Nicolas Fränkel

This is the 2nd post in the Scala vs. Kotlin focus series. Last week, I started my comparison of Scala and Kotlin with the Pimp my library pattern. In the second part of this serie, I’d like to address operator overloading.

I know about Lombok since a long time, and I even wrote on how to create a new (at the time) @Delegate annotation. Despite this and even though I think it’s a great library, I’ve never used it in my projects. The reason for this mostly because I consider setting up the Lombok agent across various IDEs and build tools too complex for my own taste in standard development teams. Comes Kotlin which has support for IDEs and build tools right out-of-the-box plus seamless Java interoperabi

As an ardent promoter of Mutation Testing, I sometimes get comments that it’s too slow to be of real use. This is always very funny as it also applies to Integration Testing, or GUI. Yet, this argument is only used againt Mutation Testing, though it cost nothing to setup, as opposed to the former. This will be the subject of another post. In this one, I will provide proposals on how to speed up mutation testing, or more precisely PIT, the Java Mutation Testing reference. Setting the bar

Logging is a not a sexy subject but it’s important nonetheless. In the Java world, logging frameworks range from Log4J to SLF4J via Commons Logging and JDK logging (let’s exclude Log4J 2 for the time being). Though different in architecture and features, all of their API look the same. The logger has a method for each log level e.g.: debug(String message)info(String message)error(String message)etc. Levels are organized into a hierarchy. Once the framework is configured at a certain

My post about immutability provoked some stir and received plenty of comments, from the daunting to the interesting, both on reddit and here. Comment types They can be more or less divided into those categories: Let’s not consider anything and don’t budge an inch - with no valid argument beside 'it’s terrible'One thread wondered about the point of code review, to catch bugs or to share knowledgeRational counter-arguments that I’ll be happy to debate in a future post'I

A little more than 2 years ago, I wrote a post on how you could create a Die rolling API in Scala. As I’m more and more interested in Kotlin, let’s do that in Kotlin. At the root of the hierarchy lies the Rollable interface

Some developers have hardly ever touched software labels translation, some do it on a day-to-day basis. It sure helps to work in a country with more than one language – official or de facto. Even for in the first case, it’s considered good practice to externalize labels in properties files. As for the second case, languages are in general related. In Java, the whole label translation mechanism is handled through a hierarchy of properties files. At the top of the hierarchy lies the root file,

Before being software developers, we are people - and thus creatures of habits. It’s hard for someone to change one’s own habits, it’s harder for someone to change someone else’s habits - and for some of us, it’s even harder. This, week, during a code review, I stumbled upon this kind of structure.