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
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
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.
What are the numbers for?
speed up certain types of applications as long as application providers don’t have to pay for special treatment
Maybe they mean by doing things like giving slight priority to real-time application traffic like VOIP over streaming over websites vs file transfers, like how home routers can?
Don’t think that should be something to charge people more for, though. They’re not even able to deliver on their own advertised speeds.
Thank goodness for the Hippocratic origins of healthcare. Wish I could throw his words back at him so he could hear how insane it sounds in the context of healthcare. Just imagine:
You think a doctor sits back and says, ‘Gosh, how can we get the price of saving this patient’s life down?’ No, it’s like, ‘How high a price can I get and maximize the profit for my shareholder?’"
But surely there’s a practical middle between “shoot first, ask later” and “sit and wait an hour”
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