ajsharp

lol "increase production flexibility" that's some top-notch corporate-speak.

fuck yea

> You can think of 𝚫 now as a CDN for dynamic code (microservices and backends).

Mmmmmmmmmmmmmm not a CDN.

If you're a startup, and you (the founders) have any sense at all, you will screen out candidates from "top 10" schools. As a startup, you have absolutely no business competing with Google / Facebook / et al engineering talent. This isn't even approaching anything like moneyball, it's just common sense. The idea that where someone went to school makes two shits of a difference in job performance is ridiculous. Job performance in technology is mostly about a collection of other soft skills in addition to grades and technical ability (communication, willingness / ability to learn new technologies, ability to work in quickly adapting work environments, etc).

Ah, of course, a flowchart! The CLASSIC path to understanding a library.

Unfortunately, none of this is surprising. Soundcloud has no real revenue model due to a seemingly inability to court rights-holders, and the product is mediocre at best. Soundcloud provided an outlet for the indie and electronic music communities to share and consume music early on, and that has more or less remained their bread and butter to this day. Even if they were charging end-users for access, the viability of it is as a competitor to Spotify and Apple music, at the prevailing market price-point ($10 / month) is slim. Ultimately Soundcloud is a niche product competing against broad market products with no real path to revenue other than somehow bringing mainstream music onboard. And it seems pretty clear that mainstream music isn't interested in collaborating with Soundcloud.

The open animation is way too slow. Not great UX.

Sucks to be in the cert market today. This is great news for everyone else though!

Fooled me ;)

I get that these are super frustrating issues for these people (cough guys) that maintain these repos, but there's something telling about it that it's all JS people. That last cute lil paragraph really sums it up for me:

> Hopefully none of these are a surprise to you as we’ve told you them before. We’ve waited years now for progress on any of them. If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!

LOL. I can't tell if this is "go-fuck-yourself"-level passive aggression, or mindless hopefulness that there might actually be a universe in which Github (or a company like it, with hundreds of millions of dollars of venture funding) could be open source. If I worked at Github, my first thought after reading this would be "mmmmm yeeeeaaaaaaa y'can g'fuck yr'self", while the second thought would be "yea, you're not wrong". Generally, passive aggression gets you nowhere when you're asking for something from someone/something who owes you nothing (I know, I know, they "owe" their customers everything).

The Node/React/JS community is hilariously entitled, petulant and childish. The tone of this whole letter is so god damned millennial, it's mind-boggling, because they're not wrong about anything they're asking for. But it's how they ask for it that leaves a dry, acid-y taste in your mouth.

> Why has Github been complacent?

Management, money, growth.

I disagree that investors are the cause, though I appreciate the sentiment. Communities develop from leaders, and the only leader Node & Javascript has ever had was Ryan Dahl. From what I can tell, Ryan blindly applied unix principles to the server in a garbage language. I don't know why he thought that was a good idea; maybe he was just fuckin bored. That sentiment, that tiny is better, was like patient zero, and the frontend community with no leader of it's own, cargo-culted it to infinity.

These idiots literally invented a principle that people now refer to as "composibility". Really it means that your library is fucking tiny and does nothing.

The only form of leadership present in the frontend development community are large companies, like Facebook. So what happens is a developer who works for Facebook inherits Facebook's brand power within the community, and a bunch of junior developers who don't have a clue assume developer X is Uncle-fuckin Bob. Inmates running the asylum.

There is no pragmatic thought leadership in Javascript; only children looking for recognition and a podium at an O'Reilly conference.

Have you worked extensively in Javascript and other dynamic languages? In my experience, Javascript is at least 10x worse on nearly every major point he raises than anything else I've seen. The library creators don't have a fucking clue what they're doing, and blindly cargo-cult what the rest of the community is doing (example: micro-libraries). This happens a bit in ruby, but NOTHING on the scale that it happens in javascript.

You can just change that "using an AOL email...should preclude you..."

I agree, React is fairly simple to use on it's own, but the Flux pattern / framework is really where the complexity comes in, IMO. I refer to them together b/c you rarely see one without the other. My general feeling is, Flux seems like an excellent solution for some of the problems Facebook has -- their inbox for example, where you have multiple components on a page that need to react when external events happen (a message is sent, a message is received, etc). My feeling is that many would-be cargo-cult-ers don't have problems at this level of complexity. Most of them are doing basic CRUD operations, and using a needlessly complex framework to do it.

There are some great things going on in React / Flux, but the part that needs to be emphasized about Flux, that Facebook doesn't address explicitly anywhere, and that most people eager to always be on the cutting edge will never admit, is that this stuff was designed to solve problems for very complex applications. Complexity is relative, and the solutions that reduce complexity and friction in the development process for Facebook may increase it for another organization. That is to say, Flux / React et al is by no means simple. Not even a little bit. But it probably simplified a lot of things for the Facebook team. However, YMMV for your 6 person startup engineering team.

Really cool article. However, I found myself thinking, "ok, that's nice of you for not doxing the guy, but, you kinda just handed the keys to the kingdom to the internet." Doesn't seem like SLJ cares one way or another, but, I got the feeling that the author knows that this article will undoubtedly lead to SLJ's outing within a month, two months tops. There's more than enough bored programmers out there who'll just apply the methods described wholesale, and throw it out there on reddit, or wherever. So, I'm not sure how I feel about the whole "doing the right thing by not doxxing" issue, b/c it seems like we're sort of splitting hairs on the issue.

The problem with docker is that it's Yet Another Tool you have to learn how to install, configure and use. Once you grok what it's doing, how to install it, how to run it on OS X, etc, it's powerful, but being forced to learn a new tool to install another, is a bit of a yak shave, and quite frustrating.

Glad you posted this. They mentioned this incident in a segment they did on Last Week Tonight. The police are completely ill-equipped to deal with online harassment, even if they could determine the identity of the attacker, which they likely rarely can.

This story is almost exactly the plot of The Newsroom (HBO) episode from two weeks ago, where a mega-douchey tech entrepreneur (played brilliantly by BJ Novak) purchases ACN with the intent of turning the network into a crowdsourced, citizen-journalism "digital media company." The real-life story is hilariously similar.

> 1) It's unconstitutional, as a violation of due process, to suspend officers without pay, before they have been adjudicated as having done something wrong.

Nope, not unconstitutional, not even close. The constitution has literally nothing to say about suspending someone's ability to work due to arrests and legal proceedings, because it's not a set of guidelines for prosecution, it's a foundation for lawmakers and the judicial system by which to form and judge laws and crimes.

> 2) It's probably unconstitutional to impose forfeiture of vested interests as punishment for a crime.

Assets are frozen during criminal proceedings all the time. Ironically, especially for drug-related prosecutions (big ones, albeit, and for good reason).

> 4) Removing legal protections for police sounds lovely when you only consider situations like this one, but you forget that for every one instance of something like this, there are dozens of instances of actual bad guys filing meritless lawsuits.

TOTALLY. Luckily, we have the magical judicial system, which is built to handle cases, you know, individual instances where the law is either broken or does not provide enough clarity, and thus, case trial can help to narrow the meaning of laws. They can also award compensatory and punitive damages, which seem more than justified in this particular instance.

Solid, well-researched and comprehensive article. One small correction:

> Unicorn is built to cut off long running worker processes after a default of 30 seconds via SIGKILL. This is why Unicorn says it's built for "fast clients" - because anything beyond that cut-off is subject to termination.

This is not what "fast clients" refers to. Unicorn being built for fast clients means that it is only meant to serve local network clients. Or, in other words, it's not meant to communicate with end-user connections/clients directly (slow clients), rather, it's meant to run behind a proxy server like nginx or apache.

The "fast client" thing is basically saying, "this is an application server, not a web server", meaning, it's good at running application code, not managing the complexities of serving web requests to public internet (slow) clients. They're called slow clients because, well, they're slow ;) They have variable quality connections, bandwidth / transfer rates, and client capabilities (http 1.0 vs 1.1, 2.0, spdy, etc). Being a fast client means you can expect that you'll receive http requests at a relatively constant rate, basically whatever the local network or file system will allow, which is extremely fast (comparatively).

So, unicorn being a "fast client" just means that it's good at talking over local network connections (or, preferably, unix sockets) with a web server, and never on port 80 serving public http traffic.

Theoretically, the number of puma threads you're running should be the same as the number of unicorn processes. That is, equal to the number of available CPU cores on the machine. So, if you're running on a machine with 8 cores, you should run 8 process or threads.

What continues to be the major issue with anything thread-based in ruby is that to reliably reach desired performance at load in a threaded setup, you need to be running an interpreter than can make concurrent use of native system threads. MRI has a global interpreter lock, so two pieces of ruby code will not run at the same time. IO is not subject to the GIL, so a lot of what happens in a web app can run concurrently (DB calls, etc), but other things that all happen in ruby (routing, view rendering) cannot.

So, basically, to reliably achieve similar performance using threads, you need to be using Rubinius or JRuby, which don't have a GIL.

Cool. Yea, I really enjoyed the HBO show too (especially in the beginning, the writing tailed off a bit mid-season). The satire around "making the world a better place" was the first thing that jumped out at me and hooked me initially.

Zing!

I enjoyed your post. I have a couple of thoughts / suggestions for you.

I got the impression that the underlying motivation for writing the post, and tactic you used for justifying your positions was largely in response to what I would consider the overly myopic hacker news user base. That is, disproportionately white, male, curmudgeoney programmers. I sympathize with your frustration, but urge you not to let their world-view cloud yours, or cause you to search for complicated answers to simple questions.

An example of what I mean:

> I believe the current skepticism around Silicon Valley's "Make The World a Better Place" mentality is deeply rooted in historical anxiety about institutional capitalism.

On this point, I urge you to consider a much simpler explanation: that people are skeptical because there is much to be skeptical of. People like Musk are a rare breed in Silicon Valley. Today's tech "entrepreneur" rarely looks like Elon Musk, someone who genuinely seems to want to do good things for the world. The skeptisism exists because there are a lot of startups doing plain silly things, masked in global do-goodery marketing narrative.

Startups are the new gold rush, today's investment banking. But the west coast has much different cultural norms towards opulent wealth than does the east coast. Put simply, we like to hide it out here, they like to flaunt it out there. Thus, "we're making the world a better place" instead of something like The Wolf of Wall Street.

Still, I enjoyed your post and your choice of using macro-economic theory as a lens through which to view this. Thanks for writing.

Interesting point:

> At Tesla, however, we felt compelled to create patents out of concern that the big car companies would copy our technology and then use their massive manufacturing, sales and marketing power to overwhelm Tesla. We couldn’t have been more wrong. The unfortunate reality is the opposite: electric car programs (or programs for any vehicle that doesn’t burn hydrocarbons) at the major manufacturers are small to non-existent, constituting an average of far less than 1% of their total vehicle sales.

I read this as effectively saying that it's easy for them to take this step, relative to companies in other industries (Apple, Google, Amazon, et al) because none of Tesla's competitors even have the ability to make use of their technology. Makes me wonder if Musk would have done the same thing if Tesla were a software company.

Slack tho.

You clearly missed the point here.

While I may agree with the sentiment, this meta-piece is just as speculative (moreso, actually) than the original TC piece.