option optional nullable type Functional Programming

Handling null: optional and nullable types

Java has long been infamous for its NullPointerException. The reason for the NPE is calling a method or accessing an attribute of an object that has not been initialized. var value = foo.getBar().getBaz().toLowerCase(); Running this snippet may result in something like the following: Exception in thread 'main' java.lang.NullPointerException at ch.frankel.blog.NpeSample.main(NpeSample.java:10) At this point, you have no clue which part is null in the call chain: foo, or the value ret

architecture microservices system design

APISIX, an API Gateway the Apache way

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. After a while, it became evident that generating a complete HTML page from scratch was not the best way and that templating - providing an HTML

language design error handling Java Rust Go Functional Programming

Error handling across different languages

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. If you search for 'err

good practices learning by doing lessons learned retrospective

Lessons learned from previous projects

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

DTO Cargo Cult Software Architecture

Alternatives to DTO

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

API lifecycle management REST

Evolving your RESTful APIs, a step-by-step approach

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

kotlin type system strong typing

Avoiding Stringly-typed in Kotlin

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

system logger logging API facade abstraction

System Logger

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

maven plugin POM

The Flatten Maven plugin

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