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

What’s the asset pipeline?

In a nutshell, the asset pipeline brings production-release processing of JavaScript, CSS stylesheets, and images to the Rails core. With the help of the Uglifier and Sprockets gems JS & CSS are stripped of white space and comments, variable name simplified, and stitched together into one big download (one for JS, one for CSS). Asset files are named with a MD5 hash of the file to ensure that returning browsers download any new asset change.

Benefits of using the asset pipeline

So why do you want this feature? Because it optimizes your web app’s front end for delivering a rich client-side experience. By stripping away unnecessary bytes your assets become smaller and take less time to download. By concatenating all JavaScript in one big file and all CSS in another the browser only has two downloads to worry about and not many (same reason we use image sprites). By naming files with a hash of their data file names are sure to change whenever the data changes, forcing revisiting browsers to download the change and not rely on an out-of-date cache.

Working with the asset pipeline

I’m not going to get into how to enable the asset pipeline on a Rails 3.1 app. There is a good Rails Guide to help with that. Instead I want to talk about an issue that I ran into but couldn’t find documented anywhere: once I had the asset pipeline properly enabled my site looked, and behaved, like crap. Why? Because I liked to break my assets into multiple files. I actually had a home grown system that auto-included assets whose filenames were based on the name of the controller and action that served a request. This led to many asset files, each tailored to a specific page, and each included only on the page they were meant for. That common, “old school” approach did not work well out of the box with the new pipeline. Moving all existing assets into the app/assets directory and letting Sprockets compile them made all hell break loose because the result is that every page included all known JS & CSS. There was no more page scoping. CSS cascades were ruined, and JS meant for one page reacted on different pages because the DOM was similar. The result was a total friggin’ mess that I had to resolve without rewriting all my assets.

Scoping CSS for inclusion on the asset pipeline

Carefully crafted, browser tested CSS was by far my biggest concern. There was no way I was going to lose the hours that went into making it work. Luckily a new addition to the Rails 3.1 core helped tremendously: SASS a.k.a. syntactically awesome stylesheets. The name says it all. SASS is everything us old time web devs have wanted CSS to be but that the W3C drags its feet on. For my task the biggest win provided by SASS was nested rules. That let me turn CSS that looked like this:

1
2
3
4
5

   .featured {
      float: left;
      margin-left: -5.75em;              
      padding: 2em .75em 0 .75em;      
   }

into this:

1
2
3
4
5
6
7
8
9

   body.home {
      &.index {
         .featured {
            float: left;
            margin-left: -5.75em;              
            padding: 2em .75em 0 .75em;      
         }
      }
   }

Remember, I was including my asset files based on the name of the controller and action that served a request. The asset pipeline made that impossible because all CSS is in one file. My solution was to continue scoping by controller and action name by including those names in the body element’s class attribute. I then used SASS’ nested rules to wrap existing CSS in the new body classes. The result is what you see above — page scoped CSS that plays well in a single file.

Scoping JavaScript for inclusion on the asset pipeline

Once I figured out how to handle my CSS, JavaScript was a cinch. I could use the same strategy with jQuery. So JS that looked like:

    $('input[type=submit]:first').effect('pulsate', { times: 1 }, 1000);

Was turned into this:

1
2
3
4
5

   if($('body').hasClass('rsvps')) {
        if($('body').hasClass('update_notes'))
            $('input[type=submit]:first').effect('pulsate', { times: 1 }, 1000);
        ....
   }

Again, page scoped JavaScript that plays well in a single file. Moving forward I could use the same strategy with the JavaScript equivalent of SASS, CoffeScript, which was also brought into the Rails core with 3.1.

Was it worth it?

The upgrade to Rails 3.1.3 with full asset pipeline integration did take some time. An asset upgrade strategy needed to be figured out, changes needed to be made, and significant browser testing needed to be done. By the time I finished I was skeptical that the effort was worth it, but once I released to production I was pleasantly surprised to see that it was. Pages loaded significantly faster than they used to. I was using minification before the upgrade, but the Sprockets concatenation gave a big boost. I could actually feel the difference. Best of all I now have a nice stage set for building out mightyvites.com with heavy dependence on client-side processing.

Incoming search terms:

• path to asset pipeline images
• ruby on rails asset pipeline
• asset pipeline upgrade
• asset pipeline
• ruby assets with hash names
• ruby asset pipeline sub web
• rails3 qrcode
• rails scoping css
• rails pipeline ensure loaded only once
• rails migrate to asset pipeline

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

Recently the time came for me to spruce up the emails mightyvites.com sends. I wanted slick-looking HTML that looks good in all email clients, makes it to users’ inboxes, is multipart, and can be tracked. In addition the email templates should be easy for non-geeks to edit. That way they can be changed often and not always by me.

I’m a fan of MailChimp. We use their (robust) API to programmatically manage our newsletter subscriber list. They make it very easy to compose, send, and track well-designed HTML email. They do not, however, make it easy to send transactional email. That’s not their niche so they don’t cater to it ¹. There is a work around, but it leaves much to be desired. MailChimp transactional emails must include unsubscribe links and other CAN-SPAM compliance content which is just out of place on notices like forgotten password emails. The MailChimp email composer, however, is pretty sweet. It’s easy to use and generates cross-client compatible HTML email complete with text versions for multi-part. The composer was perfect for my needs, but sending through MailChimp was no good because doing so automatically adds the unwanted mailing list links. Then it hit me: if I could compose and save my emails in MailChimp and later export them I could include the export in my Rails app and send through the email provider of my choice. Possible? With hominid, the MailChimp API Ruby gem, yes.

Hominid wraps the well documented MailChimp API for use in Ruby applications. It adds the syntactic sugar most Rubyists would expect and pretty much does a 1 to 1 mapping of the methods MailChimp defines. Part of the API deals with what MailChimp calls templates. Templates are reusable emails that you create at mailchimp.com and save to your account. You can access these HTML templates through the API and run them through a method to generate a text version. With both a HTML and text version “in hand” you can write the output to disk and have what you need for ActionMailer to generate fancy, multi-part emails that were edited online with MailChimp’s slick editor. I keep all this action in a Rake task which I run every time I update a template at MailChimp.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

  desc "Task to pull customer email templates from MailChimp and cache them in the app"
  task :import_email_templates => :environment do
    # Maintain a map of ActionMailer methods to MailChimp
    # template names in a YAML file. YAML looks like:
    # <mailer class name>:
    #   <mailer method name>: <name of MailChimp template used by method>
    # Example:
    # user_mailer:
    #   signed_up: "Welcome To Mightyvites"
    #   ...
    map=YAML.load_file(MAILER_TEMPLATE_YAML)
    api=Hominid::API.new(MAILCHIMP_API_KEY)
 
    # loop through the list of known MailChimp template names
    api.templates['user'].each do |template|
      html_cache=nil
 
      # find the mailer class and method this template belongs to
      map.each do |mailer, emails|
        template_name=emails.invert[template['name']]
 
        if template_name
          html_cache=File.join(Rails.application.config.view_path, mailer.to_s, "#{template_name}.html.erb")
          break
        end
      end
 
      next unless File.exist?(html_cache)
 
      # pull the latest HTML templates from MailChimp
      html=api.template_info(template['id'].to_i)['source']
 
      # create a text version of the HTML for multi-part mail
      text=api.generate_text('html', html)
 
      # inline all CSS to ensure greatest email client compatibility
      html=api.inline_css(html)
 
      # overwrite mailer views
      File.open(html_cache, 'w+') {|f| f << html }
      text_cache=html_cache.gsub('.html.erb', '.text.erb')
      File.open(text_cache, 'w+') {|f| f << text }
    end
  end

With that code I can easily update my application’s mail templates and manage them at MailChimp. My templates don’t change often so I keep the update manual, but you could set up a cron job to pull in changes nightly, or create a Capistrano task to pull in a fresh copy with each application deployment.

So what about tracking? That was the last wish on my list and was easily gotten with a nifty SMTP service called SendGrid. Goodbye Gmail! SendGrid works extra hard to give my application a high email delivery rate and it provides a nice web interface for viewing all email sends, clicks, bounces, etc. SendGrid’s tracking isn’t as slick as MailChimp’s, but it’s a heck of a lot better than nothing. Overall I’ve been very pleased with SendGrid’s service, and happy as a clam with my MailChimp’d ActionMailer templates.

Incoming search terms:

• sendgrid templates
• sendgrid email templates
• rails transactional email
• sendgrid mailchimp rails
• rails mailchimp tutorial
• mailchimp rails
• sendgrid mailchimp
• mailchimp transactional emails
• sendgrid email template with mail api
• rails mail client

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

Hurdles:

• I need a reliable way to serialize the data so I can store it as a string in the cookie
• When I retrieve the cookie I need to deserialize the data and get it into an ActiveRecord object for form display

This is easily done with Rails using JSON because

1. Cookie management in Rails is dead simple
2. Rails extends Ruby’s Object class to include a #to_json method
3. ActiveSupport provides easy JSON deserialization

Saving the POST in a cookie as JSON

1
2
3
4
5
6

cookies[:last_order]={
  :expires => 1.year.from_now,
  :value => params.to_json(
    :except => [ 'commit', 'authenticity_token', 'action', 'controller' ]
  )
}

When a request comes in I store the user’s order settings in a cookie named ‘last_order’. The cookie expires in 1 year. The value of the cookie is everything returned by #params, minus the stuff I don’t need, in JSON format. The :except filter given to #to_json ensures that I only save what is necessary for recalling the order and nothing more.

Deserializing the cookie into an ActiveRecord

1
2
3
4
5
6
7
8
9
10

def find_order
  serialized=cookies[:last_order]
  return if serialized.blank?
 
  last_order=ActiveSupport::JSON.decode(serialized)
  return if last_order.blank?
 
  @order=Order.new
  @order.attributes=last_order
end

The method checks the request cookies for ‘last_order’. If found we use ActiveSupport::JSON#decode to deserialize the previous POST into a Hash object. If deserialization is successful, instantiate a new ActiveRecord and set its attributes to the parameters retrieved from the cookie. The @order variable is then used in the view with form_for to populate the form with the user’s last selections.

Wrap Up

This works well, and I actually got it working on the first try. I like the solution because JSON is a light-weight serialization format. You could do the same thing using XML or YAML since Rails provides support for the former and Ruby support for the latter, but the output of both was more verbose than what I needed. Since I’m storing in a cookie space is a concern.

This example is based on Rails 2.2.2. The current Rails API seems to be different, so your calls may vary, but the idea stays the same.

You’ll likely want to inspect your cookie. A good way to do that is with Firebug.

Incoming search terms:

• rails json cookie
• rails json cookies
• activerecord store json
• rails json session
• rails cookie json
• mighty nice blog
• json cookie
• rails session json
• json cookie rails
• store json activerecord