Photo-1 Photo-2 Photo-3 Photo-4 Photo-5 Photo-6



Full-time web developer. Part-time smart ass.

I'm Brent Collier.

After a year and a half as an engineer on Twitter's Trust & Safety team, I'm looking for my next gig. Contact me if you know of something interesting.


It's alive!!!

Posted on 04/03/2009


So here it is...  The latest incarnation of my blog.

Not only does it look different, but it also resides at a different url.  Eventually, I'll move all the content over from acts-as-blogr, and maybe even from too.

Go ahead, click around.  Check out the links up top.  It's nice to finally consolidate all of my internet presences into one place.  Well, it's not all here yet, but it's getting there...


form_for funkiness with ActiveResource

Posted on 03/17/2009

The combination of a running nose, scratchy throat, and this ActiveResource bug made for a lovely afternoon.

The form_for method in ActionView::Helpers::FormHelper, when given an ActiveRecord object as an argument, uses the new_record? method to determine whether the form action should be POST or PUT.  Well, today I was building a controller to consume a restful web service, so I was using ActiveResource instead of ActiveRecord.

Everything was hunky-dory until I began doing a little testing.

Whenever I would submit my 'new' form, it would blow up on a before_filter method.  The odd part was that the before_filter method was declared as such...

before_filter :do_stuff, :except => [:new, :create]

WTF? It should not have been calling the do_stuff method before the 'create' action.  Well, as it turns out, it wasn't.  A little debugging helped me realize that it was actually hitting the 'update' action.  Again, WTF?

I checked the form_for method call.  I checked the generated html.  I checked the routes file.  Everything looked kosher.  I was stumped.

When all else fails, google that shit.

I did, and what did I find?  This Lighthouse ticket describing how form_for no worky with ActiveResource in Rails 2.2.1 (and 2.2.2 evidently since that what I was running).  So what's the solution?

alias :new_record? :new?

Add that to your resource model.  ActiveResource defines a new? method which works exactly like ActiveRecord's new_record? method. 

I had actually checked the new_record? method when I was debugging the issue, but for some reason no bells and whistles went off when @thing.new_record? returned nil.  WTF Brent?  I blame it on the medication.


Temporarily disable activerecord callbacks

Posted on 03/12/2009

ActiveRecord callbacks can be super-handy, but every once in a while, they get in the way.

I was recently working on an Intridea client project and I had to create a rake task to import a large set of data from a spreadsheet.  One of the models that was being imported had an after_save callback that sent out an email notification.  I didn't really want 3500 emails to be sent out whenever this rake task was ran, so I needed to disable the callback while the import task was running.

A former coworker, Blake, from NT showed me this trick...

Say you've got a model like so...

class Thing < ActiveRecord::Base
      before_save :do_stuff
      def do_stuff
        raise "This thing is doing stuff..."

In the config/initializers directory, I created a file called extensions.rb.  You can call it whatever you like.  I chose 'extensions' because I use the same file for any minor Ruby or Rails class extensions.  In it, I put this...

class ActiveRecord::Base
      def self.without_callback(callback, &block)
        method = self.send(:instance_method, callback)
        self.send(:remove_method, callback)
        self.send(:define_method, callback) {true}
        self.send(:remove_method, callback)
        self.send(:define_method, callback, method)

What this does is it grabs the callback and stores it in the method variable.  Remember, this code only circumvents the 'do_stuff' method, not anything declared as a before_save callback.  It then redefines the method to merely return true, yields to the block, and then redifines the the method with the contents of the method variable. 

Yielding to the block allows you to not have to worry about maintaining the method contents, or restoring it once you're done.  Also, if you were so inclined, you could easily modify this code to accept an array of method names and disable all of them

Once the extension is in place, you can do this...

Thing.without_callback(:do_stuff) do
      thing =

...without 'do_stuff' ever being called.

Some people will probably argue that if you need to disable your callback, then your model should be defined differently, but I say that's bullshit.  I think this is perfectly acceptable in many cases.  Granted you probably wouldn't want to do this all throughout your application code, but I see no problem with using this technique in a test, or data migration, or in my case, a rake task.


WOOT! Now there's a plugin. Check it out... without_callbacks


Dead simple task scheduling in Rails

Posted on 02/13/2009

So I was working on an Intridea project where I needed to send out a daily digest email.  The emails needed to be sent out on a scheduled interval, not as the result of some user action.  This meant that it would need to be handled outside of the normal request/response cycle.

Typically in the Rails world, when someone mentions long-running, or background tasks, you think either BackgrounDrb or Starling/Workling.  Those tools are fine and all -- actually, don't get me started on BackgrounDrb -- but I wanted something a bit more simple.

I didn't need queueing, or jobs, or anything like that.  I had only one task to manage.  I just want something that will say, "Once a day, do [task]", and that's all.

Also, I really didn't want to have to monkey with deployment tasks, be it with Vlad or Capistrano or whatever.  I wanted to just deploy as usual, and have it all just work, no extra processes to start or tasks to run.

This seemed like a tall order, but I began my search anyway.  Google led me to a number of pages about a number of tools, all of which included one or more of the things I was trying to avoid.  Of all places, I finally ended up on this page from the Ruby On Rails wiki.

Despite having only a one line mention near the bottom of the page, I decided to check out rufus-scheduler, and it turned out to be exactly what I was looking for.  There was no database table, queueing mechanism, or separate process to manage.  Just a simple scheduler to call out to your existing ruby code.

It couldn't get any simpler.  Here's how I set it up...

First, install the gem.

sudo gem install rufus-scheduler

I also froze it into vendor/gems by declaring the gem in the initializer block of environment.rb and then running rake gems:unpack.

Then I created a file called task_scheduler.rb in my config/initializers directory.   Inside this file is where the magic happens.  This is where it all goes down.  Are you ready?  Here it is...

scheduler = Rufus::Scheduler.start_new
    scheduler.every("1m") do

Yeah, that's it. Seriously.

I was in disbelief myself until I started up the server and watched it send me an email.  In it's current state, it would send the digest every minute, which is not what I wanted.  Fortunately, the rufus-scheduler provides several ways to schedule your tasks.  Once I was ready, I changed it to more of a cron-style scheduler.

scheduler = Rufus::Scheduler.start_new
    # Send the digest every day at noon
    scheduler.cron("0 12 * * *") do!

You could also use or for one time tasks set to run at some point in the future.

I know a guy who's from "the future", but that's another story.

Anyway, there you have it.  Dead simple task scheduling in Rails.  It really doesn't get any easier than that.