Zig’s package manager is still a bit rough. It only supports fetching tarballs, but many github projects don’t have them unless they have a release. There’s a trick to fetch any commit as a tarball though:

I finally got around to looking into The One Billion Row Challenge. If you’re unfamiliar, it’s a challenge to how fast a program can read and process one billion rows. It’s fascinating because it’s all about raw performance including algorithms, CPU instructions, and profiling and benchmarking. All things I enjoy dabbling with.

I recently realized the docker container for my toy project books has over 2k downloads so I finally decided to write some proper docs for it. There’s not much to document, but it deserves a nice webpage. Picked up mkdocs because I saw it used by some other projects and I’m positively surprised. You initialize a project and throw some markdown files at it. Then you run build and it gives you a nice webpage for your docs, nothing more, nothing less. Great little tool, highly recommend it.

I’ve been following the zig language for a while ever since I saw Andrew Kelly’s talk on Corecursive. The way Andrew describes the design of zig was very engrossing and who doesn’t like a language build for speed. But I have struggled with picking it up; time is in short supply and so were docs for zig when I first looked at it.

But that has changed; I finally found some motivation and ziglearn.org which is a good introduction to zig. I have only managed to read the first two chapters, much less understand them but it’s enough to be dangerous (to myself?).

I’ve been running my Kubernetes cluster on Raspberry Pis for about a year now. Overall the cluster is stable and needs little attention and by now many useful and important services are now running on it. With more reliance on these services I need to ensure that the cluster doesn’t fail from preventable errors. One of the common failure modes for Raspberry Pis are sdcards. They are not very fast, they are of limited size, and worst, they tend to fail.

Was writing a few posts for my food blog and needed to type some some “special” characters like é. When on a Mac that’s really simple because the keymap supports typing compound keys. But I’m on Linux and switching between keyboard layouts is annoying. So I figured vim must have a way for typing these characters, and behold, I learned about Vim’s digraph support. The documentation is quite good but I’ll cherry pick some combos because otherwise I’ll forget.

I’ve spent some time over the holidays building a Kubernetes cluster running on raspberry pis. One issue I ran into was that not all docker images I wanted to run were available for arm/linux. Luckily there’s a useful tool called buildx that extends Docker to build containers for different platforms and architectures using quemu and binfmt. ARM has a blog post that details the steps needed to build images.

The steps are:

I spent a good hour trying to get a custom completion script working while porting my app Harbormaster to Cobra. It would and would not work. I retried writing the file, restarting the shell and it would just not offer any completions. Eventually I stumbled upon a innocent looking post on Github that held the solution: remove the .zcompdump file which holds the cached completions. So I ran rm ~/.zcompdump && compinit and everything works as expected.

I needed to crunch some data quickly and decided awk was the right tool to do so. But every time I use awk, I have to go read the manual, so I decided it’s time for a cheat sheet.

Structure of an awk script

# Comments begin with a pound sign
BEGIN {
  # Instructions run before the main loop
  FS = ";" # Set a Field Separator
}

# Each line of input is applied against all the following
# regular expressions and runs the instructions in the
# block:

/^$/ { print "An empty line" }

END {
  # Instructions run after the main loop
}

Invoke awk with a script like so:

I was browsing the Pragmatic Bookshelf and this book caught my eye: writing a ray tracer from ground up with a test driven approach? This sounds like a fantastic challenge to me. I always was interested in ray tracers but always thought it too complicated a topic to do it myself. However, test driven development has helped me work on some complex and terrible code bases, so this feels reassuring to me.