2010-07-23

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 verysuccessfulweb 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.