Earlier this month, I introduced you to Dapr, the Distributed Application Runtime. That was a mostly conceptual introduction, showing you how Dapr works and what it can do for you. But how do you integrate it into an existing application? That’s the topic for today. This blog will be a bit shorter than the introduction to Dapr. We will dive into interacting with Dapr from a Jakarta EE application. Example: online shopping cart The example is a small application, written in Java using Jakarta EE 8.
Building distributed applications or microservice applications brings a whole new range of problems. All those application components, or microservices, need to communicate with each other. How will we do that: using messaging, or would direct HTTP calls be a better choice? Often, we must make such decisions early in a project. Since it’s hard to change it later, we call it an “architectural decision”. But this is often an excuse so we can blame the architect if the choice turned out to be wrong.
Following the recent kerfuffle around the security manager deprecation, I was curious to see if a codebase I’m working on would also suffer. But how could I find out? There are no early access builds of Java 17 yet with the latest changes for this JEP. Maybe… I should set out and try to build it myself? But that’s sure going to be a lot of work… Or is it?
Java evolves at a much faster pace than it used to do. But not all of the projects we work on keep up with that pace. I have projects on Java 8, 11 and 15 - and sometimes I want to play with early access builds of newer versions as well. How to make sure I can build them without having to constantly switch Java runtimes?
During my work on Maven today, I found a very specific bug.
The error message wasn’t that clear, and I couldn’t make a guess what might’ve caused it.
I read about
git bisect a few times and figured that today, I would use that tool to find the bug.
Recently, the Maven community decided to push forward and start working towards a 4.0.0 release. The first question after this announcement is of course: what can we expect Maven 4 to bring us? A lot - and in this post, we want to highlight some of the features that we are particularly excited about.
When you operate servers, whether physical or virtual, at some point in time you may find yourself victim to bots or botnets trying to access your server over SSH. Even if you configure your server to not expose SSH on port 22 (the default), chances are you will be a target at some point. This is especially true if your server is hosted in a public cloud, since these typically reserve ranges or blocks of IP addresses. Apart from making it as hard as possible to scan your server, you can also serve the community and report those attacks.
Everything is code, and code is everywhere. For me, this means I put more and more stuff into version control. Whether it is infrastructure descriptions, documentation, software or this blog, I always store it in a Git repository. But sometimes this gets dirty, because you accidentally forget to change your Git user details.
Over the years, badges have become a way for open source maintainers to show the state of their product. Badges can give a quick overview of the code quality, test coverage or build health of an open-source product. The problem with code coverage is, however, that a high coverage doesn’t mean the tests are any good. If only there was a way to show the quality of the test suite…
Setting up new infrastructure can be a tedious process. It doesn’t matter whether it is on-premise or in the cloud. Many organisations have a long process of filling forms, obtaining budget clearance, asking for priority and verifying everything is set up correctly. The cloud promises us to make things better, and at least it got a lot faster. But still, we can make many mistakes in this manual process, and if we want to duplicate a deliberately crafted setup things become even harder….