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.
Mocking library is an important tool in every developer toolbox. Sometimes you want to do things that at first glance look a bit more complex than returning number 42 from some method. Let’s see what stubbing techniques are available in Mockito out of the box and what they offer.
We are improving cache in the project Im working on. In the code base I’ve found a method which accepted a collection of ids and returned collection of objects for those ids. My goal was to add cache on individual values returned by the method. Creation of items was IO heavy and time-consuming operation so removal of cache was not an option.
In the past, I’ve implemented couple of tests that aimed to verify naming conventions or some other practices team agreed upon. And presented a way how to ensure they are followed. When I’ve been writing those I was not aware that there is a library that aims to test architecture conventions - ArchUnit in this post I’ll write a simple test case to check what’s possible out of the box.