Three-and-a-half Ways of Testing your Repositories

Repositories are the abstraction we use to store our data model in Domain Driven Design. Outside DDD, it's the interface between the database and the application.

I've seen a lot of codebases where the database interface isn't properly tested. Most often because it can be difficult to write proper tests for that, and as such it is often skipped.

In this talk I will use Test Driven Development to show how to use mocking frameworks to mock datastores at both the API-, and server-level, and show techniques to test against a real database as well as how we can make the tests more portable by leveraging containers when appropriate.

Test Driven Development for Everyone

“There is never enough time to do it right, but there is always enough time to do it over.”

~John W. Bergman

Test Driven Development (TDD) is a powerful approach that yields better, less buggy code. So why aren't everyone doing it?

In this hands-on workshop, I'll explain what TDD is and why I think it's so good. We'll also try it out for ourselves, using some real-life examples. You'll get to see how TDD makes writing great code simpler and gives you a safety net for when you have to make big changes to your code.

Bring your laptop and a programming language you're comfortable testing in. If you're new to testing, we've got you covered with starter projects available in multiple languages like C, C++, C#, Java, JavaScript, Kotlin, Python, Rust, and TypeScript.

We'll explore how to plan tests, the role of refactoring in TDD, and the benefits of designing code a bit at a time. Plus, you'll learn how TDD can make your code easier to read and keep up to date, and how it can help make your software more reliable.

Collaborative learning will be a key element of our session - coding in pairs is not just welcomed, it's actively encouraged! Let's embark on this exciting journey of creating better, cleaner, and more reliable code through Test Driven Development together.

This workshop was first given at JFokus but has been given at private companies after that. I can be adjusted in length with a minimum of about 2 hours and a maximum of around 6 hours.

For smaller groups I like to do an ensemble-session before everyone starts on their individual/paired assignments. This requires a longer workshop and a group of maximum 15 attendants.

Thawing Java on AWS Lambda: Reducing cold start times from 6 seconds to .1

Java has never been a perfect fit for Function as a Service platforms such as AWS Lambda or Azure Functions. While both platforms have official support for Java, Java functions unfortunately suffer from significantly longer cold start times than many other runtimes.

In this talk I will show a simple Spring Cloud Java function running on AWS Lambda with fairly horrible cold start times of around 6 seconds and then compare a few different approaches for significantly improving it. Eventually ending up with a cold start time of just 600 milliseconds - making Java a viable, though not without drawbacks, choice for FaaS platforms.

First given at JFokus 2022, but also given at CraftConf, AllDayDevOps and Devoxx.

30-45 minutes.

Test, Code, Repeat: The Secret Sauce to Business Superpowers!

Do you know what software delivery performance is?

It sounds like something you should be good at - are you?

What's the difference between a strong performer and a weak?

In this talk we will discuss software delivery performance, explain what it is and how it relates to your Business. We will also posit that automated testing is one of the most important aspects of software development when it comes to how software enables your business.

This has previously been given at internal company conferences to great effect, with more than one product manager calling it "eye opening".

Pipeline Patterns and Antipatterns - Things your Pipeline Should (Not) Do

Automated pipelines have become an integral part of our daily workflow. As the pipelines become increasingly important, the demands placed on them rise proportionally.

As with many things, a great pipeline operates seamlessly in the background, while a poorly designed one becomes a constant irritation.

Are you publishing your artefacts every time the pipeline runs, running all steps in a sequence, or installing all the tools every time a new build starts?

In this talk, I will address these antipatterns and more I have encountered during my work as a consultant, explaining why I consider them such and what you should do instead.

After listening to this talk, you will better understand what makes a pipeline great and concrete things you can do to improve it and shorten the feedback loop.

Strangling the dragon: modernizing legacy systems with the Strangler Fig pattern

Stuck in a legacy system that needs modernizing? Feel like the best course of action is to throw it in a dumpster, light it on fire and rewrite everything from scratch - maybe even in a different language?

Hold that thought. While it may be tempting to start a rewrite, rewrites of complicated systems rarely succeed for multiple reasons. Chief among them is time and the fact that not everything can stop and wait for the rewrite, but another important contributor is the second system effect, which usually causes rewrites to be of lesser quality than that which they replace.

In this talk, I'll share my experiences with the Strangler Fig pattern, a better approach where the original system is gradually replaced by breaking out or rewriting parts into separate systems. I'll also talk about combining this with Domain Driven Design and how to use the new design to execute an Inverse Conway Manoeuvre to ensure you're working with Conway's law and not against it.