The Year 2011 — A Summary

Wow, another year over already. It feels like it was just recently that I wrote a summary of 2010. Tomorrow is Christmas Eve, so it's about time that I try to sum up this year. And what a year it's been.

One of the highlights this year, just like last year, was our conference Nordic Ruby. I feel like this year was even better than last year, with amazing speakers such as Chad Fowler and Aaron Patterson, a party on an 18th century style ship, and 150 fantastic attendees. Next year we're trying something quite different, and I think it's going to be awesome. Keep a look out for the new web site for Nordic Ruby 2012.

Aaron Patterson at Nordic Ruby 2011

Aaron Patterson at Nordic Ruby 2011. Photo by Athega.

Right around the same time as Nordic Ruby, we said goodbye to our partners at Edithouse, and moved to our own space. Our new office is in a fantastic 19th century building, the old offices of the famous Gothenburg camera makers Hasselblad. We love our new office, and others seem to like it too, as we made the finals in a competition for Sweden's nicest office. Feel free to come visit us, we love having guests. If you can't make it, check out the pictures of our new office.

Our new office, in the Hasselblad building

We didn't just move out from Edithouse's office, but we also bought back their shares in Elabs. Right now I'm the full owner of the company. The main reason for this was that the collaboration that we envisioned when I started Elabs together with Edithouse never happened. In 2008 and 2009 Edithouse's business changed, and we set our own course. Our own office and ownership reflects our independence, and that feels great. Personally, I still want to say Thank you to Edithouse for helping get Elabs off the ground in 2008.

Another side of our move was that we decided to close down our Stockholm office. While we had some great projects there, for clients like Bonnier's Mag+ and TV4 Play, it was hard having people spread out. One of the best things about Elabs is our culture. Our way of working together, and our camaraderie. Extending that across the country wasn't easy, and it didn't feel fair to Ingemar and Dennis, working by themselves in Stockholm. We asked them if they wanted to join us in Gothenburg, but they decided to stay in Stockholm, and are now working for our clients Mynewsdesk and Mag+. I wish them the best of luck there.

To make up for the loss of Ingemar and Dennis, we've started hiring again! In August, we welcomed Kim Burgestrand to our team. Kim had been freelancing with us while he was on a break from his studies, and we're very happy that he decided to join us full-time. We'll be hiring more developers next year, so if you're interested in joining a fantastic team, let us know!

In 2011, we really ramped up our public speaking. We spoke at a whole bunch of different conferences all over the world. Here's a list, with links to videos of most of them:

Phew! Quite intense! In between working on client projects and speaking at conferences, our developers still found time to release some great open source projects. Nicklas released his Rails account management engine bento, and Anders released the model factory jay_z and the restful HTTP library resto. Kim did a bunch of work on Hallon, his delicious Ruby bindings to the official Spotify API. Jonas released capybara 1.0, an integration testing library used by most Ruby developers. Later in the year, he also released the brand new library turnip, an alternative to Cucumber.

In recognition for his outstanding open source efforts, Jonas received a Ruby Hero Award at RailsConf in May. We're so proud of him!

Jonas Nicklas, one of the Ruby Heroes 2011

During the year we've had the opportunity to work with some fantastic people. We've worked with some great companies in the US (such as Engine Yard, Stackmob, and LivingSocial), as well as some cool Swedish startups (like Naturkartan and Saltside), and some big established companies like TV4 and Bonnier. A big thank you to all of our clients! We're looking forward to more great projects next year.

Yesterday, our last day of work this year, we said goodbye to Antony. Antony's been working with us for almost two years, and he's been a fantastic part of the team. Now he's striking out on his own with a project related to his other big passion, photography, and we wish him the best of luck. Thank you Antony for all your great work, and for keeping our spirits high at the office. We'll miss you!

Now were taking a break over the holidays, and we'll be back on January 2nd, ready for another exciting year.

Happy holidays!

/ CJ & the Elabs team

Merry Christmas from Elabs

PS. If you want to keep up with what we're doing, follow us on Twitter or check out our Facebook page. Thanks!


Solving Cucumber's Problems

Cucumber took the Rails community by storm a couple of years ago. For the first time, we had an easy way of excercising the full stack of our applications. Many people didn't even realize that behind the scenes there was another library, Webrat, doing all the hard work. Cucumber became the de-facto way of writing end-to-end tests in Ruby.

When I wrote Capybara, it was mostly to improve the experience of writing Cucumber features. Over time however, with the arrival on the scene of Steak and similar approaches, people realized that the Capybara API was quite efficient at driving acceptance tests on its own and began using it with just plain RSpec or another testing framework.

And all was well, case closed, right?

Over the last year, I kind of abandoned cucumber, to write acceptance tests in plain Ruby, Capybara and RSpec. Throughout this experience, I have tried to keep an open mind. My verdict is: I don't buy it. In the beginning, it was fantastic, the overhead of Cucumber was gone, we were insanely productive. But over time, cracks appeared. As the projects grew larger, the tests became more and more difficult to maintain. I have since tried to figure out why this is.

Imagine the scenario of creating a task with a particular title, in Capybara, this might look something like this:

fill_in('Title', :with => 'Buy milk')

Simple enough. Imagine that we do this a lot, now we want to abstract this. Also quite convenient:

create_task(:title => 'Buy milk')

That looks good. Now imagine that this task is attached to a milestone:

milestone = create_milestone('name' => '1.0')
create_task(:title => 'Buy milk', :milestone => '1.0')
create_task(:title => 'Drink milk', :milestone => '1.0')

That's quite okay too, but what if this is a common pattern, a milestone with multiple tasks?

create_milestone('name' => '1.0', :tasks => ['Buy milk', 'Drink milk'])

That looks fantastic!

Here's the problem though: no one ever builds this abstraction. There is so much overhead involved in implementing the create_milestone method, that in practice, it's simply not done. It's certainly not done for the first acceptance test that could have used it. And herein lies the whole crux of the problem: the default behaviour for acceptance tests in Ruby is to be unnecessarily verbose, and you have to constantly fight this behaviour in order to write maintainable tests.

It is in abstracting these kinds of common patterns that Cucumber shines. In fact, this abstraction is probably still at too high a level for Cukes. If cukes are written like this:

Given there is a milestone called "1.0"
And there is a task called "Buy milk" for the milestone "1.0"
And there is a task called "Drink milk" for the milestone "1.0"
When I visit the homepage
And I click "Milestones"
And I click "1.0"
Then I should see "Buy milk"
And I should see "Drink milk"

Then you are not gaining any benefit from cucumber at all. You really want something like this:

Given I am looking at a milestone with the tasks "Buy milk" and "Drink milk"
Then I should see "Buy milk" and "Drink milk"

In my experience, it's very difficult to write tests at this level of abstraction with Ruby and a lot easier to write them with Gherkin, the language that cucumber features are written in.


Still, going back to Cucumber after being in Ruby land for a while, I encountered a number of problems. These are the same problems that are mentioned by many abandoning cucumber for plain Ruby.

  1. Having a separate test framework is annoying
  2. Mapping steps to regexps is hard
  3. Cucumber has a huge, messy codebase
  4. Steps are always global

I have written a new library, which I believe solves these problems.


Turnip parses Gherkin feature files and runs them in RSpec. You run your feature files the exact same way you would run a normal spec file, and they are automatically run when you run your RSpec suite. So to run a feature file with Turnip, you would do something like:

$ rspec spec/acceptance/view_milestone.feature

Steps are implemented with strings instead of regexps, like this:

step "there is a task called :name" do |title|
  Task.create(:title => title)

It still allows for some variation in natural language by allowing a pseudo syntax for optional letters or alternative words:

step "there is/are :count monster(s)" do |count|

Just like Markdown, we're aiming for something which follows the natural conventions of writing text, instead of using the more arcane regexp syntax. The idea is to cover the 90% use case very well, instead of allowing every possible variation.

Turnip was written just to solve this particular, rather simple problem. There is no support for other programming languages, no wire protocol, it doesn't have its own runner or formatters or anything. Its only dependencies are rspec and gherkin.

In Turnip, steps can be local by scoping them to tags:

steps_for :interface do
  step "I do it" do
    click_link('Do it')

steps_for :database do
  step "I do it" do!

Now just tag the scenarios with the @interface and @database tags and you have different behaviour for the same step in different scenarios.

Scenario: do it through the interface
  When I do it

Scenario: do it through the database
  When I do it


I don't know if Turnip solves the problems that Cucumber has. I don't know if Cucumber is the right solution for you. I do believe that Cucumber has a lot of benefits which the hivemind of this community has too easily dismissed this past year or so. I have tried to separate the ideas of Cucumber from its implementation. Try it out and see if you like the result!


Lean Startup Camp in Tokyo

The Lean Startup Camp

Inspiration. If I have to pick one word to describe The New Context Conference held by Digital Garage in Tokyo November 3rd to 4th, it's inspiration. CJ was invited to speak about integrated design and development.

The conference, also called Lean Startup Camp, was inspired by the book The Lean Startup by Eric Ries. A book that teaches entrepreneurs how to be more innovative, stop wasting people's time and be more successful. The most frequently used words during the conference talks were lean, agile and design. Something that Digital Garage hopes will inspire the attendees to go out and change the way Japanese companies work today.

You need a compass, not a map

When working the agile way you need to know what direction you're heading but not the precise way. Joi Ito talked about how things change along the way and how you should embrace that.

Our friend Ian McFarland, CTO at Digital Garage, held a keynote about the importance of design to make better software. A subject that the speakers and panels kept returning to throughout the day.

The first panel discussed how design is about experience, not looks, and how a designer's most important job is to understand the user. It's important to be agile about design, doing things in small iterations, doing a lot of testing and getting feedback. Don't be afraid to fail. Failure is discovery, a learning process.

Why build something until you know if it will work?

Kate Rutter talked about how to use a MVP, Minimum Viable Product, to get useful feedback from users before investing too much time in building a full product. It can be a sketch on a paper or a really small application. Our friends at Hyper Tiny emphasised the importance of finding the one important thing about a product and focusing on that. Say no to all other features.

Agile Blues

There seem to be a lot of rules when working agile. If you are new to the agile way this can feel discouraging, do you really need to follow the rules? Yes and No.

I like the comparison Joe O'Brien made between the agile way and blues music. There are a lot of rules, but when you know the rules you can break them and build/compose exceptional products/music.

Preparing, Sharing and Caring

CJ talked about how we work at Elabs, the importance of letting designers and developers work together. You should start every project with the whole team, preparing together. If everyone is in from the beginning there will be a better understanding between designers, developers and the client, which will result in a better product. During the project designers and developers can be more efficient by working in the same code base and pair programming. Last, the most important part is that developers care about the design and designers care about the code. Getting rid of the "not my job" mentality.

Integrated Design and Development panel

Get feedback

The first day was wrapped up with a talk from Janice Fraser. According to her the most important thing is to get out of the building, get to know your customers before you build your product. Learn who is going to use your product and what they are going to use it for. Make MVPs and remember that it's hard to build a new product, it takes time. She emphasised the continuous cycle of: build - measure - learn, or think - make - check.

We had a great time in Tokyo and met a lot of interesting people. The Lean Startup Camp was a very well produced conference and we are very happy to have been a part of it.

Arigatō gozaimasu.


Streamio Marketing Site - the Design Process

I will explain my typical process when designing a marketing site by showing you examples from my work with Streamio.

Why Streamio? Because they are a fun company to work with, easy to cooperate with and they give clear and good feedback.

First I got a mockup from Streamio with some thoughts and wishes. It's actually rare that you get a mockup this good from the customer:

The mockup from Streamio

The mockup from Streamio, which I'm very impressed with. Sooner or later they won't need my help anymore :).

An important thing with a marketing site is to get the user's attention. This is done by giving enough information in a short amount of time, so that the user gets interested and keeps on reading further down. This means that we need to scale down the information, put it in a natural order and keep it simple and clear.

It's quite known how much, or little, we read on the internet. Studies show that we read very little, I myself is a typical example. We browse sites very fast, and it doesn’t take many seconds before we jump to the next one. This is something we have to think about when designing web sites, we only have a couple of seconds to catch the users attention, not much more exposure then a logo. Some interesting articles on the subject are UXMYTHS - People read on the web, How Users Read on the Web and E-Mail Newsletters: Increasing Usability.

The first thing I do in the design process is to look through the information on the customer's mockup. The second step is to make my own interpretations. My first thoughts on the Streamio mockup was that there was too much information and the headlines were unclear. On the following drawings I have scaled down the information and changed the layout in the at the top:

Draw with pencil on paper

I love to draw with pencil on paper - a great way to get your thoughts down at the beginning of the process.

Close-up on Streamio's mockup

Close-up on Streamio's mockup.

Final drawing of the design

My final drawing of the design, which I showed Streamio.

What's left is:

  • a short headline about Streamio: they help you upload and publish videos online.
  • then a picture of a computer and two devices with their video platform or video, to show that it works on all modern platforms.
  • followed by 3 short blurbs about their advantages.
  • the 3 blurbs are then put into one sentence to make it even more clear.
  • a prominent Call-to-Action button makes it easy for the user to try the service.
  • finally there is a price tag with the minimum price.

When I'm done I show the customer the new drawings. This time Streamio was happy with the result, so then I continue with the next step: the real designing.

I design directly in the web browser, which is most efficient today. This way you work closer to the end result and you don't have to work in two steps, like when you're using Photoshop. I do additional graphical elements in Photoshop, but I constantly look at the end result in the web browser. Another great advantage with working in the web browser is that you have access to A LOT of fonts from @font-face services, such as Typekit. Today you can do a lot with the design using html and css3, which I'm sure you already know, but if you want to read more about it you can take a look at Smashing Magazine or NetTuts.

Two fonts

Two fonts used on Streamio's site. The first one is the popular serif FF Tisa which I think is great! It is used for all the content on the site. The second one: FF DIN Pro Condensed, is used for the logo.

First layout

This is my first layout after the drawings. Here I have made the basic layout and placed the content, and made some screenshots and additional graphics. But it is a bit plain and boring.

Streamio likes a very sharp and glossy style, and I won't say no to that. A lot of sites can't pull this of, but I think it gives a great vibe and harmony to this site and it works with Streamio's kind of service.

Some screenshots from the final site:

Final site 1

Final site 2

Final site 3

I really like the last page because it's only built with three images. It's a fun challenge to try to use as few images as possible. This keeps the loading time for the site short, or rather compensate for custom fonts.

Streamio launched their site on March 7th. It looks a bit different from my final version because they combined some of the final design with some of the earlier to create what they want.

Take a look at

In my next blogpost I will write about the design process behind the actual video tool which David at Streamio has developed and I've made the design for.

If you have any comments or questions you can text me on twitter: @leuchovius, thanks!


New Office - Renovations Needed

We recently announced that we'll be moving to a new office later this year. There's lots to do before we can move though, and in this post we'll talk about the current state of the office building, and some of our plans for it.

Pairing room from hallway

What really made us fall in love with the office space, in addition to its history, was all the old details. The building was constructed mid-19th century, and a lot of the original interior is still there.

We feel that the classical elegance and attention to detail really reflects our craftsmanship ideals that we strive to uphold when we develop software. It's a very inspiring environment. The old wooden paneling is classified as historically significant and must be preserved. It really makes the office something out of the ordinary.

Conference room and hallway

The office hasn't been used in quite some time, and needs to be renovated. New flooring and carpeting will be put in, windows will get noise insulation, walls and ceilings will be repainted and some glass partitions will be installed.

The fun part about the renovation is that we really get to tailor the office space to our needs and our style. We're working with a friend of ours, Jesper Larsson, to make this a great environment that we will enjoy working in.

Check out the "before" photos, and come back soon for more info here on our blog.