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

Simple enough, right? A pretty common need. I thought it would be easy to find an example online that I could use. Turns out there are tons of examples, but few work! It took me awhile but I eventually cobbled together a useable config.

server {
  listen 80;
  server_name localhost;
  root /var/www/maintenance;

  error_page 503 /index.html;

  location /index.html {
    # show page
  }

  location / {
    return 503;
  }
}

Dead simple once you get it. Every incoming request is served index.html (the maintenance page) and receives a 503 status code. This works with Nginx 0.7.65.

Incoming search terms:

• nginx maintenance page
• nginx maintenance
• nginx down for maintenance
• nginx maintenance message
• maintenance page nginx
• nginx offline page
• maintenance nginx
• nginx maintenance config
• nginx maintainance page
• nginx get Status Code

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
• rails mailchimp tutorial
• mailchimp rails
• sendgrid mailchimp rails
• tracking emails sent through rails application using mailchimp
• sendgrid email template with mail api
• rails mail client
• sendgrid mailchimp

The bigger gotcha was with my server monitoring. I use god to monitor my web serving stack. That means god watches over MySQL. Ubuntu used to run the MySQL server with the tried and true /sbin/init which, when spawning the MySQL daemon, created a file /var/run/mysqld/mysqld.pid that contained the process id of the daemon. God relies upon that .pid file to detect whether or not the server is running. If the .pid file is missing, or the PID in the file doesn’t match the id in the process list that god knows about, it thinks the server is down and will start yelling at you via whatever notifications you have configured. Recent versions of Ubuntu use upstart to control the MySQL server. Upstart doesn’t create the .pid files that god needs for monitoring. That put a glitch in my setup.

I began searching for answers in god’s documentation and discovered that you can watch non-daemon processes (i.e. those that don’t create a .pid file) with god. To do so just don’t specify a pid_file in your god watch. In that case god will create  pid for you in /var/run/god and use it for monitoring. Simple enough, but no dice. For whatever reason that didn’t work for me. God would create /var/run/god/mysql.pid but still complain that the server is down. More searching led me to a Flowcoder post that provides a way to create a .pid file from an upstart script for server monitoring. The post is for a couchdb-lucene server, but the code was easily adapted for MySQL. I made it work by editing /etc/init/mysql.conf. Here are the important parts:

post-start script
    # Make a .pid file for god monitoring of MySQL
    PID=`status mysql |egrep -oi '([0-9]+)$' |head -n1`
    echo $PID > /var/run/mysqld/mysqld.pid
    ....
end script
 
post-stop script
   # Remove the .pid file used for god monitoring of MySQL
   rm -f /var/run/mysqld/mysqld.pid
end script

Voila! Now I can control the MySQL server via /usr/sbin/service and it will create and clean up /var/run/mysqld/mysqld.pid for me. Most important, god gets its .pid file and monitors happily. That’s all good, but I don’t like the fact that I had to edit a /etc/init file to do this. Anyone got a better solution?

Mighty Nice proudly serves its web content using Linux and other open source technologies

Incoming search terms:

• upstart pid file
• god upstart
• ubuntu mysql pid
• upstart pid
• ubuntu mysql pid file
• upstart god
• upstart pidfile
• upstart pid files
• ubuntu mysqld pid
• mysql pid ubuntu

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
• command line ruby hack
• how to use command prompt to hack
• lessons of how to use command prompt to hack
• nice lessons
• nite vites re
• owd hacknight blog
• ruby varargs hash

Recently more than one web developing friend told me that they had switched from Firefox to Google Chrome for their everyday browsing and work needs. That’s saying a lot because Firefox has some great development add-ons, and because web devs know their browsers. I was curious, and since I was recently into analyzing my browser, I thought I’d give Chrome on OS X a shot.

Google Chrome is the result of the open source project Chromium. It’s the first multi-threaded browser and, being the new kid on the browser block, it has been able to capitalize on the experience of its competition. That last point shows in the Chrome’s slick interface and usability. Here is what I noticed shortly after install:

• It starts fast. Click the Chrome icon and boom, it opens.
• It renders fast. Pages come up lightning quick just like in Safari and other webkit browsers.
• The “new tab” page nicely lays out your bookmarks toolbar, thumbnails of recently browsed locations, a list of recently closed tabs, and easy access to full history.
• Address bar is also your search bar. This is similar to Firefox’s “Awesome Bar” but instead gives you search results.
• New tabs tear out AND can be pushed back in.
• Downloads, plugins, and history are easily managed through pages rendered in the browser. This just makes sense.
• “View source” opens in a new tab and has line numbers.
• Same webkit development tools that you find in Safari.
• Nice task manager for viewing Chrome’s, and other browsers’, memory usage
• Each tab runs in its own thread. When you close a tab the thread dies and its resources are freed up. If a page in a tab misbehaves the tab may die but the whole browser won’t crash.

Because of Chrome’s multi-threaded nature it is difficult to get an accurate measurement of how much RAM the whole browser is really using. However, casual profiling using OS X’s Activity Monitor, and Chrome’s monitoring tools (In Chrome: View -> Developer -> Task Manager -> Stats for nerds), suggests to me that Chrome uses about the same amount of RAM as a tweaked-out Firefox (300-350MB). Maybe a little more. And that’s with just a few tabs of plain ol’ web pages open. No Flash and no audio streaming. Throw either of those in the mix, and/or open a lot (10+) tabs, and memory usage spikes fast leading to poor performance.

So there are some memory issues with Chrome. Under light usage it acts mature and stable, but once you pile on tasks the browser loses its footing. Since I run a lot of big apps simultaneously everyday, a browser always one of them, memory is precious to me. Those issues alone are enough to keep me away from using Chrome full-time. Other no-go factors include the not so-smooth-transition from page to page and the fact that Chrome still has a small user base. As a web developer I need to build my sites in a browser that most people use, and on a Mac that means Firefox.

Chrome usage is rising fast. In time I’m sure all if its current downsides will disappear. Google will fix its memory problems and page transitions because users will complain of side-effects. Average users will adopt Chrome and web devs will become comfortable using it full-time. Until that happens, however, Chrome will be just one more browser that I need to test our sites with.

Incoming search terms:

• google chrome icon
• chrome icon
• chrome
• chrome icon jpg
• chrome page transitions
• google crome multithread
• chrome google icon
• icon google chrome
• icon chrome
• mightychrome google

Searching for a fix led me to a post titled Optimize Firefox’s memory usage by tweaking session preferences. I followed the author’s suggestions point by point and then rebooted my box to get a clean slate. After monitoring Firefox’s memory usage for a few days I was thrilled to see that it consistently only consumed 300-350MB of RAM. That’s a huge performance boost for a few simple tweaks.

Too bad those options are hidden in ‘about:config’. Hey Firefox devs, how about some performance options in the preferences pane?

Incoming search terms:

• fixing firefox