Blog Archives

Learn Ruby with the Ruby Koans

Posted in Agile Development, Code, Inside TFG, Ruby on Rails, Websites or Tools

If you’re looking for an engaging and interactive way to learn Ruby, I’d recommend Ruby Koans by EdgeCase. I think that the koans are especially interesting if you’re coming from another programming language like PHP or Java, because they rely on some basic programming knowledge, but don’t presume any Ruby-specific abilities.

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.

Guest Series: Peter Cooper – Capybara-WebKit: Bringing WebKit to your integration tests

Posted in Ruby on Rails, Websites or Tools

Today we bring you the first in a series of guest posts on our TFG blog. This post is written by Peter Cooper, editor of Ruby Inside and Ruby Weekly.

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 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.


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.


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):


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")

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.

Catch mail and serve it through a dream with MailCatcher

Posted in Ruby on Rails, Websites or Tools

Here at The Frontier Group we were having trouble finding a simple, extensible way to look at email sent out by our web applications during development. After trying quite a few alternatives, one of our developers Sam Cochran sat down in some spare time and forced slender man into skinny jeans strapped to a mailbox to create MailCatcher.

MailCatcher is a ruby mashup to catch mail sent via SMTP to a local port and serve it in your web browser for easy testing. It lets you check out the plain text and HTML versions of the email, as well as inspecting any attachments. Thanks to WebSockets (in Google Chrome, at least) you’ll see new mail instantly as it arrives.

MailCatcher v0.3.0 displaying a message

Installation and usage instructions can be found on the project home page. Over the coming weeks I look forward to sharing some more of our open source contributions from within TFG.

Adding additional processing support to CarrierWave

Posted in Code, Inside TFG, Ruby on Rails, Tips and Tricks, Websites or Tools

CarrierWave is a great gem for adding image uploading and basic processing abilities to your Rails applications. By default there is no way to set the quality of the resized images, which could be a very useful feature.

One of the applications that we’re currently building has a requirement to resize and compress images to produce smaller file sizes, as well as stripping out any personal information that may be stored in the uploaded images.

Out of the box CarrierWave provides a consistent interface to process images using RMagick, MiniMagick or ImageScience. Resizing and cropping is supported for all three image processing engines but setting the quality or removing personal data is not supported. Thankfully, CarrierWave provides an easy way to extend the default functionality so we can do more.

For the examples I’ll be adding extra functionality to RMagick processing. If you’re using MiniMagick or ImageScience the methods will need to be altered to work correctly. We’ll start by adding a new initializer into our application.


You may be wondering about the fix_exif_rotation method. Well, some modern cameras always take photos upright, in portrait. When you take a photo in landscape mode the photo is actually saved as a portrait, but the photo will contain some extra orientation metadata. When we remove the embedded data in the photo this value gets removed, so as a result we need to manually rotate the photo, which is what this method does.

The application server will need to be restarted before the new initializer can be used. Once restarted the new filters can be used in an uploader like so:


That’s it! That’s all that’s needed to add extra quality and processing functionality to carrierwave.

Search Posts

Featured Posts



View more archives