I’m experiencing a time travel back to 2006. That was when I wrote my very first Ruby on Rails application and this week I had to take it out of the archives and make it run again. I run into a few entertaining hurdles and had to perform some tricks that might be useful to know.
I think it started as a Rails 1.x application and it was upgraded until 2.3.2. I had to upgrade it to 2.3.18 now because of the vulnerabilities discovered among the years.
The application is so old that it didn’t have a Gemfile. Creating one is simple (only 7 gems, the ecosystem was tiny at the time) but the versions of the gems must be picked with care. It runs with nothing newer that rake 0.8.7, rubygems 1.6.2 and Ruby 1.8.7. Follow this tutorial to adapt the application to bundler or you’ll run into troubles in production mode (methods not found, etc).
To install ruby-18.7-p371 I had to specify the rubygem version with rvm install ruby-1.8.7-p371 –rubygems 1.6.2 or run into “There was an error while trying to resolve rubygems version for ‘latest'”.
Thanks to the pg gem it keeps working with PostgreSQL 9.2 (it started with 8.1) but I was using some stored procedures more for fun that for real need (but they were definitely faster than AR). I was accessing the recordset data with connection.exec(query).result. That doesn’t work anymore. Sometimes in the last years the result method has been replaced by values.
I was using gettext to handle internationalization because Rails didn’t have an internal i18n framework at the time. By the way, I think that gettext is still a better and higher level framework than what we have now, especially because it can parse Ruby sources, collect the new translations and add them to the translation files marking them as untranslated. Anyway, all the world uses I18n, it’s pointless to mix the two of them and gettext was abandoned. But the latest version of the gem is not compatible with Rails 2.3.5+. Big problem with 600+ translations to handle. Luckily there is a commit that fixes that.
gem “locale_rails”, :git => “git://github.com/mutoh/locale_rails.git”, :ref => “13a096f20b”
The application ran on a mongrel_cluster behind an apache reverse proxy. bundle install looks for mongrel 1.1.6 which can’t be found anywhere on the Internet but version 1.1.5 works and is on github. However with mongrel_cluster I’m having some wierd problems in the inner working of my application. Running mongrel without the cluster works fine, so I ended up starting the individual mongrel processes manually. That’s good enough until I investigate the issue and try to move the application to passenger. Should I port it to Rails 3.2? We’ll see what happens but did I mention that the JavaScript front end (some 3000 lines) is based on dojo.js and it’s pub/sub infrastructure? It’s a steep cliff to climb.
The application deals with timezones using the tzinfo gem but apparently the timezone names generated by Rails are no more what tzinfo expects. As an example, Rails’s select helper generates “London” as a value but tzinfo wants “Europe/London”. I had to implement my own helper along the lines of TZInfo::Timezone.all.map{|tz|”<options value=\”#{tz.identifier}\”>#{tz.to_s}</options>”} Actually it’s much more complicated because I also wanted to display the offset from UTC and sort by it. Maybe I’ll add a gist. I didn’t investigate the helper issue but this should apply to Rails 3.2 as well because I used the latest version of tzinfo. By the way, TZInfo doesn’t the some possibly embarrassing glitches of ActiveSupport::TimeZone, which among the others places Edinburgh into the Europe/Dublin timezone (a different country) or Bern into Europe/Berlin (again, why not Europe/Bern?). It has no Edinburgh and Bern at all but sometimes less is better. Working with timezones is always a messy business.
Eventually it runs.
A few random notes:
It still uses .rhtml files. I forgot they existed. Did you?
It was originally versioned with CVS, not even subversion, but mercifully I moved it to git years ago and forgot I did. It was a nice surprise.
This is Rails 2.3 so you manage the application with ruby script/server and ruby script/console, rails s didn’t do what I’m used to now.
Last but not least it starts up much quickly than the Rails 3.2 applications I’m working on, probably thanks to the small number of gems it uses.
Il connettivo 