Un réflexe courant de développeur, lorsque l'on est confronté à une IHM, est d'offrir le plus de fonctionnalités possibles. On se retrouve vite avec des applications usine à gaz, extrèmement "fouillies".
En partant d'une bonne intention: offrir le plus de fonctionnalités possibles, on arrive à l'effet inverse: avoir tellement de fonctionnalités que l'on n'en utilise plus qu'un sous ensemble très minime; c'est un peu ce que l'on retrouve sur les anciennes versions de word (la toute dernière version, 2007, apporte de grandes avancées en terme d'ergonomie).
Pourtant, il est souvent possible d'offrir toutes ces fonctionnalités avec une interface beaucoup plus minimaliste, notamment en les regroupant intelligemment.
Voici un article intéressant avec un exemple concret de simplification d'interface:
http://www.joelonsoftware.com/items/2006/11/21.html
Source: http://application-servers.com/
11 décembre 2006
27 octobre 2006
Expérience utilisateur
J'ai toujours insisté sur l'importance de l'IHM (GUI), car un des éléments clé de l'acceptation d'une application est l'expérience utilisateur.
Voici une image qui donne à réfléchir, tirée d'un excellent blog:
Creating passionate users
Source: http://application-servers.com/
Mot clé "final" sur les méthodes: gain de performances?
En inspectant le code de mes développeurs, je remarque par-ci, par-là des méthodes "taggées" avec le mot clé "final". Et c'est une très mauvaise pratique!
La fonction principale de ce mot clé est d'empêcher la surcharge de cette méthode dans les classes filles. Etant donné que Java est un langage objet, et que l'on ne connaît pas les développements futurs, ce n'est pas une bonne idée d'utiliser final, cela réduit les possibilités d'extension de notre appli (sauf si c'est réellement voulu, mais c'est relativement rare).
Pendant un temps, lorsque l'on était à la version Java 1.2 à peu près, il a été dit que cela améliorer "magiquement" les performances (c'est-à-dire de meilleures perfs sans aucun désavantage).
Voilà pourquoi: ce mot clé sert à dire au compilateur qu'il peut éventuellement passer la méthode en mode "inline", c'est-à-dire que pendant la compilation, le compilateur peut, s'il le souhaite, insérer le corps complet de la méthode dans le flot d'instructions bytecode au lieu de l'appel standard de méthode (mise des arguments sur la pile, saut du pointeur courant vers le bytecode de la méthode, exécution, retour au flot courant et nettoyage de la pile).
Cependant il faut savoir que maintenant, le compilo et la JVM Hotspot sont extrèmement optimisés (statiquement et dynamiquement); si bien que:
- le compilateur sait très bien quand faire passer des méthodes en inline (généralement, ce sont des méthodes simples, de moins de 4 instructions); donc il y a de grandes chances (c'est même sûr) qu'il ignore "final" pour les méthodes de plus de 3 ou 4 instructions
- le compilateur peut de lui-même et intelligemment décider d'inliner (ou "incorporer) certaines méthodes, même si vous n'avez pas utilisé "final"
- Enfin, les optimisations dynamiques vont compiler en langage machine bas niveau (assembleur) les méthodes les plus utilisées; si bien que le code en mode "inline", qui est intégré au flux et qui court-circuite l'appel standard de méthode ne sera jamais optimisé (je simplifie un peu...). Donc au lieu de gagner en performance grâce à cette optimisation, on ne fait rien --> cela a l'effet inverse souhaité: de moins bonnes performances (c'est relatif puisque comme je viens de l'écrire, dans les faits le compilateur ignore votre "final" pour l'inline; il ne le prend en compte que pour le verrouillage de la surcharge).
Bref, "final" a une utilité bien particulière dans la sémantique du langage (bloquer la surcharge), et la légende sur l'amélioration des performances est un mythe (depuis au moins Java 1.3).
Au passage, j'ai trouvé un article (en anglais), qui décrit mieux que moi les cas d'utilisation utiles du mot clé final sur les méthode:
http://www-128.ibm.com/developerworks/java/library/j-jtp1029.html
La fonction principale de ce mot clé est d'empêcher la surcharge de cette méthode dans les classes filles. Etant donné que Java est un langage objet, et que l'on ne connaît pas les développements futurs, ce n'est pas une bonne idée d'utiliser final, cela réduit les possibilités d'extension de notre appli (sauf si c'est réellement voulu, mais c'est relativement rare).
Pendant un temps, lorsque l'on était à la version Java 1.2 à peu près, il a été dit que cela améliorer "magiquement" les performances (c'est-à-dire de meilleures perfs sans aucun désavantage).
Voilà pourquoi: ce mot clé sert à dire au compilateur qu'il peut éventuellement passer la méthode en mode "inline", c'est-à-dire que pendant la compilation, le compilateur peut, s'il le souhaite, insérer le corps complet de la méthode dans le flot d'instructions bytecode au lieu de l'appel standard de méthode (mise des arguments sur la pile, saut du pointeur courant vers le bytecode de la méthode, exécution, retour au flot courant et nettoyage de la pile).
Cependant il faut savoir que maintenant, le compilo et la JVM Hotspot sont extrèmement optimisés (statiquement et dynamiquement); si bien que:
- le compilateur sait très bien quand faire passer des méthodes en inline (généralement, ce sont des méthodes simples, de moins de 4 instructions); donc il y a de grandes chances (c'est même sûr) qu'il ignore "final" pour les méthodes de plus de 3 ou 4 instructions
- le compilateur peut de lui-même et intelligemment décider d'inliner (ou "incorporer) certaines méthodes, même si vous n'avez pas utilisé "final"
- Enfin, les optimisations dynamiques vont compiler en langage machine bas niveau (assembleur) les méthodes les plus utilisées; si bien que le code en mode "inline", qui est intégré au flux et qui court-circuite l'appel standard de méthode ne sera jamais optimisé (je simplifie un peu...). Donc au lieu de gagner en performance grâce à cette optimisation, on ne fait rien --> cela a l'effet inverse souhaité: de moins bonnes performances (c'est relatif puisque comme je viens de l'écrire, dans les faits le compilateur ignore votre "final" pour l'inline; il ne le prend en compte que pour le verrouillage de la surcharge).
Bref, "final" a une utilité bien particulière dans la sémantique du langage (bloquer la surcharge), et la légende sur l'amélioration des performances est un mythe (depuis au moins Java 1.3).
Au passage, j'ai trouvé un article (en anglais), qui décrit mieux que moi les cas d'utilisation utiles du mot clé final sur les méthode:
http://www-128.ibm.com/developerworks/java/library/j-jtp1029.html
19 octobre 2006
Durée de vie des applications (l'arrivée de IE7)
Internet Explorer 7 (version finale) vient de sortir (en anglais, pour le moment).
Le point amusant est qu'une fois installé, il remplace complètement Internet Explorer 6 (on ne peut avoir les deux en même temps).
L'autre point à signaler, c'est qu'il sera de base dans Windows Vista, prochaine version de Windows qui va sortir dans 3 mois.
Pour mieux comprendre là où je veux en venir, il faut préciser que le moteur CSS et HTML a un peu évolué (c'est pas un mal), donc que le rendu des pages sera certainement différent entre la version 6 et la version 7 (http://ajaxian.com/archives/ie7-css-changes).
Alors que va-t-il advenir de toutes ces applications client léger (web) dont la partie présentation était spécifiquement développée pour IE6 ? La mise en page en sera peut être bouleversée (à 1 pixel près, cela peut jouer, notamment en mettant en décalant un gros bloc "div").
Il y a des chances pour qu'il y ait une grosse demande d'adaptation de site web à IE7, prochainement.... Et s'il faut revoir toutes les applications tous les 3-4 ans, un des intérêts fort des clients légers (partie présentation basée sur un navigateur web) par rapport aux clients lourds (SWING, SWT...) risque d'être bien remis en cause...
Le point amusant est qu'une fois installé, il remplace complètement Internet Explorer 6 (on ne peut avoir les deux en même temps).
L'autre point à signaler, c'est qu'il sera de base dans Windows Vista, prochaine version de Windows qui va sortir dans 3 mois.
Pour mieux comprendre là où je veux en venir, il faut préciser que le moteur CSS et HTML a un peu évolué (c'est pas un mal), donc que le rendu des pages sera certainement différent entre la version 6 et la version 7 (http://ajaxian.com/archives/ie7-css-changes).
Alors que va-t-il advenir de toutes ces applications client léger (web) dont la partie présentation était spécifiquement développée pour IE6 ? La mise en page en sera peut être bouleversée (à 1 pixel près, cela peut jouer, notamment en mettant en décalant un gros bloc "div").
Il y a des chances pour qu'il y ait une grosse demande d'adaptation de site web à IE7, prochainement.... Et s'il faut revoir toutes les applications tous les 3-4 ans, un des intérêts fort des clients légers (partie présentation basée sur un navigateur web) par rapport aux clients lourds (SWING, SWT...) risque d'être bien remis en cause...
18 octobre 2006
Mapping objet/relationnel et standards...
Hibernate 3.2 vient de sortir. Et alors?
Déjà c'est toujours bien de voir un bon produit Open Source qui évolue, premier point. Après, ce n'est tout de même pas si rare que ça.
La bonne chose, c'est que le domaine du mapping relationnel se standardise réellement, à travers JEE 5, et plus particulièrement JPA (Java Persistence API).
On peut argumenter que JDO était déjà un standard, mais dans les faits, plusieurs technologies s'affrontaient sur ce créneau. Le bon côté était que chaque techno (JDO et ses diverses implémentations, Hibernate, Toplink...) progressait plus vite. Le mauvais point, c'était lorsqu'il fallait que j'explique à mes courageux développeurs qu'ils allaient devoir apprendre toute une nouvelle API et ce qu'il y avait autour, et qu'en plus c'était souvent complexe et pas standard.
La standardisation, sur ce coup, tombe tout à fait à pic, car la techologie est vraiment mature (après plusieurs années). Pas d'expérimentation à la JSF (qui pour moi est toujours trop complexe à utiliser, du moins tout seul --> facelets simplifie bien les choses).
En bref, Hibernate 3.2 arrive, gère officiellement JPA et on peut enfin se baser sur un standard fiable et reconnu pour gérer nos bases de données relationnelles et Java.
(Après, est-ce que ça va me faire lâcher la simplicité de mon iBatis SQL-Maps, c'est pas sûr...)
Cyril Gambis
Déjà c'est toujours bien de voir un bon produit Open Source qui évolue, premier point. Après, ce n'est tout de même pas si rare que ça.
La bonne chose, c'est que le domaine du mapping relationnel se standardise réellement, à travers JEE 5, et plus particulièrement JPA (Java Persistence API).
On peut argumenter que JDO était déjà un standard, mais dans les faits, plusieurs technologies s'affrontaient sur ce créneau. Le bon côté était que chaque techno (JDO et ses diverses implémentations, Hibernate, Toplink...) progressait plus vite. Le mauvais point, c'était lorsqu'il fallait que j'explique à mes courageux développeurs qu'ils allaient devoir apprendre toute une nouvelle API et ce qu'il y avait autour, et qu'en plus c'était souvent complexe et pas standard.
La standardisation, sur ce coup, tombe tout à fait à pic, car la techologie est vraiment mature (après plusieurs années). Pas d'expérimentation à la JSF (qui pour moi est toujours trop complexe à utiliser, du moins tout seul --> facelets simplifie bien les choses).
En bref, Hibernate 3.2 arrive, gère officiellement JPA et on peut enfin se baser sur un standard fiable et reconnu pour gérer nos bases de données relationnelles et Java.
(Après, est-ce que ça va me faire lâcher la simplicité de mon iBatis SQL-Maps, c'est pas sûr...)
Cyril Gambis
12 octobre 2006
Design pattern et Resign pattern
Un excellent article, à prendre au second degré, sur un ensemble d'anti-pattern très couramment retrouvés dans les applications (en anglaise):
http://www.brajeshwar.com/archives/2005/08/resign-patterns-ailments-of-unsuitable-projectdisoriented-software/
Mes préférés:
Mise à jour: la page n'étant plus disponible, en voici une copie ci-dessous
http://www.brajeshwar.com/archives/2005/08/resign-patterns-ailments-of-unsuitable-projectdisoriented-software/
Mes préférés:
1.5 Simpleton
The Simpleton Pattern is an extremely complex pattern used for the most trivial of tasks. The Simpleton is an accurate indicator of the skill level of its creator.
2.3 Compromise
The Compromise Pattern is used to balance the forces of schedule vs. quality. The result is software of inferior quality that is still late.
et
3.2 Commando
The Commando Pattern is used to get in and out quick, and get the job done. This pattern can break any encapsulation to accomplish its mission. It takes no prisoners.
Ces mauvaises pratiques se retrouve malheureusement tellement souvent, en cas de forte pression sur les délais...
Mise à jour: la page n'étant plus disponible, en voici une copie ci-dessous
From http://www.agcs.com/patterns/papers/respat.htm
Resign Patterns
Ailments of Unsuitable Project-Disoriented Software
by
Michael Duell
mitework@yercompany.com
Abstract
Anyone familiar with the book of patterns by the Gang of Four [1]
knows that the patterns presented in the book represent elegant
solutions that have evolved over time. Unfortunately, extracting these
patterns from legacy code is impossible, because nobody knew that they
were supposed to be using these patterns when they wrote the legacy
code. Hence, this work is a catalog of patterns for the masses. The
patterns presented here represent abundant solutions that have endured
over time. Enjoy reading the patterns, but please don't use them!
1 Cremational Patterns
Below is a list of five cremational patterns.
1.1 Abject Poverty
The Abject Poverty Pattern is evident in software that is so difficult
to test and maintain that doing so results in massive budget overruns.
1.2 Blinder
The Blinder Pattern is an expedient solution to a problem without
regard for future changes in requirements. It is unclear as to whether
the Blinder is named for the blinders worn by the software designer
during the coding phase, or the desire to gouge his eyes out during
the maintenance phase.
1.3 Fallacy Method
The Fallacy method is evident in handling corner cases. The logic
looks correct, but if anyone actually bothers to test it, or if a
corner case occurs, the Fallacy of the logic will become known.
1.4 ProtoTry
The ProtoTry Pattern is a quick and dirty attempt to develop a working
model of software. The original intent is to rewrite the ProtoTry,
using lessons learned, but schedules never permit. The ProtoTry is
also known as legacy code.
1.5 Simpleton
The Simpleton Pattern is an extremely complex pattern used for the
most trivial of tasks. The Simpleton is an accurate indicator of the
skill level of its creator.
2 Destructural Patterns
Below is a list of seven destructural patterns.
2.1 Adopter
The Adopter Pattern provides a home for orphaned functions. The result
is a large family of functions that don't look anything alike, whose
only relation to one another is through the Adopter.
2.2 Brig
The Brig Pattern is a container class for bad software. Also known as
module.
2.3 Compromise
The Compromise Pattern is used to balance the forces of schedule vs.
quality. The result is software of inferior quality that is still
late.
2.4 Detonator
The Detonator is extremely common, but often undetected. A common
example is the calculations based on a 2 digit year field. This bomb
is out there, and waiting to explode!
2.5 Fromage
The Fromage Pattern is often full of holes. Fromage consists of cheesy
little software tricks that make portability impossible. The older
this pattern gets, the riper it smells.
2.6 Flypaper
The Flypaper Pattern is written by one designer and maintained by
another. The designer maintaining the Flypaper Pattern finds herself
stuck, and will likely perish before getting loose.
2.7 ePoxy
The ePoxy Pattern is evident in tightly coupled software modules. As
coupling between modules increases, there appears to be an epoxy bond
between them.
3 Misbehavioral Patterns
Below is a list of eleven misbehavioral patterns.
3.1 Chain of Possibilities
The Chain of Possibilities Pattern is evident in big, poorly
documented modules. Nobody is sure of the full extent of its
functionality, but the possibilities seem endless. Also known as
Non-Deterministic.
3.2 Commando
The Commando Pattern is used to get in and out quick, and get the job
done. This pattern can break any encapsulation to accomplish its
mission. It takes no prisoners.
3.3 Intersperser
The Intersperser Pattern scatters pieces of functionality throughout a
system, making a function impossible to test, modify, or understand.
3.4 Instigator
The Instigator Pattern is seemingly benign, but wreaks havoc on other
parts of the software system.
3.5 Momentum
The Momentum Pattern grows exponentially, increasing size, memory
requirements, complexity, and processing time.
3.6 Medicator
The Medicator Pattern is a real time hog that makes the rest of the
system appear to be medicated with strong sedatives.
3.7 Absolver
The Absolver Pattern is evident in problem ridden code developed by
former employees. So many historical problems have been traced to this
software that current employees can absolve their software of blame by
claiming that the absolver is responsible for any problem
reported. Also known as It's-not-in-my-code.
3.8 Stake
The Stake Pattern is evident in problem ridden software written by
designers who have since chosen the management ladder. Although
fraught with problems, the manager's stake in this software is too
high to allow anyone to rewrite it, as it represents the pinnacle of
the manager's technical achievement.
3.9 Eulogy
The Eulogy Pattern is eventually used on all projects employing the
other 22 Resign Patterns. Also known as Post Mortem.
3.10 Tempest Method
The Tempest Method is used in the last few days before software
delivery. The Tempest Method is characterized by lack of comments, and
introduction of several Detonator Patterns.
3.11 Visitor From Hell
The Visitor From Hell Pattern is coincident with the absence of run
time bounds checking on arrays. Inevitably, at least one control loop
per system will have a Visitor From Hell Pattern that will overwrite
critical data.
4 References
Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns -
Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
-----
Michael Duell is an Engineer at AG Communication Systems, where his
Resign Patterns have been rejected in favor of the Gang
of Four Design Patterns.
"Resign Patterns: Ailments of Unsuitable Project-Disoriented Software,"
The Software Practitioner, Vol. 7, No. 3, May-June 1997, p. 14.
27 septembre 2006
Résistance au changement...
S'il y a bien un sujet que je trouve passionnant, c'est la relation qui s'établie entre un utilisateur et un logiciel.
Un exemple de relation de rejet est fréquemment abordée sous le nom "résistance au changement". Quel déception lorsque l'on a terminé en temps et en heure une refonte ou une nouvelle version d'une application et que les utilisateurs continuent à travailler avec l'ancienne version...
Voici un bon article (en anglais) qui donne de bons indices sur les moyens de vaincre cette résistance:
http://headrush.typepad.com/creating_passionate_users/2006/09/why_they_dont_u.html
Et sur ce blog, combattre avec les armes de ses adversaires: quelques autres techniques pour résister à la résistance aux changements
Urbanisation des Systèmes d'Information: La résistance à la résistance aux changements
Un exemple de relation de rejet est fréquemment abordée sous le nom "résistance au changement". Quel déception lorsque l'on a terminé en temps et en heure une refonte ou une nouvelle version d'une application et que les utilisateurs continuent à travailler avec l'ancienne version...
Voici un bon article (en anglais) qui donne de bons indices sur les moyens de vaincre cette résistance:
http://headrush.typepad.com/creating_passionate_users/2006/09/why_they_dont_u.html
Et sur ce blog, combattre avec les armes de ses adversaires: quelques autres techniques pour résister à la résistance aux changements
Urbanisation des Systèmes d'Information: La résistance à la résistance aux changements
25 septembre 2006
Framework de présentation Web JEE: où en est on?
Sujet très à la mode il y a deux ou trois ans (à l'époque, plusieurs nouveaux framework se lançaient par mois) , tout semble se clarifier peu à peu.
Au final, plusieurs projets Open Source intéressants, avec des approches un peu différentes.
Cela dit, j'ai toujours eu des doutes au niveau de la pertinence de Java pour gérer la couche présentation. Trop complexe, trop lourd, il serait peut être temps de passer à des technologies de script pour gérer cette partie (Ruby On Rails ou Groovy On Rails - GRAILS ?).
Au final, plusieurs projets Open Source intéressants, avec des approches un peu différentes.
- Le framework Ajax de Google s'appuie sur le codage de la couche présentation en Java. Bien fini et élégant, il a fait ses preuves: gmail, picasaweb, my google... (même s'il comporte quelques limitations). Yahoo, msn et Adobe ont également publié leur framework de manière similaire.
- Le successeur du framework Java EE le plus utilisé, Struts, se fond dans Webworks, qui est un très beau projet. Même si la notoriété de Struts devrait jouer, et malgré l'élégance de Webworks, je ne suis pas sûr que cette future version de Struts (Struts "Action" ?) puisse faire le poids...
- JBoss Seam a pour lui des fonctionnalités intéressantes et puissantes, notamment le support de JSF (le framework officiel de présentation de Java)
- Enfin, un wrappeur de JSF reprenant les idées de l'excellent Tapestry remporte la palme en matière de légèreté: Facelets.
Cela dit, j'ai toujours eu des doutes au niveau de la pertinence de Java pour gérer la couche présentation. Trop complexe, trop lourd, il serait peut être temps de passer à des technologies de script pour gérer cette partie (Ruby On Rails ou Groovy On Rails - GRAILS ?).
01 septembre 2006
Mettre en place une interface utilisateur pour une application Web
On demande généralement systématique aux programmeurs de mettre en place l'interface utilisateur (IHM) des applications sur lesquelles il travaille.
Le problème, c'est que souvent le programmeur n'a pas de compétence ni de connaissance sur le sujet, et que l'on se retrouve avec des interfaces bancales, peu ergonomiques, complexes et souvent compréhensibles surtout par un développeur, rarement par un utilisateur final.
Voici un article (en anglais) simple et clair qui présente quelques conseils pour mettre en place de manière efficace l'ergonomie d'une application:
6 Tips for Sane User Interfaces (http://mikeomatic.net/?p=65)
Le problème, c'est que souvent le programmeur n'a pas de compétence ni de connaissance sur le sujet, et que l'on se retrouve avec des interfaces bancales, peu ergonomiques, complexes et souvent compréhensibles surtout par un développeur, rarement par un utilisateur final.
Voici un article (en anglais) simple et clair qui présente quelques conseils pour mettre en place de manière efficace l'ergonomie d'une application:
6 Tips for Sane User Interfaces (http://mikeomatic.net/?p=65)
28 août 2006
Les annotations de Java 5
Un article très clair (en anglais mais simple) et intéressant sur les annotations:
Annotation Hammer (http://www.infoq.com/articles/Annotation-Hammer)
Il présente l'intérêt de cette nouvelle fonctionnalité de Java, explique la définition et l'utilisation des annotations et expose les pièges et les meilleures utilisations.
Annotation Hammer (http://www.infoq.com/articles/Annotation-Hammer)
Il présente l'intérêt de cette nouvelle fonctionnalité de Java, explique la définition et l'utilisation des annotations et expose les pièges et les meilleures utilisations.
31 juillet 2006
Microcosme Java JEE de Cyril Gambis
Des informations utiles pour les développeurs, architectes et chefs de projet Java / JEE
Inscription à :
Articles (Atom)