Matthew Bass

  • CORS woes on Heroku

    ,

    After spending the past 4 hours attempting to solve what boiled down to a rather simple problem, I figure I’d better blog about it to save someone else the time and effort.

    If you’ve been leveraging Passenger’s new –nginx-config-template command line option to add CORS headers to static assets served from a Rails app hosted on Heroku, and the CORS headers recently disappeared under mysterious circumstances… read on.

    I’ve been using the method described here to add CORS headers to custom fonts served from a Heroku-hosted Rails app that’s proxied by Nginx which handles serving static files. I recently updated to Rails 4.2.2 and suddenly, my custom fonts (.woff and .woff2 files) no longer had CORS headers on them.

    After the aforementioned hours spent scratching my head, I discovered that the latest version of the sprockets gem is generating asset digests that are 64 chars in length, where previously they had been 32. Nginx’s default regexp for identifying requests for static assets assumes the digest will be 32 chars long, like so:

    # Rails asset pipeline support.
location ~ "^/assets/.+-[0-9a-f]{32}\..+" {
  error_page 490 = @static_asset;
  error_page 491 = @dynamic_request;
  recursive_error_pages on;</code>

  if (-f $request_filename) {
    return 490;
  }
  if (!-f $request_filename) {
    return 491;
  }
}

    Changing the regexp to recognize digests that are 64 chars in length immediately solved the problem:

    location ~ "^/assets/.+-[0-9a-f]{64}\..+" {
   ...
}

    I had to laugh after something so stupid and silly cost me a good chunk of my Saturday to debug. But at least it’s working now. My statically served custom fonts have the correct CORS headers and Chrome and Firefox are happy again.

Need help?

I’m an independent software developer available for consulting, contract work, or training. Contact me if you’re interested.

  • Creating service apps with Rails at tonight’s Ruby meetup

    , ,

    ·

    This is another brief reminder that I’ll be giving a preview of my RailsConf talk at tonight’s Ruby meetup. The meetup starts at 7 PM at Red Hat headquarters. Hope to see you there!

  • Preview my RailsConf talk at this month’s Ruby meetup

    , ,

    ·

    For those who live in the RTP area, I’ll be giving a preview of my RailsConf talk at the Raleigh-area Ruby Brigade meetup on April 17th. We meet at Red Hat headquarters on NCSU’s Centennial Campus at 7:00 PM. I’ll be talking about Teascript, homesteading, and building niche web apps that generate passive income. The talk is pretty solid, but I’ll still be asking for feedback from the group on what can be added or improved. See you there!

  • Turn finders into associations and get caching for free

    ,

    ·

    Let’s say we have a method on a model that looks something like this:

    def last_assignment
  assignments.find(:first, : order => 'created_at DESC')
end

    We call this method several dozen times from various other methods on the model. The problem is, every time we call the method a new database query is triggered. This happens even if we make multiple calls within the same method. For example:

    def last_assignment_is_old?
  last_assignment && last_assignment.completed_at && last_assignment.completed_at < 30.days.ago
end

    This results in three identical queries to the database. How wasteful! Let's fix it:

    def last_assignment
  @last_assignment ||= assignments.find(:first, : order => "created_at DESC")
end

    Ahhhh, this is much better. Now we're storing the result as an instance variable on the model. Our last_assignment_is_old? method will only trigger a single call to the database now since we're caching the result. But what happens if we do something like this?

    puts model.last_assignment.nil?
model.assignments.clear
puts model.last_assignment.nil?

    On the console, we should see false and then true, right? What we actually see is false and false. Even though we clear out the assignments from the model, the last assignment is still stored in the @last_assignment instance variable. Since we're dealing with the same instance of the model, the cached value is returned. In this particular case, that's not good!

    The way to get around this is by using an association:

    has_one :last_assignment, :class_name => "Assignment", : order => "created_at DESC"

    This association basically says, "Sort the assignments by the creation date and give me the first one in the list." After running our test code again, we're golden. It turns out that Rails' associations provide caching automatically. All we have to do is remember to call reload on our model before querying it again. This will ensure that we're working with fresh data:

    puts model.last_assignment.nil?
model.assignments.clear
puts model.reload.last_assignment.nil?

    Now we get false and then true as expected. The reload trick won't work with instance variable caching, unfortunately, which is why the association is a better choice in this case.

    After examining a few more of our models, we discover that there are many such finder methods that can be converted to associations. We quickly begin converting them, hoping nobody notices that we've been senselessly operating without freebie caching for so long.

  • Multiparameter assignment validation

    ·

    Have you ever realized that the default Rails date helpers allow invalid dates to be selected? I ran into an issue yesterday where one of my Teascript users attempted to select a date of November 31, 2007. That date obviously doesn’t exist. Instead of failing with a validation error, however, Rails threw a MultiparameterAssignmentErrors exception.

    This is the first time I’ve run into this particular problem in Rails, and I’ve been using the framework for over two years now. Suffice it to say the odds of running into it are slim, but how should it be handled once it occurs? I found a clean, if not particularly elegant, solution in the Validates Multiparameter Assignments plugin. Once the plugin is installed, adding a single line to your model is all that’s required:

    class User < ActiveRecord::Base
  validates_multiparameter_assignments
end

    The plugin causes any multiparameter assignment exceptions to be surfaced as validation errors, which is exactly what I needed to happen. Why don't I think it's elegant? Simply because it takes the shotgun approach by assuming that I want to validate all multiparameter attributes. I'd prefer to specify which attributes I want validated. This is a minor nit, though. The plugin does work quite well.

    There is one other customization that can be made to the plugin, but I've got to leave some surprises for you so check out the wiki page to familiarize yourself with the plugin. If you don't need the plugin now, I can pretty much guarantee you'll need it eventually.

    Update: This plugin is unnecessary as of Rails 2.0.2 because invalid dates are now gracefully offset to the next valid day without causing a validation error.