NDC London Day 3 Retrospective - from personal projects to developer comedy
So, my time at NDC 2020 has come to an end. But before I make any more general observations, here's my thoughts on the sessions I saw on day 3.
Crash, bang, wallop: miscellaneous lessons from exploring a drum kit
On Friday morning, technical interest won out over practical use, and I found myself at Jon Skeet's talk on programming an electronic drum kit.
https://twitter.com/jon_george1/status/1223173406767702016
I spent the first few minutes trying to work out what the heck he was wearing. I eventually managed to work out that it was a pair of trousers sporting the EU stars to celebrate our day of national self-harm, coupled with a t-shirt offering a discount on his book. Never let it be said that developers can't be stylish.
Once that realisation was dealt with, I was able to focus on the talk in which Jon gave us a walk-through of his voyage of discovery, which was based on his acquisition of an electronic drum kit. He talked about the various challenges he faced whilst interfacing with the control module (such as the difficulties of working with 7-bit addressing) and how he dealt with these from a design perspective. This also included the problem of two-way references with immutable data types, and the discovery of the extensive technical documentation that accompanied his kit.
The main point of the presentation was the joy of working on a personal project; free of external pressures and doing it just for the fun of it, setting off without any real idea what you'll get out of it and just finding out on the way.
Another interesting observation was the different perspective that learning something completely new gives you; Jon reflected on the unexpected side effect of learning the drums; he ended up noticing the drum parts far more in the music he listens to, and appreciating them more. He suggested (rightly, in my opinion) that this reinforces the value of diverse teams - a group of people with similar life experiences naturally has a more narrow perspective on any given problem than a team from different backgrounds.
Drinking a river of IoT data with Akka.NET
My next session was on something completely new to me, AKKA.net and the Actor model, given by Hannes Lowette.
This talk was split into two parts; the first gave an introduction to the Actor model, and the second discussed how this was applied to a specific problem domain, that of collecting data from smart meters.
Unlike some of my endjin colleagues, I don't have any practical experience with the Actor model so the first section was of more interest to me. Hannes took us from the origin of the model as an academic publication to implementations in Erlang, Scala and, finally, .NET in 2015, when three Actor model implementations were released almost simultaneously - AKKA.net, and Microsoft's Project Orleans and Service Fabric Reliable Actors.
He then dug into the purpose of the model and what it enables - namely, a high degree of parallelisation for stateful systems, which is growing increasingly relevant as CPU clock speeds level out but core counts increase. We continued with a deeper look at how AKKA.net implements the model, with Actors and ActorSystems, how the hierarchical relationships between actors work, and how you can split workloads across actors.
The remainder of the talk was in the context of an example architecture for handling IoT data from Smart Meters, and covered a number of design patterns and other interesting features of AKKA.net, especially around scaling, persistence, clustering, and so on.
This talk definitely piqued my interest in the Actor model and I'll be doing some further reading in the near future. Oh, and it had memes, which is always a win for me...
https://twitter.com/jon_george1/status/1223212846105931776
Introducing the benefits of the testing diamond
For the after-lunch slot, I decided to return to more testing with this session from Moreton Brockley. Again this wasn't exactly what I expected, but was still interesting. The main focus of the talk was about the value provided by different types of testing.
Essentially, Moreton's message was that we should treat testing in the same way as we treat every other product and look at what that product delivers (it's value), how we talk about it (language) and how we approach it (strategy).
He split value into three areas: confidence, documentation and feedback. Confidence talks about tests delivering confidence that the thing they are testing works as expected. Documentation looks at tests as documentation of the code they test - they essentially specify it's expected behaviour. And feedback is about the ability of tests to tell a delivery team when they have caused issues with their changes.
Language looked at the different types of tests, how we talk about them and the value each provides, along with their trade offs. Moreton talked through a variety of tests, from difficult but high-value (UI end to end tests) down to easier but individually lower value unit tests.
Finally, Strategy was about how the different types of tests should be brought to bear on different types of application. For example, an SPA will benefit from a different set of tests to an API.
The overall message was that testing is a very grey area and the answer to most questions is "it depends". Taking a product-oriented approach to delivering tests and talking about them in terms of value and strategy should help us sort through some of the confusion and ensure that the testing approach we take for our projects is well defined, understood and executed.
Combatting illegal fishing with Machine Learning and Azure – for less than £10 / month
For me, this talk is a different spin on the "personal project" as it's one I was actually involved in! Endjin's Carmel Eve and Jess Panni gave a great run-through of how endjin approached a really challenging cloud migration project for OceanMind, taking them from an on-premise system that relied on batch processing of a subset of their incoming data to a cloud-native solution based on commodity compute that was able to process all the incoming data in near real-time.
https://twitter.com/Carmel_Eve/status/1224277454635896832
Obviously I'm somewhat biased, but this was a great talk with a lot of valuable lessons. Don't just take my word for it, go and watch it yourself (as soon as NDC publish the session videos!).
The Reduced NDC Company
Taking his inspiration from the Reduced Shakespeare Company, Mark Rendle's final talk of the day (with help from ) was pitched as a presentation of all 90 sessions from the three days of NDC sessions, packed into 60 minutes for our viewing pleasure.
To make this process easier, Mark avoided actually attending any of the sessions or reading the synopses, making it easier to summarise them. I won't go into the detail, but it was an enjoyable way to end my first NDC.
The End
https://twitter.com/jon_george1/status/1223299042198855682
So, my first NDC is done and dusted. It was an enjoyable three days and I'm happy that I managed to strike a good balance between sessions that were directly relevant, those that were technically interesting but practically not much use, and ones that expanded my knowledge by giving me an introduction to new things. I didn't feel like I'd wasted my time in any of the sessions I went to, which is always a good thing.
There were a few subjects that seemed over-represented - microservices and Blazor, for example - but there was plenty of other choice as well. Overall I think the event was well executed and I'd definitely be up for attending again in future years, which is a good measure of success for me.
