Obfuscated by obfuscation

From time to time, I have to add in the list of dependencies of one my projects a library whose byte code has been obfuscated.

Who cares, would you ask? Well not me until I have to step debug into the said library because it is usually easier to follow an execution path than a technical guide. And then the pain begins: obfuscated library are (intentionally) a mess and you can not do anything in debug mode with them.

So here is my messages to vendors and other smart guys who think security by obscurity works: this is freaking retarded! You prevent legitimate users to do their business with your library the way experienced users do. No matter how good you think your user guides are, when something goes wrong, nothing replaces the ability to follow the actual execution of a program. As Bruce Schneier says it:

Security by obscurity: it doesn't work, and it's a royal pain to recover when it fails.

So please, do not obfuscate the libraries you distribute, no matter how proprietary you think they are. Your value, as a software company, does not reside in the heart of the few bytes that you try to hide. It lies in your people, your know-how and your services.

Let there be light!

Iconoclast

I am wondering how long this icon will keep meaning "Save" to anyone:


This icon does not mean anything for my kids already:


For them a phone is either cordless or cellular: no funny roundy thingy on it!

Coming back to my first example, the last time I have used a floppy disk was in 2005: is it time to overhaul our icons?

How To Always Look On Strike?

Follow the example of the world champion in the domain, i.e. SNCF.

Like them, implement some kind of lousy "not available" message to display if you hit your web site without typing www in the URL. Since many users now omit the dub-dub-dub prefix, your site (hence your company) will always appear under repair. Or on strike. Or both.

Try it! Click http://sncf.fr now!

Agitation On Demand

In my previous post, I talked about how sweet it is to push the limits of unit tests for the sake of increasing test coverage. During the testing frenzy I mentioned, I came to test a class whose most of the methods throw an UnsupportedOperationException.

Ugly? Well, this class is a subclass of javax.servlet.jsp.PageContext with a very narrow scope of usage, so this is why.

I wanted to generate calls to all these methods and catch the exception as the expected test result. My first thought was to use reflection to do this in a dynamic manner but before to opt for this approach I decided to Google for free unit test generators. This is how I came to discover JUnit Factory, a test generation service from Agitar. I already knew Agitar from Agitator, their award winning unit test generator. But their online generation service was unknown to me.

Needless to say that this service is very well done. The client I used is an Eclipse plug-in, that seamlessly installs on version 3.2 from a proper update site. To avoid uploading my whole project to their service, I isolated my troubled class in a temporary project and pushed the magic button.

A few seconds later, a test case was automatically added to my project, with all my problematic methods (and all the other ones) thoroughly test covered. Awesome: agitation on demand truly works! In other times, anarchists would have rejoiced.

When I decided to include this test case in my main project, I started to hit some issues. The unit test does not extend JUnit's TestCase but an Agitar custom one. Decided not to be stopped by such a minor issue, I promptly added their library to our Maven repository.

Then I pushed the execute button in Eclipse to run my tests and the Agitar test case complained because the launcher was the standard one from JUnit and not their own. This is when I called it quit. Of course, I could have modified my Eclipse start command to use their launcher. But with my Maven builds and reports?

That was a little too much to do and I decided to walk the path of reflection to systematically invoke the targets methods.

This is too bad because JUnit Factory is really a great concept. Try it, it might work very well for your needs.

Push Tests, Pull Cover !

I have nearly spent the whole day increasing the test coverage of one of my project. For traditional employers or ill educated project managers, this could sound like an incredible waste of time. For others, this could sound like pure geeky zealotry or a new mean of self satisfaction for IT nerds.

Indeed, seeing the coverage report display numbers above 80% is extremely satisfying but the true reason for this testing frenzy is elsewhere: this project being bound to play a critical role in the core of the business of my company, testing it thoroughly is simply the only option.

Beyond the assurance such a high coverage buys, the implicit documentation of the system's behavior that an extensive battery of test creates is worth the effort on its own. But there is more. As recently discussed by industry guru Andrew Binstock, writing tests will inevitably lead you to question both design and implementation. Hard to test classes full of not covered "blind spots" will cry for refactoring!

I was amazed to see my code getting simpler and more concise while I was struggling to push the limits of the test coverage. I wish you similar amazing moments!