No, just one internal to work (which I share pretty heavily), though I should set a public one up. I've got a few bad ideas fleshed out enough to realize why t

No, just one internal to work (which I share pretty heavily), though I should set a public one up. I've got a few bad ideas fleshed out enough to realize why they're bad, and a few multi-million-iteration things to test the fairness of go channels / cancellation strategies / etc just because it seemed like fun. But the repo has slowly grown to include things like demonstrating issues in books[1]. Boilerplate setup for me is typically: - a one-page Makefile for laziness. I try very hard to avoid automating what I don't fully understand, and large / complex makefiles are typically inscrutable for readers. usually I just have "build", "test", and "live tests", little else. - a small script to use `entr` to run tests in the last directory changed (the /_ arg) - ... that's about it. maybe a .editorconfig or .envrc? I avoid lang-specific runners because they're all different and tend to have complex relationships - if you can't run your test within a second or three, find a different way. break apart dependencies to benefit from build caches. leverage make. etc. If I wrote experiments that used networking libs, I might have common stubs, but none currently :) I'd be sorta tempted to write fakes tho (probably multi-process), and try to integrate them into tests, in part because that's often hard for no apparent good reason. Maybe I'd find out why, or maybe I'd end up with a demonstration that there isn't a good reason. [1]: https://www.oreilly.com/catalog/errataunconfirmed.csp?isbn=0636920046189 https://www.oreilly.com/catalog/errataunconfirmed.csp?isbn=0... I'm the sync.Cond.Broadcast one