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.
Over the past years I attended hundreds of interviews. Many candidates proudly told tales on how they develop their projects with a microservice architecture. Often (I don’t want to say “always”, but from my memory I think it actually is “always”) it does not require many questions to see that they used a rocket launcher to kill a mouse. Microservices are hard. Everyone who experienced the pain of operating such an architecture can relate to it.
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.
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 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.