Ruby Fu

Here's a quick case study where we got bit by ActiveRecord's use of a Transparent Proxy, namely ActiveRecord::Associations::BelongsToAssociation.

If you don't plan on reading this article, at least walk away with this:
"Don't EVER use the word 'target' for any attribute, association, or method on any of your ActiveRecord models!!!"

Why? Here's a quick example.

Consider this migration:

class CreateTables < ActiveRecord::Migration
  def self.up
    create_table :missiles do |t|
      t.column :name,    :string
      t.column :silo_id, :integer
    end
    create_table :silos do |t|
      t.column :name,   :string
      t.column :target, :string
    end
  end

  def self.down
    drop_table :missiles
    drop_table :silos
  end
end

Now consider these two models:

class Missile < ActiveRecord::Base
  belongs_to :silo
end

class Silo < ActiveRecord::Base
  has_many :missiles
end

We have a Missile model which belongs_to a Silo, and a Silo can point to a 'target'. Lets create our Missile and Silo objects and see what happens...

>> the_tube = Silo.create(:name => 'The Tube', :target => 'Washington, DC')
=> #<Silo:0x2855d8c>
>> boomer = Missile.create(:name => 'Boomer', :silo => the_tube)
=> #<Missile:0x27904c4>
>> silo.target
=> "Washingon, DC"

# okay, lets fire our missile at the target
# boomer launches and calls home to get its
# targeting information...

>> boomer.silo.target
=> #<Silo:0x2855d8c>

# wtf?  its pointed at a silo?

>> boomer.silo.target == 'Washington, DC'
=> false

>> boomer.silo.target == the_tube
=> true

# RUN!!!!

Did you catch that? Our Missile, 'Boomer', says that its silo, 'The Tube', is NOT targeting at 'Washington, DC' like we asked it to! It's targeting itself!!!

WHY!?!

Well the reason for this has to do with the *magic* behind ActiveRecord's BelongsToAssociation class, which defines a 'Transparent Proxy' object. I posted a little about these before: Transparent Proxies, Part 1.

What's going on is that when we accessed the silo association on our instance variable boomer, what we *actually* get back is an instance of the ActiveRecord::Associations::BelongsToProxy class. It's such a neat proxy, you probably never realized that you were dealing with it, because when you have one, you can't tell by looking at it that you don't just have an instance of the Silo class we defined.

So where does 'target' come in to play? Well, it turns out that the BelongsToProxy isn't completely *Transparent*, it does have some methods defined, one of which happens to be target. And in the case of Silos and Missiles, this is unfortunately a reference to the object referenced in the belongs_to association!

Fortunately for Washington, DC, this attack has been averted. Unfortunately for this web developer, its time to redefine this model's schema. But with just a little refactoring, the next Missile will find its mark!

Labels: ActiveRecord, AssociationProxy, Associations, belongs_to, BelongsToAssociation, target, transparent proxies

Tonight at the Chicago Area Ruby Meetup (CHIRB), we had some lightning-round presentations, and without too much preparation I decided to release and demo some code I had written for dealing with Regular Expressions.

The library in essence allows you to use the totally under-utilized embedded-comment faculty in Ruby's Regular Expression Extensions to label your captures.

For those who don't know, a comment in a Ruby Regexp looks like (?#this), so if you want to label a capture, you can embed comments in the parentheses for that capture, like this: /((?#number)\d+)-((?#word)\w+)/.

Of course that doesn't buy you anything on its own, so I wrote a library called 'named_captures.rb' available in my public svn repository here.

With this library, you can now use that Regexp above like so:

my_regexp = /((?#number)\d+)-((?#word)\w+)/
my_match = my_regexp.match("i got 128-bit encryption!")
my_match[:number] # <= '128'
my_match[:word]   # <= 'bit'

Feel free to explore and send me email if you use this at brendan@usergenic.com. Comments on this post welcome as well.

Labels: named_captures.rb, regexp, regular expressions

You should understand this...

a=[:x,:y,:z] # => [:x, :y, :z]
a.map{|a|}   # => [nil, nil, nil]
a            # => :z

...to know why this routes.rb example using with_options...

map.with_options :controller => 'users',
                 :action => 'show' do |map|
  map.user_groups  '/users/:id/groups',  :section => 'groups'
  map.user_history '/users/:id/history', :section => 'history'
end

...is bad.

Don't reuse the name of a local variable as a yielded local variable for use inside of a block, because the assignment will persist after the lifespan of the block. The routes example should look more like this...

map.with_options :controller => 'users',
                 :action => 'show' do |users|
  users.user_groups  '/users/:id/groups',  :section => 'groups'
  users.user_history '/users/:id/history', :section => 'history'
end

That is all.

Labels: block, routes, ruby, with_options

The super keyword is pretty sweet. It remembers the context under which it was used, even when you call an alias of the containing method. Example:

class X
  def method
    "got it"
  end
end
class Y < X
  def method
    "#{super}!"
  end
end
class Z < Y
  alias_method :original_method, :method
  def method
    "you #{original_method}"
  end
end

X.new.method # <= "got it"
Y.new.method # <= "got it!"
Z.new.method # <= "you got it!"

This behavior gives alias_method real flexibility when used to modify behaviors by composing method chains to pre-defined methods. I was first surprised by this behavior, but it was a pleasant surprise as it meant I didn't have to worry about 'super' suddenly referring to something else when delegating to aliased methods.

Labels: class, inheritance, method, ruby, super

This is an old one, but I tightened up the code a little bit. Take a look at the following:

module Enumerable
  def all
    MapProxy.new self
  end
end
class Enumerable::MapProxy
  instance_methods.each do |m|
    undef_method m unless m.to_s=~/^__(id|send)__$/
  end
  private
  def initialize proxied
    @proxied=proxied
  end
  def method_missing m,*a,&b
    @proxied.map{|o|o.__send__ m, *a, &b} # thanks, NiKA
  end
end

Basically it lets you write [1,2,3].all.to_s and get back ["1","2","3"]. It does so by creating an instance of the Enumerable::MapProxy class that dispatches any method you send it right on down to each element of the Enumerable object (an Array in the case of [1,2,3]). It's called MapProxy because it dispatches the method to each element by way of the #map method.

Its pretty convenient for some kinds of operations, but there's a downside to using Transparent Proxies-- I call them "Transparent" because as far as you can tell when you interact with it, it doesn't actually identify itself in the traditional way. If you say [1,2,3].all.class you don't get back a class, you get an Array of classes, which are the classes of the elements in the collection.

The downside therefore is that you get this object with extremely interesting behaviour, but don't really know what's going on unless you can figure out where the object came from.

If you use Rails, you already use Transparent Proxies, since the AssociationProxy class in the ActiveRecord::Associations module is a well-known example of one. In many ways the effect is seamless and great, but it can be the cause of some pretty bizarre behaviour, especially in light of the way it chooses to direct method_missing calls back down to the class the association represents.

For example, did you know that if you have a belongs_to :customer association on your Order class, that @order.belongs_to actually returns an instance of the AssociationProxy class?

If you are ever stuck with an object that you "think" might be an instance of a specific Transparent Proxy class, here is a handy way to find out:

class Class
  def one_of_me? object
    ObjectSpace.each_object(self) do |o|
      return true if o.__id__==object.__id__
    end
    return false
  end
end

# to demonstrate...

Enumerable::MapProxy.
  one_of_me?([1,2,3].all) #<= true

ActiveRecord::Associations::AssociationProxy.
  one_of_me?(@order.customer) #<= true

Labels: method_missing, ObjectSpace, ruby, transparent proxies

Greetings, programs!

My name is Brendan Baldwin and this is the inaugural post of RubyFu.com, a weblog dedicated to Ruby development. I'm starting this on a shared hosting account with limited headspace, so I'm opting for static file delivery, published via Blogger.com. As such, I'm not quite sure how things like comment moderation and permissions are going to work, so this is a test post. Feel free to contact me with any issues you encounter with this weblog at brendan at ruby fu dot com.

End of line.