A Java geek

Some resources on the Internet are written in a very imperative style - you must do that in this way. And beware those that don’t follow the rule! They remind me of a french military joke (or more precisely a joke about the military) - but I guess other countries probably have their own version, regarding military rules. They are quite simple and can be summarized in two articles: Art. 1: It’s mandatory to obey the orders of a superior. Art. 2: When the superior is obviously wro

Last week, I had a heated but interesting Twitter debate about Code Coverage with my long-time friend (and sometimes squash partner) Freddy Mallet. The essence of my point is the following: the Code Coverage metric that most quality-conscious software engineers cherish doesn’t guarantee anything. Thus, achieving 80% (or 100%) Code Coverage and bragging about it is just as useful as blowing in the wind. For sure, it’s quite hard to have a fact-based debate over Twitter, as 140 chars

This week, I’ve lived again an experience from a few years ago, but in the opposite seat. As a software architect/team leader/technical lead (select the term you’re more comfortable with), I was doing code reviews on an project we were working on and  I stumbled upon a code throwing a NullPointerException: that was a big coding mistake. So I gently pointed to the developer that it was a bad idea and that I’d like him to throw an IllegalArgumentException instead, which exactly th

Two weeks ago, I was at the JavaZone conference for the first time. There, I facilitated a Vaadin 7 workshop and presented an Introduction to Mutation Testing. Moreover, I attended many great talks by brilliant speakers, but one was really head and shoulders above the lot: 'Software Design, Why, When and How' by Kent Beck.

I guess many of you readers are familiar with the Open/Closed principle. It states that: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification This other Open/Closed principle is completely unrelated, but just as important. It states that: When 'something' is opened by one’s code, one MUST close it as well!

Many knows the tradeoff of using exceptions while designing an application: On one hand, using try-catch block nicely segregates between regular code and exception handling codeOn the other hand, using exceptions has a definite performance cost for the JVM Every time I’ve been facing this quandary, I’ve ruled in favor of the former, because 'premature optimization is evil'. However, this week has proved me that exception handling in designing an API is a very serious decision. I&#

For sure, software security should be part of every developer’s requirements: they should be explained and detailed before development. Unfortunately, it happens in real life that this is not always the case. Alternatively, even when it is, developers make mistakes and/or have to make with tight (read impossible) plannings. In the absence of security checks automated tools, sooner or later, an issue will appear. I’ve been thinking about a way to sanitize the output of a large-scale