Barcelona Ruby Conference 2014

After two very exciting and enjoyable days, the Barcelona Ruby Conference (2014 edition) is over, so here are a few things I’ve learned about and/or liked. I’ll mention these in no particular order as long as the memory is still fresh.

Barcelone Ruby Conference Poster

Barcelone Ruby Conference 2014

Over one of the lunches I discussed ways to improve coding skills online with some people at my table. For those interested in mathematical puzzles I suggested to have a look at Project Euler, at site that offers interesting and sometimes very hard to solved problems. Someone recommended rubeque, where you can “hone your Ruby skills by solving small Ruby problems while competing against other Rubyists.” Then there is Ruby Koans, where you can learn Ruby by making test cases pass.

One Tom Stuart presented some ways to avoid literals in Ruby in his (lightning) talk. Awesome, funny and probably not meant for production code.
The other Tom Stuart talked about his favourite algorithm, the Burrows–Wheeler transform, in his lightning talk.

Erik Michaels-Ober showed how to write fast Ruby. His examples showed that the faster code can also be the code that’s easier to understand. I hope that he’ll put his slides online sometime, because a) they contain all the examples he presented and b) they were very nicely illustrated.

Leon Gersing‘s presentation “Keep Software Weird” was inspiring, funny and, well, Zen. A quote from his talk: “Code is a living representation of who you are, right now.”

I also really enjoyed talking to the people form KeepFocus (including, but not Limited to Jakob, Palle and Jan).

Thank you to everyone involved in making this conference so enjoyable and exciting!

It’s Not Always A Commit That Breaks the Build

In many cases a red build means, that some commit to the version control system broke it.

However, occasionally it can be something as simple as waiting that breaks it. Here’s what happened to me very recently when changing a Ruby project:

  1. I didn’t commit (& push) to one of my projects for a while.
  2. Then I made a pretty minor change.
  3. The local test run was fine.
  4. So I committed & pushed the change to GitHub.
  5. The builds on Travis-CI turned red.
  6. Oh?!?

What happened?

Travis-CI always sets up an entirely new environment, including this:

bundle install

Now, RSpec has been updated (to 3.0.0) since the last test execution on Travis, and I didn’t specify a version in the Gemfile (actually the gem spec file of the project), and I didn’t specify which RSpec version to use, and some RSpec methods have been changed in the meantime.

In particular, some of the specs used be_true, to check a number of predicate methods. However the new RSpec way is to use is_truthy (and its counterpart is_falsey). These methods check something slightly different compared to this line:

expect(value).to be true

In RSpec 3.0 only true is true, and everything that is interpreted as true (everything other than false and nil) is truthy. Also note the absent underscore in be_true (as used in earlier versions of RSpec). See this short example of RSpec:

describe 'RSpec 3.0 true vs. truthy' do
  it {expect(true).to be_truthy}
  it {expect(true).to be true}
  it {expect(1).to be_truthy}
  it {expect(1).not_to be true}
end

Notice here, that 1 is truthy, but not true.

Lesson learned

In order to avoid trouble like this, it seems to be a good idea to fix gem versions for a project in the Gemfile (or the gemspec).

This can avoid broken builds on your Continuous Integration Service (as in my case), but it can also prevent a new team member from struggling through dependency issues after running the bundle command to set up a new machine for development. See, for example “Ruby’s Pessimistic Operator” and “Ruby Gems Guides – Patterns” on how to use the ‘twiddle wakka’ operator for gem versions.

Breaking Stories Into Tasks With Meta Stories

In this post I present an idea we had in a meeting recently. I am not sure it’s a good idea and would definitely like to know what you think about it.

The Setup

One way to look at teams implementing stories is this: Stories are pulled from a queue, then implemented and finally handed over to ‘business’, to decide whether or not a story is put into production.

Stories flow from a queue thought the team into a state 'done'

Stories flow from a queue thought the team into a state ‘done’

In many typical setups there’s another process which is used to break down stories into small enough tasks which can actually be implemented. At some point there’s also a decision to be made about the order in which to implement the stories, but that’s not a topic of this post.

Often the breakdown is done in a whole-team meeting, which can be as long as half a day. The goal of this meeting is to find tasks for a number of stories.

The Idea

Avoid the ‘whole-team story-break-down meeting’ and instead have ‘meta stories’ which are put into the queue.  Each meta story is about cutting only one story into tasks.

  • Not all the team members have to work on this (although all can).
  • Meta stories are put into the queue whenever there’s a risk that the team might run out of unimplemented stories.
  • This is the main reason to give a high enough priority to meta stories: It’s in the very interest of a product owner (or however the role may be called) to provide enough work to the team.
  • As soon as the meta story is broken into tasks, it can be prioritised and put into the corresponding position in the story queue.

Questions & Leaving Thoughts

I personally think it’s worth trying, probably in the form of a time-boxed experiment. There should be a way to decide whether or not, much like J. B. Rainsberger describes it in this presentation on vimeo. The description of running this kind of experiment starts around minute 30, but really, watch the whole video.

Can this work? Will it work? Has anybody tried this before? If yes: In what context? What were lessons learned?

Tools for Testing — 2

Just like the first tool for testing ‘GraphViz’ I briefly described earlier, today’s tool is not limited to be used in testing.

In most of my projects, I use the command line a lot. My colleague Marcus Franke pointed me to autojump, which allows you to quickly navigate directory structures, as well as open folders in a GUI tool like the Finder (or Pathfinder) on a Mac (and I’m sure it works similarly on Windows & Linux).

As the project page says:

autojump is a faster way to navigate your filesystem. It works by maintaining a database of the directories you use the most from the command line.

I use a Mac (most of the time) as well as Homebrew, so the installation of autojump was simple:

brew install autojump

After using cd to navigate to my most visited directories to ‘train’ auto jump, I can use ‘j d’ to jump into my dev folder, which is where I keep all my project directories:

$ j d
/Users/stephan/dev
~/dev $

Yes, it’s just three key strokes: ‘j’, space and ‘d’. I like this quick way to jump between directories, because it’s a lot less typing (compared to entering the real path names) and moving back and forth in the directory structure is pretty easy and fast.

Word of The Year 2014

In the same way I did last year, I have picked a ‘word of the year’ (see my posts from late 2012 ‘Word of The Year 2013‘ and December 2013, ‘A Year of Explore‘).

For 2014, I go for ‘Create':

Word of The Year 2014

Do you pick a word of the year for 2014? Which one?

Follow

Get every new post delivered to your Inbox.

Join 640 other followers

%d bloggers like this: