UPDATE: Since moving to 3.2.3 I’ve upgraded the site to 3.2.6. The minor update was to address the recent security exploits found in Rails. It was a simple change in gem versions to make this upgrade work.

Incoming search terms:

• wedding rsvp via email wording
• how to word rsvp on wedding invitations
• wedding png
• 1 mightyvites
• rails invitations
• rails3 rescue_action_in_public
• powered by ruby on rails 3
• rsvp plus one wedding
• rsvp wedding cards with email
• ruby

No, it didn’t take me a year to do the upgrade. Shortly after I wrote that post I took a full time Rails job. Then my business got busy with paying customers. Then I got engaged and a few months later married. There were a lot of distractions which kept throwing me off my Ruby On Rails upgrade plans. I did do it though. In fact I completed two Rails upgrades this summer. One for mightyvites.com and one for my employer. In both cases I transitioned webapps from Rails 2.x to Rails 3.0.10 and introduced Ruby 1.9.2. Doing so was definitely worth it. Rails 3 feels so much more mature than previous releases. The upgrade, however, was not easy. Below are the issues I had to deal with to make it happen.

Changes in Rails

• The Rails.root/lib directory must be autoloaded
• My use of JRails could be dropped due to the new UJS approach of JavaScript handling
• #fields_for and #form_for require <%= ERB blocks
• @controller was deprecated for #controller
• ApplicationController#filter_parameter_logging is now config.filter_parameters in application.rb
• Must mark application HTML as html_safe due to XSS protection being the default
• No more CGI::Session::CookieStore::TamperedWithCookie (because of signed cookies?)
• #rescue_action_in_public usage changed to #rescue_from (really a Rails 2.3 change)
• Awful “You have a model in a subdirectory, where the name of the subdirectory matches the name of the model.” problem (succinct explanation (point 4), technical explanation)
• Terrible “incompatible encoding regexp match (UTF-8 regexp with ASCII-8BIT string) (Encoding::CompatibilityError)” problem caused by rendering XLS file with render :file =>. Fixed by using #send_file
• ActiveRecord attributes with errors are displayed in a form_for with CSS class ‘field_with_errors’ as opposed to the preveious ‘fieldWithErrors’
• Had to uncomment the Nginx version of config.action_dispatch.x_sendfile_header in production.rb

Changes in Ruby gems

• will_paginate needs 3.0.pre2
• mysql2 needs 0.2.11
• had to encode DB to UTF8. Apparently mysql gem would change encoding to UTF8 while mysql2 gem does not?
• hominid needs 2.1.9
• rmagick required building ImageMagick via MacPorts w/o openmp support (CaptainPete’s explanation)

Changes in Ruby

• Array#choice now #sample
• YAML lib changes to Psych; can no longer handle ypaths with #select
• Drop use of FasterCSV because it is now the native CSV

I would say the average time it took for me to do each upgrade was 3 weeks. A full test suite was invaluable in tracking the state of the upgrade, and after launch I inevitably found bits of un-html_safe’d output. I released the Rails 3 upgrade of mightyvites.com in September of ’11. Since then I’ve upgraded the site to Rails 3.1 and instituted the new asset pipeline. Hopefully I’ll write about that sooner rather than later.

Incoming search terms:

• rails 3 rescue_action_in_public
• rescue_action_in_public rails 3
• upgrade to rails 3 0 10
• update to rails 3 0 10
• rails 3 0 10 changes
• upgrade rails 2 to 3
• send_data rails 3 0 10
• rails rescue_action_in_public
• ruby 3 0 10
• rescue_action_in_public rails3

I’ve been working with Ruby On Rails 2.2.2 and Ruby 1.8.7 for a little over a year now. The Mightyvites site is built on that foundation, as is the Mighty Nice site, and a few of our client sites. However, with the release of Rails 3, and it’s compatibility with Ruby 1.9.2, I’m itching to upgrade both. There are a few reasons why I want to upgrade the cores of our RoR sites:

• I don’t like to fall behind in upgrades. If you skip too many stable releases of a critical software package you’ll run into big headaches when you do decide to upgrade.
• It’s a good excuse to upgrade everything our sites run on: gems, plugins, JavaScript libraries, etc. Just do a full upgrade release and get it over with.
• I want core support of Rails Engines. Currently I use Rails Engines as a plugin. The less plugins to manage the better.
• I want to drop use of the Jrails plugin and harness unobtrusive JavaScript
• I want the bug fixes and performance improvements. I have no complaints with Ruby/Rails performance, but I would like to use the new Ruby interpreter which is supposedly 15% faster than the old (but slower than the previous interpreter with ActiveRecord? Yikes!).
• Rails routes have a new sugary syntax (er. DSL) which will help clean up my routes.rb files.
• Ruby has some cool new features

That’s more than enough reasons to upgrade, and thankfully I’ve got the time to do it now. In preparation I’ve cut a new development branch and I’ve talked to some fellow Chicago Rubyists to get their take on the upgrade process. One fella I met at last month’s software craftsman meetup pointed me to the rails_upgrade plugin, which I’ve already tried out and am impressed with. The plugin takes the pain out of the upgrade guess process by running through your code and printing out all you need to change and why. That’s super handy, and should help cut down significantly on the brute force break/fix upgrade cycle. There is also a good lookin’ PDF written on the upgrade process.

One thing to note: a few people have told me that moving to Rails 3 isn’t bad, but moving to Ruby 1.9 is not as easy. The reason being that many gems and plugins aren’t yet compatible. I’m going to give the move to Ruby 1.9 a try, but we’ll see how far I get.

Incoming search terms:

• rails 3 slower than rails 2
• Mighty Rails
• rails 3 ruby 1 9 performance
• rails3 ruby 1 9 performance
• rails3 slower
• rails3 slower than rails2
• ruby 1 9 2 performance
• invitation plugin in ruby on rails 3
• ruby on rails 3
• upgrade rails 3 to 1 9 2

• Varargs can now appear anywhere in a method definition
• Block parameters are now like method parameters: they can have default args and varargs
• Since symbols-as-keys hashes are so common in Ruby there is now a concise way of writing it. { :a => 1, :b => 2} can now just be { a: 1, b: 2 } (hash literals).
• Hashes now retain creation order. I’m mixed on this. A classic hash algorithm won’t maintain order for the sake of speed. If you want order, use an array. I feel like Ruby is blurring the lines here, much like it does with the distinction between arrays and linked lists in the Array class. However, hashes are used so frequently in Ruby that this is a welcomed feature.
• The Fiber library introduces a lighter-than-light-weight-threads way of doing concurrency. Granted you have to schedule the concurrency yourself, so you better know what you’re doing, but in simple cases this can be an improvement over firing off Threads.
• The CSV library is now FasterCSV. I currently use FasterCSV as a gem. The less gems I have to worry about the better.

Cool stuff, and I’m excited to use it in production. Now I just need to upgrade!

By the way, since I haven’t upgraded my system Ruby yet I played with 1.9 via the Ruby Version Manager (RVM), an easy to use command line tool that allows you to keep different versions of Ruby on your box and switch between them with ease. It works great!

Mighty Nice Mightyvites are proudly powered by Ruby and Ruby On Rails

Incoming search terms:

• chicago ruby hack night
• night vites
• owd hacknight blog
• nite vites re
• nice lessons
• lessons of how to use command prompt to hack
• how to use command prompt to hack
• hack lessons website
• command line ruby hack
• ruby varargs hash