Code-Held

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.

JPA entities have a couple of pitfalls and consequences when handling them in your application. Especially understanding how JPA manages and synchronizes the state of an entity is essential to avoid unexpected behavior. This can be unintuitive when passing JPA entities as method parameters in Spring Data in- and outside a transaction. In this post I will explain a best practice when working with JPA entities and when it’s okay to pass it through method parameters and when you should avoid it.

In recent reviews I stumbled upon extension functions which didn’t quite felt right, but I wasn’t able to determine where that gut feeling was coming from. After seeing quite a lot of them I came to some conclusions why that’s the case, and I gathered rules for me when extension functions make sense to use and when they should be avoided. I discovered an overuse of the language feature - something you often experience when you work with a new fancy language with nice features. In this post I’ll share my thoughts.

This week I was taught again that you should be thoughtful when applying patterns you read on the internet (which is ironic - because the same applies to this post ;-) ). This time colleagues heavily applied the Creational Design Patterns in Kotlin: Builder from Baeldung. Using the builder pattern in Kotlin in this example is an anti-pattern and in this post I will reason why you’ll end up with safer, less error-prone and less boilerplate when properly applying Kotlins language features instead of this builder pattern.