Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM: 429 Too Many Requests

github.com

Post reply on HN
Print view View original

111–120 of 171 posts

Re: NPM: 429 Too Many Requests

#111

Post by tehbeard »

adonese wrote: post #98
lm28469 wrote: post #10

Earlier quoted context omitted.

Some people getting in the workforce in the last few years have troubles making the distinction between work and play contexts. It's extremely visible on github, slack, &c. which are more and more looking like discord / reddit (gifs, memes, random jokes in the middle of serious discussions)

In GH in particular, I’m not sure why images are allowed to be rendered in comments at all. They are almost always harmful. External links can be used instead

UX of seeing the screenshots for a bug inline outweighs it being used for the occasional meme.

And it's consistent with the rest of GH's markdown parsing for README, issues, etc.

Re: NPM: 429 Too Many Requests

#112

Post by rickspencer3 »

I came here to see if anyone had insights about what happened to see if I could apply any lessons learned. But all the comments seem to be "get off my lawn" style comments annoyed about people posting jokes in the issue.

Unfortunately, I am unable to resist the urge to add to the noise by complaining about people complaining.

Re: NPM: 429 Too Many Requests

#113

Post by MivLives »

Symbiote wrote: post #107
Hamuko wrote: post #46

Earlier quoted context omitted.

Why would anyone use "&c" considering that it doesn't actually save any key presses?

Keypresses is a pretty poor metric to base communication upon. It annoys me to see "w/" and "w/o" anywhere except Twitter. The meaning isn't clear to many non-native speakers, and it's jarring — we recognise the most common words by the shape of the whole word, so it's easier to read "with" and "without". "&" is a ligature for the letters "et". A traditional way to handwrite it, other than as &, is a "crossed epsilon…

The Unicode character you suggest is closer doesn't seem to render on my Mac. & and Ɛ̸ do though.

Re: NPM: 429 Too Many Requests

#115

Post by scoutt »

Shacklz wrote: post #103
easytiger wrote: post #48

Earlier quoted context omitted.

I mean there is a difference between having fun and conducting yourself in a professional manner where appropriate. With the increase in adoption of certain technologies (node etc) I have noticed a relationship with the people employed to work with them and their poor level of professionalism in the workplace with regard to their work and how they deal with other people (in the UK) and even how they dress. Similar ag…

> [..] and even how they dress. While there are many points in your post that I agree with, we really should stop worrying about how people dress. If it's a developer sitting behind a computer screen all day long with zero customer contact whatsoever, he really shouldn't be forced to wear a certain dress code just to satisfy someone's standard of professionalism. Such feelings are in similar spirit as "woman should n…

> conditioning by society.

There is a limit. I'm sure you have one too if you really think about it. Is it tattoos all over the face? What about sandals? Or shorts? Or going bare-feet around the office.

I don't know... It's about people giving me money for work. I don't feel like I can go to work dressed like any given Sunday.

Re: NPM: 429 Too Many Requests

#116

Post by wbl »

vhakulinen wrote: post #97
Sharlin wrote: post #81

Earlier quoted context omitted.

JS/Node is the entry-level programming environment of the current era, like PHP used to be, and the community norms (or lack thereof) reflect that.

Your comparison of today's js/node to PHP from 20 years ago is interesting. I wonder if javascript will be in similar place in 10-20 years that PHP is today (e.g. "its not like it used to be and things a actually quite good now")? The language it self (javascript) might be there already, but is the community anywhere close yet? SQL injections used to be the thing PHP was known for in the past but not so much these da…

Javascript is a far better designed language than PHP. The identifiers don't have lengths picked because the maintainer used length as a hash function to name one notorious feature.

Re: NPM: 429 Too Many Requests

#117

Post by pdimitar »

matsemann wrote: post #85
easytiger wrote: post #48

Earlier quoted context omitted.

I mean there is a difference between having fun and conducting yourself in a professional manner where appropriate. With the increase in adoption of certain technologies (node etc) I have noticed a relationship with the people employed to work with them and their poor level of professionalism in the workplace with regard to their work and how they deal with other people (in the UK) and even how they dress. Similar ag…

I'm not saying I want memes everywhere, but since I'm spending 1/3 of my life at work I'd rather it be a good time. > Go post memes on the LKML and see what happens I think the seriousness (almost angry tone) in certain communities also is a disservice to attract new members. If I make my first PR in some project, it's easy too feel attacked when the reply is a negative one, albeit strictly professional. If it howeve…

Contrasting an opinion you don't like with the other extreme is usually called a strawman and is not a good way to argue.

As others have said, I too am not against a light-hearted tone. But when you have a legitimate problem that might be blocking you from doing your work and your only source of information is a GitHub issue then it should go without saying that the information should be dense and compressed and it should absolutely lack memes, yes.

Re: NPM: 429 Too Many Requests

#118

Post by andrewl-hn »

SirensOfTitan wrote: post #47

I’ve been considering checking node_modules into source control for some time now, has anyone else done that successfully? There would be a variety of benefits: 1. Eliminate redownload of packages on every CI build 2. Reduce the amount of gigantic IO operations from unpacking the tens-of-thousands of files sitting in node_modules. 3. Better security: code checked in can be audited better if not downloaded every singl…

Checking node_modules to git was the Preferred Way of working with dependencies in Node community in early days. Way before lockfiles, way before shrinkwrap and friends this way one could use `git diff` and `git bisect` to find out what dependency upgrade broke their application code. Several prominent community members and early adopters of Node advocated for this idea: they loved the idea of treating dependencies as integral part of your app, having good familiarity with the 3rd-party code you're using, etc.

However, early adopters of npm in the frontend world (back in Browserify and Require.js days) didn't like the practice (notably, because many parts of the dependencies contained node-only code, tests and scripts that were needed for building dependencies, etc.), and started putting node_modules in .gitignore. At the same time, Node people started to use other means to manage dependencies for reproducible builds: namely, private npm registries, dockerfiles, etc.

Over time both frontend and Node communities recognized the need for lockfiles, which we eventually got with Yarn and later versions of npm.

Re: NPM: 429 Too Many Requests

#120

Post by LeonidasXIV »

jackewiehose wrote: post #96
joeyrobert wrote: post #82

Earlier quoted context omitted.

Helps if you only have one platform you're developing on and deploying to (e.g. x86-64 Linux). If developing on macOS there can be Mac specific binaries installed, depending on the package.

And if you do have more platforms, why not just check in one node_modules-directory for each? This idea to redownload all packages all the time from external sources (and not even having a fallback-plan) seems completely brain-dead to me. Didn't the people learn from leftpad-gate?

> And if you do have more platforms, why not just check in one node_modules-directory for each?

Now you have to sync it or risk running into unreproducible build failures. Also, if you update the binary dependencies on say, macOS, then you still need some x86-64 Linux to build the dependency.

Not saying it is not possible but without a proper process (e.g. a build server being the only place that updates dependencies) this is going to be painful.

Post reply on HN