Nicolas Fränkel

Let’s face it, most developers - myself included, prefer to deal with code than with people. However, when communicating with other developers, we share a common context and understanding, which makes a lot of explanations unnecessary. It’s the same for all specialized jobs, such as lawyers or civil engineers.

I don’t like dynamically-typed languages - scripting languages in other terms. Of course, I’ve to live with Javascript because it’s so ubiquitous on the web, but given the chance, I’d switch to TypeScript in an instant. I was amazed by a demo of the Griffon GUI framework, and have read some pretty good stuff about the Spock testing framework, but I barely looked at them because they are based on Groovy, a scripting language (even if it offers optional enforcement of types

Most of our day-to-day job is learned through mentorship and experience and not based upon scientific research. Once a dogma has permeated a significant minority of practitioners, it becomes very hard to challenge it. Yet, in this post, I’ll attempt to not only challenge that sometimes tests must be ordered but prove that in different use-cases.

If you listen to other language communities - such as Python or Ruby, it seems Java developers have a strong tendency of over-engineering. Perhaps they’re just jealous of our superior platform (wink), perhaps there is some very slight reason that they believe so. I do believe so. And it’s quite interesting that I realized it by doing code review - while I may be guilty of over-engineering myself when writing code. But I’m working on it. Of course, you’re a 'simple' dev

TL;DR: Vaadin was hardly SEO-friendly in the past. Not anymore, with the new Volga library. Bookmarking pages Bookmarking is as old as www itself. Being able to save an URL is part of the ADN of websites. Regarding web apps, this is somewhat different. For example, in an e-commerce webapp, while it does make sense to bookmark a specific product, bookmarking a specific step of the checkout process does not. Following the shop example, here’s what happens in a traditional servlet-based

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.

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.

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.