ehsanul

But even then, making your first couple employees generalists doesn't sound like a bad idea to me at all. Of course, this is all speculation: I've never hired anyone, hence everyone should ignore whatever I say here. But it's definitely easier to work with people who can pick up new stuff quickly, and a generalist is usually that type of person in my experience.

Probably not what you're really looking for but, maybe you could try to eschew shared state when at all possible?

I, myself, am absolutely no good with threaded code. Message-passing between multiple processes is just such a nicer way to reason about things, without worrying about race conditions. I've been using 0MQ recently, and it's really great for this, since it's easy to get it working across machines even, as well as having common messaging patterns "just work". Try it out sometime.

While that has been my general experience as well, things can break down at the edges sometimes. I sometimes have to join 200m-row tables that don't fit into RAM (though individual partitions of the table do), against 1-10m-row tables of new data. This task is probably something more suited to Hadoop, but we're using PostgreSQL for it as that's where the data is.

With a plain vanilla join using indexed columns for the join, the smaller table is scanned while an index is used for larger table on the joined column. This is reasonable except for the fact that this results in a lot of random IO, so if you don't have an SSD or something, this will be slow. Of course, you can just increase the random_io_cost or whatever it's called, to adjust costs estimated by the query planner. I believe that results in a sorting operation for the tables before the join. Sorting can be better compared to a thrashing disk, but still slow.

The core issue is random IO here, so how about just warming up the cache for that particular partition's index/table with a big sequential read of the entire index/table, and letting it use the index-based query plan as usual? The sequential read takes a minute in the worst case for a single partition, but then when everything's cached.. BAM. The join query runs in 2-20 seconds (for a single partition, one of 26). If Postgres were psychic, it could have done this itself instead of making me force caching with an otherwise pointless extra query. But I suppose that behavior would usually not be desired, as it would destroy the existing cache. In this case, destroying the older cache was the right thing to do, but Postgres can't know that.

The whole point of this comment being: DBAs matter and you can't rely fully on the query planner to do what you may expect. Even a scrappy one like me (I'm mostly a programmer, the DBA stuff just comes with the territory for me). This is partly in response to a comment elsewhere on this page, mentioning how the query-planner is better trusted than a DBA - I wish it were always so.

My immediate reaction on seeing the page was recoil and puzzlement: it looked nothing like any C code I had ever seen. (“Is it even C?”) However, Ken counselled that I should reserve judgment. As recounted in An Implementation of J, it then happened that:

I studied this interpreter for about a week for its organization and programming style; and on Sunday, August 27, 1989, at about four o’clock in the afternoon, wrote the first line of code that became the implementation described in this document.

The name “J” was chosen a few minutes later, when it became necessary to save the interpreter source file for the first time.

I showed this fragment to others in the hope of interesting someone competent in both C and APL to take up the work, and soon recruited Roger Hui, who was attracted in part by the unusual style of C programming used by Arthur, a style that made heavy use of preprocessing facilities to permit writing further C in a distinctly APL style.

On the other hand, it's notable that many IOCCC submissions happen to pack a lot of functionality in often less than 2k. I remember reading a few descriptions of some the winning entries, but I can't find that now. Here's a glimpse though: http://cboard.cprogramming.com/brief-history-cprogramming-co...

Also like your last bit of advice - think about the person's point of view before evaluating what they've said. And by doing this, I see how one could also get to the root of a disagreement, rather than just the surface, and address that instead. Everything becomes philosophical from there I'm guessing.

Well, in my case, it's not that I make fallacious counter-arguments. My arguments are generally quite sound, and simple logic/rationality serves my need for something fundamental.

My issue is that, when something looks illogical on the face of it, rather than giving it the benefit of the doubt and try to imagine how it might work, I just shoot it down. And I shoot it down quite harshly usually, though almost always with a well-reasoned argument.

I have to be arrogant here and say that most of these arguments/ideas/statements I shoot down seem to really deserve it, which I know because I do sometimes restrain myself and just shut up and listen. However, sometimes my response is really undeserved, and I'd do better if I tried to understand where others may be coming from. Even if it's deserved, I could be much less harsh and argumentative, so as to better foster a good discussion.

How can I stop being a "faker", as you call it? I, and probably some other HNers, are often pretty critical or take things people say more literally than they meant often, rather than giving them the benefit of the doubt with a more liberal interpretation.

I realize this is usually not conducive to "profound and productive interactions", but it is almost second nature for me, something of a gut reaction and I'm not entirely sure how to go about fixing this problem. Behavior change is difficult, just seeking advice.

Secondly, you can use it as a real marketing opportunity. What I mean is, with a product from Yahoo, there's going to be all sorts of press and many cricket fans talking about their product. That's your cue to show up (without being spammy), and get the word out about yourself. You could get some media attention at the very least, as well as word of mouth (people talking about Predictopus will be told by their friends about doosracricket).

Zombie.js: http://news.ycombinator.com/item?id=2038663

HTMLUnit: http://htmlunit.sourceforge.net/

Celerity (JRuby wrapper around HTMLUnit): http://celerity.rubyforge.org/

What a strange thing to say, given that it's probably very likely that the implementations probably work pretty differently internally. You'd probably see similar differences with such a different implementation no matter the language, assuming it isn't something ridiculous like Ruby (I'm a Ruby programmer, don't bite).

Secondly, isn't the overhead for a database mostly disk IO? I realize a finely tuned DB/server is probably CPU-bound instead, but that's generally assuming that the working set fits snugly into RAM and gets cached. Which may not quite be the case when you operate the scale at which you'd resort to HBase/HyperTable.

All IPC goes through a single (per machine) routing server which handles routing messages to the various node.js processes, which may or may not be on the same physical server. Only communications are for objects around the edges of the squares, for collision detection etc. and for transferring websocket connections to another node.js process.

After a lot of thought, that seems to me to be the best way to work out a scalable solution. Have yet to see if it'll work well, but I see no reason why it shouldn't. Now if only I had enough users to test it..

Oh, and thanks for the great 0MQ library! :)

However, despite their purported effectiveness as engineers, I'm not sure what Backtype is really doing. I generally see them just below an article, in place of comments, with a long list of useless tweets referring to the article (usually of the form "article title - bit.ly/shortened". That's probably not doing them too much good for marketing, unless you think any publicity is good publicity.

Care to share the exact copy you used? When I check your website, it redirects to http://sanfrancisco.usehipster.com/ and just says "Enter your email and we'll put you on our invite list." A/B test?

Also, I wonder how one might inch that viral coefficient up and above 1.0, making it a truly viral feedback loop.