Mutually Human Software - Blog

Using custom ActiveRecord events/callbacks

2009-01-06T02:20:00Z

Sometimes you are presented with a situation where you should use custom callbacks/events in your ActiveRecord model.

For example, consider the case where you need to ship the line items of an Order after it has been paid. Do you put the logic for creating a shipment in a controller, a model, or in an observer? If you use an observer, should you rely on the standard ActiveRecord callbacks like after_save?

Let’s take a brief walk through each possibility in a progression that takes us from what may seem like the easiest solution to implement to what gives us the simplest, most maintainable code.

Using a controller to house this kind of logic violates SRP and leads to unnecessarily complex controller actions. As an added penalty it makes writing controller examples much more painful as there are more code execution paths. I don’t think you should put your controller in the position of needing examples, but that’s for another post.

This can lead to nasty looking actions:

class OrderPaymentsController < ApplicationController
  def create
    order = Order.find params[:id]
    if order.make_payment(params[:amount])
      if order.paid_in_full?
        shipment = OrderShipment.new :order => order
        if shipment.save
          ...
        else
          ...
        end
      else
        ...
      end
    end
  end
end

There’s got to be a better approach. Let’s consider pushing this down into the Order model. This moves us in the spirit of skinny controller, fat model . After all an order knows when it has been paid:

class Order < ActiveRecord::Base
  has_many :payments
  after_save :check_order_for_shipment
  
  def make_payment(amount)
    # ... 
  end
  private
  
  def check_order_for_shipment
    if paid_in_full?
      shipment = OrderShipment.create! :order => order
    end
  end
end

While this has the benefit of keeping the controller simple it really only moves the problem. Now our model becomes more complex. It violates SRP by including functionality that it shouldn’t be responsible for. Why should an order know when and how to create a shipment? Practically speaking this will make writing and maintaining the Order model and its examples more difficult.

I’d rather extract the behaviour out into an observer that can be responsible for listening to an event and then kicking off the action of creating the shipment. Doing this won’t add unnecessary complexity to the Order model. Let’s extract it out in an OrderObserver:

class OrderObserver < ActiveRecord::Observer
  observe Order
    
  def after_save(order)
    if paid_in_full?
      shipment = OrderShipment.create! :order => order
    end
  end
end

This isolates the responsibility in the OrderObserver. It also lets us write examples for this behaviour in isolation (Pat Maddox’s no-peeping-toms plugin is a great tool for isolating observer examples from model examples).

It’s reasonable to stop here and be satisfied, but the solution can still be improved with minimal effort. Rather than relying on the after_save callback in the OrderObserver it would be clearer to introduce a paid_in_full callback. This removes an unnecessary conditional as well as explicitly expresses the intent of the callback. This requires that we update both the OrderObserver and the Order model.

ActiveRecord already includes all of the necessary wiring to trigger events so we just need to update the Order model to fire the paid_in_full event at the right time:

class Order < ActiveRecord::Base
  has_many :payments
  
  def make_payment(amount)
    payments.create :amount => amount
    if paid_in_full?
      notify :paid_in_full
    end
  end
end

The OrderObserver only needs to be updated to have a callback for the paid_in_full event:

class OrderObserver < ActiveRecord::Observer
  observe Order
  
  def paid_in_full(order)
    shipment = OrderShipment.create! :order => order
  end
end

Now when a payment is made an event will be fired and the OrderObserver will listen for it and start the process of creating an order shipment. This gives the code clean separation, meaningful names, and an ability to easily open and extend the system later should more functionality need to be added when an order is paid in full.

While it’s not always necessary to create custom callbacks and events there are times when it adds value to the code by keeping the code clean, maintainable, and extendable. This is a technique I’ve been using for long time and I hope you might benefit from it as well.

Software Craftsmanship Summit

2008-12-19T17:02:00Z

On Saturday, December 14th, Craig, John, Mark, Matt and Zach joined about 30 other people for a summit on software craftsmanship in Libertyville, IL, at the office of 8th Light.

Working as several small groups, the participants charted their careers in software. While each person related his story, all others took note of similarities, differences or other interesting aspects of each person’s path. Meeting all together again, we reviewed what each group captured in the context of gathering raw material that we could distill into a definition of software craftsmanship. We then formed small groups different from the earlier ones to develop ways that we would identify a software craftsman. Finally, we gathered as one large group again to integrate all that we learned into a statement or even a manifesto of software craftsmanship.

Not uncommon for such a meeting, we generated at least as many questions as we did answers. This summit was only the beginning, though. Our community continued the discussions and work mere hours after the summit was over.

Thank you to 8th Light for organizing and hosting the summit, and thank you to all those who attended. It was great to meet some of you for the first time, to see others again and to advance together our craft.

>> MHS.welcome(Matt).on("17 Nov 2008")

2008-11-17T17:00:00Z

We’ve been working so much on great apps for our customers that we almost forgot to announce our newest human!

The population of MHS grew by one on November 17th when Matt Blodgett joined us. He brings a wealth of web development experience using ASP.NET and SharePoint as primary tools. What’s more, Matt has a passion for creating great software and a desire to learn. He’s been demonstrating these characteristics since day one, contributing to projects and adding Mac OS X, Ruby, Rails, Git, et. al. to his suite of tools.

Check out his blog or follow him as @mattblodgett on Twitter.

Zach Dennis to Teach Tutorial at RailsConf

2008-05-08T22:09:00Z

Zach Dennis will be leading a tutorial at RailsConf 2008. The topic he will be presenting on Refactoring Your Rails Application.

Tutorial Details

Time: 8:30am – 12:00pm Thursday, 05/29/2008
Location: Portland Ballroom 251

Summary

Refactoring is an essential part of a developer’s life. It can be difficult to know when or what to refactor in a Rails application. Some common and more noticeable signs that you need to refactor are:

controllers becomes bloated
models become bloated
the view ends up embedding logic within its template
view helpers become large and complex, both in size and in number of methods
view partials rely on instance variables and constants rather then local variables
models start doing work for the view
tests become large, complex and painful to maintain

Refactoring should be a continual process throughout the life of an application. In order to refactor well it requires the developer to have proper techniques, tools and discipline. For example:

applying the single responsibility principle
extracting objects from bloated methods
splitting objects into two
identifying what goes in a model and what doesn’t
identifying what goes in a controller and what doesn’t
extracting presenters
when to use classes and when to use modules
using integration tests to help you refactor
writing better tests
writing clear and meaningful code

In this talk we will show the audience how to use the above refactoring techniques and tools to keep their Rails project humming along through development. Not only will they be able to apply these techniques to existing code, but they will be able to use these techniques to write better code from this point forward.

MutuallyHuman.com Redesign

2008-05-05T09:32:00Z

Finally! We bit the bullet and actualy redesigned the website. Since we started the company, we’ve been too busy to work on our own website. I guess it’s a good problem when you don’t have time to work on your own website.

We’re running our site on mephisto and hosted at slicehost.