I am geek. Hear me type.
Relics from Languages Past

My first “real” development gig, way back in the summer of 2000, was working on a desktop application that was written in Delphi. I’d taken Pascal in high school, and I’d done some pretty cool experiments with Object Pascal. I’m sure that shortened the learning curve significantly. But there was one stylistic rule on the team that forced me to change the way I wrote functions.

In Delphi, functions had an implicitly defined variable named result that was to become the return value when the function terminated without exceptions. Functions could terminate without exceptions in two ways, either by reaching the end of execution naturally, or by encountering an explicit call to exit. Explicit calls to exit were not permitted by the project’s style guide, under the justification that all procedures and functions should have one entry point and one exit point, allowing for exceptions which were the only exception to the rule. (Holy overloaded terms, Batman!)

This meant that I wrote a ton of code that looked something like this.

function Lookup(search: String): TExample
  result := Null;

  if search = 'trivial' then
    result := TExample.Create;

I remember finding this to be a crazy annoying restriction when I was first presented with it. I found it doubly weird that it was basically enforced by the language. In my university computer science program, we used C/C++, and I had developed a personal style that looked more like this.

Example* Lookup(string search) {
  if (search == 'trivial') {
    return new Example();

  return null;

After a couple of months, I found myself writing C++ code that looked something like this instead.

Example* Lookup(string search) {
  Example* result = null;

  if (search == 'trivial') {
    result = new Example();

  return result;

And ever since, that style has stuck with me. I used it when I wrote C#, Java, PHP and more. Even (gasp) Ruby. Idiomatic Ruby would probably look something like this.

def lookup(value)
  if value == 'trivial'

But I still find myself wanting to write this instead.

def lookup(value)
  result = nil

  if value == 'trivial'
    result = Example.new


That’s a lot of extra typing, and it’s still really hard to turn that habit off. It seems to be really deep in there. In the first version, I find myself wondering what the return value is actually going to be. Is it going to be nil? Or is it going to be false because the if condition failed. The answer is pretty easy to figure out. And you’d think that after nearly 5 years of working with ruby, I wouldn’t still struggle with this, but I do.

I’m curious if anyone else is fighting styles that they learned from other languages. I’ve heard a lot of anecdotal complaints about people reading “ruby code that looks like Java”, but I’d love to hear the perspective of someone that’s probably written code that meets that description.


I was banging my head against my keyboard trying to figure out at problem yesterday, right before I stopped for the day. I got up from my desk and within 15 minutes, I had “figured it out”. Trouble is, now I’ve forgotten that epiphany, and I’m right back where I started. Grr…

Update: I just remembered what my epiphany was. The interesting thing is it wouldn’t have solved my problem. I figured out the correct solution just a few moments ago. :)

Hooked on Testing has it’s own blog

I’ve started to blog much of the content that I’m writing my upcoming book, Hooked on Testing.

My goal is to have about one post out a week. The content is not going to be released in any specific order, and it will likely be edited before inclusion in the book. It should give you a better glimpse into where I’m going, and you’ll be able leave comments and help shape the content before its written.

I’ve also created a new Twitter handle @hookedontesting that I’m going to use to provide updates about the book, announce new blog posts, and interact with the larger community of developer-testers.

So feel free to follow along and participate in the creative process.

Hooked on Testing

I’ve been approached by developers for years that have asked me to help them become better testers. In the past, I’ve focused my efforts on the different tools that are available and how to use those tools to write different kinds of tests. I’d spend lots of time talking about different kinds of tests, such as unit tests, integration tests, functional tests, and acceptance tests. I’d define the different characteristics of each kind of test and the different ways to use each test to detect a particular problem. I’d even talk about employing test driven development (TDD) to slowly build up a suite of tests while writing your code. I’d talk about all of the different benefits of having tests. I’d explain how much safer it is to refactor, how much less stressful deployments are. I’d talk about employing continuous integration to make sure that the test suite works in more than one environment and to make it easy to figure out which team member is responsible to for introducing a test failure.

After talking for hours upon hours, either in one on one sessions, brown bag lunch presentations, or in larger internal training meetings, I’d walk away thinking I’d made an impact. I’d taught people how to test. The source code around them was going to slowly get much better. They were going to ship fewer bugs. They were going to be able to refactor without fear. After all, these are all things that happened to me after I started testing. But that’s not what happened for them.

I’d chat with these developers later to learn that they were still struggling with testing. They were still asking me questions like: * How do I test? * What do I test? * How often should I test? * What should I test?

I’d remind them of all the useful information that I’d provided in the past, but that’s when a glazed look would set in. I’d lost them.

For a while, I thought that people just weren’t getting it. I thought they didn’t see the value of testing, because they had yet to experience the pain that is caused by not testing. So, based on advice from a Kent Beck talk, I started waiting for teachable moments, times when a developer would come to me saying something like this:

Hey, this method doesn’t work correctly when null is passed in, but I can’t figure out how to make the app pass that in. I’ve been poking at it with a conditional breakpoint set, and I just can’t make it happen. The user sent us an error message that’s suggests that a null reference is what’s causing this problem to occur. I’m stuck, you got a second?

And then I would swoop in and write a test that calls that method and passes it null. It would fail, and we’d compare the error message with the one the user sent in. We’d figure out the best way to handle null, and then we’d close the ticket. The bug would be fixed, and another co-worker would see the value of testing. Awesome!

The only trouble is that only ever happened once, sometime after I fell asleep, but before I woke up again. Sigh.

I never found that teachable moment, but I’m still encountering people that want to learn how to test. It seems like I encounter at least one such person on every team that I join.

So many developers have asked me to teach them to test. I’ve tried many different responses. Over time, I’ve seen a pattern emerge that I was totally missing before, because of an assumption that I was making.

All these people already knew the value of testing. They’d read books, skimmed blog articles, watched screencasts, attended conference talks. They already got it.

I didn’t need to teach these people why to test. They already knew the mechanics. They’d played with different testing tools. They’d written different kinds of tests. That part they were comfortable with already.

I didn’t even really need to teach them how to test. They already knew that, too. They knew the different tricks for making sure the test is actually executing the code that they thought it was. They knew when to use an acceptance test and when to use a unit test.

I didn’t need to teach them those things. What they were struggling with was how to keep testing. How to make it part of their routine. How to fight feeling like they were writing twice as much code and getting half as much done. How to keep from having to rewrite the entire test suite when something small changes. How to keep from testing frivolous things.

Then it dawned on me. What they were really missing was making testing a habit, a second nature impulse, something that seemed wrong to skip, something that they would crave to do when solving a problem.

So I’ve decided to write a book. The working title is “Hooked on Testing”. The book’s goal is turn developers into testing addicts.

If that sounds like something that interests you, please sign up to be notified when the first chunk is published.

The book will be available for purchase before its completed. This will let me collect feedback on it as I’m writing, and it’ll let you get early access to the content if you’re interested.

I’ll also be posting excerpts on my blog, so stay tuned.

Monkey patching away default_scope

I was recently working on a Spree store that needed to remove a default scope that was created by an extension. Lots of Google searching did not yield an answer, so I dove into the ActiveRecord source to figure out how default_scope was implemented. It turns out that the default scope is stored as an array in a class variable default_scopes. So removing the default scope was as simple as

Spree::User.class_eval do
  self.default_scopes = []

I’m sure this depends on ensuring that this code executes after any default scopes have been created, so that’s something to check if you try this out and find that it does not work.

How to: Dvorak Japanese Keyboard Layouts on Mac OS X Mountain Lion

I just figured out how to set up the Mac OS X Japanese keyboard layouts to use Dvorak, and I don’t want to forget how I did it.

Install Japanese Keyboard Layouts

Just in case you haven’t done this already, here’s how you install the Japanese keyboard layouts. If you already have the layouts installed, then you can skip to the next section.

  1. Open System Preferences
  2. Click on Languages and Text
  3. In the search box type “kotoeri”
  4. Select “Hiragana”. (You can add more, too, but you have to select at least one.)
  5. Check “Show Input menu in menu bar”

Setup Dvorak typing

  1. Switch to Hiragana using the Input menu in the menu bar
  2. Click on the Input menu in the menu bar again
  3. Click on “Koteri Preferences”
  4. Make sure that “Input style” is set to “Romaji Typing”
  5. Change “Romaji keyboard layout” to “Dvorak”
  6. Close the “Kotoeri Preferences” window

That’s it


Note: This procedure was originally outlined in someone else’s blog post, but all the image links are broken which made me dismiss it at first. My goal here is to just preserve how to do this in case I forget.

Getting spooky: remote debugging with poltergeist on Mac OS X

I’ve been working on switching our project over to use poltergeist, a phantomjs backed capybara driver, for headless browser tests. I had a couple of specs fail, and started to look into what was causing the failures. I quickly realized that I was going to need more power than looking at screenshots taken with page.driver.render('/path/to/screenshot', :full => true).

I saw that remote debugging was supposed to work on Mac OS X with phantomjs version 1.6.1+, but I found I needed to jump through some hoops to get it working. Here are the steps that I went through.

Create a shell script to launch Google Chrome (or your favorite WebKit browser)

Poltergeist is configured with an executable that wil launch a browser. I had trouble running /Application/Google Chrome.app/Contents/MacOS/Google Chrome, so I had to create a shell script that invokes open /Applications/Google Chrome.app. Here’s what it looks like.

open '/Applications/Google Chrome.app' $@

I named this file chrome.sh and made it executable with chmod +x chrome.sh.

Configure poltergeist


Capybara.javascript_driver = :poltergeist


Capybara.register_driver :poltergeist do |app|
  Capybara::Poltergeist::Driver.new(app, :inspector => './chrome.sh', :js_errors => true)
Capybara.javascript_driver = :poltergeist

Have fun

That should do it. Now you can include page.driver.debug in your test. When that’s executed, the test will be paused, and Google Chrome will load a page with two links. Click on the second link, and you should see a familiar WebKit inspector. When you are ready for the test to continue, hit enter in your terminal window.

Overheard at the office: Weight loss strategy
Co-worker: I agree that denormalization is one solution
Co-worker: in the same way that amputating your arm is a surefire way to lose weight
Co-worker: ok, exaggerated analogy ;)
Reaction to 140stitches

I just finished reading the content at 140stitches, and I want to share my thoughts.

So first off. Cool concept. We geeks are probably not so good at fashion. The clever t-shirt, jeans and sneakers look may not be the best fashion, but it does serve a useful function. I’d like to share what some of those are.

Self expression

Many geeks are really passionate about different topics. Actually, that’s a pretty good definition of a geek, someone who is really passionate about something. This passion leaks into different areas, and often comes out in style of clothing and stickers affixed to laptops and vehicles. Think of a geeky t-shirt like a tattoo that you can change everyday.

Standing out in a crowd

When I go to a restaurant and the person at the booth behind me is wearing a ‘code monkey’ t-shirt (with jeans and sneakers), I perk up. This person likely does what I do. I introduce myself. We strike up a short conversation about what we’re working on. We might trade cards. Who knows, I could make a friend this way.

It’s kind of the equivalent of wearing a shirt with your favorite sports team. In line at the supermarket, you’re likely to get asked if you ‘watched the game’, ‘what did you think of the refs’ or even ‘are we going to the finals this year’. It’s a way of signaling that you belong to a certain tribe. For better or worse, this is the dress code that’s been adopted by the indie-developer.

Standing out from peers

Not all developers are alike. Many developers work in very corporate environments where a colar on your shirt is required, denim is not allowed, and you have to wear shoes that can be shined. Other developers work in more relaxed environments wear the rule is pretty much don’t be offensive and keep the private bits covered, and it’d be cool if you didn’t smell bad.

The developers that work in the relaxed environment likely have worked in the more corporate one, so they are taking advantage of the flexibility that the new rules provide. This can come in handy. For example, when I go out to lunch, and a group of guys wearing faded polos, with wrinkled colors and wrinkled khaki’s, it’s pretty safe for me to assume that they work in IT, but they wished they could dress like I do.

There are other correlations between the jobs that care how you dress and the ones that don’t. I typically notice that the jobs that permit IT staff to express themselves by wearing clever t-shirts, are more interested in having happy employees and value quality work over fashion sense. I have a choice in where I work, and I prefer to work for places that let me express myself. I doubt that I’m alone.

Full disclosure

My entire wardrobe is built on top of the geeky t-shirt, matching color undershirt, jeans, sneakers and the occasional thrift store sports coat. I have enough geeky t-shirts to wear a different one every day for over a month. I’m obviously biased on this topic, but I have not made this decision lightly. There is logic behind this choice. Hopefully, I’ve outlined some of those here.

Final thoughts

Geeks are a strange group. We don’t always look all that fashionable, but we are attempting to stand out in a world in which we would otherwise blend in. And if we just blend in, then we’ll have more difficulty finding each other in a crowd. I hope that 140stitches can keep that in mind when making fashion recommendations.

50 Shades of Analytics
Coworker Beta: Maybe someday you'll get us something sweet to work on.
Coworker Alpha: The backend stuff is sweet too! Customer lists. Which are prelude to sexy analytics.
Coworker Beta: 50 Shades of Analytics
Coworker Alpha: Right, ok, not that sexy.