The core principle of a microservice architecture - or simply microservices - is to split an application into small services that can be developed, deployed and operated independently from each other. Individual services may be assigned to separate teams and budgets. While decomposing an application into smaller pieces is a promising approach for complex applications, microservices also introduce some challenges, affecting technical aspects as well as organizational ones.In our Spring Boot projects, we have been using microservices for over two years now. For our teams, adopting a microservice architecture was completely new. We trapped into pitfalls and faced a lot of complexities we didn't expect. However, during the last two years, we gained many new insights. In this session, we want to share our learnings, talk about our architecture's evolvement and shed light on technical as well as organizational challenges.

This talk is an introduction to Kotlin for Java Developers of any experience level done by only live coding. There is no code on slides. The following topics are shown by live coding:

- Types and Type inference

- String templates

- Expressions overstatements

- Functions

- Pattern matching

- Null safety

- Functional Programming

- Extension Functions

In the talk, I will compare the Java- and Kotlin ways of doing things and show the simplicity of using Kotlin instead of Java to do daily tasks that developers have to do. For example default arguments in Kotlin instead of method-overloading in Java etc.

There are many programming paradigms. One of them is the object oriented programming. But... Do you really take advantage of it? Are you brave enough to say that you have real "objects" in your project? Having classes and creating something from them is not enough... Have you heard about SOLID or GRASP principles? Do you know what DRY mean? Let's investigate those and some other rules to make your code really object oriented, not just pack of public getters and setters tangled as spaghetti in classes and packages.

The notion of developer productivity is a key subject in our increasingly computerized society. It seems consistent to apply the same software engineering practices to the build as for your applications and libraries.
The recent evolutions of Gradle cover the technical aspect of the build but also the ways to implement.
We will see how developments for JVM projects and dependency management allow you to model your projects and publish your libraries with richer metadata. Some examples:
* modeling test suites,
*Java compatibility of your library,
* securing your dependencies
You will learn how to organize the construction of your software, whether a mono repository or several repos. Build logic will be reusable, convention-based, and with code quality and testing.
We'll also see how Configuration Cache helps speed up local development by starting tasks running immediately. You will learn how it works and what constraints it imposes, in alignment with idiomatic recommendations.

We write tests and code for other people. Tests are code too, and both should be clean. As a clean code fanatic, I see it as a personal mission to go around preaching how powerful clean code is. But unfortunately, it seems that test code is not considered "real code", and therefore is not considered "dirty".In this session, we'll talk about concrete examples of anti-patterns in tests, and how to clean them up. We'll see how clean code principles apply directly to tests. And that's true for all tests - from unit to end-to-end, and regardless of who writes them - developers and testers. We'll see those in action."Clean code looks like it was written by someone who cares.", said Michael Feathers. Test code may even be more important to write cleanly for that reason.