This year has been the best in a long time. I’ve relaunched this website, spoke at conferences in many countries on two continents, met hundreds of you, restarted work on both OpenRasta and “the book”, albeit not as much as I’d have liked, launched the httpapis.com chat room, worked with great clients and even greater people, laughed, cried and generally lived. There were a few downs, some friendships disappeared, some people upset unintentionally, some projects didn’t happen, and on my path of self discovery, some cuts and life changes had to be made. So is life, up and downs often feed one another. I wouldn’t have had any of the great times without an amazing group of people around me, and for once I’d like to tell them how much it all means to me. I may edit the post as I remember more names, I do apologise to anyone I forgot, it’s probably only temporary!
Thank you to my family, for having me, being there, inviting me to share your happy and your less happy moments. I’m very glad and very lucky to have such a fulfilling environment. A special thank you to mom, for being there through everything over the past 35 years, such endurance! Than you to Dominique, for making LA peaceful for me; Thank you Nana for organising a surprise birthday dinner, first one I ever had. Thank you to all the others, I love you all, you know who you are.
Thank you to my friends, old and new. Jon and Simon, always there in my life. We’re ageing rather well, and I hope we continue Friday nights for many years to come. Thank you to my favourite BA, Rossana, I’m so glad to see you grow year on year, your strength and determination is a lesson to us all. Thank you to Marion, Pierre, Marie, Christina and Alessandro, for all the good moments we have in Monaco; Colin and Paul, ever present, kindest spirits, Scotland feels at home thanks to you; Didier, you made it in Barcelona, thanks for a great night; Richard, I don’t see enough of you, but you’re with me on all my easyjet flights nevertheless.
I can’t not mention all the geeks I have spent such a good time with, and I am very privileged to call friends: Toby, for being the best maintainer of OpenRasta since ever; Ian for making sure hugs go around, people and repositories alike; Liam without which cheese wouldn’t have the same appeal; Dylan, a rock I have had the privilege of hanging on many times; Ben and Barbara, so many dinners, good times and swimming pool moments, one of you get a ring on it already; Barry and Nikky for being the best hosts in Seattle, the seafood buttered orgy memories will stay with me forever; Glenn, for the great times in Portland, our conversations, and your enormous kindness; Chris and Joao, I wouldn’t enjoy lunches without you, and your work to promote diversity is so badly needed in our industry; Adam, Vancouver wouldn’t be the same without you, and no I won’t switch to Linux in 2017, maybe the year after :-P; Jef, those selfies turned out pretty great, and thank you for making me discover the wonders of Caesar cocktails, they’re pretty awesome.
You spend a lot of time with clients, and I’ve been very lucky to work alongside pretty awesome people: Dave, welcome to adulthood; Nigel and Chris, Brighton was such a fun time, just what I needed to start the year on a high note; Allan, Simon, Atif, Matt, Aaron, Sam and the others, you make that office fun to be in, here’s hoping I spend more time there.
Conferences have been amazing this year, and it wouldn’t happen without organisers sweating their arse off for months to enable us a platform for sharing knowledge. I can’t mention you all, it takes a village, but a few special mentions are in order, in no particular order: Jakob, you make NDC great, and that beach day and dinner was awesome, we should do more of that; Iva for making Las Vegas happen; Dominika and the whole crew at get.net, your dedication and support went well beyond the call of duty, thank you for everything you did; Andreas for tirelessly giving me more speaking space at Oredev, I had such fun in no small parts thanks to you; Anna and Yann, for being the most organised and efficient planners I’ve ever met, and even better skiers, thanks for the opportunity to discover Whistler and Vancouver; Todd for making conferences in pubs possible, I can’t believe you managed to haggle that jumper from that waitress, this is tons of awesome.
Sickness is part of life, and this year has been very tough on the people around me. I’ve done the dryathlon in September, and collected a bit of money for cancer research, because I think of you all often: Laurie, Violaine, Morten, Patrick, Steven and Anthony, your strength of character is enlightening. To those that didn’t pull through, thank you for having been in my life: Mark, I will never look at a Guinness without thinking of you, you would have loved your send off so much; Pieter, you loved your send off, and I’ll always be grateful for your guidance, late night skype sessions, and your guide to psychopaths, I was brought out of the darkness in part thanks to your vision.
Thank you to the people of the two slacks I always stay on, ddd-cqrs-es and httpapis, your insights are humbling, and banter refreshing: Damian, Dan, Joao, Adam Ralph, James G, Mike Amundsen, and all the others. And for those that were in my life and no longer are, I wish you all the best in your endeavours, let your future be bright and your life full of love and happiness.
Happy old year to one and all.
]]>Mocking frameworks are actively harmful, and probably infringe on my human rights.
It’s not just a matter of taste, there are fundamental issues that make it harder to design good and maintainable software.
The code starts simple enough, you write a class, you mock the first interface’s method it implements, test pass, you move on to your next test.
After you write 50 tests, you end up with 50 implementations of the same method, littered all over your testing code. Some will argue that it’s just a matter of reusing and refactoring your test code. If you’re going to reuse your mocking setup, then…
I already made that point a long time ago: mocking frameworks are a poor way to implement fakes. The code is noisy, with some frameworks it does not refactor well, and let’s face it, no amount of magic will compete with writing classes in an actual language.
If you have a one-off method on one interface that has 50, and you are already in hell, maybe a mocking framework will help you. Those cases are rare and don’t explain how often these things get used. Given the choice, I’d split the interface into smaller chunks, and test that. It’s easier and result in cleaner and simple code, and seggregates functionality as you refactor.
The author of a class or interface is the closest to knowing the contract. Understanding when the code throws, what arguments can be null or not, and what values will cause error is a matter for the contract author to define. This is done in documentation, type systems and / or pre/post conditions.
When you fake an interface you don’t own, you have to re-implement this contract, and often you will not know enough to implement this correctly. In a VeST library, the author would be the one providing the test double for you. If you do not, then implementing a fake only once, by refactoring it continuously with your new understanding of the contract will allow your whole testing codebase to improve under those scenarios.
It’s however very common for you to own the interface, the implementation and the consumer, at which point you’re in the best position to do the right thing, and ship fast in-memory versions of the implementations you expect people to use.
If you don’t, you risk hitting the next issue.
An object, in object-oriented development, is by definition encapsulating data and behaviour. Each object is a black box, that you can tell to act, hence the “tell, don’t ask” mantra.
Because an object may use one or many dependencies, building the code by stubbing each method of a dependency as you go along, you implement in your test a lot of knowledge of the inside functioning of your class. This breaks encapsulation, which makes your tests brittle, and refactorings harder.
Out of all the issues I’ve already discussed, this is probably the least visible immediately, especially in a world of package managers.
Over time, frameworks and libraries are like fashion, they get in quick and loud, and they get replaced by younger, slimmer next generations, and on and on.
Your test code, just like your applicationcode, suffers from this. The cost of rewriting all test doubles using littered mocking frameworks is high, and you hit the pit of failure. It doesn’t get done. You end up in nonsensical situations, having 4 mocking frameworks in the same library, in code that hasn’t been refactored or touched in years. This code is, for all intent and puproses, dead. And mocking frameworks were probably an accessory to murder.
This was a thing for a long time, and it is very unfortunate that people still try to do this. The combination of containers, automocking and large dependency trees result in many issues that make code more and more costly to keep.
Large amounts of dependency in a class is a tell-tale sign it’s doing too much. Stop feeding that class new responsabilities and split it.
Large dependency graphs often are because it’s easy to take a dependency, and results in overly-complicated levels of abstractions that serve no purpose. You neither need a repository wrapping a data access class wrapping an actual vendor library, nor do you need 3 levels of logging frameworks talking to one another.
And finally, the encapsulation breakage is worse than with a single class, it now pans out to a whole object tree, making your tests even more brittle. Friends don’t let friends use auto-mocking containers.
I mention this only for the sake of completeness, because that’s one part of mocking that is not used as much anymore. Interaction testing wants to know how and how often dependencies’ methods are called. This is even more non-sensical than the precedent breakages of encapsulation, you write a class and write a test to verify exactly what the class ends up doing.
Interaction testing has a place, but it’s very small, in a very limited number of scenarios where it’s not possible to test visible effects of the various calls made to a system.
Mocking frameworks are nearly always the wrong choice: they are not a good way to write classes, they lead to the path of brittleness, badly factored code, unwildly class hiearchies, and code duplication.
Do yourself a favour, write in-memory fakes and ship them alongside your code.
]]>Messaging is a good example. I’ve been working on distributed messaging systems for eons now, and I see the same implementation over and over again.
// not an actual library
MyAwesomeQueueSystem
.ListenOn(MyFabTopicNameBuilder("home"))
.IntoQueue("reaction")
.Handle(message => new MyHandler().Handle(message));
class MyHandler : IHandle<Event> {
void Handle(Event) {
if (Event is Spider)
me.Jump();
}
}
If you look at this code as-is, you can only know that a thing happens that causes a message to be posted and a “handler” to “handle” said message.
In reality, external stimulii often trigger certain actions from us, which themselves cause other events. An enormous spider next to me may make me jump which may well result into me breaking glasses. I have external stimulii that I know, like spiders crawling, which are events. I have commands, like jumping. I have breaking glasses, which are other events.
Now that explanation makes sense, but the code is not giving you that. The code gives you a very different explanation. The sun, through thermonuclear reaction causes photons to travel at the speed of light all the way through my windows to my sofa, which get scattered by a calcium-based molecular structure, hitting my retina. Through a set of neurons interconnected through electrochemical connections, triggers a flight response, releasing a high dose of adrenaline, causing an automatic muscular response…
The description is now too detailed, and it becomes very hard to know why I broke the glass. It would also become increasingly difficult to explain to you various other reactions that would lead me to break the glass. Without a model, I can’t explain clearly that a divorce and a zombie would also cause me to break glass.
In terms of code, the fact that we focus on the low level of event subscription doesn’t allow us to do anything but what the procedural code dictates, introducing systematic variance, not due to need but due to having no model.
It also prevents us from reflecting on the model. I used to have panic attacks when boarding plane, which for a conference hopper is a rather problematic condition. It’s only once I managed to model my triggers, and model my commands, that I managed to get rid of it. All the same, in code, without a model that can be introspected on, I have no way of reflecting on what my software does, be it that I want to understand it, or like Simon Brown does, document, graph and represent it.
Instead of going for pure messaging, model your messaging patterns to encode
in your code what concepts they implement. For example, instead of the
IHandle<T>, why not model what you do?
public interface IHandleComponentCommand<T> {
}
public interface IListenToExternalEvent<T> {
}
Going one step further, both OpenRasta and FubuMvc used to favour the idea of a configuration model, where all information about your system are pulled into before you actually spin up the system. This allows any further component to have enough information to configure queues, add http handlers, and everything else you may need to spin up the software.
If your model is not rich enough to generate all the plumbing from it, then your model is insufficient to document what your software does. And when you need something that your model can’t cope with, update your model.
]]>Thanks to all that attended this talk at NDC and Progressive.net!
]]>You can join the HTTP APIs Slack channel now.
There isn’t a code of conduct yet, but I’ll be discussing with the community to set one up shortly. In the meantime, be kind, be nice, and think of others.
Feel free to share the link with your communities. Welcome.
]]>I’ll be presenting a newer version of my “versioning is evil – how to do without in your http apis”, with code samples.
If you haven’t yet, register now and use the code SPECIAL_LDNUG_PROGNET for 40% off, but be quick, the offer expires soon!
]]>I’ve had a great weekend recelty at DDD Scotland, if you haven’t been, just go. The atmosphere is lovely, the conversations interesting, the food good the attendees (and organisers!) very friendly.
I presented two talks, my Versions are evil talk on how to avoid versions in Web APIs, and a new one, Alice in Agile Wonderland, a keynote-style story of all that goes wrong in the wonderland of agile, which I had much fun delivering.
Comment sections have been added to the various talks, so if you have been there and want to continue the conversation, there’s a place to do that. I’ll post the various ratings for each of the talk as the next update to this site, and if I get a bit more time all the questions I can find that were asked at each of those talks.
I’m also thrilled to be presenting at NDC Oslo a revamped version of the “Versions are evil talk”, at PubConf Oslo with “How to always be right on the internet”, and to be presenting at Oredev a bit later in the year with a completely new talk. I’m hoping to see you there!
]]>count, and so reusing a module a dynamic number of ways is impossible. To work around this, we can rely on a small DSL and null_resources.
Same advice as previous entries apply, this is advanced stuff, harder to read and more complex, use with caution and for good reason.
Let’s imagine that I have a module that spins up a variable number of machines, one per release branch in my source control system. Due to the dynamic nature of this, and without access to count on module, i’d either have to use a templating language, something i’m not happy doing, or I’d use a little dsl.
I’ll define my module with a variable called instances, with a format I invent, a coma-separated list of instance names and their instance types, themselves separated with a colon.
variable "instances" { default = "webserver:t2.micro,api:t2.small" }
We already know that split allows us to have collections by splitting strings, so the initial, and pretty unreadable, first step is to abuse string interpolation as is.
resource "aws_instance" "servers" {
// number of servers is simply the string split by coma
count = "${length(split(",",var.instances))}"
// name is the first bit in each string
name = "${element(split(":",element(split(",",var.instances),count.index)), 1)}"
instance_type = "${element(split(":",element(split(",",var.instances),count.index)), 1)}"
}
My brain has already melted. Things get a bit easier if you pass lists around, but not that much.
One alternative is to create a instances and instance_types variables, keeping two lists in sync makes interpolation a bit less obtuse, but as a user makes things pretty hard to get right.
Another one is to use the less-known null_resource. We abuse its triggers a little bit by doing the splitting there instead, which allows us to give nicer names to things.
resource "null_resource" "let" {
// we reuse this in all counts because count only interpolates from variables
count = "${length(split(",",var.instances))}"
triggers {
// we do the coma splitting here text splitting here
server_raw = "${element(split(",", var.instances),count.index)}"
}
}
resource "null_resource" "servers" {
count = "${length(split(",",var.instances))}"
triggers {
// we do the colon splitting here
name = "${element(split(":",element(null_resource.let.*.triggers.server_raw, count.index)),0)}"
instance_type = "${element(split(":",element(null_resource.let.*.triggers.server_raw, count.index)),1)}"
}
}
We’ve now kept all the nasty string processing somewhere away from our resources. It has an added bonus, the tf plan is rather useful to read:
+ null_resource.let.0
triggers.#: "" => "1"
triggers.server_raw: "" => "web:t2.micro"
+ null_resource.let.1
triggers.#: "" => "1"
triggers.server_raw: "" => "app:t2.small"
+ null_resource.servers.0
triggers.#: "" => "2"
triggers.instance_type: "" => "t2.micro"
triggers.name: "" => "web"
+ null_resource.servers.1
triggers.#: "" => "2"
triggers.instance_type: "" => "t2.small"
triggers.name: "" => "app"
We can now declare our instances using some better symbolic names.
resource "aws_instance" "servers" {
// kept so we can interpolate correctly
count = "${length(split(",",var.instances))}"
name = "${element(null_resource.servers.triggers.*.name, count.index)}"
instance_type = "${element(null_resource.servers.triggers.*.instance_type, count.index)}"
}
If you can’t avoid the complexity, with this trick you keep it localised and more readable. Terraform will soon allow lists and maps passed to modules, but count is still somewhat far off. If you’re interested in an alternative syntax I suggested, check out the github issue.
]]>Note that the strange syntax I show you are obtuse, and while someone who has done terraform for a while may well recognise the patterns, they’re non-obvious and come with an increased cost in complexity and maintenance. Make sure you make the right decision between all the costs associated with reuse.
So let’s say you have a module that registers an auto-scaling group, but you want to allow module consumers to pass an elastic load balancer they defined themselves. The naive approach would be to just pass it in the array attribute.
variable "elb" { default = "" }
resource "aws_autoscaling_group" "asg" {
// stuff here
load_balancers = ["${var.elb}"]
}
If you try to apply this, it will return an array of 1 with an empty string, which is not what the api expect.
The trick here is to force turning the string in an array.
resource "aws_autoscaling_group" "asg" {
// stuff here
load_balancers = ["${compact(split("",var.elb))}"]
}
And voila, an array of 0 or 1 element. Note that this problem will go away with terraform 0.7, as modules will be able to take lists as variables.
]]>