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.

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?

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:

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.

I’ve wanted to find a good provider of cheap and secure cloud backups for a while. I’ve compared some cloud drive providers, but didn’t quite like those. They usually have very limited free plans, somewhat pricey paid plans (e.g. 50GB for about 24$ a year for OneDrive), or like in the case of Google no information available at all. By the way, “Google one is coming soon” isn’t an announcement that I want to look at for more than a few days when looking for pricing info. Then, I’ve looked at pricing of cloud storage providers, such as AWS, Azure and Google Cloud. Those offer storage around 1 cent ($0.01) per GB per month. That’s a quarter of the OneDrive cost! It’s even less if you consider their archive offerings (AWS Glacier, Archive in Azure, Coldline Storage for Google). The cheapest offering here is from Microsoft at 0.2 cents ($0.002) per GB per month, but with some usage caveats. Since the point of backups is to keep them for a long time, this quickly adds up though. Now I’ve written a line or two of code before, so I figured I could as well write my own tool for this. So here is bart, the backup and restore tool. Note that at this point I do not offer bart as a ready-to-use executable, but only as MIT-licensed source code. In addition, bart currently works only with Azure Blob Storage - or with storage mounted into the machine’s file system. However, adding other cloud providers/archive destinations should be relatively easy, given the interfaces used in the tool.