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.


Override an AR default_scope

Posted on 06/08/2011

Say you've got a Thing class and your app uses soft deletes, so maybe you've got a default scope like so

default_scope where(:active => true)

and you want to find Thing records that have been (soft)deleted, so you try this

Thing.where(:active => false).all

which returns this

[]   #sadface

What gives?

Well, your default scope hold precedence over your where condition, so what you need to do is this

Thing.unscoped.where(:active => false).all

Using the unscoped scope returns an AR::Relation without the default scope, allowing you query for whatever you want. Enjoy.


Or, as it turns out, you can create a scope that negates the default scope, like so

class Thing
  default_scope where(:active => true)
  scope :inactive, where(:active => false)

Using link_to in a controller *gasp*

Posted on 05/16/2011

Yeah, I know it kind of breaks the MVC pattern, but whatever. Its not something you'd want to do all the time, but in the rare instance that you'd like to generate an anchor tag from within a controller, try this:

ActionController.helpers.link_to("Click Me!", awesome_path)

Chances are, whatever you're doing could/should probably be moved into a helper method instead of doing it in the controller, but that's up to you.


properly using the flash

Posted on 06/10/2009

Are those pants made of mirrors, because I can see myself in them...

No, I'm not going to tell you how to seduce the comic book superhero with an evening of dinner, cocktails, and smooth talk while demonstrating impeccable manners and etiquette.

What I am going to tell you is how to correctly use the handy Rails tool for passing objects between actions.  Now, this is no huge secret or stunningly clever trick.  In fact, you probably already know what I'm about to tell you.  It's just one of those things that I never think to do until after it's a problem.

In the typical Rails app, there a snippet/partial/whatever that displays anything from the flash hash with either :notice or :error keys.  If, in your controller action, you set flash[:notice] equal to some message and then redirect to another action, that message will persist through the redirect and get displayed on the subsequent view.

Here's the problem.  If, in your action, you just render a view template instead of redirecting, then the user will see that message like you intended but it will also still remain on the following request which may or may not be confusing.  Fortunately, there's an easy way to avoid this.

If you know you'll be redirecting, then there's nothing to worry about.  Business as usual.  But if you're not redirecting, just rendering a view, then you can use[:key].  The 'now' method only maintains the flash contents through the current request and is cleared before the next action.  Check it out.

def create
      @thing =[:thing])
        flash[:notice] = "Oh snap!  You created a thing!"
        redirect_to @thing
      else[:error] = "Damn dog, you messed up"
        render :action => :new

Notice how when the thing save without errors we use flash[] and redirect, but when there are errors we use[] and there's no redirect.  This will keep your app users from seeing any strance, out of place errors.

So that's it.  Like I said, it's nothing monumental.  As you were...


Git checkout woes [updated]

Posted on 05/06/2009

I ran into a strange issue while attempting to checkout a remote tracking branch of an Intridea project earlier today, so I thought I'd post up my work around.

I ran my normal checkout command, like so...

brent:~/Intridea/earthaid[master]$ git checkout -b prod origin/prod

which resulted in this error message

fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/prod' which can not be resolved as commit

After a bit of googling, I'm still not sure of the cause as most of the search results were related to issues around deploying tags, and I was merely attempting a checkout.  What I did find out was that I could specify the start point of my new branch by the revision/commit sha instead of the remote branch name, like so...

brent:~/Intridea/earthaid[master]$ git branch prod 02314583a99abdc276cde968c20babbadd23
brent:~/Intridea/earthaid[master]$ gc prod
Switched to branch "prod"

Once I had applied my changes, I just had to make sure to push them to the proper branch.



Ok, I'm a retard.  About a minute or two after I typed up this post, it occurred to me that Git couldn't resolve the remote branch name because I hadn't pulled first.  Yeah, that's right.  All I need to do was pull and then everything worked properly.