Monthly Archives: June 2011

Blog moving to GitHub

So, I think one reason this blog hasn’t yet been what I want it to be is that it’s really annoying trying to do things like custom JS and syntax highlighting on WordPress. So I’m ditching it. I’ve exported the posts here to Jekyll, so I can post just by writing a post in Markdown or Textile, and pushing to GitHub.

It’s really a great way to blog… all I need is Vim and Git, and I’m ready to go.

This also means no easy-peasy WordPress themes and templates, so the new blog is a little sparse at the moment. But that’s where new posts will live. So go there:


PAM authentication for Ruby 1.9


So, I’m happy to announce the availability of PAM authentication for Ruby 1.9.x, through the rpam-ruby19 gem. A couple of gems had existed for previous ruby versions, but 1.9 broke compatibility with all of those. After looking at the options, I decided that the the rpam gem was the best candidate for an update. It works really well on Linux (tested on Debian and Ubuntu), it’s simple to use, and there’s an authlogic plugin if you want to use rpam in your rails app.


I ran into a situation where I needed to use an approved “enterprise” authentication solution. My options were limited to Shibboleth, OpenID, SiteMinder, and ActiveDirectory. The first three involved a redirect to an ugly sign-in page; that was a no-go for a mobile app. So I decided to get creative. Using Authlogic + Rpam + Likewise to validate AD credentials created a seamless way to integrate into the environment, while leaving the look-and-feel of everything under my control.


Using PAM for web authentication is ONLY a good idea for internal applications. Even then, you have to be careful. But if all potential users of your application are also potential user of your systems (i.e., AD/LDAP entities), it can be a decent solution.


If you want the source, or would like to contribute, you can find it on my GitHub. It’s still a work in progress; it really needs tests and documentation. But it works, and might come in handy for someone, so I’m throwing it out there now.

TDD Hiring Practices – How do you evaluate a programmer?

I’ve been thinking a lot about hiring practices. How do you evaluate a potential employee’s programming skills? One popular yet (sometimes) controversial method is the use of coding quizzes. While I like this idea in principle, these quizzes can range from the absurd to the superfluous to the fascinating-yet-bizarre to the absolutely brilliant.

This suggestion is going to be very specific to my own milieu, but I think it can be abstracted easily.

One of my favorite learning experiences ever has to be Ruby Koans. It’s a set of failing unit tests that you have to figure out how to make pass. It’s fantastic, challenging (for the neophyte Rubyist), and enlightening.

I think this paradigm would be applicable to any TDD-oriented (and if you’re not, you should be) shop, because it tests both coding skill and testing proficiency. These aren’t the same thing, but both should be important to any hiring manager.

The other thing that comes to mind is Star Trek. Specifically, the Kobayashi Maru scenario (side note – it’s awesome that my browser and/or WordPress didn’t mark “Kobayashi Maru” as a misspelling).

For those who don’t know, the Kobayashi Maru was a no-win scenario, which Kirk managed to beat (the only time it was ever “won”) by reprogramming the computer. So you can test creative thinking, grace under fire, etc. by making some of the tests bad. If you’re into torturing applicants. It’s just an idea, not necessarily a good one, but if you’re a high-pressure shop, you might want to gauge that sort of thing.

This could happen on-site, or be sent to the applicant with a 24-hour window to submit the results.

Here’s how I think the protocol for this kind of test should go though:

  1. Timeboxed – You have a finite amount of time to complete this. It doesn’t have to be perfect, you don’t necessarily have to pass every test, we want to see how you think, how you prioritize problems to get the best results in the time allotted.
  2. Real-world – You’re not restricted as to resources. You can use Google, Stack Overflow, GitHub, whatever you want. In the real world, we try to see if we’re working on a solved problem before reinventing the wheel. I’m less interested in what you know than in whether you know how to find the answers to new problems efficiently.
  3. Honest – Be up-front about the problem. If the tests should be regarded as the source of all truth, say so. If the tests might be flawed, tell them. If you’re trying to test their ability to make that distinction, be honest. Tell them you’ll answer any questions they have unless you think it will bias the results. You want your programmers to have as much information as possible about the project you’ve just handed them, and you want them to be able to ask you the right questions about it. If they can do a better job by gathering information from the project manager, that’s a good thing.
I’ll disclaim this post by saying hiring practices aren’t part of my job. But I’ve experienced varying practices from employers and potential employers, and some of them seemed sensible, some seemed ridiculous, and some seemed like the people looking for a programmer didn’t even know what they were looking for.
I’m curious to see how various shops do this. How do you evaluate potential new hires? Do you quiz programmers? How?