Bob Nadler, Jr.

Turn a Ruby Array Into a Hash

I always forget the syntax for this:

1
2
ary = [:a, 1, :b, 2, :c, 3]
Hash[*ary] # => { :a => 1, :b => 2, :c => 3 }

Sed In-place Editing Gotcha in OS X

I just started learning about sed and came across one “gotcha” when using the -i option in OS X. The -i option allows you to edit a file in-place. It takes an optional parameter - a string to use as the extension for the backup file. If this parameter is not provided, then a backup file is not created.

I was using sed to remove some tag references from a ctags file. Since the file could easily be re-generated I didn’t feel the need to provide a backup extension. I tried to execute the command below, but received an error:

1
2
→ sed -i "/lib\/timekeeper\/employee.rb/d" tags
sed: 1: "tags": undefined label 'ags'

After some head scratching and Googling I figured out that in OS X the parameter is not optional, so the correct command is this:

1
→ sed -i "" "/lib\/timekeeper\/employee.rb/d" tags

Syntax Sugar for Defining Test Helper Methods

I prefer Ruby’s Test::Unit over RSpec, but one of the things I like about RSpec is the let method. It allows you to create memoized helper methods in your tests.

Here’s a way to do that in Test::Unit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Test::Unit::TestCase
  def self.let(name, &block)
    ivar = "@#{name}"
    self.class_eval do
      define_method(name) do
        if instance_variable_defined?(ivar)
          instance_variable_get(ivar)
        else
          value = self.instance_eval(&block)
          instance_variable_set(ivar, value)
        end
      end
    end
  end
end

Now instead of writing helper methods in your tests like this…

1
2
3
4
5
6
7
8
9
10
11
class EmployeeTest < Test::Unit::TestCase
  def test_employee_has_an_email
    assert_equal('jdoe@example.com', employee.email)
  end

  private

  def employee
    @employee ||= Employee.new('jdoe@example.com')
  end
end

You can use “let” like this…

1
2
3
4
5
6
7
class EmployeeTest < Test::Unit::TestCase
  let(:employee) { Employee.new('jdoe@example.com') }

  def test_employee_has_an_email
    assert_equal('jdoe@example.com', employee.email)
  end
end

LinkedIn API and Sinatra

I’ve been playing around with the LinkedIn API and Sinatra for about a week and wrote a tiny app. After you authenticate using your LinkedIn credentials, the app allows you to search your connections for those that have a skill you specify. I have a working example up on Heroku at and the source code can be found on GitHub.

Since this was more about using the LinkedIn API gem with Sinatra the matching algorithm is very naive. One interesting thing I found though is the amatch gem which is a set of extensions that allow you to do approximate matching, searching and comparing of strings. In the app I used the gem’s Jaro-Winkler metric to compare the search term.

Find Method Usages With Ctags and Vim

I always forget how to set up ctags for a Ruby/Rails app so that I get tags for not only the project, but also any gems specified in my Gemfile. From the project root do:

ctags -R `bundle show rails`/../* .

7 Tips for Writing User Stories

  1. Pick a format and stick to it. I prefer “As a <role> I want to <goal> so that <benefit>.”
  2. Be sure to include acceptance tests with the story.
  3. Keep technology terms / phrases out; a story should define user interaction absent of technology.
  4. Have your customers write the stories; stories must be understandable to the customer.
  5. Don’t be afraid to split large stories.
  6. Make sure each story provides something of value to the customer.
  7. Stories should be independent of each other.

JavaScript Patterns: Revealing Module

Awhile ago I wrote about the Module Pattern in JavaScript. There is an alternative that is quite popular called the Revealing Module Pattern that looks like this:

The problem is, I don’t like it. My main issue with this pattern is readability: it makes it easy to fall into the trap of confusing which functions are private vs. public. This is especially true when you come across code that alternates private and public functions haphazardly like this:

Yes, I know that you can just scroll down to the “return” statement to see which functions are public, but I find that having the public function definitions in the “return” block more intuitive when reading code. The whole point of private functions is to provide abstraction.

When using the regular Module Pattern I can read the public function and scroll up to the private definitions if needed. When reading the module from the top I don’t need to keep a mental model to track which functions are public vs. private.

Side Project: Car Fuel MPG Tracker Using Sinatra

I was playing around with Sinatra a few months ago and decided to create a small app with it. It’s a very basic online fuel efficiency tracker which I’ve dubbed with the stupid name: Fuelyo.

You send a text message to the app (I’m using ZeepMobile for SMS support) with the details of your fill-up. The app calculates your MPG and sends you a text back. You can then go to the app online and see a history of your MPG ratings.

I’ve put the source code on GitHub. Since this is my first real Sinatra app if anyone has any pointers regarding the code please let me know!