Sunday, March 11, 2012

Link dumping, March 2012 edition

Once again, it seems like there's way more going on than there's time to read.

But here's some quick link-dumping on some of the things that have been occupying me recently:

  • Two great posts from the Netflix team about the practical aspects of fault tolerance in distributed systems: part one, ant part two
    Each service that’s wrapped by a circuit breaker implements a fallback using one of the following three approaches:
    1. Custom fallback - in some cases a service’s client library provides a fallback method we can invoke, or in other cases we can use locally available data on an API server (eg, a cookie or local JVM cache) to generate a fallback response
    2. Fail silent - in this case the fallback method simply returns a null value, which is useful if the data provided by the service being invoked is optional for the response that will be sent back to the requesting client
    3. Fail fast - used in cases where the data is required or there’s no good fallback and results in a client getting a 5xx response. This can negatively affect the device UX, which is not ideal, but it keeps API servers healthy and allows the system to recover quickly when the failing service becomes available again.
  • Greg Kroah-Hartman re-caps the history of the 2.6.32 Linux kernel
    It lived (in my hands) for 823 days (only the 2.6.16 kernel lived longer at 855 days). It ended up containing 3,349 patches that matched up with patches in Linus's kernel tree, the most of any stable kernel release by far (2.6.16 only had 991 patches, the next closest was 2.6.27 with 1,596 patches, 3.0 already has 1448 patches after 133 days, so it might end up being the largest eventually.)

    The 2.6.32 kernel was the basis of all of the enterprise distros of the time, still running, and will still supported by the major enterprise Linux vendors for many years in the future, so it will live on.

  • Joshua Gans takes an independent look at the question of whether there is any substance to the government's investigation of e-book pricing collusion
    Apple is not a book retailer. It doesn’t want to work out the price of books to consumers. It thinks publishers can do that. Now Amazon and other book retailers are, of course, in a different position. They might have information they can use there.
  • Jeff Atwood really nails it with a superb, link-rich, words-from-experience article on How to Hire a Programmer If your organization can follow even a fraction of this advice, you'll do much better at selecting new unknown talent. However, be warned: this is hard work, and Atwood's suggestions will take effort to implement. But it will be worth it, for programming talent is one of the hardest things to assess.
  • Meanwhile, in one of those places where they're trying to ready some of that new talent, Michael Mitzenmacher rather tongue-in-cheekily observes that it's getting harder to find a safe day to hold an exam, as there are too many parties on the agenda.
  • And Derek Jones suggests perhaps students of programming languages would be better served if they spent less time trying to invent new languages and instead worked on improving existing programming languages.
  • Lastly, there are just way too many interesting videos to watch:

Darn these short weekends! I needed that extra hour! Well, as the Bare-Naked Ladies sing, "Who needs sleep?"

No comments:

Post a Comment