My favorite was “it’s impossible to know which DB is failing from a stack trace”. I created STAIN (stack traces and instance names): a ruby library that would wrap an object in a viral proxy (all returns from all methods are themselves proxies) that would intercept all exceptions and annotate the call stack with the “stain”ed tag.

An LLM will run the probabilistically likely command each time. This is like using Excel’s ridiculous feature to have a cell be populated by copilot rather than having the AI generate a deterministic formula.

Previously you could define a function that accepted never and throws. It tells the compiler that you expect the code path to be exhaustive and fixes any return value expected errors. If the type is changed so that it’s no longer exhaustive it will fail to compile and (still better than satisfies) if an invalid value is passed at runtime it will throw.

At Google we noticed the main cause of outages are config changes. Does that mean external config is dangerous? Of course not! But it does remind you to be vigilant

I want to +1 that Vercel has been really improving their portability. We still have Next.js specific code in Firebase, and having different architectures can sometimes make us have to figure out the best mapping of their features, but Vercel has made a noted effort to improve encapsulation of Vercel-specific features and portability has improved. I’m honestly surprised that OpenNext, which is not a new project, seems to have gained a lot of attention in the immediate past.

Should I assume that irrespective of this finding, pads should be placed where the AED indicates so that rhythm detection works correctly?