3 ms·

> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development

> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development Difficult question. In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer that were not version controlled in any way. That worked, but that's also the reason I lost most of the source code that I've written before/during university. Version control is not a simple problem. A distributed version control system, even less simple. Git has some ergonomics issues that may possibly get improved, but the fundamental problem is not trivial. We already have to learn so much to do the simplest of tasks, that removing password auth seems to not move the little much, if at all. You can certainly 'postpone' some of this learning, maybe that's one route. Back when there were "IDE wars", that would be one of the arguments ("we don't have to learn no stinkin' CLI"). Some IDEs even had their own, local, "version control". At some point you'll have to "pop open the hood" though.

runnerup 5y ago
> In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer This is what my company does. Except we use git. Everyone just keeps their repo on their drive and there's no central "canonical" repository. Everyone has a personal folder in the main fileserver and they push frequently to their personal remote repo. Any time they send emails saying they've made a notable milestone, anyone curious just merges against their remote. The codebases somehow rarely (never) diverge catastrophically. Maybe because we're doing embedded work.
- p1necone 5y ago
  What do you release from - just whatever personal repo has all the features you need? This is interesting because you're kinda using git as the fully distributed system that it's design allows for, which isn't that common.
  - runnerup 5y ago
    > What do you release from - just whatever personal repo has all the features you need? Yep - when we need to release we just kind of merge everything into a release, compile the firmware, validate it in house and then send it to our contract manufacturer in China. "Who" does that depends on whoever is free or most closely tied to that update.
- rightbyte 5y ago
  That actually sounds quite nice and quite close how Torvalds thought git would be used I guess.

runnerup 5y ago

> In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer This is what my company does. Except we use git. Everyone just keeps their repo on their drive and there's no central "canonical" repository. Everyone has a personal folder in the main fileserver and they push frequently to their personal remote repo. Any time they send emails saying they've made a notable milestone, anyone curious just merges against their remote. The codebases somehow rarely (never) diverge catastrophically. Maybe because we're doing embedded work.

p1necone 5y ago
What do you release from - just whatever personal repo has all the features you need? This is interesting because you're kinda using git as the fully distributed system that it's design allows for, which isn't that common.
- runnerup 5y ago
  > What do you release from - just whatever personal repo has all the features you need? Yep - when we need to release we just kind of merge everything into a release, compile the firmware, validate it in house and then send it to our contract manufacturer in China. "Who" does that depends on whoever is free or most closely tied to that update.
rightbyte 5y ago
That actually sounds quite nice and quite close how Torvalds thought git would be used I guess.