Page 2 of 2   « previous page

ActiveRecord associations can be specified through a bit of metaprogramming:

class User < ActiveRecord::Base
    has_many :articles
end

class Article < ActiveRecord::Base
    belongs_to :user
end

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

Controllers
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])
   end

   # ... other actions
end

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
end

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

<% form_for todo do |f| %>
   <table>
     <tr><td><%= f.date_select :due_at %></td></tr>
     ...
   </table>
<% 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.

Strengths
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.

References
•  David Heinemeier Hansson. "Rails 0.5.0: The End of Vaporware!".
www.loudthinking.com/arc/000254.html.
•  TPCI - TIOBE Programming Community Index.
www.tiobe.com/tpci.htm
•  http://community.nascar.com
•  www.twitter.com
•  www.funnyordie.com

Page 2 of 2   « previous page