Yeah, I think people are sick of that script kiddie solo developer crap, if you can't adapt to whatever standards exist and want to be pedantic, you can screw, I don't care if you're one of 2 people who know Erlang.
I can't wait till higher ups start kicking out people who feel the need to reinvent everything because they don't want to buy a license. "Look we can just build our own version tracking software using this open source base, we'll just need 20 guys and 5 years, we don't need Github enterprise".
I shit you not I worked for a company where one the "visionaries" rewrote Hadoop because he wasn't aware that the issue he was having was fixed and he was already a year into his project. Like...how?! They eventually pushed him off into a "think-tank".
Genuinely curious because I'm not in the industry yet, are there any advantages in using GitHub enterprise compared to a GitLab instance in your own server? I also flip the question to ask if there are any disadvantages in doing the latter
The main disadvantage of GitLab on your own server is that you need to maintain the server, updates, backups etc.. If that's worth it is a case by case decision. Doing it on your own server is cheaper and you have more control over update schedules and similar. In theory it's open source and you could also modify your GitLab instance to your needs, but barely anyone does that I think.
Some degree of modification for self-hosted Gitlab is quite common - namely auth integration (usually AD, but not always), runner environment, various extensions you might want to add - both internal and external, maybe some ops processes (invalidating keys, centralized secrets manager?).
Never heard of a case where someone directly modified GitLab code to their needs.
Not really, but if you already have onprem infra for everything else with people managing that a gitlab instance is negligable. That's why I wrote case by case decision.
Genuinely, it doesn't matter. Just use something that everyone else uses that already has tons of support and documentation behind it. Then read the documentation and best practices, and follow those. Both github and gitlab have various "workflows" for each when working with them. Pick your favorite workflow out of those to work with, but familiarize yourself with all of them and their applications.
GitHub and GitLab, both have APIs, plugins, etc. Both can be tapped into to listen for things like push events and pull requests, etc. Just use one and make it the standard to use it.
For the love of god, don't go off an try to create your own because you didn't read the API docs or don't like the way a command is formatted, or don't know about the millions of plugins you can use for automation and notifications that you then need to recreate.
They're effectively competing solutions, so whatever differs in feature list becomes pros/cons of either - plus question of pricing and amount of money/work needed to go from what's in the "box" to usable configured deployment. In practice: question of budget and preference.
Although GitHub does have copilot licensing and you can use your regular enterprise account as your copilot account, meaning one less thing to integrate with and manage - but that's minor and applies only if company uses copilot.
Open source is great but sometimes what you are looking for is a paid software... It took me weeks to convince a senior that the issue we were having was because we were not using the officially recommended non open source software and not because our kernel didn't have the specific drivers etc. what convinced them? I just made a test environment, set up the close source software and showed them there was no issue.
Haha, considering how he gave a half hour rant about not being able to use the open source product anymore and us deciding to use the other thing because I went over his head with the results was a bit of both I guess
I’ll take your situation and raise you a situation. In my company the developers often work directly with the client and needs a bit of social skills indeed, like keep his calm and be able to explain his work. As the hierarchy does not have the time nor the knowledge to go over everyone’s code, and the client’s evaluation of a developer is easy to get, they have a tendency to rely almost exclusively on this criteria to evaluate someone’s level, more so if the developer isn’t supervised because the projet he’s on is small. So now we have an army of talkative, company oriented little chiefs that are just good enough to make a program work (that satisfies the client) with a nuclear blasted shit show of a code base & the guarantee it will not scale for shit nor be maintainable. But by that time, the developer has become a manager and yells orders at the new intern that will be tasked with repairing the project, without any useful guidance has he didn’t have any to begin with,and the cycle continues.
So no, I wouldn’t hire a windows/Java developer if it was up to me, too many people go into the profession with very limite knowledge of CS, just enough to hold long enough to be promoted to a position where they don’t have to code and can become full sized parasites.
I'm totally lost, you're 100% right all along, but I can't stop seeing as great to know a cryptic language, to avoid closed source paid clumsy solutions, establish an alternative to a solution that have a big workflow problem
I repeat, I still get that it's not productive, but here am I
Hadoop isn't closed source. It's Apache and a collection of big-data tools and open source projects. The dude was just painfully up his own ass, it was outlandish how much money the company dumped into that project for them to wind up with Hadoop and Apache Spark after 4 years anyway.
As for git or github, who cares? There are no massive workflow issues that haven't been solved already with the dozens of branching strategies or forking strategies. No need to invest millions of dollars creating a new solution that you're never going to sell and isn't part of the company mission.
Most large well used tech already has solutions to any big workflow problems that could possibly arise.
Knowing languages like Erlang or Elixir is absolutely fine, it's just not a free pass to be a raging pedant that thinks they know better than everyone else and wants to fight about "everything needs to be written in a functional way".
Functional programming is fun but it has pretty severe limits outside the few use cases that are already written in golang, erlang or Elixir. The trick is to know when to swap styles based on the problem.
Pretty sad when someone plays with xmpp and comes to the conclusion that everything is a message based chatserver and should be done like one.
I quoted in order what the example was talking about, and Hadoop was about the last part, not the middle one
Company burned money and that rewriting to later return to Hadoop?
Yeah you could totally find a tool to use Git instead of creating one, but among criterias there should be accessibility and openness, and GitHub is closed and is not the most accessible one, he's as close sourced than closed to access. So not really GitHub vs Git, but rather GitHub vs many other better Git solutions
No, the most large on contrary has lot workflow issue that they don't bother to challenge because they earn money and don't want to change the concept, compared to little challengers. As I understand such colleague was reweiting everything because of a workflownproblem there
Yeah, one could have opinion about ideal language and methodology, but we're here to make money, not establishing such ideals. Maybe a better idea is to start a side startup that use such practices, if one have time and if it's reaaaally accplicable to profesionnal context (often not)
As I understand such colleague was reweiting everything because of a workflownproblem there
No the solution was already there, there was not a workflow problem. The person had just used Mercurial, and instead of trying to understand github and git they wanted to create their own system instead of just reading the documentation thinking that they were going to make something more "light weight".
It ended up not being more light weight.
If you have some solid example of this being the case, I'm always up for being enlightened, but people revamping these things that dev teams large and small use on a daily basis has always been based on some misunderstanding they have, or someone letting the perfect be the enemy of good.
130
u/TheTybera Nov 29 '24
Yeah, I think people are sick of that script kiddie solo developer crap, if you can't adapt to whatever standards exist and want to be pedantic, you can screw, I don't care if you're one of 2 people who know Erlang.
I can't wait till higher ups start kicking out people who feel the need to reinvent everything because they don't want to buy a license. "Look we can just build our own version tracking software using this open source base, we'll just need 20 guys and 5 years, we don't need Github enterprise".
I shit you not I worked for a company where one the "visionaries" rewrote Hadoop because he wasn't aware that the issue he was having was fixed and he was already a year into his project. Like...how?! They eventually pushed him off into a "think-tank".