Homebrew & Pinning Versions

I recently started using Tomcat for a project I’m working on. Since I work on a Mac and am using Homebrew anyway, the installation was as easy:

brew install tomcat

The location of the installed files is /usr/local/Cellar/tomcat on a Mac, BTW. Now, occasionally and out of habit, I run this:

brew update && brew upgrade && brew cleanup

I prefer (usually) small issues with small version jumps to upgrading rarely with bigger version changes (and issues). Also cleaning up seems a good idea, not only on the working desk or kitchen sink.

This time, though, the upgrade removed the previously installed version of Tomcat — including stuff that I had put into a sub folder of the location given above. Not only was the Tomcat installation upgraded, but everything I’ve put in there was gone. 😳

Lesson No. 1: Maybe I shouldn’t have put the stuff there in the first place.
Lesson No. 2: Learn how to pin a version of installed software, when using Homebrew.

It’s easy. Use, for example

brew pin tomcat

to, well, pin the tomcat version. To find out later, when you want to upgrade a piece of software and wonder why it does not happen, use

brew list --pinned

to find out, what software is pinned. Last but not least, a package can be unpinned using:

brew unpin <package_name>

Reading the Homebrew FAQ is also a good idea.

Docker’s ‘docker stats’ & names

This is mostly a technical reminder to my future self and a selection of the tips from a proposal I found at https://github.com/moby/moby/issues/20973. 😉

When using Docker, now and then I need to keep an eye on the run-time behaviour of the Docker containers. To do this, there’s a nice docker command:

docker stats

How ever, in the current version (17.05.0-ce, build 89658be), the containers are listed using the container ID.

I find it much easier to use the container names instead of the IDs, so here are two ways to display them:

  1. On an environment I don’t control (a colleagues machine when pairing, a test environment…) there’s a way to change the display of ‘docker stats’ for a single use of the command:
    docker stats $(docker ps --format={{.Names}})
  2. On my machine, I like to have this all the time, so I edited ~/.docker/config.json and added the following key-value pair:
    "statsFormat": "table {{.Name}}\t \
    {{.CPUPerc}}\t \
    {{.MemUsage}}\t \
    {{.MemPerc}}\t{{.NetIO}}\t \
    {{.BlockIO}}\t{{.PIDs}}"

    (The backslash at the end of the line indicates the the line is actually continuing.)

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: 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!

The Agile Testing Days 2014 – Day 1: The Tutorial

The 1st day of the Agile Testing Days for me was a full-day tutorial by Alan ‘The Evil Tester’ Richardson about technical testing. The tutorial was very hands on, and we actually tested something — a website.

I liked how we started with the website as such and focused on the relatively simple aspects of getting a user account and logging in. We did some testing and then reflected on what we were doing and how we did it. For example there were various ways of note-taking:

  • I mostly used pen & paper, and for some notes a text editor (e.g. when I knew that I would like to make a note of text I would enter more than once)
  • Some used their text editor of choice, Evernote or similar tools.

After interacting with the application ‘just’ using the basic browser feature of rendering HTML, we stepped down to a slightly deeper technical level and used ‘developer tools’. These allow interaction with the DOM and, for example, manipulate what an HTML form would submit back to the server — including, but not limited to, selected values of drop down lists. — While not every user will do that, some will. And it’s a good idea to test that your server can candle this unexpected input. We also looked into a number of tools to capture (and again manipulate) network traffic, such as HTTP proxies.

I liked how ‘technical testing’ was presented as something that is different from ‘test automation’. Many of the tools we use for testing enhance our possibilities as testers — and sometimes they also allow for some automation. The main point of technical testing though, is increasing the testers reach into the technical details of the system under test.

This is what I expected from the day and also what was delivered in the tutorial.

Thank you Alan, I liked it a lot!

%d bloggers like this: