GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

2 years of hackfests

Fri, 30 Oct 2009 15:10:00 -0400

On Tuesday, we’ll be hosting the November Boston.rb hackfest at the thoughtbot Boston office. This marks two years and about 30 total hackfests we’ve held here.

If you’ve never attended, please join us the first Tuesday night of every month. All skill levels and backgrounds are welcome.

attendance award

Josh Nichols deserves special recognition for attendance. He has attended more hackfests than anyone else and had about a year streak of perfect attendance once.

Thanks, Josh, for keeping the group active and vibrant.

celebrating the output

While the majority of the fun of the hackfests is meeting other locals interested in similar technologies, there has been an impressive number of open source projects big and small to which Boston Rubyists have contributed patches big and small during these hackfests.

We’d like to highlight those now and thank all those for contributing.

Note that many of the following were not written at the hackfests, although some were. All of the large projects simply had patches written at the hackfests by Boston Rubyists.

web application frameworks

Ruby on Rails is a full stack, Web application framework optimized for sustainable programming productivity, allows writing sound code by favoring convention over configuration.

gem management

Gemcutter is an open source Sinatra-and-Rails app for hosting Rubygems… awesomely.

Jeweler is a simple and opinionated helper for creating and managing Rubygem projects.

testing

RSpec is a Behaviour Driven Development framework for Ruby.

Cucumber is a BDD framework that talks to domain experts first and code second.

rspec-rails is an RSpec extension that allows you to drive the development of Ruby on Rails applications with RSpec.

Shoulda is a context test framework built on Test::Unit and a set of Rails testing “macros” that can be used in any Ruby testing framework (RSpec, test/spec, etc.).

Quiet Backtrace suppresses the noise in your Test::Unit backtraces.

jferris/mocha is a fork of Mocha that adds test spies.

RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse syntax.

greengreen is a tool for assuring quality metrics of 100% quality.

Factory Girl is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.

templating things

Effigy is Ruby views without a templating language. (alternative to Mustache, ERb)

Slidedown lets you generate slides with Markdown, for display in web browsers.

Jekyll is a simple, blog aware, static site generator that takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favorite web server.

Rails apps

Boston.rb is the source code for http://bostonrb.org, a community site for local Rubyists.

Peas is the source code for http://peas.heroku.com, a URL shortener.

Echowaves is the source code for http://echowaves.com, social group chat aimed as an open source alternative to Campfire.

Clean Together is the source code for http://cleantogether.com, which lets people post their environmental cleanup experiences.

generators

Blitz is a Rails plugin for feature, view, controller, model, & helper generators meant to be used as part of an “Outside-In” Test-Driven Development cycle.

Webster generates random short words good for human-readable confirmation codes.

configuration

jferris/config_files is dotfiles for git, vim, zsh, & irb.

process management

Under Construction is JQuery Utility for hiding or overlaying elements that haven’t been built yet, inspired by Mile Marker.

search

Ambitious Sphinx is an Ambition adapter for Sphinx.

SearchModel is a Rails plug-in for building search forms.

authentication

Clearance is a Rails engine for authentication with email & password.

computer science

CS is is a gem containing some algorithms useful for computer science and math.

command-line interfaces

Beardo is a CLI for Co-op.

Hello is a Ruby interface to a collection of the word “hello” in many languages and dialects; written for Flickr-style messages after users sign in to a web application.

web service API wrappers

Le-Git is a Ruby wrapper for the Github API.

Daywalker is a Ruby wrapper around the Sunlight Labs API.

Twitter Search is a Ruby wrapper around the Twitter API.

countless failed and semi-failed experiments, incomplete hacks, forks, & bad ideas

Daddy Warbucks was a library idea to find orphaned Ruby code not
being sent messages from anywhere in your program. We learned a little bit about Kernel#set_trace_func and called it a night.

Recommendable was a Rails plugin concept for simple item-to-item collaborative filtering.

Nurse cares for invalid ActiveRecord objects.

dancroak/rails-templates contains Rails templates for Suspenders, Heroku, & MongoDB.

MySpace API Ruby wrapper.

Wikipedia API Ruby wrapper.

ActiveObject was an ActiveRecord-like library for persisted serialized Ruby objects.

Altering Shoulda to use context as its context/should framework.

Benchmarking an add-on to Thin.

An early, failed attempt at what Joe Ferris would later accomplish in Factory Girl.

Porting apps to Rails 2.1. Porting plugins to gems.

Videoconferencing in Eloy Duran at 1am his time in Amsterdam to talk about RubyCocoa.

Creating the first version of bostonrb.org in Merb, Haml, & DataMapper when none of us had ever used any of those tools.

and a lot of pizza & beer…

I’m sure I missed a lot. Feel free to add anything to the comments.

See you Tuesday night!

Sharing assertions between Cucumber and Test::Unit

Fri, 23 Oct 2009 08:00:00 -0400

YO CUCUMBER, imma let you finish but according to rake stats, my units have the best collection of hand-rolled assertions of ALL TIME.

Guinea Pigs Battle for Cucumber: a compelling and entertaining short film

How to share with Cucumber

The gist is this: declare your assertions in a TestSupport::Assertions module, inside test/support — feel free to split them up into multiple files, to keep things organized. Then, both Test::Unit and Cucumber will load those files up and include the modules as appropriate:

[~/dev/app] tail -n 2 features/support/env.rb
Dir[File.join(RAILS_ROOT, 'test', 'support', '*.rb')].each { |f| require f }
World(TestSupport::Assertions)

[~/dev/app] tail -n 4 test/test_helper.rb
Dir[File.join(RAILS_ROOT, 'test', 'support', '*.rb')].each { |f| require f }
class Test::Unit::TestCase
  include TestSupport::Assertions
end

[~/dev/app] cat test/support/stuff_assertions.rb
module TestSupport
  module Assertions
    def assert_stuff(params)
      assert_match /stuff/, params
    end
  end
end

Ker-DRYed up code!

Letters from viewers

I hear from people who know about testing that this approach to sharing between units and Cucumber is de-facto in RSpec.

So, what do you like to share between Cucumber and your unit tests?

Have you ever...faked it?

Wed, 21 Oct 2009 13:37:00 -0400

I’ll admit it - I’ve faked it. Sometimes, you just can’t wait for a service to finish and you just want to fake a satisfactory response. There are lots of techniques for doing this: stubs, mocks, spies, and fakes. A full fake object will require more up-front effort than a quick stub, but they can be more reusable, reliable, and fail-proof.

Keeping your tests local

Probably the first reason every developer encounters that drives them to test doubles of any kind is an external service. Writing tests that interact with a live server is bad for a number of reasons: it’s slow, it’s hard to setup your test, and your tests will likely interact with each other (or other developers’ tests). You’ll also eventually run into that frustrating situation where server downtime results in a development blackout.

Overriding methods

Ruby is extremely flexible with its class definitions, to the point that you’re allowed to reopen and append (or redefine) methods at any point. I’ve seen lots of projects where this is used to simply white out pieces of the application that developers don’t want running in tests:

# The production code
# app/models/event.rb

class Event < ActiveRecord::Base
  before_validation :geocode
  # ...
  private
  def geocode
    geo = GeoKit::Geocoders::MultiGeocoder.geocode(address)
    if geo.success
      self.lat, self.lng = geo.lat, geo.lng
    else
      self.errors.add(:address, 'Unable to identify your location.')
      false
    end
  end
end

# The override
# test/support/geocoding.rb

module GeoKit
  module Geocoders
    class MultiGeocoder < Geocoder
      def self.geocode(location)
        loc = GeoLoc.new
        loc.lat = 1
        loc.lng = 1
        loc.success = true
        loc
      end
    end
  end
end

That little snippet lets you hit the ground running. Your tests don’t need to hit an external server, and you can test that a latitude and longitude is assigned when the record is created. However, you can’t test the negative case, and if you want to write tests for geo-spatial search, you’re out of luck.

Using stubs

If you need different geocoded results in different tests, a straight-up override won’t do it for you. At this point, a developer might turn to stubs and mocks:

describe Event do
  it "should geocode a valid location" do
    loc = GeoLoc.new
    loc.lat = 100
    loc.lng = 200
    loc.success = true
    GeoKit::Geocoders::MultiGeocoder.
      stubs(:geocode).
      with('123 Happy Street').
      returns(loc)
    event = Factory.build(:event, :address => '123 Happy Street')
    event.save
    event.lat.should == loc.lat
    event.lng.should == loc.lng
  end

  it "should add an error message with an invalid location" do
    loc = GeoLoc.new
    loc.success = false
    GeoKit::Geocoders::MultiGeocoder.
      stubs(:geocode).
      with('123 Sad Lane').
      returns(loc)
    event = Factory.build(:event, :address => '123 Sad Lane')
    event.save
    event.should_not be_valid
  end
end

You’ll probably need to stub out geo locations several times throughout the test suite, so wrapping these up in helper methods helps:

describe Event do
  it "should geocode a valid location" do
    loc = build_geoloc(:lat => 100, :lng => 200, :success => true)
    stub_geoloc!('123 Happy Street' => loc)
    event = Factory.build(:event, :address => '123 Happy Street')
    event.save
    event.lat.should == loc.lat
    event.lng.should == loc.lng
  end

  it "should add an error message with an invalid location" do
    loc = build_geoloc(:success => false)
    stub_geoloc!('123 Sad Lane' => loc)
    event = Factory.build(:event, :address => '123 Sad Lane')
    event.save
    event.should_not be_valid
  end
end

However, this leads to a few new problems:

Most of the time you create an Event in a test, you don’t care about geocoding, so you’ll probably still need to add an override.
Writing stubs like this in Cucumber tests is tricky - you need to make sure your stubs are torn down, and refactoring your implementation will noisily cause scenarios to fail. This isn’t what you want from an integration test.
You can’t test the stubs themselves, and these methods are difficult to reuse, especially between projects.

Swappable components

One of the best pieces of programming advice I’ve ever received is this: “separate the pieces that change from the pieces that don’t.” Logic that doesn’t directly apply to your domain, such as geocoding and credit card processing, are likely to change. Which provider will you use? Do you need failover support? Adding the code (and tests) to your models is likely to increase churn and noise in the essential models of your application. Extracting these other concerns to external components helps reduce this noise. Writing these components so that the implementation can be swapped out will take you even further.

Luckily, in the case of GeoKit, this has all been done for you. GeoKit supports several Geocoders, and the list of Geocoders that will be used can be configured per-environment. The list of Geocoders is configured via the global “provider_order” setting:

GeoKit::Geocoders::provider_order = [:fake]

GeoKit will look for a camelized constant nested under GeoKit::Geocoders for each provider specified, so you can write a fake geocoder like this:

module GeoKit
  module Geocoders
    class FakeGeocoder < Geocoder
      def self.geocode(location)
        # return a GeoLoc instance
      end
    end
  end
end

If you maintain a global registry of locations mapped to latitude and longitude, you can write steps like the following:

Given /^the following geolocations:$/ do |table|
  table.hashes.each do |hash|
    location = hash['Location']
    lat = hash['Lat'].to_f
    lng = hash['Lng'].to_f
    GeoKit::Geocoders::FakeGeocoder.locations[location] = [lat, lng]
  end
end

Because GeoKit allows you to swap out the geocoder implementation without changing your model code, there’s no test-specific code in your model, no overrides to look for, and no extra churn in your model if you decide to switch providers.

Keeping it fresh

One potential issue with the above faking strategy is that there are a number of globals involved: the GeoKit provider is specified globally, as is the registry of fake locations. This means that you’ll need a teardown phase to clear the registry. In this case, there’s little reason to swap out implementation at runtime or between tests. However, if you’re faking out something that changes live, these global won’t do.

When possible, I recommend accepting the external component as a parameter. If Event could take a GeoKit provider as a parameter, you could write tests like the following:

describe Event do
  it "should geocode a valid location" do
    fake_geocoder = FakeGeocoder.new('123 Happy Street' => [100, 200])
    event = Factory.build(:event, :address => '123 Happy Street',
                                  :geocoder => fake_geocoder)
    event.save
    event.lat.should == 100
    event.lng.should == 200
  end
end

There’s no teardown required. The FakeGeocoder is discarded after the test executes, so the mapped locations don’t live beyond the test.

Keeping it real

When faking out a component, make sure you adequately reproduce the actual expected behavior. When faking out payment gateways, you’ll need to cover a variety of error responses and so on. When faking out a geocoder backend, you may want to simulate timeout errors and other failures. Make sure you have enough test cases that your application will catch the edge cases that occur when using the real thing.

Apply liberally

Developers are forced to extract code into external components when it’s just not feasible to use the same code in the tests, as is the case when contacting external services. However, there are many pieces of behavior that can be extracted that don’t need to be: searching, authentication, and so on.

Although developers usually only use stubs and mocks when they need to, many developers eventually prefer the isolation, speed, and declaritive nature of such doubles. If you start experimenting with fakes in place of mocks for external services, you may find that there are pieces of your code that you could swap out just to keep the churn down in your models, or to keep your tests focused on what they’re testing.

How about you? Have you ever…faked it?

Video: Sinatra at Boston.rb, part 3

Tue, 20 Oct 2009 14:16:43 -0400

This is the third in a series of short videos. They feature Blake Mizerany discussing Sinatra and Heroku in great technical detail at September’s Boston.rb. Watch Part 1 and Part 2 if you’d like.

legacy APIs

Blake uses “legacy APIs” as a common use case for Sinatra. The reason params[:splat] and params[:matches] and super-flexible routing in Sinatra exists is because of work done on an existing non-RESTful, ugly API that sent all the data back in the URL itself (not in JSON or some other format).

This seems to be consistent with the philosophy of “Don’t fear the URLs”.

return values must respond to “each”

In order to be Rack-compliant, your return values of Sinatra routes should respond to each. Blake mentions the Ruby 1.9 gotcha that the Rack spec also mentions:

The Body must respond to each and must only yield String values. The Body should not be an instance of String, as this will break in Ruby 1.9. If the Body responds to close, it will be called after iteration. If the Body responds to to_path, it must return a String identifying the location of a file whose contents are identical to that produced by calling each. The Body commonly is an Array of Strings, the application instance itself, or a File-like object.

templates

get '/' do
  erb(:index)
end

The file would be named “index.erb”. Sintra doesn’t use the same “name.format.template” convention because the routes are supposed to be “less magical”. You should know what your response format is based on which route you’re already in.

begin/rescue vs. throw :halt

I hadn’t seen a discussion of these two control structures before. begin/rescue is meant for exceptions and throw :halt is meant for returning a value and returning to another section of code.

The promise is that this will come in very handy as we dive deeper into Sinatra.

get '/' do
  halt(404) unless session[:user]
  # ...
end

As Sinatra processes the route, it’s listening for halts and passes.

when Sinatra, when Rails?

I cut a section out for space reasons where Blake talks about thanking David Heinemeier Hansson for writing Rails. Blake had been trying to get Ruby into companies for years without much success, then Rails came along and made it acceptable.

Rails:

get bigger apps going quickly
less pain to get a CRUD app going

Sinatra:

more control
choose your own conventions
legacy APIs
small apps going quickly
take full advantage of Rack, no special magic to be compatible

shotgun

At the end of this video, I included a section where Blake shows, in response to an audience question, how to append to an existing body via response.body.

I thought his shotgun command was more interesting, though.

Shotgun is “an automatic reloading version of the rackup command that’s shipped with Rack.” It gets you “application-wide reloading of all source files and templates on each request” by forking into a child process, processing, then exiting the child process.

Note that this is not part of Sinatra at all. This is obviously great for a development environment, but keeps Sinatra clean by being a third party.

Moving from “classic Sinatra” to Sinatra::Base
Why throw :halt is so cool in practice.

Video: Sinatra at Boston.rb, part 2

Sat, 17 Oct 2009 00:06:30 -0400

This is the second in a series of short videos. They feature Blake Mizerany discussing Sinatra and Heroku in great technical detail at September’s Boston.rb. Watch Part 1.

In HD this time… watch out, the kid is learning!

“use” is built-in

In this video, Blake extends his example code using Rack middleware from rack-contrib called Rack::AcceptFormat:

Adds a format extension at the end of the URI when there is none, corresponding to the mime-type given in the Accept HTTP header.

Example from the docs:

GET /some/resource HTTP/1.1
Accept: application/json

GET /some/resource.json HTTP/1.1
Accept: application/json

Blake says we can use Rack::AcceptFormat in our config.ru or in Sinatra, depending on the situation.

This middleware will re-write path_info

What’s cool about this is Sinatra doesn’t have to know about Rack::AcceptFormat’s deeds making our work with content types easier. By the time the request gets to Sinatra, “.json” has been added. Call it “just-in-time routing”.

Rack Hoptoad

On the day Blake spoke at Boston.rb, he and I sat down to get Rack Hoptoad working on Heroku. Staying true to the philosophy of backing into patterns, we started with a bare-bones Rack app, then moved to Sinatra.

In both cases, we need to specify the gem in our .gems file:

# http://docs.heroku.com/gems#overview
rack_hoptoad

Rack:

# config.ru
require 'rack_hoptoad'

use Rack::HoptoadNotifier, "123abc"
run lambda { |env| fail "Fail!" }

Sinatra:

# config.ru
require 'rack_hoptoad'
require 'example'

use Rack::HoptoadNotifier, "1234"
run Sinatra::Application

# example.rb
require 'sinatra'

configure :production do
  enable :raise_errors
end

get '/boom' do
  fail "Fail from Sinatra!"
end

when Rack, when Sinatra?

Blake’s rule of thumb is to start with Rack when he knows, when he’s starting, that he’s only going to have one route, maybe two, and there’s nothing special about them.

In many ways, Sinatra is just a clean DSL around HTTP with lots of delegation to Rack. Without it, you’d have messy conditional statements that are fine for a couple of routes, but get out of hand beyond that.

routing tricks

Access wildcard operators using block syntax instead of a Rails-style params[:first_name]:

get '/:first_name/:last_name' do |first, last|
  "Hello, #{first} #{last}"
end

Sinatra allows splats, such as this non-greedy match:

get '/:name.*?/:last' do
end

The returned object will be a normal Ruby MatchData object, so everything you can do with that applies in your Sinatra code.

Stay tuned next time when our protagonist discusses:

POSTing data to a legacy API
war stories
view templates

Video: Sinatra at Boston.rb, part 1

Fri, 16 Oct 2009 18:03:00 -0400

This the first in a series of short videos. They feature Blake Mizerany discussing Sinatra and Heroku in great technical detail at September’s Boston.rb.

Blake Mizerany wrote Sinatra in 2006 because he was working on a high traffic site with a lot of POSTs, PUTs, and DELETEs. GETs can be cached but the others cannot.

In this video, Blake discusses the following concepts as they apply to Sinatra:

backing into patterns

Start with a string, start with a text file, use main on Ruby. Move up to Factories and Model-View-Controller and ActiveRecord when you need it.

Rails creates 72 files when you run the rails command. Blake decided he didn’t need to start with MVC on each new project.

clean routing system

Blake uses Sinatra often for web services. He compares Rails’ respond_to with Sinatra’s content_type declaration. He discusses his feeling that the routing systems in other frameworks are overly complex undesirable.

get '/users.json' do
  content_type :json
  @user = User.find(params[:id])
  @user.to_json
end

His first example, shown above, highlights Sinatra’s clean content type approach.

In the next video, Blake discusses:

handling the Accepts header using Rack middleware
deciding between Rack and Sinatra
rack-hoptoad
routing tricks such as passing wildcard params into block variables and non-greedy matching

fundamentals: TDD a date helper

Thu, 15 Oct 2009 11:57:00 -0400

I want to format a date range in a view for our training app. This is a job for helpers. A fundamental skill for Rails developers is writing the helper using TDD. This process takes about 10 minutes and results in a confidence-building regression suite.

Working outside-in, we start in the interface:

<%= format_date_range(course.date_range) %>

Tests fail, “format_date_range” doesn’t exist.

script/generate helper date_time

Produces:

# app/helpers/date_time_helper.rb
module DateTimeHelper
end

# test/unit/helpers/date_time_helper_test.rb
require 'test_helper'

class DateTimeHelperTest < ActionView::TestCase
end

Incidentally, former thoughtbot intern Eugene Bolshakov wrote the Rails patch that creates the helper test stub generator.

First case:

should "format date range on same day" do
  eight_oclock = DateTime.new(2009, 10, 12, 8)
  nine_oclock  = DateTime.new(2009, 10, 12, 9)
  date_range   = eight_oclock..nine_oclock
  expected     = "October 12, 2009"

  assert_equal expected, format_date_range(date_range)
end

My style is flat test structure, intention-revealing temporary variables, respect an 80-character line limit.

Make it pass:

def format_date_range(date_range)
  first = date_range.first
  last  = date_range.last
  if same_day?(first, last)
    "#{first.to_s(:month_day)}, #{first.year}"
  end
end

private

def same_day?(date_one, date_two)
  date_one.day == date_two.day
end

More temporary variables. Simple private method is there for a more expressive question in the conditional.

Next case:

should "format date range on different days of same month" do
  monday     = DateTime.new(2009, 10, 12)
  tuesday    = DateTime.new(2009, 10, 13)
  date_range = monday..tuesday
  expected   = "October 12-13, 2009"

  assert_equal expected, format_date_range(date_range)
end

Same pattern. Make it pass:

def format_date_range(date_range)
  # ...
  elsif same_month?(first, last)
    "#{first.to_s(:month_day)}-#{last.day}, #{last.year}"
  end
end

private

def same_month?(date_one, date_two)
  date_one.month == date_two.month
end

Same pattern. Date and time formatting already has a home in config/initializers/time_formats.rb, so we’re using our existing date format, month_day. Here’s what my typical initializer looks like:

{ :short_date  => "%x",                 # 04/13/10
  :long_date   => "%a, %b %d, %Y",      # Tue, Apr 13, 2010
  :longer_date => "%B %d, %Y %H:%M %Z", # April 13, 2010 11:20
  :index       => "%Y/%m/%d %H:%M",     # 2010/04/13 11:20
  :standard    => "%B %d, %Y",          # April 13, 2010
  :month_day   => "%B %d",              # April 13
  :abbr_month  => "%b"                  # Apr
}.each do |key, value|
  ActiveSupport::CoreExtensions::Time::Conversions::DATE_FORMATS.update(
    key => value
  )
end

Final case:

should "format date range on days of different months" do
  october    = DateTime.new(2009, 10, 31)
  november   = DateTime.new(2009, 11, 1)
  date_range = october..november
  expected   = "October 31-November 01, 2009"

  assert_equal expected, format_date_range(date_range)
end

Make it pass:

else
  "#{first.to_s(:month_day)}-#{last.to_s(:month_day)}, #{last.year}"
end

There’s room for improvement: that leading zero sucks. We could use %e instead of %d, which replaces the leading zero with a space:

expected   = "October 31-November  1, 2009"

That makes the test look a little ridiculous, but since the output will be HTML, the extra space is fine.

Make it pass:

:month_day   => "%B %e"

Complete source code.

Sneak peak of the app in progress, taking advantage of the date helper:

Slave to the intepreter

Tue, 13 Oct 2009 15:57:15 -0400

I think of Ruby as the “free love” language. Yet, even Ruby can put the programmer in chains.

klass

Ever seen code like this?

klass = Class.new
klass.class_eval do
  def self.xyz
    'xyz'
  end
end
@model = klass.new

The programmer names the temporary variable “klass” to avoid a collision with the class keyword.

Bob Martin uses this as an anti-pattern, extolling programmers to “make meaningful distinctions” in Clean Code.

misspelling and over-abbreviation

I wrote this last week:

attitudes.each do |tude|
  # something
end

Cute. I re-wrote it.

The problem was attitude was also a method in scope.

restricted vocabulary

I’ve been working on our training application. The education domain is full of troublesome terms for software:

classes
sessions
forms (British)

We could start talking in terms of “workshops” or “seminars”, which we may have to for the purposes of the application, but it feels like the interpreter is pushing us around.

I’m the human; you’re the computer.

I know I’m going to be teaching a class and say things like “see you at tomorrow’s class.” That’s the most natural vocabulary, but the interpreter has its own ideas.

no way out

I don’t see a way around these problems, however. Just seems like the hand we’re dealt. Any creative solutions out there?

code cowboy

Mon, 12 Oct 2009 15:24:00 -0400

I’ve written before about lightweight access control using inherited_resource’s begin_of_association_chain and raising a 404.

I still prefer this approach in the vast majority of apps I work on, but it doesn’t work in the case where there is no relationship between a user and an object other than access control.

custom

Last week, I had a need to differentiate access control to some controller actions based on whether a signed in user was a teacher or student.

This is a simple need, and I’m loathe to introduce a large gem into the app for what could just be a custom before_filter:

class CoursesController < InheritedResources::Base
  actions :new, :show, :index

  before_filter :authenticate
  before_filter :deny_student, :only => [:new]

  protected

  def deny_student
    deny_access if current_user.student?
  end
end

However, I recently saw acl9 mentioned on a mailing list and really liked the DSL. Couldn’t we have the best of both worlds?

So, Josh Clayton and I wrote up a sub-set of acl9’s DSL that would meet my needs.

module AccessControl
  def self.included(controller)
    controller.extend(ClassMethods)
    controller.send(:include, InstanceMethods)
  end

  module ClassMethods
    def access_control(options = {}, &block)
      before_filter(options) do |controller|
        controller.authenticate
      end
      before_filter(options) do |controller|
        controller.instance_eval(&block)
      end
    end
  end

  module InstanceMethods
    def allow(role, opts = {})
      if opts[:to].nil? || opts[:to].include?(action_name.to_sym)
        unless current_user.send("#{role}?")
          deny_access(opts[:flash])
        end
      end
    end

    def deny(role, opts = {})
      if opts[:from].nil? || opts[:from].include?(action_name.to_sym)
        if current_user.send("#{role}?")
          deny_access(opts[:flash])
        end
      end
    end
  end
end

ActionController::Base.send :include, AccessControl

the DSL

In action:

class CoursesController < InheritedResources::Base
  actions :new, :show, :index

  access_control do
    allow :teacher, :to => [:new]
  end
end

Very expressive. Nice work, Oleg Dashevskii!

features we cared about

optional flash mesage
natural language (allow/to and deny/from)
role is just a boolean on User

opinions we could have

This will usually be included when most actions require a signed in user. Therefore, we call authenticate and allow an ugly override for edge cases:

class CoursesController < InheritedResources::Base
  actions :new, :show, :index

  access_control(:except => :show) do
    allow :teacher, :to => [:new]
  end
end

This is used with Clearance and can therefore rely on authenticate, current_user, and deny_access.

instance_eval

Writing code with a pretty DSL in mind is exceedingly fun. The one downside seems to be that scope can become confusing.

Yesterday I was messing with Rails app templates and read the source for the 2.3 template runner. It, like this custom access control DSL, also uses instance_eval as the key line to make things work.

In the app template example, it was hard to figure out how to get the file path of the original template.

I simply wanted to require 'helper', a separate file in the app template, but because of the scope within which it was instance_eval‘d, helper could not be found.

in_root { self.instance_eval(code) }

The solution in that case was to take advantage of other public methods and mess with the load path, which would probably an atrocious solution for a vendored gem in a Rails app, but acceptable for a one-off script to generate a Rails app:

here = File.expand_path(File.dirname(template), File.join(root,'..'))
$LOAD_PATH << here
require 'helper'

In the access control example, it was hard to figure out how to have access to flash, redirect_to, etc. from a class-level scope.

Similar to the require 'helper' example, your tests will fail if:

deny and access are defined at the class level
instance_eval is not used to delay evaluation until runtime
you don’t use before_filter’s block

The solution is to use blocks and lazy evaluation to control scope, but it can be confusing to get there:

before_filter(options) do |controller|
  controller.authenticate
end
before_filter(options) do |controller|
  controller.instance_eval(&block)
end

not a code cowboy

Every time you decide to roll your own, remind yourself that you may waste time getting lost in something like a scope problem you haven’t seen before. Then, once you get the rhythm down, be careful of a thought like “it won’t take me that long to write.” Re-inventing the wheel has to be balanced with a specific reason in addition to, “it will be fun for me.”

The third-party ecosystem of gems and plugins is one reason why Rails is awesome. However, writing custom code every now and again is worth it for programmer pleasure, fewer lines of code and dependencies, and staying focused on only what you need.

Ruby makes great DSLs, though, so don’t be afraid to take inspiration from existing code and try your hand at making beautiful code for a specific purpose.

Happy Birthday, Ralph

Thu, 01 Oct 2009 13:37:45 -0400

Please join the celebration.

Today is the 4th anniversary of the incorporation of thoughtbot, inc. (We previously existed as an MA state partnership - which turned 7 years old in July). October also marks our 4th anniversary of working almost exclusively with ruby and rails as a web application platform.

We’d like to thank our current and past employees for their commitment to producing quality software in a productive environment. We created thoughtbot to make that environment a reality, and we love that it’s still going strong.

We’d like to thank our current and past customers for hiring us - and give a special thanks to our earliest customers who had to make the case for an “unproven” technology within their organizations by choosing Rails as a platform.

We’d also like to thank the Ruby community, all the other great Rails-focused companies doing web app development, the Rails core team, Ruby conference organizers, all our training alumni — for making the ruby community such a fun and professional place to exist as a software developer.

We think our best work is yet to come, and look forward to the future with a sort of crazed, sinister-yet-loving robotic stare.

testing named scopes

Tue, 29 Sep 2009 14:30:42 -0400

Everyone was psyched when Nick Kallen’s has_finder plugin was added to Rails as named_scope. They’re powerful, particularly when chaining.

One disadvantage is that they are so easy to create, people want their tests to be equally concise, which is often impossible.

Two related “testing named scopes” questions have come up recently on the thoughtbot training mailing list and the shoulda mailing list.

Movie recommendations: InternetFlicks

We’re going to create a movie recommendation system called InternetFlicks.

script/generate model Movie ranking:integer in_stock:boolean
script/generate model Viewing user:belongs_to movie:belongs_to

The user:belongs_to syntax is from Blitz. We’ll assume a User model is already created, perhaps using Clearance.

Outside-In

Say we’re working on the recommendations page for the signed in user. RESTfully, this might be:

/recommendations

We can use a simple authorization strategy:

class RecommendationsController < ApplicationController
  before_filter :authenticate
  def index
    @movies = Movie.recommended_for(current_user)
  end
end

I’m skipping a few steps here, but our goal is to determine what interface the model needs to expose.

Also note that we’re intentionally crossing resources (“recommendations”) in the RESTful sense with a model of a different name (“Movie”). This is something we’ve started to stress in training as many students have thought REST means they need to match controller names to models (probably because they’ve seen scaffold generation).

TDD will guide you to better habits

Use Role Suggesting Name for the test name, variable names, and method under test to describe the behavior of Movie.recommended_for.

class MovieTest < ActiveSupport::TestCase
  should "recommend 2 highest ranked, in stock movies unwatched by user" do
    user    = Factory(:user)
    top_out = Factory(:movie, :ranking => 100, :in_stock => false)
    top_in  = Factory(:movie, :ranking => 95,  :in_stock => true)
    next_in = Factory(:movie, :ranking => 90,  :in_stock => true)
    watched = Factory(:movie, :ranking => 100, :in_stock => true)
    Factory(:viewing, :user => user, :movie => watched)

    assert_equal [top_in, next_in], Movie.recommended_for(user, 2)
  end
end

This is a state-based test. We create a user and a few movies, have him or her watch a movie, exercise the method, and verify the results match the test name.

Skipping ahead again, say we’ve gone through a few red, green, refactor cycles, taking into account some edge cases, and the implementation now looks like this:

class Movie < ActiveRecord::Base
  def self.recommended_for(user, limit = 10)
    highest_ranked.in_stock.unwatched(user).limited(limit)
  end

  private

  named_scope :highest_ranked, :order => "ranking desc"
  named_scope :in_stock, :conditions => { :in_stock => true }
  named_scope :unwatched, lambda { |user|
    { :joins      => "left outer join viewings
                                   on viewings.movie_id = movies.id
                                  and viewings.user_id  = #{user.id}
                      left outer join users
                                   on users.id = viewings.id",
      :conditions => "users.id is null" }
  }
end

Cool, named_scopes helped us make the recommended_for method expressive. If the specification for it changes, it will be a joy to change.

No tests for the private methods

We’ll test those private methods like this.

If an object outside of Movie needs highest_ranked or one of the other private methods, we’ll write a unit test for it, watch it error, and bring it into a public scope piece by piece.

Discarded option: should_have_named_scope

About a year ago, should_have_named_scope was introduced to Shoulda.

It was later deprecated. We never felt comfortable using it. While there’s something to be said for quick Shoulda one-liners, I don’t think there’s much of an argument for should_have_named_scope except for simple scopes that are responsible for order or limit.

Since those are usually taken care of by something like utility_scopes or Pacecar (and thus do not need to be unit tested) OR are often relegated to private status, that doesn’t leave a niche for should_have_named_scope.

If you’re still a should_have_named_scope fan, please write a test for unwatched using it. I’ll be surprised if it stands up to peer review.

Discarded option: stub_chain

Another option I’ve been using this summer, but have recently rejected is stub_chain.

module StubChainMocha
  module Object
    def stub_chain(*methods)
      while methods.length > 1 do
        stubs(methods.shift).returns(self)
      end
      stubs(methods.shift)
    end
  end
end
Object.send(:include, StubChainMocha::Object)

This approach unit tests each of the named scopes and then stub_chains the class method:

should "find 10 highest ranked movies in stock that you have not seen" do
  user = Factory(:user)
  Movie.stub_chain(:highest_ranked, :in_stock, :unwatched, :limited)

  Movie.recommended_for(user)

  assert_received(Movie, :highest_ranked)
  assert_received(Movie, :in_stock)
  assert_received(Movie, :unwatched) { |expect| expect.with(user) }
  assert_received(Movie, :limited)   { |expect| expect.with(10) }
end

This is easy to understand, but very tied to implementation, does not test the “integration” of the scopes (dangerous in many situations when the resulting SQL is not combined as expected), and stubs out methods on the same object (usually a smell that something needs to be refactored).

My suggested approach may often be more lines of code, but will better describe the behavior.

No chains in controllers

Some of us have started to use a rule of thumb of “no chains in controllers”. This makes the testing decisions easier, and makes the model’s public interfaces and public/private interface distinction cleaner. The end result is usually a class method that wraps (potentially private) named scopes.

Success story: Big Room consulting

Tue, 22 Sep 2009 15:33:00 -0400

We like to spotlight our thoughtbot training students’ work.

Big Room

In this installment, we’re checking in with Mike Breen, a local Bostonian. Mike took one of our very first Boston classes.

Since last year, he has been doing Rails consulting as an owner of Big Room Technology.

Since last October I launched a family of products for SEAK.com: Directory of Expert Witnesses, Directory of Independent Medical Examiners, and Directory of File Review Consultants,

… converted multiple ol’ school ASP apps to a single Rails app,

… helped launch IAC-EZ with Lark Farm, Inc.,

… worked with Auburn Quad and now I’m working on their non-profit wing Grassroots Giving Group,

… and helping out with the RailsBridge. I lead up the Builders. We help non-profits build or rehab Rails sites. [thoughtbot developer] Jason Morrison and the Personal Genome Project signed up recently.

Rails is a productivity enhancer

As if that wasn’t enough, Mike also volunteered his time to run the inaugural Rails BugMash, which saw over 300 commits to Rails.

The next BugMash is this weekend, September 25th-27th.

Our own Tristan “Bucky” Dunn finished in the top 5 last time around. You can mash more bugs than Bucky, can’t you?

Training

We’re always pleased to see the great work that our alumni have produced.

We think you can strengthen your TDD with Rails skills through hands-on workshops in an intimate setting with thoughtbot developers.

Early Bird tickets are now available for October and December classes.

Previous spotlights on our students’ work include open source libraries Klang & strongbox and beautifully designed Rails app (with 100% test coverage!) yiloveit.

Role Suggesting Name

Fri, 18 Sep 2009 14:03:38 -0400

There’s an excellent discussion on Josh’s “self” post last week. In it, I argued:

in my opinion, naming classes, methods, and variables expressively should be the #1 goal of a programmer when writing or refactoring code.

How to write great names

The path to great naming involves a few simple rules.

You can often deduce the scope and type of a variable.

The one thing you can’t deduce from a variable is its role, or purpose, it plays in the application.

Example

The following is something I wrote today.

Let’s consider a CreditCard class:

class CreditCard < ActiveRecord::Base
  belongs_to :brand_manager, :class_name => "User"
end

class User < ActiveRecord::Base
  has_many :credit_cards, :foreign_key => "brand_manager_id"
end

Why

Context.

What reads better to you when you use these objects?

This…

user.credit_cards
credit_card.user

… or this?

brand_manager.credit_cards
credit_card.brand_manager

“User” is too generic. In the real world, credit cards don’t have users.

In the domain-specific language of this application, the people are referred to as “brand managers”.

Why not just name the model BrandManager?

In this case, User is overloaded to handle three different roles using simple flags on the model. This allows us to use Clearance normally and keeps authentication and standard user vocabulary available where it makes sense.

Another example

class Impression < ActiveRecord::Base
  belongs_to :campaign, :class_name => "Offer"
end

From the same application, we again see a case where the object in question plays two different roles depending on to whom it is being displayed. The object is a campaign to advertisers and offer to recipients.

From the perspective of impressions, the Role Suggesting Name is campaign.

Reveal refactoring opportunities

In this second example, we now intend to rename the Offer model Campaign.

We were undecided which name would be dominant in the app when we first wrote the model but as we’ve written new features, using Role Suggesting Name has dictated that the model should be renamed as there is only one place where offer makes sense.

By caring about naming as we’ve gone, that eventual refactoring will be painless as we have less code to change. We did not let ourselves feel restricted by original name, and let context and purpose drive naming.

100% stolen from studying the masters

I first heard of this idiom in Smalltalk Best Practice Patterns by Kent Beck.

I heard it applied to a similar use case in Philippe Hanrigou’s talk, What the Ruby craftsman can learn from the Smalltalk master.

There’s a lot more to great naming but I can’t say it any better than those guys, so watch Philippe’s talk and read the book.

swallow nil

Fri, 18 Sep 2009 08:02:00 -0400

I’ve been using this for about a year and a half.

Abomination or legitimate tool for the box?

Usage

two dots or more. nil anywhere in the chain is an acceptable response.

campaign = swallow_nil { supporter.politician.campaign }

Definition

def swallow_nil
  yield
rescue NoMethodError
  nil
end

try()

It’s similar to try from ActiveSupport except for chains instead of individual methods.

Law of Demeter

Are you strict about Law of Demeter violations?

Or, do you find yourself with occasional chains like this that could benefit from swallow_nil() or try() or andand()?

How to Ruin a jQuery Plug-in: Markup

Thu, 17 Sep 2009 15:03:20 -0400

jQuery is one of my favorite libraries, in any language. And one of the greatest advantages of using jQuery is the abundance of third-party plug-ins available. Just about anything you need to do has probably already been done and extracted into a plug-in. That being said there are ways I feel you can completely ruin a jQuery plug-in.

Generating or expecting specific markup.

Recently I needed a content slider for an existing homepage design. The first promising plug-in I found generated the navigation for you, so it was out the door. Several others expected very specific markup and made it difficult to customize. Eventually I found one that at least allowed me to customize the selectors and even though it still expected

elements I managed to easily modify it to work.

Proposed Solution

If you are going to generate markup from your plug-in, make it customizable. It is trivial to add another string to your default options and makes it a lot easier to find. If you need to act on the markup, which you will, then base it on an ID, or class names, and not elements.

Example Plug-in

Here’s a very basic plug-in to give you an idea what I am talking about.

(function($) {
  $.fn.awesomeMagic = function(options) {
    // Overwrite the defaults with any provided options.
    options = $.extend(true, {}, $.fn.awesomeMagic.defaults, options || {});

    return $(this).each(function() {
      // Append the markup.
      $(this).append(options.html);

      // Grab the elements needed.
      var hat    = $(this).find('.awesome-magic-hat');
      var rabbit = $(this).find('.awesome-magic-rabbit');

      // Perform awesome magic here.
    });
  };

  $.fn.awesomeMagic.defaults = {
    wand : true,
    html : '\
     \
       \
        Rabbit goes here. \
       \
    '
  };
})(jQuery);

Plug-in Usage

$('#content').awesomeMagic({
  html : '\
    Rabbit goes here. \
    '
});

How do you handle custom or expected mark up in your plug-ins? What are other ways you feel a plug-in can be ruined?

tiniest of tips

Wed, 16 Sep 2009 17:14:47 -0400

Every time you find yourself typing something long and repetitive, automate it. Every time.

I often hop into script/console, so aliasing that is a no-brainer. That is not the point of this post, though; I also often look up my current user when I’m in script/console, and I get tired of typing my email address every time. Add a method into your ~/.irbrc to make that painless, too.

[~/dev/railsapp] alias sc
sc=script/console

[~/dev/railsapp] tail -n 3 ~/.irbrc
def me
  User.find_by_email 'jmorrison@thoughtbot.com'
end

[~/dev/railsapp] sc
Loading development environment (Rails 2.3.3)

>> me
  SQL (0.2ms)   SET NAMES 'utf8'
  SQL (0.1ms)   SET SQL_AUTO_IS_NULL=0
  User Columns (2.7ms)   SHOW FIELDS FROM `users`
  User Load (60.1ms)   SELECT * FROM `users` WHERE (`users`.`email` = 'jmorrison@thoughtbot.com') LIMIT 1
=> #

Five Ridiculously Awesome Cucumber (and Webrat) Features

Wed, 16 Sep 2009 11:05:16 -0400

Cucumber, if you haven’t heard, is the Next Big Thing™. It affords developers the ability to write human-readable integration tests. Even though it’s only at version 0.3.101, it’s full-featured with a handful of hidden gems. Here are five of my favorites.

Running Targeted Features with Cucumber Profiles

In a Rails application, if a RAILS_ROOT/cucumber.yml file is present, you can store named Cucumber profiles. This becomes handy if you’re running your features in different environments (e.g. Selenium or a simulated browser).

Here’s an example cucumber.yml file:

default: --format pretty -r features/support/env.rb -r features/support/plain.rb -r features/step_definitions features
selenium: -r features/support/env.rb -r features/support/selenium.rb -r features/step_definitions features
html_output: --format html -r features/support/env.rb -r features/support/plain.rb -r features/step_definitions features

Within your terminal, you can run:

cucumber -p html_output

Tagging Scenarios

Another handy Cucumber feature is the ability to tag scenarios. Tagging a scenario is achieved by simply adding @tagname above the scenario definition, as such:

@tagname
Scenario: User is not signed up
  Given no user exists with an email of "email@person.com"
  When I go to the sign in page
  And I sign in as "email@person.com/password"
  Then I should see "Bad email or password"
  And I should not be signed in

To run scenarios with a specific tag:

cucumber --tags @tagname

To exclude scenarios with a certain tag, prefix the tag with a tilde:

cucumber --tags ~@wip

A common tag name that Cucumber supports out of the box is @wip (work in progress) and provides rake tasks to accommodate using this pattern:

rake cucumber:wip # runs only scenarios with a wip tag
rake cucumber:ok # runs all scenarios without a wip tag

One thing to note here is that Cucumber will exit with a status of 1 if your @wip-tagged scenarios pass (it’s a reminder that they’re not works in progress anymore since they pass).

Assigning Data with Tables

Cucumber supports the use of tables, which can be handy for any number of things; my favorite uses are populating fields in a form and instantiating an ActiveRecord object with values defined.

Webrat gives us a step definition for filling in form fields (within features/step_definitions/webrat_steps.rb) and can be used as such:

When I fill in the following:
  | First Name            | John                 |
  | Last Name             | Doe                  |
  | Email                 | john.doe@example.com |
  | Password              | password             |
  | Password Confirmation | password             |

With an ActiveRecord object and FactoryGirl:

# step
Given a customer exists with the following attributes:
  | Name      | Huge Local Company |
  | Code      | HLC                |

# step definition
Factory.factories.each do |name, factory|
  Given /^an? #{name} exists with the following attributes:$/ do |attrs_table|
    attrs = {}
    attrs_table.raw.each do |(attr, value)|
      sanitized_attr = attr.gsub(/\s+/, "-").underscore
      attrs[sanitized_attr.to_sym] = value
    end
    Factory(name, attrs)
  end
end

Segregating Selenium and Simulated Browser Steps

If you’ve been ambitious enough to get your features running with Selenium, you already know that doing so can add a significant amount of time to your tests. Webrat is kind enough to provide you execution blocks that run in specific modes, which makes for some snappier tests when you do run features with Webrat.

For example, within a step that outlines signing in:

webrat.automate do
  When %{I sign in as "#{email}/#{password}"}
end

webrat.simulate do
  visit "/session",
        :post,
        :session => {:email => email, :password => password}
end

Webrat will determine if you’re simulating a browser and execute webrat.simulate if that’s the case; otherwise, it’ll run the code within the webrat.automate block. This can be really helpful if you’re testing the ability to delete an item (especially if there’s a confirmation dialog).

Displaying Page Responses within a Scenario

If you’re having trouble getting a feature to pass and want to view the page, you can add in a step to have it save the result HTML and open the page in your default browser.

Scenario: User is not signed up
  Given no user exists with an email of "email@person.com"
  When I go to the sign in page
  Then show me the page # saves the HTML of that page and opens the file
  And I sign in as "email@person.com/password"
  Then I should see "Bad email or password"
  And I should be signed out
  Then show me the page # more HTML output

This tends to be much more convenient than adding this into your step definition:

puts response.body.inspect

There are, as always, a couple of caveats. The HTML it generates won’t be relative to your public folder so Javascript and CSS probably won’t load correctly. It also doesn’t persist form values, so if you run it after a step like ‘I fill in “field” with “value”’, it won’t keep that data. It also creates a timestamped html file within your RAILS_ROOT folder. A simple fix to ensure this doesn’t get committed with git would be to add the following line to your .gitignore file in the project:

webrat-*.html

Finally…

Don’t forget to read the docs! They cover everything you’d ever want to know about Cucumber and how to use it effectively. I’ve listed only a handful of awesome features Cucumber and Webrat have to offer, but each has helped me in one way or another over the course of the past year. Hopefully they’ll be as much use to you as they were me.

To self. or not to self.

Fri, 11 Sep 2009 15:24:41 -0400

Off with his head!

Ruby developers have gone back and forth for ages as to whether to use self. on their method calls. Why is everyone bickering? Can’t we all just get along?

My guess is that we can’t.

This argument is similar to that of the use of whitespace. Some people are picky while others are not; however, almost all have a very strong opinion.

This above all: to thine own self be true

I prefer to qualify all public instance method calls with self.. I’m one to lean towards being explicit versus implicit, and self. helps me achieve this goal. This also makes coworkers (or any other individual reading the code) aware of whether the method call is an attribute defined by ActiveRecord or a public instance method on the class. The reason this is an issue is because local or block-level variables will never be prefixed with self. - it’s much easier on the eyes to be able to tell immediately whether you’re dealing with one or the other.

Tempt not a desperate man

The explicitness of self. may be construed as line noise. You may also be asked why you don’t use Hungarian notation. Using self. isn’t a naming convention; it’s defining the receiver of the message explicitly. There’s no misconception and you’re relaying intent very plainly by adding five characters.

This is the long and short of it

class User < ActiveRecord::Base
  before_save :sanitize_names

  def display_name
    return email if first_name.blank?
    [first_name, last_name].compact.join(" ")
  end

  protected

  def sanitize_names
    self.first_name = nil if first_name.blank?
    self.last_name = nil if last_name.blank?
  end
end

The result, after everything is said and done, would be:

class User < ActiveRecord::Base
  before_save :sanitize_names

  def display_name
    return self.email if self.first_name.blank?
    [self.first_name, self.last_name].compact.join(" ")
  end

  protected

  def sanitize_names
    self.first_name = nil if self.first_name.blank?
    self.last_name = nil if self.last_name.blank?
  end
end

Although there may not me much of a different to the casual reader, the second is, in my mind, worlds easier to comprehend.

Zsh completion for your tests and specs

Fri, 11 Sep 2009 08:00:10 -0400

Got zsh? Loving your TATFT but tired of typing out all those spec commands?

spec -cfs spec/controllers/application_controller_spec.rb

or test commands?

ruby -Itest test/functionals/admin/users_controller_test.rb

Well, put away that keyboard oil, because you’ll be saving keystrokes left and right!

[~/dev/railsapp] $ spc a
admin/base_controller    application_controller  arrr_pirates_controller

[~/dev/railsapp] $ spc app
admin/base_controller    application_controller  arrr_pirates_controller

[~/dev/railsapp] $ spc application_controller
admin/base_controller    application_controller  arrr_pirates_controller

spec -cfs spec/controllers/application_controller_spec.rb # ta-da!

You can also complete multiple tests or specs in one line. Download the scripts and find out more in the zsh-rails-test-spec-shortcuts repository.

“I’m so tired of typing ruby -Itest test/… I’m so glad I installed the zsh completion scripts. I’ll spend all my saved energy on eating campsites and writing solid code!”

Bonus links

As a bonus, here’s a reminder of an oldie but a goodie, rake task completion for zsh: http://weblog.rubyonrails.org/2006/3/9/fast-rake-task-completion-for-zsh

And a recent one from the rubygems-developers list, for gem command completion for zsh: http://rubyforge.org/pipermail/rubygems-developers/2009-August/004860.html

What about you?

What’s your favorite time saving alias, script, or shell completion? Let us know in the comments!

Quacking like an ActiveRecord in Rails 2.3.4

Thu, 10 Sep 2009 14:34:46 -0400

You know everything about pretending to be an ActiveRecord::Base object, and especially the bit about ActiveRecord::Errors. That part’s really cool.

What we are doing here is making an object that quacks like an ActiveRecord::Base object but has no database table backing it. As examples: a search object, a credit card object, or a remote user object. To do this, you need id, new_record?, and the attributes must work in a specific fashion. You can also have errors produce an ActiveRecord::Errors instance so user errors will show in forms and whatnot.

However you may not have noticed that Rails 2.3.4 broke API compatibility for ActiveRecord::Errors. If your ActiveRecord::Base-like class provides an #errors instance method, it must now provide these class methods:

self_and_descendants_from_active_record, which produces an array of classes.
human_name, which takes an optional hash and produces a string.
human_attribute_name, which takes a string and optional hash and produces a string.

The last two of these methods are useful in your day-to-day Rails knowledge (the first is an internal, undocumented method used by Rails to produce the class itself and its parents, up to and excluding ActiveRecord::Base).

human_name is used to produce a humanized string representing the class/table name. If your class is named AuthenticationRecord, .human_name will produce "Authenticationrecord". Any options you pass to this are normally sent to I18n.translate.

human_attribute_name is used to map an attribute to a human-readable string. For example, the attribute created_at is mapped to "Created at". Any options passed to this are normally sent to I18n.translate.

Here are some tests that need to pass now:

class SearchTest < ActiveSupport::TestCase
  should "conform to the ActiveRecord::Errors interface" do
    assert_respond_to Search, :self_and_descendants_from_active_record
    assert_respond_to Search, :human_name
    assert_respond_to Search, :human_attribute_name

    assert_equal [Search], Search.self_and_descendants_from_active_record
    assert_equal "Search", Search.human_name
    assert_equal "Published at", Search.human_attribute_name('published_at')
  end
end