Quelque chose de très important est en train de se produire. Pour la première fois depuis bien longtemps, l'avenir de Flash est remis en cause par divers événements. Nous sommes à un tournant majeur dans le domaine des interfaces graphiques et les prochains mois vont être riches en enseignements.

Lire la suite »

Tout le monde le sait, en plus d'être l'homme le plus riche du monde, Bill Gates est également le plus adulé. Sa personnalité, son sens de la discrétion et sa faible exposition l'ont érigé en une sorte de surhomme planétaire qui attise toutes les convoitises.

En lisant l'article de 01net qui relate son départ de FaceBook (où il garde toute de même un bon paquet d'actions), j'ai évidemment fait le rapprochement avec ce billet que j'avais posté en 2005 quelques temps après notre rencontre au Symposium DNG. Avec ce billet qui montre simplement le scan d'une lettre de remerciements envoyée par ses services et signée par lui, j'ai vraiment pris la teneur de sa popularité. Je n'attache habituellement pas beaucoup d'importance au lien éphémère que l'on peut avoir lors d'une rencontre, aussi sincère soit-elle, avec les grands de ce monde. Le phénomène de starification (plus chère aux pays anglos-saxons qu'en France d'ailleurs où on tient à une certaine pudeur) m'a toujours un peu gêné.

Mais toujours est-il qu'il ne se passe par une semaine où ce billet ne reçoive de commentaires de familles, d'enfants désoeuvrés, persuadés que je suis Bill Gates l'ayant simplement côtoyé le temps d'une interview. Il m'arrive de les lire, même si avec le temps et la lassitude, je finis par les ignorer. Mais nul n'étant insensible, j'imagine parfois toute la détresse que peut ressentir quelqu'un qui souhaite absolument quémander, discuter ou échanger ne serait-ce qu'un instant avec le moins commun des mortels. J'imagine également ce que peut ressentir l'homme Bill Gates lorsque 10.000 amis cherchent à tout prix à le contacter sous FaceBook pour les raisons qu'on connait tous.

Peut-on rester insensible à certains de ces messages ? je ne sais pas. Je ne suis pas Bill Gates, et c'est finalement mieux comme ça.

Je viens de découvrir avec une certaine tristesse le déchaînement de passions dont vient faire l'objet Fred Cavazza sur son blog. NaCL est un sujet qui prête à débats et discussions, certes. NaCl est un sujet hautement technique, certes. NaCl est un sujet jeune et disserter sur son devenir ne peut être qu'hasardeux, certes. Mais de là à affirmer qu'un consultant Web ne peut rien apporter en terme d'analyse sur NaCl est un peu fort de café. Le pire dans cette histoire c'est qu'il y a du vrai de part et d'autres. Que ce soit dans certains commentaires corrosifs (pour ne pas dire irradiants) et dans l'analyse de Fred. Analyse qu'il avait d'ailleurs commencé à développer ici.

Lire la suite »

On me demande souvent quel est l'intérêt de Google à faire prospérer les architectures à base de client léger (HTML, JavaScript, ...) telles que Gears ou GWT.

GWT n'est qu'une pièce parmi les milliers d'atouts dont dispose la firme face à cette course effrénée vers la maîtrise de la monétisation du Web.

Lire la suite »

C'est un sujet auquel j'attache beaucoup d'importance et que j'aborde régulièrement lorsque j'anime des workshops, des formations ou simplement entre collègues. Ces trois dernières années, j'ai assisté à ce qu'on pourrait appeler une fracture entre architectes, penseurs, leaders ou experts des communautés (Java ou .NET d'ailleurs) et le monde de la réalité, celle du terrain. Pour former régulièrement des bataillons de développeurs aux nouvelles technos, je me suis aperçu à quel point les "créateurs" de nouvelles technos érigés en pourfendeurs de la bonne parole sont devenus déconnectés des problématiques du développeur moyen. Je l'appellerai (très) affectueusement "Joe le developpeur" en clin d'oeil à une récente campagne médiatisée. 

Pour étayer cette thèse, j'ai choisi (au hasard ;-)) quelques technos et mots-clé qui avaient le vent en poupe dans le monde Java et qui faisait le buzz de n'importe quel séminaire hi-tech du moment:  OSGI, Java 7 Closure, Maven, JSF, Hibernate, ESB, Tests unitaires...

Commençons par OSGI. Aujourd'hui tous les experts (dont je m'associe) s'accordent à dire que l'antédiluvien modèle de déploiement des Jar n'est plus adapté aux mécanismes de classloading et de dépendances modernes. Or, lorsque j'échange avec Joe le développeur sur OSGI, il ne comprend déjà pas le fonctionnement du mécanisme de ClassLoading traditionnel et encore moins ce que les experts lui reprochent. Tout ce qu'il voit, c'est qu'on l'oblige à positionner à la main des attributs supplémentaires dans un fichier au nom peu évocateur (Manifes.mf) et qu'on lui demande s'il souhaite un import statique ou dynamique. Mais le must, c'est qu'on lui demande de lancer une console Equinox ou Felix en ligne de commande DOS (en fonction de l'implémentation)  pour pouvoir charger ses bundle OSGI à l'aide de la commande install ou feature install. Il voit là une formidable avancée technologique, lui qui positionnait simplement un fichier jar dans un répertoire (classpath), aujourd'hui pour être hitech, on lui demande de lancer une commande DOS (je caricature bien entendu, mais Joe a souvent tendance à caricaturer en étant premier degré).

Pour les closures Java, le problème est le même. Certains spécialistes se battent aujourd'hui (si si c'est le terme) pour que le langage Java intègre dans sa prochaine version FCM ou BGGA. Non ce ne sont pas les noms de code des prochains sous-marins nucléaires chinois mais plutôt les spécifications des prochaines closures. Joe n'y connait rien aux closures. Déjà qu'il a du mal avec les classes anonymes et qu'il comprend tout juste l'intérêt du mot clé "final" dans la classe englobante, FCM ou BGGA, vous comprendez qu'il s'en tamponne un peu les coquillettes. Surtout lorsque qu'on lui explique qu'il pourra simplifier énormément son code avec BGGA de cette sorte.  Non, aucun développeur ne souhaite transformer ses listing Java en langage à base de lambda expressions comme en Scheme ou en Lisp. Que ces lambdas expressions servent à construire des pseudo constructions de haut niveau pour bâtir des expressions telles que le Linq de .NET, soit. Qu'on lui impose un langage parenthésé pour simplifier ses problèmes de tous les jours, non.

Le cas Maven est encore plus criant. Aujourd'hui, tout le monde se vante de faire du Maven. Dans la réalité personne ne maîtrise réellement l'ensemble des tenants et aboutissants de cet outil et ses effets de bord insoupçonnés. Joe comprend bien qu'il faille un outil pour gérer ses dépendances (encore que, il trouve souvent Ant plus simple). Il voit bien que parfois il s'y perd avec tous ses jar dans son classpath et qu'il tombe régulièrement sur des exceptions ClassCast ou ClassNotFound. Mais lorsqu'il se met à installer Maven et que pour quelques pauvres jar il voit défiler dans une console DOS des téléchargements internet interminables de fichiers Jar, il commence à sérieusement soupçonner l'anguille sous roche. D'autant plus que le même Maven s'interface sous Eclipse avec un plugin (m2) buggé à mort qui passe son temps à mouliner dans la choucroute. Et lorsque tout est bloqué, résoudre le problème se résume souvent à ouvrir (encore) une console DOS pour vérifier avec un mvn install ou un mvn -e l'origine exacte du problème. Ne lui parlez pas d'Archiva ou Nexus, au mieux ces termes lui passeront complètement au dessus de la tête, au pire il vous rétorquera que les voitures électriques sont encore trop chères pour lui. Et puis de toute manière, Joe ne gardera que le goût amer de cette fichue console DOS. Alors imaginez un instant lui demander de charger un bundle OSGI construit à partir d'une dépendance située dans un POM Maven ...

Je pourrais citer d'autres exemples. JSF notamment qui ne plait pas à Joe. Avec JSF,  il a l'impression de bricoler à longueur de journée. Avec ses kilomètres de JavaScript mélangés à du code HTML mélangé à des TagsLibs (JSF ou JSP) exécutés dans un contexte JSF englobé dans des méthodes, dont on ne sait jamais quand elle seront invoquées (le fameux cycle de vie d'une page JSF). Parfois, il est tellement perdu qu'il finit par rêver la nuit qu'il se fait attaquer par une horde de TagLibs.

Quant aux tests unitaires, personne ne remettra en cause leur utilité ni leur raison d'être. Tout le monde sait qu'on doit en faire. Mais qui en fait ? Je veux dire, qui en fait vraiment ? Pour auditer régulièrement des projets, on s'aperçoit souvent que les tests unitaires ont été codés pour faire plaisir et non pas pour servir. On teste ce qui marche alors qu'on devrait tester ce qui ne marche pas. On les écrit au début et on les oublie très vite à la fin lorsqu'il s'agit de livrer dans l'urgence. Et quid des interfaces lourdes à la Swing ? Quand on sait que plus de 70% de la complexité d'une règle métier peut être liée à son IHM, comment la tester efficacement sans éviter le syndrôme du test robotisé ? Là encore Joe lâche prise sur ces questions.

Les ESB enfin... Expliquer la pertinence et l'intérêt d'une architecture orientée services à Joe et vous découvrirez la nature même du vide astral dans ses yeux. A l'évocation du terme ESB ou SOA Joe pense aussitôt diagramme, modélisation, abstraction, architecte, cravate... Le plus curieux, c'est que Joe comprend très bien les WebServices ou les protocoles de type RMI ou .NET Remoting. Mais il ne voit pas pourquoi on devrait insérer une espèce d'abstraction entre le client et le serveur pour faire intervenir des modèles graphiques (alors qu'on est bien d'accord, un ESB ne signifie pas forcément BPM).

.NET n'est pas en reste. Alors que la dernière PDC a encensé le Framework .NET V4 qui fait la part belle aux langages fonctionnels et à la programmation parallèle, Joe a juste remarqué que les icônes de VS 2008 n'ont pas changé par rapport à ceux de VS 2005. Et puis il râle parce que migrer VS en WPF va encore alourdir sa mémoire et son PC. D'autant plus que Joe vient tout juste d'apprendre à maîtriser Linq (je veux dire la construction des requêtes, pas les lambdas expressions qu'il évite soigneusement d'utiliser). Et je n'évoque même pas Entity Framework ou WCF dont il a acheté les livres, mais les empile dans ses toilettes en attendant de s'en servir lors d'un hypothétique projet.

La majeure partie des reproches que Joe fait à ses nouvelles technologies, ce ne sont pas tant leur intérêt qui finalement le dépasse. Mais il a l'impression non seulement de ne pas les maîtriser, mais surtout de faire à chaque fois un retour en arrière (console DOS, designer WPF pas au niveau du concepteur WinForms, ....). Le besoin d'outil est criant, encore plus lorsque la technologie est complexe. Or, il faut bien l'avouer, les experts cherchent aujourd'hui à se faire plaisir en simplifiant leur façon de développer. Mais ils laissent sur le coin de la route des milliers (millions) de développeurs qui doivent souvent faire sans formation avec les moyens du bord et se retrouvent complètement dépassés. Voilà pourquoi plus que jamais les architectes sont recherchés sur le marché. Voilà aussi pourquoi des projets sombrent par manque de compétences techniques sous prétexte d'avoir vendu des technos "tendances" à un client, encore plus dépassé.

Joe le développeur, c'est personne et tout le monde à la fois. Joe fait le marché, suit la mode, y adhère ou la rejette. On ne peut continuer décemment à l'oublier dans les réunions d'experts, les JCP et autres mouvances sectaires d'origine non contrôlées.

Pour résorber cette fracture, la formation jouera un rôle clé. L'abstraction de toute cette complexité par la création d'outils graphiques, simples et outillés y contribuera aussi. En attendant, il nous faut expliquer, expliquer et réexpliquer les bienfaits du KISS ...

Et j'oubliais, la parole d'un Joe vaut pour moi cent fois celle d'un expert, car au final c'est lui qui se retrouve sur l'échiquier et travaille sans filet...