Also have the option of selectively/strictly enforcing in CI, to get an experience & protections similar to “compile-time type checking”
Also have the option of selectively/strictly enforcing in CI, to get an experience & protections similar to “compile-time type checking”
it lacks clear and enforced type restrictions which help with clear code contracts
Not anymore! Gradual typing is supported by the core language and pyright is a fantastic incremental type checker that you can use both in your editor and in CI.
What’s hard about vanilla Ruby?
What did you go over?
“never see addressed”? What do you think currently happens in (real, non-hypothetical) cities with good bike infrastructure?
https://www.youtube.com/watch?v=j2dHFC31VtQ&t=365
Oh look, emergency vehicles work even better on bike infrastructure than on car infrastructure
Bicylists and pedestrians can’t hard block a firetruck the way car traffic can
inheritance to avoid code duplication
What no, inheritance is not for code sharing
Sound bite aside, inheritance is a higher level concept. That it “shares code” is one of several effects.
The simple, plain, decoupled way to share code is the humble function call, i.e. static method in certain langs.
If you used good objects, you’ll only have to make the change in one place
IMO that’s generally a retroactive statement because in practice have to be lucky for that to be true. An abstraction along one dimension – even a good one, will limit flexibility in some other dimension.
Occasionally, everything comes into alignment and an opportunity appears to reliably-ish predict the correct abstraction the future will need.
Most every other time, you’re better off avoiding the possibility of the really costly bad abstraction by resisting the urge to abstract preemptively.
How does playing the game bring revenue? Ads?
Also, I would think that the business would be in a tougher situation if game popularity increased while tech workers weren’t around to maintain it
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
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”
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
What? My intuition is there’s always gotta be some equivalent nicer refactor that could do away with such an awkward construct.
In what kind of situation would that be totally unavoidable?
That route already exists today as “the web”, where the “latest” JavaScript source is downloaded and JIT-ed by browsers. That ecosystem is also not the greatest example of stable and secure software.
In my experience, LLMs aren’t really that good at summarizing
It’s more like they can “rewrite more concisely” which is a bit different