OFBiz/opentaps as a small business accounting package?

[Paul Gear]

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>.

[jonwimp]

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>.
>

[cjhowe]

Hey Paul,

You will probably have better luck with your opentaps
financials questions over on the opentaps sourceforge
forums.
http://sourceforge.net/forum/?group_id=145855
The guys working on that component likely follow both
mailing lists, but I would imagine they follow that
one a bit more religiously and can give you a faster
response there.

There have been quite a few discussions on many of the
topics you're interested in on the OFBiz mailing lists
as well.  You can search for the topics individually.
Nabble is a great site for these aggregations and
seeing the threads in context.  Here's the link for
the OFBiz portion of nabble.
http://www.nabble.com/OFBiz-f2740.html

There was quite a discussion a little more than a year
ago regarding using Quickbooks via SOAP with OFBiz as
well.  Depending on your needs you may consider that
route as well.

As far as creating work for yourself, a quick answer
is, perhaps.  A longer answer is that it's likely to
be time well spent. You'll end up with generally a
better understanding of your _actual business needs as
well as many ideas on how to better automate your
business around what your company's strengths are and
what your customers needs are.

There have been numbers passed around about the size
of a business that OFBiz is beneficial for and that's
at about 2 million dollar US + [Note: the size
breakpoint may simply be the size of a company that
likely has a budget large enough for a consultant to
make money on :-) ]  You may not need to be doing that
much business today, but if you're genuinely aspiring
to that size, you'll likely benefit in doing things in
an ERP/OFBiz style.

If you're needs are just to keep track of some things
kind of unofficially, you may also find some benefit
from the OFBiz framework and dumbing down a lot of the
other components.  The learning curve in OFBiz is
somewhat steep because it's integrating several tools
and concepts into one thing.  The tools individually
are rather straight forward and there's plenty
discussion and documentation regarding them on various
sites.  Most of those sites are linked off of
ofbiz.apache.org.  In addition, the user and
development mailing lists are quite busy so you can
usually get an answer pretty quickly there as well
regarding specific questions on using the tools.

Hope you find this helpful,

Chris


--- Paul Gear <[hidden email]> 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>.
>
>

[Ian McNulty]

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>.
>>
>
>
>

[jonwimp]

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>.
>>>
>>
>>
>>
>
>

[jonwimp]

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>.
>>>>
>>>
>>>
>>>
>>
>>
>
>

[cjhowe]

Jonathon,

What are you finding so confusing about minilang that
is not covered here http://docs.ofbiz.org/x/GAM ?
This document has been improved upon recently, but the
bottom half has been accessible from the ofbiz.org
site for two years that I can attest.  Coming from
someone who had ZERO java experience starting with
OFBiz (me) I find the elements are rather self
explanatory.  It's also not as if there aren't plenty
of examples using each one. I have no idea how well
minilang would hold up to creating various kinds of
other programs, but for writing business logic, it's
pretty straight forward.  If you're not finding that
to be the case, please ask questions there are plenty
of people here more than willing to help clarify.

Also, documentation doesn't write itself.  If you find
something that didn't work as expected or a task was
difficult to accomplish but you eventually accomplish
it, do a short write about how you got from point A to
point B and drop it into the wiki on docs.ofbiz.org or
write it to the mailing list and ask if someone can
find an appropriate place for it.  

There's a funny point in learning OFBiz.  You start
out looking at it as this huge monstrosity that's just
too much to figure out and you get frustrated with the
lack of documentation available (even given the sites
linked off of ofbiz.apache.org and the tens of
thousands of mailing list posts available and the
number of video tutorials available).  But you start
playing with it a bit, and you pass an "aha" moment.
You don't realize the moment that you pass it but when
you look back and think "how can I make the learning
curve easier for the next guy", you realize everything
was there, and it's difficult to figure out what you
can add to those websites that could make it any
clearer.  I digress, just ask questions.  If you're
unable to find your answer on a first pass through
nabble and on the ofbiz.apache.org ask the question to
the mailing list and someone may be able to find the
right document for you a bit faster or clarify a point
in a document that may be a bit unclear.


--- Jonathon -- Improov <[hidden email]> 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
>

=== message truncated ===

[Andrew Sykes]

Ian, Jonathon,

I definitely don't agree with treating Java is your language of choice
as a way to avoid learning Minilang, here's some reasons why...

1/ Minilang is far quicker to write.
2/ Minilang is much more limited in scope, so less danger of...
        2a. Writing unidiomatic code
        2b. Writing buggy code
3/ Being a simpler language, minilang can be handled by far more junior
personnel, and in some cases, I've seen non development staff being
fairly productive.
4/ Java developers are easier to hire, but not ones with a good
understanding of the OfBiz API.
5/ Learning minilang is a fast-track route to adopting the OfBiz
developer's mindset.
6/ So much functionality is already implemented in minilang that you
ignore it at your peril.
7/ When you finally have to adopt Minilang you'll have a load of
unmaintainable java legacy. This will no doubt seem more and more
cryptic as time goes on.

I could probably go on...

This type of approach breaks the golden rule when adopting something as
large as OfBiz, that is, read read read!, learn learn learn!, and only
then should you think of letting yourself loose on the code! You'll
thank yourself later!

No doubt various people will counter this with a whole lot of personal
dislikes about minilang, but I'll be surprised if any of these people
have been using OfBiz in anger for any length of time.

Sorry if this seems a little condescending, but I've seen this kind of
argument in my consultancy work several times, and the resulting costly
dodgy java or furious back-peddling that results from it.

- Andrew


On Thu, 2007-01-18 at 19:38 +0800, 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>.
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Jacques Le Roux]

Thanks Chris,

----- Original Message -----
From: "Chris Howe" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, January 18, 2007 1:35 PM
Subject: Re: OFBiz/opentaps as a small business accounting package?


> Jonathon,
>
> What are you finding so confusing about minilang that
> is not covered here http://docs.ofbiz.org/x/GAM ?
> This document has been improved upon recently, but the
> bottom half has been accessible from the ofbiz.org
> site for two years that I can attest.  

Jonathon, this is a work in progress, please see : https://issues.apache.org/jira/browse/OFBIZ-571
BTW the old doc Chris mentionned is always here : http://ofbiz.apache.org/docs/minilang.html.

Coming from
> someone who had ZERO java experience starting with
> OFBiz (me) I find the elements are rather self
> explanatory.  It's also not as if there aren't plenty
> of examples using each one. I have no idea how well
> minilang would hold up to creating various kinds of
> other programs, but for writing business logic, it's
> pretty straight forward.  If you're not finding that
> to be the case, please ask questions there are plenty
> of people here more than willing to help clarify.

> Also, documentation doesn't write itself.  If you find
> something that didn't work as expected or a task was
> difficult to accomplish but you eventually accomplish
> it, do a short write about how you got from point A to
> point B and drop it into the wiki on docs.ofbiz.org or
> write it to the mailing list and ask if someone can
> find an appropriate place for it.  
>
> There's a funny point in learning OFBiz.  You start
> out looking at it as this huge monstrosity that's just
> too much to figure out and you get frustrated with the
> lack of documentation available (even given the sites
> linked off of ofbiz.apache.org and the tens of
> thousands of mailing list posts available and the
> number of video tutorials available).  But you start
> playing with it a bit, and you pass an "aha" moment.
> You don't realize the moment that you pass it but when
> you look back and think "how can I make the learning
> curve easier for the next guy", you realize everything
> was there, and it's difficult to figure out what you
> can add to those websites that could make it any
> clearer.  I digress, just ask questions.  If you're
> unable to find your answer on a first pass through
> nabble and on the ofbiz.apache.org ask the question to
> the mailing list and someone may be able to find the
> right document for you a bit faster or clarify a point
> in a document that may be a bit unclear.

That's so true !

Jacques
 

>
> --- Jonathon -- Improov <[hidden email]> 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
> >
> === message truncated ===

[Jacques Le Roux]

Can't say best :o) Experience is speaking !

Jacques

----- Original Message -----
From: "Andrew Sykes" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, January 18, 2007 1:51 PM
Subject: Re: OFBiz/opentaps as a small business accounting package?

> Ian, Jonathon,
>
> I definitely don't agree with treating Java is your language of choice
> as a way to avoid learning Minilang, here's some reasons why...
>
> 1/ Minilang is far quicker to write.
> 2/ Minilang is much more limited in scope, so less danger of...
> 2a. Writing unidiomatic code
> 2b. Writing buggy code
> 3/ Being a simpler language, minilang can be handled by far more junior
> personnel, and in some cases, I've seen non development staff being
> fairly productive.
> 4/ Java developers are easier to hire, but not ones with a good
> understanding of the OfBiz API.
> 5/ Learning minilang is a fast-track route to adopting the OfBiz
> developer's mindset.
> 6/ So much functionality is already implemented in minilang that you
> ignore it at your peril.
> 7/ When you finally have to adopt Minilang you'll have a load of
> unmaintainable java legacy. This will no doubt seem more and more
> cryptic as time goes on.
>
> I could probably go on...
>
> This type of approach breaks the golden rule when adopting something as
> large as OfBiz, that is, read read read!, learn learn learn!, and only
> then should you think of letting yourself loose on the code! You'll
> thank yourself later!
>
> No doubt various people will counter this with a whole lot of personal
> dislikes about minilang, but I'll be surprised if any of these people
> have been using OfBiz in anger for any length of time.
>
> Sorry if this seems a little condescending, but I've seen this kind of
> argument in my consultancy work several times, and the resulting costly
> dodgy java or furious back-peddling that results from it.
>
> - Andrew
>
>
> On Thu, 2007-01-18 at 19:38 +0800, 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>.
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> --
> Kind Regards
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com

[jonwimp]

Andrew, Chris, Ian,

I would definitely choose Minilang over Java, if I didn't have a pressing "do it this minute"
schedule. It is definitely the right step forward.

I tried Minilang for a while, then realized there ARE some constructs I can't quite do like I
would with Java. Same for screen/form widgets. I posted a short question asking if there's any
docs for screen/form widgets. No response thus far. But I've since learned what env-name,
map-name, etc mean. Not by docs I can find, but through the widget framework Java sources. Simple
concepts like "how do I extract a field value and put it to a variable for later use", or even
"how do I create a variable for computation" required some digging into widget framework Java sources.

So, what did I do? I got the job done. Java works. Minilang can wait. :P Screen/form widgets can
wait (I used a Java service attached by an ECA).

Did I do a messy buggy Java routine? I'd ask you the same question. With some basic programming
principles, it's not difficult to write reusable extensible code (see the mutable checks sequence
I wrote for http://issues.apache.org/jira/browse/OFBIZ-627).

Sure, I'll eventually find it easier to do things in Minilang. Many Minilang constructs are direct
clones of Java functions anyway, so converting from one to the other and back won't be so tough.
But it's the variables, scope, "where did that variable's value got stomped" problems that put the
brick wall up for me.

So, as things stand now, I (being a Java programmer of sorts), found it easier in Java. A simple
Java programmer like me knows certain "tricks of trade" to figure out the structure of Minilang or
widget XMLs. But what about non-programmers?

 > 6/ So much functionality is already implemented in minilang that you ignore
 > it at your peril.

Anyway, I am able to tap all of Minilang's features using Java alone, so I do get best of both
worlds. :)

Actually, to be fair, Minilang isn't so bad in terms of docs (by now? recently?). See
http://ofbiz.apache.org/docs/minilang.html . I was really struggling with widget XMLs.

Right now, my project is moving ahead. And that's what counts. Sigh. Couldn't there be a time when
we abolish work, and everybody does things simply for exploration and science?

Chris,

 > Also, documentation doesn't write itself.  If you find
 > something that didn't work as expected or a task was
 > difficult to accomplish but you eventually accomplish
 > it, do a short write about how you got from point A to
 > point B and drop it into the wiki on docs.ofbiz.org or
 > write it to the mailing list and ask if someone can
 > find an appropriate place for it.

I'd be fired! I did try to get quickstart advice from mailing list, remember? But now that I've
posted questions, waited for response, dug in myself, and found answered my posts myself, I can't
find much time left to write up those docs. I don't even have enough time to submit my
enhancements and bugfixes!

Yes, bad bad programmer, not very opensource-spirited. But like I said, I can be a very
opensource-spirited non-programmer (after being fired), or I can just "do my job" and hope I can
swing back some time to contribute.

And I'll definitely want to do something for OFBiz. As I told someone here before, I'm thoroughly
enjoying OFBiz (like the manufacturing and product Virtual BOMs stuff done by Jacopo?).

 > There's a funny point in learning OFBiz.  You start
 > out looking at it as this huge monstrosity that's just
 > too much to figure out and you get frustrated with the
 > lack of documentation available (even given the sites
 > linked off of ofbiz.apache.org and the tens of
 > thousands of mailing list posts available and the
 > number of video tutorials available).  But you start
 > playing with it a bit, and you pass an "aha" moment.
 > You don't realize the moment that you pass it but when
 > you look back and think "how can I make the learning
 > curve easier for the next guy", you realize everything
 > was there, and it's difficult to figure out what you
 > can add to those websites that could make it any
 > clearer.

Hindsight is always easier. I know what you mean, Chris.

It's like we stare at some seemingly random numbers scrolling through screen, we think it's noise.
But after we spot the patterns, we wonder how we didn't see it before!

I can't learn "The Matrix green downward-scrolling font" inside of 1 week. I need to get into the
Matrix and do some work RIGHT AWAY (like run the nice noodle restaurant at the corner). So,
instead of reading those green fonts, I pulled out the Matrix engine and started plugging away at
the interfaces. (Aha! So touching this and that interface gives me very good soup noodles!).

Jonathon

Andrew Sykes wrote:

> Ian, Jonathon,
>
> I definitely don't agree with treating Java is your language of choice
> as a way to avoid learning Minilang, here's some reasons why...
>
> 1/ Minilang is far quicker to write.
> 2/ Minilang is much more limited in scope, so less danger of...
> 2a. Writing unidiomatic code
> 2b. Writing buggy code
> 3/ Being a simpler language, minilang can be handled by far more junior
> personnel, and in some cases, I've seen non development staff being
> fairly productive.
> 4/ Java developers are easier to hire, but not ones with a good
> understanding of the OfBiz API.
> 5/ Learning minilang is a fast-track route to adopting the OfBiz
> developer's mindset.
> 6/ So much functionality is already implemented in minilang that you
> ignore it at your peril.
> 7/ When you finally have to adopt Minilang you'll have a load of
> unmaintainable java legacy. This will no doubt seem more and more
> cryptic as time goes on.
>
> I could probably go on...
>
> This type of approach breaks the golden rule when adopting something as
> large as OfBiz, that is, read read read!, learn learn learn!, and only
> then should you think of letting yourself loose on the code! You'll
> thank yourself later!
>
> No doubt various people will counter this with a whole lot of personal
> dislikes about minilang, but I'll be surprised if any of these people
> have been using OfBiz in anger for any length of time.
>
> Sorry if this seems a little condescending, but I've seen this kind of
> argument in my consultancy work several times, and the resulting costly
> dodgy java or furious back-peddling that results from it.
>
> - Andrew
>
>
> On Thu, 2007-01-18 at 19:38 +0800, 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>.
>>>>>>
>>>>>
>>>>>
>>>>
>>>

[Andrew Sykes]

Jonathon,

Ok, well, I tried ;-)

- Andrew

On Thu, 2007-01-18 at 21:51 +0800, Jonathon -- Improov wrote:

> Andrew, Chris, Ian,
>
> I would definitely choose Minilang over Java, if I didn't have a pressing "do it this minute"
> schedule. It is definitely the right step forward.
>
> I tried Minilang for a while, then realized there ARE some constructs I can't quite do like I
> would with Java. Same for screen/form widgets. I posted a short question asking if there's any
> docs for screen/form widgets. No response thus far. But I've since learned what env-name,
> map-name, etc mean. Not by docs I can find, but through the widget framework Java sources. Simple
> concepts like "how do I extract a field value and put it to a variable for later use", or even
> "how do I create a variable for computation" required some digging into widget framework Java sources.
>
> So, what did I do? I got the job done. Java works. Minilang can wait. :P Screen/form widgets can
> wait (I used a Java service attached by an ECA).
>
> Did I do a messy buggy Java routine? I'd ask you the same question. With some basic programming
> principles, it's not difficult to write reusable extensible code (see the mutable checks sequence
> I wrote for http://issues.apache.org/jira/browse/OFBIZ-627).
>
> Sure, I'll eventually find it easier to do things in Minilang. Many Minilang constructs are direct
> clones of Java functions anyway, so converting from one to the other and back won't be so tough.
> But it's the variables, scope, "where did that variable's value got stomped" problems that put the
> brick wall up for me.
>
> So, as things stand now, I (being a Java programmer of sorts), found it easier in Java. A simple
> Java programmer like me knows certain "tricks of trade" to figure out the structure of Minilang or
> widget XMLs. But what about non-programmers?
>
>  > 6/ So much functionality is already implemented in minilang that you ignore
>  > it at your peril.
>
> Anyway, I am able to tap all of Minilang's features using Java alone, so I do get best of both
> worlds. :)
>
> Actually, to be fair, Minilang isn't so bad in terms of docs (by now? recently?). See
> http://ofbiz.apache.org/docs/minilang.html . I was really struggling with widget XMLs.
>
> Right now, my project is moving ahead. And that's what counts. Sigh. Couldn't there be a time when
> we abolish work, and everybody does things simply for exploration and science?
>
> Chris,
>
>  > Also, documentation doesn't write itself.  If you find
>  > something that didn't work as expected or a task was
>  > difficult to accomplish but you eventually accomplish
>  > it, do a short write about how you got from point A to
>  > point B and drop it into the wiki on docs.ofbiz.org or
>  > write it to the mailing list and ask if someone can
>  > find an appropriate place for it.
>
> I'd be fired! I did try to get quickstart advice from mailing list, remember? But now that I've
> posted questions, waited for response, dug in myself, and found answered my posts myself, I can't
> find much time left to write up those docs. I don't even have enough time to submit my
> enhancements and bugfixes!
>
> Yes, bad bad programmer, not very opensource-spirited. But like I said, I can be a very
> opensource-spirited non-programmer (after being fired), or I can just "do my job" and hope I can
> swing back some time to contribute.
>
> And I'll definitely want to do something for OFBiz. As I told someone here before, I'm thoroughly
> enjoying OFBiz (like the manufacturing and product Virtual BOMs stuff done by Jacopo?).
>
>  > There's a funny point in learning OFBiz.  You start
>  > out looking at it as this huge monstrosity that's just
>  > too much to figure out and you get frustrated with the
>  > lack of documentation available (even given the sites
>  > linked off of ofbiz.apache.org and the tens of
>  > thousands of mailing list posts available and the
>  > number of video tutorials available).  But you start
>  > playing with it a bit, and you pass an "aha" moment.
>  > You don't realize the moment that you pass it but when
>  > you look back and think "how can I make the learning
>  > curve easier for the next guy", you realize everything
>  > was there, and it's difficult to figure out what you
>  > can add to those websites that could make it any
>  > clearer.
>
> Hindsight is always easier. I know what you mean, Chris.
>
> It's like we stare at some seemingly random numbers scrolling through screen, we think it's noise.
> But after we spot the patterns, we wonder how we didn't see it before!
>
> I can't learn "The Matrix green downward-scrolling font" inside of 1 week. I need to get into the
> Matrix and do some work RIGHT AWAY (like run the nice noodle restaurant at the corner). So,
> instead of reading those green fonts, I pulled out the Matrix engine and started plugging away at
> the interfaces. (Aha! So touching this and that interface gives me very good soup noodles!).
>
> Jonathon
>
> Andrew Sykes wrote:
> > Ian, Jonathon,
> >
> > I definitely don't agree with treating Java is your language of choice
> > as a way to avoid learning Minilang, here's some reasons why...
> >
> > 1/ Minilang is far quicker to write.
> > 2/ Minilang is much more limited in scope, so less danger of...
> > 2a. Writing unidiomatic code
> > 2b. Writing buggy code
> > 3/ Being a simpler language, minilang can be handled by far more junior
> > personnel, and in some cases, I've seen non development staff being
> > fairly productive.
> > 4/ Java developers are easier to hire, but not ones with a good
> > understanding of the OfBiz API.
> > 5/ Learning minilang is a fast-track route to adopting the OfBiz
> > developer's mindset.
> > 6/ So much functionality is already implemented in minilang that you
> > ignore it at your peril.
> > 7/ When you finally have to adopt Minilang you'll have a load of
> > unmaintainable java legacy. This will no doubt seem more and more
> > cryptic as time goes on.
> >
> > I could probably go on...
> >
> > This type of approach breaks the golden rule when adopting something as
> > large as OfBiz, that is, read read read!, learn learn learn!, and only
> > then should you think of letting yourself loose on the code! You'll
> > thank yourself later!
> >
> > No doubt various people will counter this with a whole lot of personal
> > dislikes about minilang, but I'll be surprised if any of these people
> > have been using OfBiz in anger for any length of time.
> >
> > Sorry if this seems a little condescending, but I've seen this kind of
> > argument in my consultancy work several times, and the resulting costly
> > dodgy java or furious back-peddling that results from it.
> >
> > - Andrew
> >
> >
> > On Thu, 2007-01-18 at 19:38 +0800, 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>.
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[jonwimp]

Andrew,

Yeah, we all tried. Maybe I have my head so buried in Java I can't see the simple methods in Minilang.

For now, given a hot-soup mix of problems from screen/form widgets and problems with some
constructs in Minilang, I'm forced to drive things forward this way: Use Java services but
leverage every convenience method in Minilang.

Once I'm done with this current project (or when I'm fired), I can come back here to "explore and
contribute". Oh well. Back to work. :( ... :) ... :/

I still say that OFBiz rules! And I intend to prove my instincts right, after I'm done with project.

With regards Ian's comments, I personally like winning the Le Mans (less docs, more progress, but
then why do bugfix rates seem to slow down recently?). I'm a wannabe race car driver who takes
apart race cars, so I don't quite care for driver's manual in glove compartment. But then, I'm
also NOT known for having a forte in amassing world-wide adoption for OFBiz, nor can I be held
responsible for OFBiz's future popularity. :P

Jonathon

Andrew Sykes wrote:

> Jonathon,
>
> Ok, well, I tried ;-)
>
> - Andrew
>
> On Thu, 2007-01-18 at 21:51 +0800, Jonathon -- Improov wrote:
>> Andrew, Chris, Ian,
>>
>> I would definitely choose Minilang over Java, if I didn't have a pressing "do it this minute"
>> schedule. It is definitely the right step forward.
>>
>> I tried Minilang for a while, then realized there ARE some constructs I can't quite do like I
>> would with Java. Same for screen/form widgets. I posted a short question asking if there's any
>> docs for screen/form widgets. No response thus far. But I've since learned what env-name,
>> map-name, etc mean. Not by docs I can find, but through the widget framework Java sources. Simple
>> concepts like "how do I extract a field value and put it to a variable for later use", or even
>> "how do I create a variable for computation" required some digging into widget framework Java sources.
>>
>> So, what did I do? I got the job done. Java works. Minilang can wait. :P Screen/form widgets can
>> wait (I used a Java service attached by an ECA).
>>
>> Did I do a messy buggy Java routine? I'd ask you the same question. With some basic programming
>> principles, it's not difficult to write reusable extensible code (see the mutable checks sequence
>> I wrote for http://issues.apache.org/jira/browse/OFBIZ-627).
>>
>> Sure, I'll eventually find it easier to do things in Minilang. Many Minilang constructs are direct
>> clones of Java functions anyway, so converting from one to the other and back won't be so tough.
>> But it's the variables, scope, "where did that variable's value got stomped" problems that put the
>> brick wall up for me.
>>
>> So, as things stand now, I (being a Java programmer of sorts), found it easier in Java. A simple
>> Java programmer like me knows certain "tricks of trade" to figure out the structure of Minilang or
>> widget XMLs. But what about non-programmers?
>>
>>  > 6/ So much functionality is already implemented in minilang that you ignore
>>  > it at your peril.
>>
>> Anyway, I am able to tap all of Minilang's features using Java alone, so I do get best of both
>> worlds. :)
>>
>> Actually, to be fair, Minilang isn't so bad in terms of docs (by now? recently?). See
>> http://ofbiz.apache.org/docs/minilang.html . I was really struggling with widget XMLs.
>>
>> Right now, my project is moving ahead. And that's what counts. Sigh. Couldn't there be a time when
>> we abolish work, and everybody does things simply for exploration and science?
>>
>> Chris,
>>
>>  > Also, documentation doesn't write itself.  If you find
>>  > something that didn't work as expected or a task was
>>  > difficult to accomplish but you eventually accomplish
>>  > it, do a short write about how you got from point A to
>>  > point B and drop it into the wiki on docs.ofbiz.org or
>>  > write it to the mailing list and ask if someone can
>>  > find an appropriate place for it.
>>
>> I'd be fired! I did try to get quickstart advice from mailing list, remember? But now that I've
>> posted questions, waited for response, dug in myself, and found answered my posts myself, I can't
>> find much time left to write up those docs. I don't even have enough time to submit my
>> enhancements and bugfixes!
>>
>> Yes, bad bad programmer, not very opensource-spirited. But like I said, I can be a very
>> opensource-spirited non-programmer (after being fired), or I can just "do my job" and hope I can
>> swing back some time to contribute.
>>
>> And I'll definitely want to do something for OFBiz. As I told someone here before, I'm thoroughly
>> enjoying OFBiz (like the manufacturing and product Virtual BOMs stuff done by Jacopo?).
>>
>>  > There's a funny point in learning OFBiz.  You start
>>  > out looking at it as this huge monstrosity that's just
>>  > too much to figure out and you get frustrated with the
>>  > lack of documentation available (even given the sites
>>  > linked off of ofbiz.apache.org and the tens of
>>  > thousands of mailing list posts available and the
>>  > number of video tutorials available).  But you start
>>  > playing with it a bit, and you pass an "aha" moment.
>>  > You don't realize the moment that you pass it but when
>>  > you look back and think "how can I make the learning
>>  > curve easier for the next guy", you realize everything
>>  > was there, and it's difficult to figure out what you
>>  > can add to those websites that could make it any
>>  > clearer.
>>
>> Hindsight is always easier. I know what you mean, Chris.
>>
>> It's like we stare at some seemingly random numbers scrolling through screen, we think it's noise.
>> But after we spot the patterns, we wonder how we didn't see it before!
>>
>> I can't learn "The Matrix green downward-scrolling font" inside of 1 week. I need to get into the
>> Matrix and do some work RIGHT AWAY (like run the nice noodle restaurant at the corner). So,
>> instead of reading those green fonts, I pulled out the Matrix engine and started plugging away at
>> the interfaces. (Aha! So touching this and that interface gives me very good soup noodles!).
>>
>> Jonathon
>>
>> Andrew Sykes wrote:
>>> Ian, Jonathon,
>>>
>>> I definitely don't agree with treating Java is your language of choice
>>> as a way to avoid learning Minilang, here's some reasons why...
>>>
>>> 1/ Minilang is far quicker to write.
>>> 2/ Minilang is much more limited in scope, so less danger of...
>>> 2a. Writing unidiomatic code
>>> 2b. Writing buggy code
>>> 3/ Being a simpler language, minilang can be handled by far more junior
>>> personnel, and in some cases, I've seen non development staff being
>>> fairly productive.
>>> 4/ Java developers are easier to hire, but not ones with a good
>>> understanding of the OfBiz API.
>>> 5/ Learning minilang is a fast-track route to adopting the OfBiz
>>> developer's mindset.
>>> 6/ So much functionality is already implemented in minilang that you
>>> ignore it at your peril.
>>> 7/ When you finally have to adopt Minilang you'll have a load of
>>> unmaintainable java legacy. This will no doubt seem more and more
>>> cryptic as time goes on.
>>>
>>> I could probably go on...
>>>
>>> This type of approach breaks the golden rule when adopting something as
>>> large as OfBiz, that is, read read read!, learn learn learn!, and only
>>> then should you think of letting yourself loose on the code! You'll
>>> thank yourself later!
>>>
>>> No doubt various people will counter this with a whole lot of personal
>>> dislikes about minilang, but I'll be surprised if any of these people
>>> have been using OfBiz in anger for any length of time.
>>>
>>> Sorry if this seems a little condescending, but I've seen this kind of
>>> argument in my consultancy work several times, and the resulting costly
>>> dodgy java or furious back-peddling that results from it.
>>>
>>> - Andrew
>>>
>>>
>>> On Thu, 2007-01-18 at 19:38 +0800, 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>.
>>>>>>>>
>>>>>>>

[Andrew Sykes]

Jonathon,

One final point on the subject, just in case you don't already know.

If, as it seems from your email, there are just a few issues barring you
from getting productive with minilang, you could perhaps use a call-bsh
tag in the minilang to handle the odd situation when your minlang
experience is letting you down.

This isn't ideal for every situation, so be judicious, but it might just
help you on the way to surmounting the minilang hurdle!

Best of luck with it!
- Andrew


On Thu, 2007-01-18 at 23:40 +0800, Jonathon -- Improov wrote:

> Andrew,
>
> Yeah, we all tried. Maybe I have my head so buried in Java I can't see the simple methods in Minilang.
>
> For now, given a hot-soup mix of problems from screen/form widgets and problems with some
> constructs in Minilang, I'm forced to drive things forward this way: Use Java services but
> leverage every convenience method in Minilang.
>
> Once I'm done with this current project (or when I'm fired), I can come back here to "explore and
> contribute". Oh well. Back to work. :( ... :) ... :/
>
> I still say that OFBiz rules! And I intend to prove my instincts right, after I'm done with project.
>
> With regards Ian's comments, I personally like winning the Le Mans (less docs, more progress, but
> then why do bugfix rates seem to slow down recently?). I'm a wannabe race car driver who takes
> apart race cars, so I don't quite care for driver's manual in glove compartment. But then, I'm
> also NOT known for having a forte in amassing world-wide adoption for OFBiz, nor can I be held
> responsible for OFBiz's future popularity. :P
>
> Jonathon
>
> Andrew Sykes wrote:
> > Jonathon,
> >
> > Ok, well, I tried ;-)
> >
> > - Andrew
> >
> > On Thu, 2007-01-18 at 21:51 +0800, Jonathon -- Improov wrote:
> >> Andrew, Chris, Ian,
> >>
> >> I would definitely choose Minilang over Java, if I didn't have a pressing "do it this minute"
> >> schedule. It is definitely the right step forward.
> >>
> >> I tried Minilang for a while, then realized there ARE some constructs I can't quite do like I
> >> would with Java. Same for screen/form widgets. I posted a short question asking if there's any
> >> docs for screen/form widgets. No response thus far. But I've since learned what env-name,
> >> map-name, etc mean. Not by docs I can find, but through the widget framework Java sources. Simple
> >> concepts like "how do I extract a field value and put it to a variable for later use", or even
> >> "how do I create a variable for computation" required some digging into widget framework Java sources.
> >>
> >> So, what did I do? I got the job done. Java works. Minilang can wait. :P Screen/form widgets can
> >> wait (I used a Java service attached by an ECA).
> >>
> >> Did I do a messy buggy Java routine? I'd ask you the same question. With some basic programming
> >> principles, it's not difficult to write reusable extensible code (see the mutable checks sequence
> >> I wrote for http://issues.apache.org/jira/browse/OFBIZ-627).
> >>
> >> Sure, I'll eventually find it easier to do things in Minilang. Many Minilang constructs are direct
> >> clones of Java functions anyway, so converting from one to the other and back won't be so tough.
> >> But it's the variables, scope, "where did that variable's value got stomped" problems that put the
> >> brick wall up for me.
> >>
> >> So, as things stand now, I (being a Java programmer of sorts), found it easier in Java. A simple
> >> Java programmer like me knows certain "tricks of trade" to figure out the structure of Minilang or
> >> widget XMLs. But what about non-programmers?
> >>
> >>  > 6/ So much functionality is already implemented in minilang that you ignore
> >>  > it at your peril.
> >>
> >> Anyway, I am able to tap all of Minilang's features using Java alone, so I do get best of both
> >> worlds. :)
> >>
> >> Actually, to be fair, Minilang isn't so bad in terms of docs (by now? recently?). See
> >> http://ofbiz.apache.org/docs/minilang.html . I was really struggling with widget XMLs.
> >>
> >> Right now, my project is moving ahead. And that's what counts. Sigh. Couldn't there be a time when
> >> we abolish work, and everybody does things simply for exploration and science?
> >>
> >> Chris,
> >>
> >>  > Also, documentation doesn't write itself.  If you find
> >>  > something that didn't work as expected or a task was
> >>  > difficult to accomplish but you eventually accomplish
> >>  > it, do a short write about how you got from point A to
> >>  > point B and drop it into the wiki on docs.ofbiz.org or
> >>  > write it to the mailing list and ask if someone can
> >>  > find an appropriate place for it.
> >>
> >> I'd be fired! I did try to get quickstart advice from mailing list, remember? But now that I've
> >> posted questions, waited for response, dug in myself, and found answered my posts myself, I can't
> >> find much time left to write up those docs. I don't even have enough time to submit my
> >> enhancements and bugfixes!
> >>
> >> Yes, bad bad programmer, not very opensource-spirited. But like I said, I can be a very
> >> opensource-spirited non-programmer (after being fired), or I can just "do my job" and hope I can
> >> swing back some time to contribute.
> >>
> >> And I'll definitely want to do something for OFBiz. As I told someone here before, I'm thoroughly
> >> enjoying OFBiz (like the manufacturing and product Virtual BOMs stuff done by Jacopo?).
> >>
> >>  > There's a funny point in learning OFBiz.  You start
> >>  > out looking at it as this huge monstrosity that's just
> >>  > too much to figure out and you get frustrated with the
> >>  > lack of documentation available (even given the sites
> >>  > linked off of ofbiz.apache.org and the tens of
> >>  > thousands of mailing list posts available and the
> >>  > number of video tutorials available).  But you start
> >>  > playing with it a bit, and you pass an "aha" moment.
> >>  > You don't realize the moment that you pass it but when
> >>  > you look back and think "how can I make the learning
> >>  > curve easier for the next guy", you realize everything
> >>  > was there, and it's difficult to figure out what you
> >>  > can add to those websites that could make it any
> >>  > clearer.
> >>
> >> Hindsight is always easier. I know what you mean, Chris.
> >>
> >> It's like we stare at some seemingly random numbers scrolling through screen, we think it's noise.
> >> But after we spot the patterns, we wonder how we didn't see it before!
> >>
> >> I can't learn "The Matrix green downward-scrolling font" inside of 1 week. I need to get into the
> >> Matrix and do some work RIGHT AWAY (like run the nice noodle restaurant at the corner). So,
> >> instead of reading those green fonts, I pulled out the Matrix engine and started plugging away at
> >> the interfaces. (Aha! So touching this and that interface gives me very good soup noodles!).
> >>
> >> Jonathon
> >>
> >> Andrew Sykes wrote:
> >>> Ian, Jonathon,
> >>>
> >>> I definitely don't agree with treating Java is your language of choice
> >>> as a way to avoid learning Minilang, here's some reasons why...
> >>>
> >>> 1/ Minilang is far quicker to write.
> >>> 2/ Minilang is much more limited in scope, so less danger of...
> >>> 2a. Writing unidiomatic code
> >>> 2b. Writing buggy code
> >>> 3/ Being a simpler language, minilang can be handled by far more junior
> >>> personnel, and in some cases, I've seen non development staff being
> >>> fairly productive.
> >>> 4/ Java developers are easier to hire, but not ones with a good
> >>> understanding of the OfBiz API.
> >>> 5/ Learning minilang is a fast-track route to adopting the OfBiz
> >>> developer's mindset.
> >>> 6/ So much functionality is already implemented in minilang that you
> >>> ignore it at your peril.
> >>> 7/ When you finally have to adopt Minilang you'll have a load of
> >>> unmaintainable java legacy. This will no doubt seem more and more
> >>> cryptic as time goes on.
> >>>
> >>> I could probably go on...
> >>>
> >>> This type of approach breaks the golden rule when adopting something as
> >>> large as OfBiz, that is, read read read!, learn learn learn!, and only
> >>> then should you think of letting yourself loose on the code! You'll
> >>> thank yourself later!
> >>>
> >>> No doubt various people will counter this with a whole lot of personal
> >>> dislikes about minilang, but I'll be surprised if any of these people
> >>> have been using OfBiz in anger for any length of time.
> >>>
> >>> Sorry if this seems a little condescending, but I've seen this kind of
> >>> argument in my consultancy work several times, and the resulting costly
> >>> dodgy java or furious back-peddling that results from it.
> >>>
> >>> - Andrew
> >>>
> >>>
> >>> On Thu, 2007-01-18 at 19:38 +0800, 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>.
> >>>>>>>>
> >>>>>>>
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Andrew Ballantine]

Chris Howe wrote:

>There's a funny point in learning OFBiz.  You start
>out looking at it as this huge monstrosity that's just
>too much to figure out and you get frustrated with the
>lack of documentation available (even given the sites
>linked off of ofbiz.apache.org and the tens of
>thousands of mailing list posts available and the
>number of video tutorials available).  But you start
>playing with it a bit, and you pass an "aha" moment.
>You don't realize the moment that you pass it but when
>you look back and think "how can I make the learning
>curve easier for the next guy", you realize everything
>was there, and it's difficult to figure out what you
>can add to those websites that could make it any
>clearer.

A clear roadmap would be most useful so that the essential stuff gets read
first. And yes, there are already How to documents, architecture documents,
but there is too much to read plus every document starts with a brief resume
of OFBiz rather than getting down to the business at hand. Basically it
appears that every document has been written to stand alone and therefore
feels the need to fill in the back ground on OFBiz. I haven't yet read a
great deal of the available documentation, but there is a trend there.

Please don't take offence at these comments, they are only intended to help.
I also find that there is a lack of structure in the documents in that there
tends to be paragraph after paragraph of text which is neither reference nor
tutorial. And as I progress along the road to OFBiz heaven I will try to
document my path. In the mean time it might be useful to thrash out a style
and structure to the whole documentation suite. Heck I know this can be
difficult in the open source environment.

I would  favour a wiki approach to doing documents provided the wiki is
restricted to named members to stop spammers wrecking it. In the wiki, users
should use a colour, perhaps blue to indicate a question or need for further
detail in the flow of the document and the remainder of the contents in
black. I am quite willing to start up a tutorial document if you are all
willing to contribute to it with David acting as umpire.

Kind regards,

Andrew Ballantine.

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.14/636 - Release Date: 18/01/2007
04:00



*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************

[Ian McNulty]

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>.
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>

[Andrew Sykes]

Andrew (Ballantine),

As with everything OfBiz, progress is dictated by demand. With adoptees
coming from such varied backgrounds and with such disparate
requirements. It would be hard to create such a roadmap that would be
relevant to all.

Given that problem the obvious solution is to create free-standing
documents that allow people the entry point of their choice.

The key to success isn't where you enter, or how you progress, but
rather that you do it in a thorough manner. So 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 making sure you read all the
free-standing documents you can lay your hands on as you go of course!

I'm not advocating that you avoid creating a roadmap, in fact I'm sure
lots of people would be very grateful to you. But in the absence of one,
the steep learning curve doesn't need to be addressed in a hap-hazard
manner.

I hope that helps...
- Andrew (Sykes)


On Thu, 2007-01-18 at 16:34 +0000, Andrew Ballantine wrote:

> Chris Howe wrote:
>
> >There's a funny point in learning OFBiz.  You start
> >out looking at it as this huge monstrosity that's just
> >too much to figure out and you get frustrated with the
> >lack of documentation available (even given the sites
> >linked off of ofbiz.apache.org and the tens of
> >thousands of mailing list posts available and the
> >number of video tutorials available).  But you start
> >playing with it a bit, and you pass an "aha" moment.
> >You don't realize the moment that you pass it but when
> >you look back and think "how can I make the learning
> >curve easier for the next guy", you realize everything
> >was there, and it's difficult to figure out what you
> >can add to those websites that could make it any
> >clearer.
>
> A clear roadmap would be most useful so that the essential stuff gets read
> first. And yes, there are already How to documents, architecture documents,
> but there is too much to read plus every document starts with a brief resume
> of OFBiz rather than getting down to the business at hand. Basically it
> appears that every document has been written to stand alone and therefore
> feels the need to fill in the back ground on OFBiz. I haven't yet read a
> great deal of the available documentation, but there is a trend there.
>
> Please don't take offence at these comments, they are only intended to help.
> I also find that there is a lack of structure in the documents in that there
> tends to be paragraph after paragraph of text which is neither reference nor
> tutorial. And as I progress along the road to OFBiz heaven I will try to
> document my path. In the mean time it might be useful to thrash out a style
> and structure to the whole documentation suite. Heck I know this can be
> difficult in the open source environment.
>
> I would  favour a wiki approach to doing documents provided the wiki is
> restricted to named members to stop spammers wrecking it. In the wiki, users
> should use a colour, perhaps blue to indicate a question or need for further
> detail in the flow of the document and the remainder of the contents in
> black. I am quite willing to start up a tutorial document if you are all
> willing to contribute to it with David acting as umpire.
>
> Kind regards,
>
> Andrew Ballantine.
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.14/636 - Release Date: 18/01/2007
> 04:00
>
>
>
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Andrew Sykes]

Ian,

Java is a beast! Minilang is a simple business logic language.

The average java book will run into hundreds of pages, while minilang
docs can be read in an hour or two.

Jonathon is using java because it is familiar to him, if you're not
familiar with java, don't break your back by insisting on using that as
your entry point to OfBiz.

It's like trying to enter a building via the window on the third floor
because that's the way the window cleaner guy told you to go ;-)

- Andrew


On Thu, 2007-01-18 at 16:46 +0000, 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>.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
> >

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[jonwimp]

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>.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>

[Ian McNulty]

Andrew,

I agree with everything you're saying here.

I managed to get the engine started on both Windows and Linux before I
even knew of the existence of this mailing list. So the OOTB start-up
part of the handbook is largely all there. Trouble then was figuring out
how to get it into first gear. Hitting the workshop manuals and the
mailing lists, one message quickly became clear. If you want to get this
baby out on the road you're going to need an engineering degree. As it
happens, I have a couple of those, but not in OOP. Which kindof leaves
me a bit up OFbiz creek without a paddle :)

> A clear roadmap would be most useful so that the essential stuff gets read
> first.

My feeling entirely. I'd like to contribute by helping to get something
like that going, but where to start?

>  And yes, there are already How to documents, architecture documents,
> but there is too much to read plus every document starts with a brief resume
> of OFBiz rather than getting down to the business at hand. Basically it
> appears that every document has been written to stand alone and therefore
> feels the need to fill in the back ground on OFBiz. I haven't yet read a
> great deal of the available documentation, but there is a trend there.
>  

Another big thumbs-up from me there too. That explains why I have no
problems getting started, but can't get out of first gear.

> Please don't take offence at these comments, they are only intended to help.
>  

That's such an important point. Imo what we need is a more robust kind
of forum where we can thrash-out these kind of front-end problems
without risking stepping on the toes of those who are already
up-to-their ears working on more delicate matters of engine design.

> I also find that there is a lack of structure in the documents in that there
> tends to be paragraph after paragraph of text which is neither reference nor
> tutorial.

What struck me first is actually how literate and accomplished the
documentation is in comparison with other more mainstream Open Source
projects like osCommerce for instance. Which makes it all the more
difficult to understand why, several week later, I'm still stuck like a
rabbit in the headlights. Entranced by the power of what I see coming at
me, but with no idea where to jump next. Which is what makes me think
you may be onto something here.

>  And as I progress along the road to OFBiz heaven I will try to
> document my path. In the mean time it might be useful to thrash out a style
> and structure to the whole documentation suite. Heck I know this can be
> difficult in the open source environment.
>  

Too true. Is there anything I could do to help with this?

> I would  favour a wiki approach to doing documents provided the wiki is
> restricted to named members to stop spammers wrecking it. In the wiki, users
> should use a colour, perhaps blue to indicate a question or need for further
> detail in the flow of the document and the remainder of the contents in
> black. I am quite willing to start up a tutorial document if you are all
> willing to contribute to it with David acting as umpire.
>  

If you think a Wiki is the way to go then I'm prepared to help where I can.

I keep thinking of something I was taught at the very beginning of my
science training. That everything should be written-up in a form that
assumes no prior knowledge of the speciality at hand.

This is an ideal that can never be completely achieved. Not in this life
anyway. Only Allah makes things perfect. But it's the trying that  makes
the difference. It has to be admitted that this seems to have gone out
of fashion in recent years, which might be just one reason why we seem
to have thrown the baby out with the bathwater in the western world at
least, and science departments are closing down at a rate of knots to be
replaced with media studies departments aimed at producing more Big
Brothers. And we all know where that leads!

Not the place to be discussing these things I know. But just one of the
trends I would like to try and help to reverse.

Please let me know what I can do to help to move what you're suggesting
on to the next step.

Best,

Ian