I have a love-hate relationship with spring, Rails’ application pre-loader. One one hand, it speeds up the feedback loop when doing TDD. Faster running specs, promote running them more often, which promotes writing code in smaller increments, and so forth. On the other hand, it is dark magic: In its quest to be unobtrusive, it starts automatically, and barely reports it’s being used at all. Occasionally it looses track of which code it needs to reload, causing much confusion to the user, as the code executing is different than the version saved on disk.

View-centric performance optimization for database-backed web applications

This post is a walk-through of of the academic paper with the same title. Keeping page-load time low continues to be important, but it has become an increasingly challenging task, due to the ever-growing amount of data stored in back-end systems. The authors created a view-centric development environment that provides intuitive information about the cost of each HTML element on page, along with the performance-enhancing opportunities can be highlighted. The goal is to make it easier to explore functionality and performance trade-offs.

Interestingly, the development environment, Panorama, targets the Ruby on Rails framework specifically. I look forward to trying it out soon.

Zanzibar: Google’s Consistent, Global Authorization System

This paper includes a thorough description of the architecture behind Zanzibar, a global system for storing and evaluating access control lists internal to Google. As a highly distributed system, it builds on top of other Google technology, like Spanner – a distributed NoSQL database. In particular, I was very interested in consistency model and how they provide guarantees around external consistency so that the casual ordering of events is maintained. It achieves this by providing clients with tokens after write operations (called a zookie): When a client makes a subsequent request with that token, the system guarantees that any results are at least as fresh as the timestamp encoded in the zookie.

The paper has a lot more, including how they architect for performance with caching layers, and a purpose-built indexing system for deeply nested recursive permission structures.

One of the reasons that I love TDD, is that it promotes fast feedback. You write a line, execute the tests, and see what the results are. I write outside-in-TDD most of the time. Occasionally, I don’t have a clear idea of what tests to write, or I am doing exploratory coding.

Designing Data-Intensive Applications

by Martin Kleppmann

Per-project Postgres

In this post, Jamey Sharp elaborates on a neat technique to run different versions of postgres on a per-project basis. I learned that you can run postgres on a Unix socket only, without having a port open, which removes the need to manage those ports for each version of postgres. The technique also has the advantage of keeping the data for the project, inside the project directory structure. It illustrates the power and flexibility of Unix tools.

How to do distributed locking

Martin Kleppmann writes about distributed locks in general, and in particular the merits of Redlock, a Redis-based distributed-lock algorithm. Kleppmann breaks down the reasons to use a distributed lock, it’s characteristics, and how Redlock in particular is vulnerable to timing attacks. I found this to be great technical writing. The post came about when Kleppmann was researching his book, Desiging Data-Intensive Applications. I finished that book a few days ago, and hope to write a review soon. I can recommend it enough.