paulsturgess.co.uk articles

Using rspec to test a named_scope in Ruby on Rails

When testing a named_scope it's important to test the expected behaviour of the method, not how it's implemented, as this will allow you to re-factor your code using the test as an indicator that the re-factor was successful.

So in your model you might have...

class User < ActiveRecord::Base
    named_scope :active, :conditions => ["active = ?", true]
end

In your model spec I'd then have...

describe User, "::active" do
    it "includes users that are active" do
        @user = Factory(:user, :active => true)
        User.active.should include(@user)
    end

    it "excludes users that are not active" do
        @user = Factory(:user, :active => false)
        User.active.should_not include(@user)
    end
end

The key thing here is that we're not actually calling named_scope, we could change the method to be a regular class method if we wanted and the test would still pass.

It may be a good idea to check that the model has the method defined like so...

User.should respond_to(:active)

Hosting a ruby on rails blog on Heroku cloud hosting

I've taken the plunge and moved my site over to Heroku ruby cloud host. My initial impressions of the service are great so I thought I'd post up my experience so far.

I've opted for the basic free setup to see how it goes. It's difficult to compare what you get to other hosts because Heroku is so different. Everything is hosted in the cloud on Amazon EC2, you create a 'compiled slug' which is a read only version of your app and that's hosted on the 'Dyno Grid'.

I have one 'Dyno' which is kind of equivalent to a single Mongrel, essentially the more Dyno's the more concurrent your app. I figure that as my blog is so simple that concurrency is a non issue, anyway if it became one I can easily add more Dynos.

Dynos are actually spread across multiple servers so I need to forget servers. The main difference is that I don't have ssh access and I can't write to anywhere. This means user uploads (not that I have any) would need to be stored somewhere like Amazon S3. Plugins like Paperclip make this so easy anyway that it's pretty much a non-issue.

The other main change is the pure git work-flow. That's right no Capistrano. I couldn't believe how easy it is to deploy to Heroku though, all you do is push code to your repository and it's live.

But what about database migrations? Well as far as I can tell you need to pull down your database, make any changes locally and then push it back up to Heroku. I guess you would need to temporarily take down the site between updating the code and the database. I need to investigate further here but for my blog I can't see it being a problem.

Heroku provide a lot of addons to extend your app. I'm making full use of the free 5mb of memcache and while that doesn't sound like much everything appears to be running so much faster, I can always upgrade for a fee if I want.

Moving my domain couldn't have been easier because of the way Heroku have integrated with Zerigo for DNS, no sign up required at all.

I'm also using another addon for sending email through SendGrid. I have this just for notifications of new comments or exceptions. I can send upto 200 emails per day for free.

So far everything has gone so smoothly, fingers crossed it stays that way as I'm loving the zero hosting costs!

How to install a Ruby on Rails plugin from a specific git repository branch

Lots of Ruby on Rails plugins are being updated for Rails 3 and thus for older Rails apps you don't always want to install the latest and greatest version.

Recently I needed to install the Rails 2.3 stable version of the exception notification plugin and so I needed to specify a particular branch in the git repository.

script/plugin install git://github.com/rails/exception_notification.git -r 2-3-stable

The -r option allows you to identifiy the specific branch you're after.

Using named scopes (named_scope) in Ruby on Rails

Ruby on Rails 2.1 introduced the notion of a Named Scope. For me it's easily been one of the most beneficial features in helping to keep my code 'DRY'.

Essentially it allows you to apply conditions that you want to use when finding records without having to write out those conditions each time.

For example, I have an Article model and one of the attributes for an article is 'published'. Now in the old days I might have written code in my controller that looked something like this...

@articles = Article.find(:all, :conditions => ["published = ?", true])

I would have repeated this every time I wanted to get all the published articles out. The problem with this approach being that if what determines if an article is 'published' changes, then I'd need to go and change it in x number of places I'd written that line.

Introducing named_scope. In the Article model I simply define a named scope with a name and then my conditions...

class Article < ActiveRecord::Base
  named_scope :published, :conditions => ["published = ?", true]
end

Now in my controllers I can use...

@articles = Article.published

So much better, it's clearer, it's quicker to type and I can now update that published method in one place, safe in the knowledge it will ripple throughout all my controllers.

I can also chain named scopes together...

class Article < ActiveRecord::Base
  named_scope :published, :conditions => ["published = ?", true]
  named_scope :has_comments, :conditions => ["comments_count > 0"]
end

@articles_with_comments = Article.published.with_comments

You can also pass in variables to named scopes by using a lambda...

class Article < ActiveRecord::Base
  named_scope :by_author, lambda { |author| { :conditions => ["author_id = ?", author.id] }}
end

@your_articles = Article.published.by_author(current_user)

That last example is probably unrealistic as it's more likely you would call it like so...

@articles = @author.articles.published

Note that you can still use the named scope even though you're grabbing the articles via an Author model instance.

You can also use named scopes to setup commonly used limits or orders.

class Article < ActiveRecord::Base
  named_scope :recent_limit, :limit => "5"
  named_scope :order_by_last_comment, :order => "last_comment_at DESC"
end

A Ruby on Rails will_paginate gotcha

Here's a cheeky gotcha to keep an eye out for when using the popular pagination plugin/gem for Ruby on Rails will_paginate

I was doing something like...

Foo.find(:all, :order => "bar DESC").paginate :page => params[:page]

Looks harmless enough. However, what I didn't realise is that the paginate method cannot run efficiently with the find(:all, ...) method in there.

The whole point of the pagination is to only load the objects you need to for the page, an accompanying sql count allows it to build the links to additional pages.

However, the code above will actually instantiate every single Foo object and load it into memory; nasty.

I tried removing the order to see if that was the problem...

Foo.all.paginate :page => params[:page]

But still it remained inefficient.

The fix was to remove the all method and use the built in paginate :order paramater like so...

Foo.paginate :page => params[:page], :order => "bar DESC"

Now it loads only those objects required for the page.

For a moment I feared how the paginate method had been dealing with named scopes but I can confirm it is happy to work with those and retain its' efficiency, only loading what is required for the page.

How to efficiently perform a bulk update of lots of records in Ruby on Rails

If you are looking to update a lot of database records at once in Ruby on Rails then it's worth considering the different ways it can be done and which is the fastest and most efficient.

One way is to loop/iterate round a collection of objects and update each one in turn. Your code might look something like...

Foo.all.each do |foo|
   foo.update_attributes(:bar => true)
end

However, it's worth noting that using a block in that way will instantiate each Foo object into memory and will also generate a mysql query per record. The advantage of this is that any Active Record callbacks will be triggered and each object will be validated.

Another, faster, way to do this generating just a single SQL UPDATE statement would be to use the update_all method like so...

Foo.update_all(:bar => true)

It does not instantiate the involved records and the single sql query makes this method faster and more efficient. However, it will not trigger any Active Record callbacks such as 'after_save' etc. so if you need these you'll have to go with the first method of updating each object in turn.

Note that the update_all method can accept conditions as second argument in the same format as the rails find method.

Foo.update_all({:bar => true}, ["id IN (?)", foo_ids])

Alternatively you can call update_all on named scopes.

How to freeze gems in Ruby on Rails

It's always a good idea to freeze your gems in your Ruby on Rails app when you don't have full control over your hosting environment.

To freeze any gems that are listed inside your Rails::Initializer config block just run the following on the command line...

rake gems:unpack

Your gems will be frozen in the vendor/gems directory.

Alternatively you can freeze a specific gem version by...

[~/yourapp/vendor/gems] gem unpack gem_name -v=<version>

Missing these required gems: RedCloth - config.gem Ruby on Rails error

RedCloth is one of those gems that is not consistently named and has caused me problems in the past.

This time even though I had specified it's requirement in my environment.rb file inside the Rails::Initializer block I was still getting the 'Missing these required gems' error.

I had frozen the gem into the vendor directory so obviously it wasn't being found by Rails.

Turns out all I needed to do was add a lib parameter to the config.gem line...

config.gem 'RedCloth', :version => '>=x.x.x', :lib => 'redcloth'

Ruby on Rails sort_by vs sort

Given the choice when sorting arrays in Ruby it's typically better to use sort_by rather than sort.

sort_by uses the Schwartzian transform technique that is a Perl programming idiom used to improve the efficiency of sorting a list of items.

You can use sort_by like so...

foo.sort_by(&:bar)

The equivalent using sort would look like...

foo.sort{|a,b| b.bar <=> a.bar}

However, using sort will mean that the method bar is called twice for each comparison and therein lies the inefficiency.

How to include class and validation methods using a module in Ruby On Rails

A great way to re-use code across your Ruby on Rails application is to use a module and include the methods contained within it where you need them.

You simply create a file (typically named the same as your module) inside the lib directory where it is automatically loaded by Rails. For example a file lib/foo.rb may look like this...

module Foo

  def bar
    # ...
  end

end

Now in a class you can make the bar method available as an instance method thus:

include Foo

However, if you want to include a class method you need to modify the class that is including the module, this can be done using the included method. Most plugins use the included method as follows...

module Foo

  def self.included(base)
    base.extend ClassMethods
  end

  module ClassMethods
    def my_class_method
      # ...
    end
  end

  def bar
    # ...
  end

end

You simply put all your class methods inside the ClassMethods module (omitting the usual self part of the name).

However, this doesn't work for all class methods. For example validation methods and callbacks are typically called without the self prefix as it is implicit from the class that is defining the method. When including these methods you need to explicitly set the class, this can be achieved thus:

module Foo

  def self.included(base)
    base.validates_presence_of :bar
    base.before_save :some_method
  end

end