Blogging was where we began, and how we built our company so we have preserved this archive to show how our thinking developed over a decade of developing the use of social technology inside organisations

Ruby on Rails explained (in something approaching plain English)

by Tim Duckett

There’s been no shortage of “magic bullet” technologies over the years, and one of the hottest things in web development at the moment is Ruby on Rails.   At Headshift we’re using Rails for an increasing number of projects, and we’re seeing more and more interest from clients in this technology.   Having said that, it’s not always clear what Ruby on Rails actually IS, so what follows is an overview of the whats and whys, in as non-technical terms as possible.

Java, dot Net and even historical aberrations such as Visual Basic have all been up and down the hype curve over the years, so you could be forgiven for regarding the interest in Ruby on Rails as more of the same.   As a consultancy we pride ourselves on being technology-agnostic – but nevertheless, we’re Ruby on Rails fans for a number of reasons.

What is Ruby on Rails?

Ruby on Rails is – depending on who you’re talking to, and the context in which you’re talking to them in – a number of different things:

It’s a set of technologies

Ruby on Rails, as the name suggests, is two things:  Ruby is an object-oriented scripting language which has been around since the mid-1990s, and has developed a devoted following from developers who appreciate its simplicity, readability and flexibilty.

Rails is a framework written in Ruby, and it’s the nature of the framework that makes RoR so powerful.   An awful lot of what developers do is covering old ground – most web applications have a database behind the scenes, for example – so most web applications will need database integration.   One approach is to rewrite this from scratch every time – while it’s an approach, it’s one that can be slow, expensive and prone to bugs.

A framework on the other hand takes common design patterns such as database handling and provides a set of standardised functionality that new applications can hook into.   This makes it a lot quicker to set up these standard functions – and also makes it less likely that bugs will be introduced, because if lots of applications are using the same functionality it’s likely that bugs will be quickly spotted and squashed.

It’s a set of design approaches

Rails is an “opinionated” framework – it has a set of ways of doing things, and while these can be overridden when necessary, in most situations it’s easier and quicker to use the standard approach.  This can be summarised as “convention over configuration” – for example, Rails has a standard way of abstracting an underlying database structure into classes, objects and attributes which means that it will behave in the same way from application to application and developer to developer.

Rails also uses the “model, view, controller” design pattern (or MVC for short).   This is something that’s been around successfully for years – it breaks down an application into the underlying data and business logic (the model), presentation of data to users (the views), and the code that orchestrates the interactions between model and views (the controllers).  There are some subtle but powerful advantages to an MVC approach – for example, if the models are responsible for maintaining the database and enforcing business logic, if a field must have a certain number of characters or value this can be enforced in one place (the model) rather than relying on checking at every point where the values might be changed.

“Don’t repeat yourself” is another core Rails “philosophy” – if an element of a page such as a menu is used repeatedly, then rather than rebuilding it time and time again, Rails makes it supremely easy to abstract it into a module which can be reused.

It’s a community

Both Ruby and Rails are open-source, and there’s a vibrant community which has grown up around them.  The chances are that someone has experienced – and solved – your problem at some point in the past, so rather than having to reinvent the wheel the Rails community is valuable source of help and advice.  That’s not to say that other technologies don’t have communities, but Rails seems to attract people who are naturally at home with open-source ways of working.  This also helps to explain the rapid growth in the number of plugins and code modules that have been written to extend the framework.

Why is Ruby on Rails so hot?

This is a topic that’s worthy of an entire blog post in its own right, so I’ll just look at a couple of reasons.   Rails development fits very well with Agile project management techniques – which can result in true rapid application development.  Clients are often surprised at how quickly a Rails application can be put together, and how flexibly it can respond to changes in requirements as they are discovered over the course of the project.

Speed doesn’t necessarily have to sacrifice quality, though – testing is crucially important for creating reliable software.   Rails treats testing as an integral part of development rather than an afterthought – to the extent that it’s almost easier to test than not!   A particularly powerful technique is the use of “continuous integration”.   As development takes place, tests are developed along the way – and when a new piece of code is written, all the existing tests are run to ensure that the new functionality doesn’t inadvertently break something elsewhere.

And I’ve mentioned the fact that Ruby and Rails are open-source – again the topic for a whole blog post, but the combination of quality resulting from “many eyes” looking at the code and the low cost make open source an attractive proposition in the current economic climate.

The proof of the pudding…

Here’s a small sample of some of the public Rails-based sites we’ve built:

Of course, there are also plenty of sites and services that we can’t link to from here, so if you’re looking for more details of how we could help – perhaps using some of the tools and techniques here, perhaps now – feel free to get in touch.

3 Responses to Ruby on Rails explained (in something approaching plain English)

  1. By Carlo Pecchia on May 13, 2009 at 7:39 pm

    We can also say that RubyOnRails is/has a vibrant ecosystem. And particularly on the community side we can say its community is so “inclusive” too (

  2. By James Dellow on May 14, 2009 at 11:18 am

    Nice post, Tim. It really compliments my presentation at Connecting Up Australia 2009 earlier in the week

  3. By Richard Lander on May 15, 2009 at 2:41 pm

    Thanks for this. You don’t know how long I searched the web for this, something than even a non-techie dunce like me can half understand…