You can reference envs from the host in docker compose, so code it in instead of manually passing tribal knowledge in: https://stackoverflow.com/a/73826410

Simpler to keep everything in one compose file if you can, under a test service that doesn’t build unless explicitly named

Un-weird that env var and use the normal, boring feature of defining environment under your test service

I’ve often been able to alias drun='docker compose run --rm --build' and simplify down to:

drun test

Should be able to encode all those wayward args into docker-compose.yml or Dockerfile and only use vanilla docker commands – that’s the whole point of containerization

wanted to add something to the end of a for-loop, but had too little indentation

To address this, I prefer reducing length & depth of nested code, so the for/while is rarely ever not visible along with everything inside it. Others have success with editors that draw indentation lines.

opening up new/anonymous scopes

I occasionally use Python nested functions for this purpose

I find it’s possible to operate Python as a statically typed language if you wanted, though it takes some setup with external tooling. It wasn’t hard, but had to set up pyright, editor integration, configuration to type check strictly and along with tests, and CI.

I even find the type system to be far more powerful than how I remembered Java’s to be (though I’m not familiar with the newest Java versions).

That’s only because the former already implies much of the latter, so they don’t need to repeat it

If it takes 1+ hours of work to remove a feature flag branch in an area of code, I wouldn’t trust the correctness of anything the AI writes and would be super skeptical about anything the humans had written.

It refers to a male cousin that is NOT in the same paternal line, so maybe not too uncommon?