Monads explained by a imperative programmer - with examples

A monad is any type construct that follows a specific pattern; it works in the same way as other design patterns. The .NET ApplicationContext is a singleton in the same way that Array is a Monad. Something being a monad does not define its purpose; in the same way that a class can implement many interfaces, a monadic type can also conform to many patterns to increase its usefulness.

Monads are hard to get our heads around because they are very generic. They are defined by having two methods: the bind method (also commonly called fmap), and the unit method (also commonly known as pure or from).

A bind/fmap method.

The fmap method follows this signature:

// Given a monadic type TMonad with value type V1,
// and a method that takes a value of type V1 and
// returns the same monadic type TMonad but with
// a value type of V2, produce a monadic type
// TMonad with value V2.
function (TMonad<V1> m, Func<V1, TMonad<V2>> f) => TMonad<V2>

A quick breakdown of the method signature in plain english: given a monadic type TMonad with value type V1, followed by a method that takes a value of type V1 and returns the same monadic type TMonad but with a value type of V2, produce a monadic type TMonad with value V2.

From the signature, it appears that we should give the value V1 from the first monad to the function f and simply return the TMonad from that call. The ability to control the usage of that function and the ability to intercept the return value is where it gets interesting.

[Read More]

Meetup: New Ideas for the New Year

Tuesday the 12th of December, OpenTable is delighted to host the thirteenth appointment with the WEBdeLDN meetup.

To celebrate the end of the year, and welcome the new one with new and fresh ideas, we’ll be listening to different speakers (many of them first-time speakers!) giving lightning talks about the most diverse topics: from personal stories to hardware projects, from 101s on computer science to accessibility and design.

[Read More]

Meetup: Bedtime stories

Wednesday the 22nd of November, OpenTable is delighted to host the twelfth appointment with the WEBdeLDN meetup, featuring talks by Tammie Lister (Experience Designer at Automattic) and Cristiano Rastelli (Front-End Engineer at Badoo).

Tammie’s and Cristiano’s talks are linked by a common fil-rouge: storytelling. In fact, each talk is a story, told by a first-hand protagonist, of two big business-critical projects. The first one is about the complete redesign of one of the core parts of WordPress, the content editor (which involves UI/UX design, the introduction of a new tech stack, a very strict backward compatibility, and much more). The second one is about the introduction (by a developer!) of a design system in a design-driven company, and all the complexities, the failures (the “dragons”) and the wins of this quest.

[Read More]

Circuit Breakers and Application Resilience

For most people circuit breakers are a concept that belongs in the world of electricity. They are usually a box of fuses under the stairs that prevents the tangle of extension cords from turning into an unexpected open fireplace behind the TV. But the concept of a circuit breaker is something that we can apply to software and software services.

Martin Fowler described a software circuit breaker as follows:

“… a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all”


OpenTable runs on many microservices that depend on one another to deliver the OpenTable site. These services can have dependencies on data stores such as MongoDB and Elastic Search as well as services such as RabbitMQ and Redis. Sometimes these dependencies can have performance or availability issues; such as when somebody accidentally drops an index on a collection in Mongo.

This actually happened, your author accidentally dropped a critical index while working with a DB synchronization tool which resulted in downtime. Hence this article.

[Read More]

Meetup: Frontend Refactoring at Scale

OpenTable is delighted to host the tenth WEBdeLDN monthly meetup with talks by Jack Franklin (Frontend Engineer at Thread) and Nick Balestra (Senior Engineer at OpenTable - Delivery Tools Team at OpenTable).

This month’s WEBdeLDN talks will be about frontend refactoring at scale with two real use cases: refactoring a monolith frontend application, as well as migrating a large, business critical application from Angular 1 to React.

[Read More]

Hosting external events

This June, OpenTable hosted the London Machine Learning Study Group to great success. We provided the food, drinks, and space for an extremely talented speaker and over 100 RSVPs. It was also my first experience hosting an external meetup at OpenTable - and I learned a lot!

My Experience

OpenTable has frequently hosted meetups in our office such as Web Platform London and WEBdeLDN. However, acting as an event host was a complete unknown for me, so leading up to the machine learning event, I made a point of sitting down with someone who had organised one before.

We documented the key steps in setting up an external event, and then published what we’d discussed on our internal wiki so as to avoid siloing useful information for future use. Following the steps documented in the wiki proved invaluable in reducing my stress on the day.

After our last event we also looked back on how we’d done the last few events.


[Read More]

Pragmatic Testing with GraphQL

We’ve been using GraphQL at OpenTable for a little over half a year now. I won’t go into detail as to why we started using it, but suffice to say, we really enjoyed creating our very first GraphQL endpoint. It eased a lot of the inconsistencies that we were experiencing with some of our REST-ful services.

This post assumes you have some experience building a GraphQL endpoint. For those of who you aren’t familiar with it, it feels a lot like having a querying language via an HTTP endpoint. If you want to try it for yourself, I recommend GitHub’s endpoint. To get started with GraphQL, the official documentation is a perfect place.

The Problem

Now, let’s get back to writing tests for an endpoint. When we were creating our first endpoint, we started facing regression testing problems while expanding our schema. It seemed our existing testing methods were ill-equipped to handle it.

Finding a good solution to this is important because I’ve had such a love–hate affair with testing. All tests are not created equal and a naive developer would say, “write a test in case something changes”. This certainly isn’t a good measure. I’ve also found that just attempting to write tests immediately without forethought can be a costly distraction if you grow your codebase.

The Approach

[Read More]

OpenTable's Global Hackathon 2017

Last week we were excited to kick-off our first OpenTable Global Hackathon, underway simultaneously in San Francisco, Los Angeles, Mumbai, Melbourne, and right here in London. Having personally never attended a hackathon before let alone helped organise one I was initially daunted, but with some careful planning, good suggestions from the team and a fair amount of making it up as we went along, the end result was quite a success.

This post discusses what format our hackathon took, what challenges we faced in coordinating across countries, the experience in the London office and what we learned.

The basic format

The hackathon was conceived in our San Francisco headquarters and could easily have been confined to that one office, but I was delighted to learn is was intended to be a global event from the outset. The basic format, described below, was however optimised for our SF office.

In the weeks leading up to the hackathon, individuals were asked to submit their hack proposals. Idea prompts were circulated such as “engages and delights diners” or “socially connected”, as well as the judging criteria; Originality, Feasibility, Likely to adopt, Fidelity of prototype, Business impact and Captivating presentation.

One week before the hackathon, our San Francisco office held a ‘happy-hour’ in which everyone taking part mingled and discussed ideas. This social event encouraged the developers, designers and product owners to self-organise into teams and submit their proposals in advance.

[Read More]

The goal driven organisation

Quarterly team goals are an effective way to establish organisational purpose, direction and alignment while supporting team agility. But be vigilant - they can be used inappropriately.


Due to factors such as growth, acquisition, changing markets amongst others, organisations can find themselves in new environments to which they struggle to adapt.

Scaling Agile in these new environments is hard. The practices and tools that are frequently used to solve this problem can give the appearance of acting against team autonomy and agility. Teams and individuals naturally try to protect the engineering culture that they have worked hard to establish but by allowing new organisational needs to go unmet they put their autonomy and agility at risk.

In this post I will show how quarterly goal setting, using Agile principles and with one eye on the dysfunctions that can arise, is an effective way to meet organisational needs while protecting team agility and engineering culture.

What needs are we trying to meet?

[Read More]

testing-node-apps-with-docker-compose (and some Soul)

Contents of this post

  • Purpose: the reason for this blog post.
  • Scenario: what this example of using docker-compose can be useful for.
  • Prerequisites: basic setup to be able to run the code contained in this post.
  • Code example: an actual step-by-step guide on how you can setup your test environment to run with docker-compose.
  • Improvements: a couple of ideas on how to expand this technique.


As I am sure the audience of this post knows to some extent, Docker is a technology that has grown to become popular over the last few years, allowing developers to deploy pieces of software by packaging them into standardized containers, in a number of various ecosystems (Apache Mesos, Amazon Web Services and many more).

So we can use Docker for our deployment needs, awesome. But let’s pay attention to a key word I used above. Docker grants isolation. And what do we like to perform on our application in isolation? Yeah, you guessed right – testing!

Specifically, with this post, I aim to dig deeper into how to use docker-compose (a specific Docker-based tool that enables creation of multi-container Docker applications) to build and run a Node.js application connected to MongoDB, to test their interaction and the interaction of the app with the external world, all inside containers running on your machine. All isolated and testable thanks to the usage of containers that we can spin up, hit with tests, and clean up with little effort.

[Read More]