At JCore, we follow a three year program to become senior developers. After following this program successfully, you will be promoted to the JDriven company. In the final year, we have a specialization in a topic of our choice. I chose to specialize myself further into security. I have been studying this topic for some time now, even contributing to the fast track courses as a security teacher. Until now, most of my time I spent on the defending side and now I want to take a look on "the other side". So my specialization is all about attack, also described as joining "The Red Team".

In my previous blog about Running AWS locally with LocalStack I’ve shown you how to use Localstack, a tool to mock your AWS environment on your local machine. When working with Localstack, I always had to prepare the environment for my application to run. Most of the time this could be done automatically via scripts, but some preparations, for instance editing some data in a S3 bucket, could become a little tricky.

More and more companies are switching over to cloud native environments. As a developer this gives me a lot of services to create awesome applications. The challenge that occurred to me right away was how to use all those new components during development, since some companies do not have a testing/development environment in their cloud provider to play with. LocalStack piqued my interest to simulate an AWS environment locally on my laptop, or when running the CI/CD pipeline.

Adding code coverage to SonarQube is quite easy for any Maven project nowadays. Just add the jacoco-maven-plugin dependency to your pom.xml, add the prepare-agent execution task, and you are good to go. Even for multiple modules this works out of the box. But time goes on and your application grows as well. You start moving code to other modules, and somehow SonarQube no longer seems to pick up the covered code. What the heck is going on?