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.
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.
