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.

  • rspec_validation_expectations gem released

    ,

    ·

    I just released a new gem on GitHub that provides some common validation expectations to rspec. Instead of writing specs to verify that your models are handling validation correctly, these expectations simply check that the validation is getting declared correctly in your model. For example:

    describe User do
  it_should_validate_presence_of :first_name, :last_name, :email
  it_should_validate_numericality_of :zip
  it_should_validate_uniqueness_of :email
end

    Since the expectations never hit the database, they are also faster than testing the traditional way. It’s dead simple to install on Rails 2.1 or later:

    script/plugin install git://github.com/pelargir/rspec_validation_expectations.git

    The expectations become available to your specs immediately.

  • RubyCamp is coming to Raleigh

    , ,

    ·

    Raleigh’s first RubyCamp is coming to Red Hat on October 18th. This is a similar format to BarCamp in that the presentations are pitched the morning of the conference, and attendees self organize the remainder of the day. Relevance will be running their popular Refactotum workshop in the morning. The conference is free, but attendance is capped at 200 so visit the wiki to grab your spot.

  • Lindo graduates to a gem

    ·

    Lindo renders the body of an HTTP response from inside a Rails functional or integration test. It used to be a plugin, but now it’s a gem. Why? Because Rails gems are the new hotness. Now go get it.

  • finder_filter gem released

    ,

    ·

    I’m at the Ruby Hoedown in Huntsville this weekend. Being around so many brilliant geeks encouraged me to release a gem I’ve had sitting in the hopper for several weeks.

    finder_filter encapsulates a pattern I find myself using quite frequently in Rails. Namely, looking up an instance variable before an action. For example:

    class UsersController < ActionController::Base
  before_filter :find_user, :only => [:show, :edit]
  
  def show
    # do something with @user
  end
  
  def edit
    # do something with @user
  end
  
  def find_user
    @user = User.find(params[:id)
  end
end

    Sticking the finder in a before filter keeps the code DRY, but it still takes several lines to do this. finder_filter reduces this to a single line of code:

    class UsersController < ActionController::Base
  finder_filter :only => [:show, :edit]
  
  def show; end
  def edit; end
end

    There are other options to customize the column and param used in the lookup. Check out the README for full details.

    To install the gem as a plugin in your Rails project:

    sudo gem install pelargir-finder_filter --source=http://gems.github.com

    Then open environment.rb in your Rails app and add the gem as a dependency in your initializer block:

    Rails::Initializer.run do |config| 
  config.gem "pelargir-finder_filter"
  ...
end

    If you have any comments or suggestions, I’d love to hear from you. Contact me through the finder_filter project on GitHub.