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
In the US? IMO only possible in exclusive environments similar to saunas at spas or membership-based clubs/gyms
Idgi – is it saying that every game is either named “X” or “Y’s X”?
There’s the practical distinction between “everyone can do it with some dedicated intent” (so few actually bother) vs “everyone can do it on a whim”
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).
I prefer that, though (it’s in my calendar, but I don’t have to accept). I really can’t stand Outlook’s email-based calendar workflow.
That’s only because the former already implies much of the latter, so they don’t need to repeat it
I’ve heard of publishing software to design photo albums/scrapbooks/cards etc. Is there a photo collection manager for archiving, sorting and filtering?
Given access to a large set of personal photos, say tens of thousands, it should be able to group, categorize, tag, and sort along a myriad of dimensions.
Example dimensions would be time, people and places. It would need some facial recognition/image classifier/similarity scoring capability.
There definitely are some cloud offerings today that do similar things, but I’d want it to work locally for privacy and practical reasons.
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?
If talking about a closed source app, their whole goal is to move off of hosting closed source systems.
Article says the decision follows a successful pilot project, so they’re willing to absorb the short term costs. Optimistically in the long run, the symbiotic benefits of having a government entity using and supporting a full FOSS system will be huge.
Oh, interesting
Hell of a frame budget to work by, but I don’t know much about game programming
You can, once you find a game that runs at 1k fps
Not surprising that PDF comments were being used as a task list/tracker. In the same manner, Google Docs supports “@-mentions”, “assign to”, and “resolved” functionality for comments.
All you can do is send feedback to Adobe somehow and hope they add that feature back in. In the meantime, best to find an alternative workflow.
avoiding merge conflicts
No, not like that – you misunderstand. I’m not talking about actively avoiding conflicts. Coordinating to avoid merge conflicts is the same work as resolving a merge conflict anyway, just at a different time.
I’m talking about creating practices and environments where they’re less likely to happen in the first place, never incurring the coordination cost at all.
One example at the individual level is similar to what you mentioned, but there’s more to it. E.g. atomically renaming and moving in separate commits, so git’s engine better understands how the code has changed over time and can better resolve merges without conflict.
But there’re other levels to it, too. A higher-order example could be a hot module where conflicts frequently occur. Sure, atomic commits and all that can help “recover” from conflict more easily, but perhaps if the hot module were re-designed so that interface boundaries aligned with the domains of changes that keep conflicting, future changes would simply not conflict anymore.
IMO the latter has an actual productivity benefit for teams/orgs. Some portion of devs just aren’t going to be that git proficient, and in this case, good high level organization is saving them from losing hours to incorrect conflict resolutions that can cause lost work, unintended logical conflicts (even though not lexical conflict), etc. Plus, it implies abstraction boundaries better match the changes demanded by the domain, so the code is likely easier to understand, too.
It’s kind of difficult to explain in the same way git is difficult to grok on the first try.
Perhaps it’s convincing enough to just say:
I.e. whether a conflict will happen is not some totally unpredictable random event. It’s possible to engineer a project’s code & repo so that conflicts are less common.
Even better, learn how to avoid conflicts from happening in the first place!
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