Hi, Faulheit siegt. Eigentlich immer. Wie oft ich schon versucht habe mir vorteilhafte Routinen anzueignen. Ich meldete mich im Fitnessstudio an - nach ein paar Monaten ging ich kaum noch hin. Ich backte mein Brot selbst - nach (immerhin) zwei Jahren war das nicht mehr der Fall. Ich stand um 5 Uhr auf, um zu meditieren und Sport zu machen - das hielt ich nicht mehr als 4 Wochen durch.
Hi, El Niño ist zurück. Periodisch schwankt die Oberflächentemperatur des Pazifischen Ozean. Diese scheinbar unscheinbare Änderung löst eine Kaskade von Wetterveränderungen aus, die ihren Einfluss bis in die entlegensten Winkel des Globus ausüben. Überschwemmungen in Südamerika, Dürren in Australien und sogar Schneestürme in Nordamerika - alles verursacht durch ein paar Grad Temperaturunterschied im Pazifik. Dieses Phänomen tritt alle 2 bis 7 Jahre auf. Dieses Jahr ist es wieder soweit.
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 complexity kills you at one point or the other. You already had to do multiple refactorings of your architecture - because your domains didn’t work out. I wonder - why is this architecture so appealing to developers? And then I remember why I found them appealing 10 years ago.
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.
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