I’d really like for this website to be around in 20 years. And that means this website won’t be around in 20 years. It’ll have been Ship-of-Theseus’d out of existence multiple times over by then.

It’s really quite a freeing realisation, because it means I can quit obsessing over the little details and actually do the thing that matters, which is writing for this blog. It doesn’t matter if the padding and margins are inconsistent in some places, nor does it matter that the code I use to generate this site is a bit messy and could be refactored. The only thing left five, ten, twenty years from today will be my words, not the pretty frame around them.

Obviously, this isn’t to say I’ve stopped caring about the appearance or accessibility of my blog. I could never do that.

But in general, I think I should take myself less seriously. Do things that aren’t perfect, or great, or even good. Too often, I’ve found myself losing motivation for a project or putting it off indefinitely after setting unreasonable expectations for myself and quickly realising I won’t be able to meet them. In some cases, many cases, it’s okay if what I make is “bad”, because at least it is, as opposed to just a daydream rotting away inside my head. If there’s potential there, then my first iteration is never going to be the final iteration anyway!

I’ve been using Helix since October 22 2025, according to the commit history on my system’s Nix flake. Coming from Neovim, it wasn’t a radical change, but there are some things that Helix does right, imo:

1. Select-then-edit model: In the traditional Vi(m) editing model, your keybinds look like <action><selection> e.g. dw to delete the next word. Helix keybinds work in reverse i.e. <selection><action>. After using it for a while, I’m convinced that this is a much more intuitive way to edit text: being able to see what your action will affect before you do it makes for a much nicer experience.

2. Approach to configuration: Unlike Neovim, Helix doesn’t let you install and configure plugins. I maintained a pretty lean Neovim setup anyway, so this didn’t come as too jarring of a change to me. Helix comes with a lot of great features out of the box: LSP support, syntax highlighting with Tree-Sitter, basic Git integration, etc. Just like Fish, Helix comes with really good defaults. My config (TOML!) comes out at <45 lines: 12 for the editor itself and 30 for telling it which formatters to use. I do wish it came with a built-in file explorer though :(

The only downside so far is that editors and IDEs like Zed and IDEA don’t have great Helix keybinding support yet, but I’ll cross that bridge when I come to it.

I’m finally getting around to publishing a link blog! And what better post to start off with than Simon Willison talking about his approach to maintaining a link blog.

A slightly self-involved concern I have is that I like to prove that I’ve read it. This is more for me than for anyone else: I don’t like to recommend something if I’ve not read that thing myself, and sticking in a detail that shows I read past the first paragraph helps keep me honest about that.

This is important to me too, but I’d like to prove it to myself more than anyone else. I’ve wanted for a long time to more critically engage with things I read online, and hopefully this link blog will make me read and understand more deeply than I would otherwise.

It’s part of a larger effort to spruce up my website and self-hosted setup that I’m very excited about!

I'm doing Advent of Code again this year, and part 1 of today's problem reminded me immediately of some of the problems I'm doing in my Program Construction module at UCD. So, I'm going to be coming up with a formally verified algorithm to solve Part 1 using Edsger W. Dijkstra's Structured Programming style of Program Composition.

Of all the pieces of software I had to set up again when I switched to NixOS, Neovim took me the longest. This kind of surprised me at first: given that the Venn Diagram of NixOS users and Neovim users is fairly close to a circle ­— the set of people who are most productive when fiddling with configuration — I thought it'd be a breeze to get Neovim going on NixOS. Unfortunately, all that seems to have happened is, perhaps predictably, the evolution of a dozen different ways to go about this.

Something I realised while playing around with sorts in Haskell.

A while back, I came across a couple of other blogs by college students reviewing the courses they took over the previous semester. I decided to do the same because it feels like a good way to lend a sense of closure to the semester, especially since exam season was a mad rush without time for much else than revision.

I recently deployed a couple of services on a VM in the cloud so I could get my feet wet when it comes to self-hosting apps for my own personal use. So far, it's been pretty fun but also frustrating at times; I figured I'd document everything I've done up until now so it's easier for me when I migrate to a different server at some point in the future.

If you've gone through the first year of a undergraduate Computer Science degree, you'll have written enough truth tables to last you a lifetime. Personally, I decided I'd had enough halfway through the semester and wrote a program to write my truth tables for me in Go. Unfortunately, we'd moved on from the topic before I finished working on this, but I still think it's a pretty interesting project.

A few months ago, one of NetSoc's committee members built an r/place clone just for NetSoc's members, and we figured it would be nice to have a Discord bot to periodically take screenshots of the pixel art website and post updates to our server. When I volunteered to make it (because why not?), I never thought I'd spend about 5 hours wrestling with Docker while trying to deploy the app to our server, because the Dockerised app would only run on my computer.

While doing some routine maintenance on a society server running Ubuntu (I'm a sysadmin for my university's computer and networking society), I noticed that its system clock had drifted away from the true time by approximately 20 minutes. This amount of drift isn't something one would expect to see on a long-running server with an active NTP service ... except, of course, the NTP service wasn't working.