After a personal desaster with M6, the RC1 proved to be quite stable. I know it is idiotic to use always the bleeding edge, but I couldn’t resist (there had been something in the relnotes that looked too tempting to me).

To make a long story short: I wasted nearly whole of last week restarting eclipse and reinstalling JREs (M6 didn’t liked Mustang at all), but with RC1 under 1.5.06 no crash during the weeked using WST 1.5M4. OK, I restarted twice because WST got confused about the state of my Tomcat, but that was OK.

I think. It was the first time I started right out with WST a J2EE application, and hey I was an awesome experience. When using WST on an existing “J2EE project” - that is a project not created with J2EE you’ll miss many features and some things simply don’t work properly (at random, sometimes:-).

I wrote a simple Ajax app with it (actually without any XML, but that seems to be the trend, not?) which was targeted at a PHP deployment. I wanted to learn the SAJAX for the client-side so I decided to do it J2EE-wise where I am 100% sure what I am doing (and that it is also done by the machine - I hate magic, unless I do it myself).

Well, just aside: The PHP implementation took me much longer than developing the Java code!

SAJAX on the other hand is quite nice, when I find some time (so many interesting thing to do, so little time) I’ll contribute something to leverage it from J2EE more easily.

I am pretty neutral on this Java-RoR thing, so just some thoughts.

RoR is what 4GL tools promised for the Client-Server era. Some tools kept their promise, some did not. Actually many techniques I know from the Oracle*Forms world show up in RoR. I did this long enough to see where this technology leads you and this deterrs me a bit of using RoR.

I am quite sure that 9[0-9]% of all applications perform CRUD 9[0-9]% of the time. The same is true for the IDs of the screens matching table and column names. If you name it “scaffolding” or “Block-Wizard” - it is useful and it does a huge amount of the boring work. When you say that 20% of the code takes 80% of the time you will have 80% of the code written (or guessed, interpreted by default binding…) in your runtime/framework.
What you can do with RoR is as impressing as what you could do with Forms 20 years ago. Well, Forms got extended over the following decades and it got pretty complicated. Maintenance on a Forms application got difficult also after most of the out-of the box behavior got changed by custom-code.

The point was that all the auto-magic had its price (The same is true for almost any framework written in any language). At some point the 20% of code increase their share on the coding by simply showing an exponential behavior in maintenance cost. I feel now that this is pretty normal when you rely heavily on generators/conventions that do “only” 80% of the work and let you puzzle about the rest.

This isn’t even a bad thing, although the application will finally become non-maintainable you don really not have to care. There are few systems with a lifetime of more that 10 years. And as user-requirements shift more and more quickly in unforeseeable directions, it is perhaps wiser to accept that you’ll throw this one away or limit is for a specific user-group, while you do a hack with RoR to give the clients a simplified access to your spare-parts tracking, or integrate a new system to support additional requirements instead of merging it directly into your application. There are really few systems that require an complete overview over all data (a game server) over decades (accounts at social security).

The limited data contention of ordinary applications also implicitly solves scalabilty problems (or makes the solvable): Read the rest of this entry »