Andrew Poole
Senior Backend Engineer @ Flagstone, ex-ClearBank
Street, United Kingdom
Actions
Andrew Poole has been writing code for a living for 15+ years, most recently as an L5 Senior Software Engineer at ClearBank since 2020. He loves solving problems, design and architecture, communicating ideas and the incredible creativity of software engineering. He’s interested in event sourcing, immutable architecture and distributed systems. He also enjoy mentoring others and building great team culture. He has previously been a successful team lead, but what really drives him is striving to write elegant, intentional code which is easy to understand and maintain. He absolutely loves C# and only really dabbles in other languages in order to write better C#. Outside of work Andrew is a husband and father of 2 who enjoys playing bass guitar and making things in his shed.
Area of Expertise
Topics
Using .Net Aspire for next level devex and easy integration tests asserting against OTEL trace data
This workshop begins by discussing the usual issues with integration tests and how they expose the issues with running an app locally.
The workshop uses a realistically complex distributed/cloud app scenario i.e. multiple components; an API, ASB messaging, an Integration event listener, an Outbox using SQL server and a few external services.
We will cover:
* the step by step process of adding .Net Aspire and showcase its features
* adding additional OTEL telemetry to track interesting events, including persisting and rehydrating telemetry through the outbox phase
* creation of integration tests covering end-to-end flows using Open Telemetry data for assertions.
The end goal is to have a repo which when pulled down onto a fresh machine, builds first time, tests pass first time, then having run the Aspire AppHost, the the integration tests pass first time, effectively demonstrating how the problems described initially can be solved.
All code available on GitHub
There will be branches available for each stage
Getting maximum mileage from a minimal number of tests
🚀 Discover an automated testing strategy that enables you to test complex e2e flows, involving multiple executables, all in-memory, fast and also enjoyable to use!
Imagine a unit test where rather than the 'unit' being as small as possible, it is as large as possible, actually potentially multiple executables! A single test can cover the whole happy path flow of a complex piece of orchestration, from API handlers, service bus handlers, database calls etc, all in-memory, fast and with a nice fluent developer experience!
I start by outlining a realistically complex scenario of a distributed/cloud app with an API, an EventListener and an Outbox and a couple of external dependencies.
I cover how to construct a test framework and use of various libraries to help. I cover how to create Given, When and Then classes to organise re-usable code, leading to tests which read like concise plain English. I demonstrate ways to Fake Azure Service Bus behaviour and how to wire up API calls between components of the system under test, also options for database contexts and how to use the FakeTimeProvider to bend time to your will to create stable tests even for temporally complex scenarios. Because everything including the Program.cs and startup code are effectively tested we can spot configuration and IoC issues which are hard to test with more traditional methods.
This session will include slides with code snippets and live debugging demos, quite possibly also some live coding
I need enough space for my laptop, mouse and a small external monitor, at standing height
Fluent Method Chaining in C# and creating super clear orchestration code!
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug. The flows are self documenting and with some thought, even readable by product owners and business analysts etc.
Keep calm and carry on? Navigating difficult times as a software engineer
I've been a software engineer for quite a while now, I'm a senior, I'm not an industry leader or anyone special, but I have worked for several organisations and been through enough difficult periods in my career to have collected some stories and learned some lessons. There are several things I'd tell my younger self if I could, but I can't, so I'm sharing them in this talk instead!
My stories are:
* stepping up: a period of time when our team lost its product owner, business analyst and had no scrum master/agile delivery person, how we really self organised and experienced great success.
* stepping back: a period of time off sick and a phased return to work following very difficult circumstances at home
* stepping in: several times I've had to speak up for people who felt they had no voice
* stepping away: deciding to switch team/domain after 2 years worth of development, complete with heart and soul poured in was scrapped due to issues getting various business functions to agree
* also re-orgs/re-structuring - no-one tells you about these sometimes devastating but depressingly common events!
This is a new talk, the target audience would be software engineers, especially those towards the start of their careers.
Leeds Sharp
What if there was a way to declaratively describe a chain or flow of methods, especially async methods, which could be used when handling API requests or messages from a queue or anywhere actually? What if that flow of methods was self-documenting and understandable at a glance?
Recently, while refactoring a growing piece of business logic, my team and I found a way to achieve this. My talk tells the story of that refactoring journey. It is a mixture of slides and live coding demos in Visual Studio, where I show that the flows of chained methods are easy to read, navigate, debug and test. We end up with orchestration code which describes a whole system or vertical slice and, with some care, is even readable by product owners and business analysts!
.Net Cardiff
Kevlin Henney will be exploring the evolution of programming languages. By looking back at the past, Kevlin will examine how current trends, from FOSS to LLMs, will shape programming languages and their use in the future.
Andrew Poole shares his valuable insights into declaratively describing a chain or flow of async methods, which can then be used when handling API requests or messages from a service bus queue or actually anywhere.
dotnet York
Fluent Method Chaining in C# with Andrew Poole
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere? Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug. The flows are self documenting and with some thought, even readable by product owners and business analysts etc.
dotnetsheff
Fluent Method Chaining in C#
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere? Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug. The flows are self documenting and with some thought, even readable by product owners and business analysts etc.
DDD South West 2024 Sessionize Event
.net London Meetup
Async method chaining in C# => super clear orchestration code
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, Andrew found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
.net Edinburgh
Andrew Poole: Async method chaining in C# => super clear orchestration code
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, Andrew found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
Cheltenham and Gloucester Tech Meetup
Andrew Poole: Async method chaining in C# => super clear orchestration code
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, Andrew found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
Developer South Coast Meetup
Async Method Chaining in C# with Andrew Poole
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere? Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
.net southwest meetup
Async method chaining in C# by Andrew Poole, lead software engineer at Clearbank
What if there was a way to declaratively describe a chain or flow of async methods, which can be used when handling API requests or when handling Messages from a service bus queue (or in fact anywhere!) We have found a way to achieve this and the logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is extremely clear and easy to navigate and debug.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top