seldo

We believe npm's scale is a direct result of having the lowest ceremony to publish a package. Turning the dial in the direction we did has pros and cons.

I do work at npm, and you're right, that's why we do it. The same Docker-based installer (from a company called Replicated) installs on all our customers' many operating systems, so it was easiest to do the same thing to create our AMI.

We should look at ECS though. Are you more likely to deploy if something is in ECS than if it's a straight AMI?

The package author decided to unpublish the package. A new author has now stepped in and re-published the package (yay open source!) and deps are fixed.

Many thanks to ChALkeR for responsibly disclosing this to npm and giving us time to notify people and clean up as much as possible. We were very busy, and ChALkeR was incredibly patient with us :-)

In response to this disclosure, we have set up a continuously-running scanner for credential leakages of various kinds. It's not foolproof, but it's made things a lot better. We'll be writing a proper blog post about this at some point, but we've been really busy!

Not bad, please add mobile view to the login page as well :-)

npm, Inc - Oakland, CA - Onsite - Full time

npm is the package manager for JavaScript. We are hiring a lot of engineers, but the position we really need right now is a designer:

https://www.npmjs.com/jobs/#ux-ui-designer

Our website is big and popular is about to get really powerful. We need someone to really nail the UX.

We're glad private repos work for you :-) However, the overwhelming feedback from our users has been that git dependencies are a gigantic pain in the neck, and this has been our own personal experience as users of npm. Much like npm itself, we are doing something you could do without npm, it's just much easier with npm, and we hope that reduction in friction is valuable :-)

npm, Inc - Oakland, CA (remote ok, H1B ok)

www engineer, registry engineer, support tech, cli engineer

If you program in JavaScript, or use a frontend framework like Ember or Angular, you have probably used "npm install" to get new modules, or install tools to help you get your job done. We are the company behind npm, dedicated to improving the experience of JavaScript developers all over the world by reducing friction. We are hiring for all four of our teams:

- support: "npm loves you" is our unofficial motto. Taking good care of npm users who run into trouble is central to our mission.

- CLI: maintain and improve the npm command itself. With over 3MM users, we get a lot of feature requests and edge cases.

- www: we get 5MM page views a month, and a bunch of new features are in the works.

- registry: more than 50MM fresh downloads every single day, we are a big, high-traffic distributed system.

The CLI, the website, and major parts of the registry itself are all open-source.

We are not a typical startup. We believe that working sensible hours and taking care of ourselves and our loved ones is the best way to ensure long-term productivity. We care deeply about making tech a more inclusive and diverse place to work.

For more details on the jobs and us, see https://npmjs.com/jobs

Over what period does this law apply? If you are a multinational and you bring workers over for a two-week training course, do you have to give them a raise for those two weeks?

It's a pretty interesting case study of interface design that because DO's website looks so much nicer, their servers feel like a good deal, while Atlantic.net's old-fashioned branding makes it just feel fly by night, even though I'm sure they're objectively pretty similar.

We are working on including more accurate and detailed health metrics into the upcoming re-launch of the npm site. We're definitely going to be including stuff like GitHub stars (but this disadvantages non-GitHub projects), downloads, number and recency of versions, dependencies (and dev-dependencies) and are considering allowing people to filter by license and passing tests. We're also adding the Collections feature which will allow people to curate groups of packages they use or think work well together, and that will feed into rankings as well.

We've barely scratched the surface of the ways we can improve npm search, and we'd value any ideas the community has. If you have specific suggestions, I've created an issue over at https://github.com/npm/newww/issues/131 for you to throw them into :-)

Thanks! To your suggestions:

1. I tried to emphasize how important it is to keep the candidate relaxed and comfortable. Your suggestions are good, though we are too small and resource constrained to spend several weeks on interviews; each candidate gets about 6 hours in total, at least an hour of which is with me.

2. I had this process at my last job -- I asked everybody the same opened-ended architectural design question, and found it very useful for hiring back-end engineers, but at npm it's obviously inappropriate for our front-end and CLI engineers, so I've yet to come up with a "standard" question. It's a great suggestion.

As an aside, I am pleasantly surprised to see how many constructive comments there were on this article. Sort of feels like HN from a couple of years ago.

See also from a few years ago: http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

I agree with basically everything in this post, obviously :-)

Command line tools developer, npm, Oakland, CA: http://www.npmjs.com/jobs/ (REMOTE)

npm is the most popular package manager for JavaScript and we're growing fast. We need to make our eponymous command-line client more flexible, more reliable, and capable of supporting the ever-growing set of use-cases people are finding for it.

You will be working full-time on the client itself, entirely on open-source components and tooling, and your work will be used by millions of JavaScript developers every day.

We are not a typical early stage startup. We believe that working sensible hours and taking care of ourselves and our loved ones is the best way to ensure long-term productivity. We care deeply about making tech a more inclusive and diverse place.

We are accepting remote applicants for this position, but we are not currently able to sponsor work visas.

npm by default uses HTTPS, and has for more than 3 years. It's a little confusing because the loglines all say "http" in green, but if you actually look at the URLs being downloaded they are all to https://registry.npmjs.org/

Front-end developer, npm, Oakland, CA: https://npmjs.org

We are the most popular package manager for Node.js and we're completely rebuilding and redesigning our website. We want somebody who cares a lot about CSS and HTML to join our team as our second full-time front-end developer, working with a world-class design firm to make our site more useful for the millions of JavaScript developers who visit it.

We are not a typical early stage startup. We believe that working sensible hours and taking care of ourselves and our loved ones is the best way to ensure long-term productivity. We care deeply about making tech a more inclusive and diverse place.

npm is an open-source project, including our website.

For more details, http://npmjs.com/jobs/

Yes, we had another 20 minutes of downtime 4 hours later, caused by our CDN accidentally re-instating their broken datacenter. The second outage is documented here: http://status.npmjs.org/incidents/jc65gc8tzk5v

I am pretty sure I can think of simpler ways to issue a fee-free license to a patent.

They have definitely left a lot of wiggle room and you'd be crazy to build stuff based on their patents without a licensing agreement, but I think this signals that they are very open to licensing their technology, and are not trying to "build a moat". This would be a lot more interesting if they were willing to state the terms on which they are willing to license the patents, but there are probably complex legal issues with saying so explicitly.

99.9% of requests to npm over the last 3 months have been hitting things other than couch. Binaries are being served directly from disk by nginx, and 99% of JSON GETs are served from our CDN's cache. Couch is still the source of truth, but we treat it much more like a database than an app these days, and it's been much more reliable that way. The only time you're really hitting couch directly these days is when you publish.

Almost none of our downtime since February (when we sorted out some bugs in our app that were affecting couch performance) is attributable to couch. Mostly it has been network-related problems at the caching layer, and the fixes we need to make involve making failover faster and more reliable, as failures are inevitable in any large distributed system.

Our sincere apologies for tonight's downtime. We're back up now after 30 incredibly frustrating minutes, but we're making changes to ensure this incident can't be repeated.

The root cause was a network failure at our CDN, Fastly. The incident was limited to a single Point of Presence (POP) in San Jose, so if you were in Europe or Asia you didn't see anything wrong, but obviously at this time of day most traffic is from the west coast.

While our uptime over the last few months has been pretty great, in the last week we've had two non-trivial incidents. That's unacceptable to our users, and to us, and we're not just sitting around hoping it doesn't happen again, but will be making fundamental architectural changes to eliminate the sources of failure we've seen.

It is possible for it to be simultaneously true that men are more frequently victims of violent crime, perform worse in standardized tests, and earn less than women[1] and also that women are more frequently the victims of sexual assault[2] and other forms of harassment, prevented from taking the careers of their choice[3], and subject to a greater degree of criticism in the media for the same actions[4].

The existence of things that are bad for men does mean that men have things harder than women. The fact that there are things we should fix for men does not mean we can ignore the things that are broken for women. This is not a zero-sum game, and it is not productive to determine who "has it worse". There are things that are bad for women that happen to women, and we should stop those things happening without questioning whether they are "deserving" of doing so.

[1] Though I have never seen any stats that back up this last assertion, ever.

[2] https://rainn.org/get-information/statistics/sexual-assault-...

[3] http://www.sciencedaily.com/releases/2013/10/131007151635.ht...

[4] http://thoughtcatalog.com/nico-lang/2013/03/how-we-criticize...

> As long as people care far more about the plight of women than the plight of men ... we're never going to achieve anything resembling equality.

I'm unclear on your thesis here: is your position that the reason women are disadvantaged in society in general and tech in particular because we "care more about the plight of women"? Because that seems illogical.

But the only other interpretation I can think of is that you think men are at a disadvantage to women, which is a laughable assertion.

Your account is 6 days old, of course, so I may be just feeding a troll here.

> I also thought it could be this particular company was fucked up, however talking to engineers from other companies revealed this phenomena is far from unique.

While it's by no means unique, that doesn't mean it's not fucked up. There are a lot of terribly-run companies out there. Misplaced loyalty keeps them alive longer than it should. You should quit whenever a company sucks; life's too short.

> People claim that startups work you hard, I personally don’t see it. From people I’ve talked to, I’d say 50 hour weeks are average. That’s about what you see in corporate America these days.

I think only in America would somebody say 50 hour weeks don't count as working you hard. Also, the average US working week is 35 hours, 37 in "information" industries:

http://www.bls.gov/news.release/empsit.t18.htm

The fact is that past 35 hours most people just aren't very productive, and a startup asking you to work 50 hours is going to get just as much "busy-looking" time as a corporate job asking you to do the same. Don't work at any job that expects you to work 50-60 hour weeks. Those companies are unhappy places.

If you are doing large-scale CSV parsing or encoding in Node, you may also find these two packages useful:

https://www.npmjs.org/package/binary-csv

https://www.npmjs.org/package/csv-write-stream

They are both written with handling very large files in mind, so they use buffers and streams for i/o.

The concept of a "primary" smartphone is a little strange to me. How common is it to have multiple active smartphones? (As opposed to, say, one for testing software, or an old one in the closet)

They're not necessarily a bad candidate, but I have a lot of resumes to scan and this metric works most of the time. I'm okay with getting it wrong sometimes.

I didn't intend this to be taken as a personal affront to people who don't use LinkedIn, so I should have used less inflammatory language. My apologies.

Like I said, I ignore Facebook for hiring purposes because I think the context is different. You're not expecting me to go looking at it, so I don't.

I'm not a lawyer, but as I understand the situation it's illegal to take certain types of information into account when making hiring decisions (e.g. race, gender, religion I think, sexuality in some states, etc.). It's not illegal to go looking for more information about a candidate, but if in the course of doing so you also find information in those protected categories, it would be illegal to use that information. The act of finding it out is not itself illegal. The morality of doing so on a network not intended for professional purposes -- like Facebook, say -- is questionable. I don't do that.

All that said, a LinkedIn profile specifically is obviously intended for public information, so finding it and reading it seems morally 100% okay in my book, and I do this all the time. I also google applicants to find their Github profiles if they haven't supplied them, and that seems fair to me too.