Au printemps dernier j’ai proposé à des collègues de “jouer” avec Google App Engine for Java en développant une application pour gérer l’inscription au BreizhJug. Comme beaucoup nous utilisons JugEvents et comme beaucoup nous trouvons cette appli très moche, sans parler de ses plantages réguliers.
Nous sommes partis sur un truc bien trop gros pour nos petites épaules et ça a donc fait plouf en moins de deux.
La conférence de Didier Girard m’a donné envie de repartir sur ce développement, en utilisant une approche plus pragmatique et plus économique :
Les soirées BreizhJUG sont déclarées dans un Google Calendar public. Lieu, date et sujet y sont indiquées, la description servant à définir le(s) speaker(s) – première ligne – et le sujet du jour. L’intérêt ? L’appli Juggers n’a plus à gérer la saisie des événements et les droits d’accès !
L’application utilise gwt-gdata pour accéder à ce Calendar, et récupère donc une liste d’objets structurés, de manière (presque) aussi simple qu’un appel GWT-RPC.
L’inscription elle même n’est pas développée, peut être dans un premier temps sur la base d’une simple Google Form. L’idée est de progresser par tout petits pas, histoire de ne pas finir le bec dans l’eau.
J’en profite pour expérimenter uiBinder, et comme je commence tout juste un projet Wicket je ne peux pas m’empêcher de faire un parallèle : uibinder c’est la facilité de Wicket + la force de GWT, de la bombe atomique ! J’ai ainsi maquetté un widget sympa en HTML/CSS, et je peux le convertir rapidement en widget GWT utilisable partout.
L'appli est également rendue plus sexy grâce à gwt-Fx, en quelque sorte un portage de scriptaculous en GWT (pas juste un wrapper). La dernière version est vraiment bien et très souple d’utilisation.
Vous voulez-voir ce que ça donne ? http://www.juggers.org/ – attention, ce n’est ni une béta ni même une alpha, c’est un early prototype snapshot ;)
NB : ne cherchez pas, ça rend rien de bon sous Internet Explorer. Qui aurait l’idée d’utiliser ce truc de toute façon ?
Google organisait jeudi en fin d’après midi une soirée pour présenter son AppEngine en version Java à la communauté et récolter un premier feedback. Didier Girard était de la partie, décidément toujours sur les bons coups :)
L'annonce, c'est bien sur Google App Engine for Java + GWT 1.6 + un plugin Eclipse.
Premier point, la plateforme est un pseudo tomcat tournant sur un Java6 « à la sauce Google ». Comprenez que certaines API Java sont blacklistées, soit parce qu’elles n’ont aucun sens sur le « cloud » (java.io.File par exemple), soit pour des questions de sécurité. Il n’est par exemple pas possible de lancer un Thread, et certaines pratiques de réflexion ne sont pas autorisées.
Ces petites limitations ont un gros impact sur les frameworks que nous pouvons utiliser. Guillaume Laforge a fait un gros travail d’analyse sur Groovy pour le rendre compatible (et accompagner ainsi l’annonce très relayée de Google). De nombreux autres frameworks ne sont apparemment pas compatibles. La liste des outils (in)compatibles reste bien sur à construire (je projette d'ailleurs de faire ma première appli AppEngine sur ce sujet).
Autre restriction, la « base de données » de AppEngine n’est autre que BigTable, l’espace de stockage géantissime de Google – et qui n’a rien à voir avec une base relationnelle. DataNucleus (l’ex JPOX) a été choisi pour fournir aux développeurs une approche JDO ou JPA. Bizarrement, c’est la première qui est mise en avant par les wizards et exemples du SDK. JPox était en effet un outil JDO de premier plan, mais la compatibilité JPA n’en est qu’une surcouche. Autre point, déjà JPA a tendance à nous faire faire des choses « pas très bonne au sens relationnel » car on a tendance à oublier trop facilement la base de données qui se cache derrière. Avec BigTable c’est encore pire, car il ne faut pas envisager de passer par des jointures. Autrement-dit, même API qu’en JEE « traditionnel » mais pas mêmes usages et bonnes pratiques !
Pour ceux qui ne veulent (ou peuvent) pas héberger leurs données en dehors de leur SI, Google propose une API « Secured Data Channel », une sorte de trou de souris dans votre Firewall, sécurisée en SSL, et permettant au « cloud » Google d’accéder à vos données. A priori raisonnable, mais ça sent tout de même le hack ;)
Tout ça fait beaucoup de restrictions me direz-vous. Bien sur, pour déployer sur AppEngine une appli « hello world » cela prend deux clics, et l’infrastructure Google peut alors prendre en charge des pics de charge faramineux sans qu’on ait rien eu à prévoir.
Quel est la cible de AppEngine for Java ? Pas les applications JEE, vu l’inconnue sur le bon fonctionnement des frameworks, et surtout pas en l’état vu la nécessité de repenser la persistance des données. Par contre, tout développeur qui fait du JEE au boulot se retrouve en terrain connu pour déployer son appli perso. Et c’est bien la cible de Google : plus d’applications = plus d’utilisateurs du web = plus de revenus. Vous qui n’arrivez pas à vous mettre à PHP, qui ne pipez rien à python, vous allez pouvoir faire votre petite appli Java avec les outils habituels, avec votre API JPA pour stocker des données, avec GWT 1.6 pour faire de supers applis Ajax sans rien y connaître, et publier tout ça sur le Net pour pas un radis. Et si jamais votre site de vente de schewing-gum usagé explose les scores en raison d’un Buzz incontrôlé, l’infrastructure Google tiendra le choc !
Merci à Didier de m'avoir transmit une invitaton pour cette soirée, qui a soulevé de nombreuses questions et beaucoup d'intérêt ;)
Valtech organisait jeudi une journée atelier RIA, une formule originale permettant de comparer sur le terrain Gwt, Flex et SilverLight. Ces trois noms dominent en effet (pour l’instant ?) le monde très actif des Rich Internet Applications.
Petite mise au point pour commencer : une Application Internet Riche n’est pas juste une application web bourrée d'effets visuels. Ce n’est pas non plus une application utilisant Ajax pour en améliorer l’ergonomie ou la réactivité.
Une RIA c’est une application qui a été conçue pour déporter sur le client la couche présentation, tout en conservant sur le serveur des services métier de haut niveau, autant que possible sans état. C’est donc à mis chemin entre le client lourd + serveur de données et le client léger + serveur web de présentation. Le serveur devient alors un conteneur de services métier, ce qui permet de converger avec l'approche SOA.Un exemple parmis d'autres, parleys.com (en version Flex ou Gwt) : le serveur héberge les vidéos et les indexes, toutes la mise en page étant gérée sur le client.
Bien sur, cela s’accompagne souvent d’effets graphiques haut de gamme pour se démarquer des applications web devenues trop statiques. Il faut bien un moyen d'accrocher l'internaute !
Quelle est la difficulté sur ce type d'applications ?
SilverLight est la solution RIA proposée par Microsoft, nécessitant un runtime encore peu répandu, mais qui pourrait rapidement se généraliser via le meilleur outil de promotion : Windows Update ;-)
La présentation SilverLight était assez décevante, trop orientée design pour un public de purs programmeurs, et ne connaissant pas l'outil Blend la première heure a quasiment été perdue. Nous sommes nombreux à en avoir eu une image négative, sans doute fausse par rapport à cette technologie. J’en retiens trois points majeurs :
Flex utilise le runtime Flash 9, déjà installé sur de très nombreux postes.
La présentation Flex était très démonstrative, mettant en avant les capacités graphiques du format Flash. L’environnement FlexBuilder est très appréciable (175€), même si de nombreuses fonctionnalités habituelles en Java manquent (formateur de code, refactoring…). Flex permet de laisser aux graphistes le soin de préparer les objets Flash avec toute la puissance de cet environnement. La programmation nécessite cependant de se familiariser avec ActiveScript, pas infaisable mais pas immédiat non plus. Se pose aussi la question du débogage sur des applications ambitieuses. Flexbuilder est très aboutit et probablement indispensable pour envisager ce type de développement.
Pour ces deux premiers candidats, se pose la question de la disponibilité d’un runtime sur toutes les plateformes, en particulier sur mobiles, marché d’avenir pour ces applications.
GWT est un peu l’intrus dans cette journée. Il se positionne fonctionnellement très en dessous de ses concurrents, sans support pour des effets 3D ou vidéo. Par contre, il est le seul à ne nécessiter aucune installation de runtime.
La présentation GWT était plus une visite guidée d’une application GWT, mettant en évidence les principes clé. Le très gros point fort est le développement 100% Java, qui permet ainsi de coder/tester/deboguer sous Eclipse, par simples « save + refresh », et de bénéficier de l’environnement JDT pour « découvrir » l’API GWT. La programmation GWT est donc assez naturelle pour des développeurs Swing.
J’ai été impressionné par la facilité de construction d’une IHM Flex, et surtout par le très bon niveau de FlexBuilder, qui malgré la filiation du langage ActiveScript avec JavaScript propose un éditeur riche et assez proche de celui d’Eclipse pour Java. Je n’ai pas accroché sur SilverLight, ne serait-ce qu’à cause du langage C# qui m’est peu familier, mais c’est clairement une plateforme avec laquelle il faudra compter. Enfin, GWT a été très bien vendu par Sami ;-). Il reste tout de même un besoin de compétence pour la mise au point des CSS, tout aussi peu homogène au niveau des navigateurs, point qui n'est pas abordé par Gwt - domage.
Mes conclusions ?
