Unnecessary Unit Tests

Don't confuse configuration and constants

From time to time I experience that an application is unnecessarily configurable. In a recent project I experienced how too many options lead me to feel much more complexity and increased my mental load. Looking deeper into some of the values I saw that these were actually constants that would be dangerous to change “on-the-fly” anyway. In this post I reflect on this and share my thoughts.

In this project the backend processes data from an embedded devices that communicate through LPWA networks. This sets specific constraints on the system. While we developed on that system the embedded developers figured out specific values for the best user experience in terms of e.g. timeout configurations. These values were intuitively implemented as spring properties, since we had to “play around” a bit in the beginning and the underlying library that we configured also called the properties a “configuration”. But then it stayed in the project. And in the application.properties. When I joined the project this confused me. It created the impression, that these values are meant to be configurable. But actually this is not the case. For our system - with the specific constraints - these values are constants.
I actually don’t want to configure them without testing the application. Also, these values are in sync with our firmware. So I can’t even change them without a coordinated effort. In these scenarios I rather want to have a separate deployment and force myself to go through the whole build-test-run cycle.

Marcus Held

Java Bean Validation is an Anti-Pattern

The javax.validation package is widely used in our industry. And I don’t like it. I believe using bean validation is an anti-pattern. It hides business relevant constraints, it leaves the choice when a validation happens to other framework code, and I even saw cases where developers expected that the validation “just had to take place”, but it never happened. Of course, there was also no test for it. And speaking about tests - testing these business relevant constraints is painful as well.

Marcus Held

New Position and the Future of This Blog

Today I write an unusual post for this blog - A personal note. I recently took the responsibility of the System & Infrastructure department. As you can imagine taking over such a position comes along with a lot of work - especially when you didn’t get rid of the old responsibilities yet. That’s the main reason why I didn’t write a blog in the past months.

But what about the future of this blog? In my new responsibility I’m farther away from the actual technology and on this blog I especially focused on that. I don’t know how it will turn out for me, but when I managed to get into the new role and sorted out how I want to approach things, I definitely plan to get closer again. Until then, I might write a blog once in a while. I don’t know about what yet. And it might be about some management stuff as well - but time will show. This blog was and is a platform for me to sort things out for myself, organize my thoughts, and to make my argumentation’s comprehensible. And it will remain like that.

Marcus Held

Prefer UUID for your Primary Key

In my last post I discussed the downsides of using numerical types for the primary key of an entity. We should avoid these issues all together by using UUID instead and in this post I will discuss the up- and downsides of this approach.

Using a UUID as the primary ID is simple:

@Entity
class Flat(
    @Id
    val id: UUID = UUID.randomUUID()
)

Generate the ID on the application

Similar to numerical ids we can generate it on the database as well. But for UUID this is not necessary. The reason we did this in the first place is that we needed to make sure that an ID is not used twice. A collision of UUID is very unlikely to occur.

Marcus Held

The Inevitable Consequence of a Numerical Id

In many (JPA) applications numerical ids are chosen for the surrogate key of the entities. But how do we make sure that they are not used twice? In a scenario where our application needs to scale horizontally we need a solution for that. Most developers come to the conclusion that the database should take care of that. But this is a fragile solution and in this article I want to discuss it.

Marcus Held