Notes

Here's how to burn audio to a CD from the command line.

# Remove spaces from filenames
for f in *; do mv "$f" `echo $f | tr ' ' '_'`; done
# Convert all tracks to wav
for i in $( ls ); do ffmpeg -i $i $i.wav; done
# Normalize the volume across all tracks
normalize -m *.wav
# Burn to disk
sudo wodim -v -dev='/dev/cdrom' -audio -pad *.wav

So this is one of the first times I have actually come across a hurdle when it comes to developing software on old computers. A couple days ago I started experimenting with bun, which is amazing by the way. One of the big selling points is that it is really fast, but this speed seems to come at a cost...

As I use NixOS, I installed it the usual way by adding it to my configuration.nix. But alas, life isn't always simple. It seems to install ok, but when I tried to run bun I got an error immediately:

illegal hardware instruction (core dumped)

Wow an actually hardware error! I haven't seen one of those since I was trying some overclocking! So the problem comes down to the fact that bun uses some cutting edge CPU instructions that weren't around in 2012. Now, on other Linux distributions you can simply use a bash script to install bun à la:

curl -fsSL https://bun.sh/install | bash

Apparently it checks your CPU and in the event it finds something of a certain vintage it installs a baseline version of bun which I guess doesn't use any of the funky CPU instructions it would usually. Unfortunately the nix package does not at the time of writing do this. There is actually a PR open to fix this but it has not been merged yet. So for the time being you can basically just take the code from the PR, save it to a file locally and build the baseline version yourself.

1. Download and save this file.
2. Now to build is, run:

nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'

3. You should now be able to run bun by doing:

./result/bin/bun

I witnessed this absolute corker of a bug in the office today.

After a force reboot (its a long story), we noticed that the cursor was flickering on my colleague's Ubuntu laptop. After some googling, we realised that this flickering only happens at 200% fractional scaling. Setting to any other value like 175%, 150% etc. works perfectly fine.

https://askubuntu.com/questions/1234189/cursor-flickers-on-primary-display-when-fractional-scaling-is-enable-for-dual-mo

Despite the link above being more than three and a half years old, it appears that even today, this bug can still be observed in the wild, in its natural habitat, on Ubuntu.

It's taken me far too long to discover this foot-gun in express.

I started a new express project the other day and realised that my request bodies were all empty! Spent a good hour thinking it was a problem in the client or the proxy etc... but was actually just because I forgot to apply these two middlewares.

So the question is, why are these middlewares not enabled by default????

const app = express()
  // this populates req.body when the payload is json
  app.use(express.json({ type: "application/json" }))
  // this populates req.body when the payload is urlencoded 
  // (e.g when a form gets submitted)
  app.use(express.urlencoded({ extended: true }))
  ...

Sensible defaults are just something we don't deserve I guess...

Optimistic VS Pessimistic Locking

Imagine you are on a plane and you need to pee. You're a stubborn guy. When you leave your seat, you are determined to pee one way or another. You must assume your fellow passengers are as least as stubborn.

Optimistic Locking

There is a single toilet located in the middle of the plane that can be accessed from multiple directions. You are sitting at the back and can only see the entrance to the toilet that is in your direct line of sight. You want to know if its ok to go to the toilet so you check the overhead light which says "vacant". Assuming that it will remain vacant for the entirety of the time it will take you to reach your destination, you get out of your seat and commit to peeing. Now one of two things are going to happen:

1. The toilet is vacant by the time you get to it - Success
2. Someone else has slipped into the toilet via an entrance you couldn't see during the time it took you to walk there. Since you have committed to peeing, you have no choice but to do so in a cup - Failure.

Pessimistic Locking

Due to your toilet paranoia you reserve a seat on a specially designed plane. It is designed such that each seat is directly adjacent to a toilet and has excellent visibility of all its entrances. Because of this, you are able to in a single instant, both check that a toilet is free and enter it. It is therefore guaranteed that you nor any other passenger will be forced to pee in a cup.

So obviously there is a dilemma here.

The specially designed plane will carry less passengers due to its emphasis on providing the stubborn peeing passenger peace of mind. The normal plane will be more efficient but has to account for the occasional cup of pee getting knocked over.

What have we learned?

There is no "correct" way to design a plane, only trade-offs.