This is another indicator that "lifecycle" scripts in NPM (or other packaging systems, except perhaps Debian or RPM) are an idea we need to learn to live without. At most, packages should be able to emit a message to the user asking them to invoke a one-liner if a setup action is truly necessary.
As a side benefit, eliminating package scripts will contribute toward reproducibility of Docker and VM images.
I was excited about this idea, but based on the writing patterns and vague stories I'm pretty sure these writeups are mostly AI slop. For example, this is classic ChatGPT phrasing:
> The growth I’d been celebrating wasn’t real growth—it was just a spike of first-time buyers who never came back.
If I'm wrong, and these were actually written by a human, I'd love a chance to stand corrected and apologize.
My favorite section in an RFC is "alternatives considered". I've seen many times that an option that had been initially discarded became the solution after review and discussion. It's also a great way to answer later questions about "why didn't you do X instead".
Just imagine being the designer of this thing and sitting at Thanksgiving dinner with your family. "Oh, tedchs, what've you been up to at work?" "Okay well this is gonna sound odd but we invented a camera for your stool... No, not that stool... Yes, it clips onto the bowl..."
My question is, why can Google themselves not just provide a dump to archive.org themselves? Having volunteer middlemen doing the work seems like an artificial crisis.
I've used strings of Twinkly lights for a couple seasons now. They can sometimes be found on eBay for cheap. They're easy to set up, whether standalone or by clustering multiple units into one larger virtual canvas. The app has a lot of good looking animated patterns included.
I've had the reMarkable 2 for years and it's amazing. FYI, the reMarkable is itself quite hackable. There is a supported way to run an SSH server on it and push your own binaries and other files to use on the device. One example resource for hacks/mods is https://github.com/danielebruneo/remarkable2-hacks .
FYI you can use a universal infrared remote with Apple TV, which might have larger buttons or a more familiar interface. I have mixed feelings myself about the "touchpad" in the apple remote.
What I've found best is a compromise: send a chat message like "Hi foo, I hope you're having a good day! I'm trying to figure something out with Postgres and I wonder if you might have 30 minutes to chat about it?". As a remote worker, there is also a social cohesion upside to having a synchronous call sometimes.
The first line has two errors. First, 9/11 was on a Tuesday. Saying it was a Sunday is just foolish, as it happened at the start of a busy workday. Many of us still remember it like it was yesterday. Also, the line says 2011.
Further question - how do we know these intercepts are authentic?
I did this, around 2005, but I dropped ALL the prod tables. I was using a SQL GUI called Toad (awesome) and had separate windows open, for both "dev" and "prod". I was trying to reset the dev database, and used the wrong window. Thankfully, the "real" DBA at the time had 15-minute backups, and was able to restore it, and then I replayed a few transactions from logs. Lesson learned!
> While building a feature, we performed a database migration command locally, but it incorrectly pointed to the production environment instead, which dropped all tables in production.
This is a clever hack. However, if the intent is serious use, I'd be concerned about resiliency. It sounds like the schedule is maintained in Home Assistant, and that it sends a command to the ESP8266 to dispense food. That means a ton of moving parts have to all be working, otherwise the cat doesn't eat: Home Assistant's server and power source, Wi-Fi, and the $1 microcontroller.
If this is intended for serious usage, i.e. the cat won't eat if it fails to dispense, a different design would be more resilient: maybe still define the schedule in Home Assistant or another control plane, but then have it "push" the whole schedule to the device. The device will also need time sync and a realtime clock. Then, the device manages its scheduled dispensation autonomously, even if the network or control plane are unavailable. And, the dispenser should have a little battery so it can run for a couple days with the power out.