431–440 of 520 posts
Earlier quoted context omitted.
There's probably a large overlap between the two communities.
Considering almost every human I know uses Reddit in some capacity (technical and non-technical), that's pretty likely.
Earlier quoted context omitted.
Considering almost every human I know uses Reddit in some capacity (technical and non-technical), that's pretty likely.
You're in a really self-selecting crowd then. Less than half the people I know use it, mostly because my social group is outside of the tech world.
I think npm has been a headache for everyone at some point, which is one of the main reasons I started contributing to Yarn. I think npm has done a lot of good work in the past year to respond to the necessary change, so kudos to them for their work; however, it's nowhere near the rock-solid package manager that we need. If the Javascript ecosystem is to ever be taken seriously, and not as a toy -- it has to have more reliability.
Ergonomically, I currently thing it's ahead of many other package managers because of how simple it is to get running. The number of "gotcha's" after npm install is nothing to shake a stick at, though.
One of the things you can do to get builds that aren't as suspect to npm registry issues is configuring an offline mirror [1].
From the post:
"Repeatable and reliable builds for large JavaScript projects are vital. If your builds depend on dependencies being downloaded from network, this build system is neither repeatable nor reliable.
One of the main advantages of Yarn is that it can install node_modules from files located in file system. We call it “Offline Mirror” because it mirrors the files downloaded from registry during the first build and stores them locally for future builds."
Earlier quoted context omitted.
Largely because Javacsript is so broken by default that it is almost required to depend on a whole slew of dependencies for functionality other languages contain in their built-in standard libraries. And furthermore, NPM dependencies are broken down into stupidly small units, versioned rapidly, and enforces very little consistency among transitive dependencies. Other languages and package management systems don't enc…
I’m impressed. Not one thing you just said is accurate.
Gah. Moments like these always gives me a bit of panic, since I realize that so much of my software relies on external sources. Relying on npm, Atlassian/GitHub etc really hurts when stuff like this happens. Issues always gets resolved, but cases such as the GitLab incident should be enough to always keep some local copies around.
Having a redundant array of independent cloud providers seems the ideal state. This is the most effective way to provide a single source of truth without it becoming a single point of failure.
Hi folks, npm COO here. This was an operational issue that we worked to correct. All packages are now restored: https://status.npmjs.org/incidents/41zfb8qpvrdj
Were any of the deleted packages temporarily hijacked? It seems strongly like this was the case. If so, please confirm immediately so people who installed packages during this time can start scanning for malware. Even if the answer is “yes, 1+ packages were hijacked by not-the-original author, but we’re still investigating if there was malware”, tell people immediately. Don’t wait a few days for your investigation an…
Mate, one can't come to conclusions without an investigation, ya?
Earlier quoted context omitted.
And all this is happening just as after the public release of a serious exploit which allows malicious code to do all sorts of nefarious things when it is somehow installed on the target machine . Hmm. Given that there's hints, at least, that the problems were caused by some particular developer's actions, I wonder about the security model for package-managed platforms altogether now. If I were a big cybercrime ring,…
Wouldn't you need to install those packages as root for the code to have privileges to take advantage of that exploit?
Earlier quoted context omitted.
Well, kind of. Node was not a general purpose tool as conceived initially. You would write some I/O bound servers in it. And PHP too is not a general purpose tool, it is for writing interactive web pages (in its pre-Web2.0 sense) easily. Though Node.js was way more intellectually designed. I don't know much about PHP, but there's lots of literature (see https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ ).
I really wish that people would stop referencing that "Fractal of Bad Design" article. It's outdated and mostly irrelevant now (April 2012, PHP was at 5.4 then, it's at 7.2 now). It's not that I want to defend PHP, I just think people should judge PHP for what it is now instead of what it was several major changes ago. Besides, the author seems to misunderstand a great many things about PHP and languages in general.…
Some issues might be "fixed" but could they fix the actual *fractal of bad design"?
Isn't it still a mix of c-style, java-style, inconcistent, left associative, horribly broken language it always was?
I always thought the bugs were anecdotal backing of the main point: php is badly designed, non programming language for non programmers, who suffer stockholm syndrome from all php abuse...
Earlier quoted context omitted.
Three developers on my team spent the last 4 years pushing for angular. Four years ago, I was 50/50 on it vs react, so whatever, but if my team's really for it, let's do it. Fast forward to angular 2, and we're down to two developers who are still for it. Fast forward to today, I'm down to one angular dev who's still for it, and two of the original three have left for react jobs. Meanwhile, I'm left with a bunch of a…
I don't understand. We've started a new Angular 2+ project and our junior developers managed to roll into quite easily. Our designers (who know jack about Javascript) got excited when they discovered that our project uses .scss and the results have been spectacular. Seriously, I REALLY REALLY don't get this hate for Angular 2+