On and off for the last couple of months, I’ve been working on a theme for VS Code. It’s a light version of my favourite dark theme, Monokai Pro. Sadly I can’t share it as it amalgamates two different VS Code themes, one person’s theme suggestions in a GitHub comment and my own tweaks. I’ve no idea how that works for licensing, so I’m playing it safe.
Instead, I’ll share how I got there, because sometimes it’s good to read about a journey. If it inspires you, all the better.
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.