• 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.


  • Converting Mike’s Capistrano Cadillac into a Camero

    Mike Clark made a recent post on his blog about how to handle Rails versions with Capistrano. Very nice stuff. I’ve put his code samples to immediate use with an app I’m preparing to convert to Rails 1.2.1.

    I’ve run into some trouble this week, though, as I want to update one of my client projects that still runs version 1.1.6 of Rails. Mike’s Capistrano task takes a revision number so checking out a fresh copy with his script looks something like this.

    rake deploy_edge REVISION=5990 RAILS_PATH=/path/to/shared/rails
    

    This checks out 1.2.1 into the specified directory. After spending a few minutes trying to find the revision number for 1.1.6 (and chatting briefly with my Campfire peeps about the best way to proceed) I’ve decided that it’s safer to use tags instead of revisions. Deploys now look like this:

    rake deploy_edge TAG=rel_1-1-6 RAILS_PATH=/path/to/shared/rails
    

    Much more readable. The only downside, of course, is losing revision granularity. I’m essentially tied to the whim of the Core team as to when they decide to create new tags. But on the other hand, most of my projects aren’t currently running on Edge so this is suitable for my needs at the moment.

    I’ve included my rewrite of the task below. Just drop it in common.rake or wherever you prefer to put your custom tasks. Reading Mike’s post would be a good idea too since he explains how to get this working with a remotely deployed Rails application.

    (more…)

  • Montastically cool

    I have a web site I’ve been working on that tends to go down at odd times during the night. It’s an issue with the web host, and due to financial constraints my client is not willing to relocate the site anytime soon. So I’m stuck with having to log in and reset everything whenever the site goes down. It only happens once a month or so, but since the site receives a small amount of traffic it often takes several hours (sometimes several days) for anyone to inform me that it’s down. Enter Montastic.

    It’s rare that a free service comes along that is dead simple to use, works the first time (and every single time after that), and is ad-free. Montastic scores 110% on all counts. It’s a web-based monitoring service written in Rails that delivers notification via e-mail or RSS when a monitored site goes down.

    Montastic’s UI is very straightforward, some might say even elegant. Sign-up took a few seconds. Logging in, a few more. Adding my site was a breeze (it only asks for the URL, amazingly enough). I subscribed to my feed and was off and running.

    Montastic has already proven useful by alerting me to a server that went down just a few hours prior to writing this review. My sleep is that much easier knowing that Montastic is out there, ready to sound the alarm if my sites so much as twitch.

    Go ahead, try it out.

  • Dave’s EuroRailsConf keynote

    Dave Thomas’ keynote from last year’s EuroRailsConf is now online. It’s about 45 minutes long and well worth watching. Dave discusses terrorism, risk, and how it relates to Rails. This really scratched an itch for me because I’m in a work situation right now where I’m dealing with a great deal of risk. The funny thing about risk is that it’s something that can’t be fully avoided, yet many people delude themselves into thinking that it can.

  • Rails test results without the cruft

    Ever notice the cruft you get when running Rails tests from the command line? It’s horrible, especially if your project has more than a dozen test files:

    /opt/local/bin/ruby -Ilib:test "/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb"
    "test/unit/activity_test.rb" "test/unit/address_test.rb" "test/unit/application_helper_test.rb"
    "test/unit/course_calculations_test.rb" "test/unit/course_test.rb" "test/unit/course_type_test.rb"
    "test/unit/credit_hour_test.rb" "test/unit/email_test.rb" "test/unit/exam_test.rb" "test/unit/gender_test.rb"
    "test/unit/grade_test.rb" "test/unit/level_test.rb" "test/unit/notifier_test.rb" "test/unit/numeric_test.rb"
    "test/unit/obfuscator_test.rb" "test/unit/order_test.rb" "test/unit/school_test.rb" "test/unit/string_test.rb"
    "test/unit/student_test.rb" "test/unit/transcript_test.rb" "test/unit/user_test.rb" 
    Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader
    Started
    ..................................................................
    Finished in 2.509903 seconds.
    
    66 tests, 140 assertions, 0 failures, 0 errors
    

    M@ McCray recently posted a hack to the Terralien Campfire that gives you a nice, clean summary instead:

    Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader
    Started
    ..................................................................
    Finished in 2.855885 seconds.
    
    66 tests, 140 assertions, 0 failures, 0 errors
    

    Want to start enjoying this super slim summary yourself? Just stick this code in your project’s Rakefile right before the require 'tasks/rails' bit:

    Rake::TestTask.class_eval do
      alias_method :crufty_define, :define
      def define
        @verbose = false
        crufty_define
      end
    end
    

    Much better! We’re both surprised something like this isn’t already available in Core.