In this post, I’d like to show you how I’ve started with writing this blog. How the process evolved during 3 years of writing. How I’ve finally managed to set up everything in a way that works for me now. If you don’t blog yet this might help you out with technical details on how you can start easily. If you already have a blog maybe you’ll be able to pick up some ideas.
When I’ve first learned that there is something more than printing things to console log4j was state of the art solution. Then SLF4J joined the party and improved where log4j was lacking. The new version of LOG4J is available for some time already and I didn’t have a chance to look at what if offers. Let’s examine what’s possible with the second version of a very well known logging library.
Sometimes it’s good to have an option to try something out on the live environment. Checking things against production like traffic is the most reliable way to gather real-life metrics. In this post, I’m going to try and set up spring cache with a toggle. It’ll be possible to turn it off and on during application runtime possibly using external toggle service.
On almost every job interview there are questions about frameworks, programming principles, maybe some coding or whiteboard architecting. On the other side, there is the way you work. Tools and skills you use on a daily basis which define how you work. No one really asks about those things but I find them quite important.
At work, we are slowly breaking down the monolithic application into smaller manageable services. Some time ago we had a very interesting issue which proved that microservices are hard to implement. It’s especially true if you are not there yet but somewhere in the middle. When you need to introduce intermediate solutions which will enable you to work further on the migration to service oriented architecture.
Some time ago we had a problem with performance caused by generating big reports for users. During one of the firehouse meetings, there was an idea to generate reports from the replica database. We’ve solved the issue differently but the idea got me interested. In this post, I’ll configure spring-boot based application to use the replica database for all read-only transactions.
You probably already know that by default in spring transactions are rolled back only for runtime exceptions. When a checked exception is thrown from your code and you don’t explicitly tell spring that it should rollback the transaction then it get’s committed. In this post, I’m going to create simple reference material on when transactions are rollback when using Spring and Lombok.
One thing that a lot of people hate to do is writing documentation. Usually, it’s postponed until development is finished and once it’s done there is rarely time to do it properly. If you get past the struggle of writing it down there is always a problem of keeping it up to date. To avoid those pain points I’m going to explore what we can do with Asciidoctor to simplify this problem.
If you are not working with multithreading programming and don’t have to test any asynchronous code then this post will probably do you nothing good. But if you have ever struggled with testing some logic running in multiple threads and you don’t know Awaitility. A small library helps testing asynchronous code. If you’ve never heard of it then you should continue reading.