Tools, tools, tools

One of my guilty pleasures is watching videos about tools on youtube. Like many people who make things, I have an appreciation for the tooling that enables me, and there are endless rabbit-holes of content to fall into.

Although I dabble in physical projects, the majority of my professional and hobby projects are more oriented towards programming computers, thus my own tool optimisation revolves more around curating and customising a set of development tooling for software.

I choose to eschew commercial tooling where possible in favour of open source, which gives me the certainty that I am not investing my efforts into something that will be rug pulled when the company behind it inevitably need to make their graphs go up and to the right a bit more.

This philosophy and the tooling it has inspired is all neatly packaged up in my dotfiles repo, with a set of configuration files that has been honed over the last 20 years of my career.

One of the nice things that having my tools all packaged up in this way is that I can install everything on a new machine with a single command. Some might argue that this is overkill - how often do you need to setup a new computer anyway? But actually, I've found myself setting up developer environments on lots of machines.

Recently I needed to setup environments on multiple servers for example. This might seem anachronistic - with modern devops best practises, we've been encouraged to treat machines as cattle rather than pets; and although there is a lot of wisdom in this advice, the exception to the rule seems increasingly common (as shortages of GPU's, or other compute resources, compounded by extortionate cloud computing prices, combine to incentivise machines with a longer lifespan). Having a developer setup with a single command is an invaluable asset when you might need to provision a development server in this sort of situation.

One of the tools that makes all of this possible for me is chezmoi, written by my good friend Tom. It replaced a heinous makefile that I used to maintain, that would do all the symlinking necessary to get configs into the right place. After much heckling over beer, I switched to Tom's tool, and immediately everything became easier.

The development of my tooling is very agglomerative - something annoys me, I hack together a fix, and it makes it's way into my repository. Over time, the piles of hackery add up to what we would call in the industry 'technical debt'.

But every now and then, the motivation to clean up hits me, and I wade into the mess. One of the things that had been added to chezmoi since I started using it was the ability to use templating within the configuration files.

This allowed you to, for example, setup variations of configurations for differing machines - meaning it was easy to have differing setups for osx, and linux. Before, I had used some fairly horrific shell scripts to make this work, so it was nice to replace this with something more streamlined.

This immediately became useful as I found myself needing to use some servers that only had bash installed - I have been using zsh for many years now. But most shells are pretty similar, so I thought it would be trivial to support both with my dotfiles. And for the most part I was right, but the little part that was left sent me down a rabbit hole of discovering the subtle differences between .profile, .bash_profile, .bashrc and .zprofile. Beyond a certain point, development on linux becomes akin to archaology.

I settled on the following model:

zprofile sources .profile sources .[zsh|bash]rc, which essentially makes everything available everywhere, and ignores the difference between login and non-login shells.

I am sure at some point, I will find an issue that makes me revisit this, but for now it seems a pragmatic solution.

Another interesting tool that I discovered recently is Hammerspoon, which allows you to create automations for a mac with lua scripts. One of the first things I experimented with are shortcuts to manage windows. In practise, all I really do is put windows on a side of the screen, or make them fullscreen, so it was very easy to make an automation, but it's possible to create a full tiling window manager with a little bit more work.

It also allowed me to create an automation that acted like 'Visor' - a little tool I used over 15 years ago to quickly open a terminal. It was fun to be able to reimplement something like this so easily.

Given my one-liner to setup my development environment, I decided to take it a step further and allow ephemeral environments in codespaces. Github provides fairly generous free minutes for their codespaces system, and, although I have still not found a way to tolerate VSCode for development, as a quick way to make small edits to repos, codespaces is a nice tool to have in the bag.

Github have begun to inherit the embrace-extend-extinguish mentality from their Micro$oft overlords, so a little bit of work is necessary to get codespaces to play nicely with a series of dotfiles. In particular, you need to include an install script in your dotfiles repo, and you need to use their ‘devcontainer’ tooling, which despite some overt open-washing is fairly tightly bound to the VSCode ecosystem.

That being said, it doesnt take much work to get a fairly decent dotfiles setup working with codespaces, and I have even begun to use codespaces to test changes to my dotfiles at some points now.

It's gratifying to discover tools like these - computing has become such a user-hostile place with walled gardens, and the feeling of powerlessness as the big companies use us as pawns in their monopolistic desire for homogeny. Still being able to customize a developer environment, and have full control over tooling is a powerful feeling, and a throwback to a time of freedom in software.