vlfig

But you still let the user put in the effort before revealing they'll have to sign up. Just be upfront.

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.

You are not alone. https://en.wikipedia.org/wiki/Wu_wei

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.

Eminently doable, yes.

Two notes:

- 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.

Next step: embeddings and similarity.

I sanction this comment.

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.

We shouldn't dismiss the theory of how to do things right just because it is common to do things poorly.

a Dhall configuration file will never:

- throw an exception

- crash or segfault

- accept malformed input

- produce malformed output

- hang or time out

in https://docs.dhall-lang.org/discussions/Safety-guarantees.ht...

Still a fan of Python for configuration?

Different requirements, different guarantees. Principle of least power. Have a look at https://docs.dhall-lang.org/discussions/Safety-guarantees.ht....

Ban on cash: impose negative interest rates. CBDCs: all manner of restrictions to fungibility.

Sigh.

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.

Mostly yes. My advice on this topic is to read up on Liberating Structures, which I think are a level up.

https://liberatingstructures.com/

A request for a synchronous form of communication is a request for your time. People should earn it first.

Obsidian + GitJournal + NeuraCache.

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

(also, Monero > bitcoin)

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.

Base64 padding, probably.

Exactly this. One thing is to have (today) the same behaviour, another is to (forever) be the same thing.

Hah! Not seriously, no.

REST is a solid, simple, and powerful transport method and let's maybe do without CORBA moving forward.

Chill. :-) The world agrees with you.

Author here. Thanks for reading.

* What build toolchains are suited to these arbitrary DAG arrangements?

In general any CI/CD tool that allows for easy composition of jobs/pipelines, where versioned artifacts are a first-class citizen and can be the outputs and the inputs of jobs. Preferably one where the graph is emergent, i.e. just a consequence of declaring which "jobs" (taken loosely) depend on which artifacts.

I've had good experiences with GoCD https://gocd.org and Concourse https://concourse-ci.org, the latter being a fresher, younger take on these concepts. I haven't surveyed the landscape recently so there may be other tools that work well.

I love the candor in your post but you're being too hard on yourself.

Learn functional programming, gradually. You'll get there. I like to think I reverted a decade of brain damage inflicted by enterprise java development in three years.

If the main purpose is to document decisions on a project, not your journey as an engineer, consider using Architecture Decision Records — ADRs. Simple, to the point, live-with-the-code. https://github.com/npryce/adr-tools