One of the things I like about golang (and Rust too, by the way) is that it’s quite simple to build really small container images by statically linking the executables, and using scratch as the base image. I’ve done this a few times in the past, and was doing it again just recently. Except that this time around, I ran into issues: the container would crash soon after it started.

I recently had to switch phones, because my old phone conked out. I had an app on that phone that I used for short-lived MFA codes for various logins I use. That app was a poor choice, because it didn’t allow for a backup of the secrets used for the code generation, so I had to go to the relevant logins and one by one remove MFA, then add it again. While doing so, I was wondering how this stuff works underneath, so I started looking into this.

Over the years I’ve accumulated a few Raspberry Pis of different versions, each of which I’ve used for certain things, some of them I’ve retired or upgraded to newer versions. Consequently, I have a few Raspberry Pi 1 and 1B still around, and they’re not doing much aside from collecting dust. I also have an old Raspberry Pi NoIR camera that I haven’t been using much.

Over the years I’ve tried different things, including PIR-triggered recording of the camera feed, sort of to build a device that records what’s happening when the infrared sensor is triggered. While that actually worked just fine, I also wanted to be able to get a steady video stream from the camera that can be observed over the internet, if necessary.

First, let me state this more precisely: this is a post about generating c# code for ASP.Net Core from an Open API definition at build time using NSwag. If you’re looking for steps to generate code by using the NSwag toolchain manually, you won’t find that here. If you’re looking for a way to generate an Open API definition from an existing ASP.Net Core app using the NSwag toolchain, you won’t find that here either. In that latter case though you’ll get a statement from me telling you that for a professional service you probably shouldn’t do that: you wouldn’t define your interfaces after making the implementation either, right?

Earlier this year I’ve started using K3s regularly for local testing of Kubernetes workloads, APIs, tools, and more. I’ve grown quite fond of k3s for multiple reasons: it’s very easy and fast to install, very easy to use, and so far I have not found a single service designed for K8s that wouldn’t work on K3s. I’ve run it both on Linux machines as well as on Windows machines through WSL2. It just works. I use it in particular also to test my own K8s controllers and operators. Installation typically finishes in 15-20 seconds, and system pods are usually running fine after another at most 30 seconds.

One of the things I have been working on at work over the past few months is an open source implementation for .Net of the standard-to-be for HTTP message signatures. I’ve ended up calling this NSign which granted is a bit broad – the libraries deal only with HTTP signatures – but I found that the name quite fitting.

The general idea of HTTP message signatures is that clients and/or servers can create and verify digital signatures or message authentication codes over HTTP messages, that is either request or response messages. As the standard-to-be puts this:

I’ve wanted to get rid of Wordpress for a while now. It’s more of a hassle than anything else, really. And who on earth still uses PHP? Anyway, a while ago I embarked on the journey to find a good replacement. First, I looked at other CMS systems that are similar to Wordpress, but soon realized that they’d all require me to keep them up-to-date all the time, and they’d likely be just about as annoying. At the same time, I’ve gotten so used to creating web content using markdown, that I hoped I could find something where markdown indeed plays a significant role in building the content. In addition, being a developer at heart, I was hoping to also find something with a decent version control system for history and rollbacks (whenever necessary) and the likes.

Earlier this year we were dealing with an issue in one of our data processing pipelines. Through telemetry we could see where the problem was coming from, but I did wonder if I could model the problem in a simulation too. After all, if we have a tool available to predict certain issues before we implement them, that can be very helpful to adapt the design and/or code upfront. I remembered some lecture from university many years ago, where we were discussing discrete event simulations. So I figured I’d give it a shot and see if I can write a simple simulator for such a producer/consumer scenario with TypeScript.