In the US? IMO only possible in exclusive environments similar to saunas at spas or membership-based clubs/gyms
In the US? IMO only possible in exclusive environments similar to saunas at spas or membership-based clubs/gyms
One of the best tutorials on really “grokking” git
concepts, and it’s online and interactive: https://learngitbranching.js.org
For programming, start with buildings things for yourself. Be practical, start small, and iterate, regardless if you consider the previous iteration was a success or failure. I’ve heard good things about https://automatetheboringstuff.com/ (in Python) in this regard.
Can address it by writing code that doesn’t depend much on indentation, which also makes code more linear and easier to follow.
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"
All methods? Of course not. Just methods like these.
I really dislike code like that. Code like that tends to lie about what it says it does and have non-explicit interactions/dependencies.
The only thing I can really be certain from that is:
doAnything();
if(doAnything2()) {
doAnything3();
}
I.e. almost nothing at all because the abstractions aren’t useful.
I agree with the author overall, and I think it can be more straightforwardly stated. IMO it’s the idea that wrong abstractions are even worse than other ills like duplication or god classes/modules. It’s also reminiscent of “modules should be deep”.
The synchronization problem (flakiness and all the waits) is tricky to get right. Browsers are concurrent systems, and programming around one is specialized enough that many devs don’t do it well, e.g. IMO if you’re adding ad-hoc waits or nesting timeouts, you’ve already lost.
Good code is code that’s easy to delete.
I’m not a game dev, but it’s got a reputation for being more of a software engineering shit show than other software industries, which your story only reinforces.
Fine for prototyping, but adds a scaling tech debt “time bomb” for a live system. Those associations had better be really sparse.
So… a polymorphic many-to-many join table?
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.
One of the best use cases is implementing abstract data types and hiding the memory management and other potentially unsafe optimization tricks behind a clean and high level abstraction.
Also since it’s a logical/mathematical construct and not attempting to model the real world (like business logic), it’s one case where inheritance hierarchies will remain stable.
I feel a lot of advice here is trying to push the learning envelope without considering fun & the learning experience. This is for an 8 yr old, and I’m seeing suggestions that would seriously challenge high schoolers, college students, and even some software engineers in industry I’ve encountered.
For the software aspects of programming, I would suggest looking at programming(-esque) games and web browser programming environments. Here’s a solid short list, vaguely sorted from “proramming-esque” to “actual programming”:
Suggestions to go physical tinkering with electronics is good, but I’m unable to make good suggestions there.
A real computer and coding environment/shell could be good for system admin skills, but the learning curve is steep. You’ll also have to be okay with letting him accidentally brick the computer (best way to learn!).
Disagree with Docker and git at this stage of learning. This is an 8yr old playing with scratch, Minecraft, and early levels of CodeAcademy.
The answer to “not dealing with environment” isn’t Docker, it’s a programming(-esque) game or an in-browser environment.
IMO okay advice for specific types of issues, but way too prescriptive to work well generally.
Steps 3-4-5 are good, and breaking it down like that could be helpful to readers, but in my mind, it should be so well practiced and executed so naturally that it feels like a single step. I also think there ought to have been a mention of the fast iterative experimentation where 3-4-5 is repeated.
Break the build (and block other devs)? Is this a 1-team company?
Write a test first? Maybe, if you’ve already got a well isolated, somewhat understood problem whose solution won’t require deeper restructuring.
Immediately “Brainstorm as many hypotheses … as you can think of”? Inefficient if you already have a good idea of what’s wrong (wasting time guessing), and also inefficient if you have absolutely no idea what’s wrong (wasting time with uneducated guesses).
Ooh yeah PR as patches, persistent despite rebases, would be nice.
Many git operations fundamentally have three SHAs as parameters (tree operations after all), and GitHub’s model simplifies it down to two.
Unfortunately it’s uncommon now that GitHub’s PR workflow dominates, so people think in terms of (often squashed) PRs and talk about “stacking PRs”. At least GitHub supports viewing PRs commit by commit.
If PRs are just how it’s going to be, I wish GitHub could auto cut stacked PRs from a linear branch of commits.
But would you pay for it?
My employer’s paying for my access, and I only find it a bit useful here and there
Maybe my company gets a great discount or something, but if they would pay me the subscription cost to give up Copilot, I wouldn’t miss it