Announcement: Workshop & ebook: “Fast Feedback Using Ruby”

At the “London Tester Gathering Workshops 2015” (also see #LTGWorkshops on Twitter) I offer a workshop “Fast Feedback Loops & Fun with Ruby”. For this, I wanted to give attendees a handout, to make applying the stuff covered easier and it was planned to be a list of brief recipes.
Suffice to say that the handout grew (and it’s entirely possible that this is ‘feature creep’ in action). In fact, it grew to the point that I decided to turn it into an ebook. The book is not done yet, there’s some copy editing to do.

Fast Feedback Using Ruby

In any case: There will be an ebook, and it will be available on LeanPub at https://leanpub.com/fastfeedbackusingruby/. If you’re interested, please leave a note on the book’s pages.

London Tester Gathering Workshops 2015: “Fast Feedback Loops & Fun with Ruby”

My workshop at the London Tester Gathering Workshops 2015 is announced now! They’re offering an early bird rate until the 18th February, by the way. Find the abstract on the conference page or just read ahead. 🙂

Fast Feedback Loops & Fun with Ruby

Ruby is “a Programmer’s best friend”. Let’s use Ruby to get feedback including getting feedback automatically when working on projects. Whether it’s about transforming source code into test results (a.k.a. running automated tests) or generating image files from raw data, Ruby can be used to automate these tasks. Furthermore, it can also be used to automate actually running these tasks, e.g. upon saving a file to disk. Does that sound like a good idea? This session is for you.

I regularly bump into tasks that are…

  1. tedious, if done manually
  2. not done often enough, unless automated
  3. still not done often enough, unless running them is automated, too.

In the workshop we’ll combine some Ruby tools to remedy this situation. In particular the workshop will cover:

  1. Writing a simple Ruby program that does something useful, e.g. turn a markdown file into HTML
  2. Wrapping that in a Rake task
  3. Automate running the task

Knowing how to do this is useful, not only for projects using Ruby as their primary language, but can be handy in all projects.

What is expected:

  • Some Ruby knowledge; you don’t have to be an expert or anything like that.
  • A notebook (or tablet) with an internet connection & Ruby installed.
    Cool if you’re using RVM, rbenv, chruby or similar
  • Mac OS X, BSD; Linux & friends are fine, Windows may be a bit problematic.

 

London Tester Gathering Workshops 2015: Early News

There’s news about the London Tester Gathering Workshops 2015: I’ll offer one of the workshops!

I’m sure we’ll have a couple of exiting days talking about software testing. And not only talking but also some hands-on stuff using Ruby for fun and (fast) feedback.

Before I publish more information about my workshop, I’d like it to…

look right

Stay tuned!

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.

%d bloggers like this: