Je tenais à remercier chaleureusement tous ceux qui ont inscrit la session "GWT à l'épreuve du feu" dans leur agenda de la journée à Devoxx France. Pourtant, les choses étaient plutôt mal engagées avec une session précédente presqu'entièrement vide. GWT est un des sujets chauds (au sens propre et figuré) du moment, c'est sûr.

Concernant le contenu, il est toujours très compliqué de creuser avec 45 min. Il y a souvent deux options dans ce cas de figure, traiter un aspect très spécifique d'une technologie en ouvrant Eclipse et en parcourant du code (c'est ce que j'ai fait avec le compilateur en 2007) ou montrer un cas concret d'application stratégique tout en énumérant les défis techniques. Vu le type d'audience de Devoxx et le nombre de clients nous demandant au quotidien " qui utilise GWT et comment ?", l'option REX (Retour d'expérience) nous semblait un bon moyen de faire connaitre la technologie.

J'animerai sûrement dans l'année des conférences ou séminaires plus pointues lors de la sortie de la seconde édition du livre, mais sachez que tout ce qui a été dit lors de cette session est un ressenti très personnel de l'équipe de développement. Que ce soit notre regard vis à vis de JavaScript, la productivité de notre environnement ou les choix technologiques du projet, nous ne voulons en aucun cas en faire un projet "référence", chaque client a ses contraintes et ses particularités. En revanche, nous voulions insister sur le fait qu'aujourd'hui, en 2012, de nombreux clients utilisent GWT dans leurs applications stratégiques. Ils en sont tout simplement satisfaits et viennent le dire à la tribune avec nous.

Un dernier mot sur l'organisation, j'avoue que je ne connaissais pas (assez) la marque Devoxx pour n'être jamais allé à la version Belge de l'évènement. Mais la version Française m'a définitivement convaincu que c'était un évènement majeur et surtout incontournable de la communauté Java. L'organisation a été (de mon point de vue) parfaite. Je remercie donc l'équipe Devoxx pour m'y avoir invité et je leur souhaite une longue vie. Pour avoir organisé 5 Symposium DNG (dont un au Mariott), le plus dur est de durer...

L'album Devoxx :


>

La maison d’édition Eyrolles organise Mardi 27 Mars une soirée exceptionnelle destinée à faire rencontrer auteurs (spécialistes du Web) et lecteurs. C’est un événement gratuit et le nombre d’inscrits est déjà important. J’avoue que je n’avais pas prévu de faire le déplacement ce jour là mais pour une fois, je vais privilégier le livre à mes activités professionnelles.

C'est l'occasion pour ceux qui ne pourront pas se déplacer à Devoxx de faire dédicacer son exemplaire de “Programmation GWT 2”, discuter technique ou simplement échanger de manière informelle. Je serai ravi de partager un verre (ou deux) avec vous ce soir là. Rendez-vous dans les locaux d'Eyrolles de 18h30 à 20h 1 rue Thénard dans le 5 ème.

Attention, l'inscription est obligatoire => http://www.editions-eyrolles.com/Evenement/Rencontres_experts/

Sami

Difficile de rester insensible au billet de mon ami Florent dont je ne partage pas la vision même si je comprends tout à fait la problématique dans laquelle il se trouve.

Tout d'abord, le support de navigateurs obsolètes, comme Internet Explorer 6 par exemple, n'est plus l'obsession des DSI qui par contre tiennent de plus en plus à ce que leurs applications offrent également un bon rendu sur les dispositifs mobiles et tactiles.

Effectivement, je rejoins Florent sur ce point. IE 6 commence à devenir obsolète. En revanche, pour les périphériques mobiles, la situation est différente. Dans un billet très récent, le responsable de Sencha, une des sociétés leader sur le marché du JavaScript sur mobile s'exprimait au sujet du support de CSS sur les navigateurs. En résumé, leurs applications aujourd'hui ne ciblent que le moteur de rendu WebKit car c'est le plus performant et surtout le plus riche fonctionnellement grâce à ses ... extensions spécifique CSS ! Les fameux -webkit. En d'autres termes, même s'ils cherchent au maximum à créer une abstration au dessus des spécificités des navigateurs, ils maintiennent d'interminables "if (useragent=webkit) use -webkit" un peu partout. Lorsqu'il s'agit d'évoquer IE et les Windows Phone qui vont bientôt submerger le marché, le discours est tout autre. En effet, il faudrait que Sencha convertisse entièrement les styles WekKit de manière spécifique à IE. Economiquement difficile.

Qu'on se le dise une fois pour toute, l'application Web écrite en JavaScript qui tire partie des dernières évolutions d'HTML 5 et de CSS 3 ciblant la plupart des navigateurs du marché de manière unifiée est un leurre. GWT ne cherche pas à remplacer JavaScript, son coeur est assis sur JavaScript, il permet simplement de développer (et surtout) de débogguer une application Java pour générer du code JavaScript optimisé qu'aucun humain ne serait en mesure de coder. C'est aussi pour cela qu'il existe des compilateurs JavaScript vers JavaScript tels que Closure (utilisé intensivement au sein de Google et bientôt intégré à GWT). 

Lorsqu'il s'agit d'utiliser des fonctionnalités "hype" de type CSS Transform, évènements touch, je peux tout à fait comprendre que GWT ne soit pas idéal. Il reste énormément de progrès à accomplir dans ce domaine même si GWT fournit des évènements Touch.

GWT étant avant tout un socle technique, Google laisse à la communauté ou aux éditeurs tiers le soin de bâtir sur son framework. Ainsi Ex GWT, SmartGWT, Vaadin pour ne citer qu'eux disposent de composants de plus haut niveau, prêt à l'emploi. Malheureusement ces bibliothèques n'ont jamais donné pleinement satisfaction : licence peu « business friendly », adhérence importante, problème de qualité. Au final, la sagesse recommande de se contenter de GWT et de tout développer soi-même.

Là encore, sur ce point, je ne partage pas cette analyse. Côté JavaScript, le choix est encore plus abracadambresque. Qu'allez-vous utiliser, Ext-JS ? Il est payant. JQuery ? C'est plus un socle technique que graphique, il ne fournit pas le niveau de richesse d'Ext-JS. DOJO ? Trop limité visuellement pour des applications graphiques complexes. Quant à mustache, Backbone, Node.js ou JavaScriptMVC, où est la pérennité, la maturité ? Et que dire de Bindows, BackBase, Scriptaculous, Prototype, ... il en existe plus d'une centaine !

Est-ce ce monde technique que nous voulons offrir à nos applications Web de demain ? Si on considère qu'une application est jetable au gré du meilleur framework JavaScript du moment, peut-être. Si on considère qu'une application stratégique métier doit être maintenue plusieurs années et subir les évolutions futures d'HTML 5 sans avoir à tout chambouler en permanence, je vote sans hésiter GWT.

Lorsque nos client ont des besoins graphiques complexes, nous leur proposons GXT (Ext GWT). La licence développeur est payante mais largement amortie vu son degré de richesse. Lorsque nos clients souhaitent quelque chose de très "Web" (par opposition à un look applicatif), nous enrichissons les composants de base, c'est coûteux, mais tout développeur JavaScript en aurait fait de même.

Par ailleurs, GWT, au fil des versions, a gagné en complexité, le pattern « activities/places » pour être correctement employé exige que les développeurs soient bien formés ; RequestFactory, CellWidget sont des nouveautés qu'il conviendra à nouveau d'assimiler et qui contraindront la migration d'un bon nombre d'applications.

Concernant Activity&Places et RF (RequestFactory), nous avons plusieurs fois eu l'occasion de nous exprimer sur le sujet (notamment dans les commentaires de ce billet). Chez DNG, nous utilisons A&P avec parcimonie sans l'imposer à nos clients car ce pattern est loin d'être simple (il fait des dégâts irréparables auprès de développeurs non formés) . Il est aussi loin d'être adapté à tous les cas d'école. Quant à RequestFactory, il n'est pas encore mature mais ce framework offre de nombreux avantages. Nous sommes typiquement ici dans un problème de méconnaissance et sûrement aussi de pauvreté de documentation côté Google. Plus que jamais il faut être formé et plutôt que de dire à nos clients "Lisez la doc, c'est facile", nous insistons sur le caractère complexe des API avancées.

Les nouveaux chapitres de la seconde édition de "Programmation GWT 2" évoqueront aussi ces nouvelles fonctionnalités pour démystifier tout cela. Avec GWT vous êtes libres de choisir les API à utiliser en fonction de vos compétences et de votre culture, rien n'est imposé, sachez-le. 

Dans notre société nous n'avons vraiment pas de vision angélique sur cette technologie. Pour l'utiliser au quotidien depuis ses débuts, plus que quiconque nous sommes confrontés à ses désagréments. Mais lorsqu'à la fin du projet nous faisons la somme de tout ce que ce Framework nous a apporté, la question qui revient inlassablement est "Comment aurions-nous fait sans GWT ? ". Une vision pragmatique mais surtout économique.

Pour finir, la richesse de GWT est dans des API telles que ClientBundle qui permet de créer des scripts JS téléchargés avec les spécificités CSS propres à chaque navigateur ou moteur de rendu en fonction des règles du DeferredBinding. La richesse de GWT est dans sa capacité à diviser le code (énorme) JavaScript en plusieurs fragments à la manière d'un ClassLoader Java. La richesse de GWT est dans sa capacité à fournir un environnement de développement hors pair permettant de débogguer comme en Swing, de tester avec JUnit et de refactorer sous son IDE fétiche. Imaginer un instant développer une application JavaScript de 200.000 lignes de code comme on le fait aujourd'hui en Java est tout simplement incensé.

Dans les années à venir, cette question sera au coeur de tous les débats, l'avenir du Web n'est pas JavaScript. Peut-être un nouveau language, peut-être un nouveau runtime mais pas JavaScript. Le marché l'utilise "par défaut" car les navigateurs l'implémentent sans contrainte de runtime ou de plugin. En revanche, je connais peu de développeurs (non chevronnés) qui aiment JavaScript pour ses qualités intrinsèques. 

Sami

PS : J'insiste sur le fait dans cet article que je n'ai jamais dis qu'il ne fallait pas maîtriser un minimum JavaScript pour faire du GWT.

Il y a de cela bientôt trois ans jour pour jour, Google annonçait pour la première fois sa plateforme de Cloud PaaS (Platform As A Service). S'appuyant sur Java, Python ou Go comme langages de développement adossés à AppEngine comme infrastructure de services, force est de constater que 3 ans plus tard, l'engouement du départ a laissé place à plus de scepticisme au fil des mois. Les raisons sont multiples. Développer pour le Cloud nécessite de s'approprier de nouveaux outils, de nouveaux frameworks, tous aussi propriétaires les uns que les autres.

Lors de la présentation officielle de GAE en 2009, aucun des standards Java (excepté l'API Servlet) n'était supporté. Il faut le savoir, l'immense majorité des applications Java développées aujourd'hui s'appuient sur des standards, que ce soit Java EE, Spring (qu'on appellera un standard de fait) ou Java Persistence API. Mais le plus bloquant durant toutes ces années a clairement été l'accès aux données.

La plupart des applications en entreprise n'ont pas besoin de gérer des centaines de milliers d'utilisateurs simultanés, ni de monter en charge linéairement à l'infini. Le commun des mortels ne s'appelle pas FaceBook, Google ou Microsoft. En voulant imposer à tout prix des bases de données de type BigTable avec un vocabulaire aux antipodes de ce que nos développeurs maitrisent au quotidien, les fournisseurs de Cloud se sont enfermés dans des technologies puissantes mais peu productives. Dans ce monde, si vous ne parlez pas couramment MapReduce, DataStorage, Entity ou Kind, point de salut. Le langage d'interrogation des données est quasi inexistant car complexe. La gestion des indexs se fait bien souvent à la main, l'import et l'export des données est propriétaires, donc inutile. Et que dire de la partie Décisionnel ou du Data mining.

Quoi qu'en en dise, les bases relationnelles sont là pour durer. Le standard SQL est loin d'être obsolète et les serveurs d'application ne disparaitront pas avec l'avènement du Cloud. Microsoft l'avait d'ailleurs bien compris en fournissant bien avant Google le produit SQL Azure aidé par le fait qu'il éditait déjà la base SQL Server. Amazon de son côté, avec ARDS (Amazon Relationnal Database Service) en avait fait de même. Google ne pouvait rester les bras croisés.

Je le dis haut et fort chers amis, l'an 1 du Cloud à la mode GAE (Google App Engine) démarre officiellement aujourd'hui. Cette fois, nous ne parlons plus d'une pseudo API JDO ou d'un support limité de JPA sur une base BigTable mais d'une vraie, d'une pure et d'une belle base de données relationnelle, j'ai nommé MySQL. En réalité, deux évènements majeurs ont modifié cet écosystème de niche. Le premier a été l'annonce de Google en Novembre d'un support béta (voire alpha) de MySQL (dont le nom officiel est Google Cloud SQL). Un choix stratégique qui adosse GAE à une marque qu'on ne présente plus. Le second a été le support des standards JEE pour l'accès aux bases relationnelles, à savoir JPA 2 (Java Persistence API) depuis une très récente mise à jour du SDK AppEngine (1.6.1). Ajoutez à cela le support d'un framework ORM comme Hibernate et de Spring comme alternative aux API Entreprise Java Beans (non supporté, mais prévu) et vous obtenez la plateforme idéale de développement Java pour le Cloud (des contraintes de sécurité prévenait initialement tous outils instrumentant du byte-code de fonctionner correctement sur GAE).

Non seulement Il est désormais possible de développer avec une base de données relationnelle mais l'architecture applicative du Cloud reprend point pour point toutes les briques logicielles proposées par un serveur d'application lambda du marché. Concrètement, cela signifie qu'une application JEE ne nécessitera aucun changement pour s'exécuter sur le cloud de Google.

Cloud SQL, déjà largement utilisé au sein de Google achèvera d'ici peu sa phase béta et proposera un vrai modèle économique. La base est aujourd'hui gratuite avec un quota de 10 Go (au passage largement suffisant pour un grand nombre d'applications).

Enfin, cette nouvelle donne côté Java ouvre la porte à de nombreux cas d'utilisation. Il est désormais possible de maitriser ses données et de porter d'un simple click son application du Cloud Amazon à celui de Google (via des Dump MySQL). Compte-tenu de cette nouvelle portabilité inter-Cloud, les clients vont enfin pouvoir choisir le modèle économique le plus adapté sans avoir à remettre en cause leur architecture applicative.

Pour vous prouver que tout cela est possible dès à présent, nous vous offrons le code source complet de l'application DNGCloudSQL. Cette application est hébergée gratuitement sur AppEngine et fonctionne avec GWT 2.4, GXT 3.0 beta2, Spring 3.1, JPA 2, Hibernate 3.6 et MySQL 5.5. La démo est disponible ici => http://dngcloudsql.appspot.com/ et le code source ici => http://bit.ly/z7JX2W.

Amusez-vous bien !

Sami

ps1 : il vous faudra au préalable créer un compte Google Cloud SQL => https://developers.google.com/cloud-sql/docs/before_you_begin#enroll

ps2: il vous faudra également utiliser le plugin GPE pour Eclipse avec le dernier SDK 1.6.X et paramétrer le tout avec votre compte AppEngine

ps3 : ne vous fiez pas aux performances de l'application en ligne lors du première accès, les VM GAE sont parfois en hibernation ce qui engendre un temps de cold start. Le second appel en revanche doit être rapide.

Certains le savent bien, pendant les cinq dernières années, j'ai préféré décliner la plupart des invitations à des conférences publiques en tant que speaker pour me concentrer sur les activités de DNG Consulting. Depuis 2007 et les rencontres GWT animées avec Didier, je n'ai quasiment pas approché une scène (sauf en petit comité). Un expert, quel qu'il soit, ne vit et sévit qu'au travers de la réalité du terrain, il se nourrit des projets, des clients et construit son savoir faire sur les expériences concrètes du quotidien. Autrement, son discours s’effrite et il finit par boucler. Après plus de 5 ans de projets, il est temps de montrer au plus grand nombre cette partie de mon activité. Pour mettre en lumière la formidable équipe qui m'accompagne mais aussi et surtout les formidables technologies qui bercent notre quotidien depuis 2007. Devoxx France sera un bel événement, incontournable en ce début d'année. Sans trahir de secret (je préfère laisser la primeur à l'équipe Devoxx d'annoncer le contenu précis de la session), vous devriez être ravi si vous aimez Java (EJB 3 et JPA), .NET, GWT, REst, le Push Web et l'optimisation des performances d'une application Web. Je présenterai à Devoxx France le projet Cobra. Un cas concret d'innovation technologique. En espérant vous y voir nombreux. Sami