jd

I'd say that contrarian anecdotes are good if -- for instance -- the discussion spawned by the anecdote leads to a better understanding of the subject at hand. However, because anecdotes are stories we tend to remember them vividly and they affect our judgment disproportionally. Human brains are very flawed, and it may very well be the case that the negative effect of contrarian anecdotes vastly outweighs the benefit we get from the discussion it spawns. I don't know the answer. But I do know that we can't state with certainty that "having a real discussion is a good thing".

As for how we should weigh new evidence, this is essentially a solved problem: use Bayes' rule. Suppose that 100 out of 100 studies indicate that smoking is a leading cause of cancer and a contrarian viewpoint ("My grandfather smoked his whole life and lived to 123!") indicates otherwise. Then that anecdotal viewpoint should get approximately 0 weight. Zero. Nip. Zilch. Nada.

We're all experts in a few subjects at best. In those subjects we can easily explore different viewpoints, balance different arguments and keep track of the different schools of thought. We can even confidently diverge from expert consensus if needed. But in most subjects we're enthusiastic laymen at best. I don't think debates and exploration of different viewpoints then lead to much greater understanding. Just look at any forum on the internet (including this one). Debates aplenty and the few knowledgeable people get drowned out in a sea of contrarian musings.

Expert consensus is just the aggregate opinion of those who have the best understanding. So when a layman disagrees with the experts he's almost certainly wrong. What I see is the opposite of consensus culture. I see a willingness to disagree with the experts before understanding the subject material in depth.

They use regular consumer grade HDDs on the cheaper servers, and enterprise grade on the slightly more expensive ones. For instance, their EX6 servers have 2x 3TB of high quality hard drives (€70/month) and their EX5 servers have 2x1.5TB consumer grade hard drives (€56/month).

For comparison see: http://www.hetzner.de/en/hosting/produktmatrix/rootserver-pr...

When people talk about "doing something" they typically mean "create something". The author didn't say "Find something you enjoy consuming. Consume it. Over and over again.". Gaming, reading, watching the news, that's all consumption. Good only in moderation.

There are plenty of people who create stuff of value around popular games, and make a living out of it.

Interesting. Thanks for the link.

Nobody advocates running barefoot on asphalt. And yes, running can wear out your joints, but even if you wear running shoes.

Although there are certainly some entrepreneurs who do everything in anticipation of a big reward in the end, this isn't true for me or for any of the entrepreneurs I know.

It's the work itself that's rewarding. It's creating something from nothing that's rewarding. It's having happy users and customers that's rewarding.

The "reward of a distant payoff" theory outlined in the blogpost indeed only explains serial entrepreneurs, not why people start companies in the first place. But this is strange. We have no concepts like "serial painter" or "serial poet". We think it's only natural that people who feel compelled to paint still feel compelled to paint 5 years or a decade later, and it's the same for nearly any other endeavor. Entrepreneurship isn't different, and I can't think of any reason why we would expect it to be.

So when successful entrepreneurs choose not to try again I expect this to be for other mundane reasons: wanting to spend more time with the family, to catch up on stuff they missed out on, to travel, or to pursue other dreams.

Although you certainly have a point I think your judgement is a bit too harsh, and the the logic "it was copied in 12 hours [therefore] it sucks" just doesn't follow.

I didn't see my option on the list. My dislike for the abomination that makefiles are made of knows no bounds. Most of the languages above I can avoid (I simply don't use the languages I don't like), but I curse every time I have to open a makefile, because I know how painful it's going to be.

(makefiles are turing complete, so I think it qualifies as a programming language)

It's a great release, but bulk_insert is really really dangerous because it apparently doesn't call the save() method nor the pre_save or post_save signals.

I don't like this because a lot of us put validation logic in Model#save and use the signals to trigger the search indexer, and so forth. This behavior is definitely going to catch some people off guard and it's bound to lead to serious bugs.

I understand why they don't call Model#save for every object, but I think they should have introduced something like Model#validate which is called before every save (including the new bulk inserts) so you still get a place to put custom validation logic that you know will get called the moment something is placed in the database. So now inserts are faster but at the expense of correctness. I'm not convinced that's a good trade off.

Oh, and for some reason bulk updates are completely missing, even though it seems natural to add bulk_insert and bulk_update at the same time.

And the cool thing is that a smartphone now serves the function of all of these gadgets. It's a music player, video player, camcorder, digital camera, answering machine, and so on. Internet TV replaces the need for satellite TV and a cellphone camera + email replaces the need for a FAX machine. It's astonishing how few appliances you need aside from a smartphone.

Not to mention that they still serve obnoxious ads when you have a subscription.

This is a really well written response by Mike, but frankly I'm not convinced. Not in the least. And to accuse Ira Glass of unfair editing (with the dead silences and all) really takes the cake. I think Ira gave Mike every opportunity to come clean, and he didn't. Only when directly confronted with facts contrary to the story did he shift his position, and then only so slightly as to keep his main story intact.

As far as I can tell Mike is only sorry he got caught.

Nope. Some people downvoted because your assumption that people know the positions of their representatives is wrong.

The average person on the street is has a level of understanding that's closer to "Keep the government out of my medicare!!". People typically don't know the names of their representatives, the policies they stand for and the impact those policies are going to have in practice. They have to know all of those things in order to understand the meaning of "Don't mess with the internet".

The problem with this strategy is that people can create boxes filled with votes in advance. Add/remove/swap boxes to shift the election in your favor.

Also when there are reports of voter fraud it's really difficult to figure out who cheated and in which regions/districts. You can't tell by the ballots (pieces of paper) if they got there legitimately.

Electronic voting, if done right, should be a lot safer than a paper ballot system.

I think that for voting to work well it has to be completely anonymous. So you can vote the way you want and nobody can prove you voted for the wrong guy.

Otherwise your Friendly Neighborhood Thug can drop by the day before the election and kindly ask everybody to vote B. He'll come back the day after the election to check the receipts and punish those who didn't vote the right way.

Writing an unpolished programming language isn't that much work in comparison to writing a complex virus. Especially low level languages where instructions map pretty closely to the CPU instructions are easy to create.

I think it makes a lot of sense to write a custom programming language/compiler because virus scanners tend to use fingerprints to recognize dangerous pieces of code. So you want a compiler that deliberately obfuscates the code it writes and also outputs instructions in such a way that it avoids triggering known virus scanner fingerprints.

Of course there can be unforeseen complications, but those are the exception rather than the rule. You can also have complications when you bring your car to the mechanic. Still we want to know what a typical oil refill is going to cost, and if it's going to be more expensive than expected we'd like to know what the damage is going to be so we can make an informed decision.

I don't buy that we can't handle the truth and need to be shielded from the pricing and costs structure of medical procedures. Especially because most medical procedures are purely routine matters and the hospital can just publish the average cost of those procedures. You'll then at least get a rough impression of what the price is going to be and you'll be able to compare hospitals based on that.

I don't think it's obvious at all. Because the question of how to make money was implicit in the mind of Satish:

(1) build beta version and get some users, (2) improve product based on user feedback, (3) charge money for the product, (4) watch revenues increase

It sounds so simple. It's essentially the 37signals way, right? Build a product. Charge for it. It's so simple -- how can you possibly mess that up? And yet, the model above is simple, intuitive and wrong.

I think one of the key insights here is that you can have two groups of people who use your product: those who are enthusiastic about your product, give feedback and report bugs, and those people who are actually willing to pay for your product. In an ideal world those two groups overlap and it's easy to make money. What's often the case is that the two groups don't overlap very much, and if you listen to the wrong people you end up making a product that appeals perfectly to those people who have no intention of ever becoming paying customers.

It took me years to really learn this lesson, even though it was completely obvious in retrospect. In order to make a better product I should be talking primarily to my best customers (those who have subscribed to the bigger plans for an extended period of time), because the goal is to find more people like them and to keep 'em happy. If I listen primarily to the most vocal users the implicit assumption is that the most vocal users also happen to be the best (potential) customers. And that's a huge assumption that in my case turned out to be false.

People are so grossed out by a doorknob they refuse to touch it, only to immediately walk to their desk to type on their keyboard. A keyboard which is typically far dirtier than the bathroom they just avoided touching[1]. Oh, the irony.

[1] http://abcnews.go.com/Health/Germs/story?id=4774746&page...

I read the original post. $40.000 is roughly 1/3rd of the original cost of purchase. So it's completely reasonable. If you can't afford that you have no business buying a first-generation $100.000 toy.

As far as I know Tesla strongly recommends owners buy a charging station for their home and plug in their Roadsters every night.

I'm not going to point out how Tesla car batteries have to follow the laws of physics. Other people did that already.

Tesla cars aren't mass market products (yet). They're for early adopters who can afford what is essentially a $100.000+ toy. If you then don't read the manual and leave the car on a parking lot for months, then yes, you can ruin the battery.

So let's compare it to other early adopter technology. It took decades before motherboards didn't occasionally die during a BIOS update. For decades stereo equipment (and other expensive electronics) had a little slider on the back of the power supply labeled "110v - 220v". It wasn't always in the right position when you bought the device. If you forgot to switch it to the correct setting the device breaks, simple as that. Expensive cameras that you couldn't clean on the inside -- take them to the beach once and they're ruined forever. Cars with breaks that would fade so quickly that driving down a mountain became tantamount to suicide. Or how about power tools? They don't come with any manual and if you use them in the wrong condition you risk severe injury. Forget to turn off the stove before you leave for holiday? Your house might burn down.

So let's not lose perspective here. If you forget to plug in your Roadster before you go on holiday, in the absolute worst case scenario you have to replace the battery. Not the end of the world. As with any other piece of equipment, you can break it if you're sufficiently careless.

When you have a persistent page (that you update with HTML5 push-state) you suddenly have to worry about issues like memory fragmentation. If you do lots of small updates to build a page from a template + JSON every time the user navigates it's easy to hit some situation where everything starts lagging for no clear reason.

If you simply swap out a large part of the page with some HTML right out of an Ajax request you don't have to worry about any of that.

> Var is broken in js because it does not obey sensible semantics

Scoping is broken in pretty much all modern dynamic languages.

Take Ruby for example:

    i = 10
    [1, 2, 3].map{|i| i * 3}
    [1, 2, 3].map{|j| j * 3}
    puts i # prints 3
    puts j # raises undefined local variable

Or let's look at Python:

    def maybe_append(b=[], n = None):
        if not n is None: b.append(n)
        return b
    print maybe_append(n=20) # prints [20]
    print maybe_append(n=30) # prints [20, 30]

So there's only a single instance of [], so that the default argument "grows" over time.

I'm guessing that the "early spike" can't reach more than 20% of their total audience. So if they don't smash the Kickstarter record and reach 5 million I'll be amazed. Even 10 million is completely reasonable.

That's clever. You can then even improve the algorithm by only sending the hash of A:B for every phone number, where A < B (numerically). Then you don't have to worry about whether it's Friend:Local or Local:Friend.

Not that small. It's comparable to a weak password. There are about 5 billion active phone numbers in the world [1].

Besides, a small search space can only be searched quickly if it takes little time to a hash a phone number. Doing a few billion MD5-sums is not so difficult. If the hashes are computed with an expensive bcrypt then it's just a matter of increasing the number of iterations to make brute force attacks unfeasible.

Edit: I realize that the hashes can't be salted (because different phones must produce the same hashes for the same phone numbers), so a rainbow table can be created for the entire database.

[1] http://www.cbsnews.com/stories/2010/02/15/business/main62097...

What I really like about the old style bind/live/delegate is that it's so grep-able. The new on()-based API makes it much harder to search through a codebase.

In addition, when you see something like:

    $('.table a').click(function() { ... } )

it immediately looks wrong, because there are probably multiple links in the table. Wrong code that looks wrong is great, because you can then refactor it as you come across it. But now you have to check if a second selector argument is passed to "on", to see if unnecessary event handlers are created.

As far I know the only thing that works reliably is to get multiple IPs and multiple (wildcard) SSL certificates. You can try to save a little money by getting startssl certificates (free) or by using SSL host headers (multiple SSL on one IP address), but it doesn't work on all browsers so you end up wasting time explaining to your customers why they get an error when they access their site.

- Google Docs + Wiki is a pretty good description. The wiki part speaks for itself, but there are also many cases where people (ab)use excel as ad hoc database. We want to get Papyrs to the point where it can be used for that kind of informal/ad-hoc database and form use.

- Good point about the slideshow. We're thinking we should replace it with a screencast.

- I suppose it depends on the way your company is organized. We're only a 2 man company and we already need something like Papyrs to keep track of different documents (tax regulation info, receipts, brainstorming sketches, etc). With some documents we want to know when they're updated (email notification) with some we don't. Full text search. Versioning. The ability to add notes and ideas to the side of a document. Checklists are huge (when you suddenly have to fix an email or mysql server in the middle of the night it a checklist is absolutely necessary). We've haven't found any product that would solve these problems for us, hence Papyrs.

Feedback appreciated!

Thanks for the feedback!

The guys at 37signals make great products, but they tend to be on the minimalistic side. We have features such as permissions (it turns out people really care about that), a widget system, and with Papyrs you can create forms.

Of course there is a lot of cool stuff we really want to add, but for our first version we have to limit ourselves to the core functionality and that's almost by definition going to overlap with the competition.

I increased the slider speed and I changed the layout slightly to avoid the scroll down problem you described.

Again. thanks for the feedback!