Modelling errors in Scala

With functions that can fail, people tend to think there are two possible options, success or failure. This is what’s modelled by Scala’s Try[A] and Future[A] types, as well as plain old try/catch. However things aren’t quite as simple as they might first appear. Let’s go down the rabbit hole.

Securing Deliveroo (CodeMotion Milan)

Deliveroo is just over four years old and has grown incredibly quickly; we deliver millions of meals every week in 12 countries. When a company is growing at this rate, how do you get leadership, engineers and customers to prioritise security? I’ll talk about how we did that, setting up a security team, the threat landscape, improving physical security, improving authentication, setting up a bug bounty program, handling personally identifiable information, and responding to security incidents. We’ll also touch on the GDPR and what it means for your company.

The distributed pit of success at Deliveroo (QCon London)

In just two years Deliveroo has expanded from central London to hundreds of cities in twelve countries, and the engineering team has grown at a similar rate. To allow us to continue innovating rapidly we need to be able to scale the team horizontally. But building distributed systems is hard, and typically requires hordes of very senior engineers with many years of experience and past failures behind them. This talk covers how Deliveroo is using domain driven design principles and powerful building blocks to remove this limitation and allow engineers of any level to quickly and successfully deploy new systems into production.

Optimising session key storage in Redis

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?

The problem with ETags in RESTful APIs

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).


© 2013-2018 Greg Beech. All rights reserved.

Powered by Hydejack v7.5.0