SDD 2022 Schedule

No matter how much advancement we see in programming tools and hardware technology, software development remains resolutely difficult. The preoccupation of today’s developers is exactly what it was fifty years ago: how can we create software which works reliably, and how can we extend it without breaking it? We just accept that software is inherently flawed, that all software contains bugs like original sin, and we design our processes around that. But what if it were possible to write software correctly? What if we could create bug-free, maintainable code? And what if it were cheaper, faster and easier to write correct code than to write the buggy variety? What then?

It turns out that it is possible to write perfect code. In fact, perfect code is not that uncommon – we have been entrusting our lives to it for decades. What do they do, these perfect programmers, that the rest of us don’t? What research backs up their practices? Can we all do what they do?

This workshop is for developers who want to eliminate not just 95% of their bugs, but all of them. Here’s what we’ll cover:

• Good code
  • Why it matters
  • What, exactly, is software quality?
  • What does good code look like?
• Exceptions
  • How exceptions got this way
  • Why exceptions turn a drama into a crisis
  • What exceptions should have been
  • The (only) valid use of an exception
  • Exception quarantine
• Classes and Objects
  • The myth of resuability
  • Getaway classes (better than flat-pack classes)
  • Better living through immutability
  • Algebraic groups
  • Nullary objects
• If considered harmful
  • The if anti-pattern, and why debugging makes bugs worse
  • Decision trees
  • Down-converting factories
• Closure
  • Exception quarantine redux
  • Closures beat dependency injection
• Isolation: intra-program firewalls
  • Fly-by-wire
  • Layering
  • Publish and be damned
• Concurrency
  • Down with multi-threading!
  • Immutability redux
• Testing
  • Why we test
  • Why testing doesn’t find bugs
  • How to do automated testing right
  • How to do manual testing right
• Working with legacy code
  • Debug the roots, not the leaves
  • String-typing is non-typing

Asynchronous programming is being pushed further into the mainstream with the introduction of the C# async and await keywords. It is therefore becoming more and more important that when we write libraries for our own application stack, we pay attention to which functionality should be async in nature.

During this intensive workshop we will do a deep dive into how these new features work, and into the mechanics of how best to deliver asynchronous functionality into your applications.

We’ll focus not only on asynchronous compute but also on asynchronous IO, and look at some of the newer features such as async streams and ValueTask.

The two presenters co-authored the Apress book Pro Asynchronous Programming with .NET.

The objective of this workshop is that by the end of the day, you will be comfortable with designing, deploying, managing, monitoring, and updating a coordinated set of applications running on Kubernetes.

Distributed application architectures are hard. Building containers and designing Microservices to work and coordinate together across a network is complex. Given limitations on resources, failing networks, defective software, and fluctuating traffic you need an orchestrator to handle these variants. Kubernetes is designed to handle these complexities, so you don’t have to. It’s essentially a distributed operating system across your data center. You give Kubernetes containers and it will ensure they remain available. Kubernetes continues to gain momentum and is quickly becoming the preferred way to deploy applications. In this workshop, we’ll grasp the essence of Kubernetes as an application container manager, learning the concepts of deploying, pods, services, ingression, volumes, secrets, and monitoring. We’ll look at how simple containers are quickly started using a declarative syntax. We’ll build on this with a coordinated cluster of containers to make an application. Next, we’ll learn how Helm is used for managing more complex collections of containers. You’ll see how your application containers can find and communicate directly, or use a message broker for exchanging data. We will play chaos monkey and mess with some vital services and observe how Kubernetes self-heals back to the expected state. Finally, we will observe performance metrics and see how nodes and containers are scaled. Come to this workshop and learn how to deploy and manage your containerised application. On the way, you will see how Kubernetes effectively schedules your application across its resources.

This workshop highlights the ideas from the book Building Evolutionary Architectures, showing how to build architectures that evolve gracefully over time. An evolutionary architecture supports incremental, guided change across multiple dimensions.

For many years, software architecture was described as “the parts that are hard to change later”. But then Microservices showed that if architects build evolvability into the architecture, change becomes easier. This workshop, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This hands-on workshop provides a high-level overview of a different way to think about software architecture.

The topics that we’ll cover include: architecture dimensions, engineering incremental change, architectural characteristics, identifying architectural patterns, identifying fitness functions, retrofitting existing architectures, building evolvable architectures.

Deep Learning is a subset of Machine Learning that relies on deep neural networks, and it is the root of modern AI. It is how computers identify objects in images, translate speech in real-time, generate artwork and music, and perform other tasks that would have been impossible just a few short years ago. In this hands-on workshop, learn what neural networks are, how they work, how to build them with popular Deep Learning libraries such as Keras and TensorFlow, and how to use transfer learning to repurpose sophisticated neural networks trained by tech giants such as Microsoft and Google to solve domain-specific problems. More importantly, learn how to bring the magic of neural networks to the next software project that you work on, and come away with numerous code samples to get those projects started.

• 09:30–11:00 Introduction to Deep Learning
• 11:30–13:00 Neural Networks
• 14:00–15:30 Convolutional Neural Networks
• 16:00–17:30 Object Detection and Facial Recognition

The software industry is in a deep crisis. Many projects suffer from low quality, schedule slips and cost over-run. Systems are unmaintainable, complex and cannot handle change. However it is possible to develop great software systems, and Juval has helped hundreds of companies around the world meet their commitments. The key is developing software systems along engineering principles. This workshop presents Juval’s approach for software design: designing the system and the project to build it. You will learn how to mechanise design, and how to do it quickly and effectively. With system design Juval will demonstrate how to decompose a system into smaller building blocks, or services. This is where the vast majority of architects fail – doing the exact opposite of the right thing. With project design Juval will show a continuous design effort flowing from the architecture – including calculating the planned duration, cost, and risk – and devising several good execution options. Both parts complement each other: you cannot design the project without the architecture, and it is pointless to design a system that you cannot build, or that your team will fail to execute on. This workshop is likely to change the rest of your career.

In October 2019, Google announced that it had achieved “Quantum Supremacy”. It had used its “Sycamore” processor to solve a problem in 200 seconds that would have taken a conventional computer over 10,000 years. This was the first time that a real, working quantum computer had solved a problem faster than a conventional computer could.

Almost immediately, the press was abuzz with apocalyptic headlines: this is the end of conventional computers; the end of encryption; the end of the internet.

So, what did they do? What is a quantum computer anyway, and why would we want one? What can we expect to happen in the future, and how is it going to affect our lives and our profession?

During this session, we’ll take a quick tour through the history of quantum computing. We’ll briefly explore a bit of the science and mathematics behind it: what makes a quantum computer special and what kinds of problems it can solve. We’ll see some quantum programs running on real quantum hardware. Finally, we’ll talk about what Google has achieved (and how they got there); what we can now do (and what we can’t); and what we can expect to see in the next year, or two, or ten.

This is what you need to know about the principles of quantum computing, but didn’t know how to ask.

Lambda expressions in C# can be confusing the first time you walk up to them. But once you get to know them, you’ll see that they are a great addition to your toolbox. Used properly, they can add elegance and simplicity to your code. And some .NET constructs (such as LINQ) lend themselves to lambda expressions. In addition, lambdas let us scope our variables more appropriately with captured variables. We’ll take a look at how lambda expressions work and see them in action. We’ll also see how LINQ can help us move from imperative programming to declarative programming (a gateway to functional-style programming).

Artificial Intelligence (AI) is a subset of Machine Learning, and it is changing the world as we know it. From self-driving cars that react to objects in front of them to facial-recognition systems to apps that translate speech in real time, AI allows computers to perform feats of magic that would have been impossible just a few short years ago. Learn what AI is, how it works, and what types of problems it can (and cannot) solve in this fast-moving session designed to make software developers and engineers conversant in AI.

One of the great things about being a programmer is that you never stop learning. Even after having programmed for almost 35 years, I still improve on the way I write code. Recently the way I write code changed once again when I started to apply monads and especially the Try class. During a recent project, my team created a small library that ports the behaviour of the Scala Try monad. Although at first this new monad didn’t appeal to me, I soon really started to appreciate this style of programming, where we concatenate series of Map() and FlatMap() methods, using lambdas, and avoiding abundant try-catch blocks, and many if statements and null checks. In the meantime, I have contaminated many programmers with this style. Developers make it a sport to always start every method with e return statement. During this talk I’ll demonstrate the power of this simple monad, using many code examples (in Java, C# and TypeScript). Don’t hesitate to join in.

In spite of the fact that React is significantly more popular than Angular, many business application developers have a purely theoretical understanding of React and related libraries. In this talk Oliver demonstrates patterns and practical use of React, hoping to impress you with its power and ease of use. You should walk away with a much better understanding of React and how it might fit into your next project.

Microservices (small, self-contained modules, often remote, to which an application delegates work) solve many common problems, from multi-threading to demand-based scaling. They also provide an almost ideal architecture not only for web-based applications, but also for all systems developed using Agile principles. Though a Microservice architecture is often associated with distributed applications, they’re equally suitable for use systems that will never see a network, and they are very robust in the face of change. However you don’t make Microservices by breaking up a monolith into little chunks and dubbing them “services”. You need to program them in completely different ways than you might be used to. Building a service is not a simple matter of putting an HTTP-based REST interface in front of a chunk of code. The service interface has to be carefully crafted, and the service itself must be lightweight, decentralised, secure, fault tolerant, transactional, and be vendor and language neutral. This session shows you how to build a service that does all that. We’ll cover what a Microservice is, how it has to be structured, and how it communicates with other services and the outside world. You’ll also learn about service architectures and how they do (and don’t) integrate with various technologies such as Docker.

Lambdas. All the cool kid languages have them. But does ‘lambda’ mean what C#, Java, Python, C++, etc. mean by ‘lambda’? Where did lambdas come from? What were they originally for? What is their relationship to data abstraction? In this session we will explore the history, the syntax and the uses of lambdas and the way in which lambda constructs in various languages do (or do not) match the original construct introduced in lambda calculus.

Understanding the topology, rationale, and trade-offs for common architecture styles is a critical foundational skill for architects. Additionally, architects need to know when to use synchronous or asynchronous communication patterns. This session takes modern engineering practices and perspectives and applies them to a survey of architecture patterns. For each pattern, we’ll discuss the history, philosophy, rationale, topology, optimum uses, and negative trade-offs. We’ll also discuss common communication patterns within particular styles, along with pros and cons for the architecture style.

It’s very likely that the majority of the software architecture diagrams you’ve seen are a confused mess of boxes and lines. Following the publication of the Manifesto for Agile Software Development in 2001, teams have abandoned UML, discarded the concept of modelling and instead place a heavy reliance on conversations centered around incoherent whiteboard diagrams or shallow “Marketecture” diagrams created with Visio. Moving fast and being Agile requires good communication, yet software development teams struggle with this fundamental skill. A good set of software architecture diagrams are priceless for aligning a team around a shared vision and for getting new-joiners productive fast. This session explores the visual communication of software architecture and is based upon a decade of Simon’s experiences working with software development teams large and small across the globe. He’ll look at what is commonplace today, the importance of creating a shared vocabulary, diagram notation, and the value of creating a lightweight model to describe your software system using the “C4 model”, which he created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.

Open your mind to the wonderful world of Object-Orientated Design Patterns. Every OO developer should carry this virtual toolbox around in their head. In this talk you will perhaps discover new patterns, or re-discover existing techniques and learn the pattern vocabulary associated with it so that you can effectively communicate with other developers. This will be a fast action talk, with a lot of code, and an immersive deep dive into the world of design patterns.

In the 1950s Fortran released a great innovation into the world of software development: procedures. Suddenly, we could write programs orders of magnitude larger and more accurately than before. Then in the 1980s, Smalltalk and C++ introduced us to objects, and development took another great leap forwards. Now, at the start of the 21st century, another great leap forward is taking shape, and almost every language is adopting closures. Closures really do introduce a whole new way of thinking about what programming is, and how to organise our code. In this talk, Jules will describe their beginning in Algol and functional languages, show how they work in modern languages, and demonstrate a few patterns and idioms that demonstrate their extraordinary power.

With Blazor WebAssembly, developers can write C# code for SPAs in the browser and share code with the server-side of their applications. Usually, you design and use JSON-based Web APIs to communicate between the client and the server logic. In this session, Christian Weyer demonstrates how to employ gRPC & gRPC-Web in a code-first manner to share .NET interface contracts in a strongly-typed way. With this approach, no code generation is needed, you get the same syntax and full intellisense on both sides. In fact, you gain the good parts we already had many years ago with WCF – now for the ubiquitous & open web. But: is really everything gold that glitters?

This talk covers the ins and outs of choreographed Microservice systems in depth, looking at everything from architecture and implementation details to design techniques. Choreographed Microservices talk to each other asynchronously, blindly broadcasting notifications into a service cloud. Those notifications are handled by whatever client services are interested. These systems eliminate many of the problems associated with orchestrated systems (which work more like synchronous function calls), and are typically much faster than orchestrated systems, but they have their own idiosyncrasies and implementation challenges. This practically-focused session explores the inherent problems in orchestrated systems, and then looks at how choreography can solve those problems. We’ll cover three approaches to choreography: http-based, pub/sub messaging based, and brokerless swarming systems. We’ll introduce appropriate messaging architectures and frameworks and look at several practical examples. Finally, we’ll look at Event Storming: one of the best approaches to designing choreographed systems. You’ll come away from this session understanding both why you should be using choreography for most high-level APIs, and how to design and build these systems.

So you have some code and it is in a bounded context with a REST API. You are on your way to Microservices. Next you wrap it in a container and now it is an image that others can run. Simple. Now what? No service is an island. Your service needs to log information, and needs to scale and load balance between its clones. Your service needs environment and metadata way outside of its context. What about where the service will run? Who starts it? What monitors its health? What about antifragility? Updates? Networking? Oh my. Services live in clusters and clusters live in data centres. Many concepts overlap with the features of cloud management. But don’t get too flustered since, fundamentally, services are managed by clusters. There are several approaches to cluster management such as Docker Swarm, Mesos with Marathon and Kubernetes. Minikube with Kubernetes is an approachable technique to set up a local cluster that is easy to understand and get started. Whether you have a simple service or a Web application with a set of services, you can develop much of it on Kubernetes with Minikube. We will run some practical examples. Once you understand the mechanics of the tools, we will explore how it works, sort through the terminology, and share some ideas about practical uses for this technology. By the end of the talk, you will understand how to run your personal cluster on your Linux, OS X or Windows machine running applications in a cluster.

Architects must translate domain requirements, external constraints, speculative popularity, and a host of other factors to determine the key characteristics of a software system: performance, scale, elasticity, and so on. Yet architects must also analyse the trade-offs each characteristics entails, arriving at a design that manages to maximise as many beneficial properties as possible. This session describes how architects can identify architectural characteristics from a variety of sources, how to distinguish architectural characteristics from domain requirements, and how to build protection mechanisms around key characteristics. This session also describe a variety of trade-off analysis techniques for architects, to try to best balance all the competing concerns on software projects.

You think you’re doing all the right things, but you’ve got problems that go beyond the bumps and variations of learning, adapting and dealing with the unknown. You’re tracking velocity, prioritising by business value, managing your technical debt… except, it turns out you’re probably not.

This talk goes beyond the obvious problems – such as “We don’t do unit testing” and “Our non-technical product owner doesn’t prioritise technical work” – and their obvious solutions – “Start doing some unit testing” and “If the product owner is non-technical, technical work is not the product owner’s to prioritise” – to examine a number of concepts and skewed practices that maybe make your approach more rigid and brittle than Agile. Are you really tracking velocity, or just how busy developers are? Is your work really prioritised by business value, or just by guesswork and individual preference? Are you really managing technical debt, or just tracking hours of extra work to refactor parts of your codebase?

Delegates are the gateway to functional programming. So let’s understand delegates and how we can change the way we program by using functions as parameters, variables, and properties. In addition, we’ll see how the built-in delegate types, Func and Action, are waiting to make our lives easier. We’ll see how delegates can add elegance, extensibility, and safety to our programming.

Support-Vector Machines (SVMs) represent the cutting edge of statistical Machine Learning, and are used in applications ranging from facial recognition to fraud detection. They work by employing mathematical tricks to add dimensions to data to expose linear boundaries of separation that don’t exist in lower-dimensional space. Tuned properly, they often outperform gradient-boosting machines and other types of Machine Learning models. Learn what SVMs are, how they work, how to train them and prepare data for training, how to optimize them (a process known as hyperparameter tuning), and how to put them to work solving real-world problems.

Coding katas are a way that programmers can kick the tyres of their programming languages, paradigms and practices. Conventionally anchored in a TDD cycle, katas are typically simple problems that give programmers the opportunity to exercise deliberate practice and explore different approaches, whether programming style, pair programming or test-first programming. But the simplicity can be deceptive, with many programmers tiring of these katas too easily, missing out on some of the more mind-bending and paradigm-expanding opportunities on offer. This session will pick on a handful of katas and dig deeper into TDD, software craft, maths, lambdas, language(s), (dys)functional programming and Alcubierre drive.

Agile gave us small. Continuous Delivery gave us fast. Now it’s time to add safe to the equation. With Agile and Continuous Delivery, the focus shifted to speed… and nothing else. The immature tools that emerged from these methodologies expose us to new threats. The fast pace of change means we are more frequently introducing new vulnerabilities. And technology developments such as Cloud, IoT, AI and Machine Learning confront us with new attacks. DevSecOps focuses on integrating security in the heart of our processes and teams. Automate security first and fail fast will help build security in and supports the growth of awareness in the teams. Kim will show the lessons learned from her journeys to continuous security. Get an overview of the current continuous security landscape and the practical insights and pitfalls. And learn how security can be fun!

Don’t fear entropy, embrace it.

When you move toward distributed computing the likelihood of failure proportionally increases. It’s not your fault, it’s simply physics. Once you start spreading your data and applications across more devices, then access to resources such as CPU, memory, and I/O have a higher rate of failure.

Embrace entropy with chaos experiments and increase your cloud native capability model. We’ll investigate some of the leading chaos frameworks for Kubernetes and dive into hands-on experiments targeted within blast radiuses.

The Actor Model is the latest idea to storm the software industry. But is there any substance behind it and why should you care? What are the drivers of the Actor Model and why have the large cloud vendors started offering Actor-based solutions? Juval Lowy puts it all together first by outlining the long-term trend in software methodologies that brought this 50-years old computational model to the fore, and how the demise of Moore’s Law coupled with the rise of the IoT will force us to abandon sequential programming. Juval will examine the origin of the Actor Model; demonstrate Actors using conceptual examples, outline emerging design patterns, point out common misconceptions and conclude with his views on the future of the Actor Model.

For the past decade and a half, Domain-Driven Design has been giving teams the tools to successfully tackle the complexity at the heart of software. But lots of people fail when they try to put its techniques and patterns into practice, especially at scale. Why? It can’t just be because the Blue book is so thick? We’re going to argue that the “near enemies” of DDD are to blame. Things which look like DDD, but which are in fact counterfeits that push us further away from our goal. Our talk tells the story of a large-scale DDD implementation that got complicated. We’ll talk about how we took stock of the situation as we found it, how we identified where the root problems lay, how we set everyone off on a course of success, and the mistakes that we made along the way. Regardless of whether you’re working with serverless, Microservices or a more monolithic architecture (nothing wrong there!) – this fun session is for those who want to learn the lessons of implementing DDD at scale, with a healthy dose of pitfalls and hazards to watch out for too.

C# 5 built on the Task API, introducing the async and await keywords. These bring asynchronous execution as a first-class concept in the C# language. The new keywords create a very elegant model for all sorts of async work. C# 8 introduces async foreach, allowing for the creation of asynchronous iterators, an essential new addition to complete the async story. This talk will cover the simple use cases, the most common gotchas, and then provide a deep dive into how these keywords work under the covers.

Are you a C# developer looking to leverage Machine Learning but not wanting to learn Python? Good news: .NET developers now have a world-class Machine Learning library at their disposal. It’s free, it’s cross-platform, it’s open-source, and it’s called ML.NET. Learn how to use ML.NET to build sophisticated Machine Learning models in C#, and how to use it to solve tough image-classification problems by leveraging pretrained TensorFlow models.

Developers are bad at naming, especially C++ developers like me. Naming well is a learned skill: you can learn it, and start to name better right away. In this talk, I’ll tell you why names matter, what benefits a good name can bring, and how to be better at naming. I’ll discuss some categories of names and some common decisions within those categories. I’m not going to give you a set of rules to follow: this is about thinking and considering the meaning of the things you are naming. I will give you some questions to ask yourself and some structure that I use to help me to help those who read what I write. I’ll also address renaming things in existing (legacy) code, why and when to do it, and why getting it right the first time may not even be a realistic goal. You should be a lot more confident naming things after we spend this time together.

Modern web browsers support a myriad of HTTP headers and other features that provide additional security safeguards for common attacks. These mechanisms can effectively prevent Cross-site Scripting, Clickjacking, Cross-Site Request Forgery and many other attacks. This session will detail many of those headers, including browser support, and recent developments such as headers that await deprecation.

More and more, event storming has become a critically important tool in the architect’s palate. It is a way to simultaneously collaborate with business people to understand the problems that the business has to solve, and to develop an architecture for the solution. Along the way, you’ll discover the entities, bounded contexts, and events that are essential for an effective choreographed Microservices (or reactive) architecture. This session is an in-depth look at event storming and the underlying concepts (from Domain-Driven Design). It includes an extensive hands-on demo of the process. You’ll come away from this talk with a solid understanding of how event storming works and how to apply it.

The first law of software architecture (coined from my book Fundamentals of Software Architecture with Neal Ford) states that “everything in software architecture is a trade-off”. One of the key skills of an architect is to analyze trade-offs. Most people know this from the famous (and annoying) response “it depends”, from so many software architects around the world when asked any architecture-related question. However, how do you identify and analyze trade-offs? In this session you will learn tips and techniques for how to do trade-off analysis and make better decisions using real-world trade-off examples such as service granularity, shared functionality, communication protocols, distributed transactions, and many other hard decisions architects face every day.

Have you ever wondered how to get out of a bad merge? Have you ever got stuck trying to push your changes? Git is a wonderful and empowering tool, but it’s not your father’s version control system. Bring your Git questions for this no-slides demo of Git command line and GUI tools. We’ll harvest your curiosities, add in some common concerns, and run through these scenarios together. Do you have an open-source project you’re stuck on? Bring the GitHub URL, and not only will we discuss it, I’ll submit a pull request with the changes we build.

DevOps, self-organisation and autonomy. Hierarchy is being traded for the autonomy to do what is necessary to deliver. And control is being traded for responsibility for outcomes. So now the team and all its members are responsible for delivering value, and for uncovering better ways to do that. Also known as learning. Time to learn something about learning and how to deal with the stress, grief and frustration that it causes. Kim will show you the change cycle people experience. How to coach them in each stage? What strategies for coping and thriving are there? What can you do when somebody has a victimising mindset? Giving effective feedback, and what to do when someone is blind for some of their flaws. Take a step to learn learning and help your team deal with change.

Learning other programming languages enhances our work in our primary language. From the perspective of a C# developer, the Go language (golang) has many interesting ideas. Go is opinionated on some things (such as where curly braces go and what items are capitalized). Declaring an unused variable causes a compile failure; the use of “blank identifiers” (or “discards” in C#) are common. Concurrency is baked right in to the language through goroutines and channels. Programming by exception is discouraged; it’s actually called a “panic” in Go. Instead, errors are treated as states to be handled like any other data state. We’ll explore these features (and others) by building an application that uses concurrent operations to get data from a service. These ideas make us think about the way we program and how we can improve our day-to-day work (in C# or elsewhere).

With infrastructure as code (IaC) you get full control of your Cloud environment. Every change can be traced, previewed and approved with the same tools that you already use for your application code. It’s easy to set up the resources to be consistent and repeatable in different environments, and a breeze to remove it when you wish.

Terraform offers thousands of providers and a simple declarative syntax. The providers span from Cloud services like Azure to other services that you may also wish to manage by code. This session will focus mainly on provisioning resources in Azure, but the methods are the same to all providers.

We’ll start by showing how easily you can start to experiment and learn to write Terraform using HCL HashiCorp Configuration Language, and end up putting it into the release pipeline of your application. You will learn some best practices for Terraform and be equipped with some tips and tricks that will help out if you get stuck.

Part of a software developer’s job is to find new and better ways to solve problems. Writing code using his/her wits, intelligence and creativity. However, sometimes being too clever can lead to hard to track bugs, maintainability issues, and impossible to understand code. Is all cleverly written code good code, or is it a problem just waiting to happen? In this session, I will show you real-world examples of cleverly written code. And show you how we can use clean code principles, refactoring and design patterns, to transform that code from clever code to good code – code one that your peers (and future self) would thank you for writing.

In this session I show you how ASP.NET Core implements the Model View Controller pattern for Web Applications and the Model Controller pattern for Restful services. I cover convention over configuration, implementing Controllers and Action methods, Views (including partial views and layouts), Routing, and much more. This session is designed for developers new to the ASP.NET MVC and WebAPI frameworks.

To further improve time-to-market and adaptability in delivering their services, IoT company Quby (well-known for the Toon smart thermostat) are reshaping their software landscape, which largely consists of a number of mobile applications (built in Javascript and React), web applications and back-end services (Java and Spring Boot) and embedded software (written in C, C++ and Qt). While the landscape must continue to run and evolve, we started working on a new Microservices platform called Fiona, which leverages state-of-the-art technology, such as Typescript, Node.js and additional frameworks, Continuous Delivery, fully automated pipelines and running on the Amazon AWS Cloud. Unfortunately, with Microservices, there is no well-described recipe that will take you directly to your desired end state. So, with a small team Sander, chief architect at Quby, is trying to navigate through the many big and small decisions you need to make when moving towards a Microservices technology on a daily basis. During this interactive talk, he’ll take you through the small steps Quby has made, illustrating many of these architectural, design and frameworks decisions made, along the way, with real code examples in Typescript, slowly arriving at a happy state and a set of patterns and coding techniques that evolved along the way. Sander not only talks the talk but walks the walk as well. If your company or organisation is also underway towards a Microservices architecture, and Continuous Delivery, be sure to attend this talk, as you too will have to answer many of the questions Sander and his team are facing, and have faced in earlier successful implementations.

A nagging problem for architects is the ability to enforce the governance policies that they create. Yet, outside of architecture review boards or code reviews, how can architects be sure that developers utilise their rules? This session describes mechanisms to automate architectural governance at application, integration, and enterprise levels. By focusing on fitness functions, architects define objective tests, metrics, and other criteria to ensure that governance polices stick.

Diagrams as code is becoming a popular way to diagram software architecture, particularly for long-lived high-level documentation. You write the diagram source in a text-based domain specific language (e.g. PlantUML or Mermaid) or a programming language, and render diagrams using web-based or command line tooling. The benefits are well understood – writing the diagram source as text allows for easy integration into software development practices and toolchains, plus the automatic layout facilities allow authors to focus on content. The problem with this approach is that it’s easy for diagrams to get out of sync. Enter “diagrams as code 2.0” – a way to define a model of our software architecture and the views that we’d like to see, ultimately resulting in a consistent set of diagrams that are generated for us.

Over the past decades, the software development industry has carved out a massive core body of knowledge of software architecture and design patterns. And yet, fundamentally, our industry is not better off because of it, as it falls behind trying to cope quickly with ever changing requirements and increased complexity, coupled with dwindling budgets and past mistakes. In this visionary session Juval Lowy will articulate the root causes of the problem, propose a contemporary solution, and predict the impact and infliction adopting his approach will have on the livelihood and prosperity of every software professional and software business.

All ‘real’ functional languages support Pattern Matching – that’s not really true, but it is correct that aspects of a functional programming style benefit from elegant and syntactically compact case distinction. Microsoft worked on Pattern Matching as a C# feature in at least three major language versions! In this talk, Oliver demonstrates how C# Pattern Matching works, why this evolution of the old imperative “switch” is so important, and how the structure of C# Code can be generally different from the past on the basis of this feature.

It’s 17:00 on Friday, and by Monday, your boss wants a smart recommendation system that uses the reams of purchasing data your company has collected to entice customers with more products they are likely to buy. Your biggest competitor did the same and increased sales by 30%. Do you work a 40-hour weekend, or do you polish it off in time to hit the pub on Friday night? Learn how to build recommendation models, use Principal Component Analysis (PCA) to work feats of magic, use anomaly detection to predict failures before they occur, and more in this fast-moving session replete with code samples. Moreover, be the life of the party the next time the topic of conversation at the pub turns to Machine Learning.

As developers, we all know how damaging technical debt can be: it decreases velocity, reliability, and daily joy. We know that true agile working requires constant refactoring to bring technical debt down. And yet, in the constant drive to develop new features and (if we’re lucky) fix old bugs, our lords and masters urge us ever onwards, faster and faster, feature after feature, until the codebase collapses into a sticky mess.

Technical debt is not merely a matter of programmer-aesthetics, it genuinely goes the heart of what quality development is all about. But non-technical managers don’t get that. To them, code is just code: if it works: it works, and if it doesn’t: there are plenty of hackers looking for work who are more competent than you. In order to align our bosses’ needs with ours, we need to be able to express what technical debt is in language which is familiar to them. That is the language of finance. In this talk, we will explore how to quantify the cash value of code, how to measure technical debt, and how to find the actual interest rate the business is paying for it. This is how you can beat the bean-counters at their own game, and put the joy back into your code.

Long gone are the days when JavaScript was just good for opening pop-up windows and validating forms. Modern browsers support countless APIs, providing access to client hardware, implementing security protocols, push notifications, and much more. Join this code-heavy whirlwind tour of APIs you didn’t know existed, but that you’ll want to try out right after the session.

Serverless is the promise of short bursts of functions all provided by some magical cloud platform. As a developer, you write the function and automagically something else ensures your code is served and evented. It’s sorcery based on your sourcery. But how can this work on Kubernetes? Serverless is ideal for Kubernetes!

We’ll pick apart a few Kubernetes-based serverless frameworks and dive into Knative which promises a standard framework for your potions.

Rich Hickey once said programmers know the benefits of everything and the trade offs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade offs of every new library, language, pattern or approach and quickly make decisions often with incomplete information. How should we think about the inevitable technology choices we have to make on a project? How do we balance competing agendas? How do we keep our team happy and excited without chasing every new thing that someone finds on the inner webs?

As architects it is our responsibility to effectively guide our teams on the technology journey. In this talk I will outline the importance of trade offs, how we can analyze new technologies and how we can effectively capture the inevitable architectural decisions we will make. I will also explore the value of fitness functions as a way of ensuring the decisions we make are actually reflected in the code base.

Leaders aren’t born, they aren’t hatched, and they don’t apparate. Leadership is a journey, one that involves hard work, practice, and a deep understanding of not only your team members but also yourself. I’ve led teams large and small throughout my 30 year career, and certainly made plenty of mistakes on the way. But I’ve learned to fail fast, iterate, and continuously improve to create high performing teams across multiple verticals. In this session I share what I have learned over the years being a leader and being led.

Much as the need to design the system, you must also design the project to build it.

This requires understanding the inner dependencies between services and activities, the critical path of integration, the available floats, and the risks involved. All of these challenges stem from your system design and addressing them properly is a hard-core engineering task – designing the project. In this intense session Juval Lowy shares his approach for software project design, along with his unique insight for delivering software on schedule and budget, that have helped hundreds of companies deliver on their commitments. You will also see to deal with common misconceptions and typical roles and responsibilities in the team.

You know the basics of dependency injection (DI). Now it’s time to take a closer look at how DI patterns and other design patterns can help us use DI effectively. We’ll look at implementations and uses for DI patterns including constructor injection, method injection, and property injection. In addition, we’ll use other design patterns to add functionality to existing objects and to manage disposable dependencies. We’ll leave with several practical ways to improve the functionality and testing of our code.

By now your organisation has planted a flag in “the Cloud”, and it’s up to you to figure out just what that means to your application portfolio. Should everything be a Microservice? Wait, what is a Microservices anyway? How do you deal with massively distributed applications? What do you do with your legacy portfolio? In this presentation, we will walk through how the cloud impacts our applications, and what we can do to successfully move our organisations forward.

Users cannot secure your web applications through password choice alone. We cannot blame them for this; it is not their problem to solve. It is ours, as security/identity professionals and software developers. FIDO2 offers a realistic solution in the form of frictionless, possession-based authentication, and you will often see it touted as the next big thing, but can we look past the clickbait and sensationalism that surrounds security reporting and figure out a pragmatic choice for protecting our users? In this talk we’ll look at:

• Why passwords are so pervasive
• If SMS OTP really is all that bad
• How phishing attacks are now one of the biggest threats to your applications
• How you can make phishing trivial using evilginx, even defeating 2FA methods such as TOTP and push notifications
• Spooky biometrics
• How you can use WebAuthn and FIDO2 authenticators to negate phishing

ASP.NET Core has changed development of web applications and Restful services in revolutionary ways. In this session I show you what you need to know to move to ASP.NET Core.

Securing a container is like securing a virtual or physical machine. You need to understand what’s installed, ensure that it’s patched, and reduce the attack surface. But unlike traditional servers, this is done at build time for containers. Journey with us as we build a comprehensive strategy for securing your digital assets that run in Docker, and leave with concrete steps you can apply to your DevOps pipeline today.

We’re agile, we’re doing DevOps, we work in cross-functional teams, and we use the latest developer pipeline tooling. With all those methodologies and technologies we should be highly effective, right? Probably not. Most of us still struggle with balancing coding speed and quality, working on the stuff that really makes a difference, and feeling constantly stressed by all the things we should learn.

Effective developers don’t just write clean, simple, and robust code. They also have a strong understanding of the entire development process and the problem that needs to be solved. They take time to learn, practice, and play. Learn how those developers build effective coding habits, use automations whenever needed, reserve time for deep work, and much more. You’ll walk away from this talk with lots of ideas on how to work smarter, not harder.

I stopped testing for bad reasons, but started again for good ones. The experience has allowed me to demonstrate in practice the impact it can have on your code base when you don’t test, and also when you do. This talk, based on simple practical examples, explains exactly why unit tests, a TDD approach and pairing can make all the difference to your code.

Cloud Native applications are distributed to reap the benefits of resource scaling. Distributed computing is powerful, but it also makes you think differently in designing applications. Atomic, modular, highly cohesive, and low-coupled applications play nicely on these distributed systems. But it comes with costs.

We’ll look at architecture styles that adapt well to running in containers and on Kubernetes. Along the way, we’ll note the extra things your application should do to play nicely with distributed Cloud Native targets.

Just like the famous Gang of Four patterns for object-oriented programming, there are common solutions for parallelising various algorithms. In this talk, you will learn about a variety of parallel patterns, the difference between task and data-based parallelism, and when and how best to use them in a .NET environment. We will focus on the following parallel patterns: Pipe Line, Geometric Decomposition, Divide & Conquer, Parallel Loops, and Monte Carlo.

Getting started with unit testing is not hard, the only problem is that most programs are more than a simple calculator with two parameters and a returns value that is easy to verify. Writing unit tests for multi-threaded code is harder still. Over the years I’ve discovered useful patterns which have helped me to test multi-threaded and asynchronous code, and enabled the creation of deterministic, simple and robust unit tests. Come and learn how to test code that uses concurrency and parallelism – and the excuses for not writing unit tests for such code will become as obsolete as single-core processors.

Computer vision has evolved rapidly in recent years to the point that computers can often outperform humans when it comes to classifying images, identifying objects in images, detecting and recognizing faces, and performing other vision-related tasks. Learn how computer-vision systems are built with deep neural networks, how to train models of your own to solve domain-specific problems, and how to use a technique called transfer learning to process image data like the pros.

Building an API with ASP.NET MVC in .NET Core is only half the job. If you’re API is going to live more than one release cycle, you’re going to need to version it. During this session, you’ll see how easy it is now to version APIs using functionality built into ASP.NET Core.

This talk is about the advanced data access and persistence patterns CQRS and Event Sourcing. CQRS is based on really simple ideas about splitting responsibilities when handling data, but extremely complicated papers have been written about it! Event Sourcing is often viewed as a natural CQRS companion, although it’s quite separate and a decision to use it comes with its own consequences. This talk includes practical examples of implementation and application of both patterns.

Security is often treated in the way that most of us don’t like to do software development – as waterfall, i.e. at the beginning or just at the end as a last gateway/check. But unsurprisingly, that isn’t the best way to do it! So how can we incorporate security thinking into our daily work, together with our customers? What tools can we use to make it easier? Let’s find a way to add a security mindset into the whole development lifecycle!

Producer/consumer problems show up in a lot of programming scenarios, including data processing and machine learning. Channels give us a thread-safe way to communicate between asynchronous methods, and we can run them all concurrently. In this presentation, we will explore channels by comparing parallel tasks with continuations to using a producer/consumer model. In the end, we’ll have another tool in our toolbox that we can use for concurrent programming.

Entity Framework Core is the rewrite of Entity Framework, and is both evolutionary and revolutionary. In this session, I show you the features of EF Core, how (and when) to leverage the new features, and to how move to the improved features from Entity Framework 6. This session is designed for developers familiar with Entity Framework or ORMs in general.

Software development has changed dramatically in recent years; no longer can you afford to say, “That’s how we’ve always done it.” Applications are evolving rapidly, which requires you to move fast and fix things. And don’t neglect the cultural shift inherent in any technical change. (Some developers, for instance, reject build-break notifications, going so far as removing themselves from the email list.) If you’re just starting your CI/CD journey, you must ensure everyone understands the benefits, including increased speed-to-market, stable builds, and reduced drama around releases. That way, CI/CD won’t just help you deliver for your customers – it will help you sleep better at night.

Since 2003, the Open Web Application Security Project has curated an annual list of the top ten security risks for web applications. After several delays, the 2021 list was finally released in late September of that year. Time to have a look at what’s new, what has changed, and to get an up-to-date refresh on how to create secure web applications and prevent the top ten issues from happening. We will also discuss whether the list is still relevant, and what is missing.

You’re ready to go cloud native with containers. But where do you begin on Azure? There’s a dizzying range of container options available in Azure. How do they compare? Which is the best choice for your organisation? Come with us through a tour of each Azure Container hosting technology, the pros and cons of each, and decide for yourself how best to host your containers on Azure.

Programmers often believe that code does not have emotions, but it does! I will show you how the way developer feels while they work affects the code they write. I’ll also talk about why negative emotions such as fear lead to bad code, and what to do about it. And yes, it’s possible to write code that shows positive emotions, and that’s something I’d like you to try doing. Despite being about code, this talk doesn’t have a lot of code in it. Most of it is in C++, but a knowledge of C++ syntax and libraries isn’t necessary to benefit from the session.

Large systems tend to leverage one of about a dozen common architectural patterns – i.e. ways that architectural components are organised and interact. These patterns run from traditional structured monoliths to modern Microservice-based systems. In this session we’ll go through a catalogue of common patterns, explaining how they work, their benefits and their problems. The patterns approach is particularly useful when you’re starting a new system for Agile development, because it quickly lets you choose a basic structure and actually get to work.

A common challenge facing many software architects today involves restructuring their current architecture, or migrating from one architectural style to another. For example, many companies start with monolithic applications for simplicity, but find that they need to migrate to another architecture in order to achieve different architectural characteristics. This session examines patterns/antipatterns, techniques, engineering practices, and other details showing how to make major changes to architectures. We’ll introduce a new measure – the architectural quantum – as a way of measuring and analysing coupling and portability within architectures.

When developing multi-threaded applications, we need to consider thread safety when sharing state across multiple threads. These techniques require the developer to understand possible race conditions and select the cheapest synchronisation technique to satisfy thread safety. However, while this process is essential, it can often become tedious and can make even simple algorithms seem overly complex and hard to maintain. In this module, we will explore the use of framework-provided concurrent data structures shipped with the TaskParallel Library, which will simplify multi-threaded code while maximising concurrency and efficiency.

Most developers learn to code by, well, writing programs and while that’s an important piece of the puzzle, it isn’t the only skill required to be a successful software engineer. New developers quickly discover there is a multitude of topics that are vital to your success from testing to design patterns to architecture. This session will focus on the often neglected practice of reading code providing techniques to use when faced with a new code base. We’ll also discuss what constitutes good code and how to work with heritage code without tearing out our hair.

Deep neural networks have grown in sophistication to the point that they can process text and speech – sometimes more accurately than humans. Learn how to use Keras and TensorFlow to build and train neural networks that classify text, translate text, and perform other NLP tasks that would have been impossible just a few short years ago.

With ASP.NET 6.0, there’s a fourth coding paradigm joining MVC, WebAPI, and Razor Pages: Minimal APIs. It’s a great way to create the lightest weight Microservice. But are you trading everything for the small surface? We’ll start with a .NET 5 project and build up to a Minimal API looking at a bunch of brand new C# 10 features along the way. Like the other three, this is not an either/or choice, and when it makes sense, you can be really productive here too.

This presentation is a no-slides talk – it’ll be live coding from the start. Attendees will leave with a GitHub repo that includes each step along the way, so that you can reproduce what’s covered in the session, or fork and use it in your own work.

GraphQL is a flexible query language that easily adapts to your requirements. From an architectural point of view, the biggest question is where GraphQL fits into your system – especially in Microservice environments where you may have Event Sourcing read models and similar components. In this talk, Oliver demonstrates several approaches for GraphQL integration.

The economic shock of 2020 will have profound implications for years to come. Many businesses did not survive, and even those businesses that do survive will face intense demands to restructure their systems and organization. However, merely reducing staff will not do. The design of most software systems is so complex they require large teams to try to maintain. The key is to restructure the system architecture and adopt rigorous project design to ensure the optimal use of time and diminished resources. In this eye-opening session Juval provides an overview of the current state of both the world economy and the software industry. Juval then proceeds to articulate the root causes of the industry’s problems, and proposes solutions based on correct design of systems and projects, all aims at reducing cost, future proofing projects and careers.

Design by Coding (DbC) is a way to develop an architecture incrementally as you code. It builds on Test- and Behaviour-Driven-Development techniques, but adds a focus on the ‘story’ that’s central to all agile processes. The process answers the question of how you can build a coherent Agile system incrementally, without a formal up-front design process, and addresses a common failing of standard TDD: losing track of the big picture when you focus on incremental improvements. DbC provides a way to both design and develop systems that model the story very closely, resulting in a system that can handle volatility with ease. The technique is also perfectly suited for building effective and minimal Microservice APIs. Since your code is effectively your design artifact, DbC also eliminates the need for a separate design phase in the development process. We’ll do a live demo of the process during the session.

Isomorphism is a mathematical term that determines if two structures are equal in shape. It is derived from the Greek terms Isos (meaning “equal”) and morphe (meaning “form”, or “shape”). Domain to Architecture Isomorphism determines to how close the problem you are trying to solve (the domain, or application) matches the architecture style you are using (such as Microservices, Event-driven architecture, Space-based architecture, and so on). In this session we explore this concept to help determine whether you are using the right architecture style for your problem. I start this session with describing the “shape” of various architecture styles, and then use real-world examples to demonstrate how to match the “shape” of a problem with the “shape” of an architecture.

C# 8 brought new features to interfaces, including default implementation, access modifiers, and static members. We’ll look at these new features, and see where they are useful and where they should be avoided. The world of interfaces has changed; the line between interfaces and abstract classes has blurred; and C# now has multiple inheritance (sort of). With some practical tips, “gotchas”, and plenty of examples, we’ll see how to use these features effectively (and safely) in our code.

Few of us today would consider developing code without the support of a version-control system. And yet our data – which is the lifeblood of our business – tends to exist only in a “present tense”, with no versioning at all. So what would it mean to version data? What would versioned data look like, and how would it differ from versioned code? Most importantly: what would be the business benefits of routinely version-controlled data? In this talk, Jules presents some of the key learnings from a recent project he led which was set up to answer these questions.

I used to think that AWS and C# belonged to two different ecosystems. Either I use my favourite programming language and its ecosystem, or choose another programming language so I can run my code on the AWS Cloud. This could not be further from the truth: with .NET Core, Docker, and AWS tools you can write .NET applications that run on AWS from the comfort of your Visual Studio (or VS Code) and use highly scalable AWS services with a few lines of C# code.

In this talk I will show you how to create cloud native Microservices and serverless applications using .NET, how to call AWS services from your C# code, and how to modernise your existing ASP.NET applications – in the cloud. Attendees should be fluent in C# and ideally have at least some knowledge/experience of developing cloud-based applications.

Microsoft’s advice for building your own authentication system is “Don’t. Use a cloud service”. This can be good advice for some projects; however, more and more companies are finding that the pricing, feature set, and vendor lock-in just doesn’t work for them.

Doing authentication and SSO yourself can be a daunting task, but using the building blocks in ASP.NET Core and popular OSS projects, a small development team can build a secure in-house SSO solution.

In this talk, I’m going to show you the building blocks and patterns necessary for building your own SSO solution using:

• User storage with ASP.NET Identity
• Modern password hashing
• Better MFA with FIDO2
• Secure SSO with OpenID Connect best practices & IdentityServer

The OWASP (Open Web Application Security Project) Foundation are dedicated to improving web application security, and provide a set of standards and tools to help achieve this. OWASP ZAP is the world’s most popular open-source web security tool, and is used by software companies and penetration testers to help spot vulnerabilities in web-based software. We’ll demonstrate the use of YAML pipelines within Azure DevOps, Docker and the OWASP zap2docker image to build repeatable automated pipelines for running OWASP ZAP scans against web applications. In addition, we’ll delve into the different types of scans that can be run both against user interfaces and APIs; explore various different application authentication options; and demonstrate how to publish scan results as Azure DevOps test results.

A basic knowledge of the use of YAML in build/release pipelines will be helpful. Whilst the workshop will use YAML within Azure DevOps in the practical examples, any CI/CD tool that supports YAML and docker containers could be used to achieve the same results.

We love JavaScript, but we must admit: it’s weird. Why does ’this’ behave as it does? How does variable scope work? Why do we have such comical behaviour when comparing mixed types? Let’s pull back the covers of these scenarios, and learn how it truly works. Hopefully you might find a new reason to fall in love with JavaScript.

Based on my experience of running a 12-week academy programme for Made Tech, this is a talk about the principles and techniques we used to build a highly successful and effective training programme for junior engineers.

“Big design up front is dumb. Doing no design up front is even dumber.” This quote epitomises what I’ve seen during our journey from “big design up front” in the 20th century, to “emergent design” and “evolutionary architecture” in the 21st. In their desire to become “agile”, many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it’s a misinterpretation and misapplication of the agile manifesto. As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can’t be assessed or reviewed. If you’re willing to consider that up front design is about creating a sufficient starting point, rather than creating a perfect end-state, you soon realise that a large amount of the costly rework and “refactoring” seen on many software development teams can be avoided. Join me for a discussion of the lost art of software design, and how we can reintroduce it.

Traditional approaches to software architecture usually trigger thoughts of ivory tower dictators who are a long way removed from the process of building software, probably because they no longer write code. This unfortunate stereotype of “architecture astronauts” delivering large design documents to the development team before running away to cause havoc elsewhere has unfortunately resulted in a backlash against having a dedicated architect on a software development team, particularly in environments where teams are striving to be autonomous and self-organising. But, in 2022, is having a dedicated software architect still useful, or are there better ways to fulfil this role? The answer, as usual, is “it depends”.

Architects often look harried and worried because they have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which we’ll highlight by investigating what makes architecture so hard. In this hands-on, platform-agnostic workshop we’ll go beyond the fundamentals of software architecture, and concentrate on the really hard problems. We’ll focus on areas surrounding modularity vs granularity, the challenges of event-driven architectures (including difficult error-handling issues), why reuse doesn’t work anymore, how to do trade-off analysis, and how to decouple services to achieve proper granularity. Architecture is full of hard parts; by tracing the common reasons and applying lessons more universally, we can hopefully make it a little bit easier.

This full-day workshop covers everything you need to start creating your own React-based applications. We’ll begin with simple and complex components, and class-based and functional implementations. We’ll then move on to advanced topics: presentation and container components, complex lifecycles and other structural aspects, Higher-Order Components and React Hooks. We’ll check out some common integrations with additional libraries, including UI component sets, Redux and routing options. To complete the picture, tooling is demonstrated throughout the day, with Visual Studio Code, Jest, Storybook, React and Redux debuggers.

In this intensive all-day class, you’ll learn everything you need to build Microservices for the real world. You’ll learn both the nuts-and-bolts implementation details, and also the Agile architecture techniques you’ll need to develop effective service APIs and good structure. Server-side monoliths (single programs that provide all back-end services) just don’t work. They are hard to build, impossible to maintain, difficult to test and deploy, and gradually accrete so much baggage that forward development slows to a crawl. Agile development is impossible over this sort of system. Microservices – systems of small, cooperating server-side agents – solve these problems, but building a Microservice system is not as easy as you might think. They’re nothing like typical web (SOA) services, and getting it wrong is both disastrous and expensive. Many things you think you know about server-side programming are just inappropriate in this context. This workshop is a deep dive into practical Microservice architecture and implementation. You’ll learn lots of practical details and common pitfalls that can cause you months of delay, or even outright failure. You’ll learn everything you need to be successful building platform-independent, vendor and language neutral Microservice systems. You’ll learn about optimal Microservice architecture and principles, appropriate service-API and UI design, effective interservice communication, and robust failure-handling techniques. Leverage this knowledge to build robust and resilient, secure, platform-independent services with no false starts and rework.

Do you have code you want to refactor, but you don’t believe you have time?

Refactoring is something we all do when writing code, whether consciously or not. But often it’s something we guiltily avoid, or feel we don’t have time for. Sometimes our teams have areas of code that need so much refactoring we set it aside as a separate task. But the longer we leave it the harder it gets, the longer we know it will take and the more likely it never gets done.

This workshop will go through a worked example in detail, teaching you how to refactor in tiny chunks and with good test coverage. You’ll learn ways of seeing refactoring as a daily achievable task instead of an insurmountable mountain, and hear lots of good arguments for why refactoring is not only worthwhile but essential for robust maintainable code.

You will be strongly encouraged to work in pairs for this workshop – a side benefit is that you will learn how pairing can also be used as a useful tool when refactoring, as well as learning some TDD techniques.

The reason for the word “compassionate” in the title is that in software we often beat ourselves up or point the finger of blame when we believe code has not been maintained effectively. One of the emphases in this workshop will be on using forgiveness as a technique to move forward and improve the future without bemoaning the past. No code base is ever perfect.

Demonstrations will all be in C# using .Net Core, which means they will work in Linux, on a Mac or on a Windows operating system. You can do worked examples in a language of your choice. You will need coding experience. A Test-Driven approach will be used (although people are often surprised at how few new tests you need to write when refactoring).

If possible you should bring a laptop with a development environment capable of building and running code in the language of your choice. If using C#, aim to have .NET Core installed plus a text editor. You’ll also benefit from having some form of IDE installed – e.g. Visual Studio Code, Rider, or Visual Studio.

Creating multiple models for the same problem is one of the more important lessons that Domain-Driven Design teaches us. It’s a lot cheaper to quickly iterate over them and throw away less useful prototypes before we even start coding. However the way Agile software teams gain knowledge about what to build is either by the product owner or business analyst serving as a proxy to domain knowledge. Domain knowledge usually ends up as second-hand news in either functional design documents or as user stories in a Scrum tools such as Jira. Second-hand knowledge is a significant risk when building software. Each time information is transferred, the story is changed, and people make assumptions. Because as Alberto Brandolini said: “It is not the domain exper’s knowledge that goes into production; it is the developer’s assumption of that knowledge that goes into production”. Sharing knowledge is way more effective if we actively collaborate to gain new insights about the problem at hand. There are a lot of tools available to achieve it, but they have a steep learning curve, resulting in most disciplines having their own tool to model in. To solve it, we need visual collaborative modelling to learn between multiple disciplines. EventStorming is a technique that can facilitate visual collaborative modelling between the different disciplines. It is easily learned and empowers continuous knowledge sharing without the need to know a tool. In this workshop, you’ll learn the essentials of EventStorming, and how it can help you gain the necessary insights you need to deliver quality software. With our newly acquired domain knowledge, we can start modelling multiple models for the same problem with Domain-Driven Design patterns. This way of visualising gives us the power to quickly iterate over the different models and figure out which will be the best to use. You will end up with the confidence to start your coding journey TDD style!

ML.NET is a free, cross-platform and open source framework designed to build and train learning models and host them within .NET Core, .NET Framework applications, and .NET-standard libraries. Although relatively young and at an early stage in its development, ML.NET aims to democratise Machine Learning, by simplifying it to levels that are accessible for most software developers. The most interesting aspect of ML.NET is that it offers a quite pragmatic programming platform arranged around the idea of pre-defined learning tasks. The library comes equipped to make it relatively easy, even for Machine Learning newbies, to tackle common Machine Learning scenarios such as sentiment analysis, fraud detection, price prediction as if it were just plain programming. This workshop provides a tour of the general steps of any Machine Learning solution as they can be implemented in ML.NET, and how they compare to similar Python solutions. An array of challenges will be demonstrated, such as price prediction, image classification with transfer learning, sentiment analysis, and clustering. Importantly, the training phase will be neatly separated from the production, and an end-to-end ASP.NET solution will be presented – including the challenges it poses of mapping HTML forms to machine learning features and labels. The workshop is broken into four parts: (1)planning an ML.NET project (ML context, pipelines, trainers), (2) tour of the predefined tasks, (3) end-to-end solution, (4) transfer learning and interoperability.

Architects always strive for modularity to achieve extensibility, maintainability and reuse. The technology for the modules, these Microservices, changes over time, and yet the very use of smaller blocks introduces inherent complexity. When you design a highly modular system, it would be naive of you to expect that the only things you will do differently will be limited to design and technology. The development process itself needs to be modular, accommodating the complexity of the Microservices as a system. In this intense workshop, Juval will share his original techniques, metrics and ideas, all practised in real life, allowing for a Microservices-oriented development process. He’ll present a battle-hardened approach that you can immediately apply to achieve robust applications, manage requirements, and ensure faster time to market. You will also see how the various team members – the architect, the project manager, and the developers – should work in concert, and you’ll gain an understanding of their respective tasks and responsibilities towards the system and the Microservices.

How would you like to see an actual, quantum computer, actually working? How would you like to program it yourself?

Everyone’s heard about quantum computers – how they’ll be able to solve every computational problem in the blink of an eye, decrypting every coded message, and spilling our secrets across the internet.

Actually, small quantum computers exist today, and we can use them to run real algorithms. Soon, as we’re able to make them bigger and faster, quantum computers are going to be an indispensable part of the programmer’s armoury, routinely solving problems in optimisation, recognition, machine learning, and simulation that no other technology can handle.

Quantum computers are worth studying now because they’re just about ready for commoditisation and large-scale adoption, in the same way that AI systems are now being commoditised. Furthermore, quantum thinking is a useful skill to have: the kind of techniques that are used to tame uncertainty in quantum systems can also be used to tame unreliability in networks of conventional computers.

This session expands on the theory underlying quantum computation. We’ll talk about quantum fields, and why uncertainty and entanglement are important. We’ll talk about qubits and their operators, and about the nature of quantum algorithms, and we’ll introduce the Universal Quantum Machine. We’ll look at some of the different architectures that quantum processors have used, and explore the unique range of problems that each type can solve (and what they can’t).

Starting with a very simple “Hello, Quantum World”, we will create some programs on some quantum hardware and gradually build up their complexity to a point where you’ll be able to create original programs of your own.

Finally, we’ll explain what the future holds: how much more processing power we can expect to come online in the next year, or two, or ten; when and how the processors will become miniaturised enough that they will fit in a PC or a phone; and what career opportunities are likely to to be available in the decade to come.

By the end of this session, you’ll be able to develop your own quantum algorithms, write and test your own quantum programs, and deliver quantum-derived solutions into your workplace.