Weeknotes 56 and 57

It has been a trying couple of weeks so we have been in need of uplifting television shows.

Our current rotation is “Schitt’s Creek”, “Ted Lasso”, “Nadiya Bakes” and “Nigella’s Cook, Eat, Repeat”.

The latter two are a bit heavy-handed on the “everything’s alright, everything’s alright, it’s OK, it’s fine” but I don’t mind.
In an attempt to break the Groundhog Day of cooking at home and re-introduce some semblance of a date night, E and I ordered a meal kit from Perilla. It met our hopes of providing a change from something we would typically make ourselves without being a chore to prepare: the main course came in two vacuum sealed bags and only needed boiling in water for 12 minutes.

We sat at our dining table for the first time in months and realised how much we needed a break from our daily routine.
I got a Raspberry Pi 400 and was pleasantly surprised to find a print edition of the Raspberry Pi Beginner’s Guide in the box. Leafing through it while booting the Pi 400 for the first time, I pictured myself at 8 years old opening this on Christmas Day.
I’ve had my Twitter account for 14 years, initially only using it to send free group text messages. I am not the most famous “mudge” and am constantly mistaken for Peiter “Mudge” Zatko, so much so that I decided to “protect” my account a few weeks ago.

I did so in the nick of time as Zatko is the new Head of Security for Twitter.

Alas, now I’m receiving a whole new type of misdirected tweet: support and feature requests for Twitter itself.
When looking after C, one of my favourite things to do is build him the most elaborate tower out of DUPLO possible. I’ll incorporate bogies, animal heads and even the occasional submarine.

As I know he will eventually destroy it, it has become a sort of mandala.
In versions of Mozilla Firefox prior to 61.0, requests made with the Fetch API won’t send cookies unless you specify the credentials option.

I ran into this when Rails’ cross-site request forgery countermeasures prevented my Stripe Checkout integration from working properly in Firefox 52. Switching to the new default value of same-origin for credentials meant the Rails session cookie was correctly sent and the CSRF forgery protection would permit the request:
```
fetch("/some-endpoint", {
  method: "POST",
  credentials: "same-origin",
  headers: {
    "Content-Type": "application/json",
    "X-CSRF-Token": csrfToken,
  },
  // ...
})
```
Concerned there were other bugs I had missed, I started using React’s Strict Mode to perform stricter checks in development. In particular, I wanted to see how my components would behave when intentionally double-rendered.
I added JavaScript error monitoring with Sentry which caused a 493,803% increase in “events” since the previous week when I was only monitoring Ruby errors.

Specifically, I started to see a lot of errors from a window.fetch polyfill bundled with the Shopify BuyButton.js but almost all of them came from a download page.

This page shows a simple “Thank you” message to the user and immediately redirects them to a PDF using a <meta http-equiv="refresh">. When trying to reproduce the error in Safari, I noticed a bunch of different errors all due to the fact the redirect effectively cancels any JavaScript in progress.

To work around this, I copied a technique used by SourceForge and Audible and used an invisible <iframe> with a src pointing to a file with a Content-Disposition of attachment, e.g.
```
<iframe src="https://example.com/some.pdf" class="d-none"></iframe>
```
This immediately causes the browser to start downloading the PDF without cancelling any JavaScript running on the page.
I’ve been working on a web service to record anonymous usage statistics of a desktop application. A key goal of this project is to avoid storing personal data and exemplify data minimisation.

In looking for other applications that do a similar thing, I dug into the anonymous aggregate user behaviour analytics collected by Homebrew which uses curl to report events to the Google Analytics Measurement Protocol.

Reporting events to a third party over HTTP opens a whole can of worms, particularly as IP addresses alone can be considered personal data. As our reporting needs are very simple, I decided to implement my own service using Rack and Redis.

Specifically, requests to the service are stored as daily counts in Sorted Sets that expire after 90 days like so:
```
ZADD choice:2020-11-28 INCR 1 "Some choice"
EXPIRE choice:2020-11-28 7776000
```
This way, we can see what the top ten most popular choices for a particular day are with ZREVRANGE like so:
```
ZREVRANGE choice:2020-11-28 0 10 WITHSCORES
```
If we want to look at choices over a longer time period, we use ZUNIONSTORE to aggregate each of the dates in the range:
```
ZUNIONSTORE choice:past_week 8 choice:2020-11-20 choice:2020-11-21 choice:2020-11-22 choice:2020-11-23 choice:2020-11-24 choice:2020-11-25 choice:2020-11-26 choice:2020-11-27
```
Then we use ZREVRANGE again to get the results:
```
ZREVRANGE choice:past_week 0 10 WITHSCORES
```
Despite best intentions, it is very easy to accidentally store personal data without realising it. For example, even if you don’t log requests to your service in your application code, Heroku will log the IP addresses of every request made to your app, retaining the most recent 1,500 lines of logs for one week.
I enjoyed Rowan Manning’s “Yeehaw!” about attempting side projects and tip #5 “When the Fun Stops, Stop” feels especially relevant when working alone. I’ve had several situations recently where I find myself down some blind alley of refactoring and have to force myself to git restore . and refocus my efforts.
C is unhappily teething but please try not to think about how every child’s jaws are packed with teeth.