Euruko 2022 in Helsinki

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.

Processing a Number of Image Files

This is, again, is mostly a note to my future self. 🙂

Occasionally, I need to process a bunch of image files in a batch. Most often it’s about resizing them, so they fit into a given format of at most xy pixels, or precisely into, say a square format. Here’s how I do it using ImageMagick and a bit of Ruby code:

Processing a single file

ImageMagick comes with convert (it’s linked to …/bin/magick on my machine), as command line tool for processing image files in a whole lot of ways. In order to resize a single file so that it ends up as a square image in a given number of pixels one can use the following on the command line (I use zsh on macOS):

convert input_file.jpg -resize 1200x1200 -background White -gravity center -extent 1200x1200 output_file.jpg

This command

  • reads ‘input_file.jpg’,
  • creates a new image with 1200⨉1200 pixels,
  • a white background,
  • resizes the input image as needed,
  • puts it in the center of the new image
  • and saves it as ‘output_file.jpg’.

Batch processing files

For this step, I use a Ruby script (of course this can also be done in zsh, bash, Python etc.):

images = Dir['file_pattern*.jpg']
images.each do |fn|
  `convert #{fn} -resize 1200x1200 -background White -gravity center -extent 1200x1200  #{fn.gsub(/\./, '_res.')}`
end

Tip: Be sure to use different names for the input and output file names.

Reviewing Submissions for the Agile Testing Days

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!

Two Ways of Solo Programming

Occasionally, especially in times between (paid) projects, I program solo. This morning, I realised that I operate in two ‘modes’ which slightly differ in the way I leave the project I’m working on in the evenings.

One way of working is when I program along while working through a book. Currently, I’m reading ‘Agile Web Development with Rails 7‘ (by Sam Ruby & Dave Thomas). I very much leave the ‘Depot’ app (the example application used in the book) with a completed section and passing tests. The Part of the next section is a fresh starting point in the following morning.

The other way is when I’m progressing in a project, i.e. a library or tool, I work on. In these cases, I prefer to leave a (read: one) failing test in the evening, so it’s easy to remember what I was planning to do in the morning: To fix/implement the code to make the tests pass. Note though, that I do not commit & push this failing tests to version control.

This is neither a new nor my idea. Nick Holden wrote about in 2018 already, in his blog post ‘Try ending today with a failing test for a great start tomorrow‘.

Have you noticed differences in developing software (whether it’s the coding, testing, UX, or any other aspect of it), between times of working alone versus working in a team? What are they? I would be seriously interested in hearing about this.

An Odd Behaviour When Creating A Rails App

I’m currently looking into Rails 7 and found an odd behaviour when creating a new Rails app. Before creating a Rails app a few other things need to be in place, most notably Ruby, and _a_ database. My set up is this:

Ruby
3.1.0
Rails
7.0.2
rbenv
1.2.0
SQLite3
3.37.0
PostgreSQL
14.2

The simplest way to create a new Rails app is this:

rails new app_name

You can also specify various options, including, for example --css=tailwind, to use Tailwind for CSS. Since that’s what is used in a book I’m reading (‘Agile Web Development with Rails 7’ by Sam Ruby & Dave Thomas), I ran this:

rails new app_name --css=tailwind

Now I got an exception logged in the output, while also the exit code of the command was 0. Interesting. Here’s the command and the output (lots of output omitted for brevity):

rails new a_new_app --css=tailwind
      create
  …
      create  Gemfile
         run  git init from "."
Initialized empty Git repository in /Users/stephan/dev/tmp/a_new_app/.git/
      create  app
…
      create  config/master.key
      append  .gitignore
      create  config/boot.rb
…
      remove  config/initializers/new_framework_defaults_7_0.rb
         run  bundle install
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies....
Using rake 13.0.6
Using minitest 5.15.0

…
Using rails 7.0.2
Bundle complete! 16 Gemfile dependencies, 75 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
         run  bundle binstubs bundler
       rails  importmap:install
…
Add Tailwindcss include tags and container element in application layout
      insert  app/views/layouts/application.html.erb
      insert  app/views/layouts/application.html.erb
      insert  app/views/layouts/application.html.erb
…
Add default Procfile.dev
      create  Procfile.dev
Ensure foreman is installed
         run  gem install foreman from "."
Successfully installed foreman-0.87.2
/Users/stephan/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0/gems/yard-0.9.27/lib/yard/rubygems/hook.rb:88:in `require': cannot load such file -- yard (LoadError)
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:88:in `load_yard'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:163:in `setup'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:152:in `generate'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:63:in `block in generation_hook'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:52:in `each'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:52:in `generation_hook'
  from ….rbenv/…/ruby/…/request_set.rb:311:in `block in install_hooks'
  from ….rbenv/…/ruby/…/request_set.rb:310:in `each'
  from ….rbenv/…/ruby/…/request_set.rb:310:in `install_hooks'
  from ….rbenv/…/ruby/…/request_set.rb:209:in `install'
  from ….rbenv/…/ruby/…/commands/install_command.rb:210:in `install_gem'
  from ….rbenv/…/ruby/…/commands/install_command.rb:226:in `block in install_gems'
  from ….rbenv/…/ruby/…/commands/install_command.rb:219:in `each'
  from ….rbenv/…/ruby/…/commands/install_command.rb:219:in `install_gems'
  from ….rbenv/…/ruby/…/commands/install_command.rb:167:in `execute'
  from ….rbenv/…/ruby/…/command.rb:323:in `invoke_with_build_args'
  from ….rbenv/…/ruby/…/command_manager.rb:180:in `process_args'
  from ….rbenv/…/ruby/…/command_manager.rb:149:in `run'
  from ….rbenv/…/ruby/…/gem_runner.rb:53:in `run'
  from ….rbenv/versions/3.1.0/bin/gem:13:in `<main>'
Add bin/dev to start foreman
      create  bin/dev
Compile initial Tailwind build
         run  rails tailwindcss:build from "."
+ /Users/stephan/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0/gems/tailwindcss-rails-2.0.5-x86_64-darwin/exe/x86_64-darwin/tailwindcss -i /Users/stephan/dev/tmp/a_new_app/app/assets/stylesheets/application.tailwind.css -o /Users/stephan/dev/tmp/a_new_app/app/assets/builds/tailwind.css -c /Users/stephan/dev/tmp/a_new_app/config/tailwind.config.js

Done in 228ms.

This is … interesting, since yard is found, when listing matching gems:

> gem list yard

*** LOCAL GEMS ***

yard (0.9.27)

However, the command that is running at this time is (apparently) executed in the context of Bundler. Since yard isn’t listed in the Gemfile, Bundler won’t find or use it:

bundle info yard
Could not find gem 'yard'.

After uninstalling yard, creating a new Rails app works fine and doesn’t log an exception.

While this solves the issue of getting the exception, it was still unclear why this happened in the first place.

Now, what is yard?

YARD is a documentation generation tool for the Ruby programming language.

https://github.com/lsegal/yard

Aha, looking into my .gemrc (which is used to configure Rubygems), I found these two lines (Yes, I like to have the documentation generated 🙂):

install: --rdoc --ri --document=yri
update: --rdoc --ri --document=yri

After removing the --document=yri, creating a new Rails app worked fine even with yard being installed.

I still don’t completely understand, why this is an issue when specifying a CSS processor, but not otherwise. This may be topic for another post.
If you have an idea about why this happens, please let me know.

Navigation

%d bloggers like this: