Re: Ruby On Rails on the iSeries

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