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.


YARGP - Yet another Rails Gmail post

Posted on 04/06/2009

google-apps-logo.jpgWant to use Gmail, or a Google Apps account, with your Rails app?  Well, it's gotten even easier than before.

The last time I set up and app to use Gmail's smtp, I had to use a plugin called ActionMailerTLS.  Well, not any more.  Ever since Rails 2.2.2, the tls functionality is built right in, but there's a catch.

While setting up notifications for this app, it took me a few minutes to realize what the problem was.  This app is running on Rails 2.2.2, but the emails were not being sent out.  WTF?  I went back through all of the write-ups I had and seen and finally caught it.

It only works if you're running Ruby version 1.8.7, not 1.8.6.

Fortunately my Dreamhost shared hosting already had 1.8.7 installed, so notifications are working perfectly.  So leave me a comment, and I'll be notified!


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