Re: Ruby On Rails on the iSeries

[Pete Helgren <Pete@xxxxxxxxxx>]

Joe, et al,

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

So here is what I can glean from the discussion (and I wish more of this 
was going on when I joined the list 4 years ago when we were making Web 
tool/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 top 
leading the programmer masses across the application desert (hey, the 
imagery works for me!).  These are two good principles and I can see how 
they can apply in the following areas:

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

2.   Another 10% are what I would call robust CRUD applications.  Lots 
of validity checking.  Perhaps some service information retrieval 
routines.  Some "processing" type calculations.  Things that a simple 
CRUD app simply cannot handle without breaking many of the conventions 
used by the framework.  Java/JSP's are a good fit here as are RPG-CGI 
apps.  These things take time to write and debug.  They tend to have 
higher 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 end 
closing, that kind of stuff.  These applications require lots of 
processing power and fast I/O.  Even though we want to have a cross 
platform application suite, we may end up having to use platform 
specific languages and tools to make that happen.  Java works here and 
fortunately processing power has kept up with it's demands.  But RPG is 
equally a player on this front.  It may be advantageous to use RPG when 
we deploy to a System i.

Of course there would be plenty of debate on the whether Java/JSP and 
RPG-CGI would be a good fit for #1 above but something like RoR is a 
pretty good fit for that kind of stuff so why re-invent the wheel?  My 
guess is that the Java/JSP - RPG-CGI folks who DO use it for very simple 
CRUD 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 your 
language/tool/framework here) ready for Prime Time?" can only be 
answered in the frame of reference of your business application 
demands.  Sure, we can set the standard of "enterprise ready" as the 
holy grail for frameworks, but that isn't really necessary for all 
frameworks/languages.  The question to ask is "What application are you 
using 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 well 
designed 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 of 
UNIX/Linux/AIX background is hindering me a bit.  Why do you have to 
compile 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
>
>
>