Secondly, even if you don't need object graphs, Machinery can speed up your tests significantly because you can set up any model objects in a before(:all) instead of a before(:each), and at the end of the tests all activerecord objects created in the before(:all) will be cleaned up automatically.

Usage

In /spec/scenarios.rb

Machinery.define do
  scenario :earth_ships do
    @titanic = Ship.create!(:name => "Titanic")
    @pirate  = Ship.create!(:name => "Pirate")
  end

  scenario :space_ships do
    @apollo = Ship.create!(:name => "Apollo")
    @uss_enterprise = Ship.create!(:name => "USS Enterprise")
  end

  scenario :all_ships do
    scenarios :earth_ships, :space_ships
    @sunken_ship = Ship.create!(:name => "Sunk")
  end
end

In /spec/spec_helper.rb

require 'machinery'
require File.join(File.dirname(__FILE__) + 'scenarios')

In /spec/models/ship_spec.rb

describe Ship do
  scenarios :all_ships

  it "should create a pirate ship" do
    @pirate.should_not be_nil
  end

  it "should have 5 ships" do
    Ship.count.should == 5
  end
end

If it's only speeding up your tests you're after you can use anonymous scenarios, like this:

In /spec/models/ship_spec.rb

describe Ship do
  scenario do
    @pirate = Ship.create!(:name => "Pirate")
  end

  it "should update a pirate ship" do
    @pirate.name = "Updated Pirate"
    @pirate.save
    @pirate.reload
    @pirate.name.should == "Updated Pirate"
  end

  it "should have 1 ship" do
    Ship.count.should == 1
  end

  it "should be named 'Pirate'" do
    @pirate.name.should == "Pirate"
  end
end

This will create one ship only in the database.

Get it

For more info see http://github.com/lawrencepit/machinery.

Usage:

    it { should have_attached_file :avatar, :styles => { :ico => "16x16", :normal => "48x48" } }
    it { should validate_attachment_presence :avatar }
    it { should validate_attachment_size :avatar, :less_than => 1.megabyte }
    it { should validate_attachment_content_type :avatar, :allows => ["image/png", "image/jpg"], :rejects => ["video/mpeg"] }

Source: remarkable_paperclip.

This week Tim Lucas gave a preso at a ruby-on-rails meetup in Sydney presenting what he calls "view-first validations". I couldn't attend the meetup, but a gist was send around: http://gist.github.com/107555.

I thought the idea presented could be put to good use to solve the i18n issues that face ARs validate_* methods. And so I came up with a slight variation http://gist.github.com/108497 which using the gettext API to do the translations (but you could use I18n.t instead of course) and doesn't require the explicit use of the :message option for every call to the validate_* methods.

There are various reasons why I like this way of dealing with the validate_* messages:

1. The actual translation of the validate_* message can be deferred to the view level, which is a more proper place imho.
2. If you use the gettext API for translations then this way of working prevents having possible markup data in your models because sometimes a bit of markup may be needed in a translation string.
3. No need for complicated lambda messages.
4. It makes testing of models easier and clean again as you test against symbols in the errors array instead of testing against possibly translated messages.

Almost a year back now, I saw the try() method suggested. The intention of the method is to guard you against calling methods on a nil object. If you try to call a method on a nil object it should return nil, otherwise it should call the method. Here's the implementation:

class Object
  ##
  #   @person ? @person.name : nil
  # vs
  #   @person.try(:name)
  def try(method)
    send method if respond_to? method
  end
end

The implementation is a one liner. Nothing to get excited about, looks simple enough, what could be wrong? And so I've been happily using try's sparsely in my code ever since, and with me I suspect a lot of others, and was a happy camper.

But then today I started to write a few unit tests for that core extension. Hardly looked like it warranted unit tests, but for consistency sake in unit testing my apps core extensions I did it anyways. I created these 4 tests:

test "succeed when trying method" do
  "hello".try(:length).should == 5
end

test "fail when trying method" do
  assert_raises(NoMethodError) { "hello".try(:does_not_exist) }
end

test "not fail when trying method" do
  nil.try(:does_not_exist).should == nil
end

test "return nil when calling any method on nil" do
  nil.try(:to_s).should == nil
end

And so there we had it: 2 out of the 4 tests failed. Excuse me?!

So I took a closer look at this seemingly innocent little method. Apparently there are some pitfalls. For example:

>> "hello".try(:does_not_exist)
=> nil

While I expect nil.try(:does_not_exist) to return nil, I certainly do not expect nil when the receiver object is not nil. I expected a NoMethodError. Obviously, I'd say. How about this one:

>> nil.try(:to_s)
=> ""

I do expect nil.to_s to return an empty string, but not here. The intention is to be guarded against nil, and only if the receiver object is not nil should the method be called.

There is another pitfall, which I haven't created a test for, but something you might want to be aware of. If a class implements methods through a method_missing method then try might not recognize a valid method call because respond_to? will return false, and therefor try will return nil instead of the value that method_missing would return.

All pesky little details, but they could have gnarly consequences.

So I had a look around the internetz, and came across this. Don't like the ability to provide a default, instead of person.try(:name, :default => default) I'd rather do the usual person.try(:name) || default. Do like that you can do user.try(:manager, :name) instead of having to do user.try(:manager).try(:name). My example however immediately points out a flaw in it's implementation: if user.manager returns nil then the receiver object doesn't get changed and in the next iteration of the loop it returns the value of user.name. Easy to fix of course, so let's keep this feature in mind.

Then I came across a few other alternatives that were entertaining the idea of using method_missing, but let's not..

So maybe it's turtles to the rescue! Well, the author considers the code dumb, and I think he's right Still, an entertaining idea.

And so I ended up at the door steps of the Master Guardian of Ruby Land: Ragan Wald. In his last blog post from summer last year he claims he's retired from hacking on Ruby. But nothing is further from the truth. This guy is continuously rethinking how to protect his code with his various slave guards, otherwise known as his little monads doing his dirty washings. He has even come up with some new slaves in the form of Rewrite and a few days ago with RewriteRails. See also his rather obscurely located 'blog post' announcement about this. It does appear like he is on to something very dangerous! Definitely worthwhile to keep an eye on.

Meanwhile, I'm thinking in more simple terms. I just want a very simple implementation of try with no fuss. After downloading more of the internetz I found one other person who argues that the try method isn't doing what it says it's doing. He came up with this instead:

class Object
  ##
  #   @person.name unless @person.nil?
  # vs
  #   @person.try(:name)
  def try(method)
    self.send(method) unless self.nil?
  end
end

Let's run this through the tests, see what happens:

4 tests, 4 assertions, 0 failures, 0 errors

Now that's what I'm talking about! This is the implementation that I'll use. For now. I'll accept the danger that anyone might actually contribute a different try method in some class.

UPDATE: And then I read this: And I for one welcome our new insect overlords.

Dear me! The try method has been added to rails 2.3/3.0 last month.

How wrong could I be when just a few minutes ago I wrote, with apparent misplaced confidence, that I'd accept the danger of anyone actually contributing a different try method. They might as well deliver me over to the mad doctor of blood island right now! No point in postponing the horrors that are my fate.

Incidentally, 3 days ago tap has been added to rails as well. But let's stay with try here for the moment. What is it's implementation?

# Tries to send the method only if object responds to it. Return +nil+ otherwise.
# It will also forward any arguments and/or block like Object#send does.
#
# ==== Example :
#
# # Without try
# @person ? @person.name : nil
#
# With try
# @person.try(:name)
#
# # try also accepts arguments/blocks for the method it is trying
# Person.try(:find, 1)
# @people.try(:map) {|p| p.name}
def try(method, *args, &block)
  send(method, *args, &block) if respond_to?(method, true)
end

There you go. Even worse. Allowings arguments and a block, and bypassing the privacy security of your methods! It's like the IRS: they come in whenever they like and they take whatever they like. Sure, ruby is open, so if anyone wanted to break into my object and pry around my private stuff, fine, but do we have to promote that kind of behaviour?

No Mr Horse, I think this should be kidnapped, drugged, and chained deep down a mine shaft behind the bras of any Coober Pedy resident, preferably of those with long dusty zz-top beards.

(disclaimer, before anyone gets upset by my suggestion: I generally do not condone hiding things behind bras. Ever.)

The other issue remains: the example is misleading. Consider this instead:

# # Without try
#  x ? x.to_i : nil
#
# With try
# x.try(:to_i)

When x = 123 you get 123, when x = nil you get 0 with try, nil without try.

Which tests were written? :

class ObjectTryTest < Test::Unit::TestCase
  def setup
    @string = "Hello"
  end

  def test_nonexisting_method
    method = :undefined_method
    assert !@string.respond_to?(method)
    assert_nil @string.try(method)
  end

  def test_valid_method
    assert_equal 5, @string.try(:size)
  end

  def test_valid_private_method
    class << @string
      private :size
    end

    assert_equal 5, @string.try(:size)
  end

  def test_argument_forwarding
    assert_equal 'Hey', @string.try(:sub, 'llo', 'y')
  end

  def test_block_forwarding
    assert_equal 'Hey', @string.try(:sub, 'llo') { |match| 'y' }
  end
end

Okay, so again, why would anyone want to try an :undefined_method on a non-nil receiver? Doesn't make sense to me.

And for what purpose did the rails team add this try method? :

Clearly none whatsoever. Throughout the thousands of lines of code of rails it's used exactly once. No arguments, no block usage. So what's the point? Where's the value? Why do we get this?

I'd consider the reddit possibly more useful.

The past few days my interest in compilers has resurfaced. There's an itch to scratch, and this time I'm thinking about a serious compiler that should compete with erlang. Possibly by compiling into erlang bytecode like Reia does, or by leveraging some other existing VM platform such as Lua or Neko. Of course, grand ideas, when am I retiring again?

• Read _why's poetry tests in his new language potion. Fantastic commit messages!
• Read & played with Ragel. Classic writeup.
• Peeked the code of the hate promoting Utu platform. The design document is noice!
• Played some more with erlang.
• Read tons of stuff on compiler technologies.
• Browsed code of Lua, Neko VM and Reia implementations. Still wouldn't use any of them. But a lot can be learned from reading their code.
• Browsed the code of RabbitMQ, an impressively looking message queueing system on top of erlang OTP.
• Watching renewed developments in the functor gem: functional progamming based on pattern matching in ruby. Thinking of creating a version that is implemented by rewriting the AST of ruby.
• Dabbled with johnson, a javascript interpreter that runs within ruby. Want a headless browser with javascript support and support for the DOM and Ajax functions that runs on ruby (not jruby) to test the whole stack of my web apps easily. It should work by combining johnson with mechanize and env-js. Cucumber/Webrat combo isn't cutting it for me.
• Meanwhile submitting various patches to shoulda, and adding heaps of basic tests to a rails app using shoulda (macros only), factory_girl, sham with faker, matchy for rspec'ish BDD, pending and rr for using test doubles. I'm done with rspec, think it's too bloated, too slow. Like simply using expectations best when developing components/gems, not so much for testing the models, controllers or the whole stack of a webapp.
• Reread parts of the LISP documentation.
• Played with a simple distributed mapreduce function in ruby. Which incidently is currently broken because of this bug in ParseTree which doesn't seem to get any love.
• Dabbled a bit with the code of ruby2ruby.

... and then I went back to do some awfully mundane stuff. Like getting dressed and brushing my teeth.

After some initial hurdles I've come to be taken by DataMapper. It's nice, easy and fast to work with. The toughest thing to model in DataMapper though was a many-to-many self-referential graph. Others have attempted to solve this in various ways, but all seemed lacking to me. The documentation and specs are also still lacking somewhat at the moment, though good efforts are underway to improve this.

So the thing I wanted to model was a user that can friend many other users. On the user model I wanted an easy way to get to the friends of the user, and to get the users that have friended the user, all via datamapper associations.

Below is a solution that I think models this well in the database, and provides nice interfaces in a bi-directional fashion, providing datamapper collections to work with.

If this weren't a self-referential many-to-many relationship you don't need to be specific about the intermediate model. For example, you would simply do this:

class Article
  include DataMapper::Resource

  has n, :categories, :through => Resource
end

class Category
  include DataMapper::Resource

  has n, :articles, :through => Resource
end

The :through => Resource bit tells DataMapper that you're referring to another model through the anonymous Resource model. This will basically define a class ArticleCategory and a matching table articles_categories

However, due to the self-referential nature that we're looking at, we need to be specific about the intermediate model. Here are the models:

class User
  include DataMapper::Resource

  property :id, Serial
  property :name, String, :nullable => false

  has n, :friended_users
  has n, :friends, :through => :friended_users, :class_name => "User",
                   :child_key => [:user_id]
  has n, :friended_by, :through => :friended_users, :class_name => "User",
                       :remote_name => :user, :child_key => [:friend_id]
end

class FriendedUser
  include DataMapper::Resource

  property :user_id, Integer, :key => true
  property :friend_id, Integer, :key => true

  belongs_to :user, :child_key => [:user_id]
  belongs_to :friend, :class_name => "User", :child_key => [:friend_id]
end

Things to note:

• The FriendedUser model defines two integer properties explicitly and makes them the primary key. There is no need for an auto-generated (Serial) ID. Because of the primary key definition, uniqueness of the tuple (:user_id, :friend_id) is guaranteed and you get the indexes.
• The FriendedUser model belongs_to :user, referring to the User class. It maps into the property :user_id.
• The FriendedUser model belongs_to a :friend, referring to the User class. It maps into the property :friend_id.
• The User model has many :friended_users, refering to the FriendedUser class. Note that when you access this collection for a specific user it will join with the :user_id property of the FriendedUser model.
• It then defines the two associations :friends and :friended_by, through :friended_users. It must specify that what we'll expect to be returned are User instances. It also must specify the :child_key in FriendedUser to which this association should be linked. Lastly, for the :friended_by association you must specify the :remote_name, which refers to the belongs_to :user bit in FriendedUser. You don't need to (but can if you want to) specify :remote_name for the :friends association because datamapper will infer that it is referring to the belongs_to :friend bit in FriendedUser based on the association name :friends.

Let's test this:

DataMapper.auto_migrate!

jan = User.create(:name => 'Jan')
piet = User.create(:name => 'Piet')
klaas = User.create(:name => 'Klaas')
bo = User.create(:name => 'Bo')
fu1 = FriendedUser.create(:user => jan, :friend => piet)
fu2 = FriendedUser.create(:user => jan, :friend => klaas)
fu3 = FriendedUser.create(:user => bo, :friend => klaas)

# Output
p "-"*78
p bo.friended_users == [fu3]
p jan.friended_users == [fu1, fu2]
p jan.friends == [piet, klaas]
p klaas.friended_by == [jan, bo]

The resulting output:

~ CREATE TABLE "users" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "name" VARCHAR(50) NOT NULL)
~ CREATE TABLE "friended_users" ("user_id" INTEGER NOT NULL, "friend_id" INTEGER NOT NULL, PRIMARY KEY("user_id", "friend_id"))
~ INSERT INTO "users" ("name") VALUES ('Jan')
~ INSERT INTO "users" ("name") VALUES ('Piet')
~ INSERT INTO "users" ("name") VALUES ('Klaas')
~ INSERT INTO "users" ("name") VALUES ('Bo')
~ INSERT INTO "friended_users" ("user_id", "friend_id") VALUES (1, 2)
~ INSERT INTO "friended_users" ("user_id", "friend_id") VALUES (1, 3)
~ INSERT INTO "friended_users" ("user_id", "friend_id") VALUES (4, 3)
-----------------------------------------"
~ SELECT "user_id", "friend_id" FROM "friended_users" WHERE ("user_id" IN (4)) ORDER BY "user_id", "friend_id"

true

~ SELECT "user_id", "friend_id" FROM "friended_users" WHERE ("user_id" IN (1)) ORDER BY "user_id", "friend_id"

true

~ SELECT "users"."id", "users"."name" FROM "users" INNER JOIN "friended_users" ON ("users"."id" = "friended_users"."friend_id") WHERE ("friended_users"."user_id" = 1) GROUP BY "users"."id", "users"."name" ORDER BY "users"."id"

true

~ SELECT "users"."id", "users"."name" FROM "users" INNER JOIN "friended_users" ON ("users"."id" = "friended_users"."user_id") WHERE ("friended_users"."friend_id" = 3) GROUP BY "users"."id", "users"."name" ORDER BY "users"."id"

true

Lastly, note that instead of creating a friendship by calling FriendedUser.create you can also create a friend like this:

jan.friended_users.create(:friend => piet)