dang, my bad. I did a pretty quick (and large) refactor this morning and must have broke it.
EDIT: it fetches historical games when the session is established. The bug is that after you complete the game, the call to renderStats is still using the old games list; it needs to refresh the list so it includes the game you just completed. I'll fix this over the weekend. Cheers!
I use a NAS, raspberry pi, and s3 with the following workflow:
Photos are imported from SD card using a script. This script creates a new directory, captures some metadata, copies the photos in and creates thumbnails. This directory is rsynced to the NAS then encrypted, compressed and sent to s3. Nightly, from another location a raspberry pi with a large encrypted disk rsyncs the entire NAS.
All viewing and editing of photos is done against the NAS, and any changes are picked up nightly by the pis. The s3 copy acts as an immutable original.
a QR generator which will magically connect me to the WiFi with my password embedded in the QR somehow.
This is indeed what it does, but it also includes the plaintext password in case you want to connect a device that doesn't have a camera, like a PC. There's an open issue for adding a "hide password" option. You could also just cut off or scribble out the password on the print out.
Answering as the author who also understands the fundamentals of all of the technologies involved and questions much of what goes on in the minds of today's web developers and designers--
I use Make as the standard way to interact with every repo I own. This allows me to type `make build` instead of `$some-language-specific-command-I-forget-in-2-weeks`.
I use Docker for distributing every app I build. If the app is a website I also use the nginx base image. Docker images make packaging and distribution a breeze IMO.
Regarding yarn, npx, react, and jest: I'm similarly disillusioned by the churn but I also like to remain knowledgeable as the industry evolves. React was something I hadn't touched before, so I decided to pick a simple project to give it whirl ;)
In my experience, I've found the lack of polymorphism to be the larger challenge in building complex business systems in Go.
Managing a bunch of polymorphic entities in Go often requires implementing a bunch of interfaces in various types. You then have to write a bunch of mapping logic for every type, driven by type assertions. Apply this in a large codebase that encapsulates transport, data access, and so on and you end up with a ton of complexity.