Author: Stephan

About Stephan

I'm a self-employed software tester. I test and write software, listen to music and go hiking — sometimes simultaneously. Prior to this was a physicist and oceanographer, among other things.

Agile Testing Days 2022

It’s that season again: I attended the 2022 edition of the Agile Testing Days. There are already blog posts by Lisi Hocke ‘Agile Testing Days 2022 – The Unicorn Land We Build Together‘ and Stéphanie DesbyWhat I’ve learned at Agile Testing Days 2022‘. They already cover a lot of the remarkable sessions – and really, I think there’s no replacement to attend this conference in person. I’ll focus on the few things I find particularly noteworthy.

I arrived the day before the conference started and went to the gym & pool area first. After a 5½ hour drive through changing weather conditions (snow, fog, hail, sunshine, rain, more snow, sleet, and finally some more sunshine), this is just the right thing for me to shake off the stress.

Tutorial Day ‘Problem Solving with Agile Thinking and Practices‘ with Ben Linders

I very much enjoyed this well organised tutorial. Ben presented several way to find problems and then solve them. This included some role playing and games. What I appreciate: We got all the material needed to use the games in our projects as well as his ebook ‘Impediments – Problem? What Problem?’. That’s going to be so useful when applying the exercises in my projects – or playing the game with my teams (when I will meet teams in person).

The day was made even better, since I received the confirmation that I am booked for my next project. This is especially nice, since I have worked with the team already and like it a lot!

Day 1

I found Lily Higham’s talk ‘Testing the BBC World Service‘ exciting, since she explained how her team has to cover an incredibly large number of systems, languages and devices. One important insight: ‘Test with real devices’. Also remarkable: She noted how the BBC has to deal with being blocked in some countries and how, in some cases, professional smugglers help spreading the news anyway. No details about this were shared for a good reason. We were advised against trying the smuggling ourselves.

Dermot Canniffe presented ‘BDD And The Sleepy Developer‘, and made the point about the effects a sleep disorder can have during work incredibly well.

During the OpenSpace on this day we shared some information about Mastodon – and what to consider when joining it. My point of view: Two things are important:

  1. The server you chose
  2. The account name

While I didn’t use them in the Open Space, here are slides I prepared just in case:

For easy reference, here are the links used in the slides:

As is a tradition by now the first day ended with a themed costume party. This year the ‘dress code’ was ‘Fairytales’. This is also the Award Night to celebrate MIATPP (Most Influential Agile Testing Professional Person) of the year, this time won by Janet Gregory. Congratulations!

Day 2

On this day, I missed quite a few sessions I wanted to attend, since I held a workshop “Fast Feedback Using Ruby”. With about 10 people attending it was just the right size to help with the many things that can (and will) go wrong in a workshop where coding is a major part. Being (maybe over-) prepared helped a lot: While I had some material prepared to be downloaded, I knew (from experience in an earlier year) that conference WiFi may – or may not – work well. I now bring my own WiFi, so I have a back-up in case the conference one doesn’t work so well. I also had the downloadable material on a tiny small local web server – and a USB stick. Yes, I was over prepared, very likely.

In case you considered this workshop, but attended another session: There is an ebook(let) available on LeanPub, which covers the workshop. And there still are a few coupons let to grab it for free: https://leanpub.com/fastfeedbackusingruby/c/ATD-2022. Additionally there is a GitHub repository at https://github.com/s2k/fastfeedbackusingruby_workshop. The slides from the workshop are available as Fast Feedback Using Ruby slides.

The day ended with the first ‘AgileTD book fair‘ and the ‘Digesting Poets Society‘. I had the pleasure to present ‘Software People … Work From Home — Insights & Experiences From Planet Earth‘, a free ebook to which contributors from (so far) 28 countries and 33 authors provided text about life during the pandemic. Only while I was talking to some of the new readers, I realised that this wasn’t a writing task for me (I still have to add my contribution), but a project management job. Organising so many people from so many countries was – and still is – some work, but oh what a pleasure, too.

Day 3

What I remember from this day most of all, is what Stéphanie Desby shared with me about her break from – and return to working in tech. I find it super interesting what leads people to leave tech, at least for a while, and then come back. As I had to leave tech for while myself, that’s probably no too surprising.

An Afterthought

I remember that in some (pre-pandemic) years, the conference covered the whole week, either with 2 tutorial days, or 4 conference days. While I thought the conference should move back to this longer format, now I’m not so convinced anymore. 4 full days with a LOT of input, talking and, yes, having fun, is demanding.

That said: I am already looking forward to the Agile Testing Days 2023! 🦄🌈

Another Way to Write Ruby Code

Disclaimer: I am not suggesting to change the Ruby style guide.

At a workshop I was giving a few years ago, someone not used to writing Ruby code found an interesting way, that you can write Ruby code.

First let’s assume a class Thingy, that doesn’t do anything useful. It’s just needed to demonstrate the way to write Ruby.

Assume this is in file ‘thingy.rb’:

# frozen_string_literal: true

# Thingy is only used to demonstrate
# a way of writing Ruby code
class Thingy
  def initialize(*args)
    @args = args
  end

  def this(other)
    @args << other
    self
  end

  def that(*other)
    @args << other
    self
  end

  def content
    @args
  end
end

Now, let’s use this class in another script, that’s showing the alternative way to write Ruby code (in file use_thingy.rb):

# frozen_string_literal: true

(require_relative 'thingy')

part = (Thingy.new 'String', :symbol, Math::PI)

(p ((part.this 'Wahoodie?!').that :huh, Math::E).content)

Notice that rather LISP-like way to parenthesise, in line 7 in particular. I still am surprised that this is possible in Ruby and actually behaves the way I’d expect.

Running that script yields the following output:

> ruby use_thingy.rb
["String", :symbol, 3.141592653589793, "Wahoodie?!", [:huh, 2.718281828459045]]

It’s also entertaining that Rubocop does not complain about this code:

> ls
thingy.rb     use_thingy.rb
> rubocop .
Inspecting 2 files
..

2 files inspected, no offenses detected

This is one of the reasons I like programming in Ruby so much: One can discover new ways (even if probably not very useful ones, sometimes) even after years of using it.

In case you’d like to experiment with this code: It’s on GitHub: https://github.com/s2k/alternative_way_to_parenthesise_in_ruby

Getting Started with Ruby and rbenv on a Raspberry Pi

In preparation of a workshop at Agile Testing Days 2022, I’m setting up a Raspberry Pi as a backup system for participants, to be prepared if things go wrong. Especially one of the first steps “Installing Ruby – If Necessary” has the potential to fail or take too long.

With the keyboard configured (see the previous post “Setting Up a Raspberry PI with a German Mac Keyboard“), the next step is installing a recent Ruby version. I’ll use rbenv , a widespread tool to manage Ruby versions on a machine.

Installing rbenv

The rbenv page suggests to install the tool using a basic git checkout.

~ $ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
Cloning into '/home/guest/.rbenv'...
remote: Enumerating objects: 3138, done.
remote: Counting objects: 100% (288/288), done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 3138 (delta 165), reused 231 (delta 131), pack-reused 2850
Receiving objects: 100% (3138/3138), 626.69 KiB | 3.12 MiB/s, done.
Resolving deltas: 100% (1955/1955), done.

Following the next step in the docs, .bashrc is updated to initialise rbenv:

~ $ echo 'eval "$(~/.rbenv/bin/rbenv init - bash)"' >> ~/.bashrc

Restarting the terminal app actually loads the updated .bashrc, and then rbenv is installed and configured.

Another step is to also install the ruby-build plugin, which rbenv uses to compile and install new Ruby versions. I’ll use git to clone this plugin and upgrade it (as documented in https://github.com/rbenv/ruby-build#readme):

~ $ git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build

Now, rbenv can be used to install Rubyies:

~ $ time rbenv install 3.1.2
To follow progress, use 'tail -f /tmp/ruby-build.20221110172124.19039.log' or pass --verbose
No system openssl version was found, ensure openssl headers are installed (https://github.com/rbenv/ruby-build/wiki#suggested-build-environment)
Downloading openssl-3.0.7.tar.gz...
︙

As a last step set this new Ruby version to be used globally:

rbenv global 3.1.2

That’s it. Ruby 3.1.2 is now available for the user an the Raspberry Pi.

Setting Up a Raspberry PI with a German Mac Keyboard

This is another “Note to self” post.

For a workshop I will present at the Agile Testing Days 2022, I’ve set up a backup computer, in case folks don’t have Ruby installed on their machine already, or don’t get it installed within the available time slot.

The Raspberry itself had already worked … with some keyboard back in 2017 (when I used it in a ½ days tutorial at the same conference). But now, I connected a Mac keyboard to it, one with a German layout – including the umlauts. Getting the configuration to work well enough was surprisingly hard.

The existing keyboard configuration didn’t work very well, since it expected an international layout, meaning that the key cap labels weren’t always correct. Or the printed key wasn’t, depending on your perspective.

Setting it up using the GUI application that comes with RaspbianOS didn’t work so well either: for some configuration settings the keyboard stopped reacting completely. Yay! I learned another way how not do do it. 🤣

In the end I used the terminal raspi-config:

sudo raspi-config
A screenshot of the 'raspi-config' tool as displayed in a terminal window

to try all variations of (non-japanese) Apple keyboards with the corresponding German layouts and variants.

In the end I settled with this configuration, as it is stored in /etc/default/keyboard on the Raspi:

# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL=apple
XKBLAYOUT="de"
XKBVARIANT=
XKBOPTIONS="lv3:ralt_switch,terminate:ctrl_alt_bksp"

BACKSPACE="guess"

Colourful Code with Pygments

This is another entry in the ‘Note to Self’ category. 🙂 I’m sure I will need this information at some later point in time again.

The other day I wanted to have some code syntax-highlighted and be able to select the colour theme and well as use the highlighted listing in a number of ways.

Since Pygments is a library made for this task and it also provides a command line tool: pygmentize. It took me some time to use the tool the right way and produce the result I was looking for.

To show how I ended up using it, I’ll use fd as an example, a Ruby utility I wrote that dumps file contents as hex codes and utf-8 characters.

The command below is run inside a directory that contains a sub-folder ‘bin’, and inside that a (Ruby) file fd. To achieve this you can do the following (preferably when in a folder where you keep your cloned Git repositories):

> git clone git@github.com:s2k/fd.git
Cloning into 'fd'...
remote: Enumerating objects: 532, done.
remote: Counting objects: 100% (57/57), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 532 (delta 48), reused 53 (delta 47), pack-reused 475
Receiving objects: 100% (532/532), 105.97 KiB | 526.00 KiB/s, done.
Resolving deltas: 100% (261/261), done.
> cd fd

Here’s the command to create an HTML file using the given theme:

> pygmentize -l ruby -O full,style=monokai,linenos=1 -o fd.html -f html bin/fd

Here’s what the Parameters mean:

-l ruby
Set Ruby as the language to ge highlighted.
-O full,style=monokai,linenos=1
full generates output that includes everything to display the colourised code.
style=monokai sets the theme to ‘Monokai’.
linenos=1 displays the line numbers in the output.
-o fd.html
Set the output file name.
-f html
Set the output format to HTML.

When generating HTML, the full seems to be particularly important, as otherwise the HTML won’t contain the CSS used to colour the code.
The resulting highlighted code looks like this:

The colourised code of the file 'fd', including line numbers in front of each line.
The pygmentized source code

In case you’d like to experiment with pygmentize, here’s some zsh code that prints a sorted list of the styles it knows about:

> pygmentize -L styles | grep "* \(\w\+\):" | sed "s/* \([a-z_]*\):/\1/" | sort

Navigation

%d bloggers like this: