We all know mocking libraries like Mockito or Mockk to mock classes in our unit tests. They can be convenient to mock I/O with external systems by replacing the boundary classes (aka. DAO = Data Access Objects) with mock objects. That way we do not require a full-blown simulator of that external system. However, mocking using these libraries also has some drawbacks. One way to avoid these drawbacks is to write your own mocks.
Suppose you are testing a set of Quarkus based microservices. They run as Docker images inside a Kubernetes cluster on your local machine, e.g. using MiniKube or Rancher Desktop. At some point you find a bug in one of the services, or you find that you need an extra logging in code. Now you would like to quickly modify the code and redeploy it in your Kubernetes cluster. Typically your Docker image is build using a build pipeline on a build server, which may take several minutes. Can this be done any faster and easier? With Skaffold you can!
When using mutual TLS (mTLS), the client authenticates the server by checking whether the server’s certificate is signed with a trusted CA certificate, i.e. a certificate that exists in its trust store. And vice versa, the server authenticates the client by checking the client’s certificate against its truststore. Both authentications are done at TLS level. Mutual TLS thus requires truststores and keystores on both the client and server side. One-way TLS only requires a keystore on the server side, and a truststore on the client side. So one-way TLS requires a simpler client setup, because it does not need a client specific keystore. But how does authentication work with own-way TLS. Specifically, how does one protect againts a man-in-the-middle attack?
The Gradle Java plugin extends the Base plugin and provides the tasks needed to build a Java (or Kotlin) project. They resemble the Maven build phases for those familiar with Maven. See also Migrating Builds From Apache Maven - Understanding the build lifecycle However, the output from Gradle generally is very different than that of Maven, usually more concise. This is not always what you want. Below you will find some nice commands, options, and configurations that can make the output to the console more complete (a bit more like Maven). This can be particularly helpful when building in a pipeline (eg. GitLab, GitHub, etc.), in which case log files and build reports are usually less or not available. Most of the time all you have is the output to standard out, in which case you would like it to be as complete as possible, specially when the build fails.
This short story is all about the absolute joy you can experience as a Developer. I wrote it to share what it is that I miss sometimes, now that I’ve taken on a different path these last years. I wanted to write it down to share a combination of feelings that I miss that other developers might recognise as well and can cherish even more because it is written down. Hopefully this blog brings a smile to your face if you’re a developer, and can even be something that you can rely on in darker times. When those blasted builds just won’t go green, tests won’t pass, or production is not the happy place that it should be.
