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.
With spring 4.2 (released more than one year ago) serious improvements regarding embedded events were made. You probably already know it, but I’ve never had a chance to properly investigate it. Lately, when digging into code base of the system I’m currently working on I got an opportunity to see it in action and after quick glimpse, I decided to investigate it a bit further.
I’ve been using springboot for some time now, but there was that one thing that bugged me a lot. While writing integration tests with mocks you are forced to use mockito as the mocking library. That’s great and easy to understand if you are not using spock. The problem is that in spock there are better ways to mock stuff…
I left the company for which I’ve been working for last 4 years and now it is time to summarize my experiences. It is not the story of shady business nor confession of my sins (not all of it anyway), but rather my thoughts and experiences on working for a long time in the same company from which most of the time remotely.
Some time ago I’ve been struggling with mapping hierarchical data structure in angular. Labels hierarchy was complex (like 4 levels deep with multiple parents, multiple children, basically graph like structure with some logic behind it). In the end it was/is still working but that’s the best I can say about it.
We all love to write new stuff and learn about things. But when we’ve got to do something in one of the older applications we’d rather avoid it and lag as long as possible hoping that someone else will handle it. You shouldn’t be afraid of legacy code (as long it is not ball of mud). You should take the opportunity to look into the past, and learn from it as much as possible.
Some time ago I noticed new library in our code base - Random Beans which as the name suggests is a tool developed to easily create random data and random objects for testing purposes. Unfortunately, we used it in the wrong way. Here’s how we backed up from the random test data to regain control over testing.
Some time ago I’ve been trying to dynamically create spring beans. After fast stackoverflow check I decided to drop it and go with something else. Lately I’ve been trying to implement more complicated bean registration mechanism in which skipping dynamic bean creation wasn’t an option. Here’s how you can create spring beans “from code”.
Working with a lot of data using plain JPA or hibernate or spring-data is possible, it does work and usually, it doesn’t require a lot of extra coding. Starting small is the fastest way of getting things done but you must be aware of few things that might shoot you in the foot.
