DDD North is held every year at around this time. This year, it was on 14th October at Bradford University. In terms of the sessions that I saw, I think it’s probably amongst the best that I’ve attended!
This is a rundown of the sessions and anything I thought I might need to look into further (which, to be fair, is most of it!)
Session 1 - Nathan Gloyn - Microservices
Nathan started this talk by saying that, if you worked in the world of Microservices, you wouldn’t learn anything. This quickly became blatantly untrue (at least for me).
Amongst the talk, he mentioned the need for an external config management system, such as ZooKeeper. The reason being that, should you try to keep the config in a web.config type file (and use transforms to … transform them), you risk having to redeploy an entire system for a configuration update.
That you should log in a system that is running in a server that you have no direct access to is obvious, but he suggested keeping correlation Ids on the messages, so that the logs can trace a message as it travels through the system.
Regarding data updates, the suggestion was to keep the data updates separate from the app updates; and he came up with the intriguing idea of versioning the messages, so that the system can effectively self-update; for example, a message arrives in a subsystem saying it’s a version 1 message; the system realises that the latest version is 2, and so the update script is run then. This allows the system to gradually update itself.
Session 2 - David Whitney - Metaprogramming
This was a bit of a strange talk - as it started off, I couldn’t really work out what to make of it, as it seemed to be a “Have you heard about this thing called reflection?” But as the talk progressed, especially when the creation of a unit test framework was demonstrated in around 20 lines of code, the talk suddenly became very interesting.
One very interesting technique was that you could use reflection to register a set of default implementations for interfaces. Obviously, whether this would work in a particular project depends on why you’re using an interface in the first place, but in most cases, you’ll just want to be able to mock out your interface for a unit test, so you’ll have a one-to-one relationship between interface and implementation.
The other point of note was a mention of a method that allowed you to reflexively create a type without calling a constructor. I noted this down as CreateUnallocatedType, but for the life of me, I can’t find a reference to it anywhere. Please add to the comments or tweet me if you know what this is actually called.
Session 3 - Stephen Haunts - Scaling Agile
I hadn’t realised this until the talk started, but Stephen Haunts was unwittingly the person that got me interested in message queuing (through his Pluralsight course). The talk was effectively a review of how Spotify has scaled an agile team.
Amongst the overview of the specific scrum terms, I was pleased to see that Stephen referred back to the agile manifesto which, IMHO, is something that is frequently forgotten about (or in some cases not even known about) in some companies that claim to implement scrum.
One interesting concept was that of a feature train: the idea being that you work on your feature and, when it’s ready, it gets shipped in the next release. Stephen introduced us to a tool called Launch Darkly - which is a paid for product that allows feature switching.
Other established methods for scaling scrum teams that he mentioned were Scrum Nexus and Scaled Agile.
Session 4 - Stuart Lang - Async
https://speakerdeck.com/slang25/async-in-c-number-the-good-the-bad-and-the-ugly
This was probably my favourite talk of the day although, after dinner is possible the worse spot to have, as everyone is ready for a little nap. However, Stuart kept the subject alive and interesting.
The main focus of the talk was the SynchronisationContext - specifically focusing on deadlocks. The principle being that, while the base implementation of the SynchronisationContext (as used in a console app or a unit test) allows multiple delegates to be executed at any one time, all of the derivitives (WinForms, WPF and ASP.NET) do not. This means that, as much as it might be tempting to try these things out in a console app, or try to cover them with Unit Tests, the behaviour will change as soon as you drop it into your app.
Any app using .Result(), .GetAwaiter.GetResult(), .Wait() will be susceptible to deadlocks.
There were some workarounds that he mentioned; they were: - SetSynchronisationContext(null) - .ConfigureAwait(false) - Task.Run()
They all clear the synchronisation context, preventing a deadlock.
There is an Async analyser in Rosyln called Async006.
There is an open source impementation of a Context Free Task. It can be installed from NuGet, but at the time of writing, is still in a very early release.
The star of the show here is Microsoft.VisualStudio.Threading. It provides access to a JoinableTaskFactory, which implements the behaviour that you would expect if you did call something like .Result(). That is, it executes the asynchronous code, synchronously. This means, not only do you not block yourself, but you don’t spin up a load of pointless threads in the process.
Finally, ASP.Net Core does not have this problem, because of the way that it implements the SynchronisationContext.
Session 5 - Zinat Wali - Alexa
The last session was a talk on Alexa, and how you might write a routine that will report, and then predict the pollen count. The data training model demonstrated would be familiar to people that have seen Azure’s version of the same thing.