collect {thoughts}

Make your cucumber steps definitions time aware

2009-11-14T17:40:00.009-06:00

If you're like me, you've found yourself with a cucumber step definition like this:

And you want to write a step definition like this:

Instead of doing all that extra work, I threw together a cucumber step that lets you add times to any existing step definition:

To make things even easier I created a gem called Timebomb. It lets you append time constraints to your cucumber step defintions by mixing and matching:

- seconds, minutes, hours, days, weeks, months, years
- ago, from now

So with the following step definition:

I can write any of the following:

- Given I received an invitation 1 day from now
- Given I received an invitation 2 weeks ago
- Given I received an invitation 3 months from now
- Given I received an invitation 15 years ago

Timebomb to the rescue, BOOM!

== Installing ==

First install Timebomb

- sudo gem install timebomb --source http://gemcutter.org

Now, just require it in your cucumber env.rb file. BOOM goes the dynamite.

Vim Plugin for Ruby Testing

2009-07-07T10:36:00.016-05:00

If you're using ruby and you're using vim, you've probably noticed some awesome tools out there (mostly created by Tim Pope). You've got rails.vim, ruby.vim, etc. However, I noticed that there was a lack of support for some features that Textmate users have been taking for granted for a long time. I'm talking about the support Textmate provides around running your tests.

The key features I was missing from Textmate were having text output in a new buffer, the ability to run a focused test (the test my cursor was currently on) and the ability to run all tests in a given context. With the help of some ThoughtWorks colleagues on a previous project, I've put together a vim plugin that I think meets these needs.

The plugin is ruby_focused_unit_test_vim. The plugin currently supports the following ruby testing tools:

- test/unit
- rspec
- shoulda
- dust

The current features the plugin supports are:

- run focused test
- run focused context
- run entire test file
- all commands stream output to a new buffer

The streaming feature is very cool (thanks to David Vollbracht). It gives you instant feedback as your tests pass/fail in a new buffer. It feels very similar to the test output in Textmate.

The installation process is simple. Just clone the git repo and copy the ruby_focused_unit_test.vim file into your .vim/plugin directory.

Once you've installed the plugin, three commands become available to you:

- RunRubyFocusedUnitTest
- RunRubyFocusedContext
- RunAllRubyTests

To make things simple, I map these commands in my .vimrc:

I hope you find the plugin useful. In the future I'll write about my overall vim setup for ruby/rails development.

Sinatra Dances on Passenger's Stage

2008-12-29T15:55:00.012-06:00

I wrote briefly in my last post about how I've been working with sinatra quite a bit lately. After some great experiences at work, I decided to move my homepage over to sinatra from rails. It was totally inane to have the site written in rails in the first place, but I'd been learning the framework at the time and when you have a hammer...well, you know.

Anyway, I learned quite a bit about deploying a sinatra app on passenger as well as using passenger for development of sinatra apps and I figured I'd talk a bit about that. One great thing about passenger is its ability to serve any rack application. Rack is a tiny little framework that acts as a sort of standard for dealing with http requests and sinatra supports rack. This means deploying a sinatra app on passenger is pretty simple, but I had to poke around a bit to get the wheels running smoothly. Let's first look at my application layout.

We'll look at each of these files a bit closer. First and foremost, we've got the drewolson.rb file. This is my sinatra app, which we won't go into now, but remember that your sinatra app should sit at the root of your directory structure. You can also see that I have 3 subdirectories. The first is public, where you throw any static files (like images, stylesheets or favicons). The next is the views directory, which is pretty self-explanatory. Throw your view files in here.

Last but not least is the test subdirectory. This is where the tests for my sinatra app reside. Sinatra actually provides you with some pretty nice testing tools, and I'll just show you my test_helper.rb which all my tests require.

Ok, now onto the deployment fun stuff. There are two files that are key to deploying sinatra apps on passenger: config.ru and Capfile. Capfile is my capistrano deployment script and config.ru is my rackup file. Let's look at config.ru first.

I tried several variants of this file, but this is the only one that works for me. Notice that you have to explicitly state where you app_file is located as well as where your views directory sits.

Next up, let's look at my Capfile.

Again, this is super simple when compared to a standard rails Capfile. Notice that we overwrite deploy:restart. All we have to do with passenger is touch a file. Note that this also assumes you have ssh access to your server and that you're using git as your version control system.

The last piece of the puzzle is setting up a virtual host for apache. Now, you've probably already done this before but just to be complete I'll show you my virtual host for this application.

Yes, that's it. Seriously. Assuming you've enabled the site in apache, all you have to do on your first deploy is run:

cap deploy:setup
cap deploy

Bam, you're up and running with a sinatra app on passenger. But that's not all. One thing that I struggled with when getting this all working was constantly deploying, checking the app, fixing the config.ru, deploying, checking the app ... All this could have been avoided if I'd simply been developing on passenger locally and using it to run my rack based sinatra app locally before deploying. Well it turns out this is super simple. You can use the awesome passenger prefpane if you're on OS X. Simply install it, point it at your directory, and you now have a local copy of your sinatra app running on passenger + rack. How sweet is that?

Update:

It seems that newer versions of sinatra and rack break these instructions. They are verified working for rack 0.4.0 and sinatra 0.3.2. Updated code snippets to reflect this.

Mashup your RSS Feeds with ruby + sinatra + pipe

2008-12-23T13:23:00.005-06:00

I've been doing some build work lately and I stumbled upon a situation last week where I needed to take a bunch of RSS feeds, aggregate them and filter only the specific items I wanted. This actually manifested itself with continuous integration boxes. We have a lot of CI boxes running a lot of builds but each team is only interested in several of these builds.

One option is using something like CCMenu, but I actually needed a consumable RSS feed for use by another service that displayed build status is a very big, readable way (for a monitor in the team area). This aggregation and filtering of RSS feeds is, in fact, exactly what Yahoo Pipes does. However, these are all internal feeds, so Yahoo Pipes wouldn't work for me here.

Lately, I have been toying with sinatra, a great little web framework in ruby. I decided to write a tool that could be used in conjunction with sinatra to get me my RSS feed aggregation and filtering. That tool is called (not surprisingly) pipe. Below is the code for creating a simple feed containing all the ruby related articles on ycombinator and the clojure related articles on the programming subreddit:

You can install pipes like so:
- gem sources -a http://gems.github.com
- sudo gem install drewolson-pipe

The documentation is here. Enjoy.

Micro DSLs

2008-05-13T22:52:00.023-05:00

Three things you need to know about me: I spend a lot of time on planes, I like DSLs and I'm lazy. With these powers combined, I've created my new hobby: creating micro DSLs. What is a micro DSL? Basically, during my (seemingly) never ending flights from San Fran to Chicago I try to recreate DSLs I like in as few lines as possible. Oh, and one more thing: I give the resulting DSLs self-degrading names to show the respect to the people who first created them.

A couple more rules: I decide how much of the original DSL I want to recreate and I can cut any corners that I'd like. In some cases, I try to improve the original DSL or tweak the syntax a bit.

The first DSL I've micro-ized is Jay Fields expectations. I find its syntax very nice and it had some unique challenges. The general approach I took to keep the code short was to use test/unit behind the scenes. This stopped me from having to recreate all the goodness that test/unit gives me for free: a test suite runner, error/failure tracking and assertions.

Anyway, the code is below. It's about 48 lines long and implements most of the features from the original DSL.

require 'test/unit'
require 'rubygems'
require 'mocha'

class Mocha::Expectation
  def and
    @mock
  end
  
  alias_method :go, :and
end

class LoweredExpectations
  include Mocha::Standalone
  
  COMPARATORS = {
    Class => :kind_of?,
    Range => :include?,
    Regexp => :=~
  }
  
  def initialize
    @test_case = Class.new(Test::Unit::TestCase)
    @test_num = 0
  end
  
  def expect(value=true,&block)
    test_name = "test_#{@test_num += 1}"
    
    if value.kind_of? Mocha::Mock
      @test_case.send(:define_method,test_name) do
        block.call(value)
        value.verify
      end
    else
      comparator = COMPARATORS[value.class] || :==
  
      @test_case.send(:define_method,test_name) do
        assert(block.call.send(comparator,value))
      end
    end
  end
end

def LoweredExpectations(&block)
  LoweredExpectations.new.instance_eval(&block)
end

Below is an expectations file using the above code. Note there's a small different in the way mocks are used. The method and links expectations and go is used to send the mock to the block.

LoweredExpectations do
  expect do
    1 == 1
  end
  
  expect 2 do
    1 + 1
  end
  
  expect "foo" do
    "fo" + "o"
  end
  
  expect /bar\d/ do
    "bar2"
  end
  
  expect Fixnum do
    "4".to_i
  end
  
  expect mock.expects(:bar).and.expects(:baz).go do |foo|
    foo.bar
    foo.baz
  end
end

Of course, the error reporting is much worse in my version than Jay's, but I'd say not too bad for ~50 lines of code. Let me know what you think.

Update:

Source is available on github. You can see my other projects on the right side of this blog.

Diggr released

2008-09-08T14:18:00.006-05:00

I finally got around to a small side project I have wanted to work on: a new ruby wrapper for the Digg API. There's one existing library out there that I know of, but I didn't like the syntax all that much. So, like any good developer, I've reinvented the wheel! My library is called diggr and it strives to be simple and consistent with the Digg API endpoints listed here. Rather than boring you with a detailed description, I'll just show some code snippets below. For more information on diggr check out:

- Docs
- Source

Here are a few simple examples:

require 'rubygems'
require 'diggr'

diggr = Diggr::API.new

# retrieve a single user by user name and print the number of profile views
user = diggr.user("johndoe").fetch
puts user.profileviews

# iterator over the most recent 10 stories (default return size) and print their titles
diggr.stories.each do |story|
  puts story.title
end

# print the title of the 3 most recent hot stories
diggr.stories.hot.options(:count => 3).each do |story|
  puts story.title
end

# build an array of stories whos title contains "foo"
diggr.stories.inject([]) do |array,story|
  array << story if story.title =~ /foo/
  array
end

# print the title of the 2nd and 3rd most recent stories
diggr.stories.options(:count => 2, :offset => 2).each do |story|
  puts story.title
end

Ruby and Macros: An Experiment

2008-06-11T22:28:00.016-05:00

Lately I've been doing a lot of reading about Lisp. This got me thinking about how I could implement something similar to Lisp macros in ruby. DISCLAIMER: I am not a Lisp guru. I'm sure I'm missing the finer points of Lisp macros. I'm sure I'm an idiot.

That said, what I wanted to come up with was a way to define methods such that you received both the arguments to the method and the block given to the method completely unevaluated. That is, you'll be given an array of strings representing the arguments and one large string representing the block passed to the marco. You are then be free to do whatever you'd like with the arguments and the body. This, to me, captures at least the essence of macros (yes, I'm probably wrong). To do so, I've whipped up a gem called def_macro.

Below I'll show you some samples using the gem to define two classic Lisp macros: with and loop. The with macro basically gives a block access to some local variables while executing. The loop macro just loops over some code n times (the loop macro I'm describing here is WAY simplified from the true Lisp loop macro). Anyway, I'll show the examples in two stages: defining the macro using def_macro and using the defined macro.

require 'rubygems'
require 'def_macro'

The with macro:

def_macro :with do |args,body|
  eval args.first
  eval body
end

with proc { a = 1; b = 2 } do
  puts a + b
end                             # => 3

Notice in this case I'm only evaluating the first argument (there's only one). By doing so, I've set my local variables. I'm then free to evaluate the body string. Everything works as expected and we see 3 printed out. Notice that if I'm passing code as arguments, they must be inside of a proc or lambda. Ruby forces us to do this if we don't want the code evaluated immediately.

The simplified loop macro is even easier to implement. Take a look:

The loop macro:

def_macro :loop do |args,body|
  (eval args.first).times do
    eval body
  end
end

loop 2 do
  puts "hi"
end                 # => "hi" "hi"

Notice this time that it's not necessary to wrap the argument in a proc as it doesn't matter when the number 2 is evaluated.

You can download the gem in two ways:
- rubyforge: sudo gem install defmacro
- github: sudo gem install drewolson-defmacro --source=http://gems.github.com

The source is on github at http://github.com/drewolson/def_macro/tree/master

Update: Fixed spelling of macro (thanks to Nwallins on reddit)

Remote Git Repos on Ubuntu: The Right Way

2008-05-29T18:59:00.018-05:00

Overview

Over the past week or so I've been setting up remote git repositories on my slice. I figured it would be helpful to put together a post regarding what I've found to be the right way to set up remote git repos. The info in this post is basically collected from several blogs and articles, but I've yet to see all of it in a single post.

Before we get started, I'm going to make a couple of assumptions:

You're running ubuntu

You have ssh access to your box

You have access to a user on the sudoer list

You have git installed on your server and your client machine

You've generated a public/private key and it's in the standard location

Ok, enough with the chitchat, let's just get started.

Adding the git user

1. Create a git user on your server

On your server:

sudo adduser git

2. Create your .ssh folder and authorized_keys file for the git user

On your server:

su git                          # switch to the git user
cd ~                            # change to git's home dir
mkdir .ssh                      # make the .ssh dir
touch .ssh/authorized_keys      # create an empty authorized_keys file

3. Next, we need to copy the public key from our client system and add it to the authorized_keys for the git user on the server.

On your client:

ssh copy-id git@yourserver.com

4. Because we're going to be giving anyone access to the git user who needs access to the git repos, we want to restrict the actions the git user can take. To do so, we'll set the git users shell to git-shell. First, log back into your server on a user with sudo access (not the git user) and do the following:

On your server:

which git-shell             # remember this location for the next step. mine is /usr/bin/git-shell
sudo vim /etc/passwd        # find the line related to the git user, change the section that says
                            # /bin/sh to /usr/bin/git-shell (or whatever you got from the first step)

Creating a new git repo

So we've created our git user and now we'd like to create a new repository that we can use from the clients. It's actually really simple. We basically create a folder on the server in our git user's home directory named whatever we'd like the repo to be named and them we initialize it as a bare git repo. One thing to keep in is that all these commands will be performed from a user that has sudo access and is NOT the git user. Because we've set the git user's shell to git-shell, we can no longer switch to that user or ssh in as them.

On your server:

sudo mkdir /home/git/foo                # create foo directory
cd /home/git/foo                        # change to that directory
sudo git --bare init                    # initialize a bare git repo
sudo chown -R git:git /home/git/foo     # make the git user the owner of the repo

First Commit to the Repo

After initializing the repo, we're going to do a first commit from our client machine. The first commit is slightly complicated, but after you'll be all set to go.

On our client:

mkdir foo                                           # make a new folder
cd foo

git init                                            # initialize the git repo and add a file
touch README
git add .
git commit -m "added README"

git remote add origin git@yourserver.com:foo        # add the remote git repo

git push origin master                              # push your commit to it

Cloning your Repo

Our repo is now all set to clone! On our client, we could futz around with the .git/config to make our master branch track the origin, but if we clone the repo it does it for us! So, we'll just delete the directory we've just created and reclone the repo. That way, we don't have to remember how to set up the .git/config file (and I'm lazy).

On our client:

rm -r foo/
git clone git@yourserver.com:foo

And that's really all there is to it. If you'd like to give someone else access to your git repo, simply add their public key to authorized_keys. Keep in mind that with this setup, all users will have access to all git repos you create in the git user's home directory. I'll talk more about giving different access in a later post. Hope this helps you all getting git remote repos up for all your projects.

Update: Now uses ssh copy-id to copy public key to the remote server.

Don't Cry Over Spilled Context

2008-05-22T19:59:00.004-05:00

Let's talk a bit about a DSL pattern called spill-over context. In keeping with the whole "picture worth a thousand words" thing, let's take a look at a snippet of code from a rakefile to get an idea of what spill-over context actually is:

desc "I describe the task below me!"
task :stuff
  # do stuff here
end

What's cool about the code above is that the desc method seems to magically know how to attach itself to the next task defined. When I run "rake -T", I will see the description associated with my :stuff task. Very slick.

Like most things involved in DSLs, this seems magical at first. How the heck would the description know to attach itself to the next task? It's cool and very easy to see the intent of the code, but how the heck does it work? In truth, implementing the spill-over context pattern is pretty darn simple. Let's look at an example DSL I created:

make_a_sandwich = Task.new 'make a sandwich' do
  description "open up the fridge"
  step :open_fridge do
    # do fridge opening stuff
  end
  
  description "get some bread"
  step :get_bread do
    # bread stuff here
  end
  
  description "get peanut butter and jelly"
  step :ingredients do
    # get the good stuff
  end
end

make_a_sandwich.show_task

This DSL (which looks strikingly similiar to rake) lets us create tasks out of steps. We can describe each of the steps in plain english and then use the show_task method to print out a nice explanation of our task.

The code to implement this DSL is pretty easy to understand. At a high level, here's what happens. I've defined two instance methods on Task called describe and step. The describe method stores whatever sting is passed to it in an instance variable called @last_description. The step method does two things. First, it stores the block passed to it in a hash along with the step name as a key. Second, and most importantly, it checks to see if there is a description sitting in the instance variable @last_description. If so, it associates that description with the step it is creating, and then clears out the instance variable. That's all there is to spill-over context! The "magic" of the description attaching to a step is accomplished by storing the description in an instance variable and using it later. Very simple, but also a very powerful concept for creating interesting and usable DSLs.

Finally, the show_task method just iterates over the tasks and descriptions and prints them out nicely. So, without further ado, here's the implementation code:

class Task
  def initialize(name,&block)
    @name = name
    @steps = {}
    @descriptions = []
    instance_eval(&block) if block_given?
  end
  
  def show_task
    puts "Task: #{@name}"
    puts "Steps:"
    @descriptions.each_with_index do |(step,desc),i|
      puts "   #{i+1}: #{step} - #{desc}"
    end
  end

  def step(name,&block)
    @steps[name] = block
    @descriptions << [name,@last_description]
    @last_description = nil 
  end
  
  def description(text)
    @last_description = text
  end
end

Conditional includes

2008-05-14T21:37:00.003-05:00

This little problem came up at work a few days ago: what if you want to include a module but, based on the including class, get some different behavior? Enter conditional includes.

module Foo
  module Bar
    def hello
      puts "hi from bar"
    end
  end
  
  module Baz
    def hello
      puts "hi from baz"
    end
  end
  
  def self.included(klass)
    if klass.to_s == "Blah"
      klass.send(:include,Bar)
    else
      klass.send(:include,Baz)
    end
  end
end

Of course, we can change the conditional logic to fit our needs. Now we'll include this module into two classes:

class Blah
  include Foo
end

class Barf
  include Foo
end

Blah.new.hello  # => 'hi from bar'
Barf.new.hello  # => 'hi from baz'

Yahoo! We get different behavior from each class without exposing the complexity to the end user.

The rubinius community rocks

2008-04-24T02:18:00.005-05:00

The rubinius community is impressive. Really impressive. After watching Evan Phoenix's talk at MountainWest RubyConf, I decided to see what all the fuss was about. Sure enough, it was just as easy to get involved as he claimed.

How easy? I went from downloading source code to having a patch committed in less than 24 hours. And this is the first open source project I've contributed to other than my own tiny gems on rubyforge. If I can do it, you definitely can.

Oh, and did I mention that having a single patch committed (no matter how small) gives you commit rights? Ingenious.

Why is this important? Because I am now very jazzed about rubinius. People on the irc channel are super helpful. The documentation on the lighthouse page is awesome. They're even on git. I don't want to sleep. I want to submit patches.

On top of being totally accessible for a first time OSS'er, the project is just cool. After toying around with lisp and io, self-implementing languages seem really neat to me. Coding ruby to create ruby is a gratifying experience.

If you've been waiting for a project to get involved in, you should definitely check it out. They have all the tools that make it easy and fun to get going fast. And best of all, they are nice people.