Ham Vocke

Book Review: “Tidy First?”

Tue, 12 Dec 2023 00:00:00 +0000

Hardly any author shaped the way I think about software development more than Kent Beck. It took me a while to put the ideas in “Test-Driven Development: By Example” into proper practice, and once I did it changed the way I wrote code forever. Extreme Programming (XP) and its focus on embracing inevitable change, keeping options open, staying flexible, pair programming and automated testing remains my favorite way to build software in an effective and sustainable way.

Kent Beck publishes ideas about software design on his “Tidy First?” Newsletter. This newsletter is the source for his book “Tidy First?: A Personal Exercise in Empirical Software Design”. I only recently stumbled across “Tidy First?” and finished it last week. This is my review.

What’s “Tidy First?” all about?

Kent Beck introduces the concept of tidyings, tiny changes to the structure (not the behavior) of your code to make your code more manageable, readable, and flexible, one small change at a time.

Beck starts by explaining a number of distinct tidyings you can apply to your code every day. He discusses how tidyings, small structural changes, can make it easier to implement your next behavior change. And he explains how to avoid falling into the trap of tidying for the sake of tidying, keeping a focus on what’s important to your users: a change in your code’s behavior, not its structure.

The book comes in three parts.

The “What”: An introduction to the idea of tidyings, small structural code changes to support your next behavior code change
The “When”: An analysis when its best to apply tidyings as part of your workflow: before, during, or after a behavioral code change
The “Why”: An explanation how tidyings can lead to looser coupling, increased cohesion, and keep more options open for longer so that you can deal with change better

The first part is quick and fun. It explains how small changes like extracting code into helper functions, using guard clauses, or explanatory variables, can help make your code more readable. For the seasoned developer this might sound familiar. For developers new to the trade this will be practical and invaluable and give them a clear set of ideas to improve the code they encounter over their career. The first part reads like a modern, less dogmatic take on Robert Martin’s “Clean Code”.

The second part is where things get more spicy. Staying true to XP principles, Beck highlights how tidying is about solving an immediate need, not thinking too far into the future. Tidying can be fun and make you feel like you’re making progress, but the real thing you’re after is changing the behavior of your code, not its structure. Or, to use Kent Beck’s words:

Tidyings are the Pringles of software design

One tidying often leads to another, and then another. You have to know when to stop.

Beck goes on to analyze whether its smarter to tidy before , while or after you change the behavior of your code. This central question explains why the book is called “Tidy First?”. The answer, as so often, can be boiled down to an “it depends” - and Beck’s analysis is inspiring, especially for people who have a tendency to fall into the trap of cleaning up non-stop, or – even worse – not at all.

The third and final part, the “why”, was my favorite. It’s full of challenging ideas that connect the simple concept of “tidyings” to much larger, more systemic effects. Beck explains the concepts of optionality, the time value of money, coupling and cohesion. This analysis ties the seemingly innocent idea of cleaning up messy code to the fundamental idea that being able to deal with uncertainty and change is valuable, in a monetary sense. Systems that are easy to change are worth more. Things that are easy to reverse are preferable to things that aren’t. A dollar today is better than a dollar tomorrow. Earning more money, sooner, with greater likelihood is good. Spending less money, later, with less likelihood is good.

My Takeaway

Kent Beck’s “Tidy First?” is a fun read full of insightful advice. If you’ve developed software for a while it will start out seeming obvious, maybe even too trivial, by explaining simple “tidyings”. Don’t skip those, let them be a reminder of simple changes you can do to make your code easier to work with. If you have never heard of the tidyings Beck explains in the first part, you’re getting valuable advice for your entire career as a software developer. The last few years I hesitated recommending Robert Martin’s “Clean Code” to newer developers as I found it too opinionated, too dogmatic, and too dusty from today’s perspective. “Tidy First?” will be my go-to recommendation moving forward, not just due to the list of tidyings it explains but due to the insightful analysis around the “when” and “why”.

The “when” and “why” parts are where “Tidy First?” goes way beyond a pattern book and starts hitting heavier. Part 2, the “when”, helps appreciate when you’ve tidied enough and keep an eye on the actual goal, and it explains how pushing tidyings too far into the future can backfire. Both of these are traps I’ve found myself and others fall in over and over again. The grand finale, Beck’s explanation of optionality, the time value of money, coupling and cohesion and how all of these work together to build valuable software are fascinating. These ideas aren’t completely new to me as they’re deeply rooted in XP and have always been key to the goal of embracing change. Reading them this clearly helped me better connect the dots and gave me new ways to think about software design.

Go ahead and read it if you haven’t. It’s a short, enjoyable read full of great ideas. It’ll be worth it!

Path to Production Mapping

Wed, 08 Mar 2023 00:00:00 +0000

Wanna hear something reassuring? Every software development team has problems getting their shit into production. There, I said it. Now take a big sigh of relief, feel better about the absolute mess your team is in, and close the browser tab. Or read on and learn about a tool that can help you tackle these problems.

When it comes to getting your software from your grimy old Macbook Pro into the sweaty metaphorical hands of your users, one thing is a given: there’s always something to improve. No matter where you are on your Continuous Delivery journey.

Sure, some teams are better off than others on the “our path to production sucks” scale. While some are more on the “well, this is mildly annoying” side of things, others might find themselves on the “holy shit, we’ll go out of business if we don’t fix this” end. Some teams are struggling to deploy more than once a year, while others might be able to do so 10 times a day but they are annoyed by their stupidly slow integration test suite or their constantly flaky end-to-end tests that nobody really trusts anyways.

When I was doing consulting at Thoughtworks, I often worked with teams who were unhappy about their development cadence. They didn’t like how often they were able to ship new stuff to real users. Continuous Delivery was a hot topic back then (still is, honestly) and companies asked us to help them get started or get better with it.

One tool we used a lot back then, a tool I keep using today even after my consulting days are over is “Path to Production Mapping”. This tool might sound like a secret weapon but it really is something everyone can do. Thoughtworks call it out on their Technology Radar, but unfortunately don’t go into detail what this is all about. I’m here to fix that. I’ll explain how I usually do “Path to Production Mapping” with teams I work with, and how you can do the same.

“Path to Production Mapping” in a Nutshell

Okay, here’s the summary for those of you with the attention span of a squirrel:

When you run a “Path to Production” exercise, you lock a software development team into a room and don’t let them out before they have created a map that answers the following question:

What does it take us today to get a change from a developer’s computer into the hands of a real user in production?

You start with a blank canvas and something like this:

…and ask people to fill in the big ??? space in the middle. Easy peasy.

You’ll get heated discussions, maybe some yelling, inevitable bike shedding, and finally agreement. You write down the sequence of all the manual and automated steps, the people involved, the tools used, and whatever else is important to get your stuff out to production.

After a while you’ll have something like this (click image to see a larger version):

Once you’re there you can pat yourselves on the backs because you finally collectively understand what it takes to ship a change to your users. Now it’s time to crank up the heat and find ways to improve.

Sounds cool? Cool. Read on.

Get Clarity, Identify Pain Points & Improve

So what? This is just a bunch of sticky notes. What’s the big deal?

You’re a software team. The only software that matters is the one your users can use. Getting your software into the hands of your users efficiently and frequently is important. Continuous Delivery (CD, or “CI/CD” as everyone seems to call it by now) has emerged as a practice to help you pull that off. Doing CD effectively is a game changer. I’m not making this shit up, we’ve got great research to back this up.

Chances are that you claim to “do CI/CD” but you’re lying to yourself because all you’ve got is an automated build running on every pull request someone puts out there (that doesn’t even qualify as “CI”, my friend!). Or maybe you’re stuck in the dark ages and haven’t taken any steps towards automating build, test, deployment to release software to production reliably and frequently. And maybe, just maybe, you’re actually doing CD quite well already, but somehow your deployment pipeline has grown so large by now that you don’t really quite know all the things that happen. Or you secretly loathe the fact that you’ve got to retrigger your pipeline about twice per day because these stupid integration tests are constantly breaking for no good reason. Look, we all struggle with these things, we’re all on a different part of this journey, and there’s always something to improve about your path to production. And that’s why you want to explicitly map it out with a “Path to Production Mapping” exercise.

Running this exercise can help you to:

get clarity and a shared understanding about your current path to production (you’ll be surprised how different people will have different understanding of what’s actually going on)
identify bottlenecks, brittle steps, unnecessary work and things that are completely unknown to the team today
come up with plans to improve, automate, eliminate, parallelize steps on your path to production
figure out that no single person actually understands the whole process

Quick Detour: On "Value Stream Mapping"

This whole "Path to Production Mapping" thing is not new, really. It's mostly a simplified version of a technique called Value Stream Mapping that folks who love to say "Lean" and waffle about Toyota's production system have been using for ages.

Value Stream Maps sketch out all the steps in a business process that add value to your customer (or some other person who's interested in the outcome) and show how long each step takes. People use value stream maps to show what a process currently looks like, how long it takes, where bottlenecks are, where things go to waste. They often create another value stream map of the desired future process to show where the current process can be improved.

The "value stream" in a path to production exercise is the journey of a code change from a developer's machine into production. Often this value stream is built as an automated deployment pipeline. But quite often there are also manual steps involved that are worth tracking. And sometimes, if teams haven't even started working towards Continuous Delivery, there might not even be an automated deployment pipeline yet.

Mary and Tom Poppendieck have written some more about Value Stream Mapping in the context of software development in "Lean Software Development: An Agile Toolkit".

How to Create Your Path to Production Map

Maybe you’re sold on the idea that that mapping your path to production could help you make sense of the mess you’re in. Here are detailed instructions for you if you’re eager to run this exercise with a team:

To create your own Path to Production Map, you set up a workshop where the right people come together to discuss and write down the individual steps of your path to production. This sounds simple, but it will be intense.

You should plan to take between 2 to 3 hours for this meeting. If you need more time, schedule a follow up meeting, because people’s brains will be fried after this.

Invite the right people

Aim for a diverse set of opinions in this workshop. You want to have people from the different disciplines involved in getting a change out of the door. You want people with a lot of experience and people who are new to the team. Don’t listen to your rock star developer when he says “we don’t need this meeting, it’s all super simple and I can simply sketch this out in 10 minutes”. That’s bullshit, and you’ll prove it.

Think about inviting the following people. You don’t need to invite literally everyone, but you should have a good mix of roles and experience:

some of the people who build the software. software developers, data engineers, designers
some of the people who build and maintain the infrastructure your software is built, tested, and run on: software developers, operations folks, site reliability engineers, platform engineers, “DevOps engineers” ¹ , you know who I’m talking about
some of the people who are involved in testing: quality engineers, software developers, testers, product managers
some of the people who decide what gets built and shipped, and when: product managers, project managers, maybe even someone from marketing
maybe even some of the people who take a higher level perspective of what the team is doing: team leads, engineering managers

Don’t run this workshop with 20 people unless you want mayhem. 5-9 people seems to be the sweet spot allowing you to have a healthy discussion and avoiding endless debate and bike shedding.

Prepare a Canvas

I don’t care whether you do this in person or in a virtual setting. You either take a huge physical space (a whiteboard could be a good start, spreading a huge roll of paper out on a conference table is a good alternative), or you use a collaborative diagramming tool (I’ve used Miro before, but others will work fine, too).

Bring lots of sticky notes in at least 4 different colors. Bring markers for every participant. If you do this virtually, you don’t need this, of course.

Set up the canvas by showing what each sticky notes’ color is used for (you can swap the colors if you feel frisky)

Yellow: Steps (automated and manual)
Blue: People involved
Green: Tools involved
Red: Time for each step, and time between steps

You can add more types to the mix if you think it’s worth capturing more: It might be useful to capture comments & questions that come up as part of your discussion, or outputs of certain steps, or environments you run your stuff on. This is your tool, feel free to add what you and your crew thinks is helpful to understand your path to production better.

Go Wild!

Once you’ve got everyone in the room and your canvas prepared, explain what you’re doing: You want to sketch out all the steps it takes right ow to get code from a developer’s machine into the hands of your users. You want to capture who is involved in these steps and which tools are used during each step. And finally you want to write down how long each of these steps usually takes, and how much idle time is spent waiting for this step to happen.

Usually there’s going to be some chaos and hesitation in the beginning. People are shy to start, argue about the right level of detail, get lost in meta-discussions. It’s okay to let these happen for a bit but after a few minutes you should encourage them to just fucking do it and write something down to get the ball rolling. This is not an exam, there’s nobody grading what he team comes up with. If you’ve set this workshop for 2 hours, tell them they should be done with the “mapping” part after 1 hour. This will give you some room to extend their time, but it’ll give the team a sense of urgency.

During the mapping exercise, expect that the team will come up with some obvious steps rather quickly, while others are surprisingly controversial and come with a lot of discussion, questions, and back and forth. This is a great time for newer team members to ask questions, for people in non-technical roles to learn more about the technology used, and for the technical folks to better understand what business decisions are driving your development process.

Be mindful about rabbit holes and derailing conversations. Teams often get lost in details that don’t quite matter in the grand scheme of things. If you spot these discussions, make sure to help the team get out of it by breaking it up, putting down a sticky note with the open question so that you can revisit later, and move on.

Analyse the Map

Once the path to production map is done, you should take a deep breath and a short break. The next step is to analyze the map the team has created. You could either do this as part of the one session you planned or schedule a follow up. Be mindful of the energy levels in the room, creating the map can be exhausting and people might be fried by now.

When it comes to analyzing the path to production map, to take a look at all of the steps you outlined and the time each step takes. Discuss where you can find room for improvement. Highlight the pain points and write down first ideas that come up to tackle these problems.

Some things to think about:

Which steps take a lot of time today? could you cut that time down by using better automation or changing your approach completely?
Where do you have handovers that lead to a lot of waiting time?
Are there manual steps you could automate?
Are there steps that don’t provide a lot of value that you could eliminate or cut back on? Be rigorous. Over time a lot of cruft creeps as it’s always easier to add something than to remove something. Often you learn over time that something that sounded like a good idea a year ago isn’t actually pulling its own weight.
Are there steps you could parallelize instead of running them in sequence?
Are there steps you could take off the “hot path”? Could you get your changes out to production without waiting for the result of certain steps? Feature flags can help to decouple deployments from releases, which can be useful to buy you much more safety and flexibility in these regards.
Are there things to streamline and simplify? Do you, for example, have three different deployment methods for your various environments that you could unify?
Are the steps in the right order and optimize for fast feedback? Watch out for long running tasks that run earlier and push out quick verification steps to a later point in time and see if that’s worth fixing. Usually, you’d want your unit tests to run before your integration tests, for example, since they’ll give you valuable feedback much quicker.
Which steps are currently unreliable and could be made more resilient? Do you have certain deployments that often fail? A flaky test suite? Think about making these more reliable, replacing them with a different approach that is more reliable, or getting rid of them altogether.

As you discuss these things, write down the pain points and possible solutions. Let the conversation flow, there will probably be a lot of ideas, some good, some bad. Capture them all for now. Think about giving the team an opportunity to add more ideas even after the workshop’s done.

Follow Up

After this exercise you will have a few things:

A visual map showing how you get your software into the hands of your users today
A shared understanding and agreement on your path to production
A lot of ideas where you could improve your current process

Don’t let this go to waste. The Path to Production Map is great for onboarding new team members. It’s a great living document you could change as your path to production changes. Think about making this visible to your team in an easy way.

More importantly, the list of improvements is something very actionable that could help you turn your current process from something that everyone resents into something that allows you to experiment, innovate, and ship stuff reliably and frequently. Make sure to prioritize the work accordingly.

Summary

If you and your team (or a team you know and care about) are frustrated with how you ship your software to production, it’s tempting to quickly jump to conclusions, flail around aimlessly and try to improve something, anything by writing yet another script or including yet another tool. Mapping out your Path to Production can be a smarter approach that allows you to take a step back, see the bigger picture first, create shared understanding and have structured discussions about what’s painful at the moment and why everything sucks so much.

Shipping software to production is more of a social problem than a lot of us developers are ready to admit. Treat it accordingly. Gather everyone in a room, map out your path to production, analyze where your problems truly are and discuss the big ideas to improve your situation together.

I hope this exercise helps you as much as it has helped me in the past. If you’ve got questions, doubts, feedback, or comments, feel free to send them my way. All my contact data is crammed into the footer of this page.

Footnotes

get ready for people with their pitchforks. Don’t say you haven’t been warned! DevOps is not a title. ↩

Browser Bookmarks on the Command Line

Mon, 31 Oct 2022 00:00:00 +0000

I wrote a small tool. It’s merely more than a script, actually. This tool has been immensely helpful for me over the past few weeks and so I’m sharing it more broadly.

lnks¹ is a command line tool that allows you to search through a list of bookmark and open them in your default browser.

Search and open your bookmarks from the command line

You can find the code and more instructions on my GitHub repository.

Setup

Here’s all you need to do to get started:

Install fzf
git clone the repository or download the .sh and .txt files yourself if that’s your thing
Edit the bookmarks.txt file and put your bookmarks in there (see Managing Bookmarks for details)

Usage

Run the script from your command line.

./lnks.sh

Use the ↑ / ↓ arrows or Ctrl + P / Ctrl + N to navigate the list of visible bookmarks up and down.

Hit Enter to open a selected bookmark in your browser.

Type some text to run a fuzzy search against all your bookmarks. Delete typed characters with Backspace.

Exit lnks with Esc or Ctrl + C.

Managing Bookmarks

The script will read all .txt files that are located in the same directory as the lnks.sh script itself to create your list of bookmarks. You can add all your bookmarks to a single bookmarks.txt file, or create multiple .txt files, totally up to you.

A bookmark text file needs to follow these conventions:

One bookmark per line
Each line has a searchable name and a URL
The URL is the last part of your line, separated from the searchable name with a space
A bookmark file needs to have the .txt extension
You can have as many bookmark files next to your lnks.sh script as you want

Demo

Here’s lnks in action.

Create an Alias for Easier Access

Here’s a pro-tip: to make opening your bookmarks a little more convenient, add an alias to your ~/.bashrc, ~/.zshrc, or ~/.profile:

alias lnks='~/your/directory/lnks/lnks.sh'

This way you can open your bookmarks from anywhere simply by typing lnks.

Or Bind it to a Hotkey

You could take this one step further by binding lnks to a global keyboard shortcut. That way, your bookmarks will pop up by triggering a key-combo of your choice.

How to can bind custom commands to certain keyboard shortcuts depends on your operating system (and desktop environment) of choice. On Mac, you’d have to dig into Automator. On Gnome on Linux, you can set up a custom keyboard shortcut in your keyboard settings. Other desktop environments will allow similar customization. In window managers like i3 or Sway, you can bind a custom command to a key combination in your config (check out how I did this in my own Sway config).

You get the idea. You tell your operating system launch your terminal application of choice and then execute the lnks.sh script from the right directory whenever you trigger the right key combination. Depending on your terminal application the command to trigger will look slightly different, but it should be somewhat similar to one of these:

# gnome-terminal:
gnome-terminal -- bash -c ~/dev/lnks/lnks.sh
# -> replace this ^^^^ with your shell of choice if you're not a bash user

# alacritty:
alacritty -e bash -c ~/dev/lnks/lnks.sh

# foot
foot bash -c ~/dev/lnks/lnks.sh

This is going to be much more fun if your terminal and shell startup times are fairly snappy.

How the Sausage is Made

lnks uses fzf - the incredibly practical command-line fuzzy finder to do all the heavy lifting of searching and displaying stuff in a neat UI. lnks is merely orchestrating a few Unix tools, really.

The script simply reads all adjacent .txt files and passes their content over to fzf. fzf then lists each bookmark on one line. As you select a line, fzf shows the last segment of the line (the actual URL) in a preview window at the top. The rest of a line will be used as the name of the bookmark, this is also what fzf runs your search query against. Finally, I configured up a key binding in fzf so that pressing the Enter key opens the bookmark’s URL in your default browser.

Why You Might Want to Use This

As software developers, we often access a lot of bookmarks and important URLs throughout our day. Production systems, staging environments, bug trackers, observability tools, CI/CD pipelines, you know what I’m talking about.

Of course you could manage these bookmarks within your browser like a normal person. But you didn’t click the link to this blog post because you’re looking for vanilla solutions to everyday problems, did you?

Chances are that you’ve got a terminal open all day so navigating bookmarks from a terminal might feel like second nature. And if you use something like tmux (check out my tmux guide if you don’t!) you can dedicate a small pane to keep lnks open at all times.

The nice thing about keeping all your bookmarks in plain .txt files is that you can share them easily with people you work with. Most likely they will need access to the same things as you do, so sharing these bookmarks is a great way to keep important bookmarks up to date and point people to the right places at all times. A good way to do this is to fork the GitHub repository, check in your own bookmark files, and share your fork with your team.

I learned to love this kind of bookmark sharing when I worked with a software development team at Otto, a German online retailer. We did a lot of pair programming and switched machines frequently. Someone on the team had built a small bookmarks website that looked pretty much just like lnks and allowed you to search through important bookmarks for the team. As we were pairing, we could always rely on having quick and easy access to that bookmark website and therefore to all our test environments, logs, bug trackers, code repos, you name it.

I’m getting a lot of mileage out of this small script. I hope you find it helpful, too.

Footnotes

that’s “links” for people who want to save a keystroke – my contribution to the myth of German efficiency! ↩

Book Review: “Learning Test-Driven Development”

Wed, 15 Dec 2021 00:00:00 +0000

Earlier this year I received an email from my friend and former coworker Saleem Siddiqui. Saleem must have thought that spare time was overrated since he told me that he was writing a book on Test-Driven Development and O’Reilly agreed to publish it. He asked if I wanted to be one of his technical reviewers and read through early versions of the book to make sure that it is logically sound, that code samples are correct and to chime in with other suggestions.

I was thrilled.

Saleem is a person who had a huge impact on who I am as a professional. We worked together on a ThoughtWorks project in Hamburg, building software for a smart home device and its cloud ecosystem. Pair-programming with Saleem was what made TDD truly click for me. Saleem is a gifted teacher and an advocate for keeping software simple and maintainable by driving software design with automated tests. I was fortunate enough to have worked with Saleem in person. It’s amazing that he decided to take his passion and talent for teaching to a wider audience by writing this book.

Full disclosure: This is my personal review of Learning Test-Driven Development. I’m not paid for it, I don’t get any affiliate money, and nobody asked me to write this. I don’t have any financial stakes in this book. Yet, this is not an unbiased review. It couldn’t be, for the reasons I’ve outlined above. I hope this can still be a helpful review for you.

Learning Test-Driven Development in a nutshell

The summary is in the title, really. Learning Test-Driven Development teaches software developers how to do Test-Driven Development (TDD). Throughout the book, you’re building a small application that is able to calculate with and translate between different Currencies. After a short setup, you will build this application in a true TDD way. You start with a failing test, get it to pass by writing code, and then clean up and refine. Rinse and repeat until the application is done. The book uses the same Money example Kent Beck used in his seminal “Test-Driven Development by Example” and gives it a more modern spin. You can choose between three programming languages – JavaScript, Python and Go – and learn hands-on how to iteratively build a currency converter in either (or all) of these languages driven by tests. By the end of the book you will have a good understanding of what TDD feels like and how to apply it. You will use the “red-green-refactor” cycle ad nauseam (which is good) and experience how tests help you keep your code malleable and clutter-free.

Who should read this book?

This book is great for:

Developers who have never used TDD and want to learn it from scratch
Developers who have tried TDD in the past and discarded it because it didn’t click for them
Developers who want to level-up their automated testing skills without necessarily becoming TDD evangelists
Developers who are curious to dive into JavaScript, Python or Go (or all three of them) and see how they compare

If you are just starting out in your programming career and learned one popular programming language already, I highly recommend working through this book. Testing is one of the most important skills to master as a software developer and pays compound interest. Make your life as a developer better by learning this crucial skill early on.

If you are a seasoned programmer with doubts about TDD, this book might help you get a new perspective. Maybe you got fed up with TDD after working with someone who just wouldn’t shut up about TDD. Or you might have been annoyed by an overbearing manager who demanded you hit 100% test coverage and did not understand that this was a silly goal. You might have tried TDD on a gnarly legacy codebase only to find out that everything is too tedious and taking you twice as long, and that unit tests are rarely helpful anyways. Take this book for a spin and follow the examples hands-on to see if it clicks for you.

If you are an experienced TDD practitioner or someone who has written a fair amount of unit tests in the past and understands their benefits and shortcomings, this book will not teach you many new tricks. If, on the other hand, you consider training others to become more proficient with TDD and test automation, this book might serve as a nice workbook to use for this kind of training.

What’s in the book?

The book is best used as a hands-on workbook. I recommend not just reading it but actually working through the examples on your own as you read the book. Open an editor, write those tests, see them fail, make them pass. You’ll only get a fraction out of the book if you’re merely reading it back to back. By writing code on your own, you’ll make sure to truly experience the TDD cycle and the benefits of guiding your implementation by writing tests first.

The `Money` problem

The book revolves around a simple exercise: Build an application that allows you to calculate with and convert between different currencies. This program will be able to answer questions like What's 42 USD + 12 EUR in CHF?. It is a fairly well-known code kata (popularized by Kent Beck’s book on TDD) that stays fairly simple. You are not building a web application. You are not talking to a database. There is no ~~silly~~ fancy blockchain. It is a simple program doing simple calculations. This is a good thing because it allows you to keep focused on the essence of learning the TDD cycle. However, if you want to learn about advanced patterns of testing (how do I deal with caching? how do I simulate HTTP requests? how do I test code that talks to a database?), this book won’t help much (read on for some recommendations if this is your concern).

`Python` or `Go` or `JavaScript`? Or all of them?

The subtitle of this book promises that this is “A Polyglot Guide to Writing Uncluttered Code”. And it keeps that promise. The book uses three parallel language tracks to walk you through the Money example. You can choose between JavaScript, Python and Go as the language to work with. You can also choose to work with two (or even all three) languages in parallel. Totally up to you.

If you are mostly looking for a quick introduction (or a refresher) on TDD in a language you know, I recommend picking one language and working your way through the book. You should be done in a handful of hours and leave with a better understanding for TDD in you chosen language.

If you are curious about learning either of these three languages, the simple nature of the code sample is a great way to learn basic syntax, build and test commands.

If you are curious about statically vs. dynamically typed or compiled vs. interpreted languages and want to experience how writing code and tests feels with each of those, I recommend picking two or three languages when working your way through the book.

Red - Green - Refactor

The mantra of TDD - Red - Green - Refactor - describes the small feedback cycle you use to develop software in a test-driven way. You start with a failing (red) test, write code to make it pass (green) and then take your time to clean up and refactor. And back to square one. It’s one thing to read about the “RGR” cycle and nod in agreement. It’s another thing to apply it. This is where most people start struggling when the rubber hits the road in my experience. They try to get started with TDD but feel like they are going too slow and become frustrated. Or they are taking too big steps at once and lose track of what they’re doing.

“Learning TDD” drives this point home. Saleem explains the Red - Green - Refactor cycle and demonstrates over and over again how to apply it. He is giving valuable advice how you can use “RGR” to speed up when you’re confident and slow down and take baby-steps when the task ahead becomes scary and hard to grasp.

Working through this book will give you a profound understanding for this small feedback cycle. Chances are you will finish the book longing for similarly short and snappy feedback cycles for your day to day work as a software developer. Fast feedback is a great boost to productivity in software development. Continuous Delivery and Agile methodologies try to establish this concept on a team-wide level. TDD is your own personal tool to get fast feedback while you fix bugs or work on new features.

Unit Testing, Design and Maintainability

TDD is not primarily about unit testing. It is a tool to help you design your software - and you get unit tests and long-term maintainability as helpful byproducts. By writing unit tests first you think about the design of your APIs, your classes, methods and functions. You end up with working examples calling your code and asserting correct behavior. You have an automated test suite that allows you and everyone else on your team to change and improve your code in a safe way.

You will take a quick detour into software design. The book briefly explains how loose coupling and high cohesion make your code more maintainable. It touches on Dependency Injection, a crucial pattern to help with decoupling and testing. And here sits my main gripe with the book: These aspects fall a little too short to my taste. There is just enough information for beginners to learn the important terms and concepts but experienced developers will feel like they need more details here. I understand that explaining good design and waffling about low coupling and high cohesion is out of scope for this book - but I think it is an important aspect to follow up on.

This book demonstrates the ideas behind TDD rather than endlessly explaining philosophical aspects. You will write tests, write code, clean up, refactor, delete code, and improve iteratively while having a test suite backing you up on each step. If you’ve ever wanted to refactor an unwieldy, complicated and untested piece of code, you know how daunting that is. Here, you will experience what the alternative feels like - and trust me, once you’ve experienced this, you don’t want to go back.

A Practical Developer Workflow

Finally, this book puts emphasis on an effective developer workflow. You will use git to version control your changes from the very beginning. Every step you take will be wrapped up by creating distinct commits in git to conclude you work. On top of that, Saleem dedicates an entire chapter to demonstrate how to set up a Continuous Integration (CI) build using GitHub Actions.

If you are relatively new to the trade, this will be an excellent and no-frills explanation of two immensely useful tools in a developer’s toolkit: Version Control and Continuous Integration. If you are a seasoned developer and familiar with git already, it’s nice to see how you can use TDD’s “RGR” cycle to size your commits into helpful and small chunks.

Should I read this book or Kent Beck’s “TDD by Example”?

“Learning Test-Driven Development” uses an approach that’s very similar to Part I of Kent Beck’s “Test-Driven Development by Example”. So why would you read this book instead of the original? And are there any reasons to prefer Kent Beck’s book to this one?

“Learning TDD” is a modern take on Kent Beck’s 20 year old seminal book on TDD. Instead of using a rather dated flavour of Java, you can choose between JavaScript, Python and Go. “Learning TDD” is using modern workflows that are widely regarded a good idea when developing software today (namely version control and CI). Finally, “Learning TDD” is a beginner-friendly, approachable, no frills, hands-on guide to get you up to speed with Test-Driven Development. Nothing more, nothing less. It’s not trying to sell you philosophical aspects of TDD, it’s showing you how to practice it. It assumes that you’re either willing to learn TDD or looking for a refresher, it does not assume you need to be fundamentally convinced that TDD is a good thing.

Kent Beck’s “TDD by Example” goes beyond being a hands-on workshop. On top of the Money code kata, Kent Beck’s original will cover fundamental thoughts and additional patterns more explicitly. In his last part, Beck goes on to explain patterns that make writing tests and testable code easier. As an example, Beck explains how to use Mock objects to test awkward interactions (like database calls), which is a quite common need web development. “Learning TDD” doesn’t come with a dedicated “Patterns” section but rather demonstrates some of those patterns and concepts as part of the journey the reader is going through. If you’re the person who prefers reading a pattern catalogue, Beck’s book might have what you’re looking for.

Where does this book fall short?

Learning and mastering Test-Driven Development is a long and nuanced journey. I’ve been using TDD for the majority of my career. I’ve written extensively about testing. I’ve taught others. Yet there are still things I don’t know. I still write tests that are low-value. I still end up with tests that are tied too close to the implementation. And, of course, I still get silly bugs into production that could’ve been prevented by a certain test. You will discover new patterns and approaches the longer you stick with it but you have to keep an open mind and keep exploring.

If you’re looking for a book that helps you get beyond the mechanics of TDD, a book that shows you advanced patterns and helps you navigate tricky situations, this book might not be what you’re looking for.

Here are some things that are not covered by “Learning Test-Driven Development”:

How to introduce TDD in a legacy codebase. I recommend Michael Feather’s Working Effectively with Legacy Code or the Understanding Legacy Code Newsletter if this is important to you.
How to deal with databases, caches, network calls? The book briefly introduces the (essential) concept of Dependency Injection but doesn’t go into too much detail. You might want to read Mocks Aren’t Stubs for more details here.
Advanced and nuanced patterns of test automation. Gerard Meszaros’ xUnit Test Patterns is a tried and trusted (but a little dated) pattern book that can help you here. You can also read a lot of the patterns online if you’re curious about Test Smells, Organizing Tests or how to work with Test Doubles (Mocks, Stubs, Spies and Fakes).
What are the limits of unit testing? When should you reach for different kinds of tests? And how do those fit into your TDD cycle? I tried capturing some of those thoughts in The Practical Test Pyramid but this is a very nuanced discussion.
How does TDD help drive more modular, decoupled designs? This is tangentially covered but you might long for a more in-depth discussion about cohesion, coupling, dependency injection and how TDD can be at the root of those.

All of these topics are omitted on purpose. This book aims to teach new and seasoned developers alike how to get to grips with Test-Driven Development and does not try to go beyond that. It is a start of a very rewarding journey. And the good news is that learning the very basics will equip you with a very powerful mindset that you can immediately use and expand over the coming years to write more maintainable code.

I heard TDD is dead. Why should I bother learning TDD today?

Yeah… no. Don’t fall for hyperbolic posts meant to drive clicks and spark controversy. TDD is a tool that helps you think differently about the way you write code. I recommend you give it a try and see if it clicks for you. I’m convinced that TDD helps write you write better and more maintainable code like no other tool in your toolbox but you don’t have to take my word as gospel. Learn it, play around with it, try to stick with it and see for yourself.

Initially it will feel unnatural. It will feel tedious. You might think your productivity is tanking and you will be tempted to go back to your tried and trusted way of writing code.

Stick with it. You will be grateful for your past self who has written automated tests when you come back to your code in the future. TDD will make it easier for your future self and your team members to read, reason about, and change your code for a long time. Over time you will learn that TDD is a tool in your toolbox. And as every other tool it has its limitations. If you are building a throwaway prototype, testing might not be helpful. If you are spiking a new framework and have no clue how things fit together, testing might not be helpful. On the other hand, you will be surprised to see how much TDD can help in prototyping and exploratory situations to provide a quick way of testing and asserting unknown behavior. As with every tool its best to get first-hand experience with TDD, learn where it falls short and take that as a chance to either reconsider your approach or reconsider your usage of TDD for this particular situation. Do not give up on TDD as soon as you hit the first obstacle.

My recommendation

Learning Test-Driven Development - A Polyglot Guide to Writing Uncluttered Code keeps its promises.

It teaches you how to use TDD
It demonstrates TDD in three different languages
It emphasizes refactoring, cleaning up, and de-cluttering code as you go

It is as hands-on as it gets and you should treat this book as something to work with to get the most out of it. Your mileage may vary if you’re reading it back to back before going to sleep.

Saleem Siddiqui has written a modern and to-the-point version of Kent Beck’s “Test-Driven Design by Example”. Every developer who wants to pick up (or refresh) TDD skills will get a lot out of this book. If you’re not willing to give TDD a chance because you already made up your mind that TDD sucks and you write better code without it, this book is not for you. If you allow yourself to tackle this book with an open mind, I promise that you will be rewarded with a new (or refined) tool in your toolbox – a tool that I personally consider the most valuable one in my own developer toolbox. I was fortunate enough to learn TDD directly from Saleem earlier in my career and I’m excited to see that now everyone can get a similar experience by working through this book.

How remote work changed my life

Mon, 21 Dec 2020 00:00:00 +0000

“Hey Ham, how’s this remote work thing going for you?”

I often heard this question after starting a new job at Stack Overflow remotely more than 1.5 years ago.Sometimes people asked out of genuine curiosity. They couldn’t imagine how working without ever being in an office could be a thing.

Other times people seemed to be concerned about my well-being, wondering if I slowly turned into a hermit who never got to see the sunlight again.

A year later, after the global Corona pandemic forced a lot of people to work from home for the greater part of 2020, that question had been replaced with

“Does your remote work experience suck as much as mine?”

All I can say is: It’s going great. I’m happier than I’ve ever been. And I wouldn’t want to change it back.

Quitting my job and moving to the countryside was a big step for me and my family. It was packed with concerns and anxiety. Would the new job be fun? Is working remotely something for me? Will rural life become boring after a few months? Looking back on 1.5 years of living this life I’m feeling grateful, content and happy with how well things turned out. As the year is coming to an end and I have some free time, I’m going to reflect on how leaving the city for a remote job and living in the small town I grew up in changed my life - and because the year has been enough of a shit show, I promise it’s going to be really positive.

More Time

Working remotely comes with one fundamental advantage: I save a lot of time. Instead of spending 2 hours on public transport on a typical weekday (or worse if I was travelling to clients) my daily commute now consists of grabbing a coffee and going from the kitchen to my office. That’s 2 hours of extra time each day. 10 hours each week. And I can use them for whatever I want, not whatever my commute permits.

Having more free time has a compound effect. More free time means more time for my family, for myself, for hobbies, exercising, sleeping well, reading, running errands, doing chores. All of these things help improve my mental and physical health and I can feel it. More time is the foundation for all the other benefits I’m seeing in working remotely.

More Space

I grew up in a small town where rent was affordable. Being a home owner was common, not a privilege for the richest 10%. Growing up with this kind of perception of the world made accepting cost of housing in a metropolitan area extra hard for me. There was no way how our combined household income could ever allow us to buy a house or an apartment we liked in Hamburg.

Working remotely allowed us to escape the ridiculous rents and costs of living in a large city. A year after moving back to the small town I grew up in, we bought a house that was both cheaper and larger than anything we’d have gotten in any metropolitan area.

Besides a bigger place to live in, I benefit from more space in general. Nature is just a step away and I can go for nice long walks easily. I enjoy being outside, experiencing nature and the sense of calm and solitude. Especially if I get to enjoy sceneries like this regularly:

A shot from one of my evening walks in fall 2020

My dog, Lenny

With a home, a yard and a lot of surrounding nature, it felt obvious that a dog would be a great companion for our family. I’m at home all day and on some days wouldn’t have a real reason to leave the house. With a dog by my side, I’d have a buddy hanging out in my office with me each day, someone I could talk to and, most importantly, I’d have a reason to get out multiple times a day.

So about half a year after I started working remotely, we got Lenny, a Labrador mix, and he’s the best buddy I could imagine.

My dog, Lenny, snoozing in his bed

With Lenny, I get to enjoy nature every day. My wife and I usually walk the dog together and it’s become my favorite ritual to start and end the workday.

More Exercise

Exercise has become an important aspect of my life about 7-8 years ago. As a young adult, I struggled with obesity and unhealthy lifestyle choices until health problems made me change my habits and lose a good amount of weight. I joined a gym, started to go running and be more mindful around the stuff I’d put into my mouth. About 3 years ago, I saved some money to invest in a small home gym setup that I put together in the basement of our rented apartment in Hamburg. Nothing fancy - a rack, a barbell, some weights and a bench - but good enough to keep me moving and improving my physical fitness. I experimented with different workout plans and managed to get the occasional workout in each and every week but I was nowhere as consistent as I wanted to be.

Now, with a remote work setup and more time at hand, I have the luxury of more routine that allows me to exercise more regularly. This year, I pretty consistently managed to work out 4 times a week for about 1 hour each time. Usually, I’ll take my late morning or lunchtime hours when the majority of my colleagues in later time zones are still asleep to step away from work for an hour and work out in the garage gym. This has worked incredibly well so far and allows me to work on my physical health, get some quality time away from work and come back refreshed and ready to tackle the second half of my workday.

Thanks to regular exercise paired with walking the dog daily, I’m feeling happy, energized and more resilient than ever before in my life. With a job that’s mostly mentally exhausting and otherwise involves sitting in a chair for 8 hours a day, I feel it’s really important to strike a good balance and make sure you get your body to be properly exhausted as well.

Quality Time

I noticed that I spend more of my free time in ways I’d consider quality time: time spent with my family, with friends, working on things that are important to me, building meaningful connections, picking up new hobbies.

Part of this is possible because moving meant that I’d live a lot closer to a big part of my family and my friends. Many of them live within walking distance from my home now. Being physically close to family and friends allows to drop by frequently and spontaneously. I can visit my parents, bring a bowl of soup I cooked to my grandma (you should see the joy!), help a friend with renovation work when they call and ask for help, meet at the pub to play a round of Doppelkopf and have a beer or two. All of this is far away from my day job. No computers, no programming, no digital anything. Just people, human relationships, getting your hands dirty or grabbing a beer with friends.

I often compare this to how I spent my free time during my previous job. I moved to Hamburg for the job, so naturally the vast amount of connections I had came from work - that’s how you meet people as an adult. With some people I felt like I’d have made rather meaningful connections and I love them dearly. Still, whenever we’d meet up, we ended up talking about work and work-related stuff.

A tight-knit community

As a small town kid I was used to the fact that I knew a lot of people around me and people knew me. This is both fun and frightening at the same time. When I left after graduating from school I was certain that I’m never going to miss the fact that everyone knew anyone.

And yet years later I started missing it. Being a totally anonymous person when buying bread at your baker, not knowing your neighbors (or caring about them at all) and being able to live side by side without ever bothering to get to know each other even in the most shallow way was bugging me ever so slightly.

I learned that I get a sense of joy from being part of a tight-knit community. When I buy bread from the bakery they know my name, we have a short chat about what’s going on in town and occasionally they’ll shove an extra sweet raisin bun into my bag. My neighbors care about each other and invite us over for a beer and barbecue on summer nights. If I need fresh eggs I send a text message to a buddy who’s got chickens in their yard and they’ll leave a pack of eggs out on their porch for me to pick up in exchange for a glass of cherry jam from my garden. If I need firewood I know this guy from the next village I can call who’s got plenty waiting to be picked up. Every so often, people need help with renovations, moving or work around the house - and they’ll just call and ask for help. Need a hand? Ask around and people will show up in no time. Need a tractor for some nasty yard work? A friend of a friend’s got one, ask and they’ll be there. It’s all about small favors and giving back every once in a while. This may sound cheesy to some but to me this feels like I belong to a community and it feels really nice.

Fewer options

Small town living is not all sunshine and rainbows, of course. Living in a city does bring its benefits and the most obvious one is certainly the vast choice of bars, restaurants, cafes, theatres, museums, concerts and other things to choose from. Over here, there’s merely a handful of pubs and a similar amount of restaurants to go to. Museums, theatres and cinemas are rare.

I can cope with the limited choice just fine. When I’d go out for a drink in Hamburg it’d usually be one of the same five bars. I’m not getting a huge kick out of posh restaurants or the latest foodie trends. And if I want to go to a concert, I’ll have to get tickets for a show in another city and drive there or get a place to stay for the night. For me, this works just fine but I acknowledge that 2020 has been an extreme outlier where a lot of public places have been closed for the better part of the year anyways.

A steady pace

Looking back on 1.5 years of working remotely from a small town makes me feel like I’m at a happy place at this point in my life. After quitting my previous job due to burnout, I try to consistently do a pulse check to see where my mental and physical health is heading and whether I’m still on the right track. After starting a job remotely, I feel like I’ve been running at a healthy and steady pace. I’ve got rich interactions in my daily life, within and outside of work. I feel a great sense of belonging, spend more quality time with my family than ever before and still have plenty of personal time. All of this is happening while I can still work on interesting things at Stack Overflow that impacts the life of a lot of people out there.

I’m truly grateful to be where I am today.

Doppelkopf — 3 Years Later

Wed, 11 Nov 2020 00:00:00 +0000

Almost exactly three years ago, I wrote an announcement about a new side project I started working on: Doppelkopf, a browser-based version of the popular German card game with the same name.

I’ve been quiet about its progress ever since. It’s not like I’ve written lots of other stuff either, but I’ve also been quiet about that project in particular. You might be wondering about the project’s fate. Did I give up? Hit a roadblock? Nuke the entire Git repository by accident?

Nope, none of it! Almost 3 years and over 1024 commits later the project is still alive and kicking and, just like when I started out, it continues to be a lot of fun to build.

Hey you… If you’re just here looking for the Play the Game button: Here it is. But you’ve gotta come back and read on, you hear?

Go ahead, play the game right here

Contributions haven’t always been steady. Life happens. I changed jobs, moved to the countryside, got married, bought a house, got a fluffy coworker, baked at least a dozen really decent pizzas, wrestled a dinosaur, a lot of grown-up stuff. I’m trying to get my priorities straight and a browser-based card game surely doesn’t take the pole position in my life (sad, I know).

When daily life gets more calm, it’s my own meandering that gets in the way of steady progress. I like it that way since I’m partially this project to get my hands dirty with technology I’m curious about and to escape from the everyday chaos.

Sometimes I feel bad for not getting something usable out there sooner but then I remember that no one out there gives a damn because it’s not on anyone’s radar anyways.

I’ve meant to write an official update, an announcement of sorts, for at least 2 years now. Never wrote it. Mostly because I felt that the game just wasn’t ready yet. “Just these three more features, then we’ll write the announcement” I’d keep telling myself.

Yes, I know the The Lean Startup says that I should get stuff out while I’m still embarrassed or I’ve waited too long. My job at ThoughtWorks consisted of reminding people that releasing frequently and getting user feedback early is super-duper important. I’ve used lofty words like “MVP” unironically. All that only to ignore what I’d know better.

And you know what? It doesn’t matter. We’re not trying to be the Uber for niche card games or the Tinder for people who can hold 10 cards in their hand while drinking a beer with the other. There’s no rush, no deadlines, no pressure. Just a blissful journey towards creating an Open Source card game; and maybe one day someone has fun playing it.

Now that I’ve explained that slacking is cool when I do it, let’s move on and look at the things that have changed since I wrote the first few lines of code 3 years ago, shall we?

Basic gameplay

When I wrote the first blog post about this project, I didn’t have much more than a bunch of unit tests and primitive game logic in place. You could create cards, sort them, find out if one card beats another card. Low-level building blocks, only held together by unit tests.

Fast forward to today and we’ve got a playable single-player game in place, presented with a decent user interface. You can start a game, play multiple rounds, win a game, lose a game (the computer players are crap - you better win this, my friend!), get extra points for catching a Fox or winning a Doppelkopf and get correct scores after each round.

Yes, the experienced Doppelkopf aficionado will immediately notice that some things are still missing: You can’t play a solo. You can’t make any announcements. The computer players (think I should start calling them AI and score millions in venture capital?) make questionable moves. And yet it’s fun to play already.

User interface

The game’s got an interactive user interface powered by plain old HTML, CSS and Vue.js. When you build a browser game, one of the fundamental decisions to make is how you want to render your user interface. You get a few choices:

use the good old DOM and reap the benefits that decades of web development have brought us, including CSS and all its clever layout technologies (flex and grid are heaven-sent)
render everything in Canvas if you favor low-level control and don’t want the comforts of CSS or need extra performance
use WebGL if you want to get really fancy
write everything in Flash and publish your game on newgrounds.com (just kidding, this isn’t 2003. Seriously, don’t do this!)

Doppelkopf is not a fast-paced 3D action shooter. We’re not rendering a lot of flashy animations nor do we care about high performance to let 4 players play one card turn by turn. On the contrary, we’re mostly dealing with rectangular shapes (cards), some icons and text that need to be moved around the virtual table neat and orderly. And this is where CSS and HTML are a great combo.

With Vue.js we can add a good amount of interactivity to handle simple interactions like “clicking on a card” or “pressing a button”. On top of that, its reactive programming model makes it really pleasant to represent the inner state of the game in the user interface without having to do any DOM manipulation by hand.

I decoupled the game logic from the user interface logic as strict as I could. The game is running entirely client-side, so both the game logic as well as the user interface are written in JavaScript. This makes it easy for the game logic’s and user interface’s boundaries to bleed into each other, making things harder to reason about in the long run.

Using a strict test-driven approach to developing the game logic helped keep these boundaries in place as it allowed designing APIs that are usable from tests only without any user interface in place. This way the game logic becomes its own, very expressive and isolated layer in the code that can represent the entire game’s state and behavior in plain old JavaScript. Vue.js is taking care of the user interface representation only and builds the components that allow us to display information and react on user input. I’m really happy about this strict separation as it makes testing painless and allows us to steer away from tedious state-management libraries like Vuex.

Design

My Kryptonite! The game doesn’t look like ass, and that’s the most positive thing you’ll catch me say out loud. Somewhere deep down I know that the game’s visual design is okay - the color scheme is decent and doesn’t look like Hot Dog Stand, I’ve used some rather smooth CSS animations, and I’ve made sure to check some accessibility aspects that I know of. This isn’t meant to be fishing for compliments but when it comes to visual design, I’m incredibly picky yet unable to produce something great by myself.

This is why improving the visual design of the game is a massive time sink for me. I’ve spent days finding and tweaking colors on coolors.co and Color Hunt. I’ve searched, sketched, scribbled logos more than I can count, only to come up with… two overlapping cards? Well, at least it’s all CSS and has got a slick hover animation!

Whoop whoop! It moves!

I’m okay with where we’re at right now but I know that there’s so much room for improvement. I want to break out of the bleak and ordinary look of the game and make it a little more fun, a notch more quirky. I’d love to use illustrations, print stickers and card decks and send them out to players, contributors, or project sponsors - but I think I’ll need some help there.

Infrastructure

This is a simple system. We’re not building a cloud-native, webscale, serverless event-driven microservice architecture (I really tried with the buzzwords here).

We’re talking about a backend process in Python that we need to run on a server, and we’re talking about a bunch of HTML, CSS and JavaScript that we need to get to our users’ browsers. And strictly speaking, right now it doesn’t even matter if the backend wasn’t available 24/7 (and it’d be cool if it stays that way in the future).

As much as anybody else I’m a big fan of keeping things simple. At the same time, I want to take this project as an opportunity to learn a bunch of new things. So we’ve gotta balance things to avoid falling off a cliff.

I’ve set up enough build pipelines and server infrastructure to know what it takes to get software out to production in an automated and repeatable way. At the same time, building servers, dealing with networking, watching build pipelines and provisioning scripts to finish and working on all the plumbing and duct tape required to combine these aspects is something that makes me consider quitting my developer life and moving to a farm at least three times a year.

For Doppelkopf’s infrastructure I wanted to find a pragmatic middle-ground. Something more modern than a hand-crafted snowflake server running in my mom’s basement. And certainly something less ridiculous than a full-fledged Kubernetes cluster running in a multi availability-zone setup with a global CDN in place. Let’s get some users first before we drown ourselves in infrastructure debt, shall we?

With all the noise and hype in our industry I found it incredibly hard to find the sweet spot and not fall for the siren sounds of cloud vendors and tool builders out there. Ultimately, I’ve ended up with this setup:

Terraform is automatically spinning up the infrastructure - servers, domains, networking and very basic provisioning
The Terraform configuration comes as an extra Git repository. Whenever I push changes there, a CircleCI pipeline will automatically build a new environment and deploy the application
Everything’s running on a single instance of the cheapest server you can get on DigitalOcean
The backend and frontend applications are built as Docker images and pushed to a Docker registry with every change (again, a CircleCI build pipeline kicking in)
For deployment I ssh into the target servers, pull both images from the Docker registry and start them with a simple docker-compose up
Caddy takes care of setting up HTTPS using Let’s Encrypt and serving the applications

This setup is simple and effective. And most importantly: It’s fully automated. This way, I can work on infrastructure after not touching it for months without having to curse my past self for what they’ve done.

Yes, there are obvious shortcomings: no load balancing, no redundancy, no sophisticated content delivery networks involved. And you know what? At this point in time I couldn’t care less. All of these are the kind of problems to solve once you’ve got enough users playing your damn game. Before that happens, I’m not going to lose any sleep over my lack of redundancy for serving something’s that’s basically a silly static website.

A boring mature tech stack

Remember how we all made the same lame joke about the JavaScript ecosystem? The one where the popular JavaScript frameworks change every other week? Yeah, I do remember and I’m totally guilty of that.

When I started this project, I placed a few technology bets and - believe it or not - they’ve held up nicely: Modern JavaScript, Vue.js, Jest, Python and Flask, Terraform, Docker are the main drivers.

None of these were risky bets when I made them. And that’s precisely the point: I chose mature and boring technology and I’m certain that this is why I still keep pushing 3 years later. Vue.js had been around for a good while. With vue-cli you get scaffolding with sane defaults to get started easily with an ecosystem that can quickly be overwhelming. JavaScript has matured significantly since its early days and with Babel and Webpack set up you don’t have to worry about compatibility all that much. Needless to say that Flask and Python have been a sane choice for the backend as well. The backend doesn’t do much more than provide a simple REST API and a few admin screens so pretty much every web framework out there would’ve done the job, but Python and Flask have been practical and pleasant to use, so there’s that.

That’s not to say that all of these technologies were rainbows and unicorns at all times. JavaScript - of course - continues to have its quirks and larger-scale refactorings are beginning to become tedious. Wrestling Webpack configuration has made me swear like a sailor more than once. And sometimes I wish I’d just bite the bullet and use a simple PaaS solution like Heroku to deal with all my infrastructure worries. But all of those are concerns that future Ham can deal with.

The road ahead

A lot has happened and the project has seen slow but steady progress. There’s still a lot of work to be done and I try to be transparent about the road ahead. I maintain a Product roadmap on GitHub for everyone to see. I’m excited about contributions of any kind (issue reports, documentation, design, feature ideas, code, you name it!) and I’m trying to make the project as welcoming as I can. If you want to join, be my guest. I’d be glad to have you!

Now that I finally got this heartbeat out in the open, I plan to write more regular updates with more detailed topics on specific aspects of the project in the upcoming weeks. Watch this space, check out the game and if you feel adventurous, come join me over on GitHub!

Building a Jira integration for Stack Overflow for Teams

Wed, 11 Mar 2020 00:00:00 +0000

I built an integration between Stack Overflow for Teams and Jira. This post takes a peek under the hood of that integration.

Distraction-free writing with vim

Sun, 02 Feb 2020 00:00:00 +0000

I’m a sucker for aesthetics.

And for command line tools.

And for things that just do their damn job.

From time to time, I feel like writing down my thoughts. That’s why this blog is a thing. My tool of choice is vim, a notorious command line editor that stood the test of time. It’s free, ridiculously fast (if you don’t slow it down with reckless plugins) and command-line based. This puts vim very close to my personal sweet spot.

A few years ago, distraction-free writers became a thing, beautifully designed applications with the sole purpose of letting you write stuff down. No frills. No gimmick. No distraction. Everything is presented to you, the writer, in a minimalistic design. Much like sitting in front of a typewriter, just you and the blank page. Scary!

I don’t know if distraction-free writing is really going to be the game changer for you to write the next best-seller novel - or even your first blog post for what it’s worth. But I do know that they’re fun to use.

With vim being my editor of choice, I didn’t want to switch to a different tool just to do what I could already perfectly do with vim, just in a more pleasurable design.

Luckily, vim has a good plugin system and there are some talented plugin writers out there. Junegunn Choi has written goyo.vim, a plugin that turns vim into a distraction-free writer as soon as you type :Goyo:

goyo.vim in action

If you need some distraction for your distraction-free writing, go and check out limelight.vim, written by the same author. limelight.vim will highlight the region around your cursor and display everything else in a more dim color. Just type :Limelight to get let your current paragraph shine in the spotlight.

goyo.vim with limelight.vim enabled

Install either plugin using your favourite plugin manager. You’ll find instructions and more details in the respective repository on GitHub. There you go. Distraction-free writing that’s hitting the sweet spot between aesthetics, command line efficiency and doing one job well.

Moving On

Fri, 05 Apr 2019 00:00:00 +0000

For the past 4.5 years I was a consultant and software developer at ThoughtWorks in Hamburg. It’s fair to say that there has never been a period in my life where I’ve learned so much about my profession, myself, society and my fellow human beings. My time at ThoughtWorks was a wild and exciting ride and an incredible experience.

Still, I felt it was time to move on.

You bet he was!

Being a consultant is a unique chance to learn a lot in a short time. Even more so when you’re surrounded by passionate and incredibly talented people as it’s the case at ThoughtWorks. You see different projects, work with clients who want to stir things up, and get the opportunity to hone your technology and people skills in a way you don’t see elsewhere.

It was a huge privilege to work alongside so many talented people, not few of them writing books, publishing blogs and giving talks that change the software industry at large. I had so much to learn from my fellow colleagues, sometimes about technology-related things, more often about the ways people interact and how I could become a better pairing partner, team member and consultant. It amazes me how much I learned about communication, architecture, programming, influencing, empathy, coaching, mentoring, leadership, issues in society, reflection, feedback, respect and not taking yourself too seriously.

For all of these experiences, for all the people that were there for me as friends, coaches, sponsors, sponsees, and colleagues, I’m grateful beyond belief.

Schietwetter on Hamburg’s Elbstrand

Being a consultant, however, comes with a flipside. The most obvious one is the flexibility that you need to bring to the table. As a consultant, you work with clients on their challenges. That often means being onsite, playing by their rules, listening to where their pain points are. There’s nothing wrong with that and if you’re joining a consultancy, that’s exactly what you sign up for. However, this flexibility around work location and topics you’re working on can take its toll. Personally, I was very lucky as most of my projects were located in Hamburg and didn’t require that I’d travel much - being a father, travel can become really tricky.

What really got me after a while was probably a combination of multiple things.

Uncertainty around my future (what would I do in half a year to come once my current engagement comes to an end?) often felt like a pending threat to me as travel was always a likely option for the next project. That would have meant shifting my family’s routine massively and put a lot of burden on my partner.

Frequent rotation of projects and roles means that you have the privilege to get to know a lot of people - colleagues as well as clients. Being a social and rather outgoing person, I usually got along well with most of them and was happy to get to know new people. I had to learn fast that every new relationship had an expiry date. With me or them leaving the project, chances reduced (sometimes drastically) that you’d meet again in a meaningful way. Relationships tended to remain shallow, real friendships remained few.

My commute was a bigger driver. We lived on the fringe of Hamburg. Public transportation is solid and we had a station close to our home. However, every single day I’d spend 2 hours on the train. That’s 10 hours a week of sitting on the train. I know, for a lot of metropolitan areas that’s common. Eventually I was fed up with the time spent commuting.

Cost of living is another big topic. Paying rent for the rest of my life doesn’t sound like a smart idea. Owning a home in Hamburg (even on the outskirts), however, was prohibitively expensive for us.

All of these were minor annoyances compared to the final straw: burning out.

ThoughtWorks is a place full of drive. People are ambitious and they know their shit. Having so many smart people around often gives you a feeling of not contributing enough. Imposter syndrome hits you, even if you know rationally that you don’t need to worry and that you’re getting a wrong perception by focusing on the collective highlights of hundreds of colleagues. In a system that rewards you for being engaged, driven and showing impact, I tend to strive. My journey at ThoughtWorks was quite successful (so I’d say) and I got great feedback over the years. In 2018 I discovered that this could kick-off a dangerous spiral of trying to over-achieve. At ThoughtWorks we are trying to be very mindful of that and have support structures in place that help people reflect on their situation to avoid running into dangerous situations. As I stepped into an internal, singular role in 2018, I lacked these routine support structures, however. This allowed me to grind myself down without having a team noticing. Luckily, I had a colleague coaching me during this time and she helped me recognizing my situation and hitting the brakes.

After weeks and months of being stressed, grumpy, short-tempered, depressed and sleeping badly, I realized that it was time for a radical change. After long reflections with my family we ended up leaving the urban life behind, quitting our jobs and moving back to the countryside, where me and my partner grew up. I’m fortunate to have a strong social network in the place where I grew up. Family and lots of friends I know from my teenage years are still there or came back after venturing out - and I’m happy that I’ve never lost touch. Cost of living is a different dimension, so is being close to nature and still having all the infrastructure I need for my daily life.

What’s next?

I’m so stoked that I was able to find a job that accommodates this change of scenery. Starting on Monday, I’m going to work remotely for Stack Overflow, a company that has always been part of my professional life. Working remotely always seemed intriguing to me ever since I’ve read Remote: Office Not Required and I’m grateful that I get a chance to experience this first-hand.

I’m aware that this lifestyle change is drastic and might come with certain drawbacks. I will miss people, I will miss the wide range of opportunities of a beautiful city like Hamburg, I will have to adapt to another lifestyle. However, I’m more than happy to have more time for my family, my friends and myself and a more calm lifestyle while being able to work on something exciting and meaningful.

Wish me luck!

Ham

Fri, 05 Apr 2019 00:00:00 +0000

My name is Hermann. And so is my father’s name. Growing up, I found this more annoying than charming. Living in one household with another person sharing the same name can lead to weird situations.

Going with a name like “Ham” gives you a perfect excuse to print silly stickers.

When my mother yelled “Hermann!” it was always a guessing game who was supposed to answer. Sometimes I could tell by her tone of voice, especially if I knew that it was either me or my father who was in trouble.

Deciphering the intended recipient for letters and packets was annoying. So was explaining insurance companies, banks or automobile clubs (looking at you, ADAC) that my father and I are not the same person.

The worst memory I have, though, is answering the phone. Having a small handyman shop, my father often went out to install or repair things. Living in a small town in the 90s and early 00s, a lot of communication was done over landline phones. My parents always encouraged me and my siblings to pick up the phone to help them.

It was a disaster.

Once my voice started to sound exactly like my father’s people couldn’t tell us apart on the phone. And answering the phone with “Hello, this is Hermann Vocke speaking” (of course I said this in German, not English) did not help avoiding that confusion at all. After a couple dozen calls from strangers who rambled about their broken washing machines, ordered parts for their dishwasher or yelled at me because they were not happy with “my” previous job, I simply refused to answer the phone. I suspect this was the root cause for my anxiety of talking to strangers on the phone for years to come.

Luckily enough, my family was good with nicknames. Growing up, I had quite a couple of them. Some were more playful, some were super awkward, and some more presentable. The one that ultimately stuck was “Ham” (pronounced either [hæm] - as in the English word for porky meat or [ha:m] with a German pronunciation, both are fine).

Ham or Häm is a quite common nickname for people named Hermann where I grew up. When Low German (“Plattdeutsch”) was the main spoken language about two generations ago, Hermanns became Häms the same way as Heinrichs became Hinnerks. For extra credit, you’d put the last name in front and use it in a possessive way: “Vocken Häm”.

Over the past couple of years, I embraced that name more and more as it has some adorable traits:

It’s short. Three letters, one syllable. I can completely enter it into old-school arcade game high scores, how cool’s that?
It’s unique. At least in combination with my last name. I can easily go with “hamvocke” as my handle when I sign up for an online service. Searching for Ham Vocke gets you to all things that are related to me. And once I started writing a bit more, it was helpful to establish Ham Vocke consistently as my online identity (a hint Martin Fowler gave me).
It’s personal. With its origin in a regional dialect there’s a regional touch to it.
It’s fun. People usually think of the meaty product first and are confused. Being a legit name of Low German origin it has nothing to do with meat, of course. Still, it allows me to embrace this double meaning in a tongue-in-cheek way. Like printing hundreds of really spiffy ham vinyl stickers that I can put on my stuff and hand out to people to remember me.

Being Ham has always been a lot of fun. The name has got personality and charm and that’s why I love it. ♥️

Ham 🍖

Using 'make' to Make Your Code Easy to Work With

Mon, 04 Mar 2019 00:00:00 +0000

In my daily work, I often switch between codebases. Each brings its own ecosystem of tools to create, manage, build and publish source code. One thing to help with the frequent switching is to have a single entry point to work with the source code in every project. I like to have a single wrapper script that allows me to run common commands I need for my daily developer life, no matter if I’m using Yarn, Cargo, Gradle, Pipenv or a wild combination of tools under the hood.

At ThoughtWorks, we often call this a go script (which, admittedly, became confusing after go, the programming language, has become a thing). Teams at ThoughtWorks often create these scripts to make it easy run common tasks automatically: I can call ./go build to compile my source code, ./go test to run the test suite, or ./go run to start the application locally, regardless of the tools that are used under the hood. Pete Hodgson wrote a nice series of articles in praise of the go script to describe this practice in more detail (Part II is here).

Having a script as a single entry point makes your code more accessible to other developers (and your future self!). It’s easy to do the things you want to do without memorizing long-winded commands. It’s easy to switch between different projects as the commands stay mostly the same. And it’s easy to discover what’s possible (by running ./go help) which helps getting new people up to speed.

`go` Scripts: An Example in Bash

Most of the go scripts I’ve seen were written in bash and roughly followed the same structure of parsing the first parameter and then mapping that to certain actions:

#!/usr/bin/env bash
set -e

function usage {
  # print usage information
}

function build {
  # trigger build process
}

function test {
  # run test suite
}

if [[ $# -lt 1 ]]; then
  usage
  exit 1
fi

TARGET=$1
case $TARGET in
  "help" )
    usage
  ;;
  "build" )
    build
  ;;
  "test" )
    test
  ;;
  *)
    fail "Unknown command '${TARGET}'"
    usage
    exit 1
  ;;
esac

Bash is a natural choice for simple automation tasks like this as it’s often available on developer machines (and your continuous delivery server) and is undeniably powerful.

More recently I discovered that using make can be a better fit for what we’re trying to achieve here. Let’s see how.

make and Makefiles

make itself is more powerful than what we’re using it for here. Usually it’s used for build automation and especially popular in the C/C++ universe for compiling source code but that doesn’t stop it from being useful for other things.

If we want to use make as a simple wrapper to interact with our source code, we don’t need all of its bells and whistles and can start with understanding a few basics:

make looks for a file called Makefile in your current directory to figure out what it’s supposed to do. A Makefile is a plain text file that defines the different rules you can execute.

A rule follows this pattern:

target: dependencies
    system command to execute

The target defines how you call the rule from your command line. make initialize-database would look for a rule called “initialize-database” and execute the commands you defined.

An Example Using `make`

Let’s assume, we have a Python codebase using Flask and want to have a simple way to perform three different actions:

run unit tests
start the application locally
run a code formatter

A corresponding Makefile looks like this:

.PHONY: test run format

test:
	pipenv run pytest

run:
	export FLASK_ENV=development && \
	export FLASK_APP=myapp && \
	pipenv run flask run

format:
	pipenv run black myapp/

Note: keep in mind that make is picky about indentation. You need to indent your commands with a Tab.

Once we put this Makefile at the root of our project we can simply run make test, make run or make format from our command line to perform the tasks we defined.

.PHONY targets

If you take a close look at the first line of our Makefile you’ll see a line starting with .PHONY::

.PHONY: test run format

This line declares all three of our targets as phony targets, i.e. targets that do not produce or depend on files on our file system. This answer on Stack Overflow does a fantastic job of explaining what this is all about. In a nutshell: make usually expects to create files as output of the targets we run. If these files are in place, make won’t do anything.

As an example: Take the above Makefile. If we had a file called “format” next to our Makefile and didn’t declare the format target as a phony target, make would lazily refuse to do anything once we run make format. It would just claim:

make: `format' is up to date.

We can’t avoid that someone creates a file with the same name as our make targets. To avoid breaking our make automation, we declare all our targets as phony targets. This way we’re safe from running into the pitfall of having name clashes with files on our file system.

Dependencies

One of the strengths of make is the possibility to declare dependencies between targets. Usually this is meant to work with files on our file system again but we can also use it to chain the rules we have created in our makefile.

Imagine you have a clean target that removes all compiled files from your file system. Occasionally you want to run the clean target by itself but you also want to run it every time before you compile your source code again (because you have way too much time at hand and incremental builds are just not your cup of tea 🤨). In this case you could declare the clean target as a dependency for your build target and make would run clean every time before it runs the build target:

clean:
    rm -rf build/

build: clean
    # whatever you have to do to build your code

Autocompletion

Another cool gimmick when using make is that some shells provide autocompletion for your targets, either out of the box or by installing a small utility package. zsh and fish support make autocompletion out of the box. If you’re a bash you can get autocompletion - not only for make - by installing this package.

With make autocompletion in place, you can start typing make in your command line and hit tab repeatedly to cycle through the available targets defined in your Makefile.

Caveats

Using make is an easy way to make your project’s source code easy to work with. Make certainly is powerful and that power comes with great responsibility. Makefiles can grow out of hand quickly. Personally, I wouldn’t use make for anything that’s way more complex than what we’ve outlined here. If you just need small wrappers around a certain set of commands, make is a good way to go. It’s available on most systems and your Makefile can be simple and maintainable. As with every tool, you can go overboard easily and produce something that will haunt you for years to come.

Find your sweet spot, and don’t forget what the people collaborating with you feel comfortable with. Just because you’re cool with a big plate of Makefile spaghetti it might not be the best idea to write everything in make. My personal take is that if you need scripts that are more complex than a verb + noun combination (i.e. go deploy production --version=latest instead of make test or go build) you might want to look into something different than make - bash or your scripting language of choice being good options.

Testing Ansible Provisioning Locally

Fri, 14 Sep 2018 00:00:00 +0000

Whenever I need to provision servers I reach for bash scripts or use Ansible to do the tedious work of installing packages and configuring services for me. In contrast to other provisioning tools both Ansible and bash have no built-in way to test that the scripts you’re writing actually do what you want them to do. Spinning up a real server in order to test your scripts, can either become expensive or simply annoying. Time to fix that.

With the help two little tools, we can make local testing of provisioning scripts faster and more pleasant. It’s my go to way these days - there might be more sophisticated approaches out there but this is what works well for me (I’m not doing any rocket science anyways).

We’re going to use Vagrant to spin up a local VM, provision that VM with Ansible and then use Serverspec to verify that everything worked as intended.

Example Code Repository

You can find a simple example of everything I describe here in my example repository on GitHub. Check it out, fork it and use it as a foundation for your next project.

Vagrant Setup

After you’ve installed Vagrant on your machine you’re ready to spin up a virtual machine on your local computer.

A Vagrantfile in our project root will configure Vagrant. With this file you declare the operating system image Vagrant should use for the VM. You can also configure networking and provide additional steps to provision the VM.

The following Vagrantfile will make Vagrant spin up an Ubuntu machine and run Ansible during Vagrant’s provisioning step. Ansible will run on the VM, not on the host, as we’re using ansible_local, not ansible as our provisioner. After running Ansible, Vagrant will then use Serverspec to run our tests.

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.provision "ansible_local" do |ansible|
    ansible.limit = 'all'
    ansible.inventory_path = 'hosts'
    ansible.playbook = 'local.yml'
  end

  config.vm.provision :serverspec do |spec|
    spec.pattern = 'test/*_spec.rb' # pattern for test files
  end
end

Before we can use this configuration, we need to install the vagrant-serverspec plugin:

$ vagrant plugin install vagrant-serverspec

Ansible Configuration

I like to use Ansible playbooks and roles, even if what I’m doing is quite small. In the example repository I’ve added a simple role that installs nginx on our virtual machine. This can be a good starting point for you to go crazy and add more steps to your roles, more roles and do whatever you have to do in order to provision your server.

Inventory

Ansible uses a so-called inventory to find out which hosts to provision. For testing, we declare localhost (the [local] block). We also declare all our other remote servers that we want to provision in this file (similar to the [some-other-server block).

[local]
127.0.0.1 ansible_python_interpreter=/usr/bin/python3

[some-other-server]
<some_remote_ip> ansible_python_interpreter=/usr/bin/python3

Playbook

Playbooks are a way to tell Ansible what roles to apply to which hosts and how to connect to these hosts. For our local testing, we have a special playbook called local.yml. In our Vagrantfile we tell the Ansible provisioner to use this file as the playbook that should be executed for provisioning the VM.

- hosts: local
  connection: local
  become: yes
  become_user: root
  roles:
    - nginx

As we’ve configured ansible_local as the provisioner for Vagrant, we tell our playbook to use a local connection to the host declared with the name local in the Inventory (the hosts file). Remember, Ansible is executed on the VM directly, not on the host, that’s why we use a local connection instead of ssh here. Also, we define that our playbook should execute the nginx role only.

Besides the local.yml playbook, we can have multiple other playbooks that we can then use to tell Ansible how to provision our real servers and what roles to apply. I’ve added an example for remote server provisioning in the example repository.

Serverspec Tests

Vagrant and Ansible are set up and we have a simple Ansible role in place. It’s time to look at our Serverspec tests in the test directory.

Change the tests according to your needs and provisioning steps. Make sure that all your test files end with the _spec.rb pattern so that our Vagrant provisioner can find them.

This is what a simple test will look like:

require_relative 'spec_helper'

describe service('nginx') do
  it { should be_running }
end

describe port(80) do
  it { should be_listening }
end

The Serverspec documentation gives you an overview over a lot of helpful resource types you can use for your tests.

Workflow

With this in place, you can go ahead, write your Ansible roles and test them properly with Serverspec.

To test your provisioning scripts locally, simply use vagrant up or vagrant provision to spin up and provision your Vagrant VM. After a short while you’ll see the output of both, Ansible and Serverspec in your terminal and you’ll know if everything worked as intended or if there’s a problem with your ansible scripts:

PLAY [local] *******************************************************************
TASK [Gathering Facts] *********************************************************
ok: [127.0.0.1]
TASK [nginx : Install packages] ************************************************
changed: [127.0.0.1] => (item=[u'nginx'])
TASK [nginx : Restart nginx] ***************************************************
changed: [127.0.0.1]
PLAY RECAP *********************************************************************
127.0.0.1                  : ok=3    changed=2    unreachable=0    failed=0
==> default: Running provisioner: serverspec...
..
Finished in 0.53478 seconds (files took 0.08154 seconds to load)
2 examples, 0 failures

Once you’re sure that your provisioning scripts work correctly, you can provision your remote servers by calling Ansible with a different playbook:

ansible-playbook remote.yml -u root -i hosts

That’s all there is. Go ahead, provision and test all you can!

A "Doppelkopf" Browser Game

Sun, 26 Nov 2017 00:00:00 +0000

I grew up in the countryside of northern Germany. Growing up sorrounded by woods and fields you get to appreciate some rather traditional, maybe even old-fashioned parts of German culture. One of these things is learning to play card games like “Skat” or “Doppelkopf”.

I remember my father and my uncles playing Doppelkopf for countless hours every year when we visited my grandmother (also an avid Doppelkopf player) for Christmas. Later at school, people played Skat or Doppelkopf in their breaks. Going to the pub you could sometimes spot people playing these games as well.

“Die Skatpartie” by Josef Wagner-Höhenberg

Luckily, I learned the complex rules of Doppelkopf from my parents when I was a child. We played here and there. I was good enough to internalize the basic rules but never good enough that I could challenge more experienced players. Try playing with your grandparents and you’ll learn what losing looks like. After all, these folks have been playing that game all their lives. They’ve seen it all, have played every hand there is to play and recognize every tiny mistake you do. It’s intimidating.

Earlier this year, some friends asked me if I wanted to join their Doppelkopf group in Hamburg. Knowing the basics of the game I was excited to join. Now we’re meeting once a week at a random pub or down at the harbour, have a beer or two and play Doppelkopf. It’s great fun and a nice breakout from my otherwise overly digitalised daily life. Every now and then a stranger stops by to kibitz. They always seem fascinated or even nostalgic by the archaic scenery of people playing traditional card games these days.

Doppelkopf is a complex game. It has a lot of rules, exceptions from these rules and the occasional exception from these exceptions. It’s best played with four players who form two different parties in each game (Re and Kontra). It’s all about taking tricks and getting the beter score for your party. To make it even more difficult, every group of players tends to have their very own set of extra rules. The game is full of jargon. For bystanders a conversation about the game simply sounds like a bunch of gibberish. Despite the steep learning curve it’s really rewarding to learn the game. The countless hours of fun and socializing really make up for it.

Playing Doppelkopf in a Cafe in Hamburg, not meant to be a shameless plug for Astra

I have to admit that I kind of suck at Doppelkopf. My friends often kick my ass. I’m not good at memorizing all the special rules that are out there. I don’t dare to play a Solo because I know I’ll screw up. I’m bad at tactics and I can’t remember which cards have already been played in the current game. Fortunately Doppelkopf is a team effort and you rarely play on your own in a game. So my friends often make up for my lack of skills.

At one point I thought that I should have some practice to improve my game. As you might imagine, practising multiplayer game on your own is quite challenging. I looked out for Doppelkopf browser games and Android apps and sure enough there are plenty of them. Unfortunately almost none of them lived up to my expectations. They required you to register with your Facebook account, were full of ads or in-app purchases and required you to be online the entire time. I was rather looking for a no-frills, no-bullshit version. Something I could play as much as I’d like without being bugged with ads or having to fear about my personal activity being tracked with every step I take.

I’ll Build My Own Doppelkopf Game

Being a software developer I obviously found the best solution for this problem. “I’m gonna build this myself!” was my proclaimed goal.

Yeah, right, because that always works so well. Having quite a track record for starting side projects that I never finish (who hasn’t?) I know I’m probably lying to myself when I say that I’ll definitely finish that one. Still, I decided to build my own game, mainly for two reasons:

Implementing your own Doppelkopf game will teach you a lot about the game
I don’t get to do too much coding these days so a side project is more than welcome

I also found a niche for my game to live in. Seeing all the ad-infested bells-and-whistles games with social media integration out there, I knew I should build a game that has nothing of that. I thought about the great 2048 game and how often I used to play it on my daily commute because it was free, simple, didn’t require any installation and allowed me to play even without an internet connection. I knew that my browser game should have similar goals. That’s why I decided that the Doppelkopf game I’m building should be

free (as in free beer), forever, no discussion
Open Source, available for everyone to see, modify and learn
without ads or in-app purchases
easy to start, ideally just loading a website
available and playable when you’re offline

That’s a lot. Especially the offline part is giving me a headache as this means I’d need to build an AI for the other players. I’ve never done that one before so that’s going to be a nice challenge. Still, I’m certain that it’s worth it. I want the game to be as open and respectful of the user as possible. No bullshit, no screwing up the users.

Implementing the Game

Finding a tech stack was quite straightforward. As it should be an offline-first browser game there isn’t much technology to choose from. Back in the days I could have chosen Flash. Luckily, these days are over. I don’t want the user to install any plugins to play the game. They should just visit a website in their browser and be ready to play. This left JavaScript as the only option. It’s understood by every browser out there and has matured significantly over the recent years.

I sensed my chance to refresh on my frontend JavaScript skills for this task. I knew I wanted to use the latest JavaScript features available but had to keep in mind that even modern browsers do not support all of these features yet. So I got my hands dirty and set up Webpack and Babel to allow me to write the latest ECMAScript and to transpile it to JavaScript that today’s browsers can understand.

Fortunately I had a short-cut to understanding the setup of these tools. Peter Jang has written an excellent introduction to modern JavaScript that got me up and running in a breeze.

The Card Game Kata

I quickly noticed that writing a card game as code makes for a fantastic code kata. If you think of it as a domain modelling excercise it shapes up quite nicely.

A card has a suite and a rank
The rank of a card defines it’s value
A deck consists of 40 cards ¹
Each player has a hand of 10 cards
A hand can be Re or Kontra
A trick goes to the player who played the highest card

And so on.

So far I’ve been busy capturing the essence of Doppelkopf in a domain model. With the help of Jest I worked on this in a strictly test-driven way. Being test-driven (and having set up a CI server) allowed me to work on my Doppelkopf game whenever I had a few minutes to spare. I could split the complex ruleset of Doppelkopf into hundreds of small-scoped bits and pieces that could be implemented within a couple of minutes. Having tests and a continuous integration server in place allows me to come back to where I left at any time.

I’m taking some extra care of massaging my domain model into a shape that’s pleasant to use and easy to read. With a domain as tangible as a card game this has worked really well. Take a look at these code snippets to see what I’m talking about:

test('a hand without queen of clubs is kontra', () => {
    const cards = [
        queen.of(suites.spades)
    ]
    const hand = new Hand(cards);

    expect(hand.isKontra()).toBeTruthy();
    expect(hand.isRe()).toBeFalsy();
});

class Hand {
    // [...]
    value() {
        return this.cards
            .map(card => card.value)
            .reduce((acc, value) => acc + value, 0);
    }

    // [...]
}

test('hand has a value', () => {
    const cards = [
        queen.of(suites.spades),
        ten.of(suites.hearts),
        ace.of(suites.diamonds)
    ]
    const hand = new Hand(cards);

    expect(hand.value()).toBe(24);
});

These tests are easy to understand, even if you don’t know the rules of Doppelkopf. They serve as a good documentation, make it easy for me to reason about small portions of the complex game at a time and the sum of these small portions add up to the wonderful game that is Doppelkopf.

Moving on

Right now my card browser game is only a bunch of domain classes and tests. There’s nothing visible and I’m not even talking about anything that’s remotely playable yet. Still, this excercise has been so much fun for me and allowed me to work in a pace that keeps me motivated to move on, one simple rule at a time. The source code is already available on GitHub, feel free to check it out and track the progress.

There will be huge challenges further down the road. When I told my friends that I’m building a Doppelkopf game, they first raised the question how I wanted to build an AI for singleplayer mode. Actually, I don’t have a clue. I’ve never done this before and don’t know how to approach this. I guess there’ll be some research for me to do and a long way until I have build something that is more clever than a bunch of if-else statements.

My friends also asked if there will ever be a multiplayer option for this game. This, however, is so far further down the road, that I’m not even thinking about it yet. I guess implementing multiplayer should be possible and is probably even easier than building a good enough AI. Still, for building a multiplayer version I’d first have to build a game that’s at least somewhat playable.

I’m really excited about this side project. I’m in here for the challenge and hope that reasoning deeply about the game makes me a better Doppelkopf player after all. Let’s see how long I can keep this project alive and let’s keep fingers crossed that it doesn’t end up at the side project cemetary like all the other things I’ve successfully abandoned.

Stay tuned!

Footnotes

At least in the version my friends and I play. We don’t play with nines. ↩

E-book Release of Testing Microservices

Thu, 28 Sep 2017 00:00:00 +0000

Ham… I opened that Testing Microservices blog post you bugged me with. It said “37 minutes read”. Then I opened the second post and it said “43 minutes read”. Then I closed my browser. Are you serious?

That was the first feedback I received from Manuel and Lukasz, two of my lovely coworkers. I guess they had a point.

Yeah, I know. Things got a little out of hand when I wrote the last blog post series. It’s a little long and reading long blog posts might not be your thing. After receiving overly positive feedback from the folks who were persistent enough to read through the hughe wall of text online I figured out it makes sense to publish Testing Microservices for more accessible offline reading.

With the help of the fantastic Asciidoctor I published the article as an E-book.

It’s all open source and available on GitHub ready for you to download. Go ahead and grab the latest PDF, EPUB or MOBI version, send it to your e-reader and read the whole thing offline as often and as slow or fast as you like.

If you spot any typos or mistakes I’d love if you’d send me a pull request.

Download the E-book

PDF EPUB MOBI

Have fun!

Testing Microservices — Java & Spring Boot

Tue, 19 Sep 2017 00:00:00 +0000

Update: This article has found a new home on Martin Fowler’s blog. Find a revamped, edited and more streamlined version under the new title “The Practical Test Pyramid” on martinfowler.com. Have fun!

Prefer to read this on your e-reader? An older version of this article series is also available as an e-book.

Testing Microservices

Mon, 18 Sep 2017 00:00:00 +0000

Prefer to read this on your e-reader? An older version of this article series is also available as an e-book.

Remote Pair Programming Made Easy with SSH and tmux

Tue, 03 Nov 2015 00:00:00 +0000

Pair Programming has found wide adoption in software development ever since it became popular with the rise of Extreme Programming and other agile development approaches. This practice where two developers are working on the same machine and the same task has some really neat advantages over working all by yourself. Working in pairs results in higher quality, spreads knowledge between your team members and ultimately leads to higher satisfaction. Sounds cool? Well, it is!

However, pair programming often becomes difficult as soon as the development team is spread accross different locations. People might be working from home. Parts of your team might be located at a different office, maybe even in an entirely different country.

The idea of pair programming has been around for more than a decade by now. A lot of companies and products have emerged (and vanished!) over time to make remote pair programming easier. Different solutions for different needs. From fully fledged screen sharing and collaboration solutions like Pop (formerly “Screenhero” which got then acquired by Slack), over shared VNC sessions to IDE and editor plugins like VS Code’s Live Share or JetBrains’ Code With Me, there are a lot of solutions for remote collaboration on code.

If you don’t need all those bells and whistles, if you like to keep control over where your data is going, or if you’re just a weirdo who loves inconvenient things, you can use a much more low-fi and terminal-based solution to collaborate on your code. A simple combination of SSH and tmux¹ is all we need to setup a really effective and lightweight remote pair programming environment. We can use all of our beloved command line tools with finely tuned dotfiles and pat ourselves on the backs for working the way our grandparents intended.

What are we going to do?

Let’s imagine we have two developers, Alice and Bob. They want to collaborate on a task and since they both are comfortable using the command line they decide to set up a shared terminal environment to work together.

Alice and Bob connect to the same machine using SSH. They decide to use a dedicated pairing server that both of them ssh into. Setting up a server with SSH access on DigitalOcean or AWS is a no-brainer nowadays. They simply add their public keys to the ~/.ssh/authorized_keys file and then can connect securely without needing a password.

Alternatively they cold also designate Alice’s or Bob’s machine as the pairing host. In this case the respective other person has to ssh into the other dev’s machine and they’re set.

Once they are connected to the same machine, they can use tmux for a shared environment. tmux’s client-server architecture allows multiple clients to connect to the same sessions on a server (we’ve got all that session handling stuff covered in the intro guide). That’s perfect for our plans. We can have one session that holds all the windows and panes and can connect one client for each developer.

The simplest setup is using the exact same session with multiple tmux client instances. The following steps will get us there:

Alice and Bob ssh into the same server
Alice creates a new tmux sesssion: tmux new -s shared
Bob connects to that session: tmux attach -t shared

Please note that “shared” will be the name of the session, feel free to give it any name you like.

From here Alice and Bob can happily hack away on their terminal and make use of all the fancy features offered by tmux. They can create panes and windows, launch different command line applications and pair happily on their tasks. They can even detach from that session and return at any later point. Both will see the exact same output in their respective terminal window.

This is what it will look like in action:

But somehow Alice and Bob feel that this is not quite perfect. There are situations where they want to work on different stuff while still being in that session. But as soon as Alice switches to a different window to work on her tasks, Bob’s terminal will also switch along.

Independent window switching

Instead of sharing the exact same session between multiple tmux clients, we can also create multiple session within the same window group. The result is similar to what we’ve seen above with one difference: Each developer can switch tmux windows independently.

All contents of the windows will be synchronized between all clients. But each client can decide individually which window’s content should be shown at the moment. This allows Alice and Bob to work independently on different tasks if they feel the need to do so. Whenever they want to go back to normal pairing they can switch back to the same tmux window and will see the same content again.

This is how independent window switching will look like in action:

The steps for this setup are a little different:

Again, Alice and Bob ssh into the same server
Alice, as before, creates a new tmux session: tmux new -s alice. tmux will implicitly create a new window group
Bob does not join that same session. Instead he starts a new session and connects that session to the same window group as Alice’s session: tmux new -s bob -t alice

That’s it. Now both can move between tmux windows independently. The content (including panes) within those windows will be synchronized between all clients.

If you want to get a feeling for what’s happening behind the scenes you can simply look up what sessions and window groups have been created after Alice has created her session. A simple tmux ls will reveal what’s happening:

bob: 2 windows (created Mon Nov  2 22:51:24 2015) [80x23] (group 0) (attached)
alice: 2 windows (created Mon Nov  2 22:50:36 2015) [80x23] (group 0) (attached)

As you can see, there are two sessions with their respective name. Both sessions are in the same group (group 0) and therefore share the same windows.

Benefits and drawbacks

To me this is a really nice and lightweight solution if you want to collaborate remotely. You can use it for pair programming, to troubleshoot issues on your servers together and much more. However, you need to be aware that this is a solution with a lot of restrictions. You’re completely bound to the command line and its tools, there’s no way around it. You also need to have a separate channel to talk to each other

If you are looking for a fully-fledged solution that allows you to use tools outside of the command line and also includes audio and video conferencing, one of the previously mentioned tools and services might be better suited for you. But if you need something really lightweight that you can control completely on your own and are not afraid of the command line, this setup might be perfect for you.

One last honorable mention goes out to tmate.io. Tmate is a service that creates the setup I’ve just described to you in an ad-hoc fashion. If you want to avoid the (quite small) hassle of setting up your own ssh server, tmate might be interesting for you.

If you have any further experience or opinions feel free to share them with us in the comments section!

Footnotes

If you don’t feel familiar with tmux or need a quick refresh take a look at my introductory guide to tmux. ↩

Fun and Useless Tools for Your Command Line

Sun, 25 Oct 2015 00:00:00 +0000

Ah, the command line. Home of ancient power tools with text-only interfaces, loved by geeks, avoided by everyone else. Did I already mention, that I love the command line? (Oh yes, most certainly). Superficially the command line looks plain and boring and I can totally understand why people are reluctant spending any time there while everything else is nice and shiny these days. But behold! There are some really nice gimmicks to make your command line experience more fun. Don’t ask for the value of these, there probably is none. But maybe that’s why it’s so fun. These are some of my favorite useless command line applications that I keep showing to people who actually don’t want to know.

Cowsay

This is a real classic. Cowsay uses ASCII art to create a nice cow with a speech bubble that’s filled with any text you like. Cowsay is available for Linux and Mac and can easily be installed with your favorite package manager. After that your ASCII cow fun is only a cowsay yourTextHere away:

If you feel extra fancy you can make cowsay display other stuff than just plain cows. Cowsay uses cowfiles that serve as templates for your cowsay output. Using cowsay -f <cowfile> yourText you can tell cowsay to use a different template. To see which cowfiles are available simply run cowsay -l and see what’s available. You want Tux instead of a cow? cowsay -f tux is here to save your day.

Did you know that Ansible automatically detects if you have cowsay installed? If it finds a cowsay installation on your system it will use it by default for all its log messages. Here’s how they’re doing it. Awesome stuff, Ansible!

sl – the command line steam locomotive

Ever felt like being too productive? Or maybe you want to annoy some of your colleagues? sl is here to save your day. This little command is invoked by typing sl into your command line. Looks pretty similar to mistyping ls, huh? Well, that’s the point. If you have sl installed (again, available through your package manager), mistyping ls as sl will no longer show an error message but present you a slowly moving ASCII art locomotive driving smoothly through your terminal window. Want to interrupt it using Ctrl c? Nope, not gonna happen, you have to wait until completely passed your terminal.

lolcat – like `cat` but with rainbows

I know the feeling, sometimes your command line simply lacks color. What could be better to fight this feeling than lovely rainbows? lolcat has you covered. lolcat acts exactly like cat which you can use to print text to your command line. The difference: lolcat will make all your text rainbow colored.

Of course you can also use it in combination with pipes. A simple gem install lolcat will bring this piece of rainbow-awesomeness to your machine.

figlet - create ASCII banners from your command line

I have a knack for ASCII art. Seriously. That’s why I love to play around with figlet so much. Figlet creates big ASCII art characters from your input text. You can choose between many different fonts and create something really awesome in no time. Once again available through your favorite package manager, figlet will simply take your desired text as input an create beautiful ASCII art out of it. Just call figlet yourText to get started.

Want to see which other fonts are available? Use showfigfonts to get a preview of all the fonts that are installed on your system.

Making tmux Pretty and Usable - A Guide to Customizing your tmux.conf

Mon, 17 Aug 2015 00:00:00 +0000

In my previous blog post I gave a quick and easy introduction to tmux and explained how to use tmux with a basic configuration.

If you’ve followed that guide you might have had a feeling that many people have when working with tmux for the first time: “These key combinations are really awkward!”. Rest assured, you’re not alone. Judging from the copious blog posts and dotfiles repos on GitHub there are many people out there who feel the urge to make tmux behave a little different; to make it more comfortable to use.

And actually it’s quite easy to customize the look and feel of tmux. Let me tell you something about the basics of customizing tmux and share some of the configurations I find most useful.

Customizing tmux

Customizing tmux is as easy as editing a text file. tmux uses a file called tmux.conf to store its configuration. If you store that file as ~/.tmux.conf (Note: there’s a period as the first character in the file name. It’s a hidden file) tmux will pick this configuration file for your current user. If you want to share a configuration for multiple users (e.g. if you should feel the urge to start tmux as super user (please think about this carefully!)) you can also put your tmux.conf into a system-wide directory. The location of this directory will be different accross different operating systems. The man page (man tmux) will tell you the exact location, just have a look at documentation for the -f parameter.

Less awkward prefix keys

Probably the most common change among tmux users is to change the prefix from the rather awkward C-b to something that’s a little more accessible. Personally I’m using C-a instead but note that this might interfere with bash’s “go to beginning of line” command¹. On top of the C-a binding I’ve also remapped my Caps Lock key to act as Ctrl since I’m not using Caps Lock anyways. This allows me to nicely trigger my prefix key combo.

To change your prefix from C-b to C-a, simply add following lines to your tmux.conf:

# remap prefix from 'C-b' to 'C-a'
unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix

Sane Split Commands

Another thing I personally find quite difficult to remember is the pane splitting commands. I mean, seriously? " to split vertically and % to split horizontally? Who’s supposed to memorize that? I find it helpful to have the characters as a visual representation of the split, so I chose | and - for splitting panes:

# split panes using | and -
bind | split-window -h
bind - split-window -v
unbind '"'
unbind %

Easy Config Reloads

Since I’m experimenting quite often with my tmux.conf I want to reload the config easily. This is why I have a command to reload my config on r:

# reload config file (change file location to your the tmux.conf you want to use)
bind r source-file ~/.tmux.conf

Fast Pane-Switching

Switching between panes is one of the most frequent tasks when using tmux. Therefore it should be as easy as possible. I’m not quite fond of triggering the prefix key all the time. I want to be able to simply say M-<direction> to go where I want to go (remember: M is for Meta, which is usually your Alt key). With this modification I can simply press Alt-left to go to the left pane (and other directions respectively):

# switch panes using Alt-arrow without prefix
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D

Mouse mode

Although tmux clearly focuses on keyboard-only usage (and this is certainly the most efficient way of interacting with your terminal) it can be helpful to enable mouse interaction with tmux. This is especially helpful if you find yourself in a situation where others have to work with your tmux config and naturally don’t have a clue about your key bindings or tmux in general. Pair Programming might be one of those occasions where this happens quite frequently.

Enabling mouse mode allows you to select windows and different panes by simply clicking on them. I’ve found that this might mess a little bit with simply selecting text in your terminal using the mouse. You might experience the same, depending on your environment. So you should consider if this configuration is something that’s worth it for your use case:

# Enable mouse control (clickable windows, panes, resizable panes)
set -g mouse-select-window on
set -g mouse-select-pane on
set -g mouse-resize-pane on

Update for tmux 2.1:
As Jon Lillie pointed out in the comments, mouse mode has been rewritten in tmux 2.1. Once you are on tmux 2.1 (or later) you can activate the new mouse mode with a single command:

# Enable mouse mode (tmux 2.1 and above)
set -g mouse on

The new mode is a combination of all the old mouse options and fixes the text selection issues as well.

Stop renaming windows automatically

I like to give my tmux windows custom names using the , key. This helps me naming my windows according to the context they’re focusing on. By default tmux will update the window title automatically depending on the last executed command within that window. In order to prevent tmux from overriding my wisely chosen window names I want to suppress this behavior:

# don't rename windows automatically
set-option -g allow-rename off

Changing the look of tmux

Changing the colors and design of tmux is a little more complex than what I’ve presented so far. You’ll want tmux to give a consistent look which is why you most likely have to change the looks of quite a lot of elements tmux displays. This is why changes to the design often result in plenty of lines in your config. I can only recommend to put these into their own identifiable section within your tmux.conf to be able to change this block of config without accidentaly ripping out some of your precious custom key bindings. I’m using comments, starting with a # character to make it visible where the design changes start.

Credit where credit is due: I did not create the following design. /u/dothebarbwa was so kind to publish it on /r/unixporn so it’s his effort and all thanks have to go out to him. Thanks!

Depending on your color scheme (I’m using base16-ocean-dark) your resulting tmux will look something like this:

######################
### DESIGN CHANGES ###
######################

# loud or quiet?
set -g visual-activity off
set -g visual-bell off
set -g visual-silence off
setw -g monitor-activity off
set -g bell-action none

#  modes
setw -g clock-mode-colour colour5
setw -g mode-style 'fg=colour1 bg=colour18 bold'

# panes
set -g pane-border-style 'fg=colour19 bg=colour0'
set -g pane-active-border-style 'bg=colour0 fg=colour9'

# statusbar
set -g status-position bottom
set -g status-justify left
set -g status-style 'bg=colour18 fg=colour137 dim'
set -g status-left ''
set -g status-right '#[fg=colour233,bg=colour19] %d/%m #[fg=colour233,bg=colour8] %H:%M:%S '
set -g status-right-length 50
set -g status-left-length 20

setw -g window-status-current-style 'fg=colour1 bg=colour19 bold'
setw -g window-status-current-format ' #I#[fg=colour249]:#[fg=colour255]#W#[fg=colour249]#F '

setw -g window-status-style 'fg=colour9 bg=colour18'
setw -g window-status-format ' #I#[fg=colour237]:#[fg=colour250]#W#[fg=colour244]#F '

setw -g window-status-bell-style 'fg=colour255 bg=colour1 bold'

# messages
set -g message-style 'fg=colour232 bg=colour16 bold'

A Word of Caution

I took care of explaining and documenting all suggested changes in this post to make it easy for you to understand what they do and to decide if this is something you want for your tmux.conf as well.

If you do your amount of research on the web you will find plenty of heavily customized tmux configurations. It’s really tempting to just copy those and call it a day. Please, for your own sake, don’t do that. Trust me, I’ve been there. I can only recommend that you start out with a plain tmux configuration and add modifications one by one. This is the only way to ensure that you are fully conscious of all the changes you have made. And this is the only way you will actually learn something about tmux along the way. That said: go ahead and look up config files others have published. Take these as source of inspiration and choose wisely what you want to take for your own config.

There is some really interesting stuff out there. I’ve seen people doing pure magic with their status bars, displaying all kinds of system information that might be interesting. To apply those changes you’ll most likely exceed the simple one-liners I’ve presented in this post. Often there are special scripts involved that need to be loaded, accompanied by multiple lines of configuration changes. I don’t want to discourage you from using these. Just be aware that this is a more advanced topic where you can certainly screw some stuff up. Make sure to backup your config accordingly.

Further resources

As I’ve already told you, there are plenty of resources out there where you can find people presenting their tmux.confs in a similar fashion to what I’ve done here. Feel free to browse and search for inspiration. Personally I love reading other people’s blog posts about their tmux configs.

GitHub is also a great source. Simply search for “tmux.conf” or repos called “dotfiles” to find a vast amount of configurations that are out there.

If you’re especially looking for theming options, I can also recommend having a look at /r/unixporn (SFW, in spite of its title). It’s a great place where people showcase their fine-tuned and heavily themed unix environments. Some stuff is really nice, some other stuff is only pretty but mostly dysfunctional. From time to time you find people sharing their tmux.conf as well, you can also deliberately search for the term “tmux.conf” to find what you’re looking for.

You can also find my complete tmux.conf (along with other configuration files I’m using on my systems) on my personal dotfiles repo on GitHub.

Footnotes

although you can still invoke “go to beginning of line” by typing C-a C-a ↩

A Quick and Easy Guide to tmux

Sun, 16 Aug 2015 00:00:00 +0000

I love working with the command line. I think there’s hardly any more productive and versatile tool for a software developer than the terminal. The additional hacker/wizard/neckbeard kind of feeling you get when using a terminal comes for free, what’s not to love?

Over the years I’ve tried to streamline and customize my command line experience to be more convenient, more fun to use or just to look rad. One of the most important tools to drive my daily command line experience is tmux. Check this out:

This screenshot shows nothing less than the best thing since sliced bread. It’s tmux, a so-called terminal multiplexer. Simply speaking, tmux acts as a window manager within your terminal¹ and allows you to create multiple windows and panes within a single terminal window.

This post will give you the same quick introduction to tmux and its possibilities, followed by the a 10 minute hands-on guide to set up and get to know tmux yourself. If you’ve got 10 minutes to spare and want to earn street cred with your nerd friends: read on and become proficient with tmux!

What’s tmux?

tmux’s authors describe it as a terminal multiplexer. Behind this fancy term hides a simple concept: Within one terminal window you can open multiple windows and split-views (called “panes” in tmux lingo). Each pane will contain its own, independently running shell instance (bash, zsh, whatever you’re using). This allows you to have multiple terminal commands and applications running side by side without the need to open multiple terminal emulator windows.

On top of that tmux keeps these windows and panes in a session. You can exit a session at any point. This is called “detaching”. tmux will keep this session alive until you kill the tmux server (e.g. when you reboot)². This is incredibly useful because at any later point in time you can pick that session up exactly from where you left it by simply “attaching” to that session.

If you’ve ever worked with remote servers or a Raspberry Pi over ssh you can guess where this will be useful: When you lose your ssh connection the tmux session will simply be detached but will keep running on the server in the background including all the processes that run within your session. To continue your session simply ssh to the server again and attach to the running session.

tmux is helpful when working on a remote machine but it shines just as much when you’re working locally. Not only for its window management features but also for the session handling. Personally I find myself detaching from sessions when I’m switching context. I’ll just start a new session for my new task and attach to the old session whenever I want to continue with my old task.

You see that tmux basically offers two big features:

Window management in your terminal
and session management

If you are familiar with GNU Screen this might all sound familiar. Think of tmux as an easier-to-use and a little more powerful alternative to Screen (obviously I’m being opinionated here).

Enough with the concepts. Let’s get our hands dirty!

Getting Started

This hands-on guide will get you up and running with tmux pretty quickly. It will only cover the basic features which should be more than enough to get started and be productive with tmux. Simply open your terminal and follow the instructions.

Installation

Fortunately installing tmux is pretty straightforward on most operating systems: a simple sudo apt-get install tmux (Ubuntu, WSL and derivatives) or brew install tmux (Mac) should be sufficient.

Starting Your First Session

For your first session simply start tmux with a fresh session:

tmux

This will create a new tmux session with a nice all-green status bar at the bottom:

The status bar is an important part of tmux. Apart from the currently opened windows (on the left) it also shows some system information like date and time (on the right). The status bar can also be customized and I’ve seen some really fancy stuff around (upcoming calendar events, battery status, to name a few) but this is something we’ll leave for later.

Splitting Panes

Now that we’ve created our first session we can get a feeling for panes. When you create a new session, tmux will by default start with one window and a single panel inside. We want a nice split-screen, so let’s split this bad boy.

All commands in tmux are triggered by a prefix key followed by a command key (all you emacs weirdos out there will feel right at home). By default, tmux uses C-b as prefix key. This notation might read a little weird if you’re not used to it. In “emacs” notation C- means “press and hold the Ctrl key”³. Thus C-b simply means press the Ctrl and b keys at the same time.

The shortcut to split panes into a left and a right pane is C-b %. This means: to split your single pane into a left and a right pane you press Ctrl and b at the same time, release both, and then type the % key. Voilà! You’ve just invoked your first tmux command and split your pane in two.

Where there’s a split into left and right, there’s also a split into top and bottom pane. To split a pane into top and bottom panes use the C-b " shortcut.

Navigating Panes

Right now we’re trapped in the newly created pane. But we really really want to go back to the left one. Easy peasy: Switching to a different pane uses the C-b <arrow key> shortcut, where <arrow key> is the arrow key pointing to the pane you want to switch to. In our case we want to switch to the panel on the left so it’s C-b left for us. Just once more, so that we fully understand this: This means you press Ctrl and b (your prefix) followed by the left arrow key to get to the pane on the left.

You can now go ahead and split each of your new panels even further. Feel free to experiment and split your panes like a maniac to get a feeling for it.

Closing Panes

Closing a pane is as simple as closing a regular terminal session. Either type exit or hit Ctrl-d and it’s gone.

Creating Windows

Windows in tmux can be compared to creating new virtual desktops; if you’ve ever worked with one of the major Linux desktop environments (KDE, Gnome) or a Mac you’ll hopefully find this analogy helpful.

Creating new windows is as easy as typing C-b c (one last time: that’s Ctrl and b at once, then c). The new window will then be presented to you in tmux’s status bar.

You can now divide the pane in your new window as you like. Or don’t. That’s up to you.

To switch to the previous window (according to the order in your status bar) use C-b p, to switch to the next window use C-b n. If you’ve created many windows you might find it useful to go to a window directly by typing its number (the status bar will tell you which window has which number), just use C-b <number> where <number> is the number in front of the window’s name in your status bar.

Session Handling

If you’re done with your session you can either get rid of it by simply exiting all the panes inside or you can keep the session in the background for later reuse.

To detach your current session use C-b d. You can also use C-b D to let tmux give you a choice which of your sessions you want to detach. Detaching from a session will leave everything you’re doing in that session running in the background. You can come back to this session at a later point in time.

To re-attach to a session and continue where you left you need to figure out which session you want to attach to first. List the currently running sessions by using

tmux ls

This will give you a list of all running sessions, which in our example should be something like

0: 2 windows (created Sat Aug 15 17:55:34 2015) [199x44] (detached)

To connect to that session you start tmux again but this time tell it which session to attach to:

tmux attach -t 0

Note that the -t 0 is the parameter that tells tmux which session to attach to. “0” is the first part of your tmux ls output.

If you prefer to give your sessions a more meaningful name (instead of a numerical one starting with 0) you can create your next session using

tmux new -s database

This will create a new session with the name “database”.

You could also rename your existing session:

tmux rename-session -t 0 database

The next time you attach to that session you simply use tmux attach -t database. If you’re using multiple sessions at once this can become an essential feature.

And that’s it! Congratulations, you’ve just completed your first tmux session and got your hands dirty with its window and session management. Yes, there’s more stuff tmux can do. But what you’ve just learned should be everything to start using tmux in the future.

Why tmux?

A response that I get quite often is: “Great, I get it. But why should I use tmux and its weird key combinations instead of just using iTerm2?”

And you’re right, when it’s only basic window management, iTerm for Mac supports tabs and panes as well. For Linux there’s Terminator. So why would anyone feel the urge to learn some archaic technology in this day and age?

Well, obviously there’s the bragging rights. But if that doesn’t convince you, there are a couple of actual reasons why I favor tmux over iTerm et al.:

session handling: detaching from and attaching to sessions helps me with context switching and remote working
platform independence: I can use tmux on my Macbook, my Linux notebook, servers, Raspberry Pis, you name it.
customizable: there are many ways I can customize the look and behavior of my tmux environment. And I can sync this across different platforms using a simple dotfile

Moving on

If you’re curious to learn what else tmux can do that’s a great thing. And luckily most of the stuff is quite simple to discover. Just type C-b ? to see a list of all available commands and start experimenting.

Some of the commands that I’m using myself quite often are:

C-b z: make a pane go full screen. Hit C-b z again to shrink it back to its previous size
C-b C-<arrow key>: Resize pane in direction of <arrow key>⁴
C-b ,: Rename the current window

On top of that there are plenty of resources out there that help you getting further with tmux. People like me are blogging about their tmux experience and share what they’ve discovered. You can find people sharing their tmux configurations in their dotfiles repos on Github. There’s even a book by Brian Hogan dedicated to tmux.

For now it’s best to discover some stuff on your own. Experiment, fool around and maybe try to use tmux for your daily work. It takes a while to get used to and you’ll probably feel slow when you start out. I encourage you to keep using it. Get a feeling for its functionality and in no time you’ll find out that your work with the terminal will be pure bliss and refreshingly fast.

If you’re interested in customizing your tmux experience I recommend that you read my Guide to Customizing your tmux.conf.

Footnotes

If you’re coming from a Linux background you’re probably familiar with the concept of window managers like Openbox, i3 or awesome ↩
tmux is based on a client-server architecture. While this is rarely relevant, it’s helpful to understand how stuff works. The tmux server keeps track of all the running sessions. You will only ever work with the tmux client and create new sessions or connect to existing ones. ↩
there could also be M- which is the same only for the Meta key (i.e. Alt on most keyboards). ↩
This is an interesting one. Yes, you need Ctrl in your prefix and also your command key. I find it easiest to only release the b key after the prefix key and keep Ctrl pressed all the time while I hit the arrow key repeatedly. Experiment a little bit to get a feeling for it. ↩

How the metaphor of 'moving apartments' helps with your next Retrospective

Sat, 20 Jun 2015 00:00:00 +0000

Moving from one place to another is something unique. The pleasant side of it certainly is the refreshing change, the novelty of the new home. On top of that you get the chance to get rid of old stuff; baggage that’s been sitting around in your old home that you no longer need but never decided to throw out.

Then again moving is also tedious work. Moving means days and weeks full of disassembling and reassembling furniture, packing your stuff in boxes, getting everything from A to B. Along with that there’s this constant stream of stuff that needs to get done, stuff that you must not forget. Call the landlord, get a new internet connection for the new place, pay that preposterous amount of money for the real estate agent… All this has to happen at a certain point of time on top of all the work that you need to do anyway.

I recently moved to a new place so I experienced first hand what moving was all about. I had volunteered to facilitate the next Retro for our team. Since I was literally busy day and night I had struggled to find what I wanted to do for that Retrospective. When I arrived at the office at the morning of the Retro I had a short chat with our PO where she asked me how I was doing. I told her about how I was moving at the moment and complained about the huge amount of stuff that’s still left to do when it struck me: This is the perfect metaphor for today’s Retro!

Why ‘moving apartments’ is a perfect metaphor for your Retrospective

Moving apartments is a great analogy to set the scene in your Retro. You can be pretty sure that everyone in your team has moved at least once in their life (going to university, moving for a job). In turn everyone is familiar with the process, the work and the feelings that are involved.

The process of moving has certain characteristics that have shown to be great questions to ask during a retro. I have found the following four topics to be fitting questions for the current state of the project. Setting the scene by introducing the metaphor of moving helped the team to get into the perfect mindset for that.

Buy something new

As you move to a new place you figure out that you suddenly need new stuff. More space at your new home or a different room layout might call for some new piece of furniture that you have to acquire.

Buying something new usually feels good. You get something pretty or something useful that will make your new place stand out. Acquiring something for your project can have the same effect. It does not mean that you have to literally buy something (although it can if you find out that there’s something missing). Adopting a new process or trying out something new could also be things that fall under the category of “get something new”

Throw away the old stuff

For many, moving to a new place offers a unique opportunity to throw lots of stuff away that you’ve always wanted to get rid of. Stuff that’s just been sitting around because you never got to throw it away. You got used to it but thinking about it there was no real use for it.

Your project will be full of something similar. Processes that serve no real purpose, technical debt in your code, everything that can generally be called waste if you want to talk in Lean terms. Everything that you are better off without but never bothered to get rid of can be identified with the help of this analogy.

Fix what’s broken

While you’re busy with disassembling and re-assembling all your furniture you often discover that there’s a lot of stuff that needs to be fixed. There are drill holes in your wall that should be sealed, walls that need to be painted, broken hinges that should be replaced.

With this analogy in mind you can identify the broken stuff in your project and discuss ways to fix it.

Don’t forget important things

When I was moving I always had a huge list of reminders that would pop up during the day to remind me of stuff I must not forget. Paying bills, calling people or quitting old contracts are just some of these. All these are things that need to be done by a certain point in time. They usually are little tasks but each of them is crucial and has to be done at a certain point.

Every project has similar things that don’t need to be done right now but need to be done before or after a certain point in time. This analogy helps you identifying the stuff that you absolutely must remember. You can then go on and discuss the right point in time where this item needs to be done.

Our experience

We had a really great session with our team using the “moving” metaphor. The team collected lots and lots of ideas that we could discuss about. I got great feedback on how the metaphor of moving really helped the team finding all these ideas. The four given questions offer analogies that everyone can relate to and they translate to project work really well.

Resources

As in my last Retrospective, I prepared some print-outs to better visualize the content of the Retro. I could also try to draw these but my drawing skills are pretty limited so I decided to go with printing them. Feel free to download the print-out if you want to try it for yourself. I’d love to hear from you if you’re trying this out!

Download

The Tweetrospective - refresh your next Agile Retrospective

Sun, 10 May 2015 00:00:00 +0000

Retrospectives are an essential tool in Agile software development. Whatever methodology you use, as long as you develop software in iterations you will have retrospectives after each of those (and if you don’t: shame on you, my friend).

Retrospectives help the team to take a step back from the day-to-day business and to reflect on what’s happened in the past iteration. The team gets to discuss about problems and risks, annoyances and moments of frustration, but also about success stories and progress. The intention of this is to find a way to eliminate the bad and encourage the good things in the future.

Every retrospective will be facilitated by one person (the facilitator) who will prepare and setup the retro and guide the team. There are different approaches on how to facilitate a good retro and there are more books than you will want to read about that specific topic so I won’t go into detail here ¹.

In our team at ThoughtWorks we take turns on who will facilitate the next retrospectives. This week I volunteered to facilitate the retro for our team and so it was my turn to prepare the session. I have facilitated a couple of retrospectives since I’ve joined ThoughtWorks. My previous approaches to gather data for the team to discuss about usually revolved around the classic questions of “what was good?”, “what was bad?”, and “what puzzles me?” or some slight variation of these. This is a very easy and proven concept. The team is familiar with it and it gets the job done. On the other hand the terms “proven” and “familiar” indicate that it tends to be pretty boring for the team. And boredom is nothing you’d want if you want to push the team to get creative and open before starting a discussion.

In order to make the next retro more interesting again and to get the creativity flowing, I wanted to try something new instead of following the well-known and easy path. But where to start? I am far from being an experienced facilitator. I’ve read The Retrospective Handbook by Pat Kua (which I can totally recommend, it’s a quick and enjoyable read and really helps you keeping everything in mind for preparing retrospectives) and facilitated a handful of retros that got the job done but that’s about it. There’s no vast pool of experience that I could rely on.

Luckily enough there’s a nice place for inspiration online that a colleague showed me a couple of weeks ago: the Retr-o-mat has a very nice collection of ideas and approaches for the individual phases for a retrospective. And on top of it it will automatically generate a fully fledged plan for your next retro by randomly picking one of the concepts for five typical steps in a retro’s agenda.

Introducing five new concepts for our team in the upcoming retro was more than I wanted to do. For once we only have limited time and I want to get the most out of it instead of spending most of it explaining new games and approaches to the team. Secondly we are not that strict when it comes to the agenda of a retro. So instead of picking a completely generated plan I started browsing through the individual suggestions for the “Gather Data” and “Generate Insights” sections.

Eventually I stumbled across the “#tweetmysprint” idea by Thomas Guest and found it to be really interesting. It suggests using Twitter’s Tweet format to let the team write their thoughts about the past iteration and ordering it in a timeline. I decided to let my retro revolve around exactly this concept. As it turns out it was a great idea. Our team had lots of fun and we got some really interesting results out of it.

The concept in a nutshell

You start off describing the concept to the team. The team gets to write a couple of Tweets about the last iteration on sticky notes. #hashtags, @mentions and emojis are highly encouraged. Next you organize all these Tweets into a timeline and read it out loud. Every teammember gets to vote on the Tweets he or she wants to discuss about using Retweets and Favourites. You organize the highest voted Tweets into Trending Topics and give the team time to discuss about these in more detail.

It turns out that the Twitter universe offers everything you need for a retro. Restricting the opinions on the sticky notes to Twitter’s 140 characters limit is a good lesson on brevity and conciseness. It is challenging to stick to this format and therefore will result in some really creative answers. Hashtags, Mentions and Emojis offer some unique opportunities. Mentioning someone in a Tweet can be used to appreciate a specific person or to celebrate success. Hashtags are a great concept to put additional information, emotion or funny references into the short Tweet format.

Preparation

As usual make sure to have a room where the whole team fits and can talk and discuss in an undisturbed way. Get enough sticky notes and pens for everyone. Make sure to pick the right format for the sticky notes. I’ve found a wide rectangular shape to be fitting (obviously resembling the format of one single Tweet).

Print enough of the Tweetrospective Sheets at the end of this post for your team and cut out the Retweet and Favourite icons. Prepare a bunch of these icons for each team member and hand them out together with the sticky notes and pens.

Facilitating the Retro

Facilitating your Tweetrospective won’t be any different from other retros. Try your best to set a scene where everyone feels secure and comfortable. Writing Tweets allows to get creative and share short thoughts in an entertaining way with others. This could be a good opportunity to break the ice in a team.

Presenting the Concept

There might be people in your team who don’t know the concept of Twitter. Even if you think everyone is aware, it’s a good idea to recap what Twitter is and how it works to set the scene for all participants. Make sure to explain the concept of Twitter and to describe the whole vocabulary around it. Tell the team what type of content gets published on Twitter. Mention the 140 characters limit of Tweets, Hashtags, mentioning other users and Emojis.

Give the team around 10 minutes (feel free to vary) to write as many Tweets as you consider suitable (personally, I gave no limit)

In my Tweetrospective I prepared one example Tweet on a sticky note that included hashtags, mentions and emojis to show off what was possible. The content of this example Tweet was just a reference to one of our team’s inside jokes which laid out the foundation for a lighthearted atmosphere and got the idea across easily.

Writing Tweets

It might be helpful to give your team a couple of examples of what they can write about. Possible Tweets are success stories of the last iteration, stories of failures, lessons learned, rants, appreciations of others or shameless plugs of something a teammate has been up to.

Usually, Tweets always contain the author’s name. To stick to the concept of Twitter as close as possible, your Tweetrospective’s Tweets could also contain the name of the individual authors. However, this might influence the safety levels of your teammates. I decided to encourage the team to write their name on top of each Tweet if they think it’s suitable for the content. However, if they prefer to stay anonymous they could simply write “anonymous” instead.

Organising the Timeline

After the time is up, collect the individual Tweets and arrange them in a timeline. Read out the timeline to the team. This is probably the funniest part since reading out hashtags and emojis is something unusual and offers a great potential where people can get creative.

Retweets & Favourites

You’ll want to find out which topics are most important for the team to discuss. Instead of relying on dot-votes or something similar, you can - once again - use Twitter’s mechanisms for that. Let everyone put Retweets and Favourites next to the Tweets they are most interested in for the upcoming discussion. Everyone can use the cut-out icons you have prepared previously. In our Tweetrospective I made no difference between the semantics of Retweets and Favourites. However, you could also consider applying different semantics to Retweets and Favourites respectively. A possible way would be to say that Retweets are considered as votes for the upcoming discussion while Favourites indicate that you want to put emphasis on a Tweet’s content (e.g. underline the appreciation of a teammate).

After everyone has gone wild with their Retweets and Favourites you can identify the most voted-on Tweets and re-arrange them to the Trending Topics. Go through these trending topics from most to fewest-voted and let the team discuss the individual contents.

From here on it’s all discussion for the team. Just make sure to moderate and guide the discussion as you would usually do and extract action items out of it.

Resources

A Tweetrospective can be done easily and without much preparation. Just make sure you have enough sticky notes, pens and a whiteboard for everyone. You can simply let everyone draw Retweet and Favourite icons on the whiteboard right next to the sticky note Tweets.

If you want to step up your Tweetrospective game and save some time during the voting phase (drawing Retweet and Favourite icons seems to take quite some time) you can also print out the following Tweetrospective Sheets and cut out the icons for your teammembers before the retro.

Download as PDF | Download as PNG | Download as SVG

Closing thoughts

The Tweetrospective we had was a really fun and insightful session for our team. I plan to repeat it again some time in the future. Perhaps I could get the idea across and inspire someone to try it out themselves. If you give it a try feel free to share your experience. If you find something to improve or criticise just leave a comment in the comments section.

Footnotes

If you’re interested in this topic you can find a comprehensive guide in Derby’s and Larsen’s Agile Retrospectives: Making Good Teams Great ↩

Import your DKB account into Homebank

Tue, 07 Apr 2015 00:00:00 +0000

Recently I started using Homebank, a great and free personal finance tool, to keep track of my budget and spending habits. It takes a little effort to set up but is really intuitive and straightforward from there.

I started tracking all my spendings and transactions in Homebank a couple of months ago which helped me getting started with Homebank. Tracking all transactions manually, however, felt really cumbersome; especially when tracking a fair amount of transactions if you haven’t updated Homebank in a while.

Sensing that there must be a better way to track your spendings and earnings in Homebank I decided to investigate a little bit. And as it turns out, there is a better way. My findings might be helpful for others so I thought I might share.

Step 1: Export your account data as CSV

To get your transactions from your DKB account into Homebank you need to export your account data as a CSV file. This can easily be done using the DKB’s online banking interface. Just go to “Kontoumsätze” (for a DKB Cash account) or “Kreditkartenumsätze” (for a Visa account), enter the desired time frame for your report and then hit the little arrow icon in the top right corner (just beneath the printer icon). This will download a CSV file that we can convert and then import into Homebank.

Step 2: Download the dkb2homebank converter

Unfortunately the downloaded files are not compatible with Homebank’s CSV import interface. If you try to import the DKB generated CSV files right away, Homebank will simply refuse to do so as it does not recognize the file as a proper transactions file.

Luckily the Homebank developer has written a specification of the CSV import interface. It seems fairly complete and allowed me to write a little converter script that converts the DKB’s CSV file into a Homebank ready CSV file.

Download the latest version (right click -> Save Link as…) of the converter script and save it on your computer. It’s written in Python and requires you to have Python >= 2.7.4 installed. I’ve tested it with Homebank 5.0.0 on a Linux machine but expect it to work on other operating systems with a similar Homebank version as well.

Step 3: Convert the CSV file

Now that you’ve downloaded the dkb2homebank script, you can use it to convert the DKB’s CSV file to a Homebank readable one. To run the script, call it as described in the readme file on github. You need to provide the type of the CSV file (currently DKB cash account exports and Visa account exports are supported) and the filename of the respective CSV file:

./dkb2homebank.py --cash yourCashFile.csv

or for Visa account exports:

./dkb2homebank.py --visa yourVisaFile.csv

Each of these commands will create a output file called either cashHomebank.csv for DKB Cash accounts or visaHomebank.csv for Visa accounts.

Step 4: Import the converted CSV file into Homebank

You can import the newly created CSV files into Homebank using its import dialog (File -> Import -> CSV file…). This dialog will guide you through the import process. Make sure that you select the correct account to which the imported data should be added.

After that all your transactions are imported into your Homebank file. You can now start tagging them as you like to help you get an overview of all your spendings and earnings.

What else?

If you discover any problems, just contact me or file a bug report on the dkb2homebank GitHub repo. You can also try to fix or improve stuff yourself and send me a pull request.

Was this helpful? Feel free to drop me a line!

Add Color to Chrome's Header Bar on Android Lollipop

Sat, 28 Feb 2015 00:00:00 +0000

If you’re a Chrome user on Android Lollipop you might already have noticed. As someone who just recently updated to Android Lollipop I discovered this this week: Chrome on Lollipop (from Chrome 39 onwards) allows your website to change the color of Chrome’s title bar.

The first time I noticed this was when I was browsing the XDA Developers Forums:

A couple of days later I saw Ars Technica using it for their dark theme (which really adds to the whole reading experience on mobile in my opinion):

I wanted to add this effect to a little website I wrote this week, too. After short research I figured out that this could easily be achieved by using the theme-color meta tag on your website. Just define the meta tag in your header section, define the desired color and Chrome will take care to colorize the header. The tag will take any hexadecimal or named color as its value:

<meta name="theme-color" content="#663399">

<meta name="theme-color" content="RebeccaPurple">

If you use this tag on your website, Android also uses the color in the app overview:

This is a very simple way to make your website stand out on Android devices and even increase the whole User Experience of your website. So this little trick might come in handy for you in the future.

Working at ThoughtWorks, a three month retrospective

Sat, 22 Nov 2014 00:00:00 +0000

More than three months ago I took the first step of a fascinating journey: It was my first day at ThoughtWorks in Hamburg. The prospect of a new job in a new city had made me curious and nervous for the past couple of weeks. As it turned out, the anxiety should only last until my very first hours at work. After that everything immediately felt like home.

My first day

My first day at ThoughtWorks started after a night of fairly restless sleep. I woke up way too early that Monday morning and everything felt unfamiliar. A different apartment to wake up in, an unknown way to work, being a complete stranger in a big city. “This will take ages to get used to”, was the thought that constantly accompanied me.

Breakfast and Handshakes

I took public transport to the office that morning which worked way better than I expected, considering I am a complete public transport dilettante. So there I was, outside of the new office, way ahead of my time and hesitant to enter. I grabbed a coffee from a shop at the corner and decided to wait outside since I did not want to be the first on the scene.

When I finally entered the office I was greeted by a sweet breakfast with Franzbrötchen, Croissants and more people than I could ever remember in such a short time. Everyone was keen to introduce themselves and curious to hear who I was and what I had to tell.

Polyglot projects and the best tools for the job

Right during our breakfast I was told which project I’d be assigned to. I only got to know the project’s name so I was eager to get to know more about what would keep me occupied for the next months. After a short time of fiddling around with my new notebook I had a session in which I was introduced to the project, the business model and the technologies we chose to work with. Hearing about the technology stack and realizing how polyglot this project would be put a big grin on my face. It was obvious that these people really love technology. Leveraging the latest and greatest languages, frameworks and tools available is the way to go for the company and I was more than happy to be part of that. It is a great feeling to know that I could use many of the technologies I would fiddle around with in my spare time anyways.

I was used to work with self-written Java frameworks that were thought to be a one-size-fits-all solution to each and every project presented to us. There’s nothing wrong with using Java, not at all. However, I never liked the approach of shoehorning every single requirement into something that could be solved with the few given tools we had at hand instead of using the best tools for the job. Seeing that my team would share that opinion and was eager to try something new was obviously something I was absolutely happy with. Working on a project and getting the chance to learn new languages and frameworks at the same time was obviously something I was more than pleased to do.

Trains on strike, a pub & an expensive taxi

My first day ended quite spectacular. The train drivers were on strike so I had no way to get home to my apartment after work. A colleague suggested to join him for a beer at the pub which sounded like a solid plan to me. After some more than the announced “one beer” I ended up being stranded somewhere in Hamburg (thanks to my awesome orientation skills) with a dead phone and this random guy from Leeds I simply decided to call “Dave” even though that was certainly not his real name. Dave and I managed to snatch a Taxi and get to the Hauptbahnhof. I took the Taxi to get further home to my apartment and managed to end my oddysey. After all it was a great – albeit expensive, thanks to the Taxi – night and a great ending of my first day. The spontaneous pub night helped breaking the ice. On top of that I had a decent story to share on the next day.

ThoughtWorks, what’s it like?

It’s only been a little more than three months and I am far away from having seen it all. But I think I have seen enough for a first roundup. So here are a couple of things that I consider to be the most remarkable for working with ThoughtWorks:

TDD, all the way

One thing I really got to appreciate is the clear focus on Test-driven development (TDD). Of course I was familiar with writing automated tests of all kinds before. I read Kent Beck’s TDD by Example and was aware of the benefits you get from test automation. I thought I knew what TDD meant until I got to work with the people at TW.

Seeing the focus on TDD and how it helped shaping the software we created made clear that my previous understanding of TDD could at best be described with a ‘test-first’ approach. Sure, it worked and I produced results. I delivered software at my previous job as well, after all. However, it was far from what I encountered at TW and it didn’t take long to really convince me of the benefits of having a pretty strict focus on Test-driven development.

Pair Programming

The one thing that was completely new to me was the practice of Pair Programming. The entire development at TW is done in pairs. I have to admit that I had to get used to that in the first days. My fellow Devs made it very easy to get used to it, though, and turned out to be very supportive.

Pair Programming was the one thing I couldn’t decide on whether it made sense for me or not. I knew it would be practised at TW in advance so it came as no surprise. I just couldn’t imagine that having two people working on the same task all the time would really be worth the investment. It turns out that all my skepticism was unjustified. Working with a Pair turned out to be great, especially for new team members:

You get up and running very fast. Your pair can introduce you to the tools and techniques you might not know yet.
The bad conscience sits right next to you. No more “that’s good enough” solutions, no more “I will fix that later”. Everyone gets tempted to deliver a quick and dirty hack instead of cleaning up. We all know better but tend to ignore that. Good luck trying to ignore your pair!
There’s always something interesting to learn. You always take away that one fancy shortcut you can’t believe you didn’t know or that new plugin for your favorite editor. You will be surprised how much of those little tricks you can gather in a short time.
“Hitting the wall”: Your pair can help you. Everyone gets stuck from time to time. This is what we get from working with not completely understood technology and domains. Working with a pair will help you with that.
Spread the knowledge. You reduce the Bus Factor if at least two people know about each topic and therefore reduce the risk for the entire project.

Keep it simple, stupid

The KISS principle is applied everywhere and I love it. Keep it as simple as possible, avoid over-engineering, don’t try to make things unnecessarily complex. This mentality is applied to technological and business decisions and really helps us moving fast and getting stuff done.

Contribute to the community

One thing you can clearly feel while being around at ThoughtWorks is the strong community focus. Internally as well as externally ThoughtWorkers try to contribute as much to their communities as they can. There are talks on a widespread range of topics every friday over lunchtime, free for every ThoughtWorker to join. Externally, people organize and participate in meetups, hackathons, even conferences for the local communities. Its something that everyone in the company values. Giving and contributing instead of just taking is something people strive for. And rightly so. You get to learn so much more as soon as you start contributing instead of just consuming.

Moving forward

It’s been a great three months so far. I’ve met amazingly knowledgeable, genuinely friendly and helpful people and I’m looking forward to working with these people in the future. I’m excited to be able to keep on learning new stuff every day and to contribute to the community. As it turns out it’s been a great decision to go to Hamburg!

Goodbye Gütersloh, Hello Hamburg!

Tue, 19 Aug 2014 00:00:00 +0000

Today marks my last day in Gütersloh. My bags are packed, my stuff is sitting neatly packed in boxes in my apartment, waiting to be hauled into a big van. I’m sitting in my office near the Autobahn in Gütersloh, on the same floor I’ve been working for the past five years. I’m sitting here, cleaning up my stuff, waiting for my colleagues to show up for the cake my girlfriend baked for my farewell. Sitting here on my last day and waiting in my office led me to think about the whole journey that brought me here in the first place.

My journey as a software developer started mid-2008 after finishing school. I’ve always had a hand for ‘computer stuff’ and healthy interest in exploring the possibilities I had using computers, operating systems and programming languages.

My parents got their first computer when I was about five or six years old. I vividly remember how my Dad showed us kids this magical device with which you could do all kinds awesome stuff (his demonstration of Prince of Persia completely blew my mind). The following years my brother and I tinkered around with every single computer our family got. Our main goal always was to get our computer games running which often required a massive amount of messing with the operating system. Our early efforts mostly didn’t work out as expected and we ended up with a broken system and annoyed parents. But it was worth it. Both of us had fun tinkering around and the incentive of getting a computer game started was enough for us to spend hours finding out a way run it. I loved the spirit of tinkering around, even though neither of us truly understood what we were doing (we were about 8 or 9 at that time after all).

In my teenager years (I must have been around 13) I got my first personal computer. I remember spending a great amount of time in a couple of IRC channels, having a great time with several other guys I met through some forums on the www. These were the days that got me hooked on programming. Inspired by my IRC mates I wanted to write my own website without having a clue how to do so. It was the time of hosting services like Beepworld and Geocities that were notorious for hosting furiously blinking, seizure-provoking websites assembled with WYSIWYG editors. But that was not what I wanted. I wanted to create a website professionally. I wanted to learn how to do this by hand. WYSIWYG editors were out of question. I figured out I had to learn HTML first. So I studied everything, I could find on SELFHTML, a very popular German resource about HTML at that time (and apparently it’s still going strong). My first attempts using HTML and CSS were obviously crude and not really successful, but after a couple of weeks of intensive learning and writing, I launched my first website: stultus.org. Without relevant content and no concept beyond “that’s my website!” I quickly came to the conclusion, that I needed to do something more with my website. One of my IRC mates told me about PHP and that this was the way to go, if I wanted to create “real” and “dynamic” websites. I bought my first book on PHP at age 14 and with extensive coaching of the same guy in IRC I finally had my first website running using PHP and a crudely written CMS with very basic features and a MySQL database as backend. To this day I own this domain and I feel quite nostalgic about it. There’s nothing left on there, however.

I kept my curiosity and learned more and more about programming languages, especially Java and object oriented programming as well as computer graphics and web design in the following years. I voluntarily took an extra computer science course in school where we would learn object oriented programming and the Java language from scratch. During that time I did several web design tasks and consistently hacked away on my personal homepage (stultus.org, unfortunately I did never release anything of it though).

After finishing school in 2008 I stumbled upon a job ad from Bertelsmann in Gütersloh. They were looking for people to work at Bertelsmann, do a training as IT specialist (Fachinformatiker) and make a Bachelor’s degree in Business Information Systems (Wirtschaftsinformatik which is a quite popular German major combining Computer Science, Information Systems and Economics, to name a few). The opportunity to study at university (i.e. university of applied sciences) and work on a rotating basis seemed a great idea to me, so I applied. After an assessment as you would expect from a big enterprise such as Bertelsmann I got a letter offering me a job for the Bachelor of Science program. I was overjoyed and agreed on the offer. This was an opportunity to get a solid professional foundation for all my amateurish hacking efforts the years before. I would be taught a broad spectrum of knowledge at university and have the opportunity to work on real projects with real people and real customers. How cool was that?

And so it happened. I learned tons of stuff about programming languages, databases, networks, operating systems but also project management, economics, marketing, logistics, statistics and much much more. During my time at work I would work as a software developer using the Java platform. In my department we developed Customer Relationship Management software, broadly speaking. Our customers were well-known companies from different backgrounds and every project was a great challenge for itself. In my first years as a developer I would rather work on internal Java frameworks, providing bug fixes and implementing new minor features. But I soon made progress and was glad that I could help my colleagues working on the real projects providing direct business value for our customers. It was a nice feeling. And on top of that: I would get a fair amount of salary at the end of each month, regardless of whether I was studying or working.

After finishing my Bachelor’s degree, I got a new employment contract with the department I worked at the whole time. I was no longer a corporate student but finally a regular, internal employed software developer. My tasks would remain roughly the same but the salary was no longer that of a corporate student. For my accomplishments in my Bachelor’s degree, Bertelsmann decided to give me a scholarship to finance a subsequent Master’s degree of my choice. Given this opportunity I decided not to waste my time and started looking for a Master’s degree that I could do simultaneously to my work. I found out that the University of Münster was offering a major that fit to my expectations, called Information Management (which is close to their regular Information Systems major). I enrolled and was very busy working on my Master’s degree while coping with the increasingly complex tasks and the extra responsibility at work. In the end everything worked out and I got my degree.

The last 10 months have been very exciting, to say the least. I finished my Master’s degree, wrote my Master’s thesis about Continuous Delivery and how we could use it in our department and also implemented a working prototype for a deployment pipeline. Focusing on the topic of Continuous Delivery intensively for half a year was fascinating. I’ve read Jez Humble’s and Dave Farley’s Continuous Delivery and was hooked after a few pages. I read it from cover to cover in a couple of days. It got me excited to work on a concept for using Continuous Delivery at work so that we could deliver our software more frequently and more securely. The results of my Master’s thesis got some of my colleagues interested in this topic as well and you could feel a certain momentum build up in our department.

Nevertheless, I felt that there was something lacking in my current position. I had seen quite a few projects and worked with talented people. But I had the feeling that even though there was still a lot I could learn, I had no real perspective left at Bertelsmann. Our projects were basically the same, I missed real innovation, technology-wise as well as from a business perspective (besides that, there were several other factors as well but this was my major gripe). In January 2014, at the last day of my winter vacation, I discovered that ThoughtWorks, the company that basically brought up the idea of Continuous Delivery, was looking for someone with experience in Java development and Continuous Delivery for their office in Hamburg. Being quite a northerner myself and having no roots in Gütersloh, I decided to apply for this job. I had written a fair amount of Java code and spent the past six months studying the topic of Continuous Delivery intensively after all. I got lucky. Only a few hours after sending in my application I got a call from a lady of ThoughtWorks’ HR department. They told me they were interested and we chatted nicely for about 45 minutes. I managed to pass the rest of their application process and got an offer for a position in Hamburg sometime late February. I handed in my notice of termination at Bertelsmann directly afterwards.

And here I am now. Six months after I handed in my notice my cancellation period is over and my last day at Bertelsmann has come. It was a great experience, I had the chance to learn a lot, was paid a fair salary, got the chance to work with smart and talented colleagues and got to know many nice people. Nevertheless, six years into my career I felt it was time to move on. I am excited to start at ThoughtWorks next month and I’m sure that this is the right company to offer me what I’ve missed before: Learning even more, working on exciting and diverse projects and experiencing a great work culture.

Let’s hope for the best!

Ham Vocke

Book Review: “Tidy First?”

What’s “Tidy First?” all about?

My Takeaway

Path to Production Mapping

“Path to Production Mapping” in a Nutshell

Get Clarity, Identify Pain Points & Improve

How to Create Your Path to Production Map

Invite the right people

Prepare a Canvas

Go Wild!

Analyse the Map

Follow Up

Summary

Further Reading

Footnotes

Browser Bookmarks on the Command Line

Setup

Usage

Managing Bookmarks

Demo

Create an Alias for Easier Access

Or Bind it to a Hotkey

How the Sausage is Made

Why You Might Want to Use This

Footnotes

Book Review: “Learning Test-Driven Development”

Learning Test-Driven Development in a nutshell

Who should read this book?

What’s in the book?

The Money problem

Python or Go or JavaScript? Or all of them?

Red - Green - Refactor

Unit Testing, Design and Maintainability

A Practical Developer Workflow

Should I read this book or Kent Beck’s “TDD by Example”?

Where does this book fall short?

I heard TDD is dead. Why should I bother learning TDD today?

My recommendation

How remote work changed my life

More Time

More Space

My dog, Lenny

More Exercise

Quality Time

A tight-knit community

Fewer options

A steady pace

Doppelkopf — 3 Years Later

Basic gameplay

User interface

Design

Infrastructure

A boring mature tech stack

The road ahead

Building a Jira integration for Stack Overflow for Teams

Distraction-free writing with vim

Moving On

What’s next?

Ham

Using 'make' to Make Your Code Easy to Work With

go Scripts: An Example in Bash

make and Makefiles

An Example Using make

.PHONY targets

Dependencies

Autocompletion

Caveats

Testing Ansible Provisioning Locally

Example Code Repository

Vagrant Setup

Ansible Configuration

Inventory

Playbook

Serverspec Tests

Workflow

A "Doppelkopf" Browser Game

I’ll Build My Own Doppelkopf Game

Implementing the Game

The Card Game Kata

The `Money` problem

`Python` or `Go` or `JavaScript`? Or all of them?

`go` Scripts: An Example in Bash

An Example Using `make`

lolcat – like `cat` but with rainbows