Can't say best :o) Experience is speaking ! Jacques
----- Original Message ----- From: "Andrew Sykes" <[EMAIL PROTECTED]> To: <[email protected]> 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 <[EMAIL PROTECTED]> > Sykes Development Ltd > http://www.sykesdevelopment.com
