Hot Topic

Unnecessary Unit Tests

January 12, 2024

Latest Posts

Entwicklungspraxis June 26, 2023

Laziness Prevails

Hi, Laziness prevails. Always. Countless times I’ve tried to adopt beneficial routines. I joined a gym - after a few months, I barely went anymore. I baked my own bread - after (admittedly) two years, I no longer did. I got up at 5 am to meditate and exercise - I couldn’t maintain this for more than 4 weeks. As good as these routines would have been, had I kept them up for years - they come with high investments. Carrying them out takes a lot of energy. To muster up the will, pack your things, hop on a bike, and head to the gym. That requires energy.

Marcus Held

Entwicklungspraxis March 20, 2022

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

Entwicklungspraxis August 2, 2021

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

Entwicklungspraxis July 15, 2021

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