dead dead good

I been using jQuery to do AJAX with Rails a lot recently, and I love it. When I was starting out however, I hit the same problem that seems to trip up everyone: AJAX requests made from jQuery don't trigger format.js (or wants.js if you're cool) within the respond_to block of Rails controller actions.

The most common solution I've seen to this problem involves adding a one-liner to your Javascript to instruct jQuery to add a text/javascript Accept header to AJAX requests. Which works great in FireFox, but not in Safari.

The problem seems to be that in Safari, text/javascript is appended to the existing Accept header, so Rails sees something like text/html, */*, text/javascript which it still interprets as a request for HTML.

An alternate solution that I've been using is to add the following to environment.rb.

config.action_controller.use_accept_header = false

This instructs Rails to use the X-Requested-With rather than the Accept header to determine the request format. Since jQuery sets this header in both browsers, Rails controllers will behave as expected.

One thing to keep in mind is that if your app has an XML or JSON API, you might need to think carefully about whether this is the best way to fix this problem. For a while this became the default in Rails, although that didn't last very long.

Update: Passenger 2.1.2 (final) has now been released.

The current stable release of Passenger (2.0.6) isn't compatible with Rails 2.3 because of recent changes in Rack. In the app I'm working on, this manifested itself as cookies not been set correctly, making it impossible to log out of the site. The good news is that the latest beta of Passenger includes support for Rails 2.3, you can install it (on OS X) as follows:

curl -O http://phusion-passenger.googlecode.com/files/passenger-2.1.1.gem
sudo gem install passenger-2.1.1
sudo passenger-install-apache2-module

Follow the on-screen instructions on updating your config, restart Apache and you're done.

I've been working on internationalizing a Rails app, and along the way I created a simple command to lookup Rails i18n translation keys from within TextMate. You use it like this:

1. Highlight a translation key. e.g. 'activerecord.errors.messages.inclusion'
2. Hit Shift-Command-i.
3. The relevant translation is shown on a tool tip, in this case "is not included in the list".

As well as simple keys, the command also works with any additional parameters you'd pass to I18n.t when using interpolation or the alternate translation key scoping syntax. For example highlighting :greater_than, :scope => [:activerecord, :errors, :messages], :count => 100 before invoking the command would yield "must be greater than 100" on the tool tip. There's also support for replacing local and instance variables used for interpolation with placeholder strings.

Since Sven Fuchs has already started an experimental Rails i18n TextMate bundle I've forked his rails-i18n repository and added this to it. Here's how to set it up:

The command is included in Sven Fuchs' experimental Rails i18n TextMate bundle, here's how to set it up:

git clone git://github.com/svenfuchs/rails-i18n.git
cp -r rails-i18n/tools/ ~/Library/Application\ Support/TextMate/Bundles/
# You also need the i18n gem
sudo gem install mattetti-i18n --source http://gems.github.com

The command has the default locale set to :en and is only loading translations from config/locales/en.yml. If you need to do something different take a look at the command in TextMate's Bundle Editor and you'll see what you need to change to get things working for you.

Calling a method in Ruby can be thought of as sending a message to an object. This isn't just an abstract concept, it's actually implemented in the language by the send method.

'foo'.length
# => 3
'foo'.send :length
# => 3

This is a really important method in Ruby (often used in meta-programming), so important in fact, that just in case you accidentally overwrite send in your own code, it is aliased as __send__ to make sure it can always be called.

One aspect of send that often causes discussion¹ is the fact that it allows you to call private methods which would otherwise be inaccessible using the regular method calling syntax, for example:

class Foo
  private
  def bar
    'baz'
  end
end

foo = Foo.new

foo.bar
# => NoMethodError: private method `bar' called for #<Foo:0x118fcbc>

foo.send :bar
# => "baz"

And for a while, Ruby 1.9 changed the implementation of send to only allow public methods to be called, introducing a new send! method² which continued to allow private methods to be called. However, this has now been removed from Ruby 1.9 in favour of keeping the functionality of send as is. Instead, a new public_send method has been introduced which as you might expect will only call public methods.

1. There are probably others threads, but the send bang method was discussed on the Ruby Talk mailing list.
2. For forward compatability with Ruby 1.9 send was aliased as send! in Rails as well, although this has also since been removed.

Creating nested resources in Rails can be a little bit tedious, particularly if you're using Rspec and its scaffolding. Updating the controller isn't really a problem, but making the specs pass involves a bit too much busy work. And then there are the views to take care of, and their specs, and don't forget the routing specs while you're at it.

Now you might suggest that make_resourceful and resource_controller offer a neat solution to this problem. Well, yes, sometimes. Often though, I find these super controllers tend to be a little too DRY for my tastes, at least on some projects. I'm usually happier starting with some generated code and hacking from there.

So what I'd really like to be able to do is scaffold out the nested resource and its specs. A quick look around Github turned up rspec_on_rails_nested_scaffold, a plugin which does just that. It is very nearly perfect for my needs, although I have forked it and updated the templates used for views and specs with those from the latest versions of Rails and Rspec respectively.

You can install the plugin like so:

script/plugin install git://github.com/phorsfall/rspec_on_rails_nested_scaffold.git

If you already have a Post resource you can create nested Comments like this:

script/generate rspec_nested_scaffold Comment --owner=Post post_id:integer body:text

This will generate a CommentsController which includes a before_filter to load the correct Post and has Active Record calls scoped accordingly. You also get views which include the correct links and form actions, along with updated controller, view and routing specs. Before you are finished however, there are a few small things you'll need to do by hand:

1. Update routes.rb. The generator will add an un-nested map.resources for our nested resource. In our example, we'd remove this and add the following:

   map.resources :posts, :has_many => :comments

2. Create the Active Record associations in your models.

   class Post < ActiveRecord::Base
     has_many :comments
   end
   
   class Comments < ActiveRecord::Base
     belongs_to :post
   end

3. If you didn't include a foreign key when you ran the generator, add one to the migration.

With that done, migrate the database and run the specs which should all pass. You now have an app you can go to work on and hopefully you've saved a bit of time along the way.

Thanks to Jeremy Friesen for putting the original plugin together.

It looks like work is still on-going to extract functionality common to Active Record and Active Resource into a new Active Model library. Excellent. But I wanted to add a couple of callbacks to Active Resource and I wanted to do it quickly. Thankfully, someone much smarter than me has already extracted callbacks from Active Record, so getting something working was pretty straight forward.

module ActiveResource
  module Callbacks
    CALLBACKS = %w( after_save after_destroy )
    
    def self.included(base)
      [:save, :destroy].each do |method|
        base.send :alias_method_chain, method, :callbacks
      end
      
      base.send :include, ActiveSupport::Callbacks
      base.define_callbacks *CALLBACKS
    end
    
    def save_with_callbacks
      returning save_without_callbacks do
        run_callbacks(:after_save) unless new?
      end
    end
    
    def destroy_with_callbacks
      returning destroy_without_callbacks do
        run_callbacks(:after_destroy)
      end
    end
  end
end

ActiveResource::Base.send :include, ActiveResource::Callbacks

Here's a short video of me struggling to demo an Etch a Sketch app which formed part of a presentation I gave at BarCamp Leeds as part of Simon Wheatley's 'My Last Project' session.

The code is a bit rough in places but might be of interest if like me you're getting started with either Arduino or Shoes development.

I've been doing quite a bit of work recently on an Active Resource project and needed to add pagination to one of our resources. I had a quick look around to see what other people were doing, and while it looks like work is underway to add support for Active Resource (and ORMs other than Active Record) to will_paginate I don't think it's quite ready just yet. So while we wait, may I present resourceful_pagination.

If you want to dive straight in, take a look at the readme then install the gem with:

sudo gem install phorsfall-resourceful_pagination --source http://gems.github.com

With the gem installed you get a shiny new ActiveResource::Base#paginate method. Use it like this:

MyResource.paginate(:page => params[:page])

This returns a WillPaginate::Collection which you can use with will_paginate's view helpers as usual.

Easy, right?, Well, sort of. The gem makes a few assumptions about your Active Resource class and your RESTful resource. If you want to use this you'll probably need to make a few changes. First you need to add two class methods to your Active Resources.

1. A count method which returns the total number of items. This could call a custom count action on the app server.
2. A per_page method indicating how many records you require per page.

Something like this would do the trick:

class MyResource < ActiveResource::Base
  @@per_page = 10
  cattr_reader :per_page

  def self.count
    get(:count)['count']
  end
end

You also need the index action of the controller on the app server to handle the :starting_at and :per_page parameters. These map to :offset and :limit in SQL and can be passed straight through to Active Record.

MyResourcesController < ApplicationController
  def index
    MyResource.find :all, :limit => params[:per_page], :offset => params[:starting_at]
    # Render XML etc.
  end

  def count
    count = MyResource.count
    render :xml => { :count => count }
  end
end

And that's about it. There's a little bit more to do if you have a nested resource, but there's a bit more on that in the readme.

Enjoy.

Writing custom RSpec expectation matchers is a great way to enhance the readability of your specifications. As an example, here's a simple matcher to check whether a collection contains any of the given items. An example will make things clearer:

# Passing example
odds  = [1,3,5,7,9]
evens = [2,4,6,8]
odds.should_not include_any(*evens)

One thing to note is that include_any expects multiple arguments rather than a collection, hence the splat. Here's the code:

module Spec
  module Matchers
    def include_any(*args)
      IncludeAny.new(*args)
    end
  
    class IncludeAny
      def initialize(*args)
        @args = args
      end
    
      def matches?(target)
        @target = target
        @target.include_any?(*@args)
      end
    
      def failure_message
        "expected #{@target.inspect} to include one or more elements from #{@args.inspect}"
      end
    
      def negative_failure_message
        "expected #{@target.inspect} not to include any elements from #{@args.inspect}"
      end
    end
  end
end

This is about as trivial as a custom matcher gets. All of the work is done by the include_any? method, which doesn't actually exist as part of the core Ruby API. In fact it's a simple extension to Enumerable that I think I originally borrowed from Merb. Put the following in config/initializers/core_extensions.rb or similar to use it in a Rails app.

module Enumerable
  def include_any?(*args)
    args.any? { |arg| self.include?(arg) }
  end
end

Which custom matchers are you using?

Mass assignment in Rails is super handy and saves heaps of code, especially in your controllers. As everyone knows however, hackers love mass assignment so you really need to use attr_accessible or attr_protected to protect your models.

But what happens if you want to mass assign model attributes which are otherwise protected? It would be simple enough to create your own method to do this, but if you take a look at the source you'll see that Rails already has it covered. Here's the method signature for ActiveRecord::Base#attributes=:

def attributes=(new_attributes, guard_protected_attributes = true)

That optional second parameter lets you bypass attr_accessible and attr_protected exactly as we'd like. But how do we call this? Well, you use send.

@model.send :attributes=, attributes, false

Encouraged by a couple of kind comments I submitted a patch for the change I wrote about in my previous post, and as of yesterday you can now do something like this in edge Rails.

caches_page :index, :if => Proc.new { |c| !c.request.format.json? }

I'd not used Lighthouse before and I'm still getting my head around everything Git. If you're in a similar position, you might find these links useful too:

• Best Practices for Contributing to Rails with Git
• Five tips for contributing to Rails
• Ticket Guidelines

Update 20/04/2008: I submitted a patch and this is now in edge Rails

When I created the JSON feed for my deadtre.es blog badge, one thing I didn't take care of was caching. As the contents of the feed will always be the same for a given URL no matter which user makes the request, it's a prime candidate for page caching. All I need to do is add caches_page :index to my controller, and Rails takes care of caching the index action for me. However, there's a problem here as the HTML format index action will also be cached, and unlike the JSON feed this does vary based on the logged on user (if you're looking at your own bookmarks you get edit and delete links for example) and so it isn't as suitable for page caching. What I'd really like to do here is to specify a condition that will be evaluated before the page is cached, much as the session method does.

caches_page :index, :if => Proc.new { |c| c.request.format.json? }

Unfortunately, a quick look at the docs for caches_page tells me that it doesn't support this. But looking at the source code I can see that caches_page is really just a nice shortcut for setting up an after_filter to perform the caching. So, instead of calling caches_page I could do this directly myself, and check the format of the page requested so that only the JSON feed is cached:

after_filter(:only => :index) { |c| c.cache_page if c.request.format.json? }

Now, although this works, it doesn't check that caching is enable (as caches_page does) and it's also not that pretty. Instead, I decided to override caches_page by dropping the following in my ApplicationController.

def self.caches_page(*actions)
  return unless perform_caching
  options = actions.extract_options!
  after_filter(:only => actions) { |c| c.cache_page if options[:if].nil? or options[:if].call(c) }
end

This is pretty similar to the original caches_page except that it evaluates any :if proc passed in before caching the page. Now, I can now call caches_page with the syntax I originally wanted:

caches_page :index, :if => Proc.new { |c| c.request.format.json? }

Job done.

I'm spending some time updating my Rails projects to use Capistrano 2 and Git. Here are the steps I took to build Git on my Ubuntu 6.06 slice.

sudo apt-get install curl libcurl3-gnutls-dev libexpat1-dev
wget http://kernel.org/pub/software/scm/git/git-1.5.4.5.tar.gz
tar xvf git-1.5.4.5.tar.gz
cd git-1.5.4.5.tar.gz
NO_TCLTK=yes make prefix=/usr/local all
NO_TCLTK=yes sudo make prefix=/usr/local install

When I wanted a quick (and arguably dirty) way to show my current reading list from deadtre.es on this blog, I figured that it was time to play with the JSON support which was baked in Rails 2.0. Wanting to keep things super simple, all I wanted to do was:

• Create a simple JSON feed I can include via a <script> tag. (I'll write a simple Javascript callback which will insert my reading list into each page. If I decide to make this easier for users I'll put together the usual configuration page where people can play with the look and feel of their badge and get some code to copy and paste.)
• Keep things RESTful. Each user already has a URL for their bookmarks so I really wanted to avoid to avoid creating new controllers or actions.

Cutting to the chase, this pretty much turns out to be a one-liner in Rails. Here's an example:

class BookmarksController < ApplicationController
  session :off, :only => :index, :if => Proc.new { |request| request.format.json? }
  
  def index
    # fetch bookmarks ...
    respond_to do |format|
      format.json do     
        excluded_book_attrs = [:aws_domain, :id, :created_at, :updated_at]        
        excluded_bookmark_attrs = [:book_id, :id, :updated_at, :user_id]
        render :json => @bookmarks.to_json(:except => excluded_bookmark_attrs, :include => { :book => { :except => excluded_book_attrs }}), :callback => 'show_deadtrees_books'
      end
    end
  end
end

It doesn't get much simpler than that! There are a couple of things worth pointing out:

• render :json takes care of setting the content type to application/json in the reponse header. Additionally, it wraps the JSON in a call to the method specified by the :callback option. (I should allow users to override this via the querystring to avoid name conflicts in their Javascript or to remove the callback altogether to support use outside of a <script> tag.)
• You can include Active Record associations when calling to_json using :include
• You can also control which attributes are serialized (including those on associations) using the :only and :except options.
• I've disabled sessions for JSON requests to the index action since they're not required and carry a reasonable overhead.

With that in place, all you need to do is implement your Javascript callback (borrow mine if you like) and your blog badge is done!

I suppose the laziest way to describe deadtre.es is as 'del.icio.us for books'. I've been tinkering with it on and off over the last couple of months or so, and thought it time I polished off the roughest edges and gave it a mini-launch here. As far as functionality goes it's missing some fairly obvious stuff at the minute, but it's usable and includes a bookmarklet for adding books from the pages of Amazon and a simple JSON feed should you want to display your reading list on your blog. If you want something a little more comprehensive you might want to check out Library Thing, BookJetty or maybe Amazon Wish Lists, but if you want a super simple way to keep and share a reading list you're more than welcome to give deadtre.es a go.