ergobibliophile

Document data is stored in a storage system built on top of Bigtable. Storage is distributed across many machines and geographic locations, and all access to the underlying storage is tightly controlled and audited in compliance with SAS70.

For more details, I’ll refer you to this set of FAQs.

The ratio of the people in this AMA does not at all reflect the ratio of our whole team. We have lots more engineers than managers, we just wanted the rest of the devs to stay undistracted and keep working :) (That implies that I’m the least productive engineer, the one they could most afford to lose for half a day.)

I know this has nothing to do with Docs or the web, but I think this is one of the coolest things I've seen lately: http://googleblog.blogspot.com/2010/10/what-were-driving-at.html

Here you go: http://imgur.com/qVabh

Yes, but I like the anonymity I have on my personal account ;) (mostly a lurker, 4-year user)

When building Google Spreadsheets, we had a lot of challenges building performant large spreadsheet tables on top of the DOM.

We experimented with many approaches, and we ended up with a solution where we render an HTML <table> just for the viewport (where you're scrolled to), and buffer more rows and columns onto the table in all four directions.

To do this, we need to fake the scrollbar a bit so your spreadsheet appears to be as big as it should be. We also need to render rows off-screen to measure (and then cache) the row heights, so that we can make sure the table rows in the viewport are rendered at the right height even though not all the columns are actually rendered in the viewport.