Andrew Vos's Blog

I recently submitted my first patch to Rubinius and was quite amazed at how simple it was. If you're looking for a cool Ruby project to contribute to, Rubinius is the one.

Getting Started

1. Fork the project and git clone your fork.
2. Build the project and run the tests.

     ./configure
     rake spec
   

   If anything goes wrong, head to the internets! Alternatively, check out #rubinius on Freenode.
3. There is a list of specs that fail when run under 1.9.2, which is a great place to find stuff to work on. To get a list of these specs, run the following command:

     bin/mspec tag --list fails -tx19 :ci_files
   

4. Find a failing spec that looks interesting.
5. Run the tests for that method. For example, my first patch involved Kernel#puts. To run the specs I ran the following command:

   rake build && ./bin/mspec -tx19 spec/ruby/core/kernel/puts_spec.rb
   

   Notice how I'm executing rake build first? You have to do a build before running any tests if you've changed any code.
6. Fix the code! This part will obviously be different depending on the code you're changing, so if you're having problems check out #rubinius on Freenode.
7. Mark the failing test as passing:

   ./bin/mspec tag --del fails -tx19 core/kernel/puts
   

   This command should run the tests, and remove and tests that are passing.
8. Do a full `rake` before pushing your code to make sure you haven't broken anything else.

   rake
   

I use git almost exclusively for any new code I write, and I end up checking the status of my working directory quite often.

I wanted to be able to view my git status without actually typing anything so I wrote a simple bash prompt that displays a git icon if you are in a git repository. If the repository has uncommited changes the icon turns red and if the working directory is clean then the icon turns green.

An example of what it should look like is below:

Copy this code into your ~/.bash_profile and you're good to go!

function git_prompt {
  local STATUS=`git status 2>&1`
  if [[ "$STATUS" == *'Not a git repository'* ]]
  then
    echo "$"
  else
    if [[ "$STATUS" == *'working directory clean'* ]]
    then
      echo -e '\033[0;32m±\033[m'
    else
      echo -e '\033[0;31m±\033[m'
    fi
  fi
}

export PS1='\w $(git_prompt) '

You may have noticed that Homebrew doesn't include VIM in it's repositories. This is because they don't support "duplicates" which means that any command line tool that comes pre-installed with OS X will not be in their repository.

There is a workaround though and it involves using homebrew-alt.

Unfortunately the vim formula in homebrew-alt doesn't work if you happen to have Ruby 1.9.2 installed, so for now you'll have to use my fork.

# Install VIM
brew install https://raw.github.com/AndrewVos/homebrew-alt/master/duplicates/vim.rb

# Rename old vim to 'vim72' so that we can still access it if we need to
mv /usr/bin/vim /usr/bin/vim72

Now if you restart your terminal and check the VIM version you should see something like this:

$ vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jul 23 2011 20:09:39)
MacOS X (unix) version

Great! You now have a more stable VIM.

In this post I'm going to attempt to document some useful guidelines that in my experience has lead to writing cleaner, more maintainable and less flaky features.

Features can contain extra details if it is relevant to the feature

Lets say we are requesting some data from a rest service and we are expecting an xml response. It may be useful for documentation purposes to show this xml response right in the feature file.

Scenario: Data Request
Given I request some data from http://sample.org/data.xml
I should see the xml
'''
<xml>
  <data>
    hello
  </data>
</xml>
'''

Scenarios should not automate the UI

Consider the following code:

Scenario: Invalid email address
When I fill in "Username" with "Username"
And I fill in "Password" with "password123"
And I fill in "Confirm Password" with "password123"
And I fill in "Email Address" with "invalid email address"
And click "Create User"
Then I should see "Please enter a valid email address"

There is a lot of code here that is not relevant to the scenario at all and only serves to automate the browser.

If we remove the details that aren't relevant we get a much more readable scenario:

Scenario: Invalid email address
When I fill in an invalid email address
And click "Create User"
Then I should see "Please enter a valid email address"

Features should only contain information that the user sees

Element ids, CSS and XPath is only relevant to developers and should be kept in the step definitions or removed entirely.

In the following code example we use Capybara to fill in the password text input using the label which links to it using the 'for' attribute.

<label for="password">Password</label>
<input type="text" name="password">

fill_in "Password", :with => "password123"

If you are using SpecFlow instead of Cucumber then Coypu is a very powerful Capybara-like .NET tool.

Scenarios should not be dependant on other scenarios

There should never be a situation where one scenario needs to be run before another scenario.

I've personally seen feature files that had scenarios with names that had number prefixes in order to make sure that they ran in a certain order. This is evil and should never happen.

Never ever ever let this happen:

Scenario: 0TestSetup
  Given some data is in the database

Scenario: 1UserNavigatesToProfilePage
  Given the user has logged in
  When I click Profile
  Then I should see the Profile page

Scenario: 2UserChangesTheirPassword
  When I enter a new password
  And I click Save
  Then I should see "Password changed"

Use Background for setup when there's more than one scenario

Remember that whatever is more readable is always better. In the first code sample we only have one scenario so we don't need to DRY up the feature yet, but in the second sample it makes sense to add a Background section.

Scenario: Logged in user visits the user registration page
  Given I am logged in
  And I visit the user registration page
  Then I should be redirected to the home page

Background:
  Given I am logged in

Scenario: Logged in user visits the user registration page
  And I visit the user registration page
  Then I should be redirected to the home page

Scenario: Logged in user visits the logout page
  And I visit the logout page
  Then I should be redirected to the home page

Feature names are features not processes

Feature names should describe actual features. An example of a bad feature name is "A user registers an account". This feature should probably be called "Registration" or "User Registration".

Don't use multiple 'thens'

Instead of multiple Thens use one Then and follow it up with Ands. The second scenario below is a lot more readable.

Scenario: Registration
  When I fill in user details
  And click Register
  Then I should be redirected to the home page
  Then I should see "account created"

Scenario: Registration
  When I fill in user details
  And click Register
  Then I should be redirected to the home page
  And I should see "account created"

Your features are your documentation

Relish is a very useful new site that takes all your feature files and displays them in a very readable format.

Why not push all your features up there so that anyone in your team can have access to your feature documentation?

Looking for a project generator for your Sinatra projects? Check out my new project tony.

Demo

Usage

$ tony rspec sinatra heroku
create .gems
create Rakefile
create spec/helper.rb
create config.ru
create lib/application.rb
create lib/configuration.rb
create public/scripts/main.js
create public/styles/main.css
create views/index.erb
create views/layout.erb
create spec/application_spec.rb

I was having some weird problems with pretty much any Makefile I found to upload/compile arduino source code and upload it and I really didn't want to have to use that terrible IDE they provide so I rolled my own rake file.

The entire rakefile is available on github. Please feel free to fork and submit a pull request!

`curl` this code to a Rakefile and run `rake compile` to compile your project and `rake upload` to upload it.

curl https://github.com/AndrewVos/arduino-tools/raw/master/rakefile.rb > Rakefile

I recently bought an Arduino Uno and I wanted to be able to edit code in Vim and upload it directly from the command line.

1. Download and install the Arduino software.
2. Get this makefile and put it somewhere accessible to your project.
3. Create a Makefile in your project directory that looks something like this:

Now you can run `make` to compile or just `make upload` to compile and upload in one shot.

I saw an article on Hacker News about taking the digits of PI and expressing them as notes.

This inspired me to write a ruby script that does the same. The script is available on github here.

Here's a sound clip of this script:

My other post on profanity in languages was quite popular, so I thought I would try out some new words.

In the interest of not making mortal enemies I would like to note that this is all just for fun and I'm not implying that developers using X language are lazy/hacky.

Out of just below one million github commit messages, here are the stats on 'hack', 'workaround' and 'todo'.

Quite high there eh Perl?

Edit #1: By popular demand, here's a list of the commit messages with swear words in them. Also I added a bar chart below because this guy has no idea how to interpret pie charts :)

Edit #2: I've added a bar chart showing the amount of times certain words were used. Note that I got the calculation of the initial words a tiny bit wrong (I forgot to downcase the words when searching).

Edit #3: Added another chart for despo

Edit #4: By popular demand I've added Perl!

Last weekend I really needed to write some code. Any code. I ended up ripping just under a million commit message from GitHub.

The plan was to find out how much profanity I could find in commit messages, and then show the stats by language. These are my findings:

Out of 929857 commit messages, I found 210 swear words (using George Carlin's Seven dirty words ).

Note that I ripped an equal amount of commit messages per language so the results aren't based on how many projects there are per language.

Here's that data in pretty format:

If anyone is interested, the source is up at github.