Nicolas Fränkel

During the pioneer area of the World Wide Web, the content was static. To serve it, a group of developers created a web server, which is now known as the Apache Web Server. The Apache Web Server is built around a module architecture. Developers created a module to run CGI scripts to add dynamic content to the lot. Users wrote early CGI scripts in Perl.

I’ve tried Go in the past, and the least I could say is that I was not enthusiastic about it. Chief among my griefs was how the language handled errors, or more precisely, what mechanism it provided developers with to manage them. In this post, I’d like to describe how a couple of popular languages cope with errors. A time before our time I could probably go back a long time, but I needed to choose a baseline at some point. In this post, the baseline is C.

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).

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.

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.

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.

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.

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.

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.