Enhance your knowledge of software design and learn the appropriate design principles and design patterns helpful for this purpose. Design patterns are always a current topic for solid software design and should be part of the basic knowledge of every ambitious developer. This workshop provides a sound overview of various design patterns. In addition to theory, practical exercises are a crucial aspect. The exercises help to use design patterns later profitably for viable solutions with required flexibility and clear structure. In practice, it can make a big difference between a successful, maintainable, and easily extensible solution and one where extensions are difficult to implement.
This workshop focuses on the famous and most relevant, and practically used design patterns from the Gang of Four (Gamma et al.). Additionally, we will have a look at some simplifications, variations, and extensions possible to new Java 8 Language features like lambdas and streams.
Everyone is talking about APIs, be it simple services or complete ecosystems that you want to expose via API. With all the tooling available, that is quite easy, is the first thought. But it is not. The challenge of an API is not its implementation, but its design: What needs to go into the API, what do I leave out? How do I present it in a way that users find it good? What else do I need to take into account if I want my API to be a success? In this workshop we will examine several API design anti-patterns and figure out what is needed to turn them into good design. Where needed, we will intersperse a bit of theory to fill our tool box. And we will take the time to create alternative designs together. This way, we will learn good functional API design step by step – aha-experiences included.
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speaker will start after lunch break each day due to the time difference.
When building modern architectures, the hard part isn’t learning Kubernetes. The hard part is changing the way (almost) everyone thinks. If we don’t transform our mental models and communication patterns, we will deliver the exact same system we already have. Regardless of how performant our microservices are. Everyone can develop confidence in the thinking they facilitate. To develop trustworthy thinking, we need to practice argumentation: reasoning systematically in support of an idea, action, or theory. This systemic reasoning is the key to all transformational success because it delivers Integration Leadership. We apply this leadership as: – a method of inquiry – a skill we must practice – the integration of differing points of view – good judgement – the process of enabling others to make up their own mind Systemic reasoning enables people to communicate about systems, collectively arriving at the best possible solution, under the circumstances, when conditions are uncertain. (Conditions are always uncertain.) Developing this skill contributes more value than our technology-specific expertise. In this workshop, we’ll explore methods for providing integrative leadership by crafting sound reasoning, together. Feedback from previous workshops: ” I am often involved in such discussions as receiver of arguments and in most cases the offered solution only solves symptoms, doesn’t go deep enough. Now I have an advice ready why and how to go deeper.” “I went in with something that was more of a vague frustration for me and ended up with a well-organized argument that I’d feel comfortable bringing up with anyone.” “It changed my way of thinking and challenging others”
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speakers will start after lunch break each day due to the time difference.
Software architects have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which this platform-agnostic class highlights by investigating what makes architecture so hard. This class is divided into 2 main parts. Pulling things apart (Part 1) focuses on how to break up systems and identify levels of modularity. However, once you’ve broken apart your systems, how do you tie them back together? Putting them back together (Part 2) focuses on just this – the techniques of how to do contracts, orchestration, workflows, and transactions, while keeping everything loosely tied together and running smoothly.