“Rails is the most well thought-out web development framework I’ve ever used. And that’s in a decade of doing web applications for a living. I’ve built my own frameworks, helped develop the Servlet API, and have created more than a few web servers from scratch. Nobody has done it like this before.” -James Duncan Davidson, Creator of Tomcat and Ant
I tried out the Ruby on Rails (RoR) framework this weekend and I’m quite impressed. I used Apple’s new tutorial for developers which explains how to install and quickly get up and running with a simple Accounts/Expenses webapp. I did encounter one minor glitch while following the install instructions because I was installing on my Debian Linux webserver, instead of an Apple machine. It seems the default ruby install no longer comes with the ruby-zlib library, but that was quickly fixed by following these instructions.
Rails applications all have a consistent directory structure, so you always start by running a command to generate the directory structure for you. This creates directories like app, config, doc, test, etc. The names are very familiar and easy to remember and they reinforce the purpose of the directory, i.e. the test directory is used to hold unit tests and functional tests for our application.
Automatic test creation makes testing an obvious and integral part of the development process, not an afterthought. It encourages you to think of a testing strategy upfront. This is perhaps the single most appreciated aspect of Rails development for me. You are supposed to test your code in other environments, but programmers often write code and if time permits, write tests. Rails tries to make it easy and painless (as much as possible) to test your code.
The next thing I learned about was the fact that Rails, like the Struts framework, tries to explicitly embed the notion of Models, Controllers, and Views within the development workflow. The concept of Actions, which are sent to Controllers in Rails is familiar to Struts. It is very easy to take a Rails URL (as shown in the example) and figure out how the server is going to parse and execute it.
Validation came next and I was suitably impressed. You simply need to add a few lines to the model, describing what each field should validate as, sort of like describing a type for a variable. Simply restart your server and voila, type rubbish in a field and Rails will highlight the field in red and ask you to re-enter it.
After all that, the tutorial shows you how to create a relationship between two models, much like in a relational database. The relation is that ‘one account can have many expenses’. This is accomplished in Rails by adding a ‘belongs to’ field in the Expense model (an expense belongs to an Account) and a ‘has many’ field to the Account model (an Account has many expenses). Simple as that.
Other things covered in the tutorial were:
- adding business logic to total up the expenses for the account
- using helpers to change the view slightly and show the total in red if we are over budget
- writing simple unit tests and running them
Overall an excellent introductory tutorial which has left me wanting more. I will definitely go through the Rails website and find out more about RoR and what it can do.
I know this is a small toy example and I want to know how RoR handles in a real mission critical business app as those are the only kinds of apps developers write these days 
RoR is easy to code for, but is it easy to maintain? After we get past the simplicity of the example app, how hard is it to write huge apps in it, and how long does it take a new developer to become familiar with and productive with a new codebase? These are all questions that I need answers to and I have the feeling that RoR won’t disappoint.