The story is really simple. I wanted to accept my class as rest controller method param. I decided that I don’t want to convert a simple string to object every time and it would be faster if I do the conversion in the single place. After a quick research I’ve found Converter interface which looked like perfect for the job. After some digging and investigation it turns out that there is a lot of automagic in the Spring conversion service.
Most of the application we are working on are built around the data. Since the information is the core value of the application we store it in the persistent and reliable storage - database. Applications evolve in time so does the way we store the data. In this post, I’m going to present my experiences and thoughts on evolving database schema.
While investigating @EventListeners in spring I’ve noticed very interesting annotation - @DomainEvents. In this post I’m going to check what can be achieved using @DomainEvents annotation and how to effectively use it with old good JPA. Let’s start with short introduction to domain event idea if you are not yet familiar with it. Now let’s go back to the @DomainEvents annotation in spring-data. Spring-data by default provides support for this annotation and it’s complementary annotation @AfterDomainEventPublication.
I do like to write tests in Spock. I’m not sure if I know every feature available but until lately I felt comfortable with my knowledge. Obviously, I should not. There is always something that can catch you off guard. The question is how long will it take to figure out what’s happen.
Last time I wrote about events in a spring based application I’ve introduced some basics on how events can be dispatched using spring infrastructure. In this post, I’m going to dig deeper into an order of handlers, exceptions and asynchronous events handlers.
At some point in your career, you will not be happy with just a job, you’ll be looking for something which will keep you interested and will sharpen your skills. Lately, I’ve been looking for something new to do. Since I got burned last time I’ve jumped ships I decided it is the time to prepare a list of the interview questions for my potential employer.
When I’ve got some free time I try to add new features to springmock. Lately, after adding some new stuff I realized that double definition parsing class has more than one responsibility (class parsing, naming, definition creation, etc). So I’ve decided it’s time to refactor it and split responsibilities into dedicated classes. Once I did that and tests in the shared kernel started to pass I executed mvn verify just to be sure that everything was working and it wasn’t…
Code review is a great process which gradually improves code quality. It is a system you can implement in many ways. In this post I’m going to grumble about one particular way of performing code reviews - when there is only one person responsible for doing code reviews and suggesting/accepting/rejecting changes.
We all know how inheritance works and implemented some kind of class hierarchy at least few times during our career. Some of us know already that inheritance is not the silver bullet. Some of us know that inheritance must not be overused and considered with caution. Now I’m going to show you how choosing the quick win might cost you some unexpected troubles in the future.