I often believe that I need to write something completely new. But as I read more and more leadership articles, I realise that a lot of them cover the same ground. Even so, I find value in reading multiple takes and adaptations on the same idea. So I can write my own thoughts and contribute to this variety of interpretations. And, anyway, there is value for myself in writing down my versions of things, so I might as well. Here’s one of those things.

This is an idea I came across several years ago. It helped me to understand why creating alignment between individuals and teams is so important to the success of an organisation. It’s the notion that one can use vectors to model how individuals in an organisation contribute to the whole, and why aligned teams are so powerful.

I recently ported github-to-omnifocus to Go. One new thing I learned is that it’s easy to embed files into Go binaries, extending Go’s “single file” deployment simplicity to include required non-Go resources.

In this case, I needed to call JXA scripts from Go. In github-to-omnifocus, these are required to interface with Omnifocus itself; they create, read, update and complete tasks. I wanted a single binary executable still, and feared I’d need to embed the JXA scripts as strings within the binary. That would make them hard to debug as I’d not be able to run them standalone. Fortunately, Go 1.16 introduced compiler support for embedding files into Go binaries, alongside an API to read them at runtime.

At Cloudant, we use GitOps to manage our Kubernetes workloads. One of the advantages of this approach is that we store fully-rendered Kubernetes manifests within GitHub for deployment to our Kubernetes clusters.

One thing that I often find myself doing is writing small one-off tools to answer questions about those manifests. For example, “by deployment, what is the CPU and memory resource allocation, and how much does that cost in terms of worker machine price?”. As a first approximation, this can be discovered by loading up all Deployment manifests from our GitOps repository, then processing their content to discover container resource requests and the number of replicas specified by each Deployment.

For a long time, I’ve kind of existed with a barely-there understanding of Python packaging. Just enough to copy a requirements.txt file from an old project and write a Makefile with pip install -r requirements.txt. A few years ago, I started using pipenv, and again learned just-enough to make it work.

It’s relatively easy to find articles online about the basics of Kubernetes that talk about how Kubernetes looks on your servers. That a Kubernetes cluster consists of master nodes (where Kubernetes book-keeping takes place) and worker nodes (where your applications and some system applications run). And that to run more stuff, you provision more workers, and that each pod looks like its own machine. And so on.

But for me, I found a disconnect between that mental image of relatively clean looking things running on servers and the reams and reams of YAML one must write to seemingly do anything with Kubernetes. Recently, I found the Kubernetes API overview pages. Somehow I’d not really internalised before that the reams of YAML are just compositions of types, like programming in any class-based language.