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.)

Word of the Year 2017

As before (see 20162015 and 2014) I’ve picked a Word of the Year.

During the past few weeks since the Agile Testing Days 2016 (see my posts Agile Testing Days 2016 — Part 3: Tutorial Day 1Agile Testing Days 2016 — Part 4: Conference Day 1Agile Testing Days 2016 — Part 5: Conference Day 2Agile Testing Days 2016 — Part 6: Conference Day 3 and Agile Testing Days 2016 — Part 7: Unconference Day), I had a few ideas about what to kick off in 2017.

Actually implementing some of these ideas will require some development, in various meanings of the word. So that’s my guiding word for 2017:

word-of-the-year-2017-develop

With a few lines from a Xavier Rudd song, let me wish you all a great year 2017:

Well, I wish you well on your journey
I hope your dreams they come alive
I hope your dreams back down and they, they thrive
I hope your dreams they come alive

— Xavier Rudd, “Shelter” from the album “Solace”, 2007

 

Agile Testing Days 2016 — Part 7: Unconference Day

The unconference days at the Agile Testing Days started with a brief introduction by Olaf Lewitz.

I found two sessions particularly interesting. One of them was about how to help new speakers to propose a session to a conference. Here’s the flip chart summary:

help-new-speakers-2016_s

The tactical advice I have: Listen to what the organisers say and act on that. The submission page the Agile Testing Days for example, lists hot topics and also states that proposals that are related to such a topic will be more likely to be chosen. The page also states that providing a teaser video will increase the likelihood of being selected even further. I am sure other conferences have similar submission guidelines. Trust them.

Other good advice mentioned in the session: Like reading good code, reading already accepted proposals from previous conferences can help you see what gets accepted (because those already did). Also, while humour is great, it doesn’t always work well in all circumstances. Therefore, be sure to test it in a safe-to-fail environment, e.g. some work colleagues or a user group meeting.

One participant, Maarten Groeneweg, volunteered to be coached on making a conference proposal by Maaret Pyhäjärvi. Together they created an entire mind map Maarten can now use to figure out details of a topic he likes to talk about. If you get a chance to get this sort of support, by all means, take it! While it may well be outside your comfort zone, I’m definitely sure it helps a lot.

The other session I liked a lot was about “Gojko’s Future”. Again, there is a flip chart summary:gijkos-future_s

In his keynote, Gojko presented many aspects of software development and operations that may change, so that testers might become superfluous within about a decade.

Mike Sutton asked one question that I found particularly interesting (I’m paraphrasing): “What could you do, if Gojko’s future becomes the present?”

Some answers were a bit defensive, suggesting possible ways to prevent such a future and I worry about this a little bit as well. But there are many other professions that went out of fashion or disappeared almost completely. For example think about broom makers or rope makers.

Maybe with the advancing technology, we should be ready to find a new profession?

tired_unicorn_s

Now, after five intense Agile Testing Days, even the unicorn got tired and it was time for me to drive home. This conference was incredible and I met so many wonderful old and new friends! Thanks to everyone involved in making this such a special event!

Hope to see y’all again next year!

 

Agile Testing Days 2016 — Part 6: Conference Day 3

For the 3rd conference day, I’d like to mention two highlights: Ida Karine Bohlin‘s “The Tinder Project—How To Test The Right Swipes” and Gojko Adzic‘s keynote “Snow White and the 777.777.777 Dwarfs“.

Ida introduced Tinder, an online service to meet people. It can be used to find someone to have a chat at an airport or meet a lifetime partner. She described how she applied her testing knowledge to search for a partner on Tinder. The compilation of acceptance criteria  was hilarious already, including a good dozen aspects from handsome (but not weak) to strong enough so he could help with heavy luggage at airports. She presented the testing quadrant for identifying test approaches she applied and a testing pyramid to be used. To me, the topic of agile testing was very well presented, the talk was very funny and entertaining. Well done, Ida! I believe it would make a great keynote to introduce the topic of agile testing at a conference!

Gojko presented some aspects, that he believes will change the world of testing in dramatic ways. Two of the reasons for these changes are the ever decreasing cost of computation in general (e.g. by  services such as AWS Lambda), and the decreasing time needed to fix issues after production defects are found.

When applying a micro service architecture, the single service can be tiny — Gojko talks about a few dozen lines of code. With so little code, finding the cause of a bug is typically easy. (At least a lot easier than in a code base containing hundreds or thousands of lines.)

Let me finish with just one tweet about this talk (there are many more on Twitter):

Due to Gojko’s presentation there was a whole new session dedicated to “Gojko’s Future” during the unconference day that followed this 3rd day of Agile Testing Days 2016. But since that’s another day, I will cover it in the next blog post.

Agile Testing Days 2016 — Part 5: Conference Day 2

On the second day of the conference, I enjoyed a new feature: Cinema Replay. One of the morning talks was recorded and then replayed in the afternoon. This included freshly made pop corn to enjoy during the presentation. I think that this is a nice way to help mitigate one issue of all multi-track conferences: You can only attend one session at a time.

I watched the replay of Pete Walen‘s “Making Deploy Decisions Beyond ‘Hard Facts’”. The hard facts that Pete presented were taken from real projects and were used with good intentions. However, even with a strict rule such as “No known severity 0 or 1 bugs in the software”, releases can go bad.

It’s possible that no severe known bugs are found simply because testing stopped for a while before going to production. (Don’t laugh, it happens!) When you then go live there may well be serious bugs in the software. Pete presented several well known software releases than went bad. I really hope that Pete publishes the slides and that the talk will be made publicly available by the organisers. The given examples and stories are definitely worth sharing, so that these mistakes can be avoided.

Another very exciting session I attended was Eddy Bruin‘s and Bram Bronneberg‘s “Beer Tasting and Testing Workshop”. Yes, we had a workshop on beer tasting. We were given descriptions of two types of beer and then one beer. From the look, smell, and taste of the beer, we had to guess which of the two descriptions actually described the given beer. This was very funny and entertaining. I didn’t know before that beers could taste this wildly different!

Be sure to also read about this conference day on other blogs. Each post offers unique insights about the conference. Here is a great list to start:

%d bloggers like this: