Tracking authenticated user sessions can be implemented in Redis using setex with some serialised JSON. It works pretty well until you have to cope with millions, or even tens of millions of sessions where the memory usage and performance can suffer. By using Redis data structures more effectively we can achieve a 70% reduction in memory usage, at the cost of both code and conceptual complexity. Is it worth it?

Consider a collection of two addresses. #1 was updated at 11:20 and #2 was updated at 11:45. The last modified date of the collection can be the latest time that any individual address was modified. To make notation simpler I’ll just include the time for the last modified date, and the etag will be the time as they’re often derived from timestamps (you could hash the state or any other mechanism too; it won’t alter this discussion).

Most good developers take measures to protect sensitive information, and in particular personally identifiable information (PII), when building software. Some typical basic measures are putting user information in separate databases and restricting access to them, or storing credit card details with a specialist provider rather than in your own infrastructure.

We spend a lot of time designing RESTful APIs and discussing different patterns and paradigms. Contrary to popular opinion designing RESTful APIs is actually pretty difficult, so I thought I’d share some of the decisions we’ve made. You might not agree with everything, but I’ve included some discussion around the points so you can at least see why we think it’s the right thing to do.

At blinkbox books we’re making extensive use of Cucumber to capture business requirements and ensure that the code fulfils them. If you’re getting started with Cucumber, a lot of the good practices for writing Gherkin specifications and effectively automating them is captured by The Cucumber Book which is, like most of the Pragmatic Bookshelf, a very good book indeed.