Tuesday, July 03, 2007

Making the enterprise see red - part I

Ruby trough Rails has been a poster-child for the so called web 2.0, but in the enterprise level the adoption rate hasn't been all that remarkable.

Rather than go trough an extensive diatribe about how adoption rates in the enterprise for just about any open source technology is always necessarily slow, because no self respecting OSS programmer plays golf, I'll just list some of the perceived weaknesses and shortcoming usually attributed to Ruby.
- Contrary to Perl, it doesn't come installed by default on just about every Unix-like OS;
- The treathing model used is week;
- Rails doesn't scale;
- It's just a fad, and it will go away before it matures;
- Poor Unicode support;
- No single good IDE and Text Editors are soo 80's;
- Nobody wants to learn yet another language especially when there is close to 0 employability for it;

While most of these are (at least to some extent) true, there are many projects that aim at overcoming them. And Ruby itself is still just version 1.8.6 at this point.

One such project seems to be catching enough wind behind it so that it could drive Ruby into mass (wishful thinking here...) adoption. JRuby.

Now, one might expect that the "J" would stand for Japanese, but remarkably it stands for Java. Isn't that ironic? Ruby is sometimes hailed as "What programmers should be using to still have time for a personal life" contrary to Java's "Write once. Then again, Just one more time... Ok, call your mom and cancel dinner" motto.

Jruby (which just recently reached the 1.0 mark) is a pure Java implementation of Ruby, and it's developed by Thomas Enebo and Charles Nutter with Ola Bini also being credited here and there, and, to some extent, sponsored by SUN. It aims at being more that just another implementation of Ruby (not that there are many...) which means that while still programming in pure Ruby, a coder can now enjoy the following added benefits:
- Java's scaling capabilities since Ruby code now runs inside a JVM which means parallelization in multi-processor setups ;
- An optimized Database connectivity with JDBC;
- Same level of Java's Unicode support;
- Garbage Collection handled by Java. (don't we all appreciate that?);
- A great IDE (Netbeans 6. Packed with all typical goodies plus code completion and a Swing Form Builder, it just might be the VB6 of the XXI century), plus a pretty good one (XCode + a hack);
- Access to those millions of lines of code in Java classes;

And last but not least : Integration. This is the one that's going bring it home.

With Jruby and a rails plugin called GoldSpike (previously rails-integration) we're a simple rake command away from turning any Rails app into a standard WAR file, which in turn can be deployed in either Tomcat or Glassfish or presumably just about any other applet container.

What this means is, in an enterprise environment where you have all these layers (think MVC in different LAN segments) set up and where any innovation is foreseen as potentially disruptive if not outright forbidden, we can easily introduce Ruby and Rails code, and from a manager's point of view its a win-win situation where the developers get things done faster, and the implemented structure is maintained without any hiccups. And they still get Sun's level of support.

In parts II and III I'll be showing some code and examples of rapid deployment with JRuby.


Dextro said...

So it will be just as slow as java is? I don't mean to bash java but the truth is that I've never had a smooth java experience in any of the computers I've used it in, not even the cellphones...

JP Antunes said...

Well, on enterprise level hardware, java ain't slow (performance wise). On a personal computer level, I must say that my personal experience is that jruby is a thad slower than ruby, and that difference is noticeable if we compare a pure rails deployment versus a tomcat based war deployment.

But my point here is not performance, it's penetration in a specific environment. I think that jruby will improve to a point were it will be a viable deployment option for just about any (more traditionalist) organization were a completely new development and deployment paradigm isn't an option.