Nicolas Fränkel

I’m a happy Dropbox user but that doesn’t mean I’m not watching similar products, either for myself or my clients. I even made some comparison. Criteria are the following: Features: even though the primary goal of those solutions are backup, some also permit to synchronize data between different computers, share documents with other users or even keep an history of multiple versions in order to restore if an error is madeFree treshold: every product has a free version where you

Amazing thing this week! Imagine this case: developers need to access production application servers logs. These are inaccessible for now because application servers machines are production level. So they are placed in a different network zone. Between the AS zone and the DEV zone, there’s a firewall configured to disallow access from developers machines. In order to solve this, a meeting is scheduled and soon, the room is filled by system engineers and software architects, all buzzing idea

No Java this week, just the solution of a problem I’ve encountered in the past weeks. Don’t be scared, it’s computer-related. Since a couple of months, I’ve become severely addicted to the excellent Dropbox. It has three features, that linked together are particularly interesting for me: online backup, computer synch and file sharing. If you don’t already have an online storage solution, look at it ASAP: it has a free 2Go version (and by the way, contact me at nico

My article from last week left me mildly depressed: my efforts trying to ease my Vaadin development was brutally stopped when I couldn’t inherit from a Java inner class in Scala. I wondered if it was an impossibility or mere lack of knowledge on my part. Fortunately, Robert Lally and Dale gave me the solution in their comments (many thanks to them). The operator used to access an inner class from Java in Scala is #. Simple, yet harder to google…​ This has an important conseque

People who are familiar with my articles know that I’m interested in Vaadin and also more recently in Scala since both can increase your productivity. Thus it is only natural that I tried to embed the best of both worlds, so to speak, as an experience. As an added challenge, I also tried to add Maven to the mix. It wasn’t as successful as I had wished, but the conclusions are interesting.

A year ago, a colleague of mine showed me a very interesting framework named Krank (latter renamed to Crank because the previous name means 'sick' in German, which does not bode well for any framework). Crank’s goal was to ease development on top of Java Persistence API 1.0. Two interesting features caught my attention at the time.

I’ve barely begun Scala and I learned plenty of facts on Java (see previous article on a javac compiler quirk). Now, I’ve come upon another interesting point, this time completely unrelated to the compiler. It’s strange because now that I’ve realized it exists, it makes me nervous on how I could have ignored it before. The core of the problem lies in mutable objects. IMHO, entities should be mutable because one can load one from the datastore, change it, then save change

Let me first say I was not at Devoxx 2010. Yet, I heard from Matt Raible’s Comparing JVM Web Frameworks. Like many, as I read the final results, I was very surprised that my favorite framework was not ranked first. I passed through all stages of grief, then finally came to realize the presentation itself was much more interesting than the matrix. The problem lies not in the matrix, but in the method used to create it.

How many times in the last couple of years have you seen an initialization servlet (a servlet which is used only once with the load-on-startup parameter) although a context listener could have been used in its place? How many times have you seen a JSP full of indecipherable scriplets though equivalent taglibs were available? How many times have you disagreed with someone who wanted to talk you into using DTO regardless of your application’s needs? I could go forever like that but the poin