You can see them by clicking the links below:

Australian Mines
Ramelius Resources
BatteryLimits

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.

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.

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.

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.

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

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:

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

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

Here’s an overview of some of these projects from 2010.

Direct Sponsorship

The Big Geekend – Website donated to host event raising money for Children’s Miracle Network

Australian Children’s Trust – Website donated and discounted hosting (new website under construction)

MosArts (Camelot Outdoor Cinema) – Free website hosting

Bletchley Park Primary School – Sponsorship of Tournament of Minds team

Breast Cancer Care WA – Cash donation

WA Special Needs Children’s Christmas party – Cash donation

Partnerships / Organisations helped

Independent Living Centre of WA – Built and maintained web systems to help them book more appointments and serve more people in the community. Also rebuilt their website to be accessible, more useful to their audience and added an equipment supplier search feature.

Independent Living Centres Australia – Current development of the new website and the national supplier database, integrating seven state-based databases into one.

Parkinsons WA – Built accessible website.

Council for a Parliament of the World’s Religions – Built web based system to organise and run worldwide conference, as well as followup development for future conferences.

West TV – 2011 Official web partner – Development on new website features in 2011.

The Green Network – 2011 Official web partner – Development of new website, launching in February 2011.

Organisations of Interest

Climate Watch

Solar Market

Looking to 2011

Drop in the bucket – Sponsorship drive

And more…

Here’s looking forward to a big year of helping out our local, national and international communities; and sharing those stories with you!

• Slim: A template language
• ØMQ – The Guide
• Enterprise HTML/JS/CSS
• A facebook like is worth 6x a tweet
• Help stop the spread of NIBS (Native is Better Syndrome)
• Making real connections over the web by Ze Frank
• 10 Flaws that made my weekend app possible
• Linux kernel flaw gives root rights

Got some interesting links you’ve found this week that you’d like to share? Link us up in the comments.

• MongoDB CTO on Foursquare’s Scaling Issues
• Unlogo – Removing logos from video
• Faster web development with Virtual Machines
• Recommendations for usability in practice – final version
• Video from a homemade spacecraft – fantastic idea
• Erkie – Make any website fun
• Defining User Experience as Brand Experience
• Mark Zuckerberg on the “Biggest Problem in Social Networking”
• Dive into HTML5
• jQuery Fundamentals
• Hardboiled CSS3 Media Queries
• visualizing.org – Making sense of complex issues through data and design
• Stress first development

Found something interesting on the week this week? Let us know in the comments.

Gemsets and the Gemset Hierarchy

Whilst Bundler solves most of the problems related to isolating gems for me personally, on most projects I develop for there are things that make rvm’s implementation of gemsets (especially when used along with bundler) invaluable to me as a ruby developer.

Isolating Gems

A major strength of RVM is the ability to isolate gems at the system level. This keeps them safely partitioned from any other gems unrelated to my project. The way bundler isolates gems is for the most part at run time – It changes the way rubygems works to solve it’s problem and either installs all gems to a user specified path or to your gem directory.

If you are using the usr specified path option, you must to remember that your custom rubygems bin directory is not contained in your PATH. This means that you must either manually add it to the PATH, or your need to manually prefix each command with bundle exec, or alternatively you can generate the binaries into your applications bin directory and each command with ./bin/

If you take the opposite approach and install your gems into your gem home, you then need to be aware of the fact that each next install will overwrite any previous binaries – the canonical example being Rails 2 and Rails 3. The way that rubygems generates binaries lets you run gem-binary-name _version_ something to call the binary loaded from a specified gem version. Unfortunately, in Rails 3, the rails binary was moved from the rails gem into the railties gem which just so happens to break this feature of rubygems. You can try this for yourself on a new rvm gemset, install rails 2.3.8 and rails 3.0.0 and then try rails _2.3.8_ -v. If you are using the simple solution of installing to gem home, even though you are using bundler it will still overwrite the binary.

One common suggestion is to just create a wrapper binary manually (e.g. rails2) or always prefix your commands with bundle exec. In contrast RVM’s isolation works by explicitly setting rubygems home and path to directories isolated under RVM. RVM takes this even further using gemsets (think subdirectories) to handle more fine grain isolation. For example, I personally use 1 gemset per application, thus avoiding the issues described above as for each application I will have only a single version of rails installed. Even better, switching is shell-local and only persists for a single shell instance. This means that I can have two different applications with two completely different versions of Rails running at the same time in different terminal sessions without issue.

As an added bonus, because RVM isolates at the rubygems system level (using environment variables), your application doesn’t actually need to know or care about conflicts from gems that the application does not use.

Combining RVM and Bundler yields a great deal of flexibility and consisency. This affords you the ‘best of both worlds’, system level isolation with the ability to install gems from git repositories, and in application gem loading based on application environment.

For more information RVM’s gemsets, check out the Gemset’s section on the rvm site. For more information on Bundler, check out Bundler’s documentation.

Gemset Hierarchy

The second feature I use often is the global gemset. Each ruby interpreter installation comes with two gemsets out of the box – the default (blank) gemset (e.g. ree-1.8.7-2010.02) and the global gemset (e.g. ree-1.8.7-2010.02@global). When you use any gemset, rvm not only sets the gem home to a uniq directory for the given gemset (ensuring gems are installed in the correct place) but it also sets GEM_PATH.

Much like PATH, GEM_PATH is a colon separated list of directories that rubygems uses to look up gems when requiring them. By installing a gem to the global gemset for any ruby, e.g. ree-1.8.7-2010.02@global, it will automatically be made available (including it’s binaries) inside both the default gemset and any user-defined gemsets. E.g.,

• ree-1.8.7-2010.02
• ree-1.8.7-2010.02@bighelpmob
• ree-1.8.7-2010.02@tedxperth

Will all have access to gems installed in ree-1.8.7-2010.02@global.

This comes in super handy for things like awesome_print, wirble, bundler, git-up, homesick – Namely, gems you want available in every environment.

Unfortunately, bundler currently does not support multiple items in BUNDLE_PATH. We have hope it will be added in the future but for now gems you want shared between apps using bundler, you’ll get some duplication.

Default Global Gemset Contents

As an added bonus along side the global gemsets, rvm provides a way to declare a file which tells it what gems to install initially. To do this, it uses a ruby string-based directory hierarchy (see the link below) to look for a global.gems file that rvm then imports – For example, my ~/.rvm/gemsets/global.gems (that is imported into the global gemset of all ruby interpreter installs) contains the following simple list:

rake
rdoc
awesome_print
bundler
git-up
ghost
homesick
wirble

For more information on this feature, be sure to read the Automatic Gemset Initialization page on the RVM site.

Set operations

If you are writing gems, one of the most important things you can do as a Ruby developer these days is to ensure they work on all of the major implementations. At the moment, for most gem developers you should generally be testing your code against:

• REE / 1.8.7
• 1.9.2
• Rubinius
• Jruby

And optionally, MagLev and MacRuby. RVM provides tools making it simple to run code and commands against multiple rubies. This includes but is not limited to running Rake tasks and tests / specs. The idea being to make it as frictionless as possible to test your gem against all of the above interpreters. As an example, you can run:

rvm rake test

Which will run rake test against all of your installed ruby interpreters (using default gemset for each). You may need to do some manual setup (e.g. installing test gem dependencies) but rvm tries to make it all as simple as possible and more importantly, heavily integrated into your normal work flow whilst staying out of the way.

Along side rake, rvm also provides wrappers for many common binaries (e.g. ruby, spec and the like) plus the --json and --yaml flags which make it simple to get a summarised view of the program results. Using rvm exec, you can even perform set operations against any arbitrary command.

There is a whole lot more set operations can do and I suggest anyone using or considering using rvm read the set’s section on the rvm site. Go forth and have sets!

Tools for easing dependency-related pains

One of the most commonly encountered problems (since for most people, the ruby interpreter you’d normally use is distributed as a binary install) are related to external dependencies – Namely, things like readline, iconv and openssl.

In an attempt to make life easier (and in particular, work around common problems like a neutered libedit instead of readline on OSX), rvm provides the rvm package set of commands that make it easy to install sandboxed versions of these in the ~/.rvm/usr directory.

As an example, to work around the libedit vs. readline issue on OSX, you can build your ruby against readline 6.0 by running:

rvm package install readline
rvm install <ruby> --with-readline-dir=$HOME/.rvm/usr

And, as an added bonus, to automatically patch older versions of ree and 1.8.7 to respond to Control-C immediately (for example, in irb) instead of when you press enter, you can replace the rvm install command above with:

rvm install <ruby> --with-readline-dir=$HOME/.rvm/usr --patch readline-fix

Simple Ruby Upgrades

Say, for example, a new version of 1.9.2 comes out in the next few weeks and you want to automatically update your rubies to match it correctly. As of approximately rvm 1.0.0, we added an rvm upgrade command that automatically handles doing the following:

• Installing the new ruby
• Moving across gemsets
• Updating wrapper scripts and aliases

The only thing you typically have to update are references in your .rvmrc’s and your passenger configuration. But, with a little forethought (e.g. creating an alias using rvm alias create), it’s entirely possible to make it so the entire upgrade is automatic.

I have personally used this feature to move from the 1.9.2 release candidate to the final patchlevel 0 release – I used rvm upgrade to simplify the process of updating each time it was bumped.

This is currently undocumented on the rvm site but documentation will be added – for the moment, in your rvm install, run rvm help upgrade and/or rvm upgrade help.

Location Matters

One of the underlying decisions related to rvm’s architecture is where it installs your rubies – In most cases, rvm will install your rubies into ~/.rvm/rubies and gems into ~/.rvm/gems. This means that you should almost never have to use sudo for commands (there are a few exceptions, most notably passenger which relies on root permission in order to bind to port 80).

This approach is simple on the scale of things but also brings a lot of freedom – for one, it means you are free to experiment with a Ruby / RVM setup, wiping it away when you’re done with a simple rm -rf ~/.rvm && mv .rvm-original .rvm.

.rvmrc files

All of this is fine and dandy, but when you still have to manually switch ruby interpreters and rubies each time you do something, it can become mildly annoying rather fast. For this exact reason RVM offers project-specific .rvmrc files – If you haven’t encountered them before, project .rvmrc’s are files that are automatically sourced into the current shell when you change (cd) into a directory containing one. These files can contain anything that is valid shell script (and to prevent RVM automatically running code you don’t want, it defaults to asking you to trust it the first time it is run) making things like project bootstrapping and configuration simple and mostly automatic after a quick setup in the project root directory:

rvm --rvmrc --create <ruby>@<gemset>

In my own projects, I use these to automatically install the Ruby if not present, create and use a project-specific gemset and then do the minimum possible required to bootstrap the new environment – in most cases, this is simply a matter of installing a few gems (e.g. for me, I install bundler via rvm gemset import).

In some cases, I even automatically run bundle install (with 1.0, if you have the gems already installed, this is very fast) hence the first time I cd into a project it essentially bootstraps the entire environment for me automatically.

Ultimately, this approach means that the Ruby interpreter and gemset switching are completely transparent to me – No matter which project I’m using, ruby and irb are available and point to the correct executable for the current project I am in. When integrated with some code I wrote for ruby summer of code, it’s even possible to have passenger automatically use this .rvmrc file to automatically change your application’s gemset at run time.

For more information on .rvmrc files, check out the rvmrc page and the Project Workflow page on the rvm site. See RVM’s passenger integration page page for more details on gemsets with passenger.

Conclusion

I hope that you have found at least one new or useful thing about RVM. RVM has been invaluable to me as a developer on multiple open source projects over the last several months. It makes it simple for me to do things that are otherwise harder or less flexible and generally stays out of my way.