Microcosme Java JEE

Pile technologique pour projet Flex

2009-01-26T09:30:00.003+01:00

Une fois Flex choisis comme technologie de présentation, il reste à monter sa pile technologique pour son projet: accès aux bases de données, découpage en "couches", architecture globale de communication entre ces couches...

Voici un retour d'expérience, pour vous aider à choisir:

accès aux données: plusieurs choix possibles. Si vous avez les connaissances et que vous voulez coller le plus possible aux standards, partez sur du JPA (Java Persistence API). Contrairement aux EJB 2.x Entity et à JDO, la spécification semble bien partie pour s'imposer. Après, il vous reste une multitude d'implémentations; Hibernate ou Oracle TopLink (Essentials) sont des bons choix. Du côté de mon équipe, qui n'a pas beaucoup de compétence mapping objet-base relationnelle, on est sur du iBatis, solution très légère et très propre, très simple à mettre en place.

EJB ou pas EJB? Tout dépend de la taille de votre projet. Pour des projets petits ou moyens, plutôt simples dans les process et ne demandant pas une fiabilité extrême, pas besoin d'EJB, un Tomcat suffira amplement. Après, si vous vous orientez vers EJB 3, cela reste un choix très valable. Dans ce cas, il vous faudra un serveur implémentant la spécification complète. GlassFish est un des plus populaire actuellement. JBoss et Apache Geronimo sont également très bons, et du côté des commerciaux, Oracle WebLogic reste très bien, même si en perte de vitesse par rapport aux Open Source.

architecture interne de l'application: orientée Services (au sens architecture, pas au sens marketing...), à base de Spring (beans), ou de Guice (projet Google) assez à la mode en ce moment. Si vous êtes sur de l'EJB 3, vous avez déjà tout ce qu'il vous faut (à travers les annotations notamment).

communication serveur - client Flex: assurément BlazeDS se révèle être une excellente surprise. Utilisez le mode AMF si vous le pouvez (ce qui est certainement possible), pour échanger en mode binaire et optimisé entre le serveur et le client. Il est très simple de brancher BlazeDS sur Spring (je suppose que cela se fait également facilement avec de l'EJB 3)

Au final, pour notre petit projet (200 jours/h), on est arrivé à d'excellents résultats avec:
- Frontal Apache HTTP
- Apache Tomcat

- BlazeDS
- Spring
- iBatis

Très léger à mettre en place, et les développeurs ont facilement appris toutes ces technos.

Java EE: Evolutions depuis 1 an et demi

2008-12-30T09:47:00.003+01:00

Après une période à bosser sur mes projets, je reprends le clavier.

Une petite question toute innocente sur theserverside.com m'a replongé dans l'époque des grandes questions sur quelle techno de présentation Java EE utiliser (lien vers mon commentaire).

La situation générale s'est un peu éclaircie, bien que je pense toujours que l'univers Web est en période de transition:

HTML vieillissant (avec une version 5 qui n'en finit pas d'être repoussée, et dont le contenu ne cesse de bouger)
de plus en plus d'intérêt pour des pages plus riches et dynamiques; pour des sites professionnels, forte pression des clients pour en intégrer
côté AJAX, quelques grandes bibliothèques javascript(jQuery, Dojo, Prototype, Scriptaculous et consors)
de l'autre côté (plugin Adobe Flex et Microsoft Silverlight), une évangélisation à marche forcée, sauf pour JavaFX qui est complètement largué, et dont on peut être sûr que la récente version 1 sortie récemment n'aura rien à voir avec la prochaine version vu le peu de moyens qu'y a consacré Sun (d'ailleurs, ça rappelle ce qu'il s'est passé avec Flex 1 & 1.5 et Silverlight 1, très différents des versions actuelles, notamment au niveau conceptuel)
des frameworks Java EE qui intègrent de facto ou à l'aide de wrapper/adapter l'AJAX et les technos javascript, et un écrémage au fur et à mesure de ces frameworks
une tendance des navigateurs à décupler les performances des interpréteurs javascript

Au final, pour lancer un projet JEE, on a le choix pour la couche de présentation entre:

Google GWT, qui évolue vite, qui s'appuie sur du HTML/Javascript donc pas besoin de plugin, mais dont la programmation s'éloigne pas mal des classiques JSP (ce qui est de toutes façons normal pour une techno de présentation Web riche, et c'est plutôt une bonne chose, d'ailleurs - gérer des formulaires HTTP et des urls va vite devenir la préhistoire des applis Web). Mais:
- très lié à Google; même si le framework est Open Source, si Google arrête tout, qui va se plonger dans le code Google pour gérer la compilation de l'interface (écrite en Java dans le cas de GWT) vers chaque navigateur (voir chaque version de navigateur) ?
- repose tout de même sur AJAX; or, AJAX est un hack du mode de fonctionnement classique request/response du HTTP, ce qui impose de multiples contraintes, et les échanges se font en mode texte, ce qui n'est pas très optimatal pour les échanges client/serveur. Cependant, étant donné que l'interface est écrite en Java, rien n'empêche Google de développé un compilateur de Java vers Flash/Silverlight/JavaFX, un peu à la mode d'OpenLaszlo (mais en plus performant...)
Au final, GWT vaut vraiment le coup, même si le coût (d'apprentissage) n'est pas négligeable (mais je vous rassure, ça reste abordable et c'est très élégant).

Apache Wicket, basé sur une logique de composants, framework séduisant et très soutenu par une communauté très active. J'ai pas grand chose à en dire, ce n'est pas un choix que je retiens personnellement parce qu'il se base trop sur du HTML pour la partie interface, et que pour moi ce n'est pas vraiment un choix d'avenir, mais les avantages sont aussi la simplicité et la courbe d'apprentissage moins abrupte que GWT (et Flex/Silverlight).

JSF (avec Facelet et la couche intermédiaire JBoss Seam); là, je n'y crois plus trop. Trop compliqué, revu mais trop tard avec la version 2 qui sort cet hiver (ou pas...).

Adobe Flex; le choix que j'ai fait pour mes nouveaux projets. Courbe d'apprentissage assez abrupte, nécessité d'avoir un plugin, même problème que GWT pour ce qui est du projet Open Source avec la dépendance à un éditeur (Adobe en l'occurence).
Au bout d'un an, un développeur est capable de faire des choses vraiment biens, même si la logique de positionnement et redimensionnement des composants est ardue à comprendre lorsque l'on est habitué à faire des clients HTML (ça se rapproche des interfaces clients lourds comme le Swing, même si c'est tout de même beaucoup plus simple et élégant au niveau de la gestion des évènements).
Et une fois que l'on maitrise un peu la techno, c'est que du bonheur (y compris pour le chef de projet, avec une productivité bien accrue par rapport aux frameworks MVC basé sur du HTML - Struts 1 & 2, Spring MVC...)

Microsoft Silverlight; techno encore trop jeune, mais Microsoft met vraiment les moyens en ce moment. Sans doute promis à un bel avenir.

Pour passer rapidement sur les autres choix, certaines technos de bonne qualité ne vont, à mon avis pas tenir trop longtemps, par manque de visibilité ou par concept un peu dépassé:

Tapestry, qui change du tout au tout entre les versions, et qui se dilue parmi les autres technos ci-dessus
Struts 2, qui reste un choix lorsque l'on ne veut pas faire "le grand saut" vers une appli Web riche, mais qui est tout de même bien complexe et contraignant
Echo, pas trop de visibilité, en perte de vitesse par rapport à GWT et Flex
OpenLaszlo, pas assez de moyens par rapport à Flex (ils peuvent pas faire grand chose, malgré leur talent, face à une boite énorme comme Adobe, qui mise à fond sur Flex pour son futur)
Spring MVC, Webworks... même problème que Struts 2: un peu dépassés

Au final, le paysage se clarifie un peu, mais reste assez flou. Je suis persuadé que le Web va évoluer vers une ou plusieurs technos riches et se détourner du HTML pour la plupart des sites professionnels. Google finira par faire son Flex/Silverlight, quitte à ce que ce soit du "Full Javascript" dans son navigateur Chrome, ou un plugin (native client, ou autre - par exemple un plugin similaire à celui développé il y a peu pour ajouter des conversations vidéos à Google Talk dans GMail).
Ce même HTML, du fait de sa simplicité, va certainement continuer à vivre pour les sites peu intéractifs.

Et en toutes franchise, je doute que ces technos riches qui vont changer le Web soit l'une de celles cités plus haut... on est encore en période de transition pendant quelques années.

Du mouvement dans le monde des RIA

2007-05-07T12:18:00.000+02:00

Au cours de la conférence MIX07, microsoft a présenté de multiples démonstration de sa technologie Silverlight (v1.1 alpha - amusant sachant que la version 1.0 est toujours en bêta). Les démos semblent vraiment impressionnantes, la grosse machine qui s'était mise en route il y a quelques temps semble enfin offrir du concret (http://www.fredcavazza.net/index.php?2007/04/30/1507-mix07-las-vegas-jour-1-suite) .

En plus, l'architecture et les concepts ont l'air au point; les RIA (Rich Internet Application) vont-elles enfin percer au delà de l'AJAX mis en place plus ou moins maladroitement et simplement un peu partout ?

Parallèlement, Sun et le monde Java réagissent enfin sur ce créneau qui est à mon avis clé avec JavaFX. On en est par contre ici véritablement aux balbutiements.
Est-ce que la plate-forme Java est maintenant condamnée à être suiveur des technos microsoft? heureusement que la communauté autour de Java est active (Open Laszlo, Adobe Flex, et la multitude de framework Ajax), mais ces initiatives n'ont pas la puissance marketing et l'assise financière d'un projet stratégique de microsoft.
Avec JavaFX, on peut avoir le pire ou le meilleur. La technologie sera apparemment Open Source, donc j'espère bien qu'on finira par quelque chose de plus simple, rapide et utilisable que Swing.

Au final, tout se dirige, selon moi, dans la bonne direction: un langage simple, dédié à l'interface, concis et clair (que ce soit le XAML de microsoft, le MXML + ActionScript de Flex, ou le langage FX-Script de JavaFX qui semble très élégant).

Vers une généralisation des applications distribuées?

2007-04-13T08:28:00.000+02:00

Depuis plusieurs années, les technologies distribuées ont tenté de s'imposer. Si cela marche très bien dans le cas d'applications spécifiquement adaptées (les ERP par exemple), ce type d'architecture n'a jamais été vraiment pertinent dans le cadre d'applications plus traditionnelles (la grosse majorité des applications). J'ai l'impression que ça change.

Globalement, j'ai vu passer 3 étapes:

Etape 1: une première grosse tentative plus ou moins viable
Les concepts intéressants de CORBA (trop complexe pour une application lambda) ont amené un intérêt (surtout de la curiosité) dans le monde de l'entreprise pour ce type d'applications. Cette curiosité a été renforcée par les EJB 1 et 2, un véritable engouement s'est créé.
Malheureusement, CORBA est trop complexe et complètement inadapté pour une application lambda (ça n'a jamais été son but), de même que l'étaient les EJB 1 et 2, inadaptés dans 95% des cas (design Sun de référence pour les applications Web, mais les limites de l'architecture sont trop contraignantes et la complexité est abusive).

Etape 2: de la curiosité à la solution élégante
Faisant suite au rejet des EJB par la communauté des développeurs nouvelles technos, les conteneurs plus léger d'inversion de contrôle (ou injection de dépendance), ont apporté une architecture claire et saine sur ces concepts déjà intéressants.
De manière similaire, la remise en cause de CORBA mène à l'apparition des Web Services, plus légers, basés là encore sur une technologie qui suscite beaucoup de curiosité de la part des décideurs: le XML (dont on parle à tort et à travers, et qui devient la solution miracle à tous les problèmes d'interconnexion - du moins dans la tête des directions informatiques...).
Les technologies de bus de messages se répandent et maturent.

On commence à parler de SOA, architecture orientée services, qui remet en cause le principe d'encapsulation des langages orientés objets ("les attributs des objets et les méthodes sur ces attributs sont dans la classe" devient "l'objet contient uniquement les données - POJO ou Javabean, les traitements sont déportés dans des classes de service"). Cette architecture entraine pour toute application, distributée ou non, de grands bénéfices en terme de maintenabilité et d'évolutivité).

Etape 3: Généralisation

Tout s'intègre très bien: SOA se généralise et bénéficie très bien des concepts de conteneurs légers, se prête très bien à la mise en place de Web Service et cerise sur le gateau, permet une évolution très transparente vers un style distribué: à partir du moment où les services sont clairement et proprement définis, on peut selon les besoins en distribuer certains très facilement.

Les concepts de grilles de calcul et de caches répartis sont connus et les décideurs informatiques s'y intéressent et investissent dessus, le plus souvent avec grand succès. Des startups qui ont développé ces produits enregistrent des succès flamboyants (Datasynape pour les grilles de calcul, Gigaspaces et Tangosol Coherence - racheté par Oracle il y a peu - pour les caches distribués avec haute valeur ajoutée).

J'ai l'impression que ce type d'application est enfin suffisamment simple pour la mise en place, suffisamment bien vu pour l'investissement des décideurs dans ces solutions et suffisamment mature pour se généraliser.

Par contre, cette évolution entraine un autre style de programmation; l'ordonnancement et la synchronisation des process, parfois asynchrones, exigent pour les programmeurs d'être plus malins et de voir l'application de plus loin, les transformant progressivement en architectes logiciel.

Le futur des IHM

2007-02-07T16:00:00.000+01:00

Il y a quelques mois, dans un précédent billet, je parlais des diverses tendances au niveau de la couche présentation des applications web Java.

Effectivement, tout semble se clarifier dans ce monde très dynamique. En gros, il y a 3 mondes:

on améliore les concepts existants (JBoss Seam avec Facelets et JSF, Struts 2 basé sur Webwork)
on écrit le code de l'interface en Java et on compile vers de l'HTML/AJAX/Javascript (Google GWT)
on se base sur du Flash, généré à partir de code XML compilé (Flex, OpenLaszlo)

En fait, il me semble que les deux premiers mondes vont vite atteindre leurs limites. Même si l'AJAX apporte une relative fraicheur dans l'utilisabilité des applications, on reste vraiment bridé par le HTML/Javascript au niveau des possibilités et de la complexité.

Que l'on code directement avec du HTML ou à partir de code Java, on se retrouve avec au final une IHM construite à partir de technologies qui n'était pas initialement prévue pour faire de l'IHM (HTML a été créé pour lire des articles scientifiques, Java a été conçu pour faire des algorithmes, pas du layout ou de la configuration de composants).

Au final, il nous reste Flash, une technologie qui a été pensée dès le départ pour faire de l'IHM, qui le fait bien, de manière légère, cross-platform, avec un rendu identique sur toutes les plate-formes (Windows, Mac OS, Linux 32bits). Bref, pour moi, Flex est un bon aperçu de ce que seront les technologies d'IHM de demain.

La tendance est aux applications riches (RIA - Rich Interface Application), Adobe (Flash & Flex) et Microsoft (Windows Presentation Foundation / Express) l'ont très bien vu.

Je partage tout à fait l'analyse que fait Bruce Eckel sur son blog:
Hybridizing Java - http://www.artima.com/weblogs/viewpost.jsp?thread=193593

Simplicité et usabilité contre liberté

2006-12-11T11:42:00.000+01:00

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/

Expérience utilisateur

2006-10-27T11:47:00.000+02:00

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?

2006-10-27T10:08:00.000+02:00

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

Durée de vie des applications (l'arrivée de IE7)

2006-10-19T10:25:00.000+02:00

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...

Mapping objet/relationnel et standards...

2006-10-18T15:26:00.000+02:00

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

Design pattern et Resign pattern

2006-10-12T16:43:00.000+02:00

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:

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.

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...

Cyril

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.

Résistance au changement...

2006-09-27T11:10:00.000+02:00

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

Framework de présentation Web JEE: où en est on?

2006-09-25T16:00:00.000+02:00

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.

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.

Même s'il existe d'autres projets séduisants (Struts Shale, Wickets, Echo, Flex & Lazslo...), ces trois là (Google Web Toolkit, JBoss Seam + JSF, Facelets + JSF) sont mes préférés. Ils répondent à des besoins légèrement différents (ils se différencient notamment par leur légèreté) et représentent sans doute ce qui se fait de mieux au niveau de l'innovation et du respect des standards actuellement.

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 ?).

Mettre en place une interface utilisateur pour une application Web

2006-09-01T10:58:00.000+02:00

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)

Les annotations de Java 5

2006-08-28T12:44:00.000+02:00

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.

Microcosme Java JEE de Cyril Gambis

2006-07-31T11:15:00.000+02:00

Des informations utiles pour les développeurs, architectes et chefs de projet Java / JEE