What are you doing now?

Twitter on Ulitzer

Subscribe to Twitter on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Twitter on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Twitter Authors: Pat Romanski, Hovhannes Avoyan, Jim Kaskade, Bob Gourley, Lori MacVittie

Related Topics: Twitter on Ulitzer, Java Developer Magazine

Twitter: Article

Why Ruby on Rails Has Become a Popular "Next Platform"

A RoR Primer for Java Developers

ActiveRecord associations can be specified through a bit of metaprogramming:

class User < ActiveRecord::Base
    has_many :articles

class Article < ActiveRecord::Base
    belongs_to :user

The belongs_to expression in the Article class tells ActiveRecord to interpret a column from the database called user_id as a reference to the users. These constructs work in reverse as well with the has_many and has_one macros. With this knowledge, ActiveRecord can expose some interesting functionality that lends itself to writing very readable code:

article = Article.find(45)
user = article.user
users_articles = user.articles

The controller layer is used to control the flow of the site. It makes decisions about what template to render and if errors or notifications need to be displayed. The controller also ensures that any information received from a request is passed to the appropriate models and view templates. At a high level, each controller has a collection of actions. Early versions of Rails interpreted this as a way to construct URL paths (controller/action/id). The current mentality in the community is that each controller represents some sort of abstract or concrete "resource." Resources have four basic operations: create, read, update, and delete (CRUD). With this in mind, most controllers have the seven core actions (index, show, new, create, edit, update, destroy) and a few others.

For example, an events search page must query for a list of events and pass it up to the view. Moreover, this listing will be parameterized by some request parameters:

class EventsController < ApplicationController
   def index
     @events = Event.fulltext_find(params[:search_term])

   # ... other actions

Rails has some syntactic sugar here for filtering client requests and handling them in different ways. These come in the form of before_filter, after_filter, and around_filter. The most commonly used filter is the before_filter:

class EventsController < ApplicationController
   before_filter :login_required, :except => [:index]

   # ... other actions

The standard Rails template engine is called ERb. ERb looks very much like PHP but with Ruby:

<% form_for todo do |f| %>
     <tr><td><%= f.date_select :due_at %></td></tr>
<% end %>

The CRUD philosophy mentioned above exists at this level of the framework as well. This form_for uses information from the passed in todo ActiveRecord object along with some basic conventions to build the submit method and URL for the form. The object yielded to the form block has information about the todo object. This pattern will automatically fill in default values and can be customized and extended to reflect more complex widgets or formatting. Rails is making a lot of assumptions with this form of these helpers, but the end result is a very readable piece of code that's easy to understand and maintain.

The Ruby community has a very strong base in the agile development community. This has significantly influenced the development of the language and support libraries. There is an expectation that software and libraries are well tested. Rails is very strong in the agile space because changes to requirements are generally cheap. This "cheap bullets" property has allowed Rails developers to stay at the leading edge of the technology curve despite working in a fairly young framework.

Ruby is capable of very high code density. Unlike other structured languages, developers can easily create domain-specific languages (DSL) that simplify the expression of potentially complex ideas. You can see this technique throughout Rails. ActiveRecord has macros and constructs that come across to the programmer as a micro-language specific to ORMs. The controller layer benefits from this as well. There is no language construct for a before_filter, but Rails adds something close to aspect-oriented programming (AOP) as though it's a built-in feature.

Great, Now How Do I Show the World?
Deployment has been a sore spot for Rails since the beginning. Where Rails has made significant strides in streamlining the software development process, it's in many ways behind the times when it comes to deployment. Rails on its own is not thread-safe so parallelism must be found at the process level by running multiple application server processes.

Automation is a strength of Ruby and there has been some early progress with tools like Capistrano, which automated much of the deployment process. But most enterprise environments require a separation between the developers and operations. Most early Rails projects didn't have a differentiation and the result was tools that required an understanding of all aspects of the application to make a deployment efficient and effective.

In the last year, the JRuby project has made enormous progress in shrinking the gap when it comes to deployment. JRuby, now sponsored by Sun, is an implementation of Ruby under the JVM. A Rails application developed to run in JRuby will use JDBC as the database driver. Using a plug-in called gold_spike, a Rails application can be bundled into a .war file and be deployed onto a standard Tomcat server. Microsoft is beginning to take an interest in this as well and has started the IronRuby project (leveraging much of the work from the IronPython project) to develop a version of the Ruby interpreter that runs on the .NET common language runtime (CLR).

JRuby also facilitates Java-Ruby integration. Importing a library written in Java into Ruby and using it there is trivial with this new interpreter. This has dropped many of the pre-existing barriers to Ruby and Rails adoption in the enterprise. When you have all of the code that has already been written in Java available to your Ruby code, you gain much of the programmer-friendly features of Ruby with little downside.

Where Is Rails Going?
The core Rails team is pushing the framework towards a "resource-driven" design philosophy where a Web site is made up of many resources for which there are a few basic actions. This is illustrated by the focus on CRUD from ActiveRecord to view helpers. What Rails then adds to this structure is ultra-simple Representational Safe Transfer (REST) services. The end result of all of this is an implicit API for your application that's exported almost as a side effect of this development approach. So far this has proven a powerful abstraction in building very complex Web applications that will be integrated with larger systems.

Outside of the Rails core team there's a lot of work to drive Rails into very scalable deployments and even into the enterprise. JRuby and IronRuby are a few examples of this. Some of this development has come out of the necessity of a few successful applications that have had no choice but to blaze trails in this realm.

The Rails community is continuously working to find inefficiencies in the common tasks that we do as developers. Rails will continue to sand down the rough patches that appear in the development process.

•  David Heinemeier Hansson. "Rails 0.5.0: The End of Vaporware!".
•  TPCI - TIOBE Programming Community Index.
•  http://community.nascar.com
•  www.twitter.com
•  www.funnyordie.com

More Stories By Ryan Garver

Ryan Garver is CTO of ELC Technologies, a software-consulting firm based in Santa Barbara, California, that has the biggest team of Ruby on Rails developers bringing new applications to global 2000 companies and startups. He holds an MS in computer cience from the University of California, Santa Barbara.

Comments (10) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Is JDJ Fading Out? 12/11/07 08:29:42 AM EST

How did the JDJ let this article slip into the magazine this month? Ruby on Rails is still all hype. Code Monkeys BEWARE!

And frankly I would stay away from Grails, too. Try decompiling the resulting Java code, and any true Object Oriented Programmer will probably lose his/her lunch.

If this keeps up, I am discontinuing my subscription.

Anonymous Java Addict 12/11/07 08:24:34 AM EST

In response to :

"Rails on its own is not thread-safe so parallelism must be found at the process level by running multiple application server processes."

... Seriously, who really wants thread-safety these days anyway? :)

Same Old Same Old 12/07/07 09:46:47 PM EST

I really think it's hilarious when someone writes an article about "Ruby on Rails" and think it's the best thing since sliced bread.

I've been doing Struts since 1990 and, it's pretty darn good. And, lots of developers know it, you can get "good help" when you're "good" programmer goes awol, and, now there's more important things to consider in the "web development space" at now than the back end stuff.

Also, great line about "...large sites such as NASCAR Community, Twitter, and Funny or Die are choosing to use Rails and are undeniably demonstrating Rails' readiness for prime time." Come on, large sites??!!! Were you born in 1990?

Randal L. Schwartz 12/02/07 04:45:31 PM EST

Look at the Seaside Smalltalk framework as well. See http://seaside.st/ and note that it's about 10x as efficient for the same hardware, even before tuning, than RubyOnRails.

casp1 11/27/07 08:26:27 AM EST

What about groovy on grails - enhanced ruby and simplified Java - must be the next topic...

Ze'ev 11/27/07 04:32:35 AM EST

I would recommend looking at [http://www.python.org/about/ Python] and [http://djangoproject.com Django] as alternatives to the hyped RoR. I find Python much more readable dynamic programming language. Moreover, Python has a very big and loyal community and a enormous collection of open source libraries and frameworks. Django is a web framework written in Python that has many of the features of RoR and more.

Brian Mulroney 11/23/07 09:37:41 PM EST

God, yet another Ruby evangelist blowing his horn. Blah, blah, blah...Ruby is wonderful..Ruby is better than everything else.. ROR is the future and there's nothing else as wonderful. We've heard it all a million times on every blog and forum. Give us a break.

grid4reason 11/22/07 11:49:32 PM EST

The world is moving towards dynamic programming languages, so the question is really a matter of which dynamic programming language will win out. Python? Ruby? Perl 6? My bet is on Ruby.

an0n 11/22/07 11:46:04 PM EST

If/when RoR breaks into mainstream I'll be very surprised.

Web Frameworks 11/22/07 11:41:02 PM EST

If you like PHP and think Ruby on Rails or any other MVC framework is what you're into, you might want to check out a pretty cool and full featured MVC framework for PHP called Mojavi. It's here: http://mojavi.org].