A Java geek

Sep 4, 2016 technical debt refactoring software engineering

Limits of the technical debt analogy

The triangle of project management is a well-known model, used through and through since ages. I assume most software developers, even junior ones, are familiar with those: TimeCostScope As for my personal experience in the software industry, all projects have been behind schedule, with only a few exceptions for small projects (some man-months). The reason might probably because initial estimations were too low, either by accident or on purpose, but that is a subject best tackled in anothe

Aug 21, 2016 scala kotlin

Scala vs Kotlin: inline and infix

This is the 3rd post in the Scala vs. Kotlin focus series. This week, I’d like to address two features: inline and infix - not because they’re related but because neither of them would be enough to fill a post. Inlining comes from C (and then C++). In those languages, a hint could be provided to the compiler through the inline keyword. By doing so, it may replace an inlined function call by the function body itself in order to skip the overhead of a function call.

Aug 14, 2016 testing end-to-end testing behavior-driven development selenium cucumber spring

Starting with Cucumber for end-to-end testing

This week, my team decided to create a smoke test harness around our web app to avoid the most stupid regressions. I was not in favor of that, because of my prior experience with the fragility of end-to-end testing. But since we don’t have enough testers on our team, that was the only sane thing to do.

Aug 7, 2016 performance software engineering

Performance cost of reflection

In Java, it’s widely admitted that reflection - usage of the java.reflect API, comes at a high cost in terms of performance. Older Java versions had huge performance overhead, while it seems that newer versions bring it in the acceptable range. But what does 'acceptable' really mean? This is the question I asked when commenting on a performance review that advised to replace code based on reflection by standard code.

Jul 31, 2016 refactoring software engineering

You don't talk about refactoring club

The first rule of Fight Club is: you do not talk about Fight Club. The second rule of Fight Club is: you do not talk about Fight Club. I guess the same could be said about refactoring. That would first requires to define what I mean by refactoring in the context of this post.

Jul 24, 2016 scala kotlin

Scala vs Kotlin: Operator overloading

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.

Jul 10, 2016 scala kotlin

Scala vs Kotlin: Pimp my library

This is the 1st post in the Scala vs. Kotlin focus series. I’ve been introduced to the world of immutable data structures with the Scala programming language - to write I’ve been introduced to the Functional Programming world would sound too presumptuous. Although I wouldn’t recommend its usage in my day-to-day projects, I’m still grateful to it for what I learned: my Java code is now definitely not the same because Scala made me aware of some failings in both the language

Jul 3, 2016 kotlin arithmetics

Fixing floating-point arithmetics with Kotlin

This week saw me finally taking time to analyze our code base with Sonar. In particular, I was made aware of plenty of issues regarding floating-point arithmetics. Fun with Java’s floating-point arithmetics Those of you who learned Java in an academic context probably remember something fishy around FP arithmetics. Then if you never used them, you probably forgot about them. Here’s a very quick example of interesting it turns out to be: double a = 5.8d; double b = 5.6d; double

Jun 26, 2016 lombok kotlin

Comparing Lombok and Kotlin

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

Jun 19, 2016 mutation testing quality performance

Faster Mutation Testing

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