Home | Services | Events | Features | Interviews | Profiles | Reviews | News | Resources | Press | Archive

Ruby on Rails: weapons of mass customisation

by Dafydd Rees

Ruby on Rails is a framework for building web applications. This article describes Ruby on Rails - or just "Rails" as it's also known - and provides some starting points for developers.

What is Ruby on Rails?

Ruby on Rails is an "extraction" or what's known as a "harvested framework". This means that the authors wrote a working web application first and then extracted some common code to form a framework. In the case of Rails that original web application was a project management application called "basecamp" (made by 37 signals) which continues to be sold as a web-based service to this day.

From the developer's point of view it's important to remember that the productivity gained from using a framework doesn't come from having a lot of code generated up front by a tool but rather it comes from the fact that a framework is essentially a prefabricated application in a particular style and that you're inserting and configuring new pieces of code within an existing scheme. As a developer you're making an up-front choice to build an application in a certain style and are committing to the scope and limits of that style. Being productive with Ruby on Rails, like any other framework is a matter of understanding how it works, choosing it when the solution fits in with the strengths of Rails and designing within it's conventions and limitations.

How it fits together

Running the built-in Web Server - When developing with Rails, it's normal to run using an embedded web server that reloads classes on every request. This means that you can normally update your code and simply refresh a browser window to see the changes. There are separate facilities for attaching a production-grade web server. To start the embedded web server you usually launch "ruby script/server" from the command-line in the root directory of the application. After running this your development environment will become visible at http://localhost:3000 and you'll see the default front page for Rails.

Models, Views and Controllers - Many web developers are now familiar with the Model-View-Controller design pattern. Rails organises most of the application code either into Ruby classes the that represent things in the application ("models"), ruby classes that determine what happens when a web request arrives ("controllers") and views, which are usually HTML template files. Within a ruby project, you can find the models, views and controllers under the "app" subdirectory.
Each model class normally corresponds with a database table mapped using a set of naming conventions. Rather than adopt a complex object-relational mapping schema as is common in the Java world Rails adopts the simpler, more direct "ActiveRecord" pattern.



The relationship between the name in a web request and the name of the corresponding controller that manages the web request is governed by the rules described in the "routes.rb" file in the "config" subdirectory. Whilst there are defaults, many different configurations are possible. Unless the application has a non-standard configuration you can see which controller runs and which method within a controller runs by looking at the URL sent into the web application. For example given an application with a "TinkerToysController" (filed under app/controllers/tinker_toys_controller.rb), running:

http://localhost:3000/tinker_toys/1

will cause the "show" method on "TinkerToysController" class to run.

Sustainable Development - It's good to see that Rails incorporates a number of practices that encourage maintainable projects. For example, Rails creates three different "environments" with each new project: "development", "test" and "production". Each of these is a named configuration of your application. This allows clear separation between the work you do as a developer, testing and the configuration you use to set the project up for production use. In addition, Rails considers the issue of upgrading and versioning database schemas using a facility called "migrations". Every Rails database has a table called "schema_info". Rails can use this and a series of numbered database changes to migrate environments from one version of the database schema to another. This makes upgrading different installations of the application considerably easier, and having the infrastructure to do this standardised is quite valuable.

Scaffolding - In addition to creating the application, Rails can generate models, views and controllers in a "boilerplate" fashion. It's important to note that these aren't intended to be used as final implementations but as a starting point for further development. The comand of interest is called "generate" and can be launched from the root directory of a Rails application by issuing "ruby script/generate". The most comprehensive generated option is "scaffold" which generates a model, controller and views given the appropriate parameters. Running "ruby script/generate scaffold" will yield further instructions. (It's worth noting that if you generate a model using scaffolding, you might need to update your database version to incorporate the migrations that might be generated to modify your database. You do this by typing "rake db:migrate")

Where to go from here

Rails is a popular platform with many freely available on-line resources.The best known tutorial book is "Agile Development with Ruby on Rails". It presents a sample application and takes the reader through a number of development stages adding features as it goes. It's advantageous that this book is available as a PDF as well as in print, making it searchable and easy to carry around.

The most important thing to note about Rails documentation is that Ruby and Rails are both undergoing a series of rapid changes as they mature. It's important to try out what you read rather than just accepting it as a lot of the "how to" literature is out of date.

In the rush to develop new web applications, many people neglect the Ruby programming language itself, preferring to rely on the canned functionality of the Rails framework. This is a false economy as you can't understand Rails or any of the Rails plugins without a reasonable grasp of the language. Most commercial programmers (especially those from a C++, Java or C# background) aren't familiar with the dynamically typed object-oriented approach taken by Ruby so it's important to spend some time learning the language itself rather than just following Rails "howto" documentation. The book "Programming Ruby" by the Pragmatic Programmers, although popular is verbose and overly long. It's especially annoying that about half of the 803 page book is simply a less current version of the API documentation that's freely available on the web. Including that material just means the book goes out of date sooner and that it's more cumbersome to carry around. I recommend Flanagan and Matsumoto's book "The Ruby Programming Language" instead because it's well-organised and far more concise.

The "railscasts" video podcasts are a series of mini-tutorials that explain a concept or show you how to do something by video. The "railscasts" video podcasts are free whereas there are additional paid-for mini-tutorials under the name "peepcode". Both can be quite effective for learning a new technique.

Conclusion

Home | Services | Events | Features | Interviews | Profiles | Reviews | News | Resources | Press | Archive
About ITWales | Privacy Policy
All material on this website ©2002-2008 ITWales