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.

  • Show database migration versions with Rake

    ,

    ·

    Something I frequently need to do when deploying a Rails application is determine the current migration version of a database. In the past, I’ve done this by bringing up mySQL and typing:

    SELECT version FROM schema_info

    Well, I’m finally tired of doing that so I cooked up this Rake task:

    namespace :db do
  desc "Print current database migration version to the console"
  task :version => :environment do
    puts "VERSION=#{ActiveRecord::Migrator.current_version}"
  end
end

    To install, copy and paste into lib/tasks/common.rake (or wherever you store your custom Rake tasks). Then fire up a terminal window and feel the power:

    $ rake db:version
(in /Users/matt/project)
VERSION=125

    I’m surprised this isn’t already in Rails. Sure, there’s script/about, but I always forget to use it. It also spits out other information I don’t typically need to know.

    Why care about the migration version in the first place? When you’re on a project with multiple Rails deployments (dev/test/prod) and multiple developers creating migrations in multiple branches, it comes in quite handy.

  • Teascript goes live

    , ,

    ·

    TeascriptI’m proud to announce that Teascript went live early last week. It’s been a long several months since originally conceiving the idea, building the app, beta testing, and deploying but now it’s finally ready for prime time.

    Teascript is a Rails application that makes it easy to design and build professional high school transcripts. It’s mainly targeted towards home school parents and students, however, I’ve received interest from several public and private schools who are looking for a transcript generation package they can install locally so the potential for this product seems huge.

    For those interested in how Teascript was deployed, the application runs on Apache 2.2 with mod_proxy_balancer and a cluster of Mongrels. I’m using a VPS provided by Slicehost. This setup has been rock solid so far.

    My talk at RailsConf this year will focus on the development of Teascript: how the target niche was chosen, how the application was marketed, and so on. My goal is to demonstrate how the principles outlined in 37 Signals’ book Getting Real and the homesteading concepts put forth by Nathaniel Talbott at last year’s RailsConf were combined to produce a web product that is self-maintaining, sustainable, and capable of generating passive income.

    So please, check out Teascript and let me know what you think.

  • Mind blowing Ruby

    , ,

    ·

    I’ve been writing Ruby code for over four years now. I’ve been getting paid to do so for about two years. Prior to that, the bacon I brought home came mainly through the careful crafting of lines of Java, PHP, and C# code. Matz spoiled the party for me in the mid-90s, however, by releasing such a wonderfully beautiful language that it made Java tedious and uninteresting in comparison.

    Ruby is a fantastic tool. But it’s not just a tool, it’s also an art medium. I had never truly seen beautiful code until I met Ruby. All that being said, when I was first introduced to the language it was a lot like trying to breathe while standing under Niagara Falls. The “wow-that’s-cool-but-I-don’t-quite-grok-it” moments came fast and furious. Ruby was blowing my mind on a daily basis.

    It doesn’t anymore. At least, not every day. But at least once a month, I see a code snippet or read a blog post or hear about a new way to do something and… well, there goes my mind again. For example…

    (more…)

  • RailsConf registration is open

    , ,

    ·

    RailsConf registration is open. Time to scramble! From what I understand one-third of the seats are already taken. I’ll be speaking at the conference this year. Should be more fun than a barrel of monkeys. See you there.