jconley

Source code escrow works really well to sell enterprise customers. Perhaps there should be something similar for SaaS companies. An agreement, paid for by the customer, that if the company fails or the service is no longer supported, the customer will be given the ability run it themselves.

This is why I don't consider jobs with even exciting startups with early traction at this point in time. Why would I bother getting 50x less return for a similar investment and risk as a founder? We should at least be in the same order of magnitude. Especially if the startup is practicing "lean" and is going to completely change by the time it exits. Might as well just start my own company.

And, if you can't get into an incubator, you can just as easily bootstrap your way through the early stages.

It would be super-awesome to see a profile of node.js when you run this test to see where the CPU is going. Is it something low level like the string parsing, buffer copying, socket writing, or maybe something higher level like some inefficient algorithm somewhere. As I read below that socket.io is focusing on performance now, I guess we'll know soon. :)

9k messages/second on a single 3.3ghz VM with 1,000 connections seems quite manageable and isn't out of line with other systems I've seen that are written in Java, .NET, C++. 100ms is an eternity to wait for a response, however. That's concerning. Especially since that is the case at low message rates. I wonder if that is a function of how the client is acknowledging the received data, rather than the actual time the server is taking to send it back.

What was the limiting factor on the server for this test? I've seen instances where the VM network drivers get in the way in this scenario. Or, you could also be saturating the network bandwidth to the VM if it's a 100mbit interface. Or maybe it's just simply CPU limited in user time by socket.IO...

The last startup where I was CTO was largely based on the Microsoft .NET stack and we loved almost every ounce of it as a technology. Until, of course, we tried to hire startup and open-source minded engineers in the Microsoft-hate land of Silicon Valley. That's practically impossible.

StackOverflow and (hopefully) now Github will ideally do a lot of good in the next few years to break the stigma against C#.

It seems like the C# community at large contains Enterprise-oriented folks, who only like to consume open source and not give back. They just want to get their projects done and make a profit. I wish we could see more altruistic entities and startups embrace the technology. @haacked - fix it! Github seems like an ideal platform for change in this regard.

Oh, yeah, that startup was acquired and they threw away all our back end tech for no other reason than it was Microsoft based. It's not all bad, though, I do love my shiny Macbook Pro. ;)

Feature requests: - CodePlex migration tool (I have a project there...) - Github client for Windows - Github VS integration

The site owners requesting a huge list of permissions like this should really test what happens to their conversion rate across various sets of permissions. Been there, worth testing. I'm just saying... ;)

But the problem is a bit more meta than Javascript scoping. Something would have happened no matter your environment. It's always extremely risky to make huge changes just before a launch day. Stuff always breaks. Sounds like you did a good job of communicating with your customers. Ironically, they will probably be better customers than they would have been if you didn't have any problems. Overcoming adversity brings people together.

Add some concurrency to your test suite. If you have any system level or black box tests, you can often just run the same test multiple times in parallel with different threads. No new tests required. Note that this may (probably will) also uncover other previously inconceivable concurrency issues.

Then again, as someone else said, the amount of time it takes to spawn a process to encode a video relative to the amount of time it takes to do the encode is probably trivial, and you would benefit from having the process isolation in case something goes wonky.

You would probably write some sort of "process gate". Though in a distributed architecture I'd do this with some sort of distributed work queue.... I did this in .NET many years ago for a similar service: http://blog.jdconley.com/2007/09/asyncify-your-code.html

Right. I'm just sayin' that you have to be careful when you move data with a caveat like that. Moving the shard keyspace (the 13 bits) to a new machine that started generating ID's even one second behind (the first 4 bytes) would be troublesome, no?

Does allowing your employees to be happier people increase their productivity and loyalty? Yup, I think so.

"... If you’re curious to see how much faster ASP.NET requests execute without the thread switch, you can set the value to 0. This will cause the request to execute on the IIS I/O thread, without switching to a CLR Threadpool thread. ..."

Of course you would only ever set this if you are really doing every bit of I/O asynchronously in your application. Otherwise bad, bad things would happen (deadlock under load).