You might or might not know that this blog is hosted on a small single board computer in my basement and until recently I’d write or edit my posts, rebuild it locally and then push the built files up to the server hosting the static files. Works, but cumbersome and I’d frequently push drafts by accident. Not a big deal since drafts are also in Git, but still, unprofessional. But the beauty of a homelab is that you can automate things with as much or as little effort as you want. And automate I did.

So recently, against my best judgement, I’ve started working on a new project. The classic “how hard can it be?” kind of thing. What that actually is is not important right now. More important are the tech choices and how I shifted my opinion on generated code.

The tech stack I went with is what I usually pick; go for backend, pgx and sqlc for database access, htmx for frontend matters. I found managing Go’s template/html always a bit fiddly and wanted a better way of dealing with nested components and being able to render them individually. I have seen templ recommended many times and because it was a new project, I gave it a try. Initially I felt having yet another tool that generates go was weird, but after a few components I was sold.

Hugo has a really way of hooking into the rendering process that I’m using to automatically generate scaled down thumbnails of referenced images. I structure each blog post as a page bundle and render images via ![](image-name.jpg) in the markdown files. By default, hugo will render an image tag with the full sized image which can be rather heavy if it’s a large image. So instead, I set up a render hook for images in layouts/_markup/render-image.html:

In an effort to understand Postgres better I’ve worked my way through how a Postgres database is structured and executes queries.

Process Model

Postgres uses a process-per-worker model. That means every connection is handled by a separate operating system process forked off the initial process.

Subsystem Overview

Postgres consists of several components that all work together to process data and ensure it’s reliably written and can be looked up efficiently. The following are the most important components, but there more, other components that are beyond the scope of this post.

Let me tell you how I was an idiot, ignored best practices, and luckily didn’t lose anything of value. And yes, this is a story about backups.

In my homelab I now have a few machines that run NixOS. This came to be because I wanted the ability to quickly rebuild machines from scratch without having to fiddle with individual settings. Thanks to NixOS I now have a repository that holds a flake that can build bootable images and perform remote nixos-rebuild switch.

It’s this time of the year again. I’ve recently set up this little page, and I really didn’t want it to be on Github or hosted by Github Pages.

In my homelab I run many different single board computers, among them Odroid M1s. However, there’s various versions of Raspbian, Armbian, and Debian, each of them using some custom tweaks. And that’s a lot of time to maintain them. So I really like the idea of NixOS and read that it can be used to build bootable images for computers. I haven’t fully built intuition for all parts in this so it took me a while to get this working. Here’s my notes.

I enjoy reading books. I very much enjoy reading printed books, but they’re heavy, you can’t read them in the dark, and unlike my phone or ereader, I don’t have them on me all the time. So, I read a lot of ebooks. And with most ereaders, reading novels is fine, at least if you read reflowable document types like epubs. But as soon as you start reading PDFs, all bets are off. At least, until I discovered KOReader

I’m hacking on a small Zig application with a GTK frontend, and part of using GTK is passing around ?*anyopaque pointers and you never quite know if it’s working. In my app I’m passing around a struct that holds a string []const u8 to various GTK callbacks. However the string was empty. This led me down a rabbit hole of trying to figure out if my pointers were correctly passed, even going as far as stepping through it with a debugger. Turns out, the pointers are all correct. Even my string []const u8 was there with the correct length, except every single byte was set to 170 and I realized I was looking at undefined memory. Zig in debug mode sets undefined memory to 0xaa which is 170.

Recently I’ve been working on updating my blog a bit (you might have noticed?). I keep the hugo sources in a git repository and the built site in a separate repository. That repository is added as a submodule to the sources repo and during the build, the generated HTML is written into the submodule. Except the submodule kept getting messed up; git would be unable to track the changes or they’d be added to the parent repository. It was truly maddening, but as it is so often, the problem was not git but me.

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.

I recently switched back from MacVim to terminal (alacritty) Vim because I’m trying to step up my tmux game after reading the excellent tmux 2 book from the Pragmatic Bookshelf. But anyways, I noticed incredibly slow syntax highlighting for larger ruby files, so slow that editing code was almost impossible. After lots of searching and debugging I found it was the regular expression engine Vim uses by default in combination with the Ruby syntax highlighter.

I recently had the need to quickly visualize some data and none of the systems I usually work with had the data. Initially I dumped the data in Google Sheets and created a chart there, but that was slow and didn’t really scale well. The data had to be cleaned, brought into the right format, columns had to be selected and charts created. At this point I faintly recalled reading about gnuplot which, despite its name, has no affiliation with the GNU project.

I recently received my copy of Working Effectivly With Legacy Code and have been busy reading it. The book, as a product of its time, has examples of not only Java, but also C++, probably to show concepts and techniques that apply to languages that behave differently in terms of linking and building. But regardless of its examples not really applying to what I work with, it was full of useful vocabulary and techniques to work with not only legacy systems, but really, any kind of system.

Google recently announced availability of 1.0 preview of Flutter, a new framework for building mobile apps, written from scratch with performance and beautiful UIs in mind. I’ve always been interested in building apps for mobile devices in general and Android in particular thanks to the number of Android devices I own, but was always discouraged by the complexity of building Android apps. I have one on the Android store that got too unwieldy to work on and I eventually had to cease development due to time constraints. Now with flutter closing in on its first release build I got interested, not only because it is a new beginning to building mobile apps – and we all know that developers love newly built things – but also because it uses Dart, Googles attempt to create a language to replace JavaScript that, sadly, went not far.

I had this book on my wishlist for quite a while, but never thought I needed it. But then it was warmly recommended to me during a fantastic OOP Workshop with Sandi Metz. If Sandi recommends it, it must be good. Excited to dive into this one:

A coding exercise I do once in a while is writing Battleship. It’s a fun little exercise, comes with a slew of interesting decisions, and every once in a while I do this exercise with a candidate as part of the interview process. It’s always exciting to see what other developers come up with. Today I was doing the exercise and I contemplated on the primitive obsession code smell that always seems to creep into my code and saw a beautiful way to apply the extract class refactoring that very succinctly shows how nice object oriented programming can be.