A Java geek

With DevOps, metrics are starting to be among the non-functional requirements any application has to bring into scope. Before going further, there are several comments I’d like to make: Metrics are not only about non-functional stuff. Many metrics represent very important KPI for the business. For example, for an e-commerce shop, the business needs to know how many customers leave the checkout process, and in which screen. True, there are several solutions to achieve this, though they are

I had been pleasantly surprised last time when, after connecting on LinkedIn, a recruiter sent me a personalized mail. It was the first time it happened, and I found this gesture showed that the recruiter cared about the relationship. Besides, the job I currently have was found on LinkedIn - or more correctly, a recruiter found me for this job. This is to say that I have nothing against neither recruiters nor LinkedIn. Unfortunately, more often than not, I usually receive such messages: Hel

While attending JavaZone recently, I went to a talk by Neal Ford. To be honest, the talk was not something mind-blowing, many tools he showed were either outdated or not best of breed, but he stated a very important fact: application servers are meant to address resources scarcity by sharing resources, while those resources are no more scarce in this day and age. In fact, this completely matches my experience. Remember 10 years ago when we had to order hardware 6 months in advance? At that time

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!