A week of organising, done by the system.

Every tap goes to one server function.

Both sites send what people do to a single Cloud Function, a few events at a time. The browser posts plain text with sendBeacon, so a batch still leaves when the page closes.

There is no API key in the request: visitors send too, so there is no account to check. Instead the function checks where the request came from, its shape, its size and how often that device sends. A signed-in member’s batch also carries their Firebase ID token, which the server verifies; the user id written in the body is never trusted.

1. 1The endpoint: one function, POST only, no query string.
2. 2Who and where: a random session and device id, never a name.
3. 3What happened: a page, a screen, its timings, a tap.

A game is a template, its parts and their prices.

Every week’s game is made from a template: Rikki’s real WhatsApp list, turned into data. The sport, the venue and the day are the categories. The court place, the training and the BBQ are the items a player signs up for, and each has its own price for a regular, a newer player or a guest.

A sign-up is one record per part, so a court place, a training and a BBQ are paid, waited for and cancelled separately. Each record is in one of four states: claimed, confirmed, unpaid or cancelled.

1. 1Categories: the sport, the venue, the day.
2. 2Items: the court place, the training, the BBQ.
3. 3Variations: the same item at three prices, by who is playing.

What is recorded, where it goes, who reads it.

The log records the address, the screen in view and every tap: what a button says, never what anyone types. It also catches the trouble: script errors, a request that failed or took over four seconds, and frustration read from the taps, such as three taps in 600 ms on one spot, or a tap that changed nothing.

Nine goals mark the moments that count, each with a fixed id in the code, never read off a button’s words. Google Analytics hears them only after a visitor says yes. Batches are stored by the session for 13 months; every night they are summed into counts that are kept. Only the organiser’s console reads them, on its Logs and Growth pages; the public pages show counts, never names.

1. 1Each goal carries one word that splits it, such as the sport.
2. 2An unknown id is refused, so a typo fails a test, not the numbers.

The page that froze on iPhones.

Rikki, on the site saved to his iPhone’s Home Screen: “when i click on events … it freezes and wont change”. The address changed; the screen didn’t.

Reproduced in Apple’s WebKit engine and each read timed: the database’s streaming connection stalled there, and a read hung 6 to 30 seconds at random, against about 50 ms in Chrome. The cache made no difference, so the fault was the connection. The fix switches Apple’s WebKit to long polling and leaves every other browser alone: every read then answered in 0.1 to 0.9 seconds.

Found on the way: the site’s own log had dropped the opening batches of every page after the first, because each page counted from 1 again and the server skips a number it already has. That is why the freezes left no trace. The count now runs across the whole visit.

1. 1Apple’s WebKit is every browser on an iPhone, the Home Screen app included.
2. 2There: long polling, and a cache per tab.
3. 3Elsewhere: the stream and the shared cache, unchanged.

Ratings off the public record, in one line.

Making the football teams saved every player’s rating on the game, and anyone can read a game, visitors included. The privacy page promised that only the organiser sees ratings. Nothing live had leaked: the one night on the site held no rating when checked.

The fix is one mapping, run before a game is saved: copy each team without its rating total, and each player without their rating. The ratings now sit in a separate record kept for that night’s players.

1. 1Take the team’s rating out; keep the rest as t.
2. 2Do the same for every player.
3. 3Real output, the demo’s Team B: the same team, minus six numbers.