Protect your GUI thread

He (Heinz) was right about it. We were in serious trouble not tohave restricted access to our gui components from other threads than the Swing thread.

Fortunately, our design is not so bad. Last year, I had the goodidea to use an EventBus to communicate between the business layer and the gui layer (or even between the gui components themselves). As a result the correction was quite easy and came in the form of a pattern:

• the component does not register himself but registers a proxythat implements the same "EventReceiver" interface. When receiving abusiness event, the proxy forwards the call but by invoking aSwingUtilities.invokeAndWait().

This really solved the freezing bug that we had only observed once on one of our consultants computer.

However, the developper I was working with was dissatisfied with the solution. He would have preferred a "implement an interface" or"extend an abstract class" kind of pattern that would force thecomponent to be executed on the Swing Thread.

It made me think of 2 things:

• why Swing does not throw an exception when a gui component is not executed on the Swing thread, since it is so dangerous?
• could we use our components factory to insert another proxy that would check that any method call made on a GUI component is checked against this error?

I am going to investigate dynamic proxies for that matter (I hope not to have to resort to AOP,...) and will blog more about it (Santosh's blog http://www.jroller.com/page/santhosh seems to be an interesting start).

Just another thought came on top of my mind: using dynamic proxy involves the use of interfaces. Why don't we have our gui component simplement business interfaces exposing only the events they receive/send? Once a JTree is constructed, what other components need to see it as a JTree? Being a JTree after all is more a matter of implementation about how I want to see some kind of info.

That's all for today. The London exhibition was great and the testing market in UK seems interesting for us. I also felt very comfortable around English people, I don't really know why; maybe some kind of ever politeness floating around? I also met a fine magician, which is another subject I am also passionate about,...

Training that counts

We had today a java training with Dr. Heinz Kabutz.

There would be many thing to say about this, but let's just summarize a few.First of all, Heinz is a really, really fine person that made mediscover more about South Africa that I ever knew of. On top of that, my first impression that I was asking for one of the top javaprofessionals around the world was really confirmed.

Then the training in itself went largelly beyond my hopes:

• Heinz spotted a potential problem in our GUI code that, in fact just had been observed, and had bewildered us. We now think we now why and how thiskind of bug happens.
• I told about Heinz about how I wanted to set-up a cache for some objectsof our business model. He came, in ten minutes (all developers were totally amazed around the table!) with a really elegant and generic solution ( He would now say "general" solution, since Java5 has messed up his previous vocabulary)
• We had very nice tips and explanations about garbage collecting, exception handling, etc, etc,...
• No training is ever enough without hard work afterwards to experience it practically; however much hard work will be avoided and re-thought with this top-class training.

At last concrete objectives!

Today, I had the opportunity to do it the way I thought it should be done,...

Dealing with software is something, dealing with people creating the software is another. At our company, we set up an incentive policy aimed at motivating our troops. Thus, the classical "objectives" assigned to each one. I feel (and also read) that incentives must be used with care and that setting up motivating objectives is not an easy task.

So, regarding the individual objectives (there is also a reward program for company achievement) I took the following hypotheses:

• never set objectives that would make people compare to each other. Objectives are personal, you are only fighting against yourself to achieve your goals.
• a developer wants (needs) to improve itself
• if it is good for the developer professional practise, it will be good for the product
• the team member should select objectives that he likes
• no more than 4 to 5 objectives should be selected
• they should be concrete enough for me to make the evaluation at the end of the year
• the evaluation will always be a "give good marks to a nice face"exercise so the team members will need to show their best profile toget good marks

All in all, we had 3 individual sessions today, and the result were very interesting:

• people had the freedom to select from the 20 or so objectives that I proposed (+2 objectives that I imposed, see below)
• so I could learn more about their real interest (for instance I alwaysthought, and feared, that the main interest of one of them was network management. It is not at all!)
• the selected objectives will clearly benefit the developer
• the selected objectives will clearly benefit the product
• the 2 objectives I imposed were well accepted (better planning abilities and self-teaching through reading)
• I am confident that at the end of the year, we will be able to assess the achievement as objectively as possible
• because there are few objectives, it is possible to make huge progress in those
• my objective to give them 100% bonus because they performed ok will be achieved!

As a result, I also started creating a "good points" document where Iwill register every single achievement along the way. And I evenstarted collecting for one of them that had not been through an"objective setting" session yet.

And I feel good when I can give "good points"!

eXtremeProgramming applied

I had the occasion last friday to practise an eXtremeProgramming session, and found it really interesting.

We knew what the problem was.
We did a simple analysis by slicing the problem into 5 tasks aimed at the main classes we had to evolve
We started by coding the tests, thereby finding very interesting test cases
We implemented the code, doing pair programming, forced by the situation because we only had one computer !
We refactored the code were we could see some commonalities

The result was that we ended with very few compile errors (thanks to pair programming)
We had very few tests errors, the bar was almost always green.
One time we launched the whole application. It had an exception showing us that a limit test case was missing (initialization)

All in all, we coded in less than one day most of a feature that would have taken at least 2 days otherwise (that was the foreseeing).

I think this was easier because there was no significant architectural issue in the way.

The morale is : dont be trendy, over-enthusiast or negative but just give it a try !

MDA approach and Software complexity

"There is no software bullet"

This famous article from F.Brooks (1986) is always relevant today. We may think that there will be silver bullets in a near future but if they existed today, developing first-class information systems would be so easy !

Saving of my blogs on freeroller,...

Thursday July 03, 2003

Finishing the metrics component, considerations on checked exceptions

My objective today is to finish this component once and for all. Then I will document the use and deployment next week.


--------------------------------------------------------------------------------

I am still wondering about the checked exceptions debate. I feel I can hear arguments from both sides:

-pro-runtime exceptions : avoid catching exceptions without doing anything valuable
-pro-checked exceptions : formally declaring what could go wrong when using an interface.

I may incline for the runtime camp, but I think the exceptions that can be recovered from by interacting differently with the interface should be at least documented (and then may be checked exceptions).
In UML2.0, there is a notion of Protocol. It is not enough to declare as contract what are the operations/ parameters/ pre-postconditions that the interface has, sometimes, the order on operations calling and parameters values are also very important. A protocol state machine can then be linked to an interface (or any classifier) in order to declare more precisely what can be its behaviour.

The conclusion of this is that: if an exception thrown by the interface contains enough information for the caller to resume the protocol execution, then it could be a checked exception.Eventually, in my case, practise is what I need,... code with both runtime and checked exceptions and the rules will follow. ($entry.pubTime) # [Edit]

Tuesday May 20, 2003

Context switching


--------------------------------------------------------------------------------
I would like to note some of my ideas regarding "Context Switching".
What is it ? It is a common fact observed by any consultant or programmer : it is quite hard to work on something, being interrupted, then to resume on the work to do.
The questions that arise are :

How is it possible to resume faster ?
Is it possible not to be interrupted ?
On the other hand is it possible to completly switch context, so that private life is not parasitized by work ? And many more question that I dont have time to write right-on !
(2003-05-20 16:30:00.0) # [Edit]

Friday May 16, 2003
Streamlined Object Modeling



--------------------------------------------------------------------------------


Here is a message I wrote on the french XP mailing list about this great book :



--------------------------------------------------------------------------------


Bonjour à tous,


Puisque l'on aborde le sujet des livres, je souhaiterais vous faire partager ma dernière lecture :


Streamlined Object Modeling: Patterns, Rules, and Implementation
de Jill Nicola, Michael Abney et Mark Mayfield
Cela sort au départ un peu de la programmation puisqu'il s'agit plutôt de patterns d'analyse objet (objets métiers, régles métier).

En revanche, lorsqu'il s'agit d'implémentation, le livre aborde une question qui me paraît très intéressante :


Quand une régle métier porte sur 2 objets (la possibilité de les associer par exemple) qui porte la régle?

C'est à ma connaissance, le seul livre qui donne des régles explicites sur le sujet. Globalement, la réponse est connue de tout développeur objet (consciemment ou inconsciemment):

celui des deux qui possède le plus d'informations pour vérifier la régle.

La vraie force du livre est de poser la question pour chacun des 12 patterns de base qui sont présentés.
J'ai trouvé, à la lecture de ce livre (en particulier les premiers chapitres), que ce qu'est "penser objet" était assez bien expliqué et ça fait donc partie des choses que j'aurais sans doute aimé lire un peu plus tôt (en aurais-je compris tout l'intérêt ? -cf les Design Patterns).
D'autre part la connaissance des 12 patterns est un excellent framework conceptuel pour analyser les objets et régles métier à implémenter.

A bientôt pour des réflexions plus XP, quand j'en utiliserai autre chose que les tests unitaires,...




--------------------------------------------------------------------------------

Creation of my own blog today. I just gave in to the fashion,... but this may prove useful!