TimothyFitz

RAID doesn't meet his definition of "scalable" because it has a central controller.

This whole post could be summed up as "ACID doesn't scale", which has been proven. Consistency, Availability or Partition Tolerance; pick two (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1...).

Good introduction to non-ACID databases: http://highscalability.com/drop-acid-and-think-about-data

I work for a company with a 30 million node social graph. That type of data is becoming more and more common. Including things like Twitter where the social graph is effectively open to anyone.

What happened in March that you saw such a traffic surge?

As one of a few (very) small angel investors in DevjaVu, I'm both sad to see it go and excited to see what Jeff Lindsay will do next.

If the past week has been any indication, he's going to build a small army of web API related infrastructure projects: http://www.scriptlets.org/ http://www.postbin.org/ http://github.com/progrium/hookah/

For the opposite, a URL which stores what's POSTed to it: http://www.postbin.org/

For example: http://www.postbin.org/zfzfg2 (superhappydevhouse.com's pbwiki's webhooks point there)

I'm guessing it's a typo, and they meant a CRX.

Use clicky, http://getclicky.com

I've run A/B experiments via them.

I'd love to see posts about this side of things: how did you build that business, what were the challenges, etc.

Two options to deal with the "scary" part of big integrations in continuous deployment:

Don't. Commit early, often and in small chunks. Just search for Continuous Integration, more than enough has been said on it already.

When you must, roll out features independently of the code being live in production. This means things like using control logic to roll out the code to portions of users, intelligently. We roll out via: on/off switches (mitigate total failure), A/B tests (mitigate poor performance in front of customers), QA-rollout (mitigate bad experiences for customers), etc. Lots of flexibility here, including hidden rollouts: running the code without showing the results to users, so you can figure out scalability impacts.

Guessing this is a symptom of: Tiny market share Radically different approach to security (heavy sandboxing, multi-process)

We don't yet know if Chrome is actually more secure.

What about tests that intermittently fail? Race conditions etc.

Three big reasons:

One, we're the oldest company (5yrs) practicing Lean Startup ideals, an off-shoot of Steve Blank's Customer Development strategy.

Two, the company chose to be extremely public about their practices and explicit about the financial results, up through 2007. As a Board of Advisors member and Venture Advisor, Eric sees a lot of privileged information. I don't have any specifics, but there are definitely other companies getting it and moving with it.

Three, and I apologize for how vague this will sound: things just look different when you're at IMVU. The culture is so hard to describe to an outsider, and so fundamental to the way we do business. I hope Eric writes more about it, because it was an explicit decision on day 0 to have a strong culture. It worked.

I accidentally submitted his front-page instead of the actual article url, which I've since deleted. Thanks for resubmitting peter!

Interestingly, I've watched very similar symptoms happen to web services that grew organically but then attempted a 2.0 release. It's like they feel they never launched, so they need a big release to come out and impress everyone.

So they make all the same mistakes -and at the same time- ignore their existing product and users.

We might not see upgrades any time soon, they may try to push the price of their slowest instances down. Imagine if you could get an instance for $10/mo? $5/mo? They're just buying faster hardware and figuring out how many instances they can effectively run per-machine.

This is a different propopsal than the IETF draft by Donovon Preston, which is knows as "Reverse HTTP".

This is apparently "ReverseHTTP" and the specification looks about twenty times longer, needlessly. I'd love to hear any good reasons why I should use this "ReverseHTTP" instead of long-polling or Reverse HTTP... the IETF draft

Azure and AppEngine are much more closely related than either to EC2.

Both Azure and AppEngine are platform-aware and do the scale-out magic for you; you write your code and they make sure it scales (more or less, I'm certain there's still some application-efficiency/scalability rewriting, but you never worry about individual machines, in theory)

EC2 means machine level administration and custom scale-out/scale-up techniques. Not to mention there are load-balancing concerns when you're in the more-requests-than-a-single-machine-can-handle range, although that's above 500/sec for many applications.

Indeed, I've written all of my posts on a combination of Darkroom and Etherpad. Etherpad lets me involve a couple editors who can make copy edits and suggestions while I'm still the draft.

This gives me an idea:

If I should ever have to be back in the situation of applying for jobs, I'll put tracking pixels in my e-mail and my resume document. Resume open rates!

This is why I <3 HN.

Go to a website, comment on it and watch your feedback be used to evolve the website... in under half an hour! There are even comment threads where PG has a <5min read-hack-deploy-announce cycle on HN itself.

I really like the idea, so much so that I jumped through all of the hoops and added my own project: http://clusterify.com/projects/list/TimothyFitz/9/

Unfortunately, there were a lot of hoops! I had to register. Once registered I wasn't logged in?! I confirmed my e-mail then logged in, then clicked new project. Most of this went well except for the tags, where the auto-complete broke (would show the tag I had just typed, over the textbox I'm trying to type into). That might just be a Google Chrome issue?

My $0.02: You should optimize the hell out of the new user -> adding a project loop and the new user -> joining a project loop. User accounts are stupid and antiquated. Have the add project field use the same fields that wordpress comments use (name, e-mail, optionally website). Defer dealing with misuse (hopefully defer it until you're popular!)

Eep, yes :)

I edited out a section where I talked about how it's NOT just port 80.

It turns out lots of ISPs and broken routers and terrible corporate proxies only allow HTTP. They do things like require HTTP headers, so they can check for whitelists/blacklists. It's stupid and it breaks TCP/IP in general, but most people only care about the internet so it just works for most people.

I think this exactly illustrates my point... (sorry for calling you out twice moe, I very much appreciate you expressing your opinions even though I disagree with them)

You say "all lessons unlearned" implying that RSS is worse than previous incarnations of solving the same use case. This is a common opinion I really am railing against. RSS is EXTREMELY popular. Usenet is a dying architecture. It's a case where being worse in the "obvious" technical architecture allows you to be better in things that actually matter: ease of access, simplicity of use, lack of installing things and wide support. These are just some of the reasons RSS took off. Easier means more viral, because easier means a shorter viral loop.

Of course, I think RSS is better for syndication than notification, and would prefer more sites like twitter use Webhooks in addition to RSS.

Evan and I worked together at IMVU, and at one point a senior engineer heard one of my (appallingly bad) ideas and replied "You're fired." and went back to work.

A few weeks later I, apparently, made a terrible joke. Seconds later this shows up in my inbox:

Dear Timothy,

After careful deliberation, it's been decided that you need to be fired.

Reason: telling not funny jokes

You may take one (1) Odwalla for the road.

Thanks,

The Firing Committee

Not only was it hilarious but while I suspected Evan, he hadn't had time to type that whole message! Over the next few weeks I received quite a few of these e-mails, but with different messages:

Reason: distracting Evan from his conversation with Luc

Reason: Asking too many questions

etc.

It turns out that not only did Evan find the need to write a formal you're fired letter; he wrote a web service to send formal you're fired letters. To me.

Yep, that IMVU. Here are a few more staggering statistics that we've published: http://www.vator.tv/news/show/2009-01-22-recession-not-affec...

We empirically have on average 70 builds a day. The number is higher than your calculation because we don't all work 9-5, we're commiting frequently from around 8am to 9pm. We also run builds repeatedly overnight to flush out any intermittently failing tests we may have recently introduced. We'll run the builds as fast as they can go from 2am-4am.

ActiveMigration really solves a different problem. Our problem is that adding indexes or altering popular tables is impossible to do on a live and in production database. To get those changes out we have to go through quite a bit of extra work. It's really a MySQL limitation, not a process problem.

I've read your post on unit tests, and I didn't understand what you were trying to say.

Were you saying don't write automated tests that test your code, instead focus on monitoring the actual production invironment?

Or were you saying that specifically the "unit test" class of automated tests are not worth their time?

I can imagine a system that monitors the business metrics well enough to prevent defects from slipping into production (it's a stretch, metrics are soft and squishy moving targets), but I can't imagine using only those metrics to find every bug you ever slip into production. Metrics are so distant from the bug that caused their downturn; you'd waste so many cycles debugging. The gap between writing the code and finding the problem would be much larger than if unit tests found them; that has to slow things down as well.

I would love to see that post. The first question most people ask me is "How do I get there?" and I don't have a great place to point and say "start here"

A well written concise introduction to continuous integration / constant testing would be a boon to this community.