A popular approach is packaging by technical concerns. But this approach has some drawbacks. Instead, we can package by feature and create self-contained and independent packages. The result is a codebase that is easier to understand and less error-prone.
There are some principles in software development that I always try to keep in mind. They guide me when I’m in danger of heading in the wrong direction. That’s why I printed those principles and hung them on a wall in our office. In this post, I share this subjective set of quotes with you. There is also a PDF for download available.
Traditional hierarchy-based feedback flows are limited as they don’t consider the useful feedback of peers. To improve this, I suggest a “Complete Peer Feedback” session: All team members come together and share their appreciation and growth potential for their peers. In this post, I present our experiences with this approach, why we are enthusiastic about it and how you can adopt it.
Employee journey maps are a tool for preparing and structuring staff appraisals. They trigger reflection processes and reveal the employee’s motivation. Moreover, they can lead to interesting insights as they compare the different perceptions of the participants. And the best is: You only need two sheets of paper and a pencil.
Putting a fat jar into a Docker container is a waste of storage, bandwidth and time. Fortunately, we can leverage Docker’s image layering and registry caching to create incremental builds and very small artifacts. For instance, we could reduce the effective size of new artifacts from 75 MB to only one MB! And the best is that there is a plugin for Maven and Gradle handling everything for us.
I made a talk with the title ‘How to Mess up Code Reviews’ out of my blog post ‘Code Review Guidelines for Humans’. In September, I was allowed to hold it at the JUG Saxony Day near Dresden and the JCON in Düsseldorf. It was a great pleasure for me. Thank you so much for having me! Here you can find the slides for both talks.
Maintainable and readable test code is crucial to establish a good test coverage which in turn enables implementing new features and performing refactorings without the fear of breaking something. This post contains many best practices that I collected over the years of writing unit tests and integration tests in Java. It involves modern technologies like JUnit5, AssertJ, Testcontainers, and Kotlin. Some recommendations might be obvious to you, but some might conflict with what you’ve read in books about software development and testing.
I’m using MongoDB in production for many years. In this time, I tried different tools and development approaches; some turned out to be useful for us, others don’t. In this post, I like to share handy CLI tools for working with MongoDB, a Docker-based local development approach and helpful Mongo shell snippets.
Since Vaadin 10, SASS is no longer supported out of the box. Fortunately, it’s really easy to integrate SASS in a Vaadin 10+ app and its Maven build. But how can we ensure a fast feedback cycle during the SASS development? Restarting the app is cumbersome. Even a page reload would reset the UI state, which leads to annoying clicking through the app. Luckily, there is an approach that automatically exchanges the changed CSS without any browser refresh or app restart.
Testing classes in isolation and with mocks is popular. But those tests have drawbacks like painful refactorings and the untested integration of the real objects. Fortunately, it’s easy to write integration tests that hit all layers. This way, we are finally testing the behavior instead of the implementation. This post covers concrete code snippets, performance tips and technologies like Spring, JUnit5, Testcontainers, MockWebServer, and AssertJ for easily writing integration tests. Let’s discover integration tests as the sweet spot of testing.