Cross posted on LinkedIn.
Previously, I talked about how unit tests serve purposes other than verifying code functionality; I talked about unit tests serving as defacto documentation, and unit tests helping you refactor without fear. In this post, I’ll talk about yet another benefit to unit tests: writing better software.
Continue reading “The merits of unit tests — Part 3”
In the previous post, we saw how unit tests can serve as a reliable source of documentation for your code. There is a lot more that unit tests can do for you. In this post I’ll talk about a fairly obvious, but often ignored, benefit to unit testing: Refactoring.
Continue reading “The merits of unit tests — Part 2”
There are multiple reasons to write unit tests. Verification is only one of them, and the least interesting. This is part 1 of a five part series on why you should write unit tests (apart from the obvious): Documentation!
Continue reading “My code is bugfree! Why should I unit test?”
I work on Google’s air travel infrastructure team, which powers Google Flight Search. Last month, I did a #HangoutOnAir with university students in India. The main focus of that talk was to introduce the students to the sort of challenges that we face. The talk is up on Google Plus, and has since been split into two parts.
In the first part (which is targeted for a general audience), I cover the fundamentals of flight booking, tackling issues like routing (10,000+ routes for SFO-JFK!?), seat availability, fare codes, pricing and more. It answers questions such as, “why did you pay $50 more than the person sitting next you in the plane for the same ticket?”, and “why are tickets on this flight from SFO to JFK available when flying SFO to BOS via JFK, but not available for a non-stop flight from SFO to JFK?”
You can check out part 1 [here].
In the second part, I get into the computer sciency details of the complexity of airfare search (even the simplest versions of this problem are NP-hard), and provide a (over)simplified description of QPX — the engine that Google uses to search and price airfare tickets. This talk is targeted at computer science students and professional.
Check out part 2 [here].
New paper in NCA 2014, with Josef Widder.
Abstract: Failure detectors are oracles that have been introduced to provide processes in asynchronous systems with information about faults. This information can then be used to solve problems otherwise unsolvable in asynchronous systems. A natural question is on the “minimum amount of information” a failure detector has to provide for a given problem. This question is classically addressed using a relation that states that a failure detector D is stronger (that is, provides “more, or better, information”) than a failure detector D’ if D can be used to implement D’. It has recently been shown that this classic implementability relation has some drawbacks. To overcome this, different relations have been defined, one of which states that a failure detector D is stronger than D’ if D can solve all the time-free problems solvable by D’. In this paper we compare the implementability-based hierarchy of failure detectors to the hierarchy based on solvability. This is done by introducing a new proof technique for establishing the solvability relation. We apply this technique to known failure detectors from the literature and demonstrate significant differences between the hierarchies.
A preprint is available on ArXiv; click here to access it.