Ruby on Rails can be incredibly easy to install for development purposes. However, there are lots of choices when you anticipate your needs in production that can quickly add complexity. After a fair amount of research, I’ve settled on the following stack:

• Debian Testing – very close to the next release of stable at this point, necessary for Mongrel installation
• Ruby 1.8.4, etc. – only available on testing
• Mongrel – considered the successor to lighthttpd for best webserver to use with RoR
• Ruby on Rails – from the trunk under version control rather than a specific release, will lock down to a release later
• MySQL 5.0.24 – the latest on Debian Testing
• Globalize – Rails plugin to support internationalization, from trunk under version control
• Subversion – for managing my source, as well as dependencies to external source code
• Emacs and Ruby and Rails Support in Emacs
• misc. supporting packages

This stack isn’t yet complete. I’ll need to add a load balancer to dish requests out to the pack of mongrel processes. I’ve skipped this step and put off that decision until I get ready to deploy my application. I can use either Mongrel without a proxy or WEBrick for development.

Disclaimer: I’m new to both Ruby and Ruby on Rails. So please take my advice with caution. This worked for me, but may not work for you.

Now let’s get down to the nuts and bolts:

Note: there is text wrapping for the code snippets. Be careful with cutting and pasting. Also note that there are a few steps that are spelled out in paragraphs rather than code snippets, these usually involve editing a file.

Let’s assume that you have already installed a clean instance of Debian Stable (Sarge) to work with (in my case on a Xen instance). The first step is upgrading to Testing.

Edit /etc/apt/sources.list to testing instead of sarge, then do the following. Obviously this assumes that you have the sudo package installed and your user has full privileges in it.

Now edit /etc/apt/sources.list by adding deb http://www.sgtpepper.net/hyspro/deb unstable/ as the last line.

Now we move onto Rails installation via rubygems (Ruby package manager, standard for Rails) rather than Debian’s apt-get. There is a Rails apt-get package if you want to stick with apt-get. We’ll be developing with EdgeRails (source code from trunk under version control) in our project, but in order to do that you have to install the latest stable release of Rails first.

We’re going to go with Mongrel (http://brainspl.at/articles/2006/04/26/dead-simple-deployment for details) for webserver cluster with some sort of proxy front end which is why we are using Testing and need to install ruby1.8-dev (to get ruby 1.8.4). Also see here for more details: http://mongrel.rubyforge.org/docs/debian-sarge.html.

Select the latest ruby version. Now let’s doublecheck our work and test.

Edit /etc/profile and add :/var/lib/gems/1.8/bin to PATH, do this for any already existing users’ .bash_profile files, too.

Edit app/views/hello_world/index.rhtml to look like:

From another shell on the same host…

After you accept the cookie, you should get “Hello World” with the current time. If not, sorry, this worked for me.

Quit lynx and in the shell where you started mongrel, hit Control-C to shut it down. Then blow away the test app.

Time to add MySQL and it’s necessary bindings for Ruby.

Change your mysql root password!

Let’s wrap up our package downloading for a bit with Imagemagick stuff for Ruby.

My project is going to require the ability to represent non-latin characters, localization, and internatilization. This is sort of dicey in Ruby because it doesn’t support Unicode natively, but there are workarounds. In this section we’ll install and set them up. See the links at the bottom of the article for details.

First up, add Unicode package to Ruby.

MySQL needs to be reconfigured to use Unicode, too. Make utf8 the default by editing /etc/mysql/my.cnf and adding this in the [mysqld] section:

Restart mysql with /etc/init.d/mysql restart. Create a test database and user. Login to
that database as the test user and run this query:

n the results if you see include this, you are all good:

Go ahead and drop your test db and user.

We aren’t quite done with internationalization, but we are close. We’ll need the Globalize plugin for Rails. We will return to that after we get the skeleton of our new app checked into version control.

If you don’t have one yet, setup a Subversion repository for your new application. In my case this was done on a different server. I’ll be using ssh to talk to the repository, so I don’t need any of Subversion’s server functionality. Here’s how I did it:

This is as root on the host where the repository is going to live…

This is in the development are on a different host…

(optional) If you haven’t already, create a ssh key pair for your development host, place it in ~/.ssh/authorized_keys on the repository machine, this makes using subversion remotely much more pleasant.

Unless you have done it already, you probably want to set SVN_EDITOR variable in your
environment. For bash do this with SVN_EDITOR=/path/to/editor; export SVN_EDITOR and/or add the above to ~/.bash_profile. In my case, of course, it was Emacs.

Ok, time to put the initial skeleton of our application into subversion.

We add our external sources as dependencies to our repository, this way subversion
knows to update them as well without us having to manage vendors source code.

First we grab Ruby on Rails from it’s trunk. From here on out, I’ll use the short form of svn commands, like ci for commit, etc.

(Read, but skip for now) Next up, the Globalize plugin.

Currently (September 27th, 2006) Globalize from the trunk doesn’t work with Rails 1.1.X. There is a branch for compatibility, but I’m waiting for the merge from the branch back to the trunk. See http://globalize-rails.org/wiki/ for details. Here’s how you would do it, if the trunk was Rails 1.1.x compatible:

Note: if you no longer want a plugin, you can uninstall it with ruby script/plugin remove plugin_name and it will even handle the subversion removal. Caveat: Earlier versions of remove or the code in your plugin may not do the right thing and clean out data, etc.

Globalize has a bunch of base tables that need to be added to your database in order to work. We’ll create our databases, add the Globalize data model, and then finish with our Emacs enhancements. After that we should be ready to start our development with RoR in earnest.

Create the databases:

Rails will need to know our password for accessing mysql…

Edit database.yml with passwords.

(Read, but skip for now) Finally, we finish our internationalization by loading the Globalize data-model

Note: if you get an error about an index name being to long, try replacing line 68 of vendor/plugins/globalize/tasks/data.rake with this:

Edit config/environment.rb for Globalize. Add the following to the end.

include Globalize # put that thing here
Locale.set_base_language(’en-NZ’) # and here ”)

If you want to use Emacs with Ruby on Rails, you’ll want to add some nice extensions that people have added. Here’s how to do it:

First ruby, there is a debian package that will install the ruby .el files and make sure the
modes are available at startup for all users:

Now Rails:

Now add the following to your .emacs file:

(defun try-complete-abbrev (old)
(if (expand-abbrev) t nil))

(setq hippie-expand-try-functions-list
‘(try-complete-abbrev
try-complete-file-name
try-expand-dabbrev))

(require ‘rails)

;; If you want to use Mongrel instead of WEBrick, add this to you .emacs file:
; (setq rails-use-mongrel t)
The next time you start Emacs, you should have a pretty sweet setup for editing Ruby and Rails.

This entry was posted on Tuesday, September 26th, 2006 at 10:39 am and is filed under open source, ruby on rails, sysadmin. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.