TimothyFitz

This is exactly why I don't read other people's A/B experiment results. I haven't seen a single A/B experiment that listed it's statistical significance (and how that was calculated). I fear that bad data is worse than no data at all.

IMVU Inc. is hiring: http://bit.ly/6XTJ5r Work in entertainment (profitably!) on fun problems with an amazing architecture and amazing development process.

Apple is personally responsible, they bought out the company that created the original (or at least first commercially succesful one) http://www.fingerworks.com/ST_product.html

You can pick them up on ebay but they're now quite old and extremely expensive.

Specific numbers (that I used to push for their purchase at IMVU): Cold-disk grep of the entire codebase: HDD 110s, SSD 7s Cold-disk svn no-op update: HDD 140s, SSD 14s

Shipping the prototype as production code and not maintaining, fixing, rewriting or deleting it would be reckless debt.

This basically already exist(ed): http://www.fingerworks.com/ST_product.html

Apple bought them up and stopped making their products (but we got multitouch on the iPhone, an interesting trade-off).

From talking to him recently in person, he's just super busy with his startup, which is taking off: http://saucelabs.com/

See also http://www.scriptlets.org/.

Similar idea, but implemented on top of AppEngine and opensource. Designed to give you persistent URLs to run your code so you can use them as webhooks, etc.

I was unaware the cafepress version was $10 cheaper (I overpaid!). This book is worth it at any price, via any link :)

These posts are a summary-level intro to Steve's book http://www.amazon.com/gp/product/0976470705?ie=UTF8&tag=...

I wasn't trying to claim you don't understand python, simply that the only way to be CPU bound on multiple cores with a single python process (as is claimed) is to be running non-pure python code that unlocks the GIL before doing CPU intensive work.

Ahh yes, I'm familiar (though not familiar enough) with project Xanadu. The concept of keeping track of derivations is fairly common; far less common is the idea of derivation for the express purpose of indicating participation in the value chain and thus participation in the compensation.

I think we're agreeing. As I do for all blogs, I just assumed the courtesy implicit prelude: "This is my opinion shaped by my experiences and most likely only applies to the system I'm currently interacting with."

I mostly agree with his sweeping generalization if applied to, say, the subset of startups that get coverage on Techcrunch.

Which book are you referring to?

I wasn't the one who came up with the idea for this feature. The initial version of IMVU had this feature, so it's at least 5 years old.

I think his point is that scaling up on the web is a solved problem, which is mostly true. If you look at most startup's pitch/plan the biggest risks are not in technology.

Steve Blank would say there's Market Risk (will your customers want it?) but minimal Invention Risk (can you deliver it?). Contrast this with biotech where you're trying to cure diseases. Minimal market risk, tons of invention risk. Read more here: http://steveblank.com/category/vertical-markets/

Yeah, here's a little known fact about IMVU's economy: Most products allow derivation, which gives content creators the ability to tweak/remix/reskin the product and publish the changes back to the catalog. Pick a markup for the remixed version and presto, everyone in the derivation chain gets paid their respective markups for every sale. There are only a handful of root nodes; nearly every product is a derivation of another product.

"The scarce talent is business model engineering and product marketing – building for scale isn’t the problem anymore. I can build a hack protytype that works well into the "validation" stage to establish a funding event or customer revenue stream then use the new capital to rebuild, hire and grow."

This interestingly follows my own career growth. I was the tech lead responsible for scalability/reliability at IMVU for a long time, but eventually our bottleneck clearly shifted from reliability back to marketing/product development. Around that time I switched teams, and have since been the tech lead for our marketing team. It might sound less sexy to other engineers, but getting to be on the bleeding edge of marketing for virtual economies is constantly challenging and fun; especially with IMVU's data driven culture.

Why is this page styled with Facebook's CSS and header? Who is this written by?

Switching to out-of-site has two big benefits: 1. OkCupid's chat system is horrible, and results in lots of missed messages. 2. An IM handle gives an easy way to ping people later, the other person is subscribing to be IM'd by you in the future.

If you're CPU bound in pure-python computations then the GIL (Global Interpreter Lock) will cause you to only make use of one core. This is intentional: threads are hard, processes are simple.

You can see this principle at work in how 2ch/4chan's ephemeral nature shaped the behaviors of their users (and thus their culture).

Note that a url like //www.example.com will use the context's protocol, which means an img src="//www.example.com" will use http or https depending on which the page was loaded in. Very handy!

Twisted's manhole does exactly this. SSH into a process! http://www.devshed.com/c/a/Python/SSH-with-Twisted/3/

Almost everyone is splitting their tests by browser; are we (IMVU) the only ones who have to horizontally shard because of test times?

Granted, our list of fully supported platforms is small (effectively IE6, IE7, IE8, and FF3.5) considering our downloadable client is currently windows-only.

True, but decoupling services via HTTP just makes the fault lines more explicit. I imagine more of these services (like many of the current webhooks stuff Jeff Lindsay is putting out) will be opensource and easily adapted to virtual appliances / dedicated hosting. That way you can choose exactly when hosted vs hosting it yourself makes more sense.

And remember kids: WSGI rhymes with Whiskey.

Or perhaps in this case it's more subtle: code becomes optimized for the wrong thing over time. For example the difference in optimization strategies between netburst pentium 4s and core 2 duos is staggering.

It's really hard to harden yourself against code getting interpreted by the browser (and thus allowing someone to steal cookies and impersonate other users). Here's a long article on exactly how complex it is (as known today): http://tstarling.com/blog/2008/12/secure-web-uploads/

Personally, I just don't trust web uploads on the same domain. Put them on a subdomain or better yet a completely separate domain, preferably served out of something set up to never execute any code whatsoever.

It's also "poor businesses subsidizing rich businesses". Note that the rich business didn't have the ROI to go out and build the tool themselves; without poor businesses chipping in they wouldn't have the tool either.