You're absolutely right, and I share the frustration.
I'm thinking a possible solution to this signal-to-noise problem is to embrace the longitudinal view: instead of comparing each scan with the normal across the population compare only against past self, unless there's a risk factor that warrants it.
This way we could presumably make use of plentiful scan data and mostly look at the stuff that evolves in suspicious ways, not what looks suspicious.
Don't "let it" generate tests. Be intentional. Define them in a way that's slightly oblique to how the production code approaches the problem, so the seams don't match. Heck, that's why it's good to write them before even thinking about the prod side.
- I'm not convinced the graph is necessarily cyclic. Often two codependents are actually dependent on some common bits and otherwise independent.
- this is essentially deterministic propagation of configuration (think dhall, jsonnet, etc) plus reconciliation loops for external state, terraform style — not dissimilar to how the rest of CI/CD should operate, in fact my view is this is an extension of CI/CD practices up the value stream.
I'm definitely strive for something like this when possible.
Although it isn't yet clear how much the brakes did actually brake, it is known they would never be enough.
So the cable was a critical component and initial findings suggest it wasn't being verified as rigourously, thoroughly and often as it perhaps should have.
Generally what happens is that:
- Everyone is able to prove a transaction's correctness;
- There's no way for a third party to track the contents of a transaction adversarialy;
- there are ways for first and second parties to prove them if they so wish.
No-cloud (except for git, could be self hosted), local-first, plain data formats solution for note taking, knowledge organisation, text production and spaced repetition.
For a less romanticised, more practical resource on the topic, I recommend The Hitchhiker’s Guide to Online Anonymity https://anonymousplanet.org/guide.html
Aside from the click-baity article, the actual report puts emphasis on the quality of the existing data about food waste. A bit of an "let's measure this first" attitude, which is a bit of a let down to me.
"Food waste means all of the environmental impacts of food production without any of the benefits of people being fed." — it reads, and I think it misses an important point: leaving food waste to rot with the rest of the rubbish is in itself environmentally damaging while using it for composting, feeding larvae or both, is immensely beneficial.
I'd like to see more practical recommendations for what we already know we can do about food waste. And not just about reducing it, which is more easily said than done, but also about giving it a proper goodbye.
The version of the API and the version of the artifact that implements it are distinct, not the least because the artifact can implement several (major) versions of the API.
Using tests across versions is a definitely a trick to consider but your coverage may vary. Probably better to do it in addition to other methods.
[ my public key: https://keybase.io/vlfig; my proof: https://keybase.io/vlfig/sigs/m5-4eTUpqZsAvvl2vInWmcBN29lCs_WSgL94CZuS3jo ]