The term Microservices is quite vague as it leaves many questions unanswered. Contrarily, a Self-Contained Systems subsumes concrete recommendations and best practices that can guide you to create an application which is resilient and independent. But how can we implement such a system? At Spreadshirt, we build an application following the recommendations of a Self-Contained System. In this post, I’ll show you which technologies we used and which challenges we faced.

Imagine you clone a git repo and try to start its application in your IDE. It fails. Why? The database is missing. After installing and starting a database manually you look at an empty application. There is no data in the database. Moreover, the application still doesn’t work as it requires an external service… The process of setting up a local development environment is often a journey of pain with many manual actions and implicit knowledge. How cool would it be, if we just have to call docker-compose up and the whole environment is automatically created locally containing nice dummy data?

On April 25, 2018, I held a talk about my favorite topic “Kotlin in Practice” at the JAX Conference in Mainz. I’m still impressed by the huge amount of people that have been interested in my talk (~ 350 folks). There weren’t even enough chairs for everyone. I’m still thrilled! Thank you so much! Also for the great questions during and after the talk.

“Maven is old school” they said. “Use Gradle instead. It’s the future of building Java applications” they said. Sounds like something you don’t want to miss. So I tried Gradle in two real-world projects. In this post, I like to tell you about my experiences with Gradle and why I finally migrated back to Maven. It’s a story about enthusiasm and disillusionment.

On March 13, 2018, I held a talk about “Kotlin in Practice” at the JavaLand Conference. The conference was awesome and 1900 people attended. I guess about 300 folks came to my talk although it was so early in the morning. That was awesome! Thank you so much! Special thanks go out to the guys that approached me after the talk and the kind tweets. I’m still euphoric. :-)

Unit Testing in Kotlin is fun and tricky at the same time. We can benefit a lot from Kotlin’s powerful language features to write readable and concise unit tests. But in order to write idiomatic Kotlin test code in the first place, there is a certain test setup required. This post contains best practices and guidelines to write unit test code in Kotlin that is idiomatic, readable, concise and produces reasonable failure messages.

In the last post, I presented the Timestamp_Offset_Checkum continuation token for implementing web API pagination. After using them in practice for a while we discovered some drawbacks and finally came up with a new approach: Timestamp_ID. This approach is fast, scalable, efficient, stateless and easy to implement. Our pursuit of the best pagination strategy has finally come to an end.

Implementing proper pagination for Web APIs is not trivial. Offering limit and offset query parameters doesn’t cut it because this approach is slow and error-prone. But also keyset paginations with parameters like modified_since have drawbacks. Fortunately, there is a better approach: Continuation Tokens (aka Cursors). They provide fast, reliable and stateless pagination and make the client implementation very straight-forward. In this post, I propose the Timestamp_Offset_Checksum continuation token, the algorithm and point to a library simplifying its implementation.

During development, it’s important to have fast feedback loops after code changes. Waiting for a cold restart of the application is not satisfying at all and slows down the development process. In this post, I show how we can reduce the turnaround time by using certain JVM arguments and class reloading. Besides those framework-independent means, I’ll give some tips for Vaadin and Spring Boot applications.

Hibernate is my daily business. And it bugs me. Hibernate adds non-trivial complexity to your application and restricts the flexibility in terms of the query capabilities and the class design. Fortunately, there are many alternatives available. In this post, I like to recap some drawbacks of Hibernate and present an alternative: Do-it-yourself ORM with plain SQL, Spring’s JdbcTemplate and compact mapping code powered by Kotlin.