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.

  • Port of the Ocadia theme to Mephisto

    ,

    ·

    Ocadia PreviewI began poking around the intriguing Rails-based Mephisto blogging engine this weekend. While the app itself looks quite promising, there is a noticeable absence of themes for it. I’m sure this will change, but in the meantime I thought I’d make my own contribution. The particular blog I’m converting originally ran on Becca Wei’s excellent Ocadia theme for WordPress so I went ahead and ported it to Mephisto. If you’re interested in using it on your own blog, download a copy and check out the README for installation instructions. Enjoy!

    Update: Ocadia now has a home on GitHub. This means you now have the ability to check out the source code like this:

    git clone git://github.com/pelargir/ocadia_mephisto.git

  • Don’t leave empty test fixtures in your Rails projects

    ·

    A friendly word of advice: don’t leave empty test fixtures in your Rails projects. In some situations, it can cause unexpected test failures that are quite nasty to track down.

  • Bad Bailey

    ·

    This is something funny that I think you might enjoy. My brother David and I had some spare time over Christmas to do something we’ve wanted to do ever since we saw Scary Mary on YouTube: edit together a horror trailer for Frank Capra’s classic film It’s a Wonderful Life. This is what we came up with. Enjoy.

  • Introduction to rcov, code coverage for Ruby

    , ,

    ·

    Do you routinely test your code? Are you using rcov to run code coverage reports for your tests? If you aren’t, you should be. rcov is a code coverage tool for Ruby that is available as a Gem or a Rails plugin. It can generate text or HTML reports outlining what percentage of your code base is being exercised by your tests. The HTML reports even allow you to drill down and see exactly which lines in your code are being touched. If you’ve ever used a tool like Cobertura for Java, you’ll know exactly what to expect with rcov.

    Using rcov on a regular basis will enable you to isolate parts of your codebase that aren’t being tested very well (if at all). For example, the first time I ran rcov on one of my projects, it reported that the tests written against my Rails models touched 87% of the code. Not too shabby! However, my Rails controllers only had 45% coverage. Where do you think I concentrated my testing efforts after rcov was kind enough to inform me of these facts?

    Installing and using rcov with an existing Rails project is a cinch. Let’s get started:

    gem install rcov

    Now move to the root of your Rails project and type:

    script/plugin install http://svn.codahale.com/rails_rcov

    Voila! Installation complete. Don’t you just love Rails? Now let’s fall in love with Rake:

    rake test:units:rcov
rake test:functionals:rcov

    Running these tasks will generate a text-based report of your project’s code coverage. The percentage of each class covered is listed, along with a total for the entire set of tests (unit vs. functional). Rcov also creates a /coverage directory beneath the root of your Rails project. Inside this directory, you’ll find some beautiful HTML-based coverage reports.

    Want to report on just your model classes? What about controllers? Easy enough:

    rake test:units:rcov SHOW_ONLY="app/models"
rake test:units:rcov SHOW_ONLY="app/controllers"

    Delightful. Now I’d be set if only rcov integrated with Zen’s autotest to display a coverage report that automatically updates every time I change some code. One other minor nitpick is that, much as it seems like rake test:rcov should work, it doesn’t. Something else to add to a future release, I suppose.

    Are you in a team environment? Hook rcov up to a continuous integration system and catch Jonny slacking off on his tests… a full half hour before the morning stand-up meeting.

    For the price, you can’t beat what rcov provides. It won’t tell you if your tests are logically correct, but it sure as heck will scream at you if you’re not writing them to begin with.