Call Us: +44 (0) 203 005 2505

4 Reasons Amazon Drones Aren’t Imminent

Given recent media coverage of Amazon CEO Jeff Bezos’ claim of drones by 2017, David Axe explains why they’re not coming “Batteries Not Included”-esque, hovering to our doors anytime soon. – Leo, Dec 4th 2013 [read more]

Google Go – Golang, next generation language? Google Go – Golang, next generation language?

Google Go – Golang, next generation language?

For those unfamiliar, Google Go, or GoLang has just celebrated its 4th birthday, its still relatively new although critics are already hailing it as a next generation language. [read more]

Agile Coach and Scrum Master – The Difference Agile Coach and Scrum Master – The Difference

Agile Coach and Scrum Master – The Difference

An account of how Agile Coaches and ScrumMasters are defined in the Agile role structure by Joe Townsend here  (no relation!)  - Leo, Nov 12th 2013 [read more]

Unit Testing Best Practices in AngularJS Unit Testing Best Practices in AngularJS

Unit Testing Best Practices in AngularJS

Andy Shora, Senior Front End Developer at RG/A, gives insight into AngularJS testing, advocating Jasmine and Karma for Unit then Integration testing. Particularly like the Chuck Norris reference….. Here‘s a link to Andys blog – Leo Nov 8th 2013 [read more]

Ruby-on-Rails Developers’ new best-friend Clojure Ruby-on-Rails Developers’ new best-friend Clojure

Ruby-on-Rails Developers’ new best-friend Clojure

How one Ruby-on-Rails developer, Adam Pohorecki, came to fall in love with Clojure and why. Adam is a speaker at the Kracow Ruby Users Group, slides to his presentation in conjunction with this  are available at the bottom of the blog link here - Leo, Oct 18th 2013

More Ruby than Ruby talk at KRUG

A few days ago a tweet reminded me about a talk I gave on the 6th of August on KRUG:

One trend I’m observing is a lot of rubyists being fed up with messy ruby ecosystem are getting excited or even switch to clojure.

— Piotr Solnica (@_solnic_) October 15, 2013

I ❤ Ruby

I have been programming in Ruby professionally for over four years now. When I was starting out, there were probably mere dozens of Ruby programmers in Kraków. Compared being one of the thousands of Java developers, programming Ruby felt almost exotic.

Not that long ago, being a Ruby programmer meant being on the bleeding edge of web development. You had to deal with immature and unstable libraries, crappy deployment options and IDEs that didn’t offer much more than syntax highlighting. On the other hand, it also meant working with smarter than average people, who were drawn to this technology not just because it was new, but also because it was in many ways superior to the other options out there. I loved it.

A couple of years have passed and I still love Ruby. I actually love it so much, that I called my dog Ruby. However, the times have changed. Rubyland is no longer the domain of adventurous and industrious early adopters. Ruby is now mature, stable and “enterprise-ready”. Somewhere along the way Ruby has become the responsible choice of a language for building web apps.

Let’s face it: Ruby is a good language to know right now. The jobs are plentiful and well-payed, and the technology is still relatively modern, but progressively more safe and boring. The days of exciting and unpredictable Ruby are almost over, and soon I’ll only be able to like it as a friend.

I ❤ Clojure

I have come across this LISP on the JVM quite a while ago, but having had pretty bad experiences with Common LISP at my university, I never had much interest in it until in May of 2012 I came across a presentation given at RailsConf by Clojure’s creator, Rich Hickey.

I am a huge believer in Single Responsibility Principle. Most of my classes have one public method. I tend to avoid inheritance and heavily favor composition and delegation. Unfortunately, a language like Ruby punishes you for coding in this style – your small classes end up being split amongst hundreds of files and often wrapping a function in a class seems like an overhead.

Watching that video made me realize that maybe I should look into functional programming languages. After all, functions are smaller units of composition, and they are easier to combine. I watched a bunch of other Hickey’s presentations and I got hooked on Clojure.

Compared to other functional languages like Scala or Haskell, Clojure, as a dynamically typed language, was much more up my alley (in the dispute between static typing vs TDD, I stand strongly behind TDD). It also appealed to me more than Erlang, since I mostly work on web apps, and Clojure seems to do better with those.

Clojure > Ruby

I read a couple of books about Clojure, started playing with the language and I fell in love with it.

Let’s start with the fact, that Clojure is perfectly capable of expressing pretty much everything that Ruby can, most of the time just as concisely. This in itself is not much of an achievement, but factor into that the syntax of both languages. Even I could write a parser for Clojure. Do you know anyone who could write a parser for Ruby? Clojure’s syntax is the perfect marriage of power and simplicity.

Clojure has real namespaces, where Ruby only has modules. Clojure’s keywords can be namespaced as well. It avoids Ruby’s method naming problems (like when two libraries adding a method with the same name to a class like String of Array). Clojure has ClojureScript. Clojure is well suited for multithreaded programming. Clojure has macros. Clojure is faster…

I believe that this is a great time to get into Clojure programming. The ecosystem is mature enough that you can find libraries to do pretty much everything you need (even if they are not overly polished). The people in the community are above the average, because they have learned Clojure, not because Clojure programmers are in demand, but because they wanted to. There are also plenty of books, screencasts and other resources to learn Clojure from.

Uncle Bob called Clojure “The Last Programming Language”. I would settle for “The Next Big Thing”. Dig in while it’s hot:)

Thanks for reading, once again, if you’d like to see Adams presentation slide he made to Kracow Ruby User Group, click here - Leo

Agile Contrasts- Project Manager / ScrumMaster Agile Contrasts- Project Manager / ScrumMaster

Agile Contrasts- Project Manager / ScrumMaster

An intriguing blog from Chris Davies, Agile Consultant, 2nd Oct 2013 on contrasting Agile environments and ramifications for some Project Management functions. Source link to Chris’ blog - Leo

Two Agile worlds

Posted on October 2, 2013by 

There is a recurring theme that has been around the agile community for a while now. One so pervading the industry that I have spent quite some time reflecting on it.

Have you noticed that people are questioning the very nature of Agile itself? What IS Agile, people are asking. Is it a set of practices? If so, which ones? Some basic values and principles? Then how do we live them in our workplace, it seems too hard. What do you mean there’s no place for a project manager in Agile? We have loads of them! Speak to people at a conference or two, or even just read through the Agile LinkedIn groups forums and there are lots of examples of this type of question.

These questions (and others) are symptoms of the difficulty some people are having trying to apply ‘agile’ in their own environment. Let’s face it, an internet startup like Groupon or Twitter or Snapchat has a completely different environment to a multi-national Investment bank, a local government department or a defence contractor. A small company trying to figure out what its fledgling product will look like when it’s launched will have a different set of constraints to a company with an old and complex multi-platform architecture with development teams spread across three cities in two countries, a limited budget and a larger portfolio of planned projects than they have people to deliver them.

There are those who believe that Agile means Scrum. And/or XP. It means a small cross-functional team co-located, and delivering in short iterations to get a minimum viable product (MVP) to market as quickly as possible. And then delivering updates as quickly as possible based on feedback from real customers. The Lean Startup model. And these people are passionate about Agile. They live and breathe collaborative estimating and planning, test-driven development, continuous integration and one-click automated deployment. They have no need for project managers with their Big Design Up Front and detailed plans, nor system architects, or sponsors. And don’t even mention governance or… (deep breath) the project management office (PMO). For them Agile is lightweight, non-prescriptive, and fast-paced. It is lean (with a small L).

And there are those for whom this is anathema. Or a distant fantasy – a utopia beyond their wildest dreams. For they believe that their projects just cannot be run in this ill-disciplined manner. That projects need management, and planning, that a portfolio of projects needs governance. That there is a place for Business Analysts and platform-specialist developers, technical co-ordinators, change management teams, and yes the PMO as well. That implementations to Production (of multiple projects) happen maybe once a month (or longer), because there is complexity in parallel development. In this environment the involvement of external suppliers and lengthy contracts are the norm, tools for test-driven development won’t work with the platform and not everything is under source control. The approach to software delivery here is geared around projects – structured, planned endeavours with specific goals and usually a defined end-date.

As you can see, these two worlds (in the extreme examples I illustrate) are very different. Neither is right, neither is wrong. They just are. I call these worlds the Product World and the Project World respectively.

Our beliefs about what is right and proper are generated by our own experiences, knowledge and skills. Those who have experience only of the Product World have a fundamentally different view of what Agile is, and is supposed to be, than those whose only experience is of the Project World.

So we need, I believe, to recognise that these two worlds are very different, and that the same approach to Agile cannot work across both – there is no single transformation recipe, no one ‘best practice’ or method. That each organisation needs a deep understanding of the values and principles behind Agile, and work out the best way to live them in their own organisation. That what is right for one company is not necessarily right for another. And that we should all stop telling each other what is the ‘right’ way, and do more to discuss and learn about other ways in other environments. Sure there are things that we can all learn from other people in different environments, but we can’t assume that they will work the same elsewhere.

Agile is so much more than just a set of practices, and it is not a recipe book. Agile is a philosophy; a way of thinking. And all we can do is be as Agile as we can be, given the constraints under which we are working.

6 Ways-Easier Feature Testing In Ruby On Rails 6 Ways-Easier Feature Testing In Ruby On Rails

6 Ways-Easier Feature Testing In Ruby On Rails

Here’s an interesting Ruby on Rails tutorial on Feature Testing in Ruby on Rails using Rspec from Mitch Lloyd, 2nd Oct 2013 – Leo. Posted On Gaslight ; Mitch is a Developer at Gaslight and speaker at the WindyCityRails conference in Chicago.


Writing feature tests in Ruby on Rails used to be the most painful part of my development work flow. Now I kind of like it. Here’s what’s different:

1 – Don’t Use Cucumber

Disclaimer: The views expressed in the following paragraph do not necessarily represent those of the Staff or Partners of Gaslight Software, LLC.

If you have Cucumber installed, uninstall it. This stuff is already hard enough without trying to parse natural language into Ruby code.

I’m using:

  • Rspec – Testing DSL
  • FactoryGirl – Model Builder
  • Capybara – DOM Dominator
  • Database Cleaner – Database Cleaner
  • Spring – Startup Speeder

I’m happy with these. Let’s make a spec.

feature 'Navigating through workpapers' do
  let(:user) { create(:user) }
  let(:audit) { create(:audit, users: [user]) }

  scenario "User sees workpapers within an audit" do
    workpaper = create(:workpaper, audit: audit)

    visit '/'
    fill_in 'email', with:
    fill_in 'password', with: 'password'
    click_on 'Log In'

    expect(page).to have_css?('.workpaper', text:

This doesn’t look too bad but a more complicated feature would really start to get muddy and the login logic will eventually be duplicated between tests. Even this example doesn’t read as well as I would like.

2 – Use Page Objects

Capybara selectors are likely to break as development continues. Your copy-writer decides the login button should say “Sign into a world of possibilities”. Now you need to fix your tests.

Page objects are adapters to the specifics of your DOM. When the markup changes, you’ll know exactly where to go to fix the issues.

Here’s a login page object:

class LoginPage
  include Capybara::DSL

  def visit_page
    visit '/'

  def login(user)
    fill_in 'email', with:
    fill_in 'password', with: 'password'
    click_on 'Log In'

Here is another page object for the Workpaper index page:

class WorkpaperIndexPage
  include Capybara::DSL

  def select_audit(audit)

  def has_workpaper?(workpaper)
    has_css?('.workpaper', text:

Here’s the new test using these page objects:

feature 'Navigating through workpapers' do
  let(:user) { create(:user) }
  let(:audit) { create(:audit, users: [user]) }
  let(:login_page) { }
  let(:workpaper_page) { }

  scenario "User sees workpapers within an audit" do
    workpaper = create(:workpaper, audit: audit)

    expect(workpaper_page).to have_workpaper(workpaper)

Now let’s say someone keeps tweaking that login button. You can pop into the Login page, start using an ID selector or an I18n entry (which might even have been a good idea upfront), and not worry about changing any other test code. All of that page fiddlyness is contained in the page objects.

These page objects are very minimal, but they can grow to provide additional error checking as the user navigates through the UI or pass off other pages (or sections of pages) to assert on and interact with. Page objects pay off so often and so much that I always use page objects in my feature tests. Just as I never write SQL in my Rails views, I never access the DOM in a feature test without a page object.

3 – Create Useful Failure Messages

Failing feature tests can be hard to diagnose. Let’s say you used a page object like this:

expect(workpaper_page).to have_one_workpaper(workpaper)
Failure/Error: expect(workpaper_page).to have_one_workpaper(workpaper)
  expected #has_one_workpaper?(workpaper) to return true, got false

The expectation is readable, but it would be even better to know whether the workpaper was missing or whether there were other workpapers there causing the expectation to fail.

In practice I’ve raised exceptions when calling these type of predicate methods on page objects.

Failure/Error: expect(workpaper_page).to have_one_workpaper(workpaper)
    expected one workpaper called "My Sweet Workpaper", but the following
    workpapers were on the page:
      * "Bogus Workpaper"
      * "My Sweet Workpaper"

I’ve been using this technique sparingly and I’m still looking for a more elegant approach, but this helps me to get more descriptive error messages and avoid debugging trips to the browser. Let me know if you have some good ways of integrating messages like this into your tests.

4 – Embrace Asynchronous Testing

Many frustrations with browser automation testing stem from mistakes using assertions that need to wait. Adding a sleep to your tests an okay way to debug code if you think you have a timing issue, but sleep should should never make it into your final test code.

Flickering tests (tests that fail intermittently) will kill your confidence in your test suit. They should be fixed or deleted.

In general, my best advice is to learn the Capybara API well. Here are some pointers:

  • Using #all does not wait, so this is probably not the matcher you want.
  • The #has_css? method takes a count parameter so that you can indicate how many matching elements you want to wait for.
  • Asserting something like expect(page).to_not have_css('.post') is usually not what you want. This matcher waits for .post elements to show up before it can pass, resulting in a big delay. Usually you’ll want to use expect(page).to have_no_css('.post') which will pass immediately if the elements are not there, but wait for them to disappear if they are there. To use this matcher with confidence you’ll first want to assert that there were posts at some point earlier.

At times you may want to wait for something to happen outside of Capybara. For that, this handy eventually helper will save the day:

The following code waits for the workpaper to be awesome and fails if the expectation is not met within 2 seconds.

eventually { expect(workpaper).to be_awesome }

But when would you ever make a polling assertion like this without Capybara? Read on…

5 – Get Serious About Data Building

Early on I remember hearing a mantra for feature tests that went something like “Do everything from the perspective of the user”. This advice primarily served to discourage testers from manually manipulating your data in feature tests. I can confidently say that this was bad advice. It’s impractical to sign up a new user with a credit card and complete 20 other provisioning steps just to click an approval button.

I use FactoryGirl extensively for setting up data in tests. This means that I have factories that that can generate complicated objects. For instance here is a way to make a workpaper with a worflow that has steps assigned to certain users called preparers and reviewers.

FactoryGirl.define do
  factory :workpaper do
    sequence(:name) {|n| "workpaper #{n}"}

    factory :assigned_workpaper do
      ignore do
        preparer { create(:user) }
        reviewer { create(:user) }

      after(:create) do |workpaper, evaluator|
        create(:assigned_workflow, workpaper: workpaper, preparer: evaluator.preparer, reviewer: evaluator.reviewer)

  factory :workflow do
    factory :assigned_workflow do
      ignore do
        preparer { create(:user) }
        reviewer false

      after(:create) do |workflow, evaluator|
        create(:step, workflow: workflow, user: evaluator.preparer)

        if evaluator.reviewer
          create(:step, workflow: workflow, user: evaluator.reviewer)

  factory :step

This lets me create specific, declarative objects for my tests:

create(:assigned_workpaper, preparer: first_user, reviewer: second_user)

I always create database models through FactoryGirl in my feature tests. I’m definitely a fan of FactoryGirl, but I think there is probably room for improvement for building complex data like this. Whatever tool you use, the data setup for your tests should be readable, easy to use, and well-factored.

Not only is it acceptable to setup data before you begin your test, it’s also acceptable to assert that another side effect occurred that is not immediately visible to users. For instance, in the world of rich client web apps, seeing something on the screen doesn’t mean that everything has been successfully persisted in the database.

Just as we have helpers for building up the data, we should have helpers for inspecting it. This assertion will make sure that the preparer for a workpaper has been successfully saved in the database:

eventually { preparer_for(workpaper).should be(preparer) }

6 – Prefer Refining Existing Tests Over Creating New Ones

When I started doing feature tests in Rails I got some advice that went something like “each test should have one user action and one assertion”. So I worked like this:

  1. Write a cucumber scenario for a feature.
  2. Make the code work.
  3. Write another cucumber scenario for a new aspect of that feature.
  4. Make the code work.

While this is a useful guideline for unit tests, this is not good advice for feature tests.

Let’s say I have a test like this:

scenario "assigning a reviewer to a workpaper" do
  user_visits_workpaper(user, workpaper)
  eventually { expect(reviewer_for workpaper).to eq(other_tester) }

When we call ui.begin_assigning_reviewer a modal dialog pops up that lets the user pick someone to assign as a reviewer. That feature works. Great.

Now I want to make sure that only users with access to review show up in that modal dialog. Instead of making a new spec for that, I would rather refine the one that I already have.

scenario "assigning a reviewer to a workpaper" do
  user_visits_workpaper(user, workpaper)
  expect(ui).to have_excluded_user(non_reviewer)
  eventually { expect(reviewer_for workpaper).to eq(other_tester) }

You would not want to use this approach in unit tests, but this works in feature tests where the goal is to guide your progress and efficiently detect regressions.

But Who’s Testing Your Tests?

When you start building a lot of logic into you tests someone will eventually say “But who’s testing your tests?” to imply that your tests are too complicated or over-engineered. Your production code tests your tests. Don’t use the sentiment in this question to justify poorly-factored, unreadable feature tests.

The specific tools and techniques discussed above will change over time but I have heightened my sensitivity to bad feature tests forever. Refactor aggressively, design thoughtfully, and love your feature tests.

Posted On Gaslight

Recommend Recruitment Launch Recommend Recruitment Launch

Recommend Recruitment Launch

So this is it, we’ve finally launched our world changing recruitment agency! Recommend Recruitment is born from distinctive and meticulous networking [read more]