James Golick

James Golick is an engineer, entrepreneur, speaker, and above all else, a grinder.

As CTO (or something?) of BitLove, he scaled FetLife.com's traffic by more than an order of magnitude (and counting).

James spends most of his time writing ruby and scala, building infrastructure, and extinguishing fires.

He speaks regularly at conferences and blogs periodically, but James values shipping code over just about anything else.

Latest Tweets

follow me on Twitter

James on the Web

Plugins I've Known and Loved #2: has_finder

Feb 25 2008

Plugins I've Known and Loved started out as a would-be series of presentations at Montreal on Rails. I've been bad about getting to the second presentation, so I thought I'd continue PLIKaL here. No, I'm not going to talk about any of my plugins. Instead, over the next week or two, I'd like to tell you about some wonderful plugins that I only recently discovered (though, none of them are particularly new). Today — a plugin that belongs in everybody's toolbox: has_finder.

The basic idea of this school of plugins is creating reusable scopes for your models. For instance, if you had a blogging application with a post model, you might want to query for published posts. To that end, you might write something like this in your controller:

Post.find(:all, :conditions => {:published => true})

Hopefully, though, you're familiar with the skinny controller, fat model best practice, so you'd write it like this:

class Post < ActiveRecord::Base
  def self.published
    find(:all, :conditions => {:published => true})

That's a lot better, but far from perfect. If you were to write several such methods, for example, you would not be able to combine them easily. So, looking for all published posts written by James would require writing a second method; not very DRY. Of course, ideally, you'd use an association proxy to accomplish that goal anyhow. That would work with our hand-written finder, but we'd lose all the benefits of the association_proxy like nested finds (...published.find(:all, :order => 'created_at DESC')), and we certainly wouldn't be able to chain two of them together (...published.order_by_recent). has_finder solves those problems, and more.

I Can Has Finder?

In order to reproduce the finder we wrote earlier, you'd write the following:

has_finder :published, :conditions => {:published => true}

Should you want to find all published blog posts by James, you could then make use of association proxy:

User.find_by_name('James').published.find(:all, :order => 'created_at DESC')

I have come across a good number of associations used for similar purposes, but defined on the associated model. For instance (omitting irrelevant details):

has_many :published_posts, :conditions => {:published => true}

Having discovered the wonders of has_finder, I now consider this to be an anti-pattern. The has_finder method is definitely DRYer. Far more importantly, however, the definition of what makes a post published (in our case, :published => true) belongs in the post model. The same rule applies to ordering. Following this best practice ensures there's only one point of change for refactoring, and that your models and their tests tell a more complete story about the data they represent.

Finally, has_finder supports parameterization of finders. You can wrap your conditions hash in a lambda that accepts an arbitrary number of arguments. Continuing with our blog post example, you might wish to query your posts table for all posts this week, this month, or this year, depending on the situation. To keep DRY, you could define your finder as follows:

has_finder :since, lambda { |date| {:conditions => ['created_at > ?', date]} }

Using it like this:


To put it all together, let's query for all James's published posts in the last week:


It reads just like a sentence!

Oh yeah, and all of this is compatible out of the box with will_paginate. I heard a rumor that it's going to be sucked down in to rails, too. Really, how could you not check it out (get it here)?

The Crunch Mode Paradox: Turning Superstars Average

Feb 16 2008

We've all been there — a product near (or not so near) ready to launch. Bosses breathing down your neck. Deadline soon approaching. People start to work evenings, then weekends. It starts to feel, perhaps rightly so, like nobody is doing anything other than working. Crunch mode is the time when everybody buckles down, and focuses on the product, and only the product. Forget about everything else.

Crunch mode is a result of the belief that more hours spent coding means more software gets written. The obvious problem with management's formula is that a tired programmer can do more harm than good. A particularly nasty bug, for instance, can cost a team orders of magnitude longer to fix than it took to write. So, while it may be possible to increase the total number of lines of code written, it only seems reasonable to measure shippable lines of code as a metric for productivity. Nasty bugs that get written by tired, over-worked developers should be counted against total output, rather than for it. In crunch mode, managers tend to overlook the bugs, and see productivity as increasing, while it's really decreasing. That's the crunch mode paradox.

Why Does it Happen?

You've assembled a team of all-star programmers. They're going to practice test-driven development, continuous refactoring, and other agile processes. They are code artists. Indeed, your team of developers is obsessed with 'beautiful code', and whether it's artistry, or OCD, they're not happy until code is perfect. They write shippable code.

The key to understanding why your team of carefully selected programmers breaks down in crunch mode is understanding what makes them tick in normal mode. Writing shippable code means being in a constant state of careful thought. Each change to the code is a calculated maneuver, the programmer's brain always working hard to discover new patterns of duplication that may have emerged in the code base, and promptly abstract them. The process of continuously searching for a better way — for better abstraction — is a major key to writing high quality code. As with anything else, abstraction can become a pitfall, but used properly, it means writing less code, easier testing, and perhaps most importantly, fewer places for bugs to come from. Of course, continuous refactoring, and code reuse aren't the only pieces of the puzzle, but it's important to note the thought process of the developer who is crafting his code this way.

In normal mode, your superstar developer cares about writing beautiful code; that's all. That's why he makes sure to write a comprehensive test suite, to continuously refactor, and makes sure his code is readable. That is probably the biggest difference between your great developer, and the average developer you went to so much trouble to avoid hiring; your superstar's priority is the code, whereas the average programmer's priority is going home at the end of the day. When you flip that crunch mode switch, though, priorities change.

When you tell your team that there's a deadline for a certain feature set (especially when it's a tight one), the focus is no longer on the code. When everybody is racing to accomplish a set of tasks for a certain date, coming in to work every day is about trying to get as many of those features out the door as possible in as short a time. The pressure is on. People start cutting corners. Processes break down. People write fewer tests, refactor less frequently. You have effectively turned your superstar team in to a group of average programmers.

In factory terms, a worker's production rate decreases over time. A worker who is creating 10 widgets/hour at the beginning of a shift may be producing only 6/hour at the end of the shift, having peaked at 12/hour a couple of hours in. Over time, the worker works more slowly, and makes more mistakes. This combination of slowdown and errors eventually reaches a point of zero productivity, where it takes a very long time to produce each widget, and every last one is somehow spoiled. Assembly-line managers figured out long ago that when this level of fatigue is reached, the stage is set for spectacular failure-events leading to large and costly losses – an expensive machine is damaged, inventory is destroyed, or a worker is seriously injured. (Why Crunch Mode Doesn't Work)

It Doesn't Have to Be This Way

There are two problems with crunch mode: management, and developer. Being a developer, I'm going to go after the pointy haired among us first.


Crunch mode doesn't work. Sending your team on a death march quickly leads to programmer fatigue, which nearly always leads to bad code. Moreover, developers are likely to become demoralized, burnt out, lose interest in the product, and perhaps worst of all for you, they'll become resentful of management. Moreover, in many cases, due to nasty bugs, and later hits in maintainability and consequent necessary rewrites, the crunch mode developer is outputting less in total. Finally, this sort of crunch mode is nearly always symptomatic of a team that has slipped in to waterfall development.

The great thing about true agile development is that after the first couple of weeks, the code is always in roughly shippable state. So, if you are working on a product that has to launch on a particular date, for whatever reason (be it PR, or anything else), agile is a highly effective way to ensure that you're going to have a shippable product ready. The reality is that trying to shove a specific featureset down the throats of your development team with a hard deadline simply does not work. The software will be alpha-quality if you're lucky.

John Nack, Adobe Photoshop product manager says of their transition to agile:

The team's ability to deliver a public beta--a first for a major Adobe application*--is probably the single greatest tribute to the new method. In the old days, we could have delivered a feature-rich beta, but the quality would have been shaky at best. This time, as Russell says, "The public beta was basically just 'whatever build is ready on date X,'" because we knew it would be stable. (Agile development comes to Photoshop)


The key to beating crunch mode, in my experience, is forgetting about the pressure being put on you (not easy, I know); you have to work as normal. What happens to us during crunch mode is extremely counter-productive. For some reason, when we want to work faster, we stop doing all of the things that save us time. Testing, refactoring, and general caring for code is what separates ultra-productive developers from average ones. But, best practices the first thing to go when the pressure's on.

Once you've pulled yourself together, and started working normally again, the next step is to start saying no. Obviously, this piece of advice is going to be controversial, but I think it's a discussion worth continuing. As Raganwald says:

Try this: Employ an Engineer. Ask her to slap together a bridge. The answer will be no. You cannot badger her with talk of how since You Hold The Gold, You Make The Rules. You cannot cajole her with talk of how the department needs to make its numbers, and that means getting construction done by the end of the quarter. (What I admire about professions like Engineering and Medicine)

Obviously, nobody is going to die on account of (most) bad software (as they might with a poorly built bridge). But, when you know that you, and others on your team are doing bad work, it's time to speak up. If you don't, you're doing a disservice to yourself, and your company. You're the one who is going to have to maintain this nightmare when crunch mode is over (and we know that there's never really time for a cleanup). Your company is going to have to deal with low quality software, and likely a botched release. Everybody loses.

The Crunch Mode Paradox

Crunch mode is a paradox. Managers think they're fostering increased productivity, but instead, they're damaging morale, the product, and often causing a net decrease in output. Developers try to increase their productivity by cutting all of the corners that make them effective in the first place. For those reasons, the death march has the opposite of its intended effect. Agile lifecycle management seems to be the most effective tool for guaranteeing that shippable software will be ready on a particular date. So, for companies trying to develop software, next time, try agile instead of crunch mode. Everybody will be happier.

resource_controller 0.2: maintenance release - no more edge_compatible branch

Feb 15 2008

This is mainly a maintenance release.

  • The helpers have been broken out in to four separate files internally, to help with managing the deep nesting branch.
  • There have also been a few little refactorings in preparation for some new features to come shortly.
  • The biggest thing to note for users is that there is no longer an edge_compatible branch. Since rails 1.2.6 generates the same style of named routes as 2.0.2 (edit_tag_photo_path instead of tag_edit_photo_path), there is no longer a need to continue two separate streams of development (yay)!.
  • The generator has been updated to spit out the right filenames for templates (rhtml/haml vs html.erb/html.haml), and old-style migrations (t.column instead of t.string) for any users still stuck on 1.2.6, so the transition shouldn't be a problem.

Get It!

You can get the new version by exporting from svn:

svn export http://svn.jamesgolick.com/resource_controller/tags/stable vendor/plugins/resource_controller

Or, if you're using piston, you may need to switch to the new url if you were previously on edge compatible (this is untested, so it may be slightly wrong).

  piston switch http://svn.jamesgolick.com/resource_controller/tags/stable
  piston update

As always, everybody is encouraged to come join the discussion on the increasingly lively mailing list.

An Introduction to Association Proxy

Feb 10 2008

@post.comments << Comment.new(:title => 'something')
Comment.find(:all,  :conditions => ['post_id = ? AND title like ?', @post.id, 'something'])
Comment.count(:all, :conditions => ['post_id = ?', @post.id])

There is an easier way to do all of that. So, if you're still manipulating ActiveRecord associations by hand, stop; there is a better way.


When you request a collection of associated models, ActiveRecord extends that array with several helpful methods. You can treat that array like a model class, except all of the methods are automatically scoped to the association's parent. It responds to methods like find, create, new, count, etc, and, it's called AssociationProxy.

So, what if we wanted to create a comment, scoped to our post model?


Making use of AssociationProxy, the code reads better, and requires fewer keystrokes. We can also use AssociationProxy to find elements in our collection.

@post.comments.find(:all, :conditions => {:title => 'title we are looking for'})

We can even use dynamic, attribute-based finders through AssociationProxy.

@post.comments.find_by_title 'title we are looking for'

It Gets Better

Since assoc proxy responds to many of the same methods as a model class, the two can be interchanged for many operations. In resource_controller, for example, nested controllers depend heavily on association proxies. Let me show you what I mean.

If we had, for example, a typical show action.

def show
  @comment = Comment.find(params[:id])

With very little effort, we can allow comments to be shown nested, or unnested.

def show
  @comment = model.find(params[:id])

  def model
    params[:post_id] ? Post.find(params[:post_id]).comments : Comment

Since we know that AssociationProxy responds to other model class methods, we can base our create method on this technique, too.

def show
  @comment = model.find(params[:id])

def create
  @comment = model.new(params[:comment])
  if @comment.save
    redirect_to @comment
    render :action => 'new'

  def model
    params[:post_id] ? Post.find(params[:post_id]).comments : Comment

In fact, this is nearly exactly how resource_controller is built.

So, association proxy is useful in simple and complex situations alike. It can save you a lot of code, and increase readability. It's a win-win really.