Craftsmanship Tour: Jim Ray

Last Tuesday I spent the afternoon with Jim Ray at the excellent Hooked coffeeshop in Denver, CO (and then I spent the next several days sick from a bad meal and recovering, so this post got delayed).

We worked on FindAPair, a small web app he’s developing with Jeff Powell. Developers can list their city and link to their Twitter and GitHub profiles to find other devs to pair with. (Yeah, this basic idea felt pretty familiar.)

First, Jim and I added some acceptance tests using Steak to test profile editing. Steak is a DSL for acceptance in BDD, but closer to Ruby code than the popular Cucumber. Jim explained he chose Steak because this project does not have a non-technical customer who’d read, verify, and help write specs. Cucumber’s translation between text files and method calls would be unnecessary complexity.

FindAPair uses the wonderful Devise library, so we followed the steps on the wiki to allow people to log in by username as well as email address. It went pretty well, but we needed to do a little tweaking for Rails 3. Of course, we contributed back to the docs. One of the nice things about GitHub is how frictionless it is to share these small improvements.

Another interesting bit of coding was planning the URL structure of the site. The two major resources are users and the cities they live in. Jim wanted to have really simple URLs like findapair.me/jimiray or findapair.me/denver. He didn’t want to overlap the namespaces, but he couldn’t decide between them. As he was explaining the problem I thought back to the early days of the web and suggested putting cities at the root and users at findapair.me/\~jimiray. Jim laughed, decided the audience was nerdy enough to remember it, so we committed it.

I’m not going to recount all the little things we did, but it was a fun afternoon building what could be a great resource.

While I was programming with Jim, I was reminded of the importance of studying. I knew a lot more vim commands than Jim, but it’s not because I’m any smarter. When I started learning vim I quickly realized it was a far bigger topic than I could absorb at once, so I only learned enough to take care of my daily routine. After I was comfortable with that, I started reading the vim manual, but I read at most one chapter a week. Read a little, experiment, give it time to settle, refresh my reading in a few days, and then move on to something else. In the decade since then, I still watch for new information about vim, reading the vim subreddit and Twitter accounts like learnvim and dotvimrc. It’s easy to skip over the stuff I already know. It’s easier to earn in small amounts over years than read one book and hope to retain everything.