3 ms·

Set up a "scratchpad" repo for small experiments / learning, and phrase your learning as tests. Not only does it get you practice writing code, you have eviden

by Groxx 7y ago

Set up a "scratchpad" repo for small experiments / learning, and phrase your learning as tests. Not only does it get you practice writing code, you have evidence that what you think is actually true. And/or you can demonstrate it's not, when you learn otherwise. And if you push it somewhere, you can link people to it trivially (great for questions / teaching / bug reports). It's pretty much guaranteed to be faster to hop in / build / run than your day-to-day repository (often by a few orders of magnitude), and testing some things forces you to learn some new tricks (concurrency tests / bug demonstrations are particularly complex). And personally I also recommend setting up an auto-rerun-tests loop (I prefer `entr`), which gets you very nearly repl-level feedback in any language. You can interactively explore to learn basically anything in any language.

kanyethegreat 7y ago
Love this idea! I generally just have scratch files in whatever codebase I'm working on, but I like the idea of having a centralized place to keep these. Any chance yours is public? I'd love to see an example of how you organized the repo, what type of stuff your testing, any boilerplate setup/tooling you used to make it more effective (mocking library to stub out things like network calls or complex objects, test runners, etc)
- Groxx 7y ago
  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

by Groxx 7y ago

kanyethegreat 7y ago

Love this idea! I generally just have scratch files in whatever codebase I'm working on, but I like the idea of having a centralized place to keep these. Any chance yours is public? I'd love to see an example of how you organized the repo, what type of stuff your testing, any boilerplate setup/tooling you used to make it more effective (mocking library to stub out things like network calls or complex objects, test runners, etc)

Groxx 7y ago
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