Re: Ruby On Rails on the iSeries -- WEB400

Joe, et al,

I have started about three posts and abandoned them as this debate hasprogressed. My reluctance to weigh in has as much to do with mybackground and experience as it does with the fact that my thoughts areevolving and slowly gelling. I am not a "classically trained"programmer. I wrote my first program using Fortran when I was aFreshman in HS (we had just upgraded from using an Abacus and some stonetools), and although I continued to intersect with technology over theyears, my Masters degree is in Economics, not Computer Science. I am a"Seat of the Pants" programmer. I absolutely love what I do. Would NOTtrade it for any job, no matter how much it pays, primarily because offolks like those on this list. Passionate people who love technologybecause of the mental gymnastics workout it give us and the good feelingthat solving problems can bring (well, OK, not *everyone* on the list isin that camp.....)

So here is what I can glean from the discussion (and I wish more of thiswas going on when I joined the list 4 years ago when we were making Webtool/language decisions):


1.   You have to use the right tool for the right job
2.   There is no one tool you can use for every job

I can see Joe Pluta with these two tablets, standing on the mountain topleading the programmer masses across the application desert (hey, theimagery works for me!). These are two good principles and I can see howthey can apply in the following areas:

1. 85% of the applications my customers want are either A. Simple HTMLCRUD applications used on an intranet for data maintenance or B. Simpleweb "self service" applications where data can be retrieved andupdated. That is about it. No "enterprise ready" level stuff here.RPG CGI would be overkill in some cases here. I want to simply displaydata and, perhaps update it. RoR would fit nicely here (standard 5250apps do as well) The frameworks we have worked with at my company areeither RPG-CGI based or Java based. In both cases, for simple CRUD,they are both tools that are misplaced and I see our developers workingto simplify the frameworks further and further until, guess what, itlooks like RoR!

2. Another 10% are what I would call robust CRUD applications. Lotsof validity checking. Perhaps some service information retrievalroutines. Some "processing" type calculations. Things that a simpleCRUD app simply cannot handle without breaking many of the conventionsused by the framework. Java/JSP's are a good fit here as are RPG-CGIapps. These things take time to write and debug. They tend to havehigher support costs as well (that could be just our experience so far).

3. The remaining 5% are what I would call "enterprise applications".In our case it will be payroll processing, student scheduling, month endclosing, that kind of stuff. These applications require lots ofprocessing power and fast I/O. Even though we want to have a crossplatform application suite, we may end up having to use platformspecific languages and tools to make that happen. Java works here andfortunately processing power has kept up with it's demands. But RPG isequally a player on this front. It may be advantageous to use RPG whenwe deploy to a System i.

Of course there would be plenty of debate on the whether Java/JSP andRPG-CGI would be a good fit for #1 above but something like RoR is apretty good fit for that kind of stuff so why re-invent the wheel? Myguess is that the Java/JSP - RPG-CGI folks who DO use it for very simpleCRUD have scaled it down quite a bit to do the simple stuff simply.

I guess what I am saying is that the question "Is (insert yourlanguage/tool/framework here) ready for Prime Time?" can only beanswered in the frame of reference of your business applicationdemands. Sure, we can set the standard of "enterprise ready" as theholy grail for frameworks, but that isn't really necessary for allframeworks/languages. The question to ask is "What application are youusing it for?" and then the discussion can proceed.

Finally, is RoR any better or worse a framework if it loses in the"enterprise ready showdown"? Heck no! Use it for what it is welldesigned for and don't try to make the square peg fit in a round hole.

This has been good discussion. A bit OT from Aaron's original post.BTW I AM working on a port of RoR to the PASE environment. My lack ofUNIX/Linux/AIX background is hindering me a bit. Why do you have tocompile EVERYTHING in those OS's? ;-)


Pete


Joe Pluta wrote:

From: Nathan Andelin

Joe,

 Any language or  tool not having an interface to RPG and native iSeries
resources wouldn't meet  your standards for enterprise-level business
applications, if I understand  correctly.  Even Java alone, wouldn't meet
your standards, which sounds  reasonable to me.


As long as you realize there are (at least) two levels of "enterprise
ready".  First is my personal definition which pretty much requires the
ability to take advantage of and interface with existing databases and
business logic.  I don't care how powerful the tool is, having to rewrite a
few million lines of RPG is going to hurt my ROI <smile>.  So in my
narrowest definition (which is pretty valid considering the fact that all
these lists say "400" in them) the language better have a darned good
interface to ILE.

Second, though, is the general concept of enterprise-ready, in which you can
build large, secure, scalable systems that perform enterprise-level business
functions (e.g., ERP systems).  I contrast this with things like content
management or store fronts.  These are both important applications, but

neither exactly taxes your business programming skills.

My position on Java (and OOs in general) for creating enterprise
applications has been stated pretty clearly: rigid type hierarchies make
adapting to changing business conditions very tricky, and SQL as a primary
database language, well that just stinks.  And of course you have the thorny
issue of security.  Any environment that claims to be enterprise ready had
better be able to address those issues.  J2EE addresses it with integrated
security and scalability, and the only issue is whether you can write
enterprise-level code that performs acceptably using SQL.  Oracle would seem
to indicate that you can, although I don't know of a lot of Java-based
solutions.

I hope to be able to answer some of my own questions soon enough.  Since
nobody has ever taken me up on the challenge of writing any ERP-level
algorithms using SQL, I'm going to try to do some.  Once I do, I can
incorporate them into RoR just as easily as I can into Java and VB, and
maybe we can do some benchmarks.  At the same time, I'm going to write the
same code in RPG and see what happens when we call RPG.  I'll probably do
one version with stored procedures and another with direct calls.

 There are a lot of  RPG programmers who assign field names and attributes
in display file records  the same as physical file records, so that
mapping is done automatically between  the two.  That's an example of
"convention over  configuration".


Yeah, but there are just as many people who will tell you they don't like
doing things this way, and that they in fact choose specifically to NOT use
database field names in the display file DDS.  It's a coding style
technique.  This whole "convention over configuration" issue honestly has me
a little puzzled.  I think I'd prefer a framework in which *I* could set the
preferences and then generate the code, rather than have a set of pretty
rigid standards that I need to follow.

Maybe times have changed.  Back in the day, I had a hard time getting people
to follow program naming conventions, much less the names of their files and
fields.  Today there does seem to be a lot more black box coding, so maybe
the idea of following someone else's standards is more of that same
philosophy.  Don't get me started on the infamous WEB-INF folder of the
standard J2EE layout <grin>.

 This  discussion motivated me to look into the Rails philosophy,
community, and  architecture.  It has been interesting.  I've been reading
accounts of Java and  PHP developers creating Rails versions of their
applications, and reducing the  lines of code, cutting the code in half in
one account, and comparing the  versions for performance and scalability.
The reports are favoring Ruby and  Rails.


Again, I think RoR is pretty cool, and it seems to be a good tool for some
of the jobs that PHP has traditionally been used for.  Rails seems to
provide a quick way to generate CRUD applications on top of that.  If it
also lets me quickly and easily build calls to RPG for business logic, it
may be a viable option.  I'm still leaning towards EGL's metadata approach,
though.  Once you define the metadata in EGL, defining records and messages
and dragging and dropping them onto JSFs is pretty amazing.


Joe