chrisblunt.com

Run Rails 3 Apps on Passenger

2010-03-05T00:00:00+00:00

Update: Make sure you update Rubygems using sudo gem update --system.

Whilst I've been learning more about Rails 3, I've been using the built in rails server to run my code. Today I tried to run my Rails 3 app through Passenger on Apache, and immediately hit an error page:

uninitialized constant Rack::Runtime

It turns out that Passenger notices Rails' new config.ru file, causing it to run as a Rack application. This requires a slight change in the app's VirtualHost entry. The RailsEnv setting now becomes RackEnv:

# /etc/apache2/apache2.conf
# RailsEnv development
RackEnv development

But that wasn't all. My development machine was still running Passenger 2.2.7, which wouldn't support Rails 3. To ensure a clean slate, I removed the old versions of Passenger and installed the latest build (2.2.11 at the time of writing). Once installed, I ran the standard Passenger installation script and updated apache2.conf:

$ sudo gem update --system
$ sudo gem uninstall passenger
  # Remove all versions of Passenger
$ sudo gem install passenger
$ sudo passenger-install-apache2-module

# /etc/apache2/apache2.conf
# Passenger mod_rails 
# NOTE: Your paths may be different. Use the config generated by Passenger's install script)
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11
PassengerRuby /usr/bin/ruby1.8

RailsEnv development
RackEnv development

After a quick restart of Apache, Passenger kicked in and my new Rails 3 app was up and running!

References

Building apps with Rails 3, RSpec, FactoryGirl and Mocha.

2010-03-03T00:00:00+00:00

Clone the source code from github.

It's no secret that Rails 3 has been released in beta for a little while now. Like most Rails developers, I was keen to try out some of the new functionality, not least the redesigned Active Record API.

Some heavy duty googling turned up little information on how to get an app started and configured with all the associated goodies we've come to expect: rspec, mocha and factory_girl.

This is probably because most of these plugins are in a state of development to bring full compatability with Rails 3. So until that happens, I thought I'd document how I've got a skeleton app up and running on Ubuntu using the current development branches.

You can find the latest versions of the code behind on my github. I'll continue to revise this template as I figure out more about Rails 3, and the plugins.

Installing Rails 3

There's plenty of posts detailing how to get Rails 3 on your machine. Favouring gems, I followed the official advice:

$ gem install tzinfo builder memcache-client rack rack-test rack-mount 
$ gem install erubis mail text-format thor bundler i18n
$ gem install rails --pre
$ rails -v
Rails 3.0.0.beta

With everything set, we can spin a new app using:

$ rails myapp
# Lots of output
$ cd myapp

Bundling Gems

Rails 3 uses the Bundler gem to configure its environment. Bundler brings a lot of benefits, including dependency resolution and ensures that an app's gem requirements are met.

Your app's required gems are declared in a Gemfile in your project root. A default Gemfile is provided to load Rails 3 and SQLite. For our project, we'll update it to require some additional gems:

# Gemfile
source 'http://gemcutter.org'

gem "rails", "3.0.0.beta"
gem "sqlite3-ruby", :require => "sqlite3"

# Require the haml gem for rendering HAML templates and SASS stylesheets
gem "haml"

# FactoryGirl and Shoulda Rails 3 development branches from github
group :thoughtbot do
  # I've included shoulda here in case you use TestUnit. Shoulda macros for RSpec 2 don't 
  # work yet though.
  gem "shoulda", :git => "git://github.com/sinefunc/shoulda.git",
                 :branch => "rails3"

  gem 'factory_girl', :git => 'git://github.com/thoughtbot/factory_girl.git',
                      :branch => 'rails3',
                      :require => "factory_girl"
end

group :test do
  # Install development release of rspec (includes rspec-rails)
  gem "rspec-rails", ">= 2.0.0.a9"
  gem "webrat"
  gem "mocha"
end

Now you can install the bundled gems with:

$ bundle install

Configuring RSpec and FactoryGirl

One of the first tools I felt lost without in Rails 3 was RSpec. Although I tried going back TestUnit, I missed the clarity of RSpec. With RSpec 2 installed by Bundler, the app can be prepared for specs with:

$ rails generate rspec:install

This creates the appropriate spec folder and configuration files. I configured RSpec to use FactoryGirl and Mocha. Notice that in the Gemfile above, Shoulda and FactoryGirl are declared in a group :thoughtbot. Bundler loads the default gems before Rails has initialised environment constants such as Rails.root. By declaring these gems within a group, they can be defered until Rails has setup the environment (Reference).

For RSpec to use FactoryGirl, we ask Bundler to load the :thoughtbot gems in spec_helper.rb:

# specs/spec_helper.rb
ENV["RAILS_ENV"] ||= 'test'
require File.dirname(__FILE__) + "/../config/environment" unless defined?(RAILS_ROOT)
require 'rspec/rails'

# Load in RSpec and Shoulda
# Shoulda macros don't seem to work with RSpec 2. When they do, this is where to require them.
# require 'shoulda'
# require 'shoulda/rspec'

require 'factory_girl'

# Autoloading of Factories seems to be broken, so manually require the <tt>factories.rb</tt> file
require File.dirname(__FILE__) + "/../spec/factories.rb"

# Requires supporting files with custom matchers and macros, etc,
# in ./support/ and its subdirectories.
Dir["#{File.dirname(__FILE__)}/support/**/*.rb"].each {|f| require f}

For now I've left shoulda out of the configuration as the Shoulda macros don't yet work with RSpec 2. I also manually required spec/factories.rb as FactoryGirl's autoloader also seemed not to be working yet. Before running a spec, you'll need to declare your factories in spec/factories.rb:

$ touch spec/factories.rb

Finally, switch RSpec to use mocha for mocking objects:

# spec/spec_helper.rb
# == Mock Framework
config.mock_with :mocha

Writing specs

With everything setup, it's time to write the first spec. As a simple example, I'll create a User model and its associated spec. With RSpec installed, the standard rails model generator will automatically create an associated spec file:

$ rails generate model user email_address:string password_hash:string password_salt:string
$ rake db:migrate
==  CreateUsers: migrating ====================================================
-- create_table(:users)
   -> 0.0041s
==  CreateUsers: migrated (0.0043s) ===========================================

The spec for the User model can now be written using the familiar RSpec dialect:

# spec/models/user_spec.rb
require 'spec_helper'

describe User do
  it "should be valid" do
    @user = Factory.create(:user)
    @user.should be_valid
  end
end

I've also used Factory.create to build a user, so as before, you'll need to declare your user factory in spec/factories.rb:

# spec/factories.rb
Factory.define :user do |u|
  u.email_address 'joe.user@example.com'
  u.password 'secret'
end

Finally, to run your specs, you use rake:

$ rake spec

All being well, RSpec should now load up and run your specs. In this example, the spec fails trying to set User#password. To fix this, we'll add a virtual attribute, password, to the User model that sets a salted, hashed password:

# app/models/user.rb
require 'digest/sha2'

class User < ActiveRecord::Base
  def password=(pass)
    @password =  pass
    return if @password.blank? 

    self.password_salt = Digest::SHA2.hexdigest(Time.now.to_s + rand(32000).to_s)
    self.password_hash = Digest::SHA2.hexdigest(@password + self.password_salt)
  end

protected
  def password
    @password
  end
end

With that, another call to rake should report your passing spec:

$ rake spec
.
Finished in 0.062692 seconds
1 example, 0 failures

With this, you can now start to build your Rails 3 app, complete with specs and factories. I'll continue to update the code on github as I figure out more, and as more plugins become compatible with Rails 3.

References

Changed Permalinks and More Blog Tweaks

2010-02-16T00:00:00+00:00

I'm really liking Jekyll as a blog engine, and have been tweaking a few things on the site. One big change is permalinks. To follow Jekyll's preferred convention, I've switched my post's permalinks from /blog/YYYY/MM/DD to just /YYYY/MM/DD. Thanks to Apache's mod_rewrite, old links will still work, but I find mod_rewrite rules a bit of a dark art. So, for convenience and future reference, here are the rules I've used:

# .htaccess
RewriteBase /
# Don't redirect if URL is a real file
RewriteCond %{REQUEST_URI} !-f
# Redirect requests for /blog/some/page.html to /some/page.html
RewriteCond %{REQUEST_URI}% ^/blog(.*)
RewriteRule blog/(.*) http://chrisblunt.com/$1 [R=301,NC,L]

# Redirect requests for /feed to Feedburner
RewriteCond %{REQUEST_URI}% ^/feed/?(.*)
RewriteRule ^(.*) http://feeds.feedburner.com/chrisblunt [R=301,NC,L]

For now, the changed permalink structure means that Disqus comments are not available. I've contacted Disqus about this though, and hope to move those comments to the new format soon.

In the meantime, everything else seems to be running smoothly on Jekyll. I've tweaked my site's design back to a fairly minimal theme - influenced by other Jekyll sites that I've seen.

I've kept deployments simple too; rather than using git hooks, I use a Rakefile and rsync combination based on this post. The Rakefile lets me use a fork of Jekyll to compile and upload the site with a simple call to rake deploy:

# /Rakefile
def jekyll(opts = "", path = "../jekyll/bin/")
  sh "rm -rf _site"
  sh path + "jekyll " + opts
end
  
def rsync(options = {})
  options = {
    :domain => 'servername', 
    :deploy_to => 'filesystem path',
    :port => ssh_port,
    :user => 'ssh_username'
  }.update(options)

  sh "rsync -rtz -e 'ssh -p #{options[:port]}' _site/ #{options[:user]}@#{options[:domain]}:#{options[:deploy_to]}/"
end

desc "Perform a jekyll rebuild of the site"
task :build do
  jekyll 
  Rake::Task["sitemap:build"].invoke
end

desc "Serve on Localhost with port 4000"
task :local do
  jekyll("--server --auto --limit-posts 5")
end

desc "Rebuild and Deploy to Live"
task :deploy => :build do
  rsync
  Rake::Task["sitemap:ping"].invoke
end

desc "Deploy the currently cached build to Live"
task :cached do
  rsync
  Rake::Task["sitemap:ping"].invoke
end

namespace :sitemap do
  desc "Rebuild the sitemap.xml using gen_sitemap.rb"
  task :build do
    generate_sitemap_bin = File.dirname(__FILE__) + "/_tools/gen_sitemap.rb"
    cmd = "cd _site && ruby #{generate_sitemap_bin} '.' > sitemap.xml"
    `#{cmd}`
  end

  desc 'Notify Google of the new sitemap'
  task :ping do
    require 'net/http'
    require 'uri'
    Net::HTTP.get(
        'www.google.com',
        '/webmasters/tools/ping?sitemap=' +
        URI.escape('http://chrisblunt.com/sitemap.xml')
    )
  end
end

Overall everything feels a lot lighter and easier to manage, and vim now sits at the heart of my blog workflow. This is great as I find it hard work to use any other text editor since learning vim. Static HTML means the site is served quickly as well, and I feel safe in the knowledge that my data is stored in a git repository rather than a single database.

One caveat is that the site can't include external dynamic content; at least not without some Javascript. I figure, though, that there are plenty of ways to follow my Twitter ramblings or photostreams and so on without adding distraction to the site.

So hopefully the transition is complete. Once the Disqus comments are linked, I'll be able to get back to writing some content to fill the blog! There's plenty to write about, with the recent release of Rails 3 beta, and my upcoming travels. I'll also document more about Amberleaf's development, post more Rails tips as I learn, and discuss a new mobile app for Android I'm starting.

Are you using Jekyll or something similar to power your site? How have you found the transition if you've switched from bigger engines like Wordpress or Mephisto?

Switching to Jekyll

2010-02-07T00:00:00+00:00

For several years now, I've used Wordpress to power this site. As I've learned to use new tools for coding (vim, git and so on), Wordpress has started to seem a little too heavy, especially for just writing posts. A <textarea> editor just can't cut it when you've been using vim for a couple of years.

So I started looking for alternative blogging engines. After trying out a few Rails-powered engines, I eventually stumbled across Jekyll.

Jekyll is described as a "blog-aware static site generator", and I set about giving it a try. After a few minutes, I knew that Jekyll was what I'd been looking for. It lets me edit my site in a text editor of my choosing, generates static HTML files (no more heavy server-side tech), and sits perfectly in a Rails-esque git push; rake deploy workflow.

So after a few days migrating from Wordpress, this site is now 100% Jekyll powered: there is no back-end PHP; no database connection to worry about; and everything is versioned and backed-up through git. I've used a fork of Jekyll that lets me write templates in Haml rather than stock HTML.

There have been a few bumps along the way, but thanks to the growing Jekyll community and wiki, there are plenty of helpful guides and tricks available to solve any problems I've had. Here's a quick overview of how I've switched to Jekyll.

Pure Text

Jekyll uses plain text for everything. Plain text is great - it's small and portable; can be edited using your editor of choice, and is easily versionable using tools like git.

Deploying

With a suitable Rakefile, managing my site is as simple as writing a post and running rake deploy. Rather that git post-commit hooks, I've used rsync (as described in this post) to push files into my server's blog directory.

Comments

Having no server-side scripting means that Jekyll sites have no way to submit and process comments. The Jekyll sites I've seen either don't use comments, or implement them through a hosted service such as Disqus or IntenseDebate.

I like the conversation that comments bring, so I went with Disqus to manage this site's comments. The process was fairly simple, and just involved adding a couple of <script> tags to my _layouts/post.haml file.

As an added bonus, using a hosted service lets you keep track of your conversations across the web, and listen for replies across a number of sites more easily.

Migrating Posts

Jekyll comes with a set of converters for getting your posts out of other blog engines. You can find them in the lib/jekyll/converters/ folder of the Jekyll repository.

I had 6 years worth of posts stored in Wordpress, and used the built-in converter to extract them. This was fine, but I found the default converter didn't migrate tags and categories.

After taking a quick look at the Wordpress database structure, I forked Jekyll and added a snippet of code to pull out each posts' tags and categories. The tags and categories are inserted into each post's YAML front matter.

You can find my fork of Jekyll on Github.

Code highlighting

Jekyll uses pygments to as its source highlighting engine. As a lot of my posts include code snippets, I've come to rely heavily on the wp-syntax plugin. Jekyll uses a different markup delimiter though, so I've not yet managed to migrate highlighted source code. I'm hoping to find some way to patch this, probably using regex. I'll update my fork of Jekyll with any changes.

An alternative approach that I'm thinking of is to use github gists. This would allow code to be embedded into each post, and would keep all my code in one place.

Google Sitemaps and Pings

My Wordpress site used a plugin to generate a sitemap.xml file every time a post was published. Again, the Jekyll community had already developed a script to replicate this functionality, and my sitemap.xml is now built and submitted to Google every time with every update.

RSS/Atom Feeds

My site's feed is handled through Feedburner. For the few users that were directly subscribed to my site's raw XML feed (http://chrisblunt.com/blog/feed), I've used Apache mod_rewrite to redirect requests to Feedburner. This should be transparent to those subscribers, but please let me know if you find otherwise.

So that's my site switched over to Jekyll, and I'm glad to say that everything seems to have gone smoothly. Thanks to the magic of mod_rewrite all previous links should still work.

The only problem so far is that code snippets haven't migrated properly, so you'll find that they aren't syntax highlighted. I'll work on switching those manually once I decide whether to go with gist or pygments.

There are likely to be a few more tweaks to the site's layout and theme. I'll also be posting more as I get to grips with Rails 3 and Android, and Claire and I start on our travels in March...

Amberleaf: Manage Your Domains & Hosting - Public Beta Now Open.

2010-01-04T00:00:00+00:00

After several months of evening development and jumping into Rails at the deep-end, I'm happy to jump into 2010 by opening public beta accounts for Amberleaf - and every account is free for the duration of the beta!

Amberleaf is built to remind you of upcoming renewals for domains and SSL certificate expiries, and hosting account renewals, and simply to remind you when to bill your customers. It is the evolution of HostManager, an OS X app I wrote back in my university days.

Who uses Amberleaf?

Anybody who has a domain! Whether you own or manage a single domain, or several hundred hosting accounts on behalf of your clients, Amberleaf is designed to make your life easier, by providing:

Automatic WHOIS lookup for domains, with more TLDs being added.
Email notification of upcoming expiries and renewals.
Private RSS feed of your upcoming notifications.
Simple client management, with the ability to import your existing clients' vCards.
Keep a history of notes for your domains and clients, such as when special discounts are due to end.

What do you think?

Amberleaf is completely free for the duration of the beta, and signup only takes a couple of minutes; I'd love to hear your feedback and comments.

Sign up for Amberleaf now or find out more.

If you've already signed up, you can email comments to chris at chrisblunt dot com; ping me on twitter (@cblunt), or send feedback directly from Amberleaf using the feedback tab at the bottom of every page.

If you'd like to see what's coming in future releases, and get involved in Amberleaf's development, check out the public tracker at trac.chrisblunt.com.

Just Married

2010-01-03T00:00:00+00:00

Over Christmas, Claire and I travelled to Las Vegas to finally tie the knot. After a few relatively easy months of planning, several hours delay in London and very little sleep; the wedding day was perfect.

We were married at the Treasure Island, and had a small reception meal across the road in the Venetian hotel, before taking a tour of the strip, and obligatory photos at 'the sign', in a stretch.

The trip was complete with a helicopter tour of the strip and neighbouring Grand Canyon valleys.

Needless to say it was one of the most exciting and unusual Christmas' I've ever experienced, and a great start to married life in 2010!

More photos on Flickr...

Introducing Molehill: Simple Issue Tracking

2009-12-15T00:00:00+00:00

In my previous post, I wrote how I've recently been getting to grips with Cucumber and Pickle. To do this, rather than trying to retro-fit Cucumber stories into another app, I decided to start with a fresh new Rails app: Molehill.

Molehill is an experiment, both in learning behaviour driven design (BDD), and also trying out some ideas for a simplified issue tracker.

Molehill is open-source, and can be downloaded from github. See the end of this post for more details.

Post. Fix. Close.

Molehill is designed to avoid the problem I've found with other issue trackers I've used - they do too much. They require so much overhead setting up and managing versions, milestones, time estimates, shipping forecasts, gantt charts, and so on - that it's as much work posting a case as actually fixing it.

Molehill takes a much simpler approach, purposefully avoiding all that which makes other issue trackers so heavy. Instead, Molehill is based on the idea that tracking bugs and features should be as simple as post, fix, close.

Posting and Promoting Cases

Taking cues from Twitter and the micro-blog format, cases are written as simple posts which are dropped into a timeline.

If a case is posted that you think is important, you can promote it. The more promotions a case has, the higher it appears in the timeline.

For developers, this means that your users' most desired bugfixes or features are always sitting at the top of the timeline. Instead of spending hours building roadmaps, and scheduling cases for release in 6 weeks (if you're lucky), just work on whatever case is next at the top of the list and release it.

Closing Cases

Once a case has been fixed or implemented, the original author can mark it as such; or - if it's not going to be implemented - it can be marked declined.

At the moment, only the original author can close a cace - I've intentionally avoided roles (such as Developers and Reporter) in Molehill, although I may have to make an exception so that developer's can mark any case as completed or declined.

An alternative approach might be to allow any other use to suggest a case is complete, or indicate that it won't be implemented. This might be better achieved through a reply system though, like Twitter's @reply tag.

Categories and Projects

Molehill doesn't have a concept of projects, but does allow #hashtags within a case. This means cases can easily be tagged and categorised to a project or feature, for example:

There should be a way for #molehill to categorise or tag #cases.

A quick search from the homepage, or click on the #hashtag, reveals any other cases tagged with the same words.

Cucumbers Everywhere

I built Molehill primarily to learn Cucumber, and doing so has got me hooked on writing feature-first code. The majority of Molehill was built without once launching Firefox or Chrome; everything was instead written as a feature, and run through Cucumber and Webrat until that feature passed.

Good Cucumber coverage allows far more confidence when deploying your code that everything works together. Too often I've seen a minor fix in one part of an app have a completely unforeseen effect on some screen assumed to be unrelated. With Cucumber, and a good test suite, these worries can be all but forgotten. Now that it's in public beta, I'm working to retrospectively cover Amberleaf in Cucumber stories

Getting Molehill

Molehill is open sourced under the MIT licence (the same as Rails). You can grab a copy of the code from github, and setup your own local Molehill server using the following steps:

$ git clone git://github.com/cblunt/molehill.git
$ cd molehill

$ cp config/database.yml.sample config/database.yml
# You'll need to configure your local database in config/database.yml

# Molehill has a number of gem dependencies, including Cucumber and Pickle
$ rake gems:install

$ rake db:migrate
$ rake db:migrate RAILS_ENV=cucumber

$ rake cucumber

You can also generate an RCov coverage report (saved in features_coverage) using:

$ rake cucumber:rcov

There is a live demo of Molehill running at http://molehill.chrisblunt.com. To begin with, I'll use Molehill to track its own development. However, if it proves to be a workable concept (and requires less management than a full redmine setup), I'll probably use it for Amberleaf's issue tracking as well.

Rails: Building Apps with Cucumber and Pickle

2009-12-11T00:00:00+00:00

I'd often read about Cucumber, but had always been put off by the task of learning another abstract domain language to distract me from actually writing code. But as I kept reading more and more about it, curiosity got the better of me and I had to give it a try.

After a couple of weeks of learning to use Cucumber, I'm completely hooked.

What is Cucumber?

Cucumber grew out of RSpec as a language for describing user stories in behaviour driven design (BDD). Cucumber avoids the abstract and often incorrect, functional and technical documenting of the software process, instead encouraging you to write short, specific stories about an should do.

In Cucumber, these stories are described through number of individual steps that describe a situation, set of actions, and conditions to be met. For example, a Cucumber story to test logging out of an application might look something like:

# features/logging_in_and_out.feature
Scenario: A logged in user wants to log out
  Given I am logged in
  And I click the "Log out" link
  Then I should not be logged in
  And I should be on the home page
  And I should see "You have been logged out"

Stories are designed to be written and read by people, not machines. When you run your story through Cucumber, it applies some funky logic and regular expression matching to run your application code against the story's steps. Each step creates or checks the situation being described.

For example, the steps for the logging out feature above might be:

# features/step_definitions/authentication_steps.rb
Given /^I am logged in$/ do
  controller.current_user = Factory(:user) # I've used FactoryGirl to create fixtures here
end

Then /^I should not be logged in$/ do
  controller.current_user.should be_nil
  session[:user_id].should be_nil
end

Thankfully, Cucumber comes with a collection of pre-defined steps that cover common situations, such as the Then I should see "{something}" and When I click "{some link}" steps in the previous example.

Cucumber with Pickle

Cucumber works well with a number of other gems, but one that you'll definitely want to use is pickle. Once installed, pickle gives you a collection of handy step definitions for creating a referring to new models in your stories.

In the example below, a new Post model is created and assigned the label "the post". The remaining steps can then refer to "the post" directly:

# features/publishing_posts.rb
Given a post "the post" exists with published: false
And "the post" belongs to me
When I am editing "the post"
And I click "Publish Post"
Then "the post" should be published
And I should see "Post Published"

Why You Should Be Using Cucumber

Confidence

The greatest benefit of Cucumber (and most test-driven methodologies) is that you gain an incredible amount of confidence in your code. Before any release, you can quickly and automatically check that your whole application is doing what you'd expect it to do. This makes releases a far less daunting experience.

It tests your entire application, from top to bottom

I'd always found testing the high-level functionality of a web app tricky with other test tools, including RSpec. Although they were great at checking very specific, model conditions, when it came to testing the working app as a whole, they never seemed to quite cut it.

Cucumber lets you write tests that drive through every layer of your application: views, controllers, models and other utility classes (such as email handling, see this great post on email_spec) can all be tested in a much more natural manner.

Stories are reusable

As you write more stories, you'll quickly build up a library of handy step definitions. You can use more advanced regular expressions to DRY those step definitions, and then re-use them in other parts of your project, or in other projects.

Your code is self documenting

One of the greatest benefits of Cucumber stories is that they act as effective documentation for your app. Cucumber can output its running descriptions in a number of formats, including HTML. Having this documentation automatically generated can give you even more assurance that your code is doing what you'd expect, and lets you answer those "what's supposed to happen if...?" questions with certainty.

Get Started

If you haven't tried Cucumber yet, I really recommend you take an hour to follow some of the tutorials. You definitely won't regret it. There's loads more tips and information available on the Cucumber website, as well as the official RSpec Book from The Pragmatic Bookshelf.

In the next post, I'll introduce Molehill, my first attempt at building an app the BDD way. In the meantime, if you'd like to check out the code and take a look at the Cucumber stories, you can find Molehill on github.

Rails: Multiple default scopes for ActiveRecord

2009-10-22T00:00:00+01:00

Default scopes were introduced in Rails 2.3 to allow a default set of options to be applied to any find methods. The common example is to always order a set of results by a given column, e.g:

class Post < ActiveRecord::Base
  # Any calls to Post.find will automatically have the default :order option merged into them
  # Post.find(:all)
  # => SELECT * FROM "posts" ORDER BY "created_at DESC";
  default_scope :order => "created_at DESC"
end

Unlike named_scopes (which I am finding more and more useful every day), I found that default scopes cannot be combined when I tried to use the acts_as_revisable and is_paranoid plugins together:

class Post < ActiveRecord::Base
  acts_as_revisable
  is_paranoid
end

It seems the default scope declared in is_paranoid overrides that of acts_as_revisable. Post.find(:all) will therefore return every revision of Post rather than just the current revision. You can check this out by reversing the plugin order:

class Post < ActiveRecord::Base
  is_paranoid
  acts_as_revisable
end

Now, Post.find(:all) will return only current revisions, but will include any destroyed posts as the acts_as_revisable default scope overrides is_paranoid!

A Solution

This post and code snippet shows a method for declaring multiple default scopes on a model. I've not yet tried out the code, though, as one of the commenter's was kind enough to forkis_paranoid and modify it to merge any existing default scopes. With this forked plugin, Post can be scoped correctly by both plugins.

The fork is available at http://github.com/grioja/is_paranoid/tree/master.

But... is_paranoid is depracated

I noticed that the original is_paranoid plugin has ceased development, so I'm not sure if I'll continue to use it, although It's a neat little plugin, and has several forks.

The underlying problem, though, of ActiveRecord allowing only one default_scope to be declared, is something that I'm bound to come up against in the future, so it's handy to know there is a workaround at least until Rails includes the functionality.

As an aside, Rich Cavanaugh, the developer of acts_as_revisable, has pointed out that the plugin includes some basic is_paranoid functionality already (see Rich's reply to my original ramblings):

class Post < ActiveRecord::Base
  acts_as_revisable :on_delete => :revise
end

Do you use default_scope? Do you find the single scope a limitation, or do you rely on named scopes? Feel free to discuss in the comments.

Rails: Getting the id of form fields inside a fields_for block

2009-10-12T00:00:00+01:00

Something that seems to crop up a lot when working with nested forms is the need to access the id of an input field generated inside a fields_for loop. The problem is that the FormBuilder object doesn't expose its index attribute, so you can't specify the full id of the field. For example:

# app/views/people/_form.html.erb
<% person_form,fields_for :attributes do |attributes_form| -%>
  # This text field's id will be in the format person_attributes_[index]_name
  <%= f.text_field :name %>

   # No way to know what [index] should be
  <%= observe_field :person_attributes_[index]_name, ... %>
<% end -%>

I hit this problem a few days ago when I wanted to setup autocompleters on a dynamically generated field. I ended up posting a solution to Google Groups. For completeness, I'm reposting the code with all my typos removed.

Where does the index come from?

To find out how the FormBuilder generates its field ids, I delved into the Rails source code and found a couple of helper methods in the InstanceTagMethods module (source).

The methods of interest are sanitized_object_name and sanitized_method_name. They take the name of the FormBuilder's model object (which is publicly accessible) and return the generated form element id (e.g. person[attributes][0][name] becomes person_attributes_0_name).

However, the methods that work this magic are private to the InstanceTagMethods module, so you can't get at them from within your fields_for block.

Exposing the generated form field ids

I decided to duplicate these methods in my application_helper.rb, making them available to my fields_for block. Whilst not DRY, this is so far the only solution I've found for exposing the FormBuilder's index:

# app/helpers/application_helper.rb
def sanitized_object_name(object_name)
  object_name.gsub(/\]\[|[^-a-zA-Z0-9:.]/,"_").sub(/_$/,"")
end

def sanitized_method_name(method_name)
  method_name.sub(/\?$/, "")
end

def form_tag_id(object_name, method_name)
  "#{sanitized_object_name(object_name.to_s)}_#{sanitized_method_name(method_name.to_s)}"
end

# app/views/people/_person_attributes.rb
# wrapped in person_form,fields_for :attributes do |attributes_form|
<%= f.text_field :name %>
<%= observe_field form_tag_id(f.object_name, :name), ... %>

This code works for indexed partials (i.e. those with indexes based on their model id), and those generated with timestamp indexes such as in Ryan Bates' latest nested form code for Rails 2.3 - http://github.com/ryanb/complex-form-examples.

Rails: Complex Queries with Named Scopes

2009-10-06T00:00:00+01:00

I've recently come to realise the massive power of ActiveRecord's named_scopes. The revelation came whilst I was researching how to scope, by their permissions, the records a @current_user can view or edit.

I'd looked at all sorts of plugins and complex authorization configurations, before realising that named scopes have almost limitless potential for building such complex queries.

What are named scopes?

As demonstrated by Ryan Bates' screencast, named scopes let you declare finder conditions as methods on your model object.

For example, you could get all active users using

# app/models/user.rb
class User < ActiveRecord::Base
  named_scope :active, :conditions => { :active => true }
end

# To select all active users
User.active

The real power of named scopes, though, lies in their ability to be chained. As they are just methods on your model class, they can be combined, and ActiveRecord will take care of building the relevant conditions and joins:

# app/models/user.rb
class User < ActiveRecord::Base
  named_scope :active => :conditions => { :active => true }
  named_scope :admin => :conditions => { :admin => true }
  named_scope :recently_logged_in, 
              lambda { { :conditions => ['logged_in_at >= ?', 7.days.ago]  } }
end

# To get all active users who have recently logged in:
User.active.recently_logged_in

# To get all active admin users who have recently logged in
User.active.admin.recently_logged_in

Using Named Scopes to Build Complex Queries

With chaining, you can build some pretty complex queries with ease. However, it would be great if we were able to declare some conditions at run-time, rather than when the model class is loaded.

The lambda function lets you do just that, taking a set of arguments and inserting them into your query:

# app/models/user.rb
class User < ActiveRecord::Base
  named_scope :admin, :conditions => { :admin => true }
  named_scope :last_logged_in, lambda { |time_ago| 
    time_ago ||= 7.days.ago
    { :conditions => ['logged_in_at >= ?', time_ago] }
  }
end

# By default, we'll get users who have logged in in the last 7 days:
User.last_logged_in

# To get users who have logged in during the past 4 weeks:
User.last_logged_in(4.weeks.ago)

# To get admin users who have logged in in the past 6 months
User.last_logged_in(6.months.ago).admin

Combining lambda with named_scope lets you build complex attribute queries with runtime arguments. As an example, I've reworked my the code from my previous posts to make use of named_scope:

# app/models/user.rb
class User < ActiveRecord::Base
  named_scope :name_like, lambda { |terms| 
    # ensure terms is an array
    terms = [*terms]

    composed_conditions = EZ::Caboose::Condition.new :users

    terms.each do |term|
      term = ['%', term, '%'].join

      condition = EZ::Caboose::Condition.new :users
      condition.append ['first_name ILIKE ?', term], :or
      condition.append ['last_name ILIKE ?', term], :or

      composed_conditions << condition
    end

    { :conditions => composed_conditions.to_sql }
  }
end

With this small chunk of code (and a helping hand from the Caboose EZ Condition plugin), you can now search for Users by matching their first or last names with the supplied terms, e.g:

# To search for users with a first or last name like "joe"
User.name_like("joe")

# To search for users with a first or last name like "joe" and a first or last name like "bloggs":
User.name_like(["joe", "bloggs"])

As we saw above, the greatest advantage of using named_scopes for this type of functionality is their ability to chain. With this in mind, I was able to solve my problem of scoping results within the permissions of @current_user:

# app/models/user.rb
class User < ActiveRecord
  # ...
  named_scope :visible_to lambda { |user| 
    { :conditions => ['department_id IN ?', user.managed_department_ids] }
  }
end

User.last_logged_in(4.weeks.ago).name_like(["joe", "bloggs"]).visible_to(@current_user).ordered_by(:name)

Named scopes are undoubtedly one of the most powerful tools available to ActiveRecord. I can't help but think I'm still just scratching the surface of their potential, but already I've been able to refactor pages of code and build powerful, Rails-friendly custom queries.

Are you using named scopes in your code? Feel free to discuss in the comments!

Rails: Writing library code

2009-09-17T00:00:00+01:00

Plugins are great in Rails, but sometimes they seem a bit much for certain tasks, such as writing a quick utility mixin. In a previous post on writing DRY validators, I discussed putting the validation mixin code inside Rails' config/initializers directory.

Although this worked, it didn't feel clean: Rails apps come with a default lib folder that seems much better suited to the task.

Since reading this post on Rails' other files. I've used the following setup in projects such as Amberleaf to load all the mixins and utility code that doesn't warrant its own plugin:

# config/initializers/application.rb
require 'lib/application.rb'

The lib/application.rb acts as a start point for loading in any of your other library code. In the following example, I've mixed some methods into the String class and written a small extension to ActiveRecord::Base.

# lib/application.rb
require 'core_ext/string.rb'
require 'core_ext/array.rb'

require 'active_record/auditing.rb'

# lib/core_ext/string.rb
module CoreExt
  String.class_eval do
    def wrap
      ["%", self, "%"].join
    end
  end
end

# lib/active_record/auditing.rb
module ActiveRecord
  module Auditing
    def self.included(base)
      base.extend ClassMethods
    end

    module ClassMethods
      def acts_as_auditable
        include InstanceMethods
      end
    end

    module InstanceMethods
      def auditable_name
        self.name
      end
    end
  end
end

ActiveRecord::Base.send :include ActiveRecord::Auditing

This is a lot neater than putting everything in the initializers folder, and allows you to correctly namespace your files. It also prevents your model, controller and view folders from becoming cluttered with utility code.

Rails: Configuring RSpec for Spork

2009-08-28T00:00:00+01:00

RSpec is great for behaviour driven development in Rails. However, as the amount of code you test increases, so too does the time taken to run the tests.

To help speed things up, I've been using Spork; a small server that preloads all your library code and sits waiting for specs to run. Installing and setting up your project to use Spork is quick to do:

# Spork relies on cucumber
$ gem install cucumber spork

# Prepares your project for Spork
$ cd railsap
$ spork --bootstrap

Once your project is bootstrapped, you'll need to move all your RSpec initialisation code into the prefork block that Spork has added to your spec_helper.rb:

# spec/spec_helper.rb
require 'rubygems'
require 'spork'

Spork.prefork do
  # All the default RSpec stuff goes here, e.g:
  ENV["RAILS_ENV"] ||= 'test'
  require File.dirname(__FILE__) + "/../config/environment"
  require 'spec/autorun'
  require 'spec/rails'
  Spec::Runner.configure do |config|
    # ...
  end
end
#...

Now you can run a Spork server instance with:

$ spork

For me, though, Spork refused to run. It just kept throwing the following exception:

Preloading Rails environment
Loading Spork.prefork block...
uninitialized constant MissingSourceFile (NameError)

Fixing the configuration for Spork

For a short while, I skipped Spork and continued running my specs as normal. Eventually the number of specs I was testing took several seconds for each run, which soon added up to a lot of waiting.

So, after some searching and thanks to this post on Google Groups, I learned the exception is caused by a condition included as part of the default RSpec initialisation code.

The solution is to remove the condition from your spec_helper.rb:

# spec/spec_helper.rb
# ...
# before:
# require File.dirname(__FILE__) + "/../config/environment" unless defined?(RAILS_ROOT)
require File.dirname(__FILE__) + "/../config/environment"

Now you should be able to run Spork with:

$ spork
Using RSpec
Preloading Rails environment
Loading Spork.prefork block...
Spork is ready and listening on 8989!

Finally, you can tell RSpec to connect to and use Spork if it is running. Just add --drb to your spec.opts file:

# spec/spec.opts
--colour
--format progress
--loadby mtime
--reverse
--drb

Note that these options are only used if you run RSpec through the rake spec: tasks. If you run specs manually, remember to add the --drb option, for example:

$ script/spec --colour --drb spec/controllers/users_controller_spec.rb

Changing your spec setup code by removing the condition is obviously far from ideal, and it may break compatability with cucumber (see this lighthouse ticket for more information). However, it at least means you can take advantage of Spork until a proper fix is implemented.

Rails: Validating Unique Attributes with acts_as_revisable

2009-08-06T00:00:00+01:00

I've been using the acts_as_revisable plugin in my Rails apps to store a revision history of ActiveRecord models. The plugin automatically versions your models, and allows you to navigate revisions; branch and merge changes, and perform bulk changesets.

During some tests of my code, I found a conflict between the plugin and ActiveRecord.validates_uniqueness_of. It seems the conflict occurs because acts_as_revisable stores all revisions in the same database table. For example, when trying to save a record whose :name attribute should be unique, the validator will see all previous versions of the record with identical names, and prevent the save.

The fix I put in for this was to use the :scope to scope validates_uniqueness_of by the revisable_is_current attribute:

class User < ActiveRecord::Base
  validates_as_unique :username, :scope => :revisable_is_current
end

Scoping the attribute causes the validator to only consider records whose :revisable_is_current attribute matches that of the record being edited. This works for my app, as only the current revision (User#revisable_is_current= true) will ever be edited.

Are you using acts_as_revisable and come across this problem? Spotted a better solution? Feel free to discuss ideas in the comments.

Rails: Upgrade Passenger for Rails 2.3.3

2009-07-31T00:00:00+01:00

I recently upgraded a project from Rails 2.3.2 to 2.3.3, after which I started getting strange the following error from Passenger:

undefined method 'rewind' for #<UNIXSocket:0xf6206c18>

After a little Googling, I discovered that I also needed to upgrade passenger from 2.1.2 to the current version 2.2.4. If you're using RubyGems, this is a quick and easy:

gem update passenger
passenger-install-apache2-module

Once the Passenger installation has finished, be sure to update your apache config to point to the new version of Passenger:

# apache2.conf
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4
PassengerRuby /usr/bin/ruby1.8