Craig Weber

I finally got around to automating the publishing of this blog. It hasn’t been a high priority, since I only post a couple of times a year, but it’s always bothered me that something that is such an ideal candidate for automation hasn’t been automated. Anyway, I finally did it and I want to describe the setup in case it’s helpful for anyone looking to do the same.

NOTE: If you’re here for the TL;DR, skip to the bottom.

A few months ago I built out some monitoring infrastructure at work using Go. I deployed it to ECS (a Docker orchestrator, functionally similar to Kubernetes), and for fun I decided to see how minimal I could make the image. I’ve used Alpine base images before (which weigh in at about 5 MB and usually another 5 MB for a small Go binary), but being that Go advertises itself as requiring only a Linux kernel (most programming languages depend on an interpreter, a VM, and/or system libraries–the latter abstract over kernel functionality and sometimes provide a stable interface to the kernel), I wanted to see how true or practical this was, and I wanted to better understand the things that I was taking for granted by using distros.

As a matter of context, Docker has a special base image called scratch which is empty–an application running on a scratch base image only has access to the kernel (at least to the extent that containers provide isolation).

A little over 2.5 years ago, I wrote a tutorial about installing Go. Since then, one of the more significant changes to the Go ecosystem has been the addition of modules, which effectively does away with the hardest part of installing Go–$GOPATH. This change occurred in the latest version: Go 1.11.

In addition to installing Go, I wanted to make a guide that can get you from nothing to a real project in half an hour. Most languages focus their introductory material on the language and briefly cover setting up a toy program. When you’re done, you realize you have no idea how to build a multi-file program, how to add dependencies (or at least how to add them in a way that won’t break other things on your system), how to get an editor up and running, etc.

I’m not going to focus much at all on Go the language here, since it’s super easy to learn and there are already many great tutorials (the official Tour is probably not a bad place to start). I’m only going to go deep enough to give you a lay of the land; if I’ve done my job, it should be easy enough to Google for specific resources on any given topic (for example, testing).

Now without further ado…

I’ve recently been involved in conversations with a few Go developers who have expressed frustration about Go’s interfaces with respect to nil. It seems not everyone understands that interfaces are a reference type (like a pointer), and they can reference other reference types (i.e., pointers, maps, slices, etc). Because all reference types have a nil (zero) value, an interface can be nil or an interface can reference a nil pointer; people may fail to realize that the nility of the interface is independent from the nility of the thing it points to, and when we ask (for example) if err != nil, we’re actually asking is the interface nil?, not is the value behind the interface nil?. Here are a few examples that will (hopefully) demonstrate this clearly:

Sometimes I’m curious about the performance of different languages. At work, I usually write Python, but I often find tasks that are inherently parallelizable and could thus benefit from parallel execution. Unfortunately, Python is notoriously difficult to parallelize^a. In one case, we needed to validate that a table of values of a particular type could be convertible into a values of a different type based on some known set of conversion rules. Since Go is a great language for writing concurrent programs (and executing them in parallel), I decided to compare a sequential Python implementation to sequential and parallel Go implementations.

This is a guide for Unix systems (OS X and Linux), but Windows users shouldn’t find it too difficult to figure out the equivalent commands for their platform. I’m not assuming much prior knowledge, but readers should at least be comfortable navigating around a Unix terminal, and any familiarity with environment variables is helpful (a quick Google search for “environment variables” should suffice). Without further ado:

This is a collection of articles I’ve found about software development best-practices. I intend to add to it over time, so don’t be surprised if it changes.

I’ve known about this blog post for a couple years, and I find myself frequently referring people to it. It’s written by a Google engineer who does a much better job of articulating good architecture techniques than I could. A must-read for any software developer: Writing Testable Code by Misko Hevery

This next post is something I just came across, but it does a really good job explaining why writing testable code is not just about validating your code’s functionality. Because it’s something I run into a lot in dynamic languages like Python or Qt/C++, I would also add that hacky workarounds (like Python’s unittest.mock.patch()) exist that let you technically validate your code without actually writing what is considered to be well-designed, testable code. Without furhter ado: Write testable code even if you don’t write tests by Karl Seguin.