Nicolas is a developer advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Currently working for Hazelcast. Also double as a trainer and triples as a book author.
Gone are the times when developers’ jobs ended with the release of the application. Nowadays, developers care more and more about the operational side of IT: perhaps they operate applications themselves, but more probably, their organizations foster increased collaboration between Dev and Ops.
I started to become interested in the Ops side of software when I was still a consultant. When Spring Boot released the Actuator, I became excited. Via its convention-over-configuration nature, it was possible to add monitoring endpoints with just an additional dependency.
Since then, other frameworks have popped up. They also provide monitoring capabilities. In this article, I’d like to compare those frameworks concerning those capabilities.N. Frankel
This week, I learned about a nifty “new” feature of Optional that I want to share in this post. It’s available since Java 9, so its novelty is relative.
We start with a sequence to compute the total price of an order, for which it is nowadays more adequate to use streams instead of iterations.
Optional makes the code less readable! I believe that readability should trump code style every single time.
Fortunately, Optional offers a stream() method (since Java 9). It allows to simplify the functional pipeline. Functional code doesn’t necessarily mean readable code. With the last changes, I believe it’s both.N. Frankel
When your application goes beyond a dozen of lines of code, you should probably split the code into multiple classes.
At this point, the question is how to distribute them. In Java, the classical format is the Java ARchive, better known as the JAR. But real-world applications probably depend on other JARs.
This article aims to describe ways to create self-contained executable JARs, also known as uber-JARs or fat JARs.N. Frankel