Let's install it

tar xzvf rubygems-0.9.0.tgz
cd rubygems-0.9.0
su
ruby setup.rb

This puts a number of things (including the gem command) into /usr/bin. It also puts a lot of files into /usr/lib/ruby/site_ruby/1.8 In particular it creates the directory /usr/lib/ruby/site_ruby/1.8/rubygems.

Now to install rails, do this:

su
gem install rails --include-dependencies

This seems to work and installs rails-1.1.3 along with rake, activerecord, activesupport, actionpack, actionmailer, actionwebservice. The claim is that gem update rails can be used to update my rails installation if and when things move beyong 1.1.3

They tell me that it will "just work" with MySQL. A side note is that there is a database adapter out there for ruby access to MySQL, but we don't need to explicitly get it to use rails.

Let's test fly it (with WEBrick)

The rails command is used to create a rails application. It sets up directories and things using the appropriate conventions. I get brave and do this:

cd DocumentRoot
rails hello
cd hello
ruby script/server

Now I fire up a browser and go to the url http://mymachine.x.y:3000 and voila, it works!

Now I will add some code, following the ruby on rails book:

cd hello
ruby script/generate controller Hello

And away we go .... this seems to be the gold plated doughnut of web development environments (and I means that in a good sense, regardless of how you might have taken it). I have done more than my share of PHP, and I did try to work with modRuby (although it betrayed me at several turns and I gave up on it), but this really looks great -- I can write ruby code, get it on the web, use MySQL without dealing with SQL for the most part. How could life be any better?

My development mode quickly became the following:

• One text window with an editor hacking the controller.
• One text window with an editor hacking the views.
• One text window running Webrick.
• One window running a browser.

There was no need to have a window doing tail -f on the apache error_log as I always do when developing PHP applications. Rails gives very nice error reports right in the browser. This in itself is enough reason to dump PHP and cake, if only this would run smoothly with apache.

Server options

I am jumping ahead now to Chapter 22 in the rails book. It turns out there are 3 main options:

1. Webrick makes an excellent development server running on an alternate port, as has been done above. It could be run on port 80 if you were willing to dump apache, but you don't really want to do that.
2. Apache is the logical next step, but there are issues. I have already been disappointed by mod_ruby, and it is similarly deprecated by the authors of the rails book. Apache and CGI will work, but be impractically slow. FastCGI would be the thing. There are two variants: mod_fastcgi (for apache 1.x), which has been stagnant since 2003 (some just call it orphaned) and has issues with Apache 2.x which sometimes force people who try to use it to jump back to running Apache 1.3.x The second is mod_fcgid which is advertised to work with apache 2.x and also requires ruby-fcgi (see below). The thing to do would be to first get a rails application running with plain old CGI, then see if fastCGI will do the job. It certainly looks like the thing if you need to run an apache server.
3. A server called lighttpd is fast and has an actively developed FastCGI. You could consider dumping Apache and running lighttpd, but the word thus far is that it is not as stable as Apache.