Inter-sections.net : Category ruby-rails, everything about ruby-rails

Rails sucks?

Thu, 10 Jan 2008 10:33:00 +0000

With astonishing regularity, articles or posts come out claiming that Rails sucks in some way or another. People complain that Rails isn’t as easy to deploy as PHP, that Rails just didn’t do it for project XYZ. They range from the articulate and well thought out to the frankly inane and stupid (and wrong). Recently, there’s also of course been the spectacular nuclear rant by Zed Shaw, which was more a rant against random elements of the community than against Rails, but was still presented as a rant against Rails.

These anti-rails rants come in so regularly, and have been doing so for so long, that some people even bothered to write pre-emptive rant responses, like the Six ground rules for rails sucks articles, written all the way back in 2006. RubyInside even has a Troll of the month category that will provide some fun reading.

Perhaps this means that this article is redundant. Oh well. It does get tedious after a while, to read all these rants, and I felt like writing my response to them too.

Why people say Rails sucks

There’s a large number of reasons why people come to the conclusion that Rails sucks. Here’s a by-no-means-exhaustive list:

It’s too slow
It’s not easy to deploy
It uses up a lot of RAM
It’s not as easy as PHP
It’s got weird syntax
The manual is too long
The manual is too short
The creator of Rails is arrogant and eccentric
It doesn’t work with my specific project
It doesn’t scale
It’s got this obscure problem that no one can be bothered to fix
It’s not thread-safe
etc…

What they all boil down to, in effect, is that some people get immensely irritated because Rails does not conform to their idea of perfection. They have some specific requirement that Rails doesn’t support, and they post rants about how “they” (the rails core team) owes them to adapt Rails to their requirements, or how “rails sucks” because it doesn’t do exactly what they need out of the box.

I’m sure you can see the obvious shortcoming of this approach, but let’s break it down, because there’s several aspects to this complaint which make it very, very wrong.

1. Rails owes you nothing

Rails is entirely free. You can run it on any OS you like. You can run it with a free DB or a paying one. You can rip out the bits you like and discard the rest. You can even make changes to it if you want (and with a plugin like Piston, you can keep your changes tracked even as Rails evolves and you update it to the latest edge revision).

No one in the Rails world owes you a thing. In fact, if you’re using Rails, you have a big debt to the Rails world. Most importantly, all of us using (or trying to use) Rails owe DHH a big one for being so kind as to share his framework with the rest of the world. Even if you decide that Rails is not for you, you still have to recognise the influence that Rails has had on web frameworks everywhere - and it’s a very positive influence.

The Rails core team also doesn’t owe you anything. They are all volunteers who work on it for free. You owe them.

So stop thinking that Rails owes you something. Rails owes you nothing. You owe Rails.

2. Rails isn’t perfect

There’s no such thing as a perfect web development framework. All of them (including Rails) suck in one way or another, once you use them for real stuff. There’s no such thing as a perfect language, either. All of them (including Ruby, Lisp, Python, haXe, Erlang, Lua, etc.) suck in some way. In fact, there’s no such thing as a perfect anything - whether in the world of computers or outside of it. Everything is imperfect. If you want perfect, then die. If the Christians are right, you might go to heaven and witness perfection. I wouldn’t bet my life on it though.

There’s a certain maturity in realising this, and it seems that most of the anti-Rails ranters lack that maturity. There’s a point in life where it suddenly dawns on you that no choice is ever perfect, no matter how much you may try or how perfect it may look before you put it in practice, and that you have to satisfy yourself with the best choice, rather than with illusory perfection. For those on whom this never dawns, everything is perpetually dissatisfying.

I’m not saying you should settle for crap. No, strive for the best that you can. Create something even better if you can and have the inclination. But accept that everything has limitations and shortcomings, and that a good choice is one which balances the trade-offs between the available choices to maximise whatever it is you wish to maximise. In some cases, that might mean accepting slower out-of-the-box performance in exchange for quicker development and better maintainability.

Back to the Rails argument, this becomes especially clear once you’re put in the position to decide which language and framework to use for your project - for instance when you are starting a business around that application and it really matters. With that experience, there is a very clear learning point: each framework is imperfect, but your responsibility is to choose the one that makes most sense for your specific project. Once you’ve made your choice, you can even change it, sometimes - but do so with the knowledge that every framework you try will have its own shortcomings.

But, at the end of the day, there’s no point in complaining that Rails isn’t perfect. Yes, it’s not. If that’s news to you, you’ve got a bit of growing up to do.

3. Rails isn’t suited for all applications

There are many situations where Rails isn’t the right choice. If you’re writing a high volume transaction processing system for a bank, don’t write it in Rails. If you’re writing a 3-page web presence for a hairdresser, don’t write it in Rails. Rails is extremely good for a certain class of applications (medium to large web applications), in a certain set of circumstances (particularly well suited when getting something out soon is of paramount importance).

If Rails isn’t right for your project, that doesn’t mean that Rails sucks. It just means that your project isn’t right for Rails.

4. Rails isn’t suited for all people

Rails is a smart and opinionated framework. It’s built to allow smart people to leverage their skills to be many times more productive than many other web development frameworks. And it does so - for me, and for many people I know. It allows these smart people to be very productive, create clear, maintainable code, and have fun while doing it.

This doesn’t mean that you can do it too. And you know what, those people don’t care whether you can do it too. They’ll help you if you ask for help (I know several Rails core developers and they are without exception friendly, polite, helpful people - and that’s not even counting the rest of the Rails community, who are also very helpful). But if you decide Rails is not for you, no one will shed a tear.

This, to me, is actually a positive feature of Rails. Because you have to be smart to write good Rails code, it’s easy to tell smart developers from not-so-smart ones, because the latter just won’t be able to cope with Rails, whereas the former will often take to it like a fish to water. (see comments) - It’s much harder to fake being a good Rails developer than it is to fake being a good PHP developer.

Not “getting” Rails doesn’t mean you’re stupid, mind you. Some people don’t get Rails simply because they think differently. Others say that Rails is cool, but they prefer something else (e.g. Django or some Lisp or other). That’s fine. If you don’t like to think in the Rails way, no one’s forcing you to use Rails.

Rails may not be for you, for any number of reasons. That doesn’t mean Rails sucks.

5. Rails is extremely flexible

The thing that really gets me about people who rant about how Rails doesn’t do what they need is that Rails is by far the most versatile framework I’ve worked with. When Jakarta Struts didn’t do what I wanted in the Java world, I had to make wild and ugly contortions to get it to work - or even turn around and tell my boss “Sorry, we can’t do this because xyz”.

Every time I have a “different” requirement, I am astonished to find that either there’s already a way designed into Rails that allows me to do it easily, or it’s a neat, well contained three-line hack to get it working. I’ve never seen this in any other framework (including the ones I wrote myself). Everywhere else, there always comes a point where you have to turn around to the client and say “it can’t be done”. That just never seems to happen when developing web applications with Rails.

This applies to all enhancements, from performance improvements to functional extensions. If your ActiveRecord query is too slow and causing a bottleneck, you can bypass it with some inline SQL or even memcache it. If you need to get Rails to produce a custom binary output, you can. If you need custom table names that don’t fit the convention, you can. If you need to override the dynamic finders to do things slightly differently, you can. In most other frameworks, you can’t do anything unless it’s been thought of. Rails is the most open and versatile web development framework I’ve ever worked with.

That’s what really gets me when people say things like “Rails doesn’t scale”. First of all, that statement is based on outdated information, and secondly, Rails code, when written properly, is so clean and easy to work with that locating and optimising bottlenecks is a breeze - much more so than in many other frameworks.

So if Rails doesn’t yet do what you need, don’t complain that it sucks. Do write a bit of code to make it do what you need.

In conclusion

There are many valid reasons to use something other than Rails, but do yourself a favour. If you decide Rails isn’t for you, don’t post a rant about how “it sucks”. You’re only making yourself look dumb by doing so, and while it may be amusing for the rest of us, it’s really not doing yourself any favours.

Feel free to post comments below to tell me that actually, Rails sucks for such and such reason.

Array matcher

Mon, 26 Nov 2007 20:04:00 +0000

Here’s a lovely little snippet that shows the reasons why Ruby is such a nice language to work with. It’s to do with matching at least one of a series of items in RSpec.

Step 1: First, it was simple

Then("user $email should receive an email with his confirmation link") do |email|
  mail = ActionMailer::Base.deliveries.last
  user = User.find_by_email(email)
  mail.body.match(/#{user.confirmation_code}/) && mail.body.match(/#{user.id}/)
end

This is my simple matcher that I started with… The world was simple, and this worked fine. But then, something happened. The world started sending more than a single email in one Story, and so the need for matching multiple emails was born.

Step 2: Then, it was easy, but messy

Then("user $email should receive an email with his confirmation link") do |email|
  matches = 0
  ActionMailer::Base.deliveries.each do |mail|
    user = User.find_by_email(email)
    matches += 1 if (mail.body.match(/#{user.confirmation_code}/) && mail.body.match(/#{user.id}/))
  end
  matches.should == 1
end

This works. It works well. It works fine. But, it’s ugly. It’s not readable. It’s not RSpec-like, and it stands out like a sore thumb in the middle of my step matchers. I have Ruby to thank for the fact that fugly hacks like this stand out and beg to be rewritten in a neater way. Other languages, such as PHP, do not have this quality, and so hacks remain untouched for ages and ages.

I could not let things rest in this state. Ugliness like that must be removed. Trying to match any one of an array of items is one of those things that are likely to be repeated a few times, so I decided to extract that out. This is where another one of Ruby’s qualities came forth, and made it child’s play to extract this concept and stick it where it belongs - in Enumerable (but, I hasten to add, only when running specs…).

Step 3: Then, it was simple again

Enter my latest addition to /stories/helper.rb:

ENV["RAILS_ENV"] = "test"
require File.expand_path(File.dirname(__FILE__) + "/../config/environment")
require 'spec/rails/story_adapter'

module Enumerable
  # my_array.should_match_at_least_one { |item| item.match(/abc/) && item.match(/def/) }
  def at_least_one_should
    matches = 0
    self.each do |item|
      matches +=1 if yield item
    end
    matches.should >= 1
  end
end

Which means that the step matcher can now been reduced to the reasonably elegant and expressive:

Then("user $email should receive an email with his confirmation link") do |email|
  user = User.find_by_email(email)
  ActionMailer::Base.deliveries.at_least_one_should do |mail|
    mail.body.match(/#{user.confirmation_code}/) && mail.body.match(/#{user.id}/)
  end
end

You might be tempted to point out that I could probably use String#include? instead of String#match, since I do not care about the actual matching, only about the presence… and you’d be right. But, like an imperfectly perfect persian rug, I’m happy with my code like this.

Principles of Rails Development

Thu, 25 Oct 2007 07:38:00 +0000

I am trying to put together a series of articles on “correct” Rails development, for the purpose of helping to get across what I mean to a company that I am working with. I thought I’d post them on my blog because they can be useful for others too.

I see these applying to any size of team, whether it’s a one-man show or a 15-people XP team - although the 15-people team will probably require some additional management processes to function. Those are not, however, key rails development principles.

Here’s the first article. There will likely be more in this series.

DRY - Don’t Repeat Yourself

A key philosophy of Rails is to not repeat your code. Why? Repeated code (aka “wet” code) introduces the potential for bugs, takes longer to write, and is harder to read. If the code needs to change, and it’s repeated in multiple places, then you run the risk of forgetting to update one of the places where it’s been repeated. The result is hard-to-find bugs that take a long time to debug. Other key consequences of repeated code are: it takes longer to write (more things to type), it is more difficult to read (repetition clutters the code), it is more difficult to modify (you never know where to make the change to catch “all” the instances of the thing you want to change).

Keep the code simple and readable

Simple code is easier to read and understand. Therefore, it is easier for multiple people to work with. It is also easier for the original developer to go back to six months later. Finally, it is easier to discover bugs in simple code. Ruby and Rails both provide enormous potential for keeping code clean and simple, even while doing a lot of clever things with it. This is linked to the DRY principle, but subtly different.

MVC with thick models, thin controllers, thin views

Rails provides a full MVC stack, but that doesn’t mean that just writing in Rails will make your application a good MVC application. There are three places to put code in Rails: The model, the view, the controller. The view tells the server how to display the page - nothing more. The view should only ever contain simple display logic. The controller tells the server what functions to call in response to requests. It should only ever contain code that directs the execution towards the correct models and their appropriate method. The model tells the server what the business logic of the application is. Any validations, business logic units, etc, should go into this layer.

Test everything that you write (and only what you write)

Testing is essential for a variety of reasons. First, it provides a safety net to ensure that you don’t break one part of the code when you change another. Secondly, writing tests before writing code forces the developer to think about what they are developing before they start writing code. This always results in better designed, cleaner, more quickly written code. Ideally, the tests should consist of both BDD-type specifications that map directly to the code, and integration tests that check that the application is behaving correctly on the whole.

Tests are of key importance. Any code without an automated test suite is by definition unreliable and resistant to change, since you can have no confidence that changing one thing will not break three others. Testing enables you to be confident that you can make changes without making the code buggy.

Use Rails standard tools/code/plugins wherever possible

One of the advantages of Ruby on Rails is its huge community of developers. They produce many useful plugins which help accelerate development. Moreover, the core Rails distribution includes a large number of utilities (such as validators). These should be used whenever possible, in preference to custom code. Any custom code doing more than pure business logic or simple controller and view logic should be clearly justified.

Continuous unit testing and continuous integration

Tests and specifications should be executed as often as possible. Since the computer does not care how many times it runs the tests, there is no reason to settle for anything less than continuous testing. Tests should be running continuously in the background and notify the developer(s) immediately when they fail. The advantage of this is that developers know immediately when they write a piece of code that causes something else to break. This saves huge amounts of time in debugging.

Integration testing with rfacebook - solving the session problem

Sun, 21 Oct 2007 11:07:00 +0000

It’s always very important to write integration tests. Hell, it’s not just very important, it’s critical. Some systems make it easier than others to do so. Rails, for instance, provides many, many hooks and bits of framework to make your apps easily testable. Facebook, on the other hand, is a major pain in the ass.

One of the many ways in which Facebook (or more precisely, rfacebook) makes it difficult to write integration tests, is the session problem. Here’s how it goes:

You write your integration test, including a fresh set of fbparams to make the request pass through rfacebook’s requirefacebookinstall
It works, it passes, you’re happy and you buy everyone a round of drinks.
Some time later, for no apparent reason, your integration breaks and seems to think that your test fbparams don’t actually represent a valid user.
You shoot your coworkers after spending 3 hours trying to find what’s changed in your code to make it fail.

Now, we don’t want that, do we?

Symptoms

This is often visible through a spec failing with an error message something like:

  Spec::Expectations::ExpectationNotMetError: expected /Test message/, got "<html><body>You are being <a href=\"http://www.example.com/facebook\">redirected</a>.</body></html>"

After tearing your hair out just enough to make you look like a Benedictine monk, you’ll check the test.log file and find something like this:

Processing FacebookController#create_message_profile (for 127.0.0.1 at 2007-10-21 10:47:54) [POST]
  Session ID: 30f78183e4c851ef6af04c479bb34224
  Parameters: {"message"=>{"contents"=>""}, "post_form_id"=>"8a47588a90e2b89399aa4621eedaf9b4", "fb_sig_time"=>"1192733662.7756", "fb_sig_is_mockajax"=>"1", "fb_sig"=>"460d0402bf9475b18963ca8417a24a93", "action"=>"create_message_profile", "fb_sig_session_key"=>"<snip>", "fb_sig_profile"=>"<snip>", "controller"=>"facebook", "fb_sig_expires"=>"0", "fb_sig_added"=>"1", "fb_sig_api_key"=>"<snip>", "fb_sig_user"=>"<snip>", "fb_sig_profile_update_time"=>"1192638467"}
Can only render or redirect once per action
/Users/<snip>/Sites/<snip>/vendor/rails/actionpack/lib/action_controller/base.rb:714:in 'render_with_no_layout'
/Users/<snip>/Sites/<snip>/vendor/rails/actionpack/lib/action_controller/layout.rb:256:in 'render_without_benchmark'
/Users/<snip>/Sites/<snip>/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:50:in 'render'
...

At this point, you should be just about ready to go postal. If you are fortunate to work from home, like me, however, you don’t have any coworkers to shoot. This leaves you with only one option: figuring out what the hell is going on in there.

You might be tempted to try scraping a new set of test parameters from a “real” request to your system. If you do so, you’ll find that works. If you then play with which field exactly causes it to work again, you’ll find two fields must be updated in your test data for your integration test to work again: fbsig and fbsig_time. Since those fields are not actually required to create a new session, you might be inclined at this point to curse rfacebook. And, in a sense, you’d be right.

What’s actually happening in the guts of rfacebook is this: rfacebook not only checks that your session is valid. Before it even bothers doing that, it checks that your session parameters are consistent with each other. One of the checks is to see whether fbsigtime is less than 48 hours ago. If it isn’t, ie if your beautiful integration test has been running for a staggering two days, it will wipe all the fb_sig params, right away - which obviously causes issue when the rest of rfacebook tries to determine whether a user is logged in. This is what causes the redirect.

Here’s the guilty method:

    # Function: get_fb_sig_params
    #   Returns the fb_sig params from Hash that has all request params.  Hash is empty if the
    #   signature was invalid.
    #
    # Parameters:
    #   originalParams - a Hash that contains the fb_sig_* params (i.e. Rails params)
    #
    def get_fb_sig_params(originalParams)

      # setup
      timeout = 48*3600
      prefix = "fb_sig_"

      # get the params prefixed by "fb_sig_" (and remove the prefix)
      sigParams = {}
      originalParams.each do |k,v|
        oldLen = k.length
        newK = k.sub(prefix, "")
        if oldLen != newK.length
          sigParams[newK] = v
        end
      end

      # handle invalidation
      if (timeout and (sigParams["time"].nil? or (Time.now.to_i - sigParams["time"].to_i > timeout.to_i)))
        # invalidate if the timeout has been reached
        #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature was timed out"
        sigParams = {}
      end

      # check that the signatures match
      expectedSig = originalParams["fb_sig"]
      if !(sigParams and expectedSig and generate_signature(sigParams, @api_secret) == expectedSig)
        # didn't match, empty out the params
        #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature did not match"
        sigParams = {}
      end

      return sigParams

    end

Now, personally, I think that’s appalling behaviour for any code. It’s quietly swallowing one issue that it finds, “safe” in the knowledge that some other bit will break later because of this. In the realm of trying to stop developers from figuring out why their code breaks, this is pretty clever. Matt Pizzimenti must have a special deal with arms dealers located near technology hubs.

The solution

Now that we’ve found this awful piece of code, what can we do about it? We don’t want to just hack the gem and remove it, because god knows what might happen then. Who knows what other part of the code might blow up when we make such changes. Adding a special parameter to make it ignore fbsig and fbsig_time when that parameter is present would be a security issue. And anyway, the spirit of the code is right (checking session validity is a good thing), it’s just the implementation which sucks.

Turns out Ruby, with its wonderful dynamic aptitudes, provides more than enough rope to quickly hang rfacebook by the ear. You can overwrite that method from within your own code. This means that your integration tests will pass, and that your fixing code will never be overwritten by an rfacebook gem update - although it *is* possible that it would cause weird errors should Matt decide to change that method and move that check about. Hopefully he would make a specific announcement about that when releasing the update though.

To solve this issue, just add the following to your spec/story helper:

module RFacebook

  class FacebookWebSession
    def get_fb_sig_params(originalParams)

      # setup
      timeout = 48*3600
      prefix = "fb_sig_"

      # get the params prefixed by "fb_sig_" (and remove the prefix)
      sigParams = {}
      originalParams.each do |k,v|
        oldLen = k.length
        newK = k.sub(prefix, "")
        if oldLen != newK.length
          sigParams[newK] = v
        end
      end

      # # handle invalidation
      # if (timeout and (sigParams["time"].nil? or (Time.now.to_i - sigParams["time"].to_i > timeout.to_i)))
      #   # invalidate if the timeout has been reached
      #   #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature was timed out"
      #   sigParams = {}
      # end
      #
      # # check that the signatures match
      # expectedSig = originalParams["fb_sig"]
      # if !(sigParams and expectedSig and generate_signature(sigParams, @api_secret) == expectedSig)
      #   # didn't match, empty out the params
      #   #log_debug "** RFACEBOOK(GEM) - fbparams is empty because the signature did not match"
      #   sigParams = {}
      # end

      return sigParams

    end
  end
end

Now you can have any fbsigtime and fb_sig you want in your integration tests. Best part is, it will only affect your tests - your production code will continue to check sessions correctly.

Spying on an object’s method calls

Sat, 20 Oct 2007 08:53:00 +0000

Sometimes, while figuring out why something doesn’t work, it’s useful to just quickly get a dump of what methods are being called, e.g. on a controller. Yes, debuggers can help you do that, but you don’t always want the full power of a debugger. Sometimes you just want to spy what’s happening in there.

My first thought about how to do this was a proxy object. Then I realised that I wasn’t the one instantiating the object (rspec was, the object being an ActionController), so that wasn’t going to work. So then I thought perhaps I could inject a spy by somehow renaming all the methods and putting in my own method_missing. But it turns out that’s not necessary.

Ruby, useful as ever, provides a hook for this kind of dirty work via the settracefunc method. Here’s the awfully simple code that I throw into my spec when I want to know exactly what a controller does when a certain page is called, for debugging purposes:

    set_trace_func proc { |event, file, line, id, binding, classname|
      printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, classname if file.include? "facebook_controller.rb"
    }
    do_post
    set_trace_func proc {}

Et voila!

This will print out something like the following:

    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:131   set_user FacebookController
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:131   set_user FacebookController
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:131         []     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:131         []     Hash
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:132   set_user FacebookController
  return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:134   set_user FacebookController
    call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:12 create_message FacebookController
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:13 create_message FacebookController
    call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:136 create_message_private FacebookController
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138 create_message_private FacebookController
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138 create_message_private FacebookController
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         []     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         []     Hash
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         ==     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         ==     Hash
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         []     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         []     Hash
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         []     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138         []     Hash
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138     empty?   String
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138     empty?   String
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:143 create_message_private FacebookController
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:143         []     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:143         []     Hash
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:143         []     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:143         []     Hash
  c-call /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:143         []     Hash
c-return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:143         []     Hash
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:145 create_message_private FacebookController
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:146 create_message_private FacebookController
  return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:138 create_message_private FacebookController
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:14 create_message FacebookController
    line /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:15 create_message FacebookController
  return /Users/danieltenner/Sites/amigos.local/amigos/app/controllers/facebook_controller.rb:13 create_message FacebookController

Note: on occasion, this code misbehaves and refuses to trace only the controller that you wanted to trace. If so, add the call to settracefunc to an empty proc in the “after(:each)” block.

  after(:each) do
    set_trace_func proc {}    
  end

What to test and specify, and where to do it

Fri, 19 Oct 2007 12:33:00 +0000

So I’ve been struggling a bit with my specifications approach lately. Well, only until I found out about the new Story Runner functionality in rspec. That’s resolved a number of things, by providing a powerful tool to prepare integration tests (in the form of User Stories). From the look of things, it seems like many developers like myself have been lingering in the limbo of no-integration-tests-land, simply because rspec lacked the capability, Test::unit feels unclean, and the full-on rspec-with-watir-or-selenium seems just too large a step when you don’t even have any integration tests.

Apart from this obvious benefit, the new Story functionality has allowed me to give some more thought to something that’s been bothering me. Namely, “What do you test/specify”, and where do you do it. One of the salient issues linked to this is how to specify validations. Hang in there for a potential answer as we go through this article (as always, comments are most welcome).

What’s in an app?

That’s a key question when determining what to test and how. We’re looking at rails apps, here, so the basic model is MVC. So is this what’s in an app?

This is the basic model of a Rails app. However, from the perspective of deciding what to specify and test, it’s incomplete. I’m not talking about helper classes which belong in one of those three boxes. I’m not even talking about things like daemons, or mailers, or those kinds of components, because actually they still fit in the MVC model, just one without end-user interaction. What’s missing from this diagram, I believe, is the dependencies.

One of the problems which I (and many people, looking at the rspec-users mailing list and the #rspec channel on freenode) have hit many times and which is very irritating is what to do about those validators and relationships. How do I specify my polymorphic has_many :through, eh?

First, the big stuff

The first point I’d like to make in this article is that with the Story engine, we now have the tools to specify almost the entire system. The mapping is fairly simple:

First, you write Stories (in an outcome-focused way, with the “Given/When/Then” approach), which are essentially a much nicer way to express integration tests in a business-focused way.

Next, you write specification to define how your code will make those stories pass. You write a behaviour-focused specification each for the model, the view, and the controller, because these are the key architectural separations. Please note that this doesn’t imply you should write a specification for each method - specifications should be linked to behaviours, not low-level programming constructs. However, they are inevitably influenced by the architecture of the system.

Finally, once the specifications pass, the stories should pass too. If later, you refactor or change your code, you have your integration tests holding you up and making sure your system is still working as a whole.

You have two scenarios for a change: an internal change (e.g. refactoring) or an external change (change in the user requirements). The first is driven by a change in the code, the second is driven by a change in the Story.

If you change your code, the following things sequence of events should happen:

First, the spec for the item you changed will break. Start by fixing that spec to be correct.
Simultaneously, if you changed the behaviour, some of your Stories will break. This is not because they are wrong, though, only because your specs are mismatched - ie you’ve updated your spec for your item, but not for its dependencies. Don’t change your Stories at this point.
You proceed to update the specs for everything which was dependent on the item you changed. They break. You update the code. They pass. You’ll know that this process is complete because your Stories will pass again.

If you change the Stories, the process is subtly different:

If you change the Story, it will start by breaking.
You then change some specs to make the Story pass.
This may cause other Stories to break. At this point, you should not change those Stories (unless they are directly affected), but instead, fix the specs in the method outlined earlier, when looking at an internal change.

If your Stories are comprehensive enough, these processes will stop you from introducing bugs, while at the same time allowing you to spec the “right way” (at least according to me): by specifying behaviours rather than outcomes.

Issues with speccing validators and relationships

There are still some issues to do with validators and relationships. How should they be specced? The arguments tend to go like this:

Someone writes code like:

##################
describe User, "with neither facebook uid nor phone number set" do
  include UserSpecHelper

  before(:each) do
    @user = User.new
  end

  it "should not be valid" do
    @user.should_not be_valid
  end
end

##################
describe User, "with facebook uid" do
  include UserSpecHelper

  before(:each) do
    @user = User.new(valid_facebook_attributes)
  end

  it "should be valid" do
    @user.save!
    @user.should be_valid
  end

  it "should reject duplicate facebook uid" do
    @user.save
    @user_2 = User.new(valid_facebook_attributes)
    @user_2.should_not be_valid
  end
end

This prompts someone else to ask:

1 - What are you supposed to be testing?

The answer to this is usually “your own code”. Therefore, a test (I refuse to call it a specification) like the above makes no sense. Yet is the most common way that people specify a validator.

What am I testing here? The validator code. That’s really pointless, because Rails already tests that. And it results in a lot of duplication (though technically, it can be argued to be “not duplication” because you’re testing that the business rule of requiring a particular field is there, but I think that’s just rationalising a bad practice). Ultimately, though, this is uncomfortable because you’re testing an outcome, not specifying a behaviour. You may use rspec to do so, but it’s still an outcome. And that’s not what behaviour driven design is about. Ultimately, this is testing, not specification.

2 - But how do a specify one of those weird validator things?

I think a lot of the issue is also caused by the simple language constraint that specifying validators and relationships is just plain fugly at the moment. Here’s the code provided by David Chelimsky (chief maintainer of rspec):

it "should validate_presence_of digits" do
  PhoneNumber.expects(:validates_presence_of).with(:digits)
  load "#{RAILS_ROOT}/app/models/phone_number.rb"
end

Now I love rspec, and very much respect David - I’ve had a few chats with him on freenode#rspec and he’s a very smart guy - but this code is just nasty! That nastiness is required to get around the fact that the validator is loaded when the class loads, so can’t be specified as something that will happen later.

As per the Sapir-Whorf hypothesis that BDDers know and love, language drives behaviour, and nasty language like this doesn’t encourage people to go this way, even though, as I’ll explain a bit further down, I think this is actually the correct way to go, in spirit if not in form.

3 - But if I just specify that “thing”, how do I know that it actually does what it’s supposed to?

A couple of weeks ago I would have replied: This is not a valid concern. It just shows that you really need to write that spec. You need to find out how your code is going to work before you write it. Surely that should be obvious?

But then, like all things, this is not quite so black and white. There are validation and relationship constructs which are complex enough that you want to not only specify them, you also want to unit test that they work, and that they continue working even when things change, for instance when you deploy Rails 2.0. And that’s the key to solving this puzzle. The “specification” in point 1 looks wrong because it’s not a specification, it’s a unit test. It’s not an integration test, so it doesn’t fit in the Story Writer. But it’s also not a specification, so it doesn’t fit in your User spec.

So, the solution?

I put forward that this item belongs in a third category, that we thought eliminated by the arrival of BDD, but which actually should still exist: unit tests. Specifically, unit tests relating to the behaviour of third party code, or of your interpretation of that code. So these are not system integration tests, in the sense that they are not testing your system as a whole. They are more like unit integration tests, there to codify your understanding of the way the rest of the world behaves.

As such, they do not fit in the Story Runner. They have nothing to do with user requirements. What we need is a new directory in the rspec folder, dedicated to what I would like to call Assumption Tests. They are tests of your assumptions about your dependencies. As such, they are both redundant and essential. They are redundant in an ideal world where you know exactly how the external code you use works and you know about any changes to it. They are essential in the ugly world where you have to be just that little bit paranoid about other people’s code, even if it’s specified and tested up the wazoo, because sometimes things change in a way that breaks your assumptions.

And, importantly, these are not specifications. They are unashamedly outcome-driven. This is especially acceptable when you consider that they are not specifying your own code, but testing other people’s code to make sure it fits your assumptions.

Without further ado, here’s an example of one such assumption test:

class ActiveRecordTester < ActiveRecord::Base

  # This makes this model tableless
  def self.columns() @columns ||= []; end
  def self.column(name, sql_type = nil, default = nil, null = true)
    columns << ActiveRecord::ConnectionAdapters::Column.new(name.to_s, default, sql_type.to_s, null)
  end

  column :foo, :string

  validates_presence_of :foo
end

##################
describe "Presence Validator" do

  it "should not be valid without foo" do
    @test = ActiveRecordTester.new
    @test.should_not be_valid
  end

  it "should be valid with foo" do
    @test = ActiveRecordTester.new(:foo => "1")
    @test.should be_valid
  end

end

Once you’ve got this in place, you should never need to test the outcome of validatespresenceof again. So the code in example 1 is now obsolete, and your specifications can remain entirely behaviour-driven, rather than including bits and pieces of outcome testing. All you need to specify is that, say, your User model calls “validatespresenceof” for facebook_uid in the way that’s codified and auto-tested in your assumptions.

So now you have:

specs for controllers
specs for models
specs for views
stories for the whole system
assumption tests for things which you didn’t write but want to test anyway

Sorry for the long article, but there were a fair number of ideas to cover. I’d love to hear comments about this, as it’s all still a bit fresh to me. You can put those comments below, or even comment on your own blog (I have trackback enabled). Thanks for reading!

Specifying a before_filter and/or private method

Thu, 04 Oct 2007 13:12:00 +0000

How do you write specs for a private or protected method? Specifically (as this is often the case), how do you write a spec for a before_filter?

The answers that I found while looking online were not very explicit. The main points seemed to be “don’t test private/protected method”, “you should be specifying expected behaviours in the places where they’re used.” I decided to write this article to clarify how I’ve interpreted that advice.

Essentially, I decided to follow the advice given online. Don’t test the methods, test the behaviours you expect. Let’s take a simple example and see what this means in practice.

For our facebook application, I have a facebook controller which handles all the facebook posts (very RESTless, but that’s facebook for you!). There are two things that I want to see happen with every authenticated facebook action, and I’ve defined a filter for each of them:

class FacebookController < ApplicationController
  before_filter :require_facebook_install
  before_filter :set_user

  def index
    # ...
  end

  def other_action
    # ...
  end

private
  def set_user
    if @user = User.find_by_facebook_uid(fbparams["user"], :include => [:interactions])
      if fbparams["friends"]
        @user.cached_friend_uids = fbparams["friends"]
        @user.save
      end
      if fbparams["session_key"]
        @user.facebook_session_key = fbparams["session_key"]
        @user.save
      end
    end
  end

end

Now, requirefacebookinstall is given by RFacebook, so all I want to specify is that for certain actions, this filter must be called. All that it does is return true if proper parameters are included, that represent a valid facebook session. There’s a lot of those parameters, and I only use a few of them. The only time when I might want to have this filter return false is if I was testing what would happen with a blank session. However, this should never happen in my specifications, since I’m not trying to spec RFacebook, but my own code. This is the simple, shared spec that I wrote:

describe "Facebook Action", :shared => true do
  include FacebookControllerSpecHelper

  before(:each) do
    @controller.should_receive(:require_facebook_install).and_return(true)
  end

end

It’s not much to look at, and it doesn’t need to be! How to use it? Just include this (which I’d like to call a partial spec, but the rspec keyword is “shared”) into other specs:

describe FacebookController, "index page" do
  include FacebookControllerSpecHelper

  it_should_behave_like "Facebook Action"

  before(:each) do
    @user = User.create(:facebook_uid => 1)
  end

  def do_post
    post :index
  end

  it "should render the canvas" do
    do_post
  end

end

I can do this for any of the other facebook “pages”, of course. So far so good. Adding this “itshouldbehavelike” directive ensures that the filter is called for the actions where I specify that it needs to be called. Handily enough, this also removes the need for me to mock requirefacebook_install in every one of those specs, since it’s mocked just once in the shared spec.

How about setuser? That’s a little bit more tricky. In this case, I have actually written setuser myself, so I need to specify it. But I can’t! It’s a private method, therefore invisible to my specs! Oh dear. Let’s go back to the initial advice. Don’t specify methods, specify behaviours where they’re used. Okay. Thinking about it on a basic level, this makes sense. I do want to specify that my filter is working for each of the actions I’ve told it to work for. One way to do this would be to specify that set_user must function properly in each of those actions. The smart way is of course to put that into a partial spec as well.

describe "Facebook Action With User", :shared => true do
  include FacebookControllerSpecHelper

  before(:each) do
    @user = User.create(:facebook_uid => valid_fbparams["user"])

    @controller.should_receive(:fbparams).at_least(:once).and_return(valid_fbparams)
    User.should_receive(:find_by_facebook_uid).at_least(:once).and_return(@user)
  end

  it "should call set_user" do
    do_post
  end

  it "should save the user's cached friends" do
    @user.should_receive(:cached_friend_uids=).with(valid_fbparams["friends"])
    @user.should_receive(:save).at_least(:once)

    do_post
  end

  it "should save the user's session key" do
    @user.should_receive(:facebook_session_key=).with(valid_fbparams["session_key"])
    @user.should_receive(:save).at_least(:once)

    do_post
  end
end

Those are the three things I expect my setuser beforefilter to do for me. So now I can include them in my controller action spec as well!

describe FacebookController, "index page" do
  include FacebookControllerSpecHelper

  it_should_behave_like "Facebook Action"
  it_should_behave_like "Facebook Action With User"

  def do_post
    post :index
  end

  it "should render the canvas" do
    @controller.instance_variable_set(:@user, @user)
    do_post
  end

end

And that’s all. The best part is, including the “Facebook Action With User” behaviour automatically mocks that part of the process for me in all the actions where I put it, so that I don’t need to do it again and again. By extracting those apparently intractable filters into their own shared spec, I’ve not only managed to spec them, but I’ve also reduced the clutter in my mocking code. I now only mock the things which are relevant to the current action, instead of having to mock everything to “make things work”.

On the downside, by DRYing up this code it’s become a tad harder to follow at a glance, but I think it’s more readable once you’ve figured out what the included shared specs provide.

One final caveat: if you mock something in your shared specs, don’t mock it again in your concrete specs. Otherwise, you will get errors about your shared spec being broken.

I hope you found this article useful. Please feel free to leave a comment below if you agree or disagree with this method - particularly if you have something better to suggest!

The difference between TDD and BDD

Wed, 03 Oct 2007 08:59:00 +0000

“It’s all about the words”. “Focus on behaviour”. “Design your API as a client of your own API”. “It’s a clearer way to express the same thing, so it helps communication with stakeholders”. Those are all typical responses to the questions “Why is Behaviour Driven Development better than Test Driven Development? Why should I switch to BDD?”

I’ve given this some thought. All these reasons are correct, of course. BDD uses different wording, which is much clearer. BDD focuses on specifying behaviour (though the benefit of that is often not clarified, and some people will claim that all you’re doing is writing your code twice). Designing your own API as your own client means you will design it more easily and more quickly. Being clearer, BDD does help to communicate with other coders or stakeholders (although I’m not entirely sure that the average spec is really client-friendly enough to show unfiltered).

Some of those are not really benefits of BDD, however - rather, they are benefits of Designing. Many programmers (particularly in the less sophisticated parts of the agile movement) tend to focus on code and ignore the rest. BDD provides them with a neat, coder-friendly way of doing design and specification. Of course that helps! There’s a reason why the industry standard development processes include a design phase, after all - it’s not just to delay the project!

I think there’s another important reason why BDD is better, as a test suite. It helps make your test suite less brittle in the face of specification changes. Here’s the reasoning.

Update: Please have a look at this article from Pat Maddox. BDD is a fairly new field that’s still evolving, and Pat’s article is right on the money. The approach I outline in this article is what Pat would call “pure interaction testing” and, as he points out, it should not be a goal - only an available technique. Currently, I use pure interaction testing for Rails controller testing, and state-based testing for ActiveRecord models. There’s certainly a place for the ideas exposed in this article, but they shouldn’t be used blindly everywhere.

BDD focuses on specifying what will happen next. The basic sentence structure of a BDD spec is:

This should happen; then this should happen; then this. Tell me if that doesn’t happen when I say “foo”. Foo.

TDD, on the other hand, focuses on setting up a set of conditions and then looking at the output:

Foo. Is Bar set to the right value? What about Baz?

Put in other words, BDD specifies behaviours while TDD specifies outcomes. The difference is more than just language, though. It’s a paradigm shift that has some severe consequences.

The main one, in my view, is that behaviours can be layered, while outcomes cannot. This might sound a bit cryptic, so let me explain. Let’s use the analogy of a big machine. At one end, you put a variety of raw materials, and at the other, you get a widget. Outcome testing will examine the widget from all angles. It will ask “Does this widget perform the functions that I expect a widget to perform?”. This is basically black box testing - and that’s what most integration tests do (and, sadly, many unit tests, as it’s often hard to separate the two without extensive mocking, which requires deep knowledge of the internals of the module you’re testing).

Behaviour specification turns this upside down. Instead of trying to specify the outcome, and using mocking only where you absolutely need to in order to get the thing working, you start with the goal to specify precisely those internals that you tried to avoid in TDD. “The machine should be able to turn sand and gold flakes into gold flaked glass; to do this, it should heat up the sand into molten glass. Then it should insert the gold flakes.” This requires internal knowledge of the machine.

Hopefully this is clear so far. Now here’s the clincher, the real advantage of behaviour specification over outcome testing. In order to test an outcome, you need all the parts up to that outcome to have done their job. If I want to test that my widget has a gold-flaked glass pane in it, I need the rest of the widget-building to have succeeded and not produced a molten lump of goo. In other words, outcome testing is quite brittle. If one of the parts malfunctions, there will be many knock-on effects onto other tests. You might point out that this is why we have unit tests, but my point is, BDD enables you to design your unit tests properly. Let’s take a fairly simple method as an example.

class Mogrifier < Polator
  def transmogrify(foo, bar)
    foo.extrapolate!
    bar.extrapolate!

    baz = intrapolate(foo, bar)

    return ultrapolate(baz)
  end
end

With a Test-First approach, we might have written something like this as a test, before writing this code:

def test_mogrifier
  foo = test_foo
  bar = test_bar

  test_result = Mogrifier.new.transmogrify(foo, bar)

  assert test_result.ultrapolated?
  assert test_result.intrapolated?
  assert test_result.contains(foo.relevant_bit)
  assert test_result.contains(bar.relevant_bit)
end

How would you write this as a specification?

describe Mogrifier, "transmogrify" do

  before(:each) do
    @mogrifier = Mogrifier.new
  end

  it "should extrapolate foo" do
    foo = "foo"
    foo.should_receive(:extrapolate!).and_return("extrapolated foo")

    @mogrifier.my_method(foo, "bar")
  end

  it "should extrapolate bar" do
    bar = "bar"
    bar.should_receive(:extrapolate!).and_return("extrapolated bar")

    @mogrifier.my_method("foo", bar)
  end

  it "should intrapolate" do
    @mogrifier.should_receive(:intrapolate)
    @mogrifier.my_method("foo", "bar")
  end

  it "should ultrapolate" do
    @mogrifier.should_receive(:ultrapolate)
  end

end

Why is the test more brittle? It’s brittle because if the specification changes and states that actuallly, the transmogrifier should also encrypt its results, your test will break, whereas not one of your specs will break. In a BDD world, you’d write:

  it "should encrypt" do
    mock_baz = mock("baz")
    mock_baz.should_receive(:encrypt)
    @mogrifier.should_receive(:ultrapolate).and_return(mock_baz)
  end

And then you’d add the encrypt call to the transmogrify method. With TDD, on the other hand, any of your tests that depend on the outcome of the transmogrifier will have to change. You might even be quite stuck at this point, in this specific example, if the encryption happens to be one-way - if that were the case, you won’t be able to test the outcome at all, since it will be opaque! Then you’d have to redesign your code so that transmogrify doesn’t actually encrypt stuff, but some other method does. What a pain!

Behaviour specifications enable you to ensure that your transmogrifier code keeps extrapolating and intrapolating as required - no matter what it does with its input later. If it needs to do other stuff too, that’s fine, you can specify it as well - but each specification will (or should) focus on a single behaviour and that way, as long as your spec passes, you know that the specification is being met, and that foo and bar are still being extrapolated (in this example).

As the behaviours multiply, and the layering increases, this becomes even more useful. Because of the focus of each specification, there is rarely any need to change more than a handful of specifications when the code changes (if the specs are well-written and cleanly split out into small and specific behaviours). For instance, if the Polator changes its processes (but retains its interface), the Transmogrifier test code will remain the same. BDD encourages low coupling of tests, which, to be fair, TDD doesn’t encourage. In TDD, it’s easier to write a test that uses real objects (at least at first). In BDD, you simply cannot specify behaviours without using mocks.

This is the major winning point of BDD for me, the reason why it feels so much more right. I think that the clarity, the speed, design, words, etc, are all nice bonuses to this main benefit. If you have any comments on this, any disagreements, etc, do feel free to post something below!

PS:

On the other hand, please note that I don’t suggest that we shouldn’t use tests at all. As mentioned here, specs do not validate whether your system actually hangs together and works on the whole. Tests are the ones to give you that.

Textmate rSpec error

Sat, 29 Sep 2007 14:10:00 +0000

Just a short post to mention an issue with TextMate and the rSpec bundle that wasn’t so easy to figure out. There’s not much help on google about this, but I got lucky, so I thought I’d share it here so that if others encounter the same issue.

Sometimes, you might press your rSpec run shortcut, with the aim of getting the nicely formatted output, and see instead a blank textmate window with an error like:

/Users/username/Library/Application Support/TextMate/Pristine Copy/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:18:in `run_files': private method `split' called for nil:NilClass (NoMethodError) from /tmp/temp_textmate.Hm7cJH:4

The very simple solution is that the Command-R run behaviour shortcut executes the selected files, not the currently open file. It’s quite similar to the Subversion bundle in that way. In order to resolve this, make sure you have the file selected in the file drawer. With no files selected, you will always get the above error. With some non-rspec files selected, you will have a different (longer) error.

This kind of sucks. This should default to the open file. Well, funnily enough, the TextMate rSpec bundle does include that, under a different shortcut. Press Command-D (for run behaviour description) and it will run the currently open file, rather than the selected directory, which Command-R defaults to.

That’s all for this post. I told you it would be short!

Polymorphic has_many :through enhanced

Wed, 26 Sep 2007 17:35:00 +0000

Yesterday I posted an article describing how to do a DRY, readable polymorphic has_many :through join. Since then, I’ve made a few key improvements to them, so I thought I’d share them here.

The key shortcoming that came up as I used my has_interaction collection was that it wasn’t setting the interaction type automatically. This is a big problem, because the following code won’t work:

@user.hidden_messages << message

I guess my tests weren’t as clearly defined as they should have been. What actually happened was that the interaction was being created, but the interaction type stayed null. This makes sense, since I was only specifying it as a selection criteria. The tests only passed because the “hidden_messages” collection was being cached. So the first thing to do is to rewrite the tests so that they actually reload the data from the database to make sure the relationship has been persisted correctly. I’ve only included one test rewrite for brevity:

def test_should_be_able_to_hide_messages
  @dan.hidden_messages << @message_three
  assert_equal @dan.hidden_messages(true).first, @message_three
end

This should apply to all the tests, though. The useful addition there is the (true) which forces the collection to reload from the database.

So how to make this work? Well, reading this good post by Josh Susser of the well-named “has_many :through” blog, I came up with this:

module HasInteractions

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

  module ClassMethods
    def has_interaction(args)
      has_many  (args[:type] + "_" + args[:model].downcase.pluralize).to_sym,
                :through      => :interactions,
                :source       => :victim,
                :source_type  => args[:model],
                :conditions   => "interaction_type = '#{args[:type]}'" do
                  def <<(victim)
                    Interaction.with_scope(:create => { :interaction_type => args[:type] }) { self.concat victim }
                  end
                end
    end

  end

end

That’s nice, and readable, and all that, but it doesn’t work. It throws a NoMethodError because args is not defined anymore by the time we executed “<<”. This makes sense, because args was a local variable to the has_interaction method, so it’s meaningless when we get back from our external code.

Unfortunately, Josh’s examples all involve only unextracted hasmany :through. If I’d written out each relationship explicitly without extracting it out, his code would have worked. However, I have extracted out hasinteractions, and it is more readable, so I’m going to keep it that way. How to get it to work, then? Well, on this front I got some very good help from the excellent #ruby-lang channel on freenode, mainly from 4 people with the handles “oGMo”, “Sepp2k”, “nutrimatt” and “apeiros”. The result was this:

module HasInteractions

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

  module ClassMethods
    def has_interaction(args)
      has_many  (args[:type] + "_" + args[:model].downcase.pluralize).to_sym,
                :through      => :interactions,
                :source       => :victim,
                :source_type  => args[:model],
                :conditions   => "interaction_type = '#{args[:type]}'" do
                  class_eval do
                    define_method("<<") do |victim|
                      Interaction.with_scope(:create => { :interaction_type => args[:type] }) { self.concat victim }
                    end
                  end
                end
    end

  end

end

I won’t go into a detailed explanation of why this works. If you got here looking for how to make it work, this works. If you want to find out why it works, a quick read through the api documentation for classeval and definemethod will clear it up.

There was one more useful improvement that apeiros suggested: The ClassMethods module I had copied from Rails was unnecessary. Instead of “include”ing, I could just “extend” the HasInteractions module and define the has_interactions in there directly. Here’s the resulting code:

module HasInteractions

  def has_interaction(args)
    has_many  (args[:type] + "_" + args[:model].downcase.pluralize).to_sym,
              :through      => :interactions,
              :source       => :victim,
              :source_type  => args[:model],
              :conditions   => "interaction_type = '#{args[:type]}'" do
                class_eval do
                  define_method("<<") do |victim|
                    Interaction.with_scope(:create => { :interaction_type => args[:type] }) { self.concat victim }
                  end
                end
              end
  end

end

And in user.rb, we just replace “include HasInteractions” with “extend HasInteractions” - et voilà! It works. All the tests pass. It’s readable.

I hope you find this article useful and it helps you with what you’re trying to implement. If you have any further suggested improvements, or any comments, feel free to leave them below.