A sprint is the basic unit of development in Agile. Sprints tend to last between one week and one month and are a “timeboxed” development effort of a constant length.

Our sprint planning session is broken down as follows:

• Product owner – prioritise and explain highest priority items in the product backlog (we use Pivotal Tracker). The team can ask questions at this point.
• Product owner – set a sprint goal (what are we achieving this sprint).
• Team – select Pivotal Tracker stories you can commit to, to attain that goal.
• Team – demonstrate a solution to each story in the sprint and ensure no outstanding questions.

Our Friday afternoon review session:

• Product Owner and Team  - demo all completed stories.
• Team – Review estimates from the sprint and note down how you went and how you can improve (if target not met).
• Team – Review points missed from the sprint and why, and how you can improve on that for next sprint.

If you’re running sprints in your organisation do you do things a little differently? Drop us a line in the comments.

The Koans walk you along the path to enlightenment in order to learn Ruby. The goal is to learn the Ruby language, syntax, structure, and some common functions and libraries.

By manipulating and building upon Ruby’s TestUnit framework, the EdgeCase developers have created a step-by-step process for teaching Ruby through the practice of “Red, Green, Refactor.” They’ve added some simple game mechanics too, by showing your systematic progression through the 270+ challenges (puzzles). Reaching enlightenment results in a pretty ASCII graphic, and a legitimate sense of achievement.

Before you start with the koans though you’ll need a working Ruby installation. I recommend you take a look at the excellent rvm project, which will allow you to install multiple rubies (1.8.7 and 1.9.2 for example, alongside each other) and multiple gemsets in your home directory. Former Frontiersmen and 2011 Ruby Hero Award winner Darcy Laycock was heavily involved in this project as part of the 2010 Ruby Summer of Code, so we really like rvm at TFG.

The GitHub repository even includes a handy Keynote presentation, which I used as the basis for my talk about Ruby Koans at last week’s Ruby on Rails Oceania Perth meetup.

Lastly, if you’d like to have a play with the koans before diving in too deep, they’re available online through your web browser at Ruby Koans Online. This is a no-risk way of trying out Ruby (hint: team them up with why’s Try Ruby project) in your browser.

You’re using Capybara, right?

It’s an acceptance / integration test framework for Ruby that superseded Webrat and makes it easy to automatically interact with Web applications but at the user level. It’s now the de facto way to do request / integration / acceptance testing (seriously, it gets called any or all of these) in Rails 3.

Capybara supports using different ‘drivers’ to run the scenarios you specify and by default it’ll use Rack::Test or Selenium (which uses Firefox’s Gecko engine). capybara-webkit is a library by the guys at Thoughtbot that gives Capybara a WebKit-powered driver using the WebKit implementation in Qt, a popular cross-platform development toolkit.

Why?

Why get WebKit involved with your integration tests at all? Perhaps your userbase is primarily made up of Safari and Chrome users (both WebKit-powered browsers) and you want to focus on them. Or perhaps you’re thorough and want to ensure the JavaScript on your pages works fine with your tests in a WebKit scenario too.

Installation

Here’s the bad news. You need Qt installed in order to install capybara-webkit. If you’re on OS X, grab it from here (pick the Cocoa: Mac binary package – the 206MB version). You can install via homebrew too (using brew install qt), but Thoughtbot says it takes forever (well, almost).

For other platforms, check out Qt’s Downloads page.
If you’re on CentOS, in particular, check this article.

Once you’ve installed the Qt toolkit, add this to your app’s Gemfile:

gem 'capybara-webkit'

Then run bundle and you’re off to the races.

Usage

Once everything’s installed, you can set Capybara’s JavaScript driver to use Webkit by default, by adding this to your normal Capybara config options (or if you have none, in spec/spec_helper.rb in most Rails 3 cases):

Capybara.javascript_driver = :webkit

Then, if you’re using Cucumber you can add the following tag to the header of your scenario to trigger JavaScript usage specifically (it’s not done by default):

@javascript

In regular RSpec code, you can do something like this:

feature "The signup page" do
scenario "should load", :js => true do
visit new_user_registration_path
page.should have_selector("form.user_new")
end
end

You could also use the :driver option to specify :webkit if you want to choose the driver on a per scenario / describe basis. The same applies to @webkit in Cucumber.

If you’re on OS X, when you first run tests using capybara-webkit the OS X firewall might go a little crazy since it works by connecting over a socket. Just approve it and you’re on your way.

You may also have issues if you’re using transaction fixtures. If so, read the “Transactional Fixtures” section of the Capybara README.

If you’re thinking of visiting either the Mt Lawley or Joondalup campuses on the day, check it out!

Has Face is a neat little gem that uses the face.com API to ensure that an image contains a persons face. It’s very simple to use and can be easily integrated into an existing rails application.

To get started add the has_face gem to your Gemfile and run a bundle install

Can’t see this Gist? View it on Github!

Run the generator to copy over an initializer:

Can’t see this Gist? View it on Github!

The initializer should look something like this:

Can’t see this Gist? View it on Github!

Now we’ll need to make a face.com developer account. You can signup for a free account over at face.com. Once you have signed up, place your API key and API secret in the initializer config.

The last option in the initializer (skip_validation_on_error) will change the behavior of has_face when an error occurs. If set to true, when an error occurs a warning will be logged to the logfile with detailed information about the failure and face validation will be skipped. This can be useful if you want your application to function if the API service is not reachable. If the value is false then an exception will be raised when an API call fails, this will allow you to manually handle the exception yourself, please check the documentation for details on the errors raised.

Once the initializer settings are setup then we can add face validation to a model. In the example below I’m using carrierwave to attach the image to the model but other image attachment gems should also work fine (anything that correctly responds to `path` should be OK).

Can’t see this Gist? View it on Github!

That’s it, that’s all we need to have a functioning face validator. There are a few other options that I haven’t covered here in this short guide, please consult the readme for more detailed information.

“Whilst prototyping the early stages of a new app with Filter Squad, we found ourselves prototyping a lot of API clients for new versions of APIs that were lacking up to date clients or in the case of other APIs, were missing functionality we required.”

Read the full post over at Engine Yard: Building Structured API Clients with API Smith

Firstly, a congratulations to our very own Darcy Laycock for winning a Ruby Hero award. The Ruby Hero awards are put in place to recognise people that have gone above and beyond in the Ruby community.

We’ve rolled out our new Frontier Group blog design, and would love to hear what you think of it in the comments below. We’ve also added a Featured Posts section in the sidebar, so you can see what other visitors (and hopefully you) are interested in too.

We’ve been heavily featured in a range of Podcasts recently, such as Ruby5 and The Ruby Show. Also we’ve been featured in prominent Ruby and Rails websites such as Ruby Weekly and Ruby Rogues.

We’d love you to keep visiting. Sign up to receive our newsletter using the form to the right, or stop back here from time to time. Don’t forget to check out the rest of our site and see what we’ve been working on.

I had some conditional logic I needed to test that was based on the current Rails environment. Basically something like:

if Rails.env.production?
# Do something
Elsif Rails.env.staging?
# Do something else
End

I needed to stub out the Rails.env call. I had a quick Google around but I couldn’t really find a way of doing this I was happy with.

The solution

I whipped up this function that allows you to set the Rails environment to whatever you want:

Can’t see this Gist? View it on Github!

Put the above function in your spec file or your spec_helper.rb. The function can be called as such:

Can’t see this Gist? View it on Github!

How does this work?

The Rails.env function looks like this:

Can’t see this Gist? View it on Github!

So all you’re doing is setting the cached instance variable to the environment you want.

Follow Up (June 20, 2011)

So two distinct issue have come up as a result of the above content.

Firstly, there was no ensure meaning that if an exception was raised in the middle of the stub then the environment would be changed for the remaining tests. This was a stupid mistake but, it happens, so I’ve updated the gist and my code.

Secondly, the issue of checking environment in code. The solution for this would be to have a constant in each env file that defines whatever it is you are using the env check for. So in the example I was working with each env file would have a EMAIL_TARGET constant.

You still need to test this, so the stub provided is still useful in this regard.

It doesn’t handle character encodings though so I went about adding that. With the handy rchardet gem and IConv, detecting the character encoding of the incoming string and converting it to UTF-8 was pretty simple. I’ve created a pull request for the gem that will hopefully be accepted.

The essential code is below, and revolves mainly around the detection and conversion. Using //TRANSLIT causes IConv to try and convert the incoming character code to something that exists in the UTF8 character set, and then //IGNORE will ignore any characters that don’t exist in the UTF8 character set. Chaining //TRANSLIT and then //IGNORE will make IConv try a conversion first and then ignore anything it cannot convert.

I used this gem after the above changes to convert about 400,000 records of text data with ASCII, windows-1252, IBM866 and other character encodings from an old SQLite installation to a new postgres database without any issues.

After looking around for a little while I found this: https://github.com/rspec/rspec-core/issues/370

In short: the new RSpec has been broken up into modules a tad more, the one that we require for rspec to run correctly ‘autorun’ is not included by default, so to solve this simply add require ‘rspec/autorun’ to the top of your spec_helper.

Can’t see this Gist? View it on Github!