vendredi 20 novembre 2009

Spam, la Peste électronique


Véritable déluge numérique, qu'ii touche nos boîtes aux lettres, nos forums/wikis/blogs favoris, nos messageries instantanées ou nos téléphones portables, le spam (et non je refuse d'utiliser les termes de pourriel ou pollupostage !!!) est un véritable fléau des temps modernes. Un fléau à l'échelle d'Internet, c'est à dire celle de la planète.

Le Messaging Anti-Abuse Working Group (MAAWG), sur la base de mesures régulières réalisées sur plus de 100 millions de boîtes aux lettres électroniques depuis plus de 3 ans, estime que le spam représente plus de 85% du nombre total d'emails reçus (cf. http://www.maawg.org/about/EMR/). C'est tout bonnement effrayant... Concentrons nous donc le spam de nos boîtes aux lettres.
Cette gangrène emailistique est difficile à combattre car elle ne se diffuse pas de manière centralisée mais plutôt de manière infectieuse, à l'intérieur de réseaux zombies ou botnets. Il s'agit de véritables réseaux cachés au sein d'Internet, regroupant l'ensemble des ordinateurs asservis au centre de contrôle du botnet. Ces ordinateurs asservis, ou bots1, le deviennent suite à une infection via des chevaux de Troie, des vers ou des backdoors. Un fois un ordinateur infecté, il rejoint le botnet et augmente ainsi sa puissance de nuisance, en tentant de contaminer les contacts déclarés sur le poste et en les ajoutant à la liste des cibles du spam. Lorsque le bot asservi en recevra l'ordre, il enverra le spam qui lui a été communiqué, à l'ensemble de ses contacts. Le centre de contrôle du botnet, parfois véritable plate-forme « Spam As a Service » commerciale et mafieuse, permet aux utilisateurs autorisés de composer et d'envoyer leurs déferlantes sur Internet en utilisant les ordinateurs disponibles dans le botnet.
Prenons quelques exemples pour bien appréhender l'ampleur du phénomène :
Lorsque l'hébergeur américain McColo a été forcé d'arrêter ses activités, le 11 novembre 2008, le spam mondial a été réduit de deux tiers. En effet, McColo hébergeait un des noeuds du centre de commande de Srizbi, considéré comme le plus gros botnet mondial avec 450 000 bots et une capacité de 60 milliards de spams par jour (oui... vous avez bien lu milliards) !! Depuis, le contrôle du botnet aurait été transféré en Europe.
Conficker, un ver exploitant (une faille de) Windows - dont l'éditeur est prêt à donner 250 000 dollars à quiconque aiderait à l'arrêt des malveillants - est relié à un botnet dont la taille est estimée à 9 millions d'ordinateurs et la capacité à 10 milliards de spams par jour.
En 2005, trois jeunes hollandais ont été arrêtés pour avoir créé et utilisé à des fins malveillantes un botnet (CodBot ou ToxBot) de plus d'un million et demi de machines.
Bref le spam de boîtes aux lettres est un phénomène réel et de grande ampleur. Mais pourquoi tant de haine ?! Pourquoi en 2009 le spam est-il toujours en croissance ? A mon avis c'est à la fois un phénomène sociologique et économique.
Sociologique d'abord, car il joue sur les : crédulité, luxure (les sites Web pornographiques sont de vrais pièges à bots) et cupidité. Rien de bien nouveau sous le soleil me direz vous, mais là, l'échelle est plus grande et les barrières techniques beaucoup moins hautes. De quoi attirer les personnes peu scrupuleuses voire malveillantes.
Mais également au niveau économique : avec une force de frappe qui se compte en milliards d'emails et un relativement faible coût d'investissement, il suffit qu'une très infime portion des destinataires commandent effectivement le viagra qu'ils ne recevront jamais ou envoient un acompte pour débloquer un compte fictif à l'étranger, pour que toute l'opération devienne rentable. De quoi attirer toutes les mafias du monde en quête d'argent facile, qu'il provienne de l'utilisation de botnets ou de la location de services offerts par les botnets. Et c'est vrai que c'est quand même bien pratique pour suivre l'évolution du cours du vi@gra ou des plugins d'extension de l'anatomie masculine!!
Mais alors que faire devant un tel fléau ?

Se résigner ?
Une première solution est de ne plus utiliser sa messagerie. Bon d'accord, c'est radical ! Mais est-ce qu'ignorer le problème dans sa globalité, en continuant de nettoyer à la mano chaque jour sa boîte aux lettres (ou déléguer ce nettoyage à l'hébergeur), ce n'est pas quand même adopter la politique de l'autruche ? Un fois le réseau complètement saturé, pollué et inutilisable, on ne pourra peut être plus utiliser sa messagerie...

Réagir techniquement ?
Il existe différentes solutions techniques développées pour lutter contre le spam a posteriori. Que ce soient des solutions d'antispam coté client ou coté serveur de messagerie, des solutions de blacklisting, greylisting, whitelisting (à quand le rainbowlisting ?) ou encore des solutions à base de DNS spécialisés, elles s'attachent toutes à détecter et traiter le spam en aval plutôt qu'à l'éradiquer en amont. C'est un peu comme un traitement individuel en cas d'épidémie...

Réagir légalement ?
Certains pays (comme ceux de l'Union Européenne, le Canada, l'Australie ou encore les États-Unis) ont déclaré comme illégale la pratique du spam. Cela a permis de démanteler certains botnets, en s'attaquant aux centres de contrôles des réseaux zombies. Mais souvent il s'agit d'une solution temporaire car les centres de contrôles sont souvent constitués de plusieurs noeuds se sécurisant les uns les autres, et disposent de certains de ces noeuds situés hors des zones d'application des lois antispam comme en Estonie ou en Russie.
Donc, en attendant un consensus mondial via des règles de gestion nationales (euh... pardon, des lois nationales, déformation professionnelle !) homogènes, voire en attendant une résolution de l'ONU (!!), nous voilà bien démunis par rapport au chaos rampant...

Devant tant d'impuissance, pourquoi finalement ne pas voir le bon coté des chose et se réjouir ?
Mais oui ! Au final cette maladie électronique a clairement été inventée par des informaticiens bien trapus, et pas par les utilisateurs finaux des offres de « Spam As a Service ». Cela prouve au moins qu'il est techniquement possible de déployer des systèmes hautement distribués sur Internet. Et cela fait plaisir à l'architecte logiciel qui sommeille en nous : c'est nuisible, c'est pas cool mais c'est beau ! De même, à l'heure du buzz sur le Cloud Computing, quelle meilleure preuve de concept que l'Elastic Spam (on détecte de plus en plus de spams en provenance de plates-formes de cloud computing).
Pour y voir plus clair, peut-être faut-il se demander à qui profite le crime ?... Car je ne pense pas que les bénéfices engrangés par les méchants spammers soient comparables à ceux qui sont indirectement versés à l'industrie informatique, qu'il s'agisse des fournisseurs de matériel, de logiciels (antispams, antivirus et anti-spyware) ou de services (accès Internet2, service antispam payant de l'hébergeur) !! A mon avis il ne s'agit pas du tout des mêmes ordres de grandeur...
Donc finalement, si toi lecteur tu es comme moi, payé par l'industrie informatique... ben, quelque part tu es aussi en partie payé par le spam !!
Alors si la sensation de cautionner une épidémie mondiale de Peste électronique polluant Internet te dérange un peu, ben en tant qu'informaticien, commence par faire du développement durable et sécurisé. Utilise des logiciels non infestés de chevaux de Troie, vers et autres backdoors, comme GNU/Linux et plus généralement les logiciels libres. Explique à ta famille et à tes amis pourquoi ils devraient faire de même (et donc se mettre à lire « l'excellent » GNU/Linux Magazine France). Et peut-être qu'on pourra, par effet tâche d'huile, réduire la taille des botnets et ainsi les rendre moins efficaces et donc moins intéressants à exploiter.
Restons exigeant sur la qualité des logiciels que la société de consommation nous propose, nous avons le choix. Des produits de mauvaise qualité peuvent nous rendre malades et ces maladies devenir contagieuses et poser un problème de santé publique !
Parce qu'y'en a marre de la médiocrité, des logiciels avariés, des développeurs en batteries et de la disparition des petits artisans soucieux du travail sain et bien fait.

Jean-Pierre Troll
jp.troll@gmail.com (vous l'aurez compris désormais, m'envoyer un e-mail s'est s'enregistrer sur TrollNet).

samedi 1 août 2009

Langages simples

Y en a mare de ces langages qui évoluent tous le temps. Où s'est perdu le bon sens et la raison ?

Au début, il y avait le C, avec ses pointeurs, ses types primitifs, ses structures et son pré-processeur. Puis est arrivé les pointeurs sur les fonctions et les unions. Bien plus tard, le C++ avec l'héritage unique, suivit de l'héritage multiple, l'héritage virtuel, les pointeurs de méthodes, la surchage des opérateurs, les références, les constantes, les exceptions, le Run-Time Type Information et enfin les templates et les casts sémantiques.

C'est trop compliqué ! Inventons un langage simple : Java.

Ce dernier a été vendu comme cela. Plus simple que C++. Vous vous rendez-compte, Madame, il n'y a PAS d'héritage multiple, mais des interfaces ; PAS de surcharge des opérateurs, d'un coté les types primitifs, de l'autre les objets. Puis sont venu les inners classes, les classes locales à une méthode et les variables finales, les classes anonymes, l'introspection. Plus tard, de nouvelles syntaxes pour les boucles, les types génériques, l'auto-boxing et les annotations. La suite annonce la programmation par aspect avec cinquante mots clefs nouveaux et les closures. Stop ! C'est trop compliqué.

Il faut repartir avec des langages plus simples. Python par exemple, langage objet simple avec des boucles riches. Puis est venu l'uni-code, les arguments optionnels explicites, les annotations pour les fonctions, les paramètres et les returns ; plusieurs types de divisions ; une plus grande rigueur dans les comparaisons ; les variables non locales, etc.

Et encore, et encore, et encore. Pourquoi est-il impossible de rester avec des idées simples ? Pourquoi faut-il toujours ajouter plus de syntaxe, de plus de paradigmes, de plus de subtilité ? Pour occuper les ingénieurs en charge du langage ? Virez les !

De plus, on multiplie les langages à maitriser : SQL, HSQL, XML, XSL, SOAP, Javascript, HTML, perl, shell, etc. Voir le mélange des genres, tel langage est traduit en tel autre. Allez déverminer le résultat...

Prenons simplement Java, langage simple par naissance. Le tableau suivant reprend quelques extraits de syntaxe. Comptez le nombre de ligne dont vous avez parfaitement compris le sens, et dont vous savez parfaitement utiliser les concepts sous-jacents. Enlevez un tiers, car c'est toujours plus compliqué que ce que vous ne croyez. Un article par ligne ne suffirait pas. Divisez le résultat par deux. Quel est votre note sur 20 ? Prétendez-vous maintenant que vous connaissez Java ?

Comment un débutant peut-il appréhender cette complexité ? Qui s'interroge encore des causes de dysfonctionnement, de bugs multiples généralement stupides ? La faute à qui ? Aux chercheurs qui nous offrent toujours plus ? Au chef de projet qui souhaitent des petites mains, à peine formées, devant produire immédiatement du code de qualité ?

Et encore, je n'évoque même pas les librairies standards plus riches et plus nombreuses chaque jour. Tellement riche que les concepteurs du langage ne les connaissent même pas. Allez jeter un œil dans les sources des librairies d'un langage. Vous trouverez inévitablement un code qui reprend à la main le code présent dans une autre partie. Inflation quand tu nous tiens.

« Il y existe deux manières de concevoir un logiciel. La première, c’est de le faire si simple qu’il est évident qu’il ne présente aucun problème. La seconde, c’est de le faire si compliqué qu’il ne présente aucun problème évident. La première méthode est de loin la plus complexe. » - C.A.R. Hoare

Parce qu'y'en a marre de la médiocrité, des développeurs en batteries et de la disparition des bons produits simples et naturels.

Jean-Pierre Troll

jp.troll@gmail.com




1 class Foo {...}
2 class Foo {…}
3 class Foo {…}
4 class Foo {…}
5 List
6 List
7 List
8 class Goo extends Foo {…}
9 class Goo extends Foo {…}
10 class Goo extends Foo {…}
11 static T goo(List ts) {…}
12 T goo(T t1, T t2) {…}
13 public void foo(int i, String... strings) {…}
14 foo(7,new String[] {"One String","Two Strings"});
15 foo(A.this);
16 a.super();
17 class A { static class B {} };
18 void goo()
{
class C extend A.B {}
}
19 void goo(final int a) {…}
20 new Thread(new Runnable(){...}) ;
21 public enum E { A,B,C,D }
22 import static java.util.Collections.*;
23 assert first != null : "bad first name";
24 Annotation Processing Tools
25 Doclet
26 throw x.fillInStackTrace()
27 @Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Documented
public @interface A { }
28 volatile double d;
29 final class A { }
30 static {…}
31 try {…} catch (…) {…} finally {…}
32 finally() {…}
33 int hashCode() {…}
34 boolean equals(Object x) {…}
35 class A
{
Object goo() {…}
}
class B extends A
{
Integer goo() {…}
}
36 void g(Integer x) {…}
void h() { g(3) ; }
37 class A
{
void f(Object x) {…}
void f(Integer x) {…}
void f(int x) {…}
void g() { f(3); }
}
38 @Override
@PostConstruct
@PreDestroy
void f() {…}
39 class A
{
static final int a;
static
{ a=3 ;
}
}
40 for (String a:cont) { … }

mercredi 1 juillet 2009

Le syndrome HTTP


Avez-vous été prévenu de la naissance d'un nouveau réseau ? Le fameux réseau « port 80 » et son copain, le réseau « port 443 » ? On réinvente les couches réseaux au-dessus d'HTTP qui n'est plus vu comme un protocole à rapprocher des couches hautes du modèle OSI mais comme un nouveau protocole de transport universel. Pourquoi diable en sommes nous arrivés là ? Et est-ce vraiment une si bonne idée ?

HTTP c'est bien parce que c'est pur porc 80 (euh pardon... port 80 !) ! Eh oui ça passe les pare-feux en standard donc il vaut mieux utiliser HTTP comme transport et s'encapsuler dedans... C'est la porte ouverte à toutes les fenêtres ! C'est sûrement pour cela qu'on a inventé les ports TCP et les pare-feux...

En gros, comme paramétrer un pare-feu c'est compliqué1, on préfère n'autoriser qu'un nombre réduits de ports. Mais on ne réduit pas pour autant le nombre de protocoles, puisque ces derniers vont se cacher dans HTTP. Alors bien sur y'a la solution logique de complexifier encore plus les pare-feux en les rendant plus intelligents et capables de reconnaître les protocoles caché dans HTTP plutôt que de se fier au numéro de port. Bref, pourquoi faire simple ?

Revenons aux sources du mal : la (pseudo) sécurité. En effet, si HTTP est devenu le « passage » par défaut, c'est parce qu'il permet très souvent de « passer les pare-feux ». Mais ces derniers ne sont ils pas justement là pour « bloquer » les communications illégitimes ? Et pourquoi diantre utiliser HTTP pour contourner ces pare-feux ? Simplement parce qu'une autre aberration sécuritaire énonce que plus on ferme de ports possible, plus on est en sécurité, bien à l'abri des méchants hacker. N'importe quoi !

Avec des outil à la portée de tous on peut aujourd'hui aisément construire des tunnels SSH au travers d'une connexion HTTP (le seul pré-requis - pas cher – est de disposer d'un serveur SSH qui écoute sur le port 443) et, hop, on sort du réseau. De plus en plus de personnes ont d'ailleurs recours à ce genre de mécanismes pour répondre à des besoins légitimes comme récupérer les sources d'un projet libre encore géré par CVS (ou même parfois Subversion) car une mauvaise configuration de proxy (intentionnelle ou pas) peut rendre impossible la récupération via HTTP de code source.

Bref, un technicien un minimum débrouillard contourne en moins de 5 minutes la politique de sécurité... Alors quid du hacker ? Il rît, et il passe...

Pendant ce temps, les utilisateurs standards ne cessent de souffrir car leurs clients de messagerie ne peuvent se connecter en POP ou IMAP, ou parce que la bande passante - surchargée par l'usage de HTTP pour tout et surtout n'importe quoi - n'est pas suffisante. Finalement, en lieu et en place d'une architecture réseau claire, où chaque flux circule dans son propre tuyau, permettant ainsi du faire du contrôle sur le contenu et la légitimité du trafic ; on obtient un réseau où tout, absolument tout, passe dans HTTP, y compris, caché discrètement dans ce foutoir où l'on ne peut rien contrôler, notre pirate, hilare.

Du coup comme HTTP est vu comme le protocole de transport mondial, on reconstruit toutes les couches réseau au-dessus d'un protocole qui n'a pas initialement été conçu pour cela. En effet, HTTP est un protocole déconnecté, sans état. Il a été fabriqué comme cela pour permettre aux serveurs et ne pas avoir à retenir des informations entre les différentes requêtes d'un même client et ainsi pouvoir traiter un grand nombre de clients.

HTTP a pris la grosse tête avec le succès du Web et se prend désormais pour IP ! Que se passe-t'il pour la grenouille qui veut se rendre aussi grosse que le bœuf ? Elle éclate. C'est joli, mais pas très efficace.

Et puis les différents types de caches positionnés dans les architectures pour optimiser les performances mettent le souk dans tout ça, qu'il s'agisse de proxy ou de reverse-proxy. Alors, pour calmer le jeu, on utilise l'instruction CONNECT de HTTP, celle servant normalement à faire passer les flux cryptés, pour ouvrir un socket vers la destination, en traversant tous les intermédiaires, proxy, pare-feux, etc.

Pourquoi ne pas aller jusqu'au bout de cette logique et de créer des VPN sur HTTP ? Ben oui ! OpenVPN par exemple le permet. C'est pratique, on refait passer un flux IP encapsulé dans HTTP lui même encapsulé dans IP. Vu comme ça cela paraît aberrant, non ? Mais au moins cela permet d'éviter d'avoir à recréer une nouvelle stack réseau au-dessus d'HTTP et de réutiliser celle d'Internet. A quand une API OpenVPN dans les serveurs d'applications et les navigateurs ? Comme les poupées gigognes, on peut alors, juste pour rire, ouvrir un autre VPN sur une couche HTTP de ce nouveau réseau. « C'est pas grave, les machines sont de plus en plus rapides. »

Et ce qui est sympa avec HTTP, c'est qu'on est pas certain que les flux ne seront pas manipulés au passage. Il faut donc travailler en mode texte, le plus basique possible. Et voilà qu'entrent en jeu XML, les encodage b64 ou hexa, etc. Beaucoup de bruit, de traitements, de trafic réseau... pour rien !

On se retrouve obligés de réinventer pas mal de roues pour permettre des appels distantsde procédures ou de services. La catastrophe a commencée avec l'apparition des services Web et des protocoles SOAP et WSDL. Cela partait d'un bon sentiment pourtant : créer une couche d'interopérabilité pour pouvoir rendre les applications Web agnostiques en termes de technologies. Mais c'est aussi un moyen de repousser le problème et de masquer l'incapacité du monde informatique à gérer l'interopérabilité (mais je réserve ce sujet à un autre coup de gueule).

Donc un fois la planche bien savonnée, il ne restait plus qu'à se lâcher avec la pléthore de surcouches ou de compléments : WS-Security, WS-Transaction, WS-Coordination, WS-Addressing, WS-Transfer (celui là a un nom prometteur...), WS-Notification, WS-Policy, WS-Reliability, WS-ReliableMessaging, WS-Resource, WS-Federation, WS-CAF (Composite Application Framework), WS-CDL (Choreography Description Language), WS-Discovery, WS-Eventing, WS-Federation, WS-MetadataExchange, WS-Trust, WS-Topics, ... STOP !!! Arrêtons le massacre ! On savait pas faire tout ça avant l'apparition d'HTTP et des services Web ? Avec des protocoles conçus pour cela et éprouvés par l'usage ?

Même pour une simple connexion vers une queue de messages, il faut encapsuler plusieurs sockets dans un seul. En effet, un service de messages doit pouvoir en recevoir mais également en envoyer. Comme il est interdit, par le pare-feu, au serveur de messages de contacter directement le client, ce dernier utilise un protocole simulant deux connexions dans une seule qu'il a initié. Pour faire passer dans HTTP, on ajoute un nouvelle couche.

Même les jeux en lignes utilisent cela. Par exemple, le célèbre jeu Dofus utilise une pseudo connexion HTTP via une requête CONNECT pour communiquer avec le serveur. En réalité, le flux est en clair. Les pare-feux ne se rendent même pas compte que la connexion SSL a été abusée. A quoi servent-il ?

En outre, on a perdu toutes les couches protocolaires de type broadcast. Pour diffuser un flux radio, il faut désormais une connexion par auditeur. Impossible d'envoyer un flux à un groupe d'auditeurs. Idem avec la vidéo. La catastrophe est annoncée, avec la généralisation de la diffusion vidéo en HD. Si toutes les vidéos de YouTube étaient en HD, le réseau ne tiendrait pas. Crac.

Parce qu'y'en a marre de la médiocrité, des RSSI qui interdisent tout systématiquement sans réfléchir et de la disparition des petits administrateurs système soucieux du travail bien fait et conscients de leurs responsabilités.

Jean-Pierre Troll jp.troll@gmail.com
(parce que là au moins je peux consulter ma messagerie à travers n'importe quel pare-feu !)

lundi 1 juin 2009

Sauvons le Web ! Il est en danger.


Mais nous allons finir par tuer le Web si ça continue comme ça ! Je suis attristé d'observer comment une industrie informatique sans recul et les intérêts mercantiles de quelques sociétés commerciales menacent de détruire les fondements même de ce qui a fait le succès du réseau mondial.

Le Web a été conçu il y a 18 ans au CERN, laboratoire de recherche européen sur les particules, par un scientifique anglais du nom de Tim Berners-Lee, désormais directeur du World Wide Web Consortium (W3C). Voilà une idée qu'elle était géniale ! Créer au dessus d'Internet, un réseau de pages reliées entre elles par les liens hypertextes. L'idée, comme un soufflet réussi, a très vite pris. Le nombre de sites Web est monté en flèche, les premiers standards ont été définis pour gérer les noms de domaines, le langage de balisage utilisé pour créer les pages (HTML). On peut vraiment dire que c'est le Web qui est à l'origine du succès d'Internet.

C'est également dans un centre de recherche, américain, le National Center for Supercomputing Applications (NCSA), qu'a été créé le navigateur Web Mosaic. Ce n'était pas le premier mais il était graphique et multi plate-forme et est vite devenu la killer application d'Internet. A un tel point qu'un des développeurs du logiciel, Marc Andreessen, crée en 1994 une société commerciale produisant le navigateur Netscape basé sur Mosaic. L'entrée en bourse de la société Netscape Communications l'année suivante, rendant Andreessen multimillionnaire en une nuit, a marqué le début de la bulle Internet et l'entrée du Web dans la sphère commerciale.

Microsoft, dont le PDG Bill Gates ne croyait pas du tout au potentiel d'Internet, a été pris par surprise par le succès du Web et de Netscape. Pour rattraper son retard, Microsoft a acheté une licence d'un navigateur, lui-même basé sur Mosaic, pour le renommer Internet Explorer en 1995. Cela marque le début de la première guerre des navigateurs, Netscape contre Internet Explorer. Cette guerre, finalement perdue par Netscape à cause d'un abus de monopole de Microsoft, même si elle a été à l'origine de certaines innovations (JavaScript normalisé sous le doux nom d'ECMAScript, applet Java, HTTPS), a bien failli avoir la peau du Web si prometteur. En effet, les deux camps se concentrant plus sur l'ajout de nouvelles fonctionnalités que sur la correction de bugs et sur l'innovation propriétaire plutôt que les respects des standards, ont produit des navigateurs de moins en moins interopérables et normalisés. L'exemple le plus pénible est sans doute les implémentations de JavaScript. Quel développeur Web n'a pas déjà pesté en découvrant que son site ne fonctionnait plus (qu')avec Internet Explorer ?

Cependant Netscape libère le code source de son navigateur en 1998 sous le nom de Mozilla, nom de code interne et mascotte du navigateur chez Netscape. Le succès viendra avec une version plus allégée du navigateur, renaissant tel un Phénix sous le nom de FireBird, puis de Firefox. Cela marque le début de la deuxième guerre des navigateurs, avec l'émergence de nouveaux belligérants comme Opera, Apple et récemment Google.

Plus encore que lors de la première guerre, celle-ci risque de remettre en cause la pérennité du Web en tant que réseau interopérable basé sur des standards. Y'en a marre des stratégies commerciales qui influent sur les normes dans le seul but d'emprisonner les internautes et les entreprises dans des produits propriétaires ! Y'en a marre que des normes, élaborées pourtant avec patience par des passionnés qui aiment les belles choses bien faites, soient torpillées par des industriels qui inondent le marché avec du mauvais logiciel produit à la chaîne, comme l'ex futur EcmaScript 2 qui ne plaisait pas à Microsoft !

A l'aube de la métamorphose du Web, d'un réseau de pages en une plate-forme d'accès à de services et des ressources, les technologies sur lesquelles il est basé se doivent d'évoluer. Donc, oui au client riche plus sexy et multimédia, oui au mode déconnecté, au Push depuis le serveur, et aux fonctionnalités du client lourd perdues lors de l'avènement du Web. Mais n'oublions pas que c'est l'existence d'un jeu de standards partagés et librement implémentables par tous qui a permis cet avènement. Quand je vois Microsoft, Adobe ou, dans une moindre mesure, Sun se tirer la bourre pour occuper le terrain en proposant tout bonnement de remplacer les standards par leurs technologies et protocoles propriétaires, j'attrape une crise d'urticaire rien qu'à l'évocation de ces solutions élevées en batterie !! Qu'est-ce que sont XAML, MXML ou JavaFX sinon les sombres rejetons d'éditeurs commerciaux qui rêvent de remplacer HTML et pousser leurs technologies qu'elles soient .Net, Flash ou Java ? Et que penser lorsqu'ils remplacent carrément le protocole HTTP ou sortent du navigateur avec le modèle Rich Desktop Application (RDA) ? On ne peut plus appeler cela du Web, juste du vieux client/serveur poussiéreux qui réutilise certaines notions démocratisées par le Web comme le balisage, la séparation du contenu de sa présentation et de son style, et la diffusion du code exécuté sur le client via le réseau.

Il reste cependant une lueur d'espoir. Certains libres penseurs subsistent et tentent d'améliorer et faire évoluer le Web via ses standards. Merci à Mozilla, Opera et Apple d'avoir décidé, en 2004 et en réaction à la stratégie Windows Presentation Foundation (WPF) de Microsoft, de s'allier, au sein du Web Hypertext Application Technology Working Group (WHATWG), pour proposer des évolutions des standards du Web à un W3C sclérosé. Depuis, leur travaux sur X/HTML 5 ont été repris au sein du W3C. Merci aussi à Google, qui – pour continuer à indexer nos vies ! – pousse également cette initiative et améliore l'existant en attendant, avec des solutions comme Google Gears pour le mode déconnecté ou son implémentation plus performante d'EcmaScript (V8).

X/HTML 5 et les standards Web connexes comme XBL 2 sont en cours de finalisation. Ils comblent eux aussi les manques du Web actuel avec des propositions comme les balises [canvas/] et [video/], le mode déconnecté, le support du drag-and-drop ou encore WebForms 2.0... intégrées à HTML 5. Alors que par ailleurs, le WHATWG continue de travailler sur la définition de notions telles que les WebWorkers pour permettre l'exécution parallèle de code JavaScript.

Mais comme il s'agit d'un travail de normalisation, cela prend forcément plus de temps que de sortir de nouvelles technologies d'un laboratoire propriétaire et d'essayer d'en faire un standard de facto. A nous de choisir entre du travail bien fait ou de la production industrielle et mercantile moins soucieuse de notre bien être... Surtout que certaines des recommandations sont et seront implémentées dans les navigateurs bien avant les versions officielles des normes. Par exemple les dernières versions de développement de Firefox implémentent déjà les balises [canvas/] et [video/], alors qu'Opera implémente en outre complètement WebForms 2.0.

Mais le chemin sera très certainement semé d'embûches, à l'instar de la controverse autour de la balise [video/] et du format Ogg Theora qui, suite à des pressions de la part d'Apple et Nokia, a été retiré d' HTML 5 en tant que codec recommandé...

Si l'on ne veut pas que le Web reste dans l'histoire de l'informatique comme une période révolue où l'ubiquité interopérable aura prévalu avant d'être exterminée par la recherche du profit et en raison des stratégies de domination des fournisseurs de technologies, il nous faut réagir maintenant ! Sauvons le Web ! Restons exigeants et donc patients ! Exigeons du développement informatique durable ! Consommons des produits sains et qui respectent l'écologie du Web !

Parce qu'y'en a marre de la médiocrité, des développeurs en batteries marqués au fer de tel ou tel éditeur et de la disparition des petits artisans soucieux du travail bien fait.

Jean-Pierre Troll

jp.troll@gmail.com (parce que j'adore qu'on indexe ma vie privée !)

vendredi 1 mai 2009

L'abus de composants


Y'en a marre des projets qui accumulent les composants - Open Source ou non - comme des trophées. Les développeurs ne savent plus coder sans utiliser des composants externes, de plus en plus nombreux, générant de plus en plus de traitements. Et pour quoi faire ?

Chaque composant impose sa liste de dépendance. Pour bénéficier d'un service, il faut en rapatrier beaucoup d'autres. Cela devient tellement compliqué qu'il faut concevoir des chaînes de dépendances pour être certain de tout avoir sous la main, au cas où une méthode aurait besoin de quelque chose. Les programmes deviennent ainsi de plus en plus volumineux, sans que les fonctionnalités suivent pour autan.

Une étude rapide du code d'une application démontre souvent que les composants sont utilisés pour pas grand chose. Quelques lignes codées « à la main » peuvent avantageusement remplacer un composant et toute sa clique de dépendances.

À titre d'illustration, évoquons un audit effectué sur une applet java, un code qui doit être téléchargé sur le poste du client. Le code était très volumineux car très riche et complexe, utilisant Swing, de nombreuses fenêtres et boites de dialogue, des graphiques, des analyses mathématiques et de la communication dynamique avec le serveur. En étudiant le code, nous avons constaté qu'une grande part des composants, tous Open Source, était utilisé par une ou deux méthodes. Il était possible de les remplacer par deux lignes de code Java. En suivant nos recommandation, la taille de l'applet a été divisée par deux, sans aucune perte de fonctionnalité. Il y a avait donc 50% de code inutile !

Coté serveur, c'est la même chose. Les applications sont de plus en plus volumineuses, exigeantes en mémoire et en espace disque, alors qu'elles ne font généralement que de la gestion de base de données et se limitent à produire quelques pages XHTML.

Un simple exemple comme « petclinic » de Spring, ne gérant qu'une dizaine de page et une petite base de données, est porté par une archive de 17 Mo ! Cela donne quoi comme image mémoire ? Il faut combien de serveurs pour gérer quelques centaines de requêtes par secondes ?

N'y a t'il pas là un effet CV ? « Plus j'utilise de frameworks Open Source, plus je peux en ajouter dans mon CV et donc, plus je suis un balaise ! »

C'est absurde. A l'époque du C++, il y avait un dogme très important : « je ne paye que pour ce que j'utilise ». En gros, je ne veux pas devoir ajouter un parseur XML spécifique, un composant de logs particulier, un analyseur d'expression régulière, des fichiers de ressources en 53 langues, tout cela pour lire un fichier de paramètres me permettant d'initialiser mon application.

Pour répondre au principe évoqué, les composants doivent être le plus économes possibles en termes de dépendances. Pour cela, il faut parfois revoir l'architecture pour accepter des plug-in optionnels, imposant alors quelques dépendances supplémentaires. Ainsi, l'application consommatrice ne dépend que de ce qui est indispensable. Je n'ai pas besoin que mon fichier de paramétrage puisse être renseigné en XML, alors je n'utilise pas le plug-in correspondant. Une simple lecture de « properties » suffit.

Les frameworks deviennent de plus en plus riches, de plus en plus souples, mais au prix d'une explosion de la complexité et d'une dégradation assurée des performances.

Par exemple, le framework Spring offre une dizaine de scénarios d'usage (avec ou sans AOP, avec ou sans AutoProxy, avec ou sans annotations, etc.). Au final, lorsque l'on étudie un peu le code du framework, on découvre un volume monstrueux de traitements. Pour faire quoi ? Instancier des objets et les relier entres eux. Cela se traduit en 3 lignes de codes sans Spring !

« Mais il est absolument indispensable de pouvoir modifier le framework de persistance utilisé par l'application sans toucher une ligne de code ». Qui fait vraiment cela ? Ne faut-il pas alors re-tester complètement l'application et la débugger ? S'il y a un bug, c'est donc qu'il faut modifier l'application. On re-teste alors avec l'ancien framework de persistance pour garantir la portabilité ? N'importe quoi. Les projets doivent faire des choix, sélectionner des technologies, et s'y tenir. Il faut assumer dans la vie. S'il est nécessaire par la suite de remettre en cause les choix, on refactorise, car on a une batterie de tests unitaires pour éviter une dégradation de l'application.

À force d'ajouter des couches, plus souple les unes que les autres, lorsqu'un objet désire invoquer une méthode d'un autre objet, en réalité il va passer par de nombreuses étapes :

  • L'objet cible est en fait un proxy. Ce dernier capture l'invocation de toutes les méthodes.

  • Le proxy génère des instances pour décrire l'invocation de la méthode invoquée.

  • Le proxy appelle une instance associée qui analyse la méthode à invoquer pour y apporter éventuellement des modifications, pour encapsuler le code d'une gestion de transaction, de la sécurité, etc. Il faut donc comparer le nom de la méthode et ses paramètres avec différentes combinaisons pour savoir de quoi elle traite. Et une boucle de plus. Plus il y a de méthodes dans l'objet, plus le traitement est long.

  • Puis le traitement est lancé à l'aide des paramètres construits par le proxy.

  • Le code utilise alors l'introspection pour trouver la bonne méthode dans la classe, construire un tableau d'objets avec les paramètres et la méthode est invoquée. Une boucle de plus.

  • La JVM analyse l'invocation dynamique pour la transformer en invocation directe vers la méthode cible.

  • Le traitement s'effectue sur l'objet cible ? Non, sur le prochain proxy qui se charge d'une autre couche !

  • Et on recommence pour ajouter la sécurité, la tolérance aux pannes, etc.

  • Au final, après plusieurs cycles, l'objet cible est enfin invoqué.

  • J'ai enfin atteint la cible. J'ai demandé un getNom(), je peux le retourner à l'appelant.

  • Et on remonte tous la chaîne dans l'autre sens. Faut-il modifier l'objet en retour ?

  • Pop, pop, pop, on remonte la chaîne.

  • Et enfin, le nom est retourné à l'appelant.

  • Je veux le prénom maintenant. Pas de problème, on recommence !

Combien de fois faut-il faire cela dans une application ? Plusieurs milliards ? Plusieurs milliards de milliards ? La CPU sert à quoi dans ce cas, à montrer que le framework est « super balaise », qu'il a une plus grosse « introspection » que les autres ? Et cela, sans compter que le serveur d'applications utilise également un machine virtuelle : la JVM.

Heu, je veux juste invoquer getNom() puis getPrenom(). C'est 10 cycles CPU normalement, pas 200 millions de cycles... On marche sur la tête.

Des audits sur la consommation CPU ont été effectué sur des projets d'EAI utilisant abusivement les services Web. Au final, 70% de la CPU ne sert qu'a parser les flux XML. Elle est où la valeur ajoutée ? Pour une machine qui travaille, il en faut sept qui font du bruit, de la chaleur et consomment les ressources de la planète. Et tout le monde est content. Voire pire, les développeurs sont fiers de leurs architectures et de leurs projets. Nous n'avons pas tous les mêmes critères.

Utiliser des composants, oui, mais à discrétion. La valeur ajoutée du composant doit être très forte. Il ne suffit pas de vouloir ajouter une ligne à son CV pour justifier un composant, ou que celui-ci soit « à la mode ». Nous avons eu la période « Strust », puis la période « Spring ». C'est quoi la prochaine, l'AOP ?

À quand une charte de qualité environnement pour les projets informatiques ? Il faut exiger une consommation de ressource minimum dans les appels d'offres. Valoriser les améliorations du code permettant de libérer un des serveur du parc informatique et contribuer à sauver la planète.

Parce qu'y'en a marre de la médiocrité, des développeurs en batteries et de la disparition des petits artisans soucieux du travail bien fait.

Jean-Pierre Troll

jp.troll(at)gmail.com (tout seul sans composants ni amphétamine)

mercredi 1 avril 2009

Les machines virtuelles en exploitation


Y en a mare des discours marketing qui incitent les développeurs à faire n'importe quoi. Et ils s'y précipitent sans recul, avec la certitude d'avoir fait les bons choix, alors qu'ils ne font que suivre des discours lénifiants. Où sont les petits artisans qui façonnent un code avec de bons produits, qui réfléchissent avant d'agir ?

Parmi les nombreux sujets me hérissant les poils, il y a l'utilisation de machines virtuelles pour résoudre tous les problèmes de production. Mais où va t'on ?

Initialement, il y avait des systèmes d'exploitations minimalistes n'offrant en gros, qu'un accès à des fichiers. Puis sont venu des systèmes multi-tâches permettant à plusieurs applications de fonctionner ensemble. Qu'elle drôle d'idée ! Chacun sait que le dogme actuelle en déploiement est « une application égale un serveur ». Et oui, grande nouvelle, les systèmes multi-tâches savent gérer plusieurs applications en même temps. Donc, en déploiement, pour mutualiser les ressources, la meilleure approche est d'installer plusieurs applications dans le même système d'exploitation.

Avec l'avènement du Net, il a fallu accepter de très nombreux utilisateurs en mêmes temps pour la même application. Des serveurs d'applications ont été conçus pour différentes technologies : .Net, Java, Php, etc. Ces serveurs ont vocation à accueillir différentes applications gérées par le même serveur. Pour permettre cette mutualisation, des serveurs comme Apache acceptent d'avoir plusieurs noms : les virtuals hosts. Ainsi, le même serveur peut accueillir différentes applications, pour différents sites et cela dans le même programme ! Grande nouvelle, il y a bien un s à serveur d'applications. Donc, même si le système d'exploitation sait gérer plusieurs applications en même temps, il est généralement suffisant d'avoir un seul applicatif coté serveur pour mutualiser les ressources.

Parfois, ce n'est pas possible. Par exemple, si le serveur d'applications utilise une gestion des ressources paraisseuse. La mémoire qui n'est plus nécessaire n'est pas libérée immédiatement, mais plus tard, lorsqu'un ramasse miette le juge nécessaire. Dans ce type d'architecture, mutualiser toutes les applications dans le même serveur d'applications peut entrainer une exigence plus importante de la mémoire et donc un temps de nettoyage des ressources trop important.

Qu'a cela ne tienne. Comme le système d'exploitation sais gérer plusieurs applications en même temps, il n'y a qu'a lancer plusieurs instances de serveurs d'applications avec un partage de la mémoire. Ainsi, deux nettoyages pourront s'effectuer en même temps, mais sur un volume de mémoire moins important pour chacun.

Il est donc possible de mutualiser à plusieurs niveaux : dans un serveur d'applications ou dans le système d'exploitation.

Oui mais voilà que les machines virtuelles pointent leurs nez en production. Pour ne pas remettre en cause le dogme débile : « une application égale un serveur », les marketeurs proposent d'utiliser des machines virtuelles. Ainsi, chaque application possède son propre système d'exploitation et son propre serveur d'applications. Vous souhaitez mutualiser les ressources ? Ajoutez une machine virtuelle ! (on oublie de vous dire qu'il faut également ajouter un autre système d'exploitation et un autre serveur d'applications). Et on fait quoi du dogme ? On s'assoit dessus sans le dire, car il y a bien physiquement plusieurs applications dans le même serveur, non ?

Bonjours le nombre de couches ! Pour chaque application, nous avons : un serveur d'applications qui a perdu son 's' car il ne gère plus qu'une seule et unique application ; un système d'exploitation qui ne sert franchement pas à grand chose, car il ne doit plus gérer qu'un seul processus ; un noyau de virtualisation hébergé ou non dans un autre système d'exploitation, qui se charge d'isoler les applications les unes des autres.

Isoler quoi ? Uniquement l'accès mémoire. Les machines virtuelles n'isolent pas le réseau, la consommation CPU, la place disque, etc. L'isolation mémoire est-elle vraiment nécessaire ? Les systèmes d'exploitations n'exploitent-ils justement pas la mémoire virtuelle des microprocesseurs pour cela ? Avec une machine virtuelle, on isole un isolant. Quelle riche idée !

  • Et c'est mieux ?

  • Oui, oui, madame Michu. Du moment que cela vous coûte plus cher.

À force d'ajouter des couches au bébé, ce dernier n'est pas prêt de marcher. Tout nu, il fera ces premiers pas. Avec trop de couches, il sait faire le grand écart, mais cela ne lui sert à rien. Un peu de bon sens que diable !

Puis, n'ayant pas saisi les vraies raisons motivant d'utiliser une technologie plutôt qu'une autre, le développeur va faire preuve de prouesses dans le grand n'importe quoi. Par exemple, et cela se rencontre dans la vraie vie, deux machines virtuelles seront installées sur le même nœud physique afin d'avoir de la tolérance aux pannes. Ah bon ? Quelles pannes ? Le plantage d'un serveur d'applications ? Pourquoi pas. Mais cela règle vraiment le problème ? Un chien de garde n'est pas suffisant ? Et que se passe-t'il si le disque du nœud plante ? Et bien toutes les machines virtuelles sont instantanément hors circuit. Que se passe-t'il si un des nœuds a son réseau planté ou qu'il est attaqué par déni de services ? Toutes les machines virtuelles sont mortes. Paix à leur âmes... Qui peut me donner un seul argument justifiant cette architecture ? J'entends par là, prouvez moi qu'il n'existe pas une autre solution plus économe en ressource.

À quoi servent vraiment les machines virtuelles ? Voilà la question qu'il faut se poser. Et non : « comment ça fonctionne ». Un bon artisan se pose les bonnes questions et ne cherche pas à ajouter une ligne à son CV : « j'ai mis en place des machines virtuelles ».

Les machines virtuelles servent essentiellement en phase de développement. Elles permettent un retour arrière lors des installations, permettent à chaque développeur de simuler des architectures complexes, facilite les tests de portabilité entres systèmes d'exploitations hétérogènes, etc.

En production, elles permettent une mutualisation des ressources, si et seulement si, chaque instance utilise un système d'exploitation différent. Il n'y a pas d'autre solution pour marier sur le même serveur, une application exigeant Windows et une autre exigeant Linux que d'utiliser des machines virtuelles. Mais avec deux Windows ou deux Linux, n'y a-t'il vraiment pas d'autres solutions ?

Parfois, les machines virtuelles migrent dynamiquement d'un nœud à l'autre, le soir par exemple, afin de pouvoir éteindre physiquement certains serveurs. Il faut par exemple dix serveurs en charge nominale, mais que deux serveurs dans les périodes creuses. Dans ce cas, quel est l'intérêt, le soir, de distribuer dynamiquement dix machines virtuelles sur deux nœuds ? De toutes façons les deux nœuds ne savent pas tenir la charge des dix machines virtuelles. Elles sont donc sous utilisées. N'est-il pas plus judicieux de paramétrer dynamiquement le répartiteur de charge pour lui dire de n'envoyer les requêtes que sur deux nœuds et d'oublier les autres ? Quelques lignes de scripts suffises, mais c'est moins sexy. Cela ne ressort pas pareil sur un CV.

Souvent, par crainte d'affronter les projets pour leurs imposer de mutualiser les ressources dans le même système d'exploitation, les exploitants utilisent des machines virtuelles. C'est un marché de dupes. De qui se moque t'on ? Les ressources sont bien partagées, mais à l'insu du projet. La bonne affaire. On ajoute une couche « système d'exploitation » pour rien, uniquement parce que les développeurs ne savent pas travailler dans le respect du système d'exploitation d'accueil. Qu'ils retournent à leurs fourneaux. C'est leurs jobs que diable ! On ne sait plus écrire un code qui partage le système d'exploitation ?

Parfois, il faut ajuster le système d'exploitation pour les besoins spécifiques d'une application. Le paramétrer de manière particulière. Est-ce que ces ajustements sont incompatibles avec une autre application ? C'est très rarement le cas.

Maintenant, nous arrivons à une évolution naturelle de ces usages : « pourquoi ne pas se passer du système d'exploitation ? » C'est en effet, une bonne question. Certains serveurs d'applications savent se passer de système d'exploitation pour dialoguer directement avec le noyau de virtualisation. D'autres utilisent un noyau Linux minimaliste pour faire la même chose. CQFD.

Le système d'exploitation du futur est la virtualisation. On gagne quoi dans l'affaire ? Rien. On croit résoudre un problème en changeant le nom d'une couche. Il faut arrêter de se leurrer. La virtualisation n'est pas une fin en soi. C'est un moyen de dernier ressort. À n'utiliser que s'il n'existe pas d'autres solutions. Il faut démontrer qu'il n'est pas possible de mutualiser les ressources dans le serveur d'applications, puis dans le système d'exploitation avant d'envisager d'utiliser la virtualisation en production.

Le nombre de couches à traverser pour effectuer un traitement basique est de plus en plus prodigieux. Il faut alors multiplier le nombre de serveurs pour finalement pas grand chose à l'arrivée. Alors que certains gèrent 150 hits par secondes avec deux serveurs, d'autres doivent utiliser 6 serveurs pour obtenir les mêmes résultats. Quelle approche faut-il utiliser ? La plus économe, la plus écologique, ou la plus hype et séduisante sur un CV ?

Les mêmes travers ont été constatés au fil des années, avec l'utilisation des EJB en Java/JEE : « c'est très bien, il faut absolument les utiliser, cela réglera tous vos problèmes », puis plus tard, les mêmes de sermonner : « voyez comme les EJBs ne sont pas efficaces, utilisez maintenant les EJB3 ou les bons vieux objets Java ». On nous présente maintenant les POJO (Plain Old Java Object) comme une nouveauté ! On marche sur la tête. Ceux qui n'ont jamais quitté les objets Java simples, étaient « has been » auparavant et deviennent subitement « in » désormais. Cycle éternel de l'informatique.

L'histoire est un éternel recommencement, dans quelques années, on nous expliquera que les machines virtuelles doivent remplacer les systèmes d'exploitations, puis que finalement, un système d'exploitation bien paramétré est largement suffisant et tellement plus simple à administrer.

À quand une charte de qualité environnement pour les projets informatiques ? Il faut exiger une consommation de ressources minimum dans les appels d'offres. Valoriser les améliorations du code permettant de libérer un des serveur du parc informatique et ainsi contribuer à sauver la planète.

Parce qu'y'en a marre de la médiocrité, des développeurs en batteries et de la disparition des petits artisans soucieux du travail bien fait.

Jean-Pierre Troll

jp.troll(at)gmail.com (parce que j'ai bien qu'on référence ma vie privée)

dimanche 1 mars 2009

L'excès de structure

Y en a mare des grands principes d'architectures qui imposent des couches et couches sans valeurs ajoutées. Où est perdu le sens commun ?

« Il faut séparer la couche métier, de la couche processus, de la couche présentation, de la couche de persistance. Chaque couche doit être hermétique. »

Super. J'ai participé à des projets basés sur ce type d'approche.

  • Comment gérer les exceptions ?

  • Et bien, dans chaque couche, on capture l'exception, on l'encapsule dans une autre et on la propage.

  • On ne doit pas capturer les exceptions par leurs types ? Si je l'encapsule, je n'ai plus le moyen de différencier la gestion d'erreur suivant son type !

  • Si, si. Fait un switch sur le instanceof getCause() !

  • Ce n'est le rôle de l'instruction catch ?

  • Heu, oui mais autrement cela viole les principes architecturaux.

Donc, pour écrire un simple traitement métier pouvant par mégarde avoir un problème (violation d'une règle d'intégrité de la base de donnée, paramètres invalides, etc.) je dois écrire beaucoup de traitements, sources d'erreurs.

J'écris le traitement de la couche métier qui traite les paramètres et retourne un objet métier. Un nouveau traitement, normal.

Dans la couche métier une capture d'exception de la couche de persistance. Transformer l'exception et la propager. Et un nouveau traitement, cela fait deux.

Pour qu'elle ait une sémantique, je dois donc écrire une nouvelle classe d'exception spécifique. Et une nouvelle classe.

Dans la couche processus, s'il n'y a pas d'exception, je vais bien entendu transformer les objets de présentation reçu en paramètre pour les rendre présentable à la couche métier. Je fais de même pour transformer les objets de retour de la couche métier en objets utiles à la couche présentation. Je remplace les entiers, les flottants, etc. en chaines de caractères. Et deux nouvelles classes, ce qui fait trois et deux nouveau traitements ce qui fait quatre.

De plus, je capture l'exception pour l'encapsuler et la propager sous une autre forme. Et un nouveau traitement, ce qui donne cinq.

Pour garder une sémantique, je dois écrire une nouvelle classe d'exception spécifique à la couche processus. Et une nouvelle classe, ce qui fait quatre.

Dans la couche présentation, j'utilise les objets de présentation. En cas d'exception, j'analyse en profondeur la cause, puis je présente des excuses à l'utilisateur. Un traitement de plus, mais c'est inévitable.

Pour respecter l'architecture, j'ai donc écris cinq traitements supplémentaire et quatre classes. Tous cela pour une seule petite méthode métier !

Les impacts négatifs sont nombreux : complexification du code ; multiplication du nombre de ligne de code, donc d'erreurs ; difficulté à faire évoluer le code ; empreinte mémoire plus importante ; consommation CPU plus importantes ; multiplication des ressources de la plate-forme de production ; impact écologique associés.

Rappelez moi l'objectif d'une architecture ? Ce n'est pas d'uniformiser et de simplifier ? C'est réussi ? Il semble que non.

Pourquoi ne pas utiliser des idées simples comme : « Les objets métiers peuvent être directement manipulé par la présentation ». « Les objets métiers sont persistants » « Les exceptions ne doivent en aucun cas être convertie, à moins d'apporter un valeur ajoutée permettant un meilleur traitement de celle-ci. »

Certaines idées émergent maintenant, comme le mariage de la couche métier et de la couche de persistance, grâce à des frameworks d'annotation et de modification dynamique du code. C'est une bonne chose. Mais, sans ces frameworks, c'était possible également. Par excès de structure, on a séparé les couches.

Lorsque l'on propose des solutions alternatives à ces architectures, démontrant clairement la simplification d'une architecture alternative, la réduction du nombre de lignes de code, l'amélioration des performances, on reçoit généralement un refus du client ou de l'architecte. « C'est moins académique... » Que répondre ? Il n'y a pas plus sourd que celui qui ne veux pas entendre.

Nous manquons de bon sens ou de sens pratiques. Les études que nous avons suivi nous incitent tous à faire la même chose, sans réfléchir. Comme le montre brillamment l'expérience de Victoria Horner (http://tinyurl.com/8n7wx2 ), Les singes réfléchissent, les enfants nous singent. Il est temps de devenir adulte et de réfléchir.

A suivre le troupeau, ont fonce vers des catastrophes. Dans un autre métier, la finance par exemple, il fallait surtout suivre le voisin, même si tous le monde savait qu'on allait dans le mur. Maintenant c'est fait.

On ne vous reprochera pas d'avoir tord avec les autres. Seulement d'avoir tord tous seul. Par contre, avoir raison tous seul n'est pas facile.

Au exemple réel. Je devais faire passer des tests en C++, rédigés par d'autres, afin de tester les connaissances des candidats à l'embauche. La question était simple : écrivez une classe qui permet d'avoir une pile de caractères avec les méthodes push() et pop(). (Les Standards Templates Librairies n'exitaient pas encore). Une méthode pour ajouter un caractère à la pile, une autre pour enlever le caractère au dessus de la pile.

Tous les candidats sans exceptions, écrivaient une classe périphérique Item pour pouvoir construire une liste chainée portant le caractère à mémoriser. La classe Stack offraient les méthodes push() et pop() et manipulait la liste chainée en conséquence.

Super, cela fonctionne. Mais, c'est la plus mauvaise réponse pour le cas d'espèce. Il s'agit d'une pile de caractères ! Soit un seul octet en mémoire ! Mettre en place une infrastructure logicielle lourde, avec de nombreux objets, des pointeurs partout est une absurdité. C'est utiliser trois semi-remorque pour aller chercher une demi-baguette.

La bonne réponse est d'allouer un simple tableau de caractère et de gérer un entier indiquant le nombre d'élément. Si le tableau déborde, on en crée un nouveau plus grand, on recopie l'ancien, on ajuste les compteurs et voilà.

La réponse académique n'est pas la bonne. Pour s'en rendre compte, il faut réfléchir un peu et ne pas foncer tête baissée. A t-on appris à réfléchir dans nos formations ? Continuons comme des enfants ou avons nous passé le stade du singe ?

L'inversion de dépendance est la dernière idée à la mode. C'est en effet une excellente solution pour casser la dépendance entre les composants, pour pouvoir les réutiliser dans différents contextes. C'est très bien pour les composants génériques et les frameworks. Mais est-ce vraiment utile pour les simples applications ?

Pour une application, cela permet de lier quelques objets entres-eux le temps d'un test unitaire. Les tests sont ainsi plus léger. Mais en production, les objets à utiliser et à lier sont finis, bien identifiés et ne doivent pas bouger. On ne change pas à chaud de framework de persistance ! Utiliser l'inversion de dépendance dans la phase d'initialisation de l'application pour construire les différents objets et les lier entres eux est une bonne idée. Cela prend quelques lignes de code.

Faire la même chose via un fichier XML complexe, entrainant l'utilisation de framework lourd, cela en vaut vraiment le coup ? J'ai toujours pensés qu'il était plus facile d'écrire quelques lignes de code Java ou C# que d'écrire la même chose en XML. Le rapport signal bruit du XML étant très, très mauvais, quelques lignes de Java ou C# sont toujours plus économique en volume de code, vitesse d'exécution et place mémoire.

Par abus du principe d'inversion de dépendance, les projets ne savent plus lier deux objets sans passer par le framework Spring. Il faut que tous objets puissent être relier à tous les autres objets du monde. C'est vraiment utile ? Il faut vraiment que tous les objets utilisent Spring ? Les quelques objets structurant ne sont pas suffisant ? Il faut un fichier XML énorme pour montrer qu'on maitrise le framework ?

Maintenant, l'évolution consiste à utiliser les annotations pour cela. C'est une très bonne chose. Il faut abandonner les fichiers de paramètres XML si on peut écrire la même chose avec quelques lignes de code !

Lorsque l'on conçoit une architecture logicielle, il faut toujours garder à l'esprit le volume de code nécessaire à écrire pour la respecter. Une bonne architecture est économe en ressources. Elle doit être pragmatique et non académique.

La différence entre un terroriste et un architecte ? On peut négocier avec un terroriste.

À quand une charte de qualité environnement pour les projets informatiques ? Il faut exiger une consommation de ressource minimum dans les appels d'offres. Valoriser les améliorations du code permettant de libérer un des serveur du parc informatique et contribuer à sauver la planète.

Parce qu'y'en a marre de la médiocrité, des développeurs en batteries et de la disparition des petits artisans soucieux du travail bien fait.