Some time ago, I was looking for a way to define a clear separation in a Go project between my unit tests and my integration tests. At the time, the solution I came up with involved creating a submodule and some Makefile shenanigans to separate these into two sets. I was unhappy with this approach, since it ended up being convoluted and prone to error as the code base evolved. However, today I recently learned about Go’s build tags that seemlessly allow me to separate my integration tests from my unit tests.

A while back, I was investigating a bug where my deployment job had failed, but the service had been deployed. At first I thought this was weird, afterwards I thought this was extremely concerning: had this happened before and I was just noticing now by accident? Since I did not want to have failed deployment jobs actually deploying my services, I took a closer look at this issue. The situation What happened was pretty simple.

Slices are Go’s bread and butter. However, more often than not, small mistakes happen because it isn’t exactly clear what actually is a slice. Since they are so prevalent in Go code, I decided to dive a bit deeper into their internal structure, how they are handled in different situations, and how some of the issues that arise can be avoided. But first, arrays Before diving into slices, it is important to know that Go also has the concept of arrays.

NetFlow is a protocol developed by Cisco that has had several iterations over the years. This network protocol’s main focus is to collect IP traffic information and export it for monitoring purposes. A router configured to collect NetFlow will aggregate data packets into what is known as a flow, which is basically a summary of the traffic passing through the device in a given time span. Of the multiple iterations of the NetFlow protocol that Cisco has produced, two have cemented themselves as the most commonly used protocols: NetFlow v5 and NetFlow v9.

When testing software locally, one of the main tools at a software engineer’s disposal is Docker, more particularly, the Docker Compose tool. This tool allows engineers to define and run a multi-container setup using YAML files. The vast majority of software produces a form of output known as logs, which provide information on what is happening in a running application, such as errors, possible warnings, general information, and more. The issue with inspecting Docker Compose log messages When you run a Docker Compose setup locally, you’ll usually see all container logs being printed in rapid succession in your terminal, and, depending on the amount of logs your multi-container stack produces, this might be very difficult to navigate, reason about, and correlate log messages from different containers.

This is a neat little trick I learned recently. I was in need of creating a Clickhouse container to attach to another application that would write to it. And I found myself thinking: it would be really convenient if there were a way to create a Clickhouse container that already comes with a set of tables created. Most of the solutions I found only were severely convoluted and relied on scripts to make this happen, so I thought that there must surely be a better way.