Weeknotes 143

Swipe down to die – It seems a lot of car manufacturers are realising that physical controls are good, actually. Except one.

With your car rolling backwards out of control, simply turn your attention to the touchscreen—because there is no physical button to feel for—stab your finger at the letter P, hit it precisely, and hold it there. What could be easier?

We arranged for a survey to be carried out last week at the new house. When buying a house, it is nice to know if the house works.

The company carrying out the survey ignored my pleas for an update for an ENTIRE week, eventually responding without including the quote they blamed for the delay.

Do you know what the quote looked like? It looked like a single line saying “Fix a thing £??? + VAT”. Then, they had the cheek to send their invoice requiring payment within one business day!

I’ll be waiting a week to pay the invoice.

EE continues to impress. I’ve been out and about this week and it has saved me from shitty coffee shop Wi-Fi a couple of times. Of course, my favourite coffee shop still remains a blackspot, but the signal is improved.

Debugging Voyager 1 when commands take 22.5 hours distance to reach the computer.

Good news from the Voyager 1 spacecraft that has been stuck sending a 0101 pattern since Nov 2023.

The team has long suspected the root cause to be a corrupted area of memory in the FDS computer. On Mar 1, they sent some commands to make the FDS skip around sections of memory. The data stream rcvd 45 hours later looked different and was decoded to contain a read-out of the entire FDS memory!

PERF IS NOT ENOUGH – interesting take on database performance.

Performance in general, and general-purpose benchmarking in particular, is a poor way to choose a database. You’re better off making decisions based on ease of use, ecosystem, velocity of updates, or how well it integrates with your workflow.

We went over to Bath on Thursday to see Jonathan Pie at The Forum. It was very enjoyable, but very full on. Preaching to the choir, for sure, but it was a fun night out.

A friend of mine had an idea for a SaaS web product. The product would need to expose an endpoint to which JSON could be POSTed. It needs to be highly available, and never drop a request. I find this very interesting.

It made me think of Plausible, a privacy friendly web analytics product which I use on my own websites. It’s written in Elixir, and is a very good comparison problem space I think. Of course, Plausible has lots of features that are a more traditional SaaS product, but the thing it needs to do very well is ingest web analytics events and store them somewhere for later analysis.

I’ve never worked on, or been solely responsible for, a very highly available service like this. To be honest, I find the idea a bit scary. But I also find it really interesting. How do you receive and persist loads of events like this with no downtime?

Well, Elixir is about processes. They are not comparable to OS processes; they’re far cheaper and lightweight. I looked at the Plausible source code and the way they do it is to have an Elixir process which receives and buffers events, and they periodically flush the events to disk (aka write them to a database).

How do you end up with certain magic numbers in a system like this? How many events do you buffer, and how often do you choose to flush them to the database? I have no idea where to start.

I often look at software and assume that the end product is a result of genius, but in reality it’s more than likely the result of trial and error. Start with buffering 100 events, test, and see what happens. How often should you flush to disk? Choose a number of seconds, and test, test, test.

A realistic, repeatable, test script is your friend.

Speaking of which…I tried out wrk and it seems really neat. You can script your load tests using Lua.

Still, one of the biggest issues for me with load testing is coming up with realistic numbers to use in tests. How many concurrent users? How many requests? Tricky.