Menu
Trying to make the (IT) world a little bit better
QAware GmbH, Principal Software Architect, #CloudNativeNerd
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.
These days, many teams favor loose coupling, isolation and autonomy of services and therefore typically opt for event-driven and reactive architectures, using a communication pattern known as choreography. While choreography is beneficial in some situations, it is far from the holy grail of integration. In some scenarios, it increases coupling, often accidentally and to a dangerous degree. Orchestration is a better choice for some situations, but is often bashed for introducing tight coupling. I will debunk some of these myths and show how orchestration can even reduce coupling in some situations and totally work in an asynchronous, message-driven fashion. TLDR: Choreography vs. orchestration is NOT about choosing THE right approach. In real life, you need to balance both, so it is about choosing wisely on a case-by-case basis. In order to help you with that, I will walk you through the differences and give you some concrete guidance on decision criteria, backed by examples collected in various real-life projects.
Research shows that on average developers spend about 58 percent of their time on reading code! However, we are not explicitly taught reading code in school or in boot camps, and we rarely practice code reading too. Maybe you have never thought about it, but reading code can be confusing in many ways. Code in which you do not understand the variable names causes a different type of confusion from code that is very coupled to other code. In this talk, Felienne Hermans, associate professor at Leiden University, will firstly dive into the cognitive processes that play a role when reading code. She will then show you theories for reading code, and close the talk with some hands-on techniques that can be used to read to any piece of code with more ease and fewer headaches!
The clean code principles are well-known in modern, agile software development. But what has become the default for our business code, unfortunately by no means applies to our infrastructure code. Instead, we find badly crafted, complicated and highly tangled code that is manually tested using a trial and error approach. However, for modern cloud based systems the infrastructure code plays a crucial role. So it’s about time we being to treat it as a 1st class citizen! In this hands-on session we show several useful patterns, practices, tools and frameworks that help to write and craft clean infrastructure as code.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
