jOOQ is an ORM library that sticks close to SQL, allowing you to write fast and efficient queries while providing a nice, type safe API for that. Before I started using it in my work, I was mostly relying on Spring Data + Hibernate combo. I was pretty skeptical, when I first learned about jOOQ. With it you write DDL first, create schema and tables, and then generate the classes for accessing those tables. With Hibernate you declare models in your code first, and then you can generate DDL out of them, while Spring Data can generate all the repositories for you, so in the perfect case scenario you only have to declare the models and repository interfaces. Seems like it’s almost a no-brainer, right? With Spring Data and Hibernate you write less code, so it’s less code to maintain and that’s always good. Unfortunately, in my experience that perfect case scenario was never the case. Almost in every project I had to either write JPQL or even plain SQL queries. And if you have have to write plain SQL anyway, why not embrace it and take full control of how you access the data in your DB? Let’s see how we can build a convenient and type safe data access layer with jOOQ and Kotlin.
Continue reading
Designing a type-safe, sane API that prevents consumers from misusing it could be crucial for further implementation of that API. Frustrated consumers, necessity for extra validations, delayed feedback and convoluted, hard to maintain code are just a few things you might have to pay with for poor design decisions during early development stages. Thankfully, Kotlin provides a plenty of tools to design a great API. Let’s have a look at how to build a good API with Kotlin to make your life and life of your API consumers easier.
Continue reading
Depending on your needs using polymorphism might benefit different aspects of the project. For example, having a limited class hierarchy might make your code cleaner and more expressive in contrast to a single class having nullable fields or a type label. And it only seems natural to use it with document-oriented databases like MongoDB. But if you want to have a document with polymorphic fields using MongoDB and Spring Data you might face an exception similar to this: MappingInstantiationException: Failed to instantiate ...FieldType using constructor NO_CONSTRUCTOR with arguments. Let’s see why this happens and how to fix that issue properly.
I have Fedora 36 installed on my laptop. Recently I’ve been using it a lot with a Bluetooth headset and noticed that sometimes WirePlumber creates high CPU usage. Turns out it was happening when the system was switching the Bluetooth profile for the headset from HSP to A2DP and backwards. There is a fix for that issue, but it is not yet available in Fedora’s repos. If you’re having the same issue, here’s how to fix it.
Continue reading
Update: the guide works for Fedora 36/37/38.
Before Fedora 36 it was a bit problematic to automatically sign kernel modules the same way Ubuntu does that. But starting with this release, you can do that in just a few easy steps. Here’s how to automatically sign NVidia kernel module in Fedora 36.
Continue reading