rozim

I enjoy Sam Harris, https://www.samharris.org/podcast .

Reshevsky, many times over.

"In 1981, at the age of 70, he tied for 3rd place in the U.S. Championship. In 1984, at the age of 72, he took first place in the powerful Reykjavik Open, which featured many grandmasters"

http://www.chessgames.com/player/samuel_reshevsky.html

It would be interesting to see a comparison of Korchnoi vs Samuel Reshevsky as Reshevsky was quite strong as senior GM:

"... He won his last American championship in 1971 at the age of 59. In 1981, at 69, he was a finalist among Americans seeking to qualify for the world championship matches. And in 1984, at 72, he tied for first place in the Reykjavik International Tournament, his last world-class showing..."

http://www.nytimes.com/1992/04/07/nyregion/samuel-reshevsky-...

There's a story of how how when Reshevsky was quite old he went to watch a strong tournament in Europe and someone dropped out, and they asked him to be a last minute substitute ("house player"?) and didn't he surprise everyone by winning it?

But Korchnoi RIP, such great fighting spirit and interesting games.

Below what threshold though? L1 cache size? O(64 bytes), no?

See also the papers by IM & PhD Kenneth Regan on "Intrinsic Chess Ratings" such as http://www.cse.buffalo.edu/~regan/papers/pdf/ReHa11c.pdf .

Googler here. We avoid doing "work" in constructors as per the style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

See 'Nobody ever got fired for using Hadoop on a cluster' http://research.microsoft.com/pubs/163083/hotcbp12%20final.p...

I thought it was developed for settop boxes - and called 'Oak' back then..

The leveldb page shows mixed results wrt sqlite3 - I would say that it is generally faster that sqlite3 based on the results. There is no comparison to sqlite4.

Most notably in large value operations, and also slightly in random reads, sqlite3 wins. In in other benchmarks however, leveldb is faster.

The leveldb page notes that they perform poorly with large values due to the increased I/O that is done. The relatively poor random read performance isn't discussed but my guess is that it's due to having to fetch a compressed page of data that contains values for other keys, thus leveldb is doing "more work" than strictly necessary.

Variation on a theme: implement Stockfish in NACL, or, if Stockfish is too hard to port, a simpler though strong program like Fruit.

Then, you can essentially isolate out one of the variables, the strength of the "node", or client, engine, and you can play your Stockfish distributed against a Stockfish on a local box.

Of note is that there will still be 2 advantages the distributed version has: - more CPUs (obvious to everyone) - more RAM (well, obvious once you mention it)

If the distributed version is stronger then one question will be, was it more CPUs, or more RAM, that tipped the balance?

I used to see so many security problems with xmlrpc.php, and never used the functionality, so I put in a cron job entry that did this for all blogs I had hosted:

    mv PATH/xmlrpc.php PATH/xmlrpc.php.nope
    chmod 000 PATH/xmlrpc.php.nope

something like once an hour in case I upgraded and forgot to secure the site.

I've used this LDA code http://code.google.com/p/plda/ on multiple systems, however it's not really as well packaged as the Apple code seems to be.

It looks like it has become a hybrid pixel / vector graphics editor...note the screenshot at the bottom right and the control points highlighted on the butterfly.

I find this kind of shallow but maybe it's just me.

In contrast I thought the Cluetrain Manifesto was better developed: http://www.cluetrain.com/

I esp liked the sequence starting at Slide 47 - Any company can be described in 9 building blocks - thru the complete picture of the idea, slide 57.

In a system with a GUI (Android, Web Browsers, old school X windows) I often do a variation on pong but instead have a bunch of (round) bouncing balls with a simple Newtonian physics engine.

A normal onsite interview is 45 mins and yes, a normal start is the phone screen which counts as an interview too.

I work at Google and have interviewed O(250) people there.

Obvious followup: "Amazon Simple SMS Service". Watch out Twilio...

To me this is all nice and straightforward except for the merge i.e. when does it happen? Magically in the background or only at restart.

In either case then the question is how does this affect the responsiveness of the system.

This paper http://downloads.basho.com/papers/bitcask-intro.pdf is a nice easy ready with another level of detail over the linked to article.

I suspect they could consider - varint encoding of the key and value sizes on disk - aligning some writes to disk block boundaries to avoid spanning 2 blocks

though both probably only have minor gains.

For more inspiration see Jeff Dean's comments on the SSTable data structure at Google: http://osdi2006.blogspot.com/2006/10/paper-bigtable-distribu...

The journey is the reward, though it may not seem like it.

I think Kasparov disagrees with you via "...working hard is also part of an individual’s talent"

though to be fair he follows with

"I think working hard is sometimes just as important to having a talent."

http://www.chessbase.com/newsdetail.asp?newsid=6069

They were tightly run and limited to 15m minutes. Usually only team leads talked and there wasn't much back and forth.

It's more normal at Google to have fewer people and 30 or 60 minute mtgs.

Purify: formerly the name of an amazing memory access detector so I guess you can claim your name is different enough not to be confused but anyway, FYI, heads up.

http://en.wikipedia.org/wiki/Purify_(software)

See also SpotSigs ("...stopwords may however be very good indicators of the actual interesting parts of a web page...")

http://infoblog.stanford.edu/2008/08/spotsigs-are-stopwords-...

MVP on GAE. Minimum Viable Product on Google App Engine.

In particular, did the middleman vendor take a cut?

Cache locality: especially with open addressing and linear probing.

If you disrupt an existing business significantly then they can't help but be interested in you and then ideally they decide: - to reduce the number of players in the market (by acquiring you) - that it's cheaper and quicker to market by acquiring you rather than develop inhouse

Yeah, what drives me crazy is the insistence that java "properties" be hidden behind set/get methods even for simple ones in which their is realistically no need to every intercept their accesses. I think C# and Python at least allow transparent control of properties while still allowing the caller's code to look natural.