Ian,
> Can we all help each other? It would be great if we could.
Sure. We'll let each other know where we need help.
> I've just starting reading Bruce Eckel's Thinking in Java and starting
> thinking, maybe there just aren't enough years left to get up to speed on all
> this?
Never enough years to speed in every direction. Just get to where you wanna be.
I'm not exactly a programmer myself, Ian. Do I know all of Java? Probably just 1% (well, ok, I did
know 99% once). PHP? Maybe 5%. But the level of my knowledge depends on "what's on my plate at the
moment". I have a problem, too. I probably won't pass many programmer tests. If I do happen to
score well, it's because I worked on reverse-engineering my memory faculties, not the programming
topic at hand. I went through school studying my learning faculties rather than the topics at
hand. Yeah, shame on me. But you can say the same of many Singaporeans! (Dispassionate, robotic,
relentless bunch of soulless creatures.)
What I'm saying is you, given your prior engineering experience plus some sense of adventure and
clever experimentation, can more than pick up any concepts or tools you need to work OFBiz.
Probably more than I can. I'm just a simple reverse-engineer (problem-solver in general), not a
real engineer. I'm also one of those "average weekend drivers", not just someone in overalls. Just
focus on "whatever is relevant to you at the moment", and you'll get started quick. I can try to
show you how if you'd like. Try my methods of picking up OFBiz or anything in general. Won't hurt
(I think).
Take Andrew Sykes' advice to Andrew Ballantine: "take a part of the code that is of interest to
you (you'll need relevance to stay motivated) and then work through artifact by artifact".
I believe that you'll be customizing OFBiz within a day of research, just like I did. Just like
many folks here did, I believe.
Join us! (or *hynotically* "join... us... join... us..."). Heh.
Well, my boss (and previous bosses) will probably tell you I can be irritating when I kept trying
to make a software engineer out of him. But I'm seriously telling you that OFBiz is a solid
framework you can easily build on/with. No kidding.
We just need to get the documentation and user manuals in place...
> So I guess what I'm saying is that, for the moment at least, I'm better off
> leaving the engineering to the experts and focussing on what the average
> driver needs to see.
That's alright. You can help to testdrive and complain! I love complainers! That's the best way
I'll know to fix something.
> For the past few years I've been installing Open Source e-commerce for
> SMEs. It's a huge and expanding sector. 150,000 members on osCommerce and Zen
> Cart forums alone! With up to 2,000 online at any one time! But the problem
> they are all now facing is, now they have a successful website, how do they
> integrate the back end with in-house accounting and POS? Which is how I
> discovered OFbiz in the first place.
Oh? I didn't realize that. Yeah, if you need help taking on that piece of pie, we can help each
other. But you might have to go through my boss first.
> I care deeply about Open Source and want to see it grow. I understand
> why Formula One racers might not see what weekend drivers and
> glove-compartment handbooks have got to do with them. My point is that a
> wider user base increases the market, the need for all levels of
> mechanics, and the bargaining power of the top class engineers.
We'll need a really solid effort to do all that, multi-tiered forums and all. Lots of work in
forum moderation (but sure, we can recruit solid volunteers to help in every stratum). And then
OFBiz might become like MySQL. Or sellout eventually like Compiere?
OFBiz's Minilang (coupled with widget XMLs), when properly documented, will be an extremely strong
pull factor. If we could somehow breach the divide between developers and users, OFBiz will
certainly be wildly successful and widely popularized virtually overnight.
Argh. Last ounce of energy. 2am. Later.
Jonathon
Ian McNulty wrote:
Jonathon,
Your words of comfort are much appreciated. My instincts tell me OFbiz
rules and I suspect God may too. So Amen from me too!
Can we all help each other? It would be great if we could.
But I think I need to make my position clear at the outset, to avoid
possible disappointment further down the line.
I've been working with computers on and off since the late 60s and have
had to learn to hack various languages, from Algol through to php. But
it was never my major area of expertise. I never got into C, so OOP and
Java is still entirely new territory for me. Java, Minilang, or
Freemarker, I'd have to learn them all from scratch, will always be
miles behind everyone else, and could be in serious danger of being more
of a cost than a benefit. I've just starting reading Bruce Eckel's
Thinking in Java and starting thinking, maybe there just aren't enough
years left to get up to speed on all this?
This could be either a major weakness or a strength, depending on where
I'm standing and what people might be relying on me to do.
From what I've seen on this group over the past few weeks, there is no
shortage of top class engineers who I have no doubt could strip down the
engine and stick it back together again working better than ever, before
I'd finished making the morning tea (or coffee, depending on what side
of the pond you're on. :)
I'm enough of an engineer to know how utterly irritating it is to have
people whittering on about irrelevancies like sticking door locks when
you've been up all night regrinding the cylinder head. But I've also
been down that road enough times to know how crucial it can be to have
someone fresh to take over, to wipe the grease off the bonnet, polish
the chrome work and wheel it out onto the forecourt, after you've done
your bit and just need to go home to bed.
So I guess what I'm saying is that, for the moment at least, I'm better
off leaving the engineering to the experts and focussing on what the
average driver needs to see.
For the past few years I've been installing Open Source e-commerce for
SMEs. It's a huge and expanding sector. 150,000 members on osCommerce
and Zen Cart forums alone! With up to 2,000 online at any one time! But
the problem they are all now facing is, now they have a successful
website, how do they integrate the back end with in-house accounting and
POS? Which is how I discovered OFbiz in the first place.
There are many points that come out of this. Too many to properly
discuss here.
First would be a huge potential market with installation fees of $3K
upwards, and with very little heavy engineering required at all. Store
owners care mainly about the look of their shop windows, the learning
curve for their staff, reducing staff overheads and the reliability of
the whole thing, and are prepared to pay for it. After a while they
start to understand the benefits of tuning the engine, which is where
the heavy engineering work kicks in. But this is something they will not
even contemplate until they are confident they have a solid vehicle that
will take them reliably from A to B.
Second would be how the structure of these forums cultivate many levels
of users, from Formula One engineers all the way through to those who
don't even want to fill up the windscreen washer themselves. And this is
only the tip of the iceberg. For every one member on these forums there
are 9 others who can't even handle the log in and just want somebody to
take care of it all for them.
I care deeply about Open Source and want to see it grow. I understand
why Formula One racers might not see what weekend drivers and
glove-compartment handbooks have got to do with them. My point is that a
wider user base increases the market, the need for all levels of
mechanics, and the bargaining power of the top class engineers.
If anybody thinks this make some kind of sense, please let me know.
Ian
Jonathon -- Improov wrote:
Er, Ian. I forgot to mention this.
The docs for engineers aren't too comprehensive either. Try putting
your best Java developers into picking up OFBiz. Take the screen
widgets and form widgets for example. See how they fare. Like I said,
Java is more documented than OFBiz-specific technologies.
BUT.. but it's entirely possible to use Java only, plus
non-OFBiz-specific technologies like Freemarker for front-end
development convenience, and to skip Minilang and screen/form widgets
to a large extent. Non-OFBiz-specific technologies are generally
better documented since their developers focus develoment time solely
on those techs, like Freemarker (front-end tool) developers don't
delve into entity engines (backend tools).
As I was telling my boss, it's actually easier to hire Java
programmers than to hire Minilang or screen/form widget programmers.
So, beware of the implications. Say I code customizations for you in
Minilang and screen/form widgets, using almost or entirely zero Java.
Future tech support could be an really hairy issue for you.
BUT... at some point (I can't guarantee when), Minilang and
screen/form widget docs will be complete, audited to be comprehensive,
etc. You'll then probably find that programming in Minilang is more
cost-effective than in Java. (Either that, or I get paid by someone to
completely reverse-engineer and document all of Minilang and
screen/form widget in a reasonable timeframe --- say a month. Not an
impossible task, just a mountain of Java codes, is all).
For now, Java is perhaps your best bet.
To the other folks in overalls, I've been meaning to ask this. Is
there any way at all to insert debug messages inside of Minilang and
screen/form widget codes? I find it easier to debug Java codes for now.
Jonathon
Jonathon -- Improov wrote:
Ian,
Amen! Yeah, God is good. OFBiz is good. Both can be hard to
understand. But I do believe that both are loving, very loving. Amen.
If there's any way we can all help each other (Paul, Ian, Jonathon),
let me know.
Jonathon
Ian McNulty wrote:
Hi Jonathon and Paul,
Could I dive in here and say I'm currently trying to get a working
model up and running that I could demo to small business clients in
the UK.
OFbiz looks so beautifully designed from the ground up, streets
ahead of the competition and adaptable to almost any situation from
running a one-man consultancy to a multinational enterprise.
It looks like the most awesome super-car you've ever seen. I can't
believe everybody won't want one.
As Jonathon says, the community seems entirely focussed on moving
forward rapidly and winning the next Le Mans. Which is how it should
be.
Imo this explains the lack of docs and the small bugs. The mass of
available documentation is actually almost as awesome as the
framework itself. Problem is that it is all aimed at engineers who
need to understand how it works ... not how to work it. Enough
workshop manuals to fill shelves in the garage, but no simple driver
handbooks you can put in the glove compartment.
This is a very fundamental difference. An entirely opposite point of
view.
Try talking to the average driver about the thermodynamics of
combustion and they glaze over in seconds. They neither need nor
want to know. They simply want to drive it. They pay the garage to
take care of all that for them so they can free themselves up to
deal with other things - like where to drive to.
It's the little, superficial things that are most important. How
does the door latch sound? Where is the gear shift and indicator
switch? How often does it break down?
This is true for all levels of users. More so in fact for the
President of a large Corporation to whom image arriving at the golf
club is everything, than to the small businessman in the street who
accepts he may have to get his hands dirty occasionally.
Winning the Le Mans is obviously a huge selling point and an
essential place to start. In those circumstance, a door latch which
needs a knack to open, the absence of a drivers handbook and the
need for team of mechanics to tune it before every race is
absolutely par for the course. And a racing driver who complains
about such things will - quite rightly - be quickly shown the door.
But for the average driver in the street it's exactly the opposite.
One sticking door latch, one miss-start, one breakdown on the first
test drive and they've had their one bite of the cherry and ain't
never coming back for more.
Imo this is the only problem I'd like to see solved.
I started out a few weeks ago trying to point out that this list is
more for users in overalls at the pit stop than drivers in business
suits on their way to the office.
Imo a forum for user-drivers rather than user-engineers would help
focus the view from the other end of the telescope and prevent
discussion of such superficial issues from clogging the inboxes of
the rocket scientists who really need to be concentrating on getting
us to Mars.
I personally would like to contribute towards the development of
some kind of drivers handbook. But if I can't get a working model
going for myself then it's hard to know where to start.
Ian
Jonathon -- Improov wrote:
Hi Paul,
I believe I'm currently doing it for a small business as well.
You'll need to customize. Customization in this case involves
defaulting many values and code execution paths for a more
condensed workflow. That is, you can cut out some unnecessary steps
in the workflow and also auto-populate default values for some
fields (or leave them blank and unused).
I propose that we work together on this? I have yet to hit the
accounting and GL side of things. I have figured out the ecommerce
(PO, SO) and product configuration side of things, though. And also
manufacturing, because my boss does manufacture stuff.
You'll find that being a novice Java developer is ALL you need to
be, the framework is that easy to use. Well, you also need acute
reverse-engineering skills because the only way you'll find out how
things work is by diving into the framework source codes (see
GenericDelegator.java for entity-related functions). No docs.
Community is too being moving OFBiz forward rapidly.
In fact, you may find it easily initially to use Java instead of
Minilang. Java is a lot more documented than Minilang.
Tell you what. I can offer you very quick answers to "how do I do
this or that". I'm a reverse-engineer by trade; I have small crack
teams that mathematically take apart legacy system codes to break
vendor-lock for my clients. So, figuring out OFBiz, given that it's
opensource no less, is really... an interesting exercise, not a
tedious impractical one.
You can help me with your accounting knowledge. (Yes, help me!! I
beg you!)
How about that?
One warning, though. There are quite a few bugs in OFBiz. They're
small issues if you can dive in to fix them yourself. But if you're
waiting for the community to fix them, you could be looking at
weeks before a patch goes in, especially for non-trivial fixes that
take time to review/audit. I'm currently holding quite a number of
fixes in-house, not yet reviewed by community and merged back into
OFBiz.
I'm deploying a customized system for my boss inside of 1 month.
And he has quite a bit of customizations to do, particularly for
the manufacturing side of things. Oh, the Manufacturing module is
very feature-rich (thanks Jacopo!), just that my boss has special
needs. I'd say we could work together and customize OFBiz for you
inside of 2 weeks?
Jonathon
Paul Gear wrote:
Hi folks,
I'm looking at different accounting/business management packages
for use
in my small business, and i was excited when i found how
comprehensive
and easy to install opentaps was.
However, it is a daunting application for the beginner, and it
leads me
to ask: is it asking for trouble trying to use it as a small business
accounting package? My requirements are fairly simple: invoicing
(services only, no inventory), general ledger, and GST tracking
for the
Australian tax system.
I'm a novice Java developer, so i can get through most basic problems
OK, but understanding the framework is a bit more complex an
undertaking. Am i just creating work for myself thinking that i
can use
OFBiz/opentaps for my small business?
Thanks in advance,
Paul
<http://paulgear.webhop.net>
--
Did you know? Using HTML email rather than plain text is less
efficient, taking anywhere from 2 to 20 times longer to download,
and a
corresponding amount more space on disk. Learn more about using
email
efficiently at <http://www.expita.com/nomime.html>.
