The Ship's Log

Terralien is a people-centric business. I just had a conversation with a customer wherein he praised the developer working on his project (Matthew Bass) up one side and down the other, asked me how in the world I found such a great developer, and then wondered somewhat incredulously if I had any more. Why yes, as a matter of fact I do, and if you’d like one working on your project, drop me a line :-)

But that is a good question – how do I find great developers (and designers) for the Terralien network? Just like with any other selection process, I stereotype, judge and discriminate. Oops, I guess the more politically correct term these days is, I “filter”. So what are my filter criteria? Well, some of the folks in Terralien are people I’ve worked with in the past. That one’s pretty easy – I know from first-hand experience they can cut it. In the absence of that, the first thing I’m looking for is code, often via the open source projects someone is involved with. Oh, and seeing the code goes for designers just as much as it does for developers – pretty is great and necessary, but what I really want to know is does the designer get the web, and their code is the best way to tell that.

I have two other filters that really matter to me. First, I want to see how someone communicates. One of the Terralien distinctives is that we’re not just code monkeys – everyone communicates well with the “business people” and can do their own day-to-day project management. Thus I’m looking for blogging, conference presentations, project documentation, etc., that will tell me if the person involved is a good communicator. Second, entrepreneurial pursuits are really important to me, since they say something about initiative and a passion for software that goes beyond the technology and in to the business. Since we like working with people starting things, it makes a big difference if my designers and developers have tried to start something themselves.

So what does all this have to do with certification? Well, there’s been a big rumbling in the Ruby community lately about certification, brought on by Pat Eyler’s revelation that he’s working with a university on a certification program. Now I know Pat, and I know he’s very interested in community feedback, as his Ruby Certification: Is It Worth It? post makes clear. My impression is that Pat might be on the fence, especially now that guys like Jamis Buck are saying NOT to do it, and I want to make sure he makes the right decision.

So here’s what I think, Pat – we need Ruby certification (and Rails certification) as soon as you can make it happen. It would simplify my filtering job a lot, since I would be able to immediately discount a whole swath of potential network members. I’d be able to quickly tell if someone just can’t cut it in the real world, has trouble communicating, is more interested in having things given to them than in making things happen, has no passion for software, and likes to buy their way rather than earning it. This would be of great value to me, and to a lot of others like me, so lets do it sooner rather than later.

Now, I know a lot of people are going to say that someone having a certification doesn’t tell you any of those things, but they’re wrong. You see, the problem most people have when filtering by certification is that they disqualify people who don’t have them. I’ll be instantly disqualifying everyone who does have a certification, or at least everyone who’s lame enough to tell me they do, and I can’t think of a better first-pass filter.

So what are we waiting for? Lets make this Ruby certification thing happen, and start separating the wheat from the chaff. It’ll just make my job that much easier.

Say you’re using ActiveRecord, and you want to write a query that uses the same parameter value several times. For instance:

  Lead.find(:all, :conditions => 
    ['created_at > ? AND updated_at > ? AND published_at > ?', 
      10.days.ago, 10.days.ago, 10.days.ago])

Hmmm… that’s not very DRY, is it? How about we spiff it up some with a bit of Ruby hackery:

  Lead.find(:all, :conditions => 
    ['created_at > ? AND updated_at > ? AND published_at > ?', 
      *([10.days.ago] * 3)])

That works, and it’s probably the shortest solution you’ll find, but it has a few problems. Most glaringly, we’re still not really DRY, because the idea that there are three query parameters is repeated in both the query itself and in the substitution values. Named parameters to the rescue:

  Lead.find(:all, :conditions => 
    ['created_at > :time_limit AND updated_at > :time_limit AND published_at > :time_limit', 
      {:time_limit => 10.days.ago}])

While this is actually the longest solution character-wise, it’s the shortest conceptually, and that’s the way we like it. The one other thing I’d want to do in a case like this is look at the underlying data model and make sure there’s a good reason to repeat the parameter like that… but that’s a topic for another day.

Named parameters are an oft-neglected option in ActiveRecord, even though folks like Robby were riffing on them over a year ago. They’re a major DRY’ing agent, so add them to your toolbox today!