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

Left-pad as a service

left-pad.io

Post reply on HN
Print view View original

191–200 of 269 posts

Re: Left-pad as a service

#191

Post by pklausler »

BenoitP wrote: post #170
coryfklein wrote: post #151

Earlier quoted context omitted.

If you want to actually know the "why", I don't think any one person can answer for certain but I have noticed similar trends on HN and attribute it to the culture necessary among start-ups: brutally challenging assumptions and discovering failure points. I think that kind a culture is necessary in quickly shutting down projects that have a high likelihood of failure before too much time is invested in them. Unfortun…

> brutally challenging assumptions and discovering failure points Nicely phrased. I'd apply this to engineers in the general too. People can often speak of them (and me) as difficult; when this is really what is needed of people that make things happen. Especially on critical infrastructure. You can't really wing details on the integrity of the bridge you are building.

"Don't implement critical systems with tools that any idiot can use, because they'll show up."

Re: Left-pad as a service

#192

Post by gefh »

nogridbag wrote: post #169

I'm late to the left-pad discussion. I thought it was considered a bad practice to depend on an external repo as part of your build process. At my company we use Artefactory to host our maven libs. Even if one were removed maven central our builds would continue to work fine (in theory).

Terrible, terrible practice. But I think a lot of people got caught out as left pad was usually an indirect dependency, and using npmjs in your build is the quickest way to satisfy your dependency graph.

Re: Left-pad as a service

#194

Post by mikeash »

nogridbag wrote: post #169

I'm late to the left-pad discussion. I thought it was considered a bad practice to depend on an external repo as part of your build process. At my company we use Artefactory to host our maven libs. Even if one were removed maven central our builds would continue to work fine (in theory).

I'm always surprised at how common this is. You check out some repository, and it ends up having to fetch more stuff from all over creation. Whether it's just git submodules or some more sophisticated dependency manager, it seems like an obviously bad idea.

It's OK if they're pulling from other repositories you own, but requiring external repositories as part of the checkout process seems like an obvious point of failure. There's all sorts of possibilities for malicious activities, and just plain downtime will affect you too. Storage is cheap, so it seems like there ought to be no reason not to pull in external dependencies and save them locally. Dependency managers should support and encourage this rather than defaulting to just referencing some random stuff off in space.

Re: Left-pad as a service

#198

Post by d0m »

guelo wrote: post #165
andy_ppp wrote: post #8

Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. How stupid of people to reuse small often used functions that only do one thing well. How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM…

In most other languages you end up with a poor approximation of npm's micro-libraries via stackoverflow copy-paste. Actually thinking about it, an ideal solution would be a combination of stackoverflow and npm: all the solutions to a problem grouped together in one place with community votes and comments, and then you can subscribe to an answer from your code.

This is what npm/github is! Rather than having comments in one thread you have them spread in issues and pull request.

Re: Left-pad as a service

#199

Post by rkuykendall-com »

paulclinger wrote: post #180
jameshart wrote: post #36

Earlier quoted context omitted.

Best practice for performance for large left-pad jobs is to call the service recursively using mapreduce. Remember that left-pad(str,pad,n) is equal to left-pad(left-pad(str,pad,n/2),left-pad("",pad,n/2),n). This should run in logarithmic time and is highly parallelizable. If you don't like the "" magic string in there you could replace it with a call to left-pad(null, null,0).

You should be using emptystring.io instead of the "magic string" or a "null, null" hack.

Here you go: https://api.left-pad.io/?len=0

Re: Left-pad as a service

#200

Post by toyg »

mikeash wrote: post #194
nogridbag wrote: post #169

I'm late to the left-pad discussion. I thought it was considered a bad practice to depend on an external repo as part of your build process. At my company we use Artefactory to host our maven libs. Even if one were removed maven central our builds would continue to work fine (in theory).

I'm always surprised at how common this is. You check out some repository, and it ends up having to fetch more stuff from all over creation. Whether it's just git submodules or some more sophisticated dependency manager, it seems like an obviously bad idea. It's OK if they're pulling from other repositories you own, but requiring external repositories as part of the checkout process seems like an obvious point of fai…

The reason is maintenance. Once you set up yet-another-repo-mirror (after your apt, rpm, nuget, pypi etc mirrors), someone needs to keep it up, back it up, secure it, refresh the packages, etc etc.

It's "cloud culture": rely on some else's maintenance effort and just work on your own problems. Like all things, it has drawbacks.

Post reply on HN