Nicolas Fränkel

An exciting part of software development is what was unanimously considered good practice at one point in time can be more ambiguous years later. Or even plain wrong. However, you generally need to do it multiple times over time to realize it. Here are my top learnings from my experience in Java projects. Packaging by layers When I started my developer career in Java, every project organized their classes by layers - controllers, services and DAOs (repositories). A typical project’s str

More than a decade ago, I wrote about the DTO: A data transfer object is an object that carries data between processes. The motivation for its use is that communication between processes is usually done resorting to remote interfaces, where each call is an expensive operation. Because the majority of the cost of each call is related to the round-trip time between the client and the server, one way of reducing the number of calls is to use an object (the DTO) that aggregates the data that woul

Designing an intuitive, user-friendly RESTful API is a tough job. It might already be a massive task if it’s your first attempt. Planning for the lifecycle management of your API is likely to be an afterthought. But it’s possible anyway: in this post, I’d like to propose a no-nonsense approach to evolving your APIs, even if it was not planned. The initial situation Let’s consider a sample application that says 'Hello' when using it. > curl http://org.apisix/hello Hello world > curl

A couple of years ago, I developed an application in Kotlin based on Camunda BPMN to help me manage my conference submission workflow. It tracks my submissions in Trello and synchronizes them on Google Calendar and in a Google Sheet. Google Calendar offers a REST API. As REST APIs go, it’s cluttered with String everywhere. Here’s an excerpt of the code: fun execute(color: String, availability: String) { findCalendarEntry(client, google, execution.conference)?.let { it.c

December was not a good time for Java developers and even less for Ops. The former had to repackage their apps with a fixed Log4J’s version, and the latter had to redeploy them - several times. Yet, every cloud has a silver lining. In my case, I learned about System.Logger. A good time to start using the new standard System.Logger API introduced in Java 9: https://t.co/SaBUnqEZqF. It works like SLF4J and by default logs using JUL but can use Log4J or any othet logging under the hood. https

This is the 10th post in the Start Rust focus series. The Gilded Rose Kata is a refactoring exercise. The full description is available on GitHub. Nowadays, the kata is much more widespread. It’s available in plenty of languages, even some that are not considered mainstream, e.g., XSLT or ABAP. In this post, I’d like to do it in Rust.

One of the Apache Maven committers recently wrote about their plans for Maven 5. I consider the following one of the most significant changes: In summary, we need to make a distinction between two POM types: the build POM, stored in the project source control, that uses v5 schema for build time, requiring a new Maven version able to use the new features associated to the new schema,the consumer POM, that is published to Maven Central in the good old v4 schema, so every past or future build t

Security is the poster child of a Non-Functional Requirement: most people don’t care until the proverbial fecal matter hits the rotary propeller. Consequences can range from losing reputation to legal liability to putting the business out. In my post on running unsecured code, I concluded that you should treat security as a risk - and left it at that. I think it warrants a dedicated post. Risk management is pretty much documented. You can find it in many engineering disciplines, if not ev

Last December, Log4Shell shortened the nights of many people in the JVM world. Worse, using the earthquake analogy caused many aftershocks after the initial quake. I immediately made the connection between Log4Shell and the Security Manager. At first, I didn’t want to write about it, but I’ve received requests to do so, and I couldn’t walk away. Hey @nicolas_frankel, isn't the #Log4j-Exploit the perfect argument against deprecation of the Java SecurityManager?!— Johan

If you’re implementing microservices or not, the chances are that you’re calling HTTP endpoints. With HTTP calls, a lot of things can go wrong. Experienced developers plan for this and design beyond just the happy path. In general, fault tolerance encompasses the following features: RetryTimeoutCircuit BreakerFallbackRate Limiter to avoid server-side 429 responsesBulkhead: Rate Limiter limits the number of calls in a determined timeframe, while Bulkhead limits the number of concurren