Getting Back on Rails

I've been pretty busy in the past months and didn't felt inspired enough to write. Today is time to get back to writing in a human language instead of a computer one.

Coming Back Home

I've been involved in web development for more than ten years, but for a long time I could only be labeled a designer. A little more than four years ago I began developing web sites using that awesome little framework named Ruby on Rails. After toying with it for less than a year, I gave it up to go on the dangerous path of trying to really understand what was going on behind all that magic. After learning a lot while dabbling into some lesser known frameworks like Pylons, Helma and then Compojure, I now got the chance to code in a more professional setting using Ruby on Rails.

Good Old Rails Has Changed

For the better! Since four years ago, Rails has visibly matured and it is now used in a lot of very successful web sites. All this popularity pushed the framework to evolve and it has become much more capable with the help of an army of plugins. Some simple features were kicked out of the main codebase to be replaced by plugins. For example, the built-in pagination was removed from Rails 2.0 and turned into a plugin called classic_pagination. It has fallen out of favor for another plugin, will_paginate, which is really much better.

Back then there was a generator called login to build basic authentication and user management features into your application. This generator has been deprecated and now there's multiple plugins available. I've only tried Authlogic by now and I'm pleased by its simplicity and customizability so far.

And there's a lot more! More conventions, more syntactic sugar, more ready to use plugins. One notable change is that Rails is now RESTful, meaning that it uses the HTTP protocol intelligently for routing requests. For example, if a DELETE request with only the name of the controller is sent, by convention, Rails will call the destroy action. One last thing to note is that ERb template files have given up the .rhtml file extension for a more versatile .erb appended after the output file extension.

Development Environment

Well, I'm a staunch Emacs user, so I ended up using it for developing Rails applications. Nonetheless, I was curious about the degree of support offered by some IDEs, especially from the latest release of NetBeans which some people say is getting pretty good. I've tried it for a couple of hours to find out that it was really not the kind of environment I'd like to work in.

First, the wizard wasn't able to create a database in Derby because it tried using the inexistent root user. Then it was the included GlassFish server that didn't want to use another port than 8080, completely ignoring the provided configuration file (which is WEBrick specific it appears). Those are all minor glitch, but it continued like that for an hour or two and soon I felt the need for this trusty Emacs text editor. The most glaring bug that really pushed me off NetBeans was the configuration screen for syntax highlighting, it was at some point using 90% of both cores on my machine! No wonder everybody says Microsoft have the lead in the IDE world, even I must say that it's a decent development environment after manually setting Emacs like shortcuts (the included ones just don't cut it).

Emacs Configuration

There's two mode for Rails on Emacs, namely emacs-rails and Rinari. The first one is older and is quite outdated. It has been replaced by a new mode named emacs-rails-reloaded by the same author. It provides navigation between the multitude of files in a Rails project, make it easy to call rake or generators and a lot more. Rinari is a lightweight alternative that I haven't tried yet but it looks quite capable too.

For editing the ERb templates, you can use the nXhtml mode, which is already included in the Windows port of Emacs. I had some compatibility issues between that version and emacs-rails-reloaded and had to install the latest version.

Deployment

I had the opportunity of deploying an application and find out that there were great improvements made on this side.

First and foremost, is that incredible tool called Capistrano. It make deploying Rails application in a consistent and reversible manner a breeze. With very little configuration, it will copy your files in a date/time tagged directory, help you easily start/stop your application server(s) and get back online previously deployed versions easily. It's even more than just a tool for RoR projects, you can understand it as being a sort of Makefile for remotely controlling multiple servers.

Finally, back in the days, most hosting provider offered only fastCGI or mod_rails on top of Apache for running your applications. Today there's more options, but I won't go through all of them as I've still got much to learn about them. For now I've learned that Passenger (previously mod_rails or mod_rack) is the recommended way of deploying a Rails app, it can use Apache or Nginx as its web server.