eries

37 ms·

601.
by eries 18y ago
Thanks so much for posting this! My thoughts here: http://startuplessonslearned.blogspot.com/2008/09/seth-godin...
602.
by eries 18y ago
Just a theory I've been kicking around. I'm very interested in feedback if anyone wants to discuss.
603.
The Lean Startup(startuplessonslearned.blogspot.com)
1 points by eries 18y ago|1 comments
604.
by eries 18y ago
We mostly used simpler RPC mechanisms like XMLRPC or REST. But cross-language calls (other than client-server) were really the exception. Probably the only really performance sensitive ones were to our SOLR-based search. Yes, you can easily
605.
by eries 18y ago
When absolutely necessary, we would solve this by keeping global (centralized) ID's in an autoincrement table either on the master or on a vertical shard. It didn't come up that often, because most tables (in our app) are really dedicated t
606.
by eries 18y ago
We're just discussing over in this thread: http://news.ycombinator.com/item?id=296656 I have had really good experience with a very simple centralized lookup facility. It's very easy to prevent that from becoming a CPOF, either using repl
607.
by eries 18y ago
I'm not sure who would be embarrassed if our data did turn out to be that parallel :). IMVU has a pretty typical data profile for a social network + IM site. We worried all the time that we would have to build a really fancy distributed tra
608.
by eries 18y ago
Good point. Sorry about that. I just posted a PDF version, let me know if it works for you: http://www.speakeasy.org/~ericries/Just-In-Time%20Scalabilit...
609.
by eries 18y ago
I would add, work together with them on a problem that is completely out of their comfort zone and/or background. See what kind of questions they ask, how fast they recognize a dead-end, and whether they learn from what you are trying to ex
610.
Just-In-Time Scalability(startuplessonslearned.blogspot.com)
4 points by eries 18y ago|10 comments