This week marks the official launch of a project we have been busy working on for the past few months. Since October we have been putting together mobile and web apps for a startup in Perth called Synaptor.
Synaptor is changing the way SMEs in hazardous industries ensure the safety of their people and the environment with innovative mobile and web apps. We’re happy to have been involved in a project for a local company that is going to improve health and safety outcomes in hazardous industries.
We have put together a case study (Synaptor case study) to showcase the products, but here’s a sneak peek below:
Visit the Synaptor website to check out the project, or try out the mobile apps (iPhone/iPad) in the App Store (Observations & Maps)
Last year we wrote about MailCatcher, a gem developed by our own Sam Cochran (@sj26). MailCatcher runs a super simple SMTP server which catches any message sent to it to display in a web interface.
There have been many updates in that time, and MailCatcher has picked up a bit of a following too. It’s still a great tool, so if you’re a developer you should check it out.
Here’s some feedback from around the web:
“Ruby Mailcatcher should be deployed in every local development environment, regardless of whether you’re using Ruby.” – @brightball (link)
“Learn about one of @srbiv’s favorite gems – http://mailcatcher.me our latest blog post:” – @highgroove (link)
“MailCatcher is one of the better email testing gems I’ve seen.” – @hkarthik (link)
In any given week our company is typically developing five projects at once, with teams of one to three. We run one-week sprints with a half day planning session on Monday morning, and a review session on Friday afternoon.
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.
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.
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.
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).
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.
