The Details

The backend is still CouchDB, so we didn’t have to sweat out the mysteries of Ruby 1.9 versus the MySQL adapter. In fact we pulled out ActiveRecord entirely, who says Rails is monolithic?

We are using Thin for the web server, which seems to be working great under 1.9. Mongrel had compilation issues, and we didn’t want to try moving our entire Passenger setup to 1.9.

We use the RedCloth, hpricot, json, and dm-validations gems and none of those gave us any trouble under 1.9.

Michael has been working hard on beefing up our CouchDB interface with DataMapper. With luck we should get a post from him shortly on that topic.

The Stack Today

• Apache 2.2 with mod_proxy_balance
• Thin 1.2.2
• Rails 2.3.2
• Ruby 1.9.1-p129 (on x86_64 Linux)

and

• CouchDB 0.9.0
• Erlang (BEAM) 5.6.3 (also 64-bit)

Notes from Installing and using Ruby 1.9

We installed 1.9 from source and put it in /opt/ruby-1.9 to avoid trying to upgrade the vendor ruby packages. We also used the --program-suffix=19 option so that all our binaries have names like ‘ruby19’ and ‘gem19’, this makes it a lot easier to tell which ruby you are running something under. It did mean adding /opt/ruby-1.9/bin/ to the PATH.

Most Rails commands work the way you would expect:

• rake19 gems to show Ruby 1.9’s view of the gems that your app needs
• ruby19 ./script/server to fire up a development server.

However script/console calls irb underneath, so it needs a special argument. Otherwise script/console will still be running under Ruby 1.8, which will be highly confusing.

• ruby19 ./script/console --irb=irb19

Because we installed Thin with gem19, it is automatically setup to use the Ruby 1.9 interpreter. To check, look at the first line of your thin script ( /opt/ruby-1.9/bin/thin in our case ). The first line should be #!/opt/ruby-1.9/bin/ruby19 and not #!/usr/bin/ruby or #!/bin/env ruby.