codahale

Say hey to the folks we both know for me when you see them.

Keep up the good work.

You mean like what happens to women when they talk about sexism in our industry? You mean like what people are doing to Justine right now?

Yes, that would be bad.

Fuck off.

    If Vitalism is true, Soylent is a bad idea.
    Vitalism is false,
    therefore Soylent is a good idea.

Spill a little dimethylmercury? Welp, you're dead.

Sign something with your DSA key using a dodgy PRNG? Welp, you're dead.

[citation needed]

    Some smart people like Coda Hale also work there.
    I wonder if they'll leave or not.

* a realtime message delivery service which handles hundreds of thousands of concurrent clients

* an activity stream data store serving just shy of a billion requests a day

* a distributed database serving well over a billion requests a day over tens of terabytes of data with ~10ms response times at the 99th percentile

* a realtime search indexing pipeline, complete with a denormalized entity store, index replication and an autocompletion service

* a data export service which basically performs a diff of the state of millions of business objects and sends it out as a streaming ZIP file

* a user account synchronization service which handles streaming JSON dumps of companies' LDAP/AD server data

* an affinity prediction service which provides ranking of arbitrary objects based on past interactions (e.g., who you're most likely to CC on a message)

* an OAuth2 token service for 4MM users

* a collection service for the user events pipeline of our analytics system, handling hundreds of thousands of user events a second

* plus a grip of open-source libraries

And this is a team of seven people (now). The other teams at Yammer ship just as much as we do.

https://gist.github.com/845874

Hint: you don't know.

And I'm pretty sure they would consider themselves to work at a fucking bank (an FDIC one).

Perhaps this will be more to your liking:

http://geekfeminism.wikia.com/wiki/Timeline_of_incidents

* The CAP theorem is a logical proof of the impossibility of providing both consistency and availability on a network which can lose messages (or using machines which can fail). You can't implement it any more than you can implement general relativity. It's a description of reality.

* The CAP theorem is not a data model which competes with or intersects at all with relational algebras. Rather, a relational algebra is the logical model (allegedly) underlying RDBMSes which are systems which historically provide consistency at the expense of availability in the presence of faults (thus obeying the CAP theorem because they're real systems and not opium dreams).

* Scaling horizontally does not imply anything about fault-tolerance. It instead describes systems in which resources can be incrementally added to incrementally gain capacity. It's possible to build a horizontally-scalable system which is less reliable than a single-machine system; it's also possible to build fantastically fault-tolerant systems which are also horizontally-scalable (c.f. Dynamo). Doing the latter is considered "a good idea;" doing the former is considering "fucking daft."

* Nothing about horizontally-scalable systems (or NoSQL or really anything the author mentions except for Redis) requires that the entire dataset be kept in memory. Systems like Riak (http://riak.basho.com) or Voldemort (http://project-voldemort.com/) use pluggable storage engines, some of which (e.g. InnoStore and BDB-JE) have excellent performance with 1:10 RAM-to-dataset ratios. By the author's own metric, the Holy Grail has not only been found but the damn things are multiplying.

* Neither epoll nor kqueue "scale indefinitely in terms of I/O concurrency." Nothing does. That's horseshit.

You're better off huffing glue than reading this thing. I don't even care what he has to say about Redis. He could have some incredible insights about it, but they'd be completely and totally negated by the incomprehension, misinformation, untruths, and general crazytalk which preceded it.

tl;dr: 15+ years of RDBMS experience gives you 0 clues about distributed computing; reading Time Cube (http://www.timecube.com/) is preferable to reading this drek.

"You are staffing up so quickly?" vs. "such a small team"

I can't tell if you're trolling or just really inconsistent regarding the reasons for your dislike of them.

The actual cutting edge of event-driven server architecture[1] looks something like this:

    server = do {
      sys_call_1;
      fork client;
      server;
    }

    client = do {
      sys_call_2;
    }

[1] Li and Zdancewic. Combining events and threads for scalable network services. Proc. 2007 PLDI (2007).