The term microservice has been getting a lot of hype and attention. I have to admit that I fail to understand what’s the big deal about it. The best practices about microservices are similar to the ones we should apply to everyday software design. Avoid tight coupling. Single responsibility principle. Keeping things simple. Even those principles go back to the old Unix mantra of doing one job and doing it well (and that’s from 1978). And even that could in turn be labelled just “common sense”.

In this post I’m using the Maven Enforcer plugin to break the build when certain files don’t follow the expected naming convention. It’s always a good idea to take the time and implement these checks inside the build pipeline. The alternative is hoping that code reviewers will spot the problems, which is a manual, tedious and error prone approach. Automate all the things!

If your Windows PowerShell profile is inside your OneDrive folder and you don’t like that, this is what you have to do:

• open the Registry Editor
• navigate to HKEY_CURRENT_USER, SOFTWARE, Microsoft, Windows, CurrentVersion, Explorer, User Shell Folders
• change the Personal key's value

When it comes to installing software on a Windows laptop, I often prefer portable apps compared to Windows installers. I am also looking currently into Chocolatey as a package manager solution. But also there, I prefer portable apps.

TL;DR: I made a hobby project that gets the pull requests that still need code reviews from Bitbucket and posts a notification message on HipChat to inform developers. It’s written in JavaScript (nodeJS). Travis CI automatically deploys it to AWS as a Lambda function. AWS CloudWatch is used to trigger the function hourly.

A little bit more than a month ago, I created an improved Maven archetype project. Similar to the default quickstart archetype, but for Java 8 and with recent jUnit dependency. In order for someone to use it, they’d have to clone the repo, as I had not published it in Maven. After a bit of studying, I figured out what is needed to make the package public. More importantly, I implemented the process in Travis, so that a new version gets published automatically.

In this post we’ll create a small Java application, run it inside a Docker container, and use IntelliJ IDEA to debug. This is a rather large post, so take your time.

Using Kafka on your local development machine adds another level of complexity. You need to manage two extra services, Apache ZooKeeper and Apache Kafka. In a previous post, I mentioned the possibility of creating a Windows service wrapper for Kafka, so that managing is a bit easier. In this post, we’ll have a look at Docker and how we can use it to solve the same problem in a different way. I am new to Docker, so this is a very basic post, more like an introduction to Docker.

Code is going to be written once but read many times. A consistent coding style across the entire code base is important to increase readability and maintainability. Luckily, there are tools that can help to define and enforce such styling rules. From mere cosmetics up to nasty code smells, static code analysis can help increase the quality of your code. I wrote some posts on static code analysis in JavaScript a bit more than a year ago (which in the JavaScript world means the tools are now different, ESLint instead of JSCS/JSHint). In this post we’ll see the Checkstyle tool in the Java world, how to use it with TeamCity and IntelliJ and finally a few words about SonarQube.

Code Coverage is a useful set of metrics that show you how much of your code you’re impacting during testing. It doesn’t say much about the quality of your tests (you can read more in the old post What is code coverage?), but a 30% coverage is definitely worse than 90%. Let’s see how we can use JaCoCo to see our code coverage in the Java world. We’ll check a few options to use it, such as using it manually, using it within a CI, breaking the build with it, etc. The assumption is we’re working with a Maven project.