So after my post about Installing Rails in Production I was contacted several times with questions of why ruby 1.8 was better then 1.9. Usually I wouldn’t get into responding publicly, but I wanted to do so in this case because I think it’s important. A bit further down are instructions for installing Ruby 1.9 on a Ubuntu based server.

Why 1.8 over 1.9

First let me state that 1.9 has several improvements over 1.8 and for some of my clients those improvements are worth using 1.9. However I don’t feel that 1.9 is totally production ready for all my clients. For the most part, 1.8 is a much better and more supported choice.

First, 1.9.3 (and all the recent patch levels) have not made it into main stream repositories. Repositories are usually behind active development. So you can’t just “apt-get install ruby1.9” and get a functioning ruby install. You can with 1.8 though.

Second, 1.8 and 1.9 can’t be run on the same server without kludgy workarounds like revers proxying. So if you have two applications sharing the same server then you have to pick a specific version and use it to run everything.

Third, 1.9 doesn’t have as many gems that work with it as 1.8. Rails development (or ruby for that matter) depends heavily on gems to add new functionality without having HUGE costs. It’s code sharing and awesome, but 1.9 is newer and that means that fewer gems support 1.9. While this might not be a big deal for new projects it is on older projects.

Lastly, small differences between 1.8 and 1.9 means that you can’t just make your code work by upgrading it. So older projects that use, say rails 2.3, are now major upgrade projects. First you need to get rails up to date, then ruby, then the server. While this might be acceptable to some clients. Telling them that you need to charge large amounts of money to give them nothing that they can see, has always been, in my experience, a bad thing.

When to use 1.9

All that said 1.9 does have some nice features. It is worth using because you will have to upgrade eventually, and a bunch of other reasons. So if a project meats all the requirements below I use 1.9.

  • It’s a new project never in production.
  • It’s new code with gems that are 100% 1.9 ready
  • It’s going to sit on a server by it’s self or with other projects that use only 1.9
  • It’s not going to cost the client large sums of money just to do the update

Meeting these quick guidelines means the project is a good candidate for running under ruby 1.9. Thats not to say that at some point in the future that all websites won’t have to be eventually upgraded, but we are not there yet. New for the sake of new doesn’t offset the cost to the client. And in the end that’s what is most important. I would also like to point out that using these guidelines defaults most new projects to 1.9. Clients can also request that I upgrade their code to 1.9, and we can talk about cost. But I have never had a single client ask for it. In the end, the client just wants their site working, and making them money.

Finally Installing

So Installing ruby 1.9.3 is not all that hard but there are a few gotchas. First you need to have a sane build environment. On Debian based servers this is not installed by default, for good reason, but you will need it anyway for building gems with native code. Once that is done run the following commands.

This will install a recent version of libYAML, needed by ruby for writing YAML files. Ruby may work without it, but it give nasty warnings so just install it. Don’t depend on your system’s version, in my experience it won’t work.

sudo apt-get remove ruby
apt-get install libxslt-dev
cd ~
tar xzvf yaml-0.1.4.tar.gz
cd  yaml-0.1.4
/configure --prefix=/usr/local
sudo make install

Next you build and install ruby it’s self, pointing to your new version of libYAML.

cd ~
mkdir ruby_src
cd ruby_src
tar -xzf ruby-1.9.3-p194.tar.gz 
cd ruby-1.9.3-p194
./configure --prefix=/usr/local --enable-shared --disable-install-doc --with-opt-dir=/usr/local/libnou
sudo make install

Again you can see I didn’t install documentation, this is a personal preference. Production shouldn’t need it. if you need to look something up on production your doing something wrong in (in my opinion). Also of note you could have to change version numbers above to get the desired effect. Programming LLC. is about one thing. Getting your project done the way you like it. Using Agile development and management techniques, we are able to get even the most complex projects done in a short time frame and on a modest budget.

Feel free to contact me via any of the methods below. My normal hours are 10am to 10pm Eastern Standard Time. In case of emergency I am available 24/7.

Phone: (813) 421-4338
Skype: coteyr
Guru: Profile