I've been using GitLab for a while.
And for me this looks like a PR move in the light of Github being bought by Microsoft.
EDIT: did not notice post was from 2016. Has nothing to do with Microsoft buying Github.
GitLab (not self-hosted) has constant deployment/stability issues. They do an update and sometimes GitLab is down for several hours.
This is not a huge deal for me, as I can just push my code later.
But the main concern I have is that recently they've just removed some free features in order (I guess) to force people to pay.
Features removed (the only once I've noticed):
- Merge requests: squash commits feature
- Push rules: make sure users do not push commits with non-Gitlab user emails.
- Protected branches: allow certain users to push/merge, not a whole role.
There was no email notifying about this changes, it just happened that I've created a new repo, and then noticed some stuff missing.
EDIT:
Since this got traction. I've started digging to see the differences between repos.
I have one group that is under "Early Adopter" plan, which has all the features mentioned.
Recently I've created a new group, which went under "Free" plan, and this group does not have features mentioned.
I wonder why the "Early Adopter" plan is not carried over to my new group.
> For existing users on the Free plan, we've created a special Early Adopter Plan for you. This plan has all of the existing features available in our Silver plan, with the exception of additional CI minutes or premium support. Any group or user account created before September 1st will be put onto this plan for a year for free. While we will not add new paid features to this plan, you'll continue to enjoy powerful features, like multi-project pipelines and canary deployments, for the next year. After 12 months, you will get rolled back to the Free plan. You can upgrade at any time.
Still personally feels like they're taking away free features, but just giving me a year to enjoy what I've already had.
2. Leave your previous experience behind. E.g. know C, forget about it while learning a new language.
3. Read official docs.
4. Follow the language rules (as much as possible).
5. Analyse language parts (e.g. concurrency, error handling, etc).
6. Synthesize the parts. See how parts combine (e.g. error handling in concurrent code).
7. Bring back your previous experience (e.g. see how different languages solve problems).
The main point is to know "what tools present and what can be done with those", rather than "what is felt about tools present and why the world sucks".
PS:
A small set of observations:
- "disliking" parts of a new language while learning returns you back to the step 0.
- steps 5, 6 and 7 are almost never ending (especially in languages that grow).
- step 7 requires discipline. It is needed not to "pick the best language", but to understand various ways of solving a problem across different languages (do not forget to identify a problem).
For the purpose of reproducible `node_modules` tree.
Ideally if all packages would use commits, and the installation algorithm will never change, then there will be no need for lock files.
In reality some packages will use NPM existing mechanism, so "git-based algorithm" will need to accommodate for that by reading git repo of the NPM package and referring to a specific commit, which should be store in `package-lock.json`.
I don't get why not just use git repo registry (e.g. github) for package management. If you work in a "strict" environment you can basically fork all your dependencies and use your own git repo registry.
NPM already allows using git repos, but needs some tweaks to allow better support:
I agree. I do not understand the reasoning behind overselling. Profit, yeah, like the airlines don't make enough profit by cramming as much people as they can in the aircraft, and selling better seats for higher price.
Why not just teach JavaScript or C or Java in comparison with different languages.
For example, when explaining (so evil) `var` explain that in JavaScript it works different from C or any language with block-scope variable declaration.
Big picture is important.
The problem is not the language, the problem is inferring that every new thing you pick up is somehow similar to "that thing I've used before".
It is more an expression of confusion rather than type system quality evaluation, but
why does JSON parser's implementation returns its own types like JsonNode? Why doesn't it just return core types like:
What I tried to say is that there's other side of some "people need to eat". But it is up to the author or authors to choose which side to choose (or any point in between). And there's nothing wrong with any choice.
That would be great to have this algorithm open sourced.
EDIT: I use gitlab.com