Reboot

This blog has been stagnant for some time now. I vowed most of my time to my work, and the spare I had, I selfishly kept to me.

Time to start over, though. In the past weeks, I changed client, discovered new coding ways, wanted to share, but also wanted to make something clean while not losing some posts people have been used to easily find.

Hope I will stick to my writing a little more, and hope it will be useful. Have a nice browsing.

When to use log.isDebugEnabled?

One of the first coding-related question my partner asked me when I joined my current project: do you use log.isDebugEnabled()? This is a recurring question, and my answer is generally the same: “No.” Still, there is some nuance in this no. I will try to get to the point today and forget my usual digressions.

Continue reading When to use log.isDebugEnabled?

Better comparison of Java implementations

I already posted a class to enable the comparison of Java method implementations. However, this was a draft method rather than a true solution.

Today, I come back with a(n almost) valid solution. You can get it on my Github repository: labs-java, implementation-comparer branch.

Basically, it will be able to compare several implementations of any class within its context, rather than the previous solution which forced you to rewrite the methods within the comparer.

Let us imagine you have a Foo class with a bar(String arg), but you suspect this method can be written in a better and more efficient way, but you want to ensure both methods return the same results and make sure which methods is the most efficient.

You will have to write the variants for your method, and suffix them with an incremental index (bar1(String arg), bar2(String arg), …). Then, you will call the implementation comparer with some arguments you wish to test:

This will output something like this:

The time checks are performed only if the info log level is above INFO, and the result comparison displays the details only on debug level, but the compare method returns true if all methods return the same result, and false otherwise.

This comparer can be really useful when you are refactoring or even included in unit testing if you find a use for it.

For more details, you can have a look at the class itself. It is really not that complicated and I made it an obligation to have documented code nonetheless.

As a reminder, you can also have a look at my my previous draft version, which came with more explanations. The main principle remains the same, only with more freedom.

And if you need help, you can always ask below, as I will not go further into details right now.

For the logging of tables, I used Alcibiade’s asciiart library.

All this just in preparation of my next post… And yet, I am quite satisfied with myself and feels this will come in handy next time I refactor…

Comparing multiple directories (Java)

Several tools enable the recursive comparison of directories, but most of them allow for the comparison of only two directories (like my favorite, WinMerge). KDiff3 goes as far as comparing three files or directories.

As for me, I needed to compare up to five directories. As a consequence, I implemented my own algorithm. Read for more information.
Continue reading Comparing multiple directories (Java)

ASETNIOP, the next step of Dvorak keyboards?

The first Dvorak keyboard (and all the variants that appeared afterwise) were designed to avoid wrist injuries by reducing the distance your fingers have to move when typing. Still, movements were still required.

ASETNIOP might be the same philosophy, just one step further: when using it for typing, you do not need to move your fingers anymore.
Continue reading ASETNIOP, the next step of Dvorak keyboards?