
So, I joined the Ruby on Rails crowd. One year ago I got a complimentary book from O'Reilly, and only this week I got around to read it. I have wanted to explore Ruby on Rails for quite a while, and today I had my first taste.
I put the book on my desk, and I started following the examples on my Linux desktop.
A great architecture.
It started very well. Unlike many freehand architectures, Ruby On Rails forces you to do the right thing. Separating the programming logic from the interface is something that is recommended in all programming books, but Ruby on Rails imposes its goodness on you. If you want to take advantage of the quick framework, you need to follow the rules.

Ruby On Rails MVC architecture is not new. The geniality of this implementation is to make it easy.
Going uphill
After the theoretical part, it was show time. So I followed the tutorial. Well, I tried.It looks like Ruby on Rails 2.0 has changed a few defaults. As a result, the vast majority of great tutorials in the web and on books are broken. No kidding.
Default database
The first obstacle was easy. By default, Rails now uses SQLite3 instead of MySQL.The rationale given in the announcement is that SQLite3 is easier to use than MySQL. That may be true, provided that your application stays confined to your desktop, and perhaps to three or four users. When your application scales as to require more than one web server, you face a migration of a production environment. True, Ruby on Rails assists you in this task, but my personal feeling is that planning is better than patching.
This one was easy to spot. Many tutorials recommend editing the database configuration file, and I did it, only to find out that it was not what I expected. The online help in my Mac says that the default is still MySQL.
$ rails --version
Rails 2.0.2
$ rails --help
Usage: /usr/bin/rails /path/to/your/app [options]
Options:
-r, --ruby=path Path to the Ruby binary of your choice (otherwise scripts use env, dispatchers current path).
Default: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
-d, --database=name Preconfigure for selected database (options: mysql/oracle/postgresql/sqlite2/sqlite3).
Default: mysql
-f, --freeze Freeze Rails in vendor/rails from the gems generating the skeleton
Default: false
Anyway, the solution is to start with$ rails -d mysql project_name
And we are back in track. The tutorial could resume.scaffolds
But it turned out that the backend database was not the only significant change. This one kept me tied for about two hours.Almost every tutorial illustrates the joy of publishing with Rails, by creating a simple table, and having its contents listed on the web, with a simple editing form to insert new contents and modify existing ones. It is a feature that attracts developers to Rails, and I was eager to enjoy the quick glory of instant publishing.
It didn't work. The tutorials all sing the same song:
- generate a model
- edit the model, adding the attributes
- generate a controller
- edit the controller, adding a scaffold line
- run and marvel
Then I thought that perhaps Rails had not been installed correctly, and thus I reinstalled Rails on both boxes, and started from scratch. It failed again.
I thought that maybe, given that the new default database was SQLite3, using it could make a difference, so I tried that one as well. It failed on Mac OSX just as before, and it did not started at all on Linux, because SQLite3 was not installed (it was just an "apt-get" away, but that it's beyond the point).
So I did what I should have done in the first place. I entered "ruby on rails scaffold" on a Google search textbox, and the first item in the result list gave me the answer. RoR 2.0 breaks compatibility with the past (and with the enthusiastic tutorials that are attracting its users).
The song now is :
- generate a scaffold with attributes
- generate a controller
- run and marvel.
In the end I got my application running, and making it required just a few minutes, once I got the right moves.