2007 August | Muses et essais

Archive for August, 2007

Cartoonesque ProgressBar

Friday, August 10th, 2007

I second Romain Guy when he says that Progress Bars are boring: let’s part with this idea that a progress bar has to be a simple long rectangle that is half full or half empty… I am sure that we can find better paradigms, best suited for each case:

  • copy of a bunch of files: have a decreasing stack of files on the left and an increasing one on the right
  • CD burning: have a CD on fire that becomes just a pile of ashes when finished

Here’s my weak attempt at creating a Cartoon-like Progress Bar (you will need Java installed to run that), but it probably took me more time to configure the JNLP than to actually create the animation…


By the way, I greatly recommend Romain’s book Filthy Rich Clients that I have added to my Safari bookshelf and that I think I should finish to read, if you consider my attempt at animating Swing… :)

Sphere: Related Content

Evolutionary vs Extensive: Refactorbot explained

Wednesday, August 1st, 2007

Yesterday, I was discussing the Refactorbot with a friend of mine. Although he has been a developer for longer than me, he couldn’t grasp why the Refactorbot could not possibly test every solution and had to fall back to evolutionary design.

A bit of maths

If you want to test every possible solution for a given design, you have to test every possible number of packages to hold classes and every possible combination of those classes in the packages.

If you have done some probabilities, statistics or enumerative combinatorics, you certainly will see where I am going to with that…

I have never been very good myself at mathematics, but my guess is that the number of possible solutions to our design problem can be represented with the following formula.

This is the sum of all combinations, without repetition, of n classes in p packages for p ranging from 1 (all classes in 1 packages) to n (each class in its own package):

Equations for all solutions


Equation for all solutions, for a given number of packages and classes

(for example, for 30 classes and 5 packages, this gives us 17100720 possibilities for this case alone)

We then quickly understand that it would be impossible for a program to test each and every possible design for a sizeable system: the sheer number of possibilities would make it impossible to test in a lifetime!

Refactorbot v0.0.0.3

If you want to have fun staring at an empty console while your CPU is hitting 100%, I have created an implementation of such a refactoring method.

You can download the Refactorbot v0.0.0.3 which includes this method. Good luck!

The case for small systems

As much as my mathematical demonstration convinced me, myself and I, I had to tell you about my experiments on the design challenge (included in the test cases for the Refactorbot)…

It seems that for a small number of classes, say 8, the method is not only quick but very effective: I found the best ever solution to the design challenge!

ref model: 3 packages/8 classes (D=0.4444444444444445, R=0.8333333333333334)
-> p1 (3 classes): B A C
-> p2 (3 classes): D E F
-> p3 (2 classes): G H

new model: 3 packages/8 classes (D=0.08333333333333333, R=1.0)
-> p0 (4 classes): G C A B
-> p1 (3 classes): E H D
-> p2 (1 classes): F

However, don’t be fooled by this stunning result! It would become increasingly tedious to try and find a solution for bigger and bigger systems.

The deal with evolutionary refactorings

I don’t think that the purpose of the Refactorbot is to come up with the best design - and I will write a piece soon about a definition of the BEST design - possible, but rather with a better design.

If we consider that the design of a software is its DNA, then you can probably try small improvements and keep them or discard them in an evolutionary fashion. Better design would emerge by trial and error; the Refactorbot should do just that.

What is perfect design anyway?

Sphere: Related Content