skysight-inc/HackerNews huggingface dataset:
I'm starting to do things like this in Redis. For instance consider Redis Lists: POP and PUSH are O(1), also to get the first or last 10 items in constant time is possible with LRANGE, but what if the user is often accessing a "far" range in a very long list? A similar problem happens to ZRANGE and Sorted Sets.

Ok this problems allows to apply some access-pattern based optimization solution. For instance the linked list will have an associated N-elements circular buffer with pointers to far elements, so you can jump to the N-th node if it's on the (small) circular buffer and the clients continue to ask for an "LRANGE mylist 1000000 1000010".

This is probably just the start but in general a small cache of "nodes" to recently very used places of data structures is a promising strategy in order to turn otherwise O(N) access patterns in constant time when they are very frequent.
Because price is a filter; the more restrictive the filter, the more valuable your product actually is to your customer, and therefore the less likely they are to squander the relationship.
Pinker's core point is that Gladwell is a shallow dilletante that writes well, but makes profound conclusions based on this basic dabbling.

Gladwell does nothing but make one of Pinker's specific challenges appear much shakier (and yes, I'm going to be stereotypical here and guess that Pinker probably is much less comfortable with Football than Gladwell). If I hadn't ever heard of Pinker before, this would do something to my trust in his argument.

However, knowing Pinker's track record and background, Gladwell's "rebuttal" seems a frail attempt that tries to hit at the one weak point he found. Really? Nothing more substantial to refute?
Going evented with Node.js - Naked JavaScript
Ipage Uptime & Ipage Review for October 2009
Ipage uptime by IpageReview.org for October 2009: 98.992% over the Internet
My wife's uncle Brian used to do it. Perhaps it's a cultural thing, prevalent in one group, absent in most or all others.

I, too, was surprised when I learned of it, but it's possible that the cheap wood used for set construction is amenable to the technique. I may now have to go and try it for myself.

Regarding evidence on the 'net, I wouldn't be surprised to learn that set builders don't often blog about the precise methods they use in building sets, so evidence is likely hard to come by.

However, my evidence is weak, and not first hand, so perhaps the story has changed in the telling. Even if true it's likely only to be in limited circumstances, but even so. Sometimes something someone is doing appears obviously wrong. Sometimes it isn't, even if usually it is. Your original point stands, even if there's a minor exception to the parable.
Oh thanks.. now I've just placed an order I didn't want. Don't click. It orders food.
Well there are many ways to add durability to an in-memory DB. For instance Redis 1.1 is supporting three of this ways with different degrees of safety VS performances.

1 - snapshotting) This uses the idea that after a fork() the OS uses copy-on-write semantics. So Redis forks() and dumps a very compact snapshot of the data in RAM on disk. This snapshot is also used in master-slave replication for the initial synchronization. You can configure different save-points, for instance save when there are at least 100 changes and 60 seconds elapsed, and so forth.

2 - append only journal) In this mode Redis just append every command that modified the DB into a file, in order to later reload the log to rebuild the status of the DB. This is much more durable. This days I'm coding a command that is able to rebuild the log in background in order to avoid to end with a huge log. The rebuilding process is fully non-blocking as it uses the same trick of the background snapshotting, that is, copy-on-write of fork. So basically Redis forks and starts to rebuild the append-only log on a different file. The parent process continues to log to the old file and accumulates all the new differences in RAM. When the child finished the rebuild, the parent adds all the new logs at the end of the file and atomically rename(2) the new log to the old one.

3 - master-slave replication.
Should this company receive an award for Accidentally Honest Disclosure?
The link is pointing to an image. This is the actual link

https://www.grubhub.com/
can you explain ? both try to minimize the number of tcp connection and thus avoid the slow start at every http requests.

spdy got the advantages of being a dropped in solution, aka you push the layer in the browser, and in the server. But no change in the website itself.

"resource packages" requires changes in the browser and at web site level.
Well whaddyaknow, I have a guy at my door with a vat of falafel. It's quick; I'll give it that.
Big productions: Why 'Fail Early, Fail Often' Is The Wrong Approach
Rotor is not open source. It uses a shared source license which would taint me, making it impossible for me to work safely on any other .NET implementation.
German court rules tell-a-friend functionality to be spam (in German)
I thought this was interesting, although limited to Germany: a court has ruled against a company offering a "tell a friend" button. They had implemented the tell a friend functionality so that people could enter other people's email address, but then a "x wants to tell you how great we are" mail was send from the companies account.

It would have been less likely to be rules as spam if the recommendation mail had been sent from the recommending persons account. Also apparently there should not be incentives to enter as many email addresses as possible (like "invite a friend and you get 10% off your next purchase"). All in all the "tell-a-friend" functionality seems to be a gray area according to that court.
I thought this was interesting, although limited to Germany: a court has ruled against a company offering a "tell a friend" button. They had implemented the tell a friend functionality so that people could enter other people's email address, but then a "x wants to tell you how great we are" mail was send from the companies account.

It would have been less likely to be ruled as spam if the recommendation mail had been sent from the recommending person's account. Also apparently there should not be incentives to enter as many email addresses as possible (like "invite a friend and you get 10% off your next purchase"). All in all the "tell-a-friend" functionality seems to be a gray area according to that court.
> * Distributed File System (all data public, private data gets encrypted)

> * Sandboxed Map Reduce

> * Public keys as account identifiers

Yes, my initial thoughts are almost exactly the same. I'm beginning to think it's a common idea. This bodes well :)
"Open source" doesn't have much to do with it :)

More substantially, "platform" usually implies centralization, even if your platform can federate. It's probably more useful to envision a radical solution (<i>to the root</i>), and start thinking about how to get there.
Situs resmi pesantren raudlotut tolabah
Situs Resmi Pesantren Raudlotut Tolabah
I never said you couldn't have a TV that allows general-purpose access to the web. But also having TVs that are "just" TVs gives you more options, not fewer. Devices can integrate, but the future is not one kind of device that does everything (e.g. a phone that is also a TV that is also a toaster that is also a book reader that is also a game console); it's an infinite variety of devices that represent the power set of all possible device synergies.
In my previous company, as it was reaching the end of its life (I was becoming burned out on the idea and the business) I made dramatic price changes over the span of a couple of years. I increased the prices by about 50% every six months, and made minor tweaks to the model lineup to make them more profitable even without the price changes. The result was generally happier, but more demanding, customers. As tptacek mentioned, it was a filter...we got a different kind of customer with the price changes. They were less educated about our products, Linux, and technology in general, but were more enthusiastic about the benefits we provided for them, especially our unlimited technical support. We also made more money; sales volume didn't decline remarkably, but the revenue per unit sold went up. Nonetheless, the hours I had to put in to support those units increased. If I had kept that business running I would have needed to raise prices even more or stop offering unlimited support (making support a paid for option has always seemed somehow wrong, to me, but it works for many enterprise companies).

With Virtualmin, we started out charging 50% the price we knew (and everybody else also knew; it was listed as being "on sale") we would eventually charge. I did find that the number of customers demanding even lower prices dropped to almost nothing when the 50% off discount ended. Those customers simply weren't in our market segment, and went back to second-tier products that cost dramatically less and offer dramatically less capability. And, I suspect, but don't know for sure, that cPanel and Plesk customers became more likely to migrate to Virtualmin after the price increase. But, I believe that has more to do with perception of value in an existing market with existing price expectations, rather than any particular price point.

Anyway, I believe the rule of thumb is roughly true. Cheaper products certainly attract a buyer that has weaker loyalties (as soon as they find a better price, they're gone). They probably are also more demanding.

We have a range of prices from $138 to $998, and I would wager that the $138 buyers are at least twice as likely to ask for support as the $998 buyers. I don't know how to make that more fair for us or the $998 buyer, however, since the pricing is based on usage, and a natural result of using the product more is being more familiar.

The point of all this rambling is that I don't think there are any hard and fast rules, but I do think charging more is worth an experiment for most companies. You can always revert your prices (and refund the "suckers" who bought at the higher prices) if things go badly. At worst, you'll learn that lower prices were a better position for you.
Also, people who are able to pay more are generally more likely to be mature and good communicators.

This is also a well known phenomenon in the web hosting industry.
"Developer evangelism is marketing, not development. "

I agree. I am just surprised such "marketing" is successful in influencing developers. Maybe I have an (erroneous) image of developers as essentially rational people who are somewhat immune to such empty "buzz" as Mr Dodge seems to put out.
The naive implementation of this ruins all the elegance of caching which is very important in modern websites. You end up choosing between getting all the common elements shoved down the wire at you every time or invariably having to go back for the few images unique to the page that you missed.

We're in the middle of a research projects right now where the server automatically constructs cache groups and does this properly. It was one of the things the guys working on spdy and us talked about, but they are taking a slightly different approach.

We'll see what happens, but this is the direction we want to move as well.
I can understand feeling down after being fired. I can't understand magically having opinions opposite to those you held when employed by your new employer's competitor. The flippant and unprofessional tone just exacerbates the problem.
Do speedy math in your head
It is, but I'm of the opinion that HTTP needs more than pragmatism to solve its woes at the moment.

The latency issue with the protocol is just immense and this takes a whack at a main issue, but doesn't quite get to where it should. One of the main drawbacks is you still have to wait for the first reply before you can request any associated content, which is bigger deal than it seems. The second drawback is it requires the website owner to do this by hand and invariably they'll bundle things in the wrong way, not account for differing network bandwidth types or simply not do it.

That said, for some very good reasons, this is good direction, so we'll see what happens.
>Which means you probably didn't look very hard.

Because I've only seen these two blog posts? I'm not sufficiently interested in Don Dodge to spend time researching him; and even if I were, a lifetime of washing oil off baby seals wouldn't change the issues I have with his blog post.

>Don was around YC around 2 years ago and while initially thinking the YC model was a joke, he changed his mind by observing. That's what you want isn't it? People think one thing, but change their minds after observing. Fluid thinking instead of fixed mindsets.

You can't honestly think that this blog post is the result of a reasonable change of mind after gaining new information. It's a complete and utter reversal of his stances on publicly available products he'd already used.
We trade everything, too. But no agreements are binding.
Because if you offer competitive deals, that opens you to market segments who purchase based on price. That often means they are lower income, meaning a lower hourly rate, meaning spending time haggling may be rational for them.

Also low income is correlated with low education/working class demographics, which have associations with being more demanding, rude, etc.

Your situation sounds like consulting/contract work so this is probably quite painful. But it's the right segment to target for mass market and volume products...
That's exactly the continuum I'm referring to.
A note with respect to the portions mentioning gaming: one of the ideas floating around recently in game design is a move away from the term "fun" towards the term "engagement." Why? Because "fun" implies a certain kind of candy-coated, theme-park image. It straight-jackets your views. "Engagement" can apply to all kinds of experiences - serious, practical, romantic, frivolous - so it allows a broader vision for the interactive medium.
Yes, Settlers is an old hat for people who living in or next to Germany. (It's not the new "Monopoly", yet, but comes close for some circles of gamers.)

Caylus is worth a look, too. For a medium-light and fun game, take a look at St. Petersburg. Tongiaki has very elegant game mechanisms (and you can do a nasty things to your fellow players).

If you are only playing with your spouse, Roma and Lost Cities are worth a look. The latter being a very nice gateway drug for non-gamers.

(I could talk all day about games.)
Very interesting, and a good lesson for startups.

Paraphrased: if price is your selling point, you're likely to attract customers who care only about price and tell you they want it even cheaper or they'll go somewhere else.

The infamous race to the bottom, which is a place where very few companies thrive.
Be sure to get a set with wooden figures (like the old German version). The plastic stuff is just not nice too look at and handle.
The Board Game Geeks generally prefer heavier games. That skews the rating somewhat, if you are looking for lighter stuff.
Slow light (1.5 m/s) rendering
Dominion is Magic The Gathering light. (I still enjoy it and bought a copy.)
I like Bohnanza, too. You can do some pretty fancy three or four-way trades, if you play the game mechanics right.

(If only we hadn't played it as often as we did, it would still hit the table.)
Keep your hands off his Microsoft shares Bill Gates.
WriteRoom is cool for sure. If you ever need to "upgrade" a bit, then i've personally found Ulysses to be the next logical step. It has a fullscreen mode akin to writeroom, but also supports semantic marking for later output generation + system for keeping track of related documents in a "project"

No affiliation, just like it.
Just play with a handicap of one meeple less (or something like that).
Sometimes the lists that he mention are really sets sometimes it is about linear order. I don't see how it can be so deep thought when it is not even precise.
I bought the Card Game before I bought the board game. That was back in 1997 when I was a cash-strapped pre-teenager. The card game went for 20 Deutsche Mark and the board game was 40 Deutsche Mark.

All in all I prefer the board game, since there's no use in trading in the card game, when you think about it. There's no use in cooperating in a two-player game, unless you have objectives other than winning.

Roma (http://www.boardgamegeek.com/boardgame/16496) is my preferred German-style two-player game at the moment. Though Lost Cities is also nice.
protip: replace with

<table with="35em">
I like the positive vibe I got from reading this. Nothing shockingly new but a good way to say be prepared for anything ("...will last 10 minutes. Or is it 15 minutes? Or 17 minutes?")
I added it to our compilation: http://delicious.com/outspokes/yc_interview
I agree completely. I noticed a while back that the order bar was a fake -- I especially love that it slows down and jerks around a bit for authenticity -- but what a great way to stave off hundreds of customer calls saying "I didn't get the confirmation email". This GIF tells them to wait a while, because real-world processes take time, without actually forcing them to sit in a browser with a spinning progress bar.
Worlds most resiliant tracking
6 Reasons Users Hate Your New Feature
Thanks, that was interesting and thoughtful, and I agree in general. However, in this case, I don't think it would be so bad to say something like, "Your order is in our system. We'll confirm that the restaurant got it correctly and email you in a couple minutes."

I think the most amusing part of this whole thing is that there's no way any user actually believes there are ~100 discrete steps to the order placement process, despite the high "progress resolution" of the progress bar.
In my experience (supporting 3 very different types of products with 3 very different companies), the amount of money a customer pays is somewhat inversely proportional to how demanding they are.

My guess is that companies that pay more for software also tend to hire people to manage and provide tier-1 support for the applications they use. They also tend to take more time making purchases and thus better understand the capabilities and limitations of the software.

That's not to say that large customers (or customers that have paid more money) can't be demanding, but they're usually more understanding and less likely to be unreasonable when they contact us, and have more reasonable expectations around resolution times.
Cost/Benefit.

Buying several TB of RAM is not cheap...
Do you have credit crunches as well?
"This call may be monitored to check for awesomeness" always makes me smile. It's the little things...
The old quipu X.500 directory originally used a similar approach (load to ram at startup, writes go to ram+disk, reads+searches come from ram).

You get durability and run-time performance, but there can be appreciable downtime during the startup phase.
You guys are hilarious! I guess my 1990s Geocities upbringing is showing itself.
all my favorite interviews involve the interviewee going on an interesting tangent.
Twenty seven seconds.

Twenty seven seconds is how long it took one of my customers to a) click from my site to Paypal (T = 0), b) authenticate with Paypal, c) authorize the transaction, d) return to my site, and e) email me asking me why they hadn't gotten their Registration Key yet despite the fact that promised it would be delivered "instantly". (T = 27)

They eventually got their Registration Key in 33 seconds (well, that was how long it took for them to click the link in it), and a few minutes later got it resent by me, along with an apology for taking so long. (The cause was the customer winning the race back to my website with Paypal's IPN trailing behind. It happens -- their bank took a few seconds longer to authorize it than usual, it fell into a verification queue, gremlins ate an HTTP packet, whatever.)

Now, I have a certain amount of luxury in dealing with customers with high expectations as to my availability, because I clear $30 on every order and if 10% of them want to chat, well, I can deal with getting paid $300 per email I write. However, if I were running a business which processed thousands of transactions a day, and I made about a buck an order prior to paying my CS staff, I would put a significant amount of effort into making sure that you didn't become an emergency for my CS team just because you had to wait twenty-seven seconds.
One-Way RPC using AMQP as transport and THRIFT for communication
So true - the other thing is it attracts more serious customers too.

My on-the-side consultancy initially was charging silly low rates to get some custom. It kinda worked but we ended up with demanding customers looking for a good deal at a low rate.

Now we feel established enough to raise rates the customers are a LOT better and the sites are rolling out a lot more smoothly all round!
The Pirate Bay Closing Their Torrent Tracker for Good
Yahoo Emali Id Hack in 2 min
If you took the venuses out it would be just as good.
"pray for it to last"

It could be interesting to discuss what circumstances might bring the 'source for truth' to an end ... what might be done to minimize the loss should it end ... how to route around the damage should the official internet be ended by someone afraid of the truth. It certainly is vulnerable to that ... but that doesn't mean it has to be.

Given the history of the world, the net may disappear and reappear several times. Before long, a large chunk of it will fit into a backpack ...

WRT 'not knowing before the Internet': you can have a trusted relationship with an author based on years of experience with his/her work. If everything they wrote checked out in the past - and/or they have a reputation for sweating the details - their books are inherently more valuable than a 'net source you're not friends with yet.
Definitely. I've been fed up with that for some time. I'd be very happy to have a couple of canonical IDs with everything else hanging off of them.
Sorry but this does not matter except for nostalgic feelings.
Collect a fee for providing a warm fuzzy for executives who claim they need someone to call or blame when things go wrong.
some links:

http://webworkerdaily.com/2008/08/28/getting-delinquent-clie...

http://webworkerdaily.com/2009/09/11/tips-from-the-trenches-...

http://www.acuitydesigns.net/how-to-deal-with-non-paying-cli...

http://articles.sitepoint.com/article/7-great-rip-offs
i think there are salient advantages to preferring to fail over documentation---which is about getting the implementation right before time-consuming bugs or poor code are introduced--and preferring to "fail fast"---which is about not investing in a product the market doesn't support.
> I don't think it would be so bad to say something like, "Your order is in our system. We'll confirm that the restaurant got it correctly and email you in a couple minutes."

It adds complexity but provides no value.

If you call a cab, you also accept "be there in 10 minutes", even though it's not confirmed, not "Right, tell you what, I'm gonna push this button on my radio, which closes an electrical curcuit connected to a big radio, and announce your request to our fleet of cars. Now, provided that there's no interference, and that the nearest car isn't in a garage or a tunnel or something, and if the driver isn't fighting with his wife on his cellphone, or in a place getting a coffee, he'll hear the message, and radio back confirmation. He'll then drive to your address, where, bar mechanical failure of perhaps the brakes or the pressurized oil system, he will arrive in 10 minutes. Have a good day."

> I think the most amusing part of this whole thing is that there's no way any user actually believes there are ~100 discrete steps to the order placement process, despite the high "progress resolution" of the progress bar.

Progress is often temporal, and time has infinite resolution. There may no be 4*60 distinct steps to the process of steeping a cup of tea, but we still accept the turn of the second-hand as a measure of progress.