In a very short time Ruby on Rails has gained popularity in the enterprise development community among both programmers and system managers. As an open source platform, Ruby is proving to offer a number of advantages for powering enterprise applications, not the least of which is a shorter development time for robust applications and the creation of denser code that's easy to work with and maintain. This article is offered as an introduction to Ruby on Rails for Java developers, offering some basic insight into the evolution of Ruby and Rails and its expanding role in enterprise application development.

The Ruby Language
Ruby was born as an open source programming language on February 24, 1993 and was publicly announced to the world in 1995. Ruby's primary author is Yukihiro "Matz" Matzumoto. Like Perl or Python, Ruby is an interpreted dynamically typed object-oriented programming language. While Java was growing at breakneck speed in the 1990s as a commercial development platform, Ruby remained a more or less academic project. Since many of its language constructs were adopted from Smalltalk, many of Ruby's initial followers were Smalltalkers and language aficionados. These early adopters had a strong cultural influence on Ruby, largely in the promotion of agile development practices for Ruby projects.

Enter Ruby on Rails
Ruby started to see a rapid rise in visibility and popularity shortly after July of 2004 when David Heinemeier Hansson released his first version of Ruby on Rails. Rails was created as a framework to create database-backed Web applications. The first application built with the new framework was a Web-based project management tool called Basecamp.

Relatively speaking Ruby is very new to the Web development space compared to competing languages. Ruby on Rails came on the scene around the time PHP was gaining ground as a standard for building small to medium-sized Web applications.

The Ruby on Rails stack is similar to Struts, WebWork, or CakePHP in using a Model/View/Controller (MVC) abstraction. Many of the early adopters of Ruby on Rails who weren't already in the Ruby community when Rails was released came from the PHP or Java worlds. The PHPers were drawn to Ruby on Rails to escape the lack of structure and the time spent developing custom standards for each application. And the Javanese were attracted because of what is often seen as the bloat and friction of the existing Java frameworks and their components. Ruby on Rails is a complete solution and avoids many of the hang-ups in other development platforms by applying a default set of standard practices to a new project and seamlessly integrating all of the subcomponents behind the scenes to provide a uniform interface to the developer.

Since Rails is a threat to existing institutions in the Web application space, it's been accused of being unfit for large deployments, or anything other than building blogs. As a developer who has applied Rails to e-commerce, social networking, distributed computing, and data reporting, among other domains, and made them scale, I can say with confidence that these claims are far from credible. Increasingly 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. Practical experience proves that Rails is highly scalable and can handle millions of users or transactions.

How Does It Work?
Rails can be broken down into two core libraries: ActiveRecord and ActionPack. ActiveRecord is an object/relational mapping (ORM) library similar to Hibernate. ActionPack encapsulates the core controller stack (ActionController) as well as a view level template engine (ActionView/ERb). A standard Rails installation includes several tools to automate a broad spectrum of common tasks as well.

One significant cultural difference between the Java frameworks and Ruby on Rails can be seen in the Rails mantra: "Convention over configuration." Every Java developer has had to endure the pain of maintaining the seemingly endless XML files that plague their projects. Rails absorbs much of this by setting forth basic conventions for file, database table, and column naming as well as directory structure. The intention of this shift is to let developers focus on the real problems, which don't include "What should we name the directory where X files are in?" or "Should ids be <tablename>_id or just id?"

Another cultural difference is exemplified by another common phrase in the Rails community - DRY up your code. DRY is the acronym for "Don't Repeat Yourself." Similar Java implementations make it very difficult to make changes. The Java and .NET solutions tend to work around this problem by building tools for the purpose of "refactoring" or renaming a definition that has references all over the place. Because so many implementation details are implied from a master source, making changes in Rails becomes straightforward and generally requires a change at a single location.

Models
The Ruby on Rails model layer is provided by ActiveRecord (AR). ActiveRecord is an ORM library in the same vein as Hibernate or TopLink. ActiveRecord objects represent individual records from a database table. Defining an AR class is very simple and much of the configuration is hidden behind default conventions:

class Page < ActiveRecord::Base
end

Compare this to an equivalent Hibernate definition:

/**
* @hibernate.class table="miners"
*/
public class Miner {
    private Long id;

    ... more column vars ...

    /**
    * @hibernate.id generator-class="native"
    */
    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }

    ... more column getters and setters ...

}

The first difference that you will notice is that there is no configuration or mention of column names in the ActiveRecord implementation. This code fragment will reference the pages table, and will have its getters and setters automatically generated. The attributes for an instance of the class are inferred from the database, as are their types. Most of these default conventions can be overridden if needed but otherwise the naming conventions provide Rails with enough information to get out of the way and let you solve the real problems at hand. The only configuration that is needed is used to set up the initial database connection; the database.yml:

development:
   adapter: mysql
   database: application_development
   username: application
   password: password
   host: localhost