Code-Held

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.

In my last post I reflected 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.

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.

Did you work on the task to integrate Spring Security in a project? If yes you probably stumbled upon the decision which PasswordEncoder to use. I saw many developers actively researching that question and deciding on a concrete algorithm. In one project we even choose a less secure decoder - for performance reasons. Don’t. Just don’t! Don’t choose a weak encoder for performance. Actually, don’t choose at all! Let Spring handle your security.

Personal development goals in software engineering are not trivial to define. In general, goals should be SMART (Specific, Measurable, Achievable, Realistic and Timely). But in reality our field of expertise is that diverse and complex that it is not as easy to find those goals like in other professions. For someone working in the sales department a revenue goal is easy to define and to decide whether he succeeded or not. For us software developers it is different. In order to improve we need abstract goals that are independent enough to survive in our agile day-to-day business. I received many goals in the past, and a lot of them felt wrong, unfair and not helpful for my personal development. For my employees I took another approach. The overall goal needs to be to enable your colleagues and in this post I describe how I achieve that.