Category: Learning

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.

A Year of ‘Explore’

At the end of last year, I decided I would not make any new year’s resolutions in favour of selecting a ‘word of the year’, see the blog post from early 2013. I picked the word ‘explore for 2013 and since the year is (nearly) over, it’s time to look back and see how it worked out.

The Black Box Software Testing Courses

At the time of this writing there are four BBST (Black Box Software Testing) courses the Association for Software Testing offers:

  1. Foundations
  2. Test Design
  3. Bug Advocacy
  4. Instructors

I took the first three of them in the first half of 2013, and the last one in October. And while I do recommend taking these courses, I have to say that I needed a good amount of time to work through all the material, labs & exercises. Especially the ‘Test Design’ course offered a phenomenal amount of material.

I totally recommend these courses to everyone working in software testing and software development in general.

Conferences

For a while now, I try to go to two conferences each year, a programmer conference as well as a tester conference. I used to recommend this to my fellow ‘programming tester colleagues’, but now I’ve also started to recommend it to the ‘testing programmers’ as well. While I focus on software testing, I find it useful to know a bit about programming, too.

I hoped to be able to go to the EuRuKo (European Ruby Conference) in Athens, Greece in summer. In the end it didn’t work out as planned and I couldn’t go. However, I gave my ticket away and received two post cards in return. Thank you, you know who you are.

In September I attended the BARUCO, the ‘Barcelona Ruby Conference’ in Spain, and in October I went to the Agile Testing Days in Potsdam, Germany. At both conferences I gave short presentations about testing and the two values of software. Furthermore, at the Agile Testing Days I had the pleasure to assist Lisa Crispin and Janet Gregory at the  beginning of their keynote presentation:

A remark: The BBST Instructors course and the Agile Testing Days overlapped a bit. If you can, I suggest to avoid a commitment like that. Although it did work for me (in the end), this is a way of exploring, I’ll avoid in the future.

Projects

Early this year, I wanted to try some rather short software testing projects and joined uTest (now renamed to be Applause), where I worked on several apps for mobile devices as well as OS X. Given my background with longer running projects, having just a few days for testing was a refreshing experience. I also joined a project using Calabash to automate testing (well, checking actually) on Android devices.

In late June I joined a new longer running project using a whole bunch of technologies I’ve heard about before, but which were new to me – Another way to explore! So now I work in a project using MongoDB, VarnishPuppet and Vagrant. All of them are really interesting technologies, and the team doesn’t stop there: Every now and then we take a day to, well, explore new ways that may improve our work.

Summary

It’s been a very exciting and busy year and I am convinced that picking a ‘word of the year’ instead of making new year’s resolutions made a big difference. Instead of a plan, I felt I had some guidance that helped in deciding what to do (and what not to do in some cases). I will pick a word of the year for 2014 as well and if you also pick one, or if you already had one for 2013, why not write a short comment whether (or not) it helped you and in which way?

Navigation

%d bloggers like this: