If because of reasons you have to run Maria/Postgres/Oracle on localhost for development and you often import database dumps into it you probably spend some time waiting for DB to be ready to use. In this post, I’m going to show you how you can automate the whole process and save some time doing it with docker.
It all started on Friday, like many of the bad things that can happen in software ;) We’ve been working for some time and after being blocked with deployments for a long time (don’t ask, you don’t want to know ;)) we were finally able to deploy a new version. Our last release was about week ago. Do the deployment - seems like the easy thing to do. I’ve triggered deploy plan on Jenkins and it’s failed. Here is the story how I’ve fixed something that looked like hours of analysis in few minutes.
Imagine the situation when you’ve just released something on production and deployment went fine. You’ve just sent release notes and went out to grab a coffee. Once you are back you see an email with information that feature team have been working on for past 3 sprints doesn’t work at all. Turns out you forgot to change something in production server configuration. In this post, I’m going to present the simplest idea which will help you to avoid this kind of issues.
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.
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.
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.
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”.
Page object pattern is common practice when writing automated tests using selenium. It allows to gather all possible operations on the page in one place and hide page implementation details from test case. Page object pattern can be used in the same way for angular directives, react and [put framework name here] components.