A brief intro to Ruby on Rails
Posted 17 November 2006
I’m currently at the Rails Edge conference, an interesting gathering of about 100 Ruby on Rails aficionados, newbies, and everything in between, in Denver. I’m excited about this framework and plan to use it for my future web development work.
For those of you who know about Rails, this post isn’t going to tell you much; I’ll have some deeper content later. But for everyone who may have heard of Rails but can’t quite make sense of it, I hope you’ll have a much better idea of what it is and why it is important by the end of this short article, even though it only scratches the surface.
Ruby is a pure object-oriented programming language, sometimes called “post-modern” and the object of an amazing amount of genuine affection. Programmers who have switched to Ruby really love this language. Ruby fans call themselves Rubyists and users groups go by the Ruby Brigade moniker. It’s attracting a lot of defectors from the Java and PHP communities, as well as from Python and Perl. I believe it is poised to become the most important language for the next wave of innovative web applications.
What’s so great about Ruby? It is clean and easy to read and to write (once you get accustomed to it), and it encourages good object-oriented programming practices without being overly constraining. It is a dynamic scripting language, which means that there’s no compilation required, no strict typing, and classes and objects can be extended dynamically at runtime. Programmers from a C++ background may find some of these freedoms horrifying and fear that they make it too easy to insert hard-to-find bugs, but the Ruby community would strongly disagree.
One of the benefits of Ruby is that it’s easy extensibility and minimalist syntax allows you to turn in into a domain specific language. In essence, this means your code can stay at a high level of abstraction, with terms that match the real-world names of the things in the domain your code deals with and a bare minimum of language-specific complexity to get in the way.
In this short piece, I’m going to have to ask you to take all this Ruby affection on faith for now, and move on to Rails, which is the short name for Ruby on Rails.
Ruby on Rails is a framework for writing web applications in Ruby. It was created by 37Signals as part of their Basecamp web-based collaboration tool. They didn’t set out to write a general-purpose framework; rather, they built the framework that they wanted for the application they were building, and when they were done, they extracted the framework from the application and published it as open source. Since then, a vibrant open-source community has helped rapidly enrich the framework. There’s a stunning amount of brainpower being applied to moving this technology forward.
Rails implements a design pattern well know to most experienced programmers, called Model-View-Controller (MVC). The code is divided into these three categories, with the following separation of responsibilities:
- Models: Models are the only code that talks to the database. They maintain the integrity of the data and do all the heavy lifting when it comes to manipulating data.
- Controllers: The controllers sit between the views and the models, making requests from the database and preparing the results for use by the views.
- Views: As the name suggests, the views are responsible for presenting information and accepting user input. Everything that is visible comes from a view.
It is certainly possible to write MVC applications in other languages, but none makes it as easy and natural as Ruby on Rails, and none has nearly as large and enthusiastic a community behind it. You can use Struts with Java to write MVC applications, but the amount of complex Java code and XML configuration that is required can be literally a factor of ten times greater than that for Rails. You can write MVC applications in PHP, but unless you work hard to avoid it, PHP’s natural path is to lure you into rolling everything into the view.
People with substantial experience building Java applications claim true order-of-magnitude improvements in productivity after moving to Rails. Perhaps even more significant, and also a source of this productivity improvement, they love doing it. Many people respect Java, and value what it can do, but few love writing programs in it. Barely a decade after its birth and rapid rise to the server programming language of choice, Java has become the old-school way of doing things that many Ruby converts say they will never go back to.
Rails encourages Agile development practices because it makes it so easy to make changes. This supports the iterative development style that is at the heart of most great applications today.
There’s lots more, from simple implementation of Ajax user interfaces to built-in templating and testing frameworks, but since this is a blog post and not a book, I’d better stop here.
Of course, Ruby on Rails is not without its drawbacks. Ruby is relatively slow, and this has been the source of much disparagement. In response, however, advocates note that while it may not make as good a use of CPU cycles as Java, it makes far better use of programmer cycles, and those are a lot more expensive and harder to scale. And there are efforts under way to increase its performance dramatically. The framework is also relatively young and rapidly evolving, which sometimes makes life challenging for developers. But to the converted, Rails has become the Holy Grail.