Category: Uncategorized

Why I think We Can Do better Than asking ‘Why’ 

Pattern Uncategorized No Comments

The other day I read this (German toot) on Mastodon (This toot apparently has ‘timed out’ by now. My answer is still available on Mastodon, though → Stephan: “@Minnasophie@troet.cafe @wandklex@mastodon.art Da…” – Software development is a social activity):

Die Frage ‘Warum’ blockiert oftmals das Annehmen einer Situation.

https://troet.cafe/@Minnasophie/109619420357312175

My translation to English: ‘The question ‘Why’ often blocks accepting a situation.’

I immediately reacted to this.

I thought back to the day a doctor diagnosed me with cancer. He saw a question I was about to ask and before I started to speak, he told me to not  ask ‘Why’. He advised me to  instead concentrate on how I wanted to deal with the situation.

That really changed my thinking. To help me with this, he asked whether I had any plans for the near to mid-term future, something that I wanted to achieve. This changed my thinking from intense worrying extremely to something I I could focus on.

I still worried about the treatment! But I also thought about any plans that I had. And indeed, there was one big plan that I did have: To give a keynote at Agile Testing Days 2018! I WANTED to do it. Badly.

I later realised, another good news that was hidden in the question about my plans for the future: Apparently the doctor thought I had a future, at least the chance to have it.

As it turned out, I was not able to give the planned keynote, since the therapy massively compromised my immune system and that meant I had to avoid larger crowds of people. During the traditional flu season, I was strongly advised to not meet more than 3-4 people at a time. And to avoid even that whenever possible.

Eventually, in 2019, I could give the keynote, and it was received well. Very well, indeed.

Now, having read that quote from above, I started to think about asking ‘Why’ – or even asking ‘Why’ five (!) times to dig into the cause of whatever one is investigating. There may be better questions or approaches. Is asking ‘How do we want to deal with this?’ a better way?

I can imagine that especially when trying to understand a situation that went bad, avoiding ‘Why’ may be a good idea. At least in German ‘Warum’ (of the similar terms ‘Weshalb’ or ‘Wieso’) already carries with it a tiny bit of shaming or (suspecting) guilt. This is  something that one very likely wants to avoid, if the plan is to actually get to the root causes of a situation.

Given the learnings from my illness, I think the following question is an improvement on asking ‘Why?’:

How do we want to deal with this situation?

In my experience, asking ‘Why?’ often also involves ‘you’ as in ‘Why did you do X?’. This adds to the potential of shaming or assuming guilt: Now, there is also some separation between the one asking and the person being asked. 

I had good experiences using ‘we’, when figuring out problems. Using ‘we’ signals that, in fact, we have a problem. 

Using ‘We’ puts us on the same side of a task: we are facing the problem together. Therefore neither of us ‘is’ the problem (or maybe we all are), but… the problem is the problem. 

Having made clear that this problem is our problem, we can collaborate to find a good solution. Even better, we might find three (or more) solutions and then select the best one for the given context, at that moment in time, and implement it.

This is related to Jerry Weinberg’s observation about understanding problems:

If you can’t think of at least three things that might be wrong with your understanding of the problem, you don’t understand the problem.”

Gerald M. Weinberg. Are Your Lights On?. Part 3 – What Is The Problem, Really?. https://leanpub.com/areyourlightson

Another Way to Write Ruby Code

Experiment Learning Ruby Uncategorized No Comments

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

Note To Self Ruby Tools for Testing Uncategorized No Comments

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.

Euruko 2022 in Helsinki

Conferences Ruby Uncategorized No Comments
The Euruko 2022 master of ceremony Antti on the stage

After a 10 year break I made it to an in-person Ruby conference again: Euruko 2022 in Helsinki. For travelling, I chose the Finnlines ferry from Travemünde to Helsinki. That’s travelling without a hurry, since each trip takes 30 hours. At the time of this writing, I’m sitting in the ship’s café looking out over the Baltic Sea into the sunshine, just south of Oland and slowly approaching and then passing Bornholm. There are worse places to write a post. 😁

A sunrise over the Baltic Sea: Near the horizon the sky is free of clouds, above is a thin layer of clouds. below the sea is watery and looks cold.
Sunrise over the Baltic Sea
Photo taken onboard the Finnmaid, while approaching the port of Vuosaari, Finland

Thankfully there’s a gym, a sauna (if a Finish line after all) and lots of nice places to take a seat watch the waves pass by. I even met the fist few other attendees on the ferry already!

Even before reaching Helsinki, Leo Kiisi one of the organisers, sent an invitation to join the sauna – including access to the open water. We met in the evening and had a great time as several attendees and a speaker joined. It was a fantastic way the end the first travel day, relaxing, refreshing and overall remarkable.

The opening Keynote was recorded and presented by Matz, and he busted several myths and claims that were made about Ruby. What surprised me most, is his take on type systems: He explained that (at least some) type systems are Turing compete. which means that the type system alone is already complex enough to encode any algorithm or program. 🤯 — Whether that’s desirable or not is another question. 😉

Wiktoria Dalach told us about how security aspects can be handled, by categorising the infinite space of possible issues into only thee categories:

  1. Confidentiality: How to keep secrets secret
  2. Integrity: How to be sure that we get what we expect
  3. Availability: Ability to access our information always

What we’d need do do ourselves: Select the aspects from these categories that are most important to us — and them work on them.

Adarsh Pandit told us about ‘The Technical and Organizational Infrastructure of the Ruby Community’ – and drew parallels to the transportation infrastructure differences he found between California (where he lives) and Finland. I understood that the difference is mainly that in the US transportation seems to optimise the number of cars the system can handle, while in Finland it’s more the number of people and how they can get from A to B. We also learned how individuals (and companies) can support the Ruby community:

  • Contributing to the language implementation(s) and its libraries: The code is still being optimised, bugs a fixed etc. All think work needs to be done by someone. Thank someone could be you.
  • Support Ruby Central/Ruby Together with money: In the end services such as Rubygems (and its website & repositories), Bundler etc. require hardware to run on and that costs money. These projects are also improved and that involves investing time and/or money as well.
    BTW, you can support RubyTogether at https://rubytogether.org.

An amusing point Adarsh made: He said that Finland seems to have the happiest people and at the same time the angriest music. (Note: Finland has the highest number of mates rock bands per capita worldwide).

Vesa Vänskä explained how to move ‘From massive pull requests to trunk-based development with Ruby’ – and reminded us of Dr. Eliyahu Goldratt’s observation:

I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory.

Dr. Eliyahu Goldratt

Be sure to check out the talks on the conference site; I believe, at least some talks were recorded and will be available in the next few days. As always, I thoroughly enjoyed the conference days, meeting many new people, the great food at the lovely location.

I’m already looking forward to the next Ruby conference I’ll attend. It may be the next EURUKO and the community voted for Vilnius, Lithuania.

Reviewing Submissions for the Agile Testing Days

Conferences Feedback Uncategorized 2 Comments

Other reviewers have also blogged about this topic:

The other day a discussion about the review process of the Agile Testing Days developed:

Since I contributed to this thread and was a reviewer for this years programme, here’s my take. It’s my personal view and other reviewers may well have other aspects they focus on.

  1. On the conference page there are blog posts covering how to write a good proposal. I suggest to read them. This blog contains some tips as well:
  2. The conference offers a list of ‘hot topics’ which changes each year. If a proposal fits to this list it’s a plus, since this is a step towards a consistent conference programme.
  3. I prefer proposals that catch my interest, without telling too much about the topic. – If a proposal already expels everything well, time may be better spent in another session.
  4. A well written abstract text, that is easy to understand (for me) is a plus, too. This includes avoiding typos and grammatical mistakes. We all make them, and even the best spell checkers can’t catch all issues. But still, some proposals are really hard to understand due to language problems. Don’t let that get in your way of getting accepted. My tip: Get feedback by a native English speaker before (!) submitting. Many well known testers and speakers offer help and it is worthwhile accepting this help.
  5. Understand what the fields in the proposal form are meant for. Fill them to provided the information that is asked for,
    Avoid repeating the same text in different parts for the form. Change the wording at least a bit. In some cases the title, sub headline, main statement and key learning(s) contained exactly the same or very similar text. To me as the reviewer this is a little bit boring, and doesn’t help me understand what the session is about.
  6. Sometimes, repeating is worthwhile: It helps to understand what is important. Use this tool carefully.

Some questions may guide to writing a good proposal:

  • Will this help the reviewer to give me a high rating?
  • Am I giving enough information to inform a potential attendees decision to come to my session?
  • Am I giving too much information?
  • Is this a good fit for the conference this year?

A leaving personal note: It took me years to get accepted at the Agile Testing Days, even for what was then called a ‘consensus talk’. In the very early years the proposals weren’t very well written, in some years I failed to match the overall conference theme. And then it clicked, I asked for help, gave workshops, a tutorial and, in 2019 even a keynote. For me it was worth the effort.

Good luck and may your proposals be accepted!

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d bloggers like this: