Tmux is a wonderful tool to increase my productivity by multiplexing windows and apps to a single terminal. I use it all the time when working on a project to organize my tools, and quickly switch between them. One things I do these days is create a shell script to launch, and customize, my tmux session for the specific project that I am working on. This give me quick access to a complex setup, allowing me to jump into a project and get moving quickly.

Go 1.11 introduced a new concept of Modules which brings first class support for managing dependency versions and enabling reproducible builds. Go previously had no notion of dependency versions, and it has been a long and arduous road to get where we are now. Modules do not just copy the style of other programming language’s dependency tools, rather it introduces a few slightly different concepts intended to enable programming in the large.

Testing gets easier the more you do it. I guess it’s like most things in that regard. For me my comfort level has risen as I have forced myself to practice the small steps that make up Test Driven Development. That was the next step in my TDD journey. If you recall from my previous TDD blog post I was starting from nothing. No experience dong TDD or testing. My uncomfortableness was physical, a mini anxiety attack, a moment of doubt.

This post was originally published here. You would think the world is falling apart; or rather it seems that way, and I’m only really talking about the world of software. I’ll leave politics out of this. It’s not that the world of software is falling apart; or rather our applications are. What once were gleaming monoliths, monuments to our own achievement are now being hacked and splintered into microservices. Rather this is the natural cycle that our industry seems to follow every few decades.

There is something small and tiny that I feel I am missing about Test Driven Development. I understand the basic principle of the matter; write a test that fails, then write the code to make it pass, rinse and repeat; red, green, then refactor. Knowing that basic truth of what TDD is has not translated into actually being able to use it as a practice in my day to day coding.