mcgwiz

This is an apples to oranges comparison. The article centers on (the author's idea of) the messaging that greater American society would like to impart on the archetypal Stanford student, who is upper-class, American, young, inexperienced, entitled, sheltered, and likely the recipient of perks that helped their admission. A message from greater German society to any specific German student archetype would obviously differ.

Even the comparison with MIT is arguably invalid, as elite tech university admissions are more objective and less discretionary, making the archetypal student less likely both to have an entitled mentality and to have received perks that helped their admission. Perhaps the author wouldn't have objected to the word "deserve" at an MIT convocation, nor at one in Germany.

One way or another, you have to achieve product-market fit.

"local maxima"? The commenter never said that progress was finished, and that nothing more should or could be done. He was merely describing it as better than the prior state, from a utilitarian perspective.

Relative to standards of living in America today, the situation described in the article is abhorrent. But social/cultural progress is not fast, direct, pretty, or easy. America struggled through many stages of oppressive, inhumane periods. Even today's society may be described by future generations as barbaric (e.g. wage slavery, government surveillance, etc etc).

The problem for me is not technical per se, but that it adds another element of complexity to an already complex programming environment and has implications for human resourcing.

Becoming expert in a new language goes beyond learning syntax; one must also learn code conventions/style, compiler/transpiler quirks, runtime quirks, and library/framework ecosystem. In CoffeeScript the last two may be moot, but the first two remain. Additionally, to be an expert in a transpiled language, one must be an expert in the target language. It is much harder to find someone that has this knowledge and experience in both CoffeeScript and JavaScript.

This begs the question of each web dev team: if you are already experts in JavaScript, is the value-add from the transpiled language worth the cost of increased solution complexity/cognitive load, and smaller talent pool? My take is that CoffeeScript doesn't meet that bar for most teams.

For individual projects, or isolated one-off tools, these non-technical issues are moot. Also, server-side may be less of an issue since complexity is reduced by not having to write for multiple runtimes (only Node.js and usually without DOM).

Cheers. And didn't mean to trigger a pet peeve, I was just continuing the example. The point was more "even when you put SSDs under an RDBMS, it's still an RDBMS".

Yeah, memory-mapped files and journaling are standard OS primitives. I would say auto-sharding, replication, indexing, and complex schema-less querying are not.

In my experience, MongoDB arrived with NoSQL/BigTable to fill a different set of needs than RDBMS's. Relational databases are great but not all applications need full ACID or transactions. Sometimes applications require greater data modeling flexibility. Other times, pain-free scaling/distribution are important.

MySQL is great when those features are required, but even when you put SSDs under MySQL, it's still MySQL.

Yes, I agree. But regarding my comment, the use case was caching with persistence. Redis has some persistence options (pure snapshot or pure journal), but they just aren't its primary use case and aren't nearly as mature or performant as MongoDB's memory-mapped filing. Also Redis is key-value so requires manual indexing, i.e. much more up-front developer effort.

Memcached doesn't have persistence.

Sorry, I guess, that you haven't heard of teams caching denormalized data in MongoDB...

MongoDB uses memory-mapped files across all available memory to manage data, it sacrifices ACID for speed, and its capped collections sacrifice undefined size for more speed. Its client drivers originally defaulted to fire-and-forget semantics, emphasizing its performance-oriented design. Such performance orientation is suitable for cache or cache-like needs. The general point is that its place in a system is different than that of the typical "database", whether it's SQL/RDBMS, ACID-compliant, or even document.

I'm fully aware of the MongoDB's trough of disillusionment status in the community hype cycle. 10gen brought this on by setting unrealistic expectations early on, through poor documentation and marketing. Calling it a database, a term laden in the mind of the professional developer with expectations of ACID compliance and proprietary languages, was a shortcut that ignored its atypical performance-first roots, and all of the trade-offs that followed from that. I've read more comments from people with a lack or faulty understanding of MongoDB to surmise that it's stalled in the trough because the name confuses developers. "In-memory cache with persistence" is a also shortcut, but one that is a little more circuitous and strikes a better balance.

I'm confused. You do realize that MongoDB uses memory mapped files for managing and interacting with all data...

No one's arguing that disk paging is high-performance. In fact, MongoDB themselves explicitly recommend that you keep your working set size below physical memory size.

MongoDB is not a particularly good database. But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche. It's a small change in perspective (that is betrayed by their marketing) but has a huge impact on expectations, use and value.

I would have named it something like MongoCache.

I totally agree. But I like the cave idea so I would prefer caves along the perimeter of the floor. (Though you might not call them caves anymore.)

At the same time I've known (more?) programmers that prefer the dark. And I also know programmers that prefer a constant buzz of activity in the background (e.g. leading them to coffee shops). I fall into this category on some days. So my dream office would have dark caves, light caves, and some open plan. I'd have a home desk, but there'd be enough surplus that I could visit any other area if the mood suits me.

I wouldn't necessarily elevate an expectation of visual and behaviorial consistency to "theory". I have learned that a chair can hold my body weight. When I rest my body on an object that resembles a chair and that I've never encountered, I expect to be able to rest my body on it. This is the foundation of design, industrial or interactive.

We're not debating the outer contours and nuances of this idea. The article presents a cut-and-dry analysis of basic application of it.

You put far too much stock in your own experience and comfort exploring a tablet UI, and yet you seem to hold yourself as more representative as a "real user" than the author. I disagree. I've witnessed people in my personal and professional life get basic things wrong. What you perceive as a button, a data grid, a message window, they often perceive as an indiscriminate arrangement of text, lines, and color. Which is why I think the author's analysis, in those terms, is worthwhile.

Heuristically, anytime you're doing I/O (network or filesystem) could be an opportunity to increase concurrency with async/await. By using asynchrnous I/O and trickling that asynchronocity all the way up to ASP.NET, you make much more efficient use of the ThreadPool and allow more requests to be served. That's because you are recouping cycles otherwise lost on blocking.

This isn't the only way to increase concurrency. Obviously you can grow your IIS web farm as well. But async/await (or some other .NET asynchronous programming pattern[1]) is a one-time .NET development cost as opposed to a recurring infrastructure/hosting cost.

[1] http://msdn.microsoft.com/en-us/library/jj152938.aspx

Agreed. But why are things the way they are and how do we progress from there?

In my experience, a lot of the difficulty in comprehending/accepting that women experience the industry so differently than men is that many men either A) over-generalize from an exceptional interaction, or B) follow those that have over-generalized. By "A" I mean that men can rely on confirmation bias to cement their impression of the female experience based on a few choice interactions. For example, confirmation bias can allow a random chat with a well-adjusted, confident woman who appears impervious to tech sexism can dispel for many years any notion in that man's mind that sexism exists in the industry. Thereafter, contradictory signals of other women can themselves be dismissed as exceptions, and because of cognitive dissonance, can actually reinforce his misconception.

By "B" I mean that many men have no relevant direct interactions with women (given their low numbers) and may follow the lead of the people with whom they associate, who are by definition men. Any confirmation bias of those men then spreads to them.

In addressing this, what is not often recognized is that individual women do have unique experiences. They are affected to varying degrees and in various ways by prejudism and ostracization. As a male, rather than tip-toe around or ignore the issue with a female colleague, I've found the best hueristic for recognizing your potential participation in a prejudicial environment is to earnestly sense/inquire the nature of her past experience. (You may also share your own experiences of prejudism, if any.) By opening such a dialogue, you establish a common foundation and framework for maximizing the team and progressing the industry.

IMHO, focusing on the direct, open, and individual treatment of interpersonal relationships (and moving away from the one-experience-fits-all mentality, which lacks common sense and is susceptible to confirmation bias) is an important next step for evolving relations between social groups in general.

Can Web of Trust/PGP be applied/adapted to client-server communication such as that handled by HTTP? Conceptually, HTTPS built on PGP? Would new products or services help the adoption of this (like a social network for PGP keys)?

Although it wouldn't solve all of the NSA techniques (social engineering, acquiring pre-encrypted data) it would certainly be harder to track down (i.e. steal, crack, coerce, subpoena, etc) tens of millions of keys rather than tens of thousands.

Websites differ in their basic nature, and one size does not fit all. Roughly speaking, websites that are document-like (primarily consumption-oriented) should probably be progressively enhanced; websites that are tool-like probably should not (interaction oriented, like gmail, analytics apps, other saas). Websites that fall in the middle will have to carefully consider the user experience benefits and the available technical/operational resources.

The upside is that progressive enhancement can refer to a spectrum of techniques. Deliver only above-the-fold content as HTML, inline your CSS/JS, inline the initial JSON data, omit <form> POST support, etc. Two templating systems do not need to be supported. It's a straightforward technical problem to apply JS templates server-side (and I'm speaking as a boring old .NET developer--Nustache and Edge.js come to mind).

Btw, another benefit of progressive enhancement can be SEO.

Pretty good stuff, but the second suggestion about mobile development should, at the least, be given a big asterisk if not removed entirely.

When differentiating content based on user-agent and including the "Vary: user-agent" header in responses, you are effectively disabling HTTP caching. Because of the huge number of user agent strings, neither the server's output cache nor any CDN/intermediary cache will be effective at reducing request processing load. This is a very poor trade-off, and typically unacceptable.

If you must serve dynamic content based on user agent, the third option on the cheat sheet is probably better: use rel=canonical with separate URLs per device class. On each request, the server would still sniff the device class from the user agent string, but if the sniffed class does not match the one designated by the URL, the server 302-redirects (temporarily) to the device-specific URL (else, it serves the appropriate HTML). This requires a little more programming effort, but is usually worth having both caching and SEO.

(I dislike URLs that essentially represent the same content to vary in domain or path, so I distinguish them with a simple "?lite" query parameter. It's also very nice to have the server take into account an override cookie when sniffing the device class, which the user can set through UI in the site header/footer.)

Far more interesting blog post by their CEO here:

http://www.mongodb.com/blog/post/whats-name

All sensationalism, little substance. Particularly regarding the topic of the link-baity title.

> "One such company, Lenddo, determines if you're friends on Facebook (FB) with someone who was late paying back a loan to Lenddo....

No explanation of the what the mechanism for collecting this is. Likely it's a matter of opting in to share your data through a Facebook app, an act whose culpability lies with the consumer.

> "Lenddo has about 250,000 members, but it only operates in the Philippines, Columbia and Mexico."

Um. Ok. Three sem-developed nations. It's journalistically incompetent not to explain what the relevance of those nations are to the operation of Lenddo, and why any of that is relevant to the American general public.

The only thing I learned from this was that CNN Money articles can be remarkably content-farmy and AOL-like, and HN readers can subdue their analytical spirit when it comes to piling on the criticism of an already-hated company (e.g. Facebook).

Makes sense, and I think most people understand this. That said, I think the name "the Sunday test" and the description "If this person were alone at the office on a Sunday..." is far from ideal.

(Off the top of my head, "the Drink test" with the description "If this person were alone at the bar/cafe on a Sunday..." is better.)

> we can hire lawyers, doctors, and surgeons on the back of a CV and an hour interview.

You can do that with programmers too. And depending on the type of work you are hiring for, this can be sufficient.

Menial product maintenance is suitable for one-hour interview hires. Routine legal and medical work likewise.

But some work is so demanding that it requires a team. Hiring for a team means recognizing group dynamics. Whether you're starting a new law firm, or hiring someone to join your surgical department, or building a development team that must be able to respond quickly and effectively to changes to a startups understanding of the landscape, you don't settle the hiring question on a one-hour interview.

Not all work is the same. Please refrain from acting as if it was.

Thank you for the reply.

According to your example about the night sky, a claim is merely an observation if everyone will make the same claim in response to the same evidence. This seems very porous and weak, but following that logic, I would argue that given evidence that "the brain generates our experience of self by merging information about our body from multiple sources, including the eyes, the skin, the ears, and even one’s internal organs" it does not obviously follow that by observing a visualization of your body and heart beat will cause one to experience the phenomena of dissociation with his body. Then it seems that claiming so and contriving repeated samples is scientific.

It seems to me, the point you're really driving at is that a claim must be couched in some systemic view. It must base itself on a collection of related reinforcing ideas and assumptions (and state as much), and refine or extend that system. These systems abstract irrelevant things. Neuroscientific work is not phrased in string theory. It builds on a system that includes physical assumptions. Should a theoretical physicist argue neuroscience is on shaky ground because we do not understand all the details of the underlying physics? Should a neuroscientist argue evolutionary anthropology is on shaky ground because we don't understand all the details of the underlying neuroscience?

To your broader point. The motives and actions of neither psychiatric pharma, nor society, nor academia even, do not invalidate the possibility that collections of reinforcing ideas and assumptions can explain human thought at some level of neuroscientific abstraction. For better or worse, Jung, Freud, etc have established such systems which can and have been subject to methodical examination and testing by others. That they have subsequently not held up does not mean that the possibility is invalid.

I think also that there's a tendency to conflate the physicality (non-qualiality) of phenomena and its ability to be subject to "scientific" methods. And yet entrepreneurs expand knowledge with this all the time, as they make predictions about customer behavior, statistically test, refine, extend... This might not be Los Alamos "science", but it's method is certainly "scientific".

Interesting. I haven't read the paper, but I took the "theory" to be: "when presented with a visualization of one's body, augmented with a signal pulsing synchronously with one's heartbeat, one's perception of self extends to include the visualization. This builds on the existing theory that the brain generates our experience of self by merging information about our body from multiple sources, including the eyes, the skin, the ears, and even one’s internal organs. Here we present statistically affirmative research."

Can this not be empirically tested? Can it not be falsified or generate consensus?

I would think it more direct to criticize theories like this for their qualial basis. Still, how is the statistical nature of a sufficiently large sample of humans providing qualial data different from that of a sufficiently large number of H20 molecules providing neutrino collision data?

I agree. Along with that I'd add that they've taken off because of their expert marriage of the concepts of social networking with open source development, to harness Metcalfe's Law. By providing such a good social experience, they've pulled all developers into the fold. Once there, they have their foot in the door (doors?) whenever it comes time for private SCM. It's a great strategy pulled off well.

That seems to be SF's existential problem. What's their strategy? Adware installers are certainly interesting, perhaps even "innovative", but seem to be a near-term monetization tactic that doesn't address the strategic problem of community stagnanation. What happens in the hypothetical situation when all the big projects die or leave (perhaps because they've become so successful they can now support their own infrastructure costs)?

Thanks for your reply. First off, you're right, cheers for resuscitating SF.

Not that it would by any means be easy, I was suggesting a conceptual re-think of SF to attract and enthrall new users/projects. However your response (and the refrain I hear from others) indicates a strategy of monetizing the big binary projects you already have. That's cool, and that's a market. But I would fear

- those projects being coaxed away by innovations from services in adjacent markets (GitHub using enterprise revenue to cover download costs), and

- those big binary projects eventually dying (as projects sometimes do), without replacement from new young projects (because they will prefer to start on GitHub and will then mature there).

Perhaps go after the conceptual strategy of "SF is where you go when you've grow out of GitHub".

Good luck.

Good write-up, thanks.

But this isn't a sustainable strategy. You're basically asserting SourceForge's unique selling point/competitive advantage is its ability to host files. You've got to be kidding.

GitHub has taken off like a rocket whose thrust show no signs of abating. SourceForge is going down the drain with a passiveness that shows no sign of abating--unless it is conceptually rethought, from the ground up. You know, does something new and innovative to address project needs from a contemporary point of view. Dice certainly doesn't seem to have an appetite for that kind of risk, just an appetite for the last drops of life sucked out of a dying carcass by throwing leeches on it.

Thanks for the pointer. Will dig in.

How about a demonstration of something of real-world significance?

- content negotiation (basic building block of hypermedia APIs),

- authentication (and ensure SSL is used when authenticated),

- most importantly, HTTP caching, where

-- unauthenticated users get cached content, authenticated users don't,

-- vary on representation negotiations (media type, encoding, and language),

-- cache is located on server and in browser.

In other words, take basic advantage of HTTP to improve security and performance. Taken together, the requirements listed above comprise a problem of only moderate complexity, and are fundamental to flexible, high performance web apps. Accomplishing it in ASP.NET MVC/Web API is painful and relies on the inconsistent, malfunctioning, horrifically designed ASP.NET response caching module.

Show me a framework that does the above and makes it reasonable to build hypermedia APIs, and you've got yourself a convert.

Ah, yes. The law. If someone breaks the law, they are punished. Justice is that simple.

Oh, wait, unless the laws happen to constrain the interrogation techniques used against detainees. Or if they prevent access to the private lives of American citizens. Or if they protect whistleblowers. Or if they get in the way of fighting terrorism in any other way.

But aside from that minor footnote of an afterthought, the law is the law, so we all need to just shut up and accept it.