Sunday, 15 November 2015

API Testing Patterns for the Play Framework

A robust suite of end-to-end tests for your APIs gives you the confidence to iterate and move quickly. With APIs being easier and faster to test than web frontends, the invaluable benefits of testing come at a low cost of investment.

Two of the key challenges when creating API tests are expressing the desired system-level behaviors precisely and, more technically focused, deciding how to cover external dependencies.

After a few years of working with the Play Framework I’d like to share a few of the testing patterns I am using to both solve the challenges just mentioned and create tests effortlessly and productively.

Sample code to accompany this blog post, including a vagrant dev environment, is available on my github.

Wednesday, 21 October 2015

Strict JSON Deserialization with Enum Validation

It's important to validate data sent to your APIs. Silently ignoring unrecognised fields or not detecting and rejecting values outside of the allowable range is a dangerous way for errors to go undetected.

Clients will be calling your API, getting a 200 response and blissfully assuming everything is wonderfully integrated. Enraged customers will eventually find the problem and it won't result in you getting a pay rise.

These risks are especially inherent to JSON APIs. With XML we have XSDs to enforce the schema. We haven't quite got there with JSON yet, so it's vital to be extra vigilant in your code.

I recently found out that it's actually not as easy as it should be to reject unrecognised JSON fields and out-of-range enum values in Scala (using the Play Framework).

Thursday, 8 October 2015

Sharing Databases Within Bounded Contexts

A contentious topic in distributed systems is if/when/how to share databases. Some developers/architects will tell you never to do it. Others, like me, will cautiously mention a few acceptable scenarios.

"Components [within a bounded context] work together very closely; therefore, having shared dependencies increases cohesion... without necessarily causing problems"

Patterns, Principles and Practices of Domain-Driven Design

Who is right? What is the one true way?

In this blog post I won't be wasting time on such futility. Instead I’ll be elaborating on my belief that sharing databases, and other dependencies, within bounded contexts can be sensible and savvy.

Thursday, 10 September 2015

Please Use The Cascade Rule

Amongst all the hype of shiny new technologies, fashionable working practices and clever design patterns, sometimes I think the absolute basics of writing readable code are ignored or discarded as boring. I can’t think of a more saddening example than the unloved cascade rule.

Please can we use the cascade ruuuule?

We write code from left-to-right because we read left-to-right. Our eyes go from the left of the screen to the right, and then down to the start of the next line. It’s easy and comfortable because that’s how we read books and articles.

Logically, then, we should write code that reads from top-to-bottom since our brains are trained to read that way. That's all there is to the boring-but-effective cascade rule. It makes code easier to read and I love it.

Saturday, 15 August 2015

Domain-Driven Architecture Diagrams

Domain-Driven Design is about creating shared understanding of the problem space that is reinforced ubiquitously via conversations, code and diagrams. DDD’s Shared understanding enhances synergy and alignment, increasing the ability to deliver value sustainably - ideally over the lifetime of a product.

As I most recently attempted to justify at the London Women Who Code Intro to DDD Architecture workshop, the architecture of a system, expressed via diagrams, is a profitable avenue for reinforcing DDD’s shared model.

Highlighted in red: where architecture diagrams can be advantageous using a domain-driven approach.
Diagram modified and borrowed from Patterns, Principles and Practices of Domain-Driven Design published by Wrox

Saturday, 25 July 2015

Trying to be a Good Code Teacher

It's a privilege to be responsible for the education of others. But it's also tiring, relentless and a tough lesson in modulating your emotions. Undoubtedly, teaching programming is hard, especially on-the-job training where you are under pressure to produce deliverables.

Thankfully, playing the role of teacher also confers enlightening personal growth. Guiding a learner's progress is rewarding; dynamically tailoring their learning plan in real time is a vigorous lesson in empathy; and trying to inspire the persistent desire to learn in others is a marathon of emotional intelligence training.

The opportunity to teach others is an opportunity for immense self-growth and self-exploration. By writing this blog post, I hope to solidify my learnings as a teacher and contemplate how I can improve on my many weaknesses.....

Sunday, 14 June 2015

What I Learned from the Business Model Canvas Workshop

How can you make developers happier, more engaged, and poised for innovation? If you relied on developers to achieve your goals, how would you foment these potent productivity multipliers?

My feelings, as a developer, are that freedom and responsibility are the key - explain the problem, and then let me and my team pursue your goals with frequent collaboration and minimal constraints. I say this because when I am not being pressured, and I feel important, that’s when I feel at my absolute best. My developer friends express this preference, too.

Freedom and responsibility are extremely dangerous, though. Not only can they unlock peak potential, but they also risk catastrophe. Instead of helping our organisations to steam past competitors, we can can get too focused on clean code or microservices, forgetting we are supposed to be making someone's life better.

If we want the freedom and responsibility, we need to have a deep situational awareness. This is why I think the Business Model Canvas is a marvellous tool for improving alignment between developers, executives, and just about anyone else in an organisation.

Having experienced the alignment benefits of the Business Model Canvas, I wanted to get the opinions of others who have operated within a variety of different organisational structures and cultures. So I ran a Business Model Canvas workshop for the London Agile Leadership Community.

In this post I will tell you will what I learned at the workshop and where I am focusing on improving my understanding in the future.