I sense a certain disdain from much of the HN community for introvert/extrovert pop theory. They're all too frequently reduced to meaningless buzzwords.
My general rule of thumb is that any thing which talks about a Big Five personality trait (like Extraversion, in this case) but does not cite any studies is not worth reading.
What are you trying to accomplish by following projects on github? Maybe they can make activity on projects more meaningful, like show you more activity if you're a committer or only big commits if the project is very active but you don't often click on activity items.
That's the point: it's very difficult to automatically determine what someone wants when they follow a project. Sometimes I only want to bookmark it because I know I'll find it useful in the future. Other times, I only care when a new stable version of it is released, with a changelog. When I'm a participant I want to see more details, like new issues or commits.
Instead, because of the lack of options, we're left with an unusable wall of notifications. Smaller projects get drowned out by larger ones, and it tells me every little detail of what is going on with every single project. I'm pretty sure I've never clicked on a single link from it in the past few years of using GitHub.
That's exactly how averages work if you're using the median value rather than the arithmetic mean. If the median age for an apple is 14 months, then you have the same chance of selecting an apple that is either older or younger than 14 months.
If I recall correctly, Scott Hanselman raised the Assembly analogy in a post linked from this thread: http://news.ycombinator.com/item?id=2783060 . While discussing the unreadable JavaScript behind Google+ and similarly large-scale sites, Erik Meijer said
"JavaScript is an assembly language. The JavaScript + HTML generated is like a .NET assembly. The browser can execute it, but no human should really care what's there."
JavaScript generated by CoffeeScript is very readable and thus does not exactly correspond to that concept of JS-as-Assembly.
You can, but one reason nginx isn't used as much is that it does not fully support HTTP 1.1.
As a result, for example, although it's possible, it's not trivial to proxy WebSocket connections, which are commonly used with node.js apps. Streaming uploads/downloads have similar challenges.
> does not fully support HTTP 1.1. As a result, for example, although it's possible, it's not trivial to proxy WebSocket connections
Non-sequitur. WebSocket protocol is not HTTP/1.1.
WebSocket does have HTTP-like handshake as a hack, but it does not give required behavior in spec-compliant HTTP/1.1 clients, e.g. RFC 2616 requires connection to be closed after Upgrade is sent. WebSockets needs it open. HTTP requires proxies seeing Connection:Upgrade to remove the Upgrade header. WebSocket clients require this header to be present.
So basically a fully HTTP/1.1 compliant proxy is unable to proxy WebSocket connections by design.
If you need only fast downstream communication, you can use Server-Sent Events though.
I wonder how many people who paraphrase Taylor's "Principles of Scientific Management" have carefully read it. Taylor exposes several insights that are antithetical to the commonly paraphrased version "Faster is better. More hours are better."
At least in the context of moving pig iron slabs, he observed that highly-qualified (for the job) and better-paid workers produced better results working fewer hours than less qualified workers working longer hours.
This point is perhaps better paraphrased as "better management, better workers, fewer hours, and higher pay produce measurable improvements in output."
I have. :) I was more using Taylorism as an example of the notion that he came at it from a physical standpoint: if someone goes to work at the metal factory, their mood has less impact on their productivity than we do at a small startup, because they can still leverage their physical training and muscle memory (if we're talking an extremely routine process). Certainly an over-simplification of his work, of course, but a decent enough allusion for a short introductory paragraph. :)
I find it hard to believe that you have read it, I have too. A common tactic of his was to reduce hours to increase total output - you are agreeing with him.
A great example of this is where he employed a foreman for the sole purpose of enforcing rest periods. Forcing the workers to rest for 56% of the day - resulting in a 4x increase of output.
