Google Buzz est en fait plus similaire au service FriendFeed, car vos amis peuvent noter s’ils aiment une de vos remarques, un de vos messages. Il existe dès maintenant une API Google ce qui permettra de créer rapidement des applications intégrées à votre bureau comme Tweetie, ou des clients pour téléphones mobiles.

Comme expliqué sur le blog de Google, ce nouvel outil est une fonction supplémentaire intégrée à GMail. Vos contacts GMail deviennent automatiquement vos « followers ». Contrairement à Twitter, il n’est pas possible de souscrire à un compte Google Buzz pour le suivre.

Cet outil sera un sérieux concurrent à Google Wave pour les micro-discussions, les échanges type forum, que l’on voit sur Google Wave. C’est très similaire à une discussion lancée par une remarque de quelqu’un finalement.

Parmies les limitationes, Google Buzz ne marche pas avec les comptes Google GMail pour l’entreprise, intégré à Google Application. Par contre, vous pouvez dépasser les 140 caractères par message, ce qui montre aussi que l’usage visé est différent de Twitter.

Donc, non, Google Buzz ne sera pas un tueur de Twitter.

Pour aller plus loin:
Annonce officielle de Google
API Google Buzz

Cette deuxième journée Devoxx Université débute par 3 heures sur Google App Engine. En fait cette présentation était une revue de code d’un projet développé sur Google App Engine par Sam Brodkin et Scott Stevenson. Nous avons parcouru le code, tout en regardant le résultat de l’application développée en temps réel. A noter que la session a été très participative. L’ensemble de la salle a navigué sur le site, ce qui était plutôt vivant.

L’application SwagSwap
Scott débute la présentation en expliquant le but de son application, SwagSwap. Tout d’abord un Swag, c’est un de ces petits cadeaux que l’on vous offre lors des conférences. Tee-shirt, stylo, autocollant, poster, bref tous les goodies qui font le bonheur des Geeks. L’objectif de l’application SwagSwap est de permettre à chacun de lister les goodies de la conférence, puis de noter et de commenter les cadeaux offerts pas les sponsors. L’application est en ligne à l’adresse http://swagswap.appspot.com sur Google App Engine. Sujet plutôt sympa pour débuter la journée.

Un slide me fait sourire, où Scott littéralement propose à l’audience 5 niveaux de participation :
- Faire le Zombie : vous restez assis là pendant 3 heures sans rien faire
- Bug Patrol : vous recherchez et vous loguez les bugs trouvés dans SwagSwap sur le site Google Code du projet
- Lurker : vous téléchargez le code, vous le regardez mais vous n’y contribuez pas
- Inquisitor : vous posez des questions de manière interactive ou via le site Google Moderator qu’ils ont mis en place
- Contributor : vous ajoutez une nouvelle fonction ou vous fixez un bug pendant les 3 heures.

Scott commence ensuite sa démonstration de SwagSwap. L’interface sommaire à la Web 1.0 est développée dans la version qu’il sélectionne avec Spring MVC. En fait, Sam Brodkin a codé une version Spring MVC, une version GWT. Scott Stevenson a codé une version JSF2. La suite de la présentation sera largement consacrée à une comparaison pointue des 3 solutions, ce qui est plutôt intéressant pour nous.

Quelques mots sur Google App Engine
A moins d’avoir fait un stage chez les Mormons, vous ne pouvez pas me dire que vous n’avez pas entendu parler de Google App Engine. En quelques mots, c’est la solution PaaS (Platform as a Service) de Google pour faire tourner dans le Cloud une application Web Java. GAE (Google App Engine) utilise Jetty, et permet de faire tourner avec quelques limitations, une application java. Les avantages de la solution : plus besoin d’installer une infrastructure, même plus besoin de s’amuser avec des images comme avec Amazon EC2 (voir mon article de lundi). Google monte en puissance pour vous, de manière transparente. Vous ne payez que l’usage réel. Et chose très intéressante, Google ne vous fait payer le service que lorsque vous dépassez un seuil d’utilisation des ressources. Il est donc possible de démarrer un projet sur GAE et de ne rien payer.
Google App Engine propose une console d’administration Web qui permet de suivre la consommation de son serveur. Il est aussi possible de voir les Entités de son domaine, de régler quelques paramètres de son application.

Il y a cependant quelques limitations qui font qu’il sera peut-être impossible pour vous d’utiliser GAE. Tout d’abord le temps d’une requête Web est limité à 30 secondes. Au delà, Google coupe la connexion. Il n’est pas possible de faire tourner vous-même des tâches de fonds, ni des Threads sur le serveur. Vous n’avez en fait jamais accès à une machine, vous vous contentez de déposer votre WAR avec les outils de Google, c’est tout. Donc pas d’installation de logiciels possibles. Il n’y a pas de serveur Push, le système de fichier est considéré comme étant en lecture seul. Il n’est donc pas possible de sauver un fichier temporaire. Pour envoyer une image vers le serveur, il faut donc ruser et travailler en mémoire avant de stocker l’image. Enfin le point le plus important : vous n’avez pas accès à toutes les classes Java. Google donne une liste blanche des APIs autorisés. Par exemple il n’y a pas d’API Swing, donc il est impossible de retravailler des images sur le serveur. Pour la démo de SwagSwap, ils ont donc utilisé un service de Google pour créer des Thumbmails sur la page d’accueil. Bref tout ceci pour vous dire qu’il y a quelques sacrifices à faire pour que tout fonctionne.

Le développeur travaille en local avec une émulation de Google App Engine. Des plugins pour IDEA IntelliJ et Eclipse permettent de packager et d’envoyer vers GAE votre archive, lorsque vous souhaitez faire une mise en production.

La base de données
Les données sont stockées avec BigTable. Le DataStore de GAE est un moteur basé sur un noyau hautement distribué, capable de monter en charge, transactionnel et sans schéma. En fait, BigTable c’est une énorme Hashtable dans le Cloud. GAE supporte JDO et JPA, mais les démonstrations ont été écrite avec JDO, qui semble mieux documenté d’après les speakers.

L’application de base
Le coeur de la partie Service est implémenté avec Spring 3.0, JDO, les transactions et un peu de RESTful avec Spring Web MVC. Ensuite, 3 GUIs différents ont été implémenté. La version Spring MVC a demandé 3 jours de travail. C’est une application Web 1.0 plutôt bien écrite de ce que j’ai vu. La version GWT 1.7 a demandé entre 3 et 4 semaines d’efforts. Il y a cependant un gros travail sur l’ergonomie. Sam a utilisé SmartGWT pour créer une interface plutôt sympathique. Enfin la version JSF2 a demandé 5 semaines, et toutes les fonctions n’ont pas été implémentées. Il a encore peu de projet avec JSF2 sur GAE, donc Scott a pas mal travaillé. Mais le résultat est sympa.

Pour compiler et déployer le projet, ils ont utilisé Ant. Le support de Maven2 et de GAE d’après eux, ce n’est pas encore cela. Concernant la gestion du code source et les tickets d’incident, le tout est sur Google Code.

La sécurité
Les utilisateurs sont authentifés avec les services de Google. Le code est très simple, et il est facile d’appeler les services de Google. Pour protéger les pages, Spring MVC et les filters permettent de déclarer les URLs qui demanderont de l’authentification. L’application a aussi un objet SwagUser avec par exemple les votes et vos commentaires. Cet objet est créé lorsque l’utilisateur s’authentifie la première fois sur l’application. Il est ensuite simplement rechargé si vous revenez. La clé primaire utilisé n’est pas l’email Google mais le Google Account Name. En fait, Sam a découvert que la version GWT envoyait vers le client la liste des emails des personnes ayant postées un Swag sur le site, plutôt genant.

L’accès aux données
Concernant les données, un tour dans la classe ItemDAO nous montre que le code est plutôt simple. Ils utilisent Spring JDOTemplate, avec un persistenceManager. Les Transactions sont aussi utilisées, mais j’ai vu des méthodes synchronized (comme updateRating). Bizarre.

Un souci de Google App Engine et du modèle de persistence : il n’est pas possible de faire des recherches sur plusieurs Entités à la fois. La recherche sur les champs textes est aussi forcément Case sensitive… Bref si vous voulez ajouter un champ « Search » sur votre application GAE, le mieux est de vous tourner vers un projet comme Compass. Celui-ci se place au dessus de Lucene. Il indexe les entités et permet de faire de la recherche full-text sur des Entités. Très pratique, je m’en suis servi sur http://touilleur.appspot.com (projet non terminé).

Concernant l’authentification, si vous cliquez sur un lien dynamique (GET /view/item?order=toto) et que vous devez passer par la page d’authentification de GAE, la QueryString n’est pas conservée. Il y a un bug sur App Engine (bug 2225) à ce sujet.

Spring MVC
Des 3 frameworks utilisés, c’est le plus simple et le plus pratique. Nous avons passé un bon bout de temps dans le code. Cette partie était trop axée Spring, et plus tellement GAE. Mais bon, si vous ne connaissez pas encore Spring MVC, il faut vous y mettre. Les annotations et la gestion des RequestMapping par exemple, c’est fort.

Google Web Toolkit 1.7
La version GWT est clairement très Web 2.0. Mais ce que j’ai retenu c’est que trop de Web 2.0 c’est plutôt fatiguant. D’un point de vue applicatif, il n’y a pas grand chose de plus. Oui de l’Ajax, ok. Mais j’ai été un peu inquiet de voir la quantité de code pour un résultat qui n’est pas si énorme que cela. De plus avec 1000 fichiers dans cette petite application, je trouve que l’on se rapproche trop de la limite des 3000 fichiers statiques par application Google App Engine. Du côté de GWT, le framework SmartGWT est vraiment propre. Rien à voir avec cette bouse de GWT-Ext qu’un client aux USA veut utiliser…

La gestion des images
L’application vous permet d’uploader vers le serveur une photo du Goodie, afin de l’afficher sur la page d’accueil en vignette, et en grand sur la page détaillée du Swag. Mine de rien, cette partie sur le traitement de l’image, pour GWT, JSF2 ou Spring MVC, représente un gros boulot par rapport à une application classique.

Sam présente tout d’abord le service de Google qui traite les images, les retaille et vous les redonne. Plutôt bien fait je trouve. Comme il n’est pas possible de stocker les images dans un répertoire, il faut écrire une Servlet qui stream le contenu de l’image vers le navigateur. C’est pas top je trouve. Hier la démo d’Amazon avec le service Amazon S3 pour stocker les images m’a semblé bien plus pro que ce que j’ai vu là. Cela donne des URLs super sexy pour récupérer une image dans l’application. Jugez plutôt:

<img src="<c:url value='/springmvc/showimage/${swagitem.imageKey}'/>" /> 

Bien entendu, cela pose aussi des soucis avec le cache du navigateur… Si l’image change, le navigateur ne rafraîchit pas l’image. Il semble qu’il ne soit pas possible de changer les headers HTTP et de faire expirer le cache… Je n’ai pas posé la question.

Qu’est-ce qui marche sur GAE ?
La liste des classes Java est limitée. En conséquence, tout les frameworks Java ne fonctionnent pas sur GAE. Par exemple Grails par défaut déclare un log4j avec un FileAppender… ce qui est interdit sur GAE. Regardez cette page pour vous donner une idée de ce qu’il est vraiment possible de faire sur GAE:
Will it play on Google App Engine ?

JSF2.0
Là j’ai décroché… Ce que j’ai entendu c’est que c’est faisable, mais difficile. Les slides enchaînent les soucis et les limitations, de quoi déprimer. Mais le résultat est plutôt sympa concernant l’interface utilisateur. Le code source dans la partie Java est propre, comparé à la soupe de la version GWT+SmartGWT. Bon si vous voulez voir ce que donne JSF et Google App Engine, le mieux est de télécharger le code du projet et de regarder par vous-même

Autres trucs cités
Scott parle aussi du service d’envoi des emails de Google App Engine. Pratique et simple à utiliser, limité à 1000 mails par jour. Ils effectuent aussi une démonstration de la mise en production sur l’App Engine : simple et clair comme les autres projets Google. Concernant l’asynchronisme, il est possible de configurer des Jobs pour appeler une URL donnée avec une syntaxe à la Cron. Pas du JMS, mais pratique pour envoyer par exemple un email à minuit aux abonnés du site.
Une question sur la gestion des backups : il y a un projet appelé GAE bar http://aralbalkan.com/1784

Conclusion
En sortant de la présentation, j’ai trouvé que la partie Spring du côté service était vraiment intéressante et adapté à Google App Engine. La version GWT+SmartGWT demande quelques efforts de programmation mais semble plutôt bien écrite. La version JSF2 m’a déprimé et me semble encore trop jeune par rapport à l’architecture de GAE pour l’instant.

Google App Engine est très certainement une plate-forme intéressante. Attention cependant à bien se rendre compte que cette plate-forme demande un investissement assez important afin d’apprendre à écrire un modèle de données sans schémas. De nouveaux problèmes apparaissent comme ce cas de la gestion des vignettes du site. Ne pas pouvoir stocker un fichier sur un disque, cela vous force à chercher d’autres solutions.

Nous manquons encore un peu de recul, mais ce projet est un très bon point de départ si vous cherchez un exemple complet d’application sur Google App Engine. J’aurai aimé une version Groovy pour comparer, avec Grails ou Gaelyk par exemple.

Voilà je n’ai pas tout couvert, mais Romain de Xebia était aussi là, et donc le blog de Xebia vous donnera un autre angle sur ce sujet.

Références
Page du projet SwagSwap sur Google Code
Page d’accueil sur Google App Engine de SwagSwap
La version Spring MVC
La version JSF2
La version GWT 1.7

Si le mail n’était pas arrivé un dimanche matin à 00h03, j’aurai bien cru un moment que j’étais une personne très importante pour que l’on me donne un compte… En fait Google a annoncé le 17 juillet dernier que 5800 comptes Google Wave avaient été distribué lors de la conférence Google I/O et qu’au cours de l’été, 20 000 nouveaux comptes seront ouverts. Bref c’est donc une histoire de temps aussi pour vous si vous avez fait la demande.
Premiers arrivés, premiers servis. Je m’étais inscrit quelques heures après l’annonce, grâce à l’information trouvée sur Twitter. Si vous souhaitez faire une demande de compte, rendez-vous sur la page Google Wave.

Bref avant de vous parler de mes premiers pas avec Google Wave, j’en profite pour revenir sur l’USI 2009. Suite à sa présentation des outils Google pour l’entreprise, Didier Girard de SFEIR a proposé d’organiser une présentation de Google Wave avec Guillaume Laforge de SpringSource, chef de projet de Groovy. C’est donc dans une petite salle de 50 personnes que nous avons pu voir Google Wave pour l’une des premières fois en France.

Guillaume Laforge (à gauche) et Didier Girard (à droite) débutent la présentation par une diapo qui explique Google Wave en 140 caractères, à la Twitter. Notez cette idée pour vos prochaines présentations. Si vous n’êtes pas en mesure de résumer votre contenu en un message twitter, vous pouvez encore bosser. Excellente idée de Didier.

J’aime bien aussi l’idée de Didier de se présenter non pas comme un Geek ou un Boss mais comme… un Beek ou un Goss !

Google Wave en quelques mots
Wave est le nouvel outil de communication propulsé par Google qui ressemble à un client de messagerie électronique, auquel des fonctions de messageries instantanées ont été ajoutées. Lorsque vous éditez un message pour répondre, et qu’un autre destinataire est en ligne, vous voyez littéralement l’autre personne « taper » son texte en direct sous vos yeux. C’est donc un mélange de twitter, de client mail et d’IRC/Chat.

Google Wave c’est aussi le concept de Robot qui vient du monde IRC. Ces invités virtuels peuvent être ajoutés à votre conversation. Lorsqu’ils sont présents, le texte que vous tapez est analysé en temps réel afin de l’enrichir et de fournir de nouveaux services. Vous tapez un numéro de téléphone ? Un robot le reconnaît et ajoute une URL skype pour appeler le numéro. Vous tapez une adresse ? Un lien vers Google Maps est ajouté automatiquement.

Il est possible aussi d’ajouter des robots capables de traduire à la volée votre texte. Dans la vidéo de la démonstration, on voit un francophone écrire un texte en français, et celui-ci est traduit en anglais à la volée. Il est donc possible d’imaginer de nouveaux outils, qui seront eux-même hébergé sur Google App Engine, la plateforme de Cloud Computing de Google.

Didier Girard a implémenté un Robot capable de reconnaître un tag SMS. Lors de la démonstration, il tape « SMS:0600112233 ceci est un test », et quelques instants plus tard un message est affiché sur son téléphone portable. Un robot écoute la « Wave » et a reconnu le mot clé « SMS: ». Après avoir extrait le numéro de téléphone, il se charge d’envoyer un vrai SMS au téléphone de Didier. La démonstration va plus loin puisque nous avons tous participé en envoyant un SMS qui s’est affiché… dans la Wave !

A quoi pourra servir Google Wave ?
Après la démonstration, je discute un peu avec Didier. Nous sommes d’accord pour dire que nous venons de voir « quelque chose » mais qu’il est encore tôt pour se rendre compte de la portée de ce nouvel outil de communication. Quelque part j’essaye de me souvenir de la première fois que j’ai utilisé un client de messagerie en 94 à l’Ecole… De la première fois où j’ai envoyé un SMS à un ami, où j’ai commencé à Twitter… On ne se rend pas alors très bien compte si ce que l’on fait fera parti de notre quotidien dans quelques mois ou non.

Je me souviens aussi de projets comme ICQ en 97, que vous connaissez peut-être. Mais qui se souvient en 1996 du projet Marimba, fondé par Kim Polese une ancienne dirigeante de SUN Microsystems ? A l’époque c’était THE application. Le principe consistait à pousser de l’information vers le client, un peu comme nos Widgets de météo et d’information sur Mac. Racheté par BMC Software en 2004, le produit n’existe plus… Kim Polese était la responsable produit de Java chez SUN en 1996… Je m’en souviens car j’ai travaillé avec SUN France à cet époque et que Marimba était le truc à la mode.

Alors à quoi pourra bien servir Google Wave ?
J’imagine de vrais usages, comme lorsque répondez pour la 6e fois dans un email, et que votre email ressemble à une conversation de Chat et que vous perdez un temps précieux avec vos correspondants. J’imagine aussi ce nouveau système de réunion, à la fois tableau blanc interactif, document partagé mais aussi plus proche du courrier électronique…

De mon côté j’essayerai bien d’écrire un Robot pour Wave. Mon Geek Day Robot vous proposerait de vous tenir informé des prochaines soirées de Geek, de vous dire qui viendra et de vous donner quelques informations. Là expliqué comme cela, je sens pas un grand enthousiasme. Mais pas de soucis, je vous montrerai cela dès que possible.

L’interface de Google Wave
Comme vous pouvez le constater sur cette capture d’écran, c’est relativement simple :

La zone de Navigation sur la gauche rappelle un client de messagerie électronique classique. La zone Contact permet en bas à gauche de retrouver vos amis. La zone centrale marquée « By Me » sur la capture d’écran, est la zone qui liste les différentes Waves. A droite enfin, le contenu de ces fameuses Wave. Par rapport à un email classique, les correspondants/contributeurs de la Wave sont listés en haut. Les Robots lorsqu’ils sont invités par le créateur de la Wave, apparaissent en haut.

Bon alors, raconte…
Quelques minutes après m’être authentifié, je commence par lire les messages dans les plus grosses Waves. Mes premiers pas me font penser à un Wiki qui serait mis à jour sous mes yeux. Je vois ainsi un utilisateur entrain de compléter un des articles. Chacun de ses caractères, presque la vitesse à laquelle il tape, c’est assez bluffant. Google Docs propose un système similaire mais croyez-moi, il y a une différence entre les deux. J’y reviens après vous avoir laissé admirer une autre capture d’écran :

Une Wave c’est donc un document partagé avec l’enregistrement de la conversation des différents contributeurs du document. Une ligne de temps avec des commandes « avance rapide », « retour au début » permet de rejouer la Wave et de voir l’avancement des discussions entre les membres de la conversation. Ou comment rejouer de l’instantané… Imaginez un instant l’espace de stockage et la puissance nécessaire pour réaliser ce boulot, qui n’a rien d’exceptionnel, à part le fait que… personne d’autres ne pourrait le faire.

Google s’appuie sur sa plateforme de Cloud Computing afin d’ajuster la quantité de puissance (et d’énergie électrique un jour) pour que le système fonctionne correctement. Chacun de vos caractères est envoyé au serveur, qui peut ainsi retourner aux autres contributeurs vos messages. Et l’édition à plusieurs fonctionne même très bien, bien mieux que sur Google Spreadsheets.

Techniquement, Google Wave c’est du GWT du côté client ce qui rassure tout le monde quant à la pérennité de GWT. Cette fois-ci c’est bon, GWT est la technologie de rendu avec HTML 5 de Google. Côté serveur, une API permettra aussi d’intégrer ses propres Waves dans son site. Dès demain, nous pourrons donc avec une Wave attachée à mes billets sur le Touilleur Express, et chacun de vous pourra alors voir les autres lecteurs et discuter en temps réel à propos de l’article… « Hé tu as vu comment il raconte encore n’importe quoi ? Waaah il est trop fort ce nicolas, je vais appeler mon chien Touilleur Express en hommage ! Tu sais que depuis que je lis le Touilleur Express j’ai les cheveux qui repoussent ? « .

Notez que je ne vous encourage pas à dire n’importe quoi… Comme toujours je suis très sérieux…

Bon c’est pas tout, mais j’ai un joujou avec lequel m’amuser alors je vous laisse.

Y’a la zone de commentaires froide en dessous où tu peux laisser un commentaire si tu veux.

Références
- Je vous recommande l’article de François Goldgewicht qui présente Wave en quelques mots.
- Faire une demande pour un compte Google Wave
- La page de démarrage de Google Wave SandBox, une fois que votre compte est actif
- L’article de Didier Girard sur Application-Servers.com

http://francois.goldgewicht.com/2009/06/03/google-wave-en-quelques-mots/

Google App Engine est une plate-forme de Cloud Computing qui permet de déployer facilement une application Web Java. Voici comment cela fonctionne : vous codez votre application Java en local, vous la télechargez ensuite vers le serveur de Google, puis quelques instants plus tard votre application est déployée.

L’intérêt et la force de la solution de Cloud Computing de Google est d’offrir un serveur très puissant, dont la capacité en CPU, en mémoire, en bande passante, s‘ajuste automatiquement à l’usage, aux nombres de visiteurs. La différence avec un serveur classique sous Unix comme celui sur lequel j’héberge le blog, c’est la virtualisation totale du serveur. Chez l’hébergeur du blog le Touilleur Express, j’utilise déjà une solution de virtualisation, qui me permet de rajouter ou de retirer des CPUs ou de la bande passante. Cependant c’est à moi de régler cette capacité. Or au début je n’avais aucunes idées du nombre de processeurs nécessaires… J’ai payé pour rien jusqu’à trouver les bons réglages. Et encore, c’est empirique, il n’y a pas de console m’indiquant le taux d’usage de ma machine.
Avec la solution de Google App Engine, s’offre à vous un portail Web d’administration qui vous affiche l’utilisation de votre application. Par défaut, gae (Google App Engine) est gratuit. Si vous savez écrire une application Web simple en Java, vous pouvez donc vous inscrire et tester en quelques heures.

CanadaDry, CanadaGrails
Bref me voilà il y a quelques temps devant mon éditeur favori, IDEA IntelliJ, avec une idée de développement histoire de me faire la main. Je décide de tester Grails, un framework en Groovy qui permet d’écrire très rapidement une application. Une fois Grails installé, je récupère ensuite le plugin pour Google AppEngine afin de commencer à créer ma première application. Je décide de tester la version JDO, car après avoir vu la doc de DataNucleus, j’ai le sentiment que JPA est encore un peu trop neuf.
Si vous n’avez pas encore testé Grails, prenez 15 minutes pour suivre le Quick-Start puis ensuite lisez attentivement les différentes pages sur le plugin Google App Engine.
J’ai été vraiment emballé de pouvoir faire une application type Crud en quelques minutes. Ensuite je suis quelqu’un de curieux. Alors j’ai garé la voiture « Grails » sur le côté de la route et j’ai commencé à regarder le moteur. Premier besoin : je veux changer une des vues pour afficher un datePicker au lieu d’un champ date. Je teste avec un autre plugin d’interface utilisateur… pas très emballé. Grails vient avec un moteur de plugin qui permet d’ajouter et de retirer des fonctionnalités rapidement. Le souci est qu’il est plus difficile de trouver la raison d’une erreur, et que pour valider vos changements vous déployez beaucoup plus, par peur que ce que vous venez de faire ne marche pas.

Je rencontre ensuite un souci de namespace. Voici la solution que vous devrez aussi faire :
Message d’erreur:
Cannot find the declaration of element ‘datastore-indexes’.
Solution:
Editer le fichier $APP_HOME/target/war/WEB-INF/datastore-indexes.xml et effacer le namespace de la première ligne :
xmlns= »http://appengine.google.com/ns/datastore-indexes/1.0″

Le déploiement vers l’appengine est relativement facile, il faut simplement utiliser l’utilitaire appCfg.sh de GAE la première fois afin de spécifier son mot de passe Google. Par la suite, le plugin de Grails est capable de déployer l’application.

Jusqu’ici tout va bien.

Difficultés rencontrées
J’ai eu du mal avec Groovy et Grails. Malgré le support d’IDEA IntelliJ de Groovy, j’ai pas mal de soucis avec le côté dynamique du langage. Bref je patauge pas mal et dès la première difficulté, je peste.
Un langage dynamique, cela entraîne en fait pas mal de phase de redéploiement pour s’assurer que tout fonctionne. Je trouve un peu poussif les performances, quoique cela soit purement subjectif. Je parle de Grails + plugin Google App Engine.

Ensuite j’ai trouvé que la promesse de l’écriture rapide était bien remplie. Un create entity, un update view, oui Grails est vraiment bien fait, bravo à l’équipe de Grails. Mais la perte de certains repères, du typage fort, représente une difficulté à ne pas négliger.

Spring MVC et SpringFuse
Un peu inquiet de ne pas avancer aussi vite que cela avec Grails, je recrée un nouveau projet Java afin de tester du simple code Java.
C’est ensuite en mettant en place Spring MVC que j’ai l’idée de reprendre un projet généré avec SpringFuse. Et hop, en quelques heures j’ai transformé mon application en projet full-Java, quelques JSPs, deux controllers, un peu de JDO pour Google App Engine, bref j’avance beaucoup plus vite. Paradoxal non ? C’est grâce au code de SpringFuse, à la fois simple et en même temps bien documenté. J’ai viré pas mal de trucs pour le faire passer sur GAE, mais rien de bien difficile. J’attends le support de JPA prévu pour bientôt. Sinon Spring MVC 2.5 marche très bien sur Google App Engine, qu’on se le dise. Je n’ai pas utilisé les annotations, ni les transactions par contre.

Premier bilan
Lorsque l’on bosse seul sur son projet dans son garage, et que l’on vise une application massivement Web, paradoxalement je pense que l’on va plus vite en n’écrivant que ce qui est nécessaire.
Grails vaut vraiment le coup d’être testé. Le plugin GAE n’est pas encore parfait, et il sera plus difficile de trouver de l’aide sur Google en cas de plantage. Soit vous êtes un aventurier, soit vous êtes plutôt conservateur. A vous de voir.
Je ne parle pas sinon des tests pourtant intéressant de GTPL, une idée vraiment intéressante qui permet d’écrire des templates de page en Groovy. Cela mérite un article plus complet.

Suite des aventures dans le prochain numéro.
Nom de code du projet : GeekDay

Dans la première partie de la soirée Maxime TIRAN de Google France nous présente la démarche de Google. Le navigateur est le client du futur, l’effort d’un navigateur comme Chrome est de proposer un outil puissant, afin de pouvoir proposer de nouveaux services. Les dernières technologies Webs comme HTML5 basées sur des standards ouverts visent à rattraper Flash, Java FX et Silverlight. Google se positionne aussi sur l’objectif de faciliter l’accès aux données et d’offrir un socle de Partage. Maxime mentionne le projet Shindig hébergé par Apache, un conteneur OpenSocial qui est une implémentation de l’API OpenSocial. Google souhaite proposer à la communauté des développeurs des présentations, comme cela se fait aux Etats-Unis, afin de prendre en compte votre point de vue. Il rappelle que les projets sur code.google.com sont suivis par les équipes en interne chez Google.

Dans la deuxième partie de la présentation, Didier Girard de SFEIR nous propose une présentation des nouveautés de cette version d’AppEngine. Didier explique en quelques mots le principe du Cloud-Computing et les 3 types de service. Il y a tout d’abord le cloud computing physique, où l’infrastructure est un service (IaaS). C’est l’hébergement classique comme chez Gandi.net qui vous permet de rajouter du CPU ou de la mémoire sur votre serveur. Vient ensuite l’hébergement de services, comme Salesforce.com. Le principe est d’hébergé à l’extérieur un service comme la gestion client (CRM) ou vos emails (Google Mail). Enfin, et c’est le principe d’AppEngine, l’hébergement de type plateforme (Plateform As A Service). Google AppEngine est un serveur d’application qui vous permet de faire tourner des applications écrites en python (depuis un an) ou en Java/Groovy (depuis mercredi dernier).
Ses équipes ont développé deux applications qu’il nous montrera ensuite plus tard dans la soirée. Il a eu en effet la possibilité de tester il y a plus de deux mois, les premières versions bétâ du support de Java, avant l’ouverture aux développeurs.

Un exemple d’application hébergée sur Google AppEngine assez célèbre : http://www.whitehouse.gov/openforquestions/. Oui il s’agit bien de la maison blanche de Barack Obama. Il s’agit d’une application développée à l’occasion d’une séance de questions ouvertes posées par les Internautes. La plate-forme de Google a permis d’offrir des performances le soir de l’événement assez importante. Il y a aussi d’ailleurs du GWT. C’est une application en Python.

Les 5 nouveautés de cette nouvelle version de Google AppEngine sont :
1) La possibilité d’acheter de la puissance supplémentaire
2) Le support de tâches type cron déclenchées par une URL
3) Support d’une base de données type BigTable
4) L’accès à travers votre firewall à vos applications d’entreprise (SDC)
5) Early look at Java Support -> premier regard au support de Java

Concernant le point 1 : l’offre est gratuite jusqu’à 5 millions de pages vues par mois. Autant dire, on a le temps de voir venir. Je n’ai aucuns détails sur le pricing, nada, rien. Impossible de comparer avec Amazon EC2. Les offres ne sont de toutes les façons pas comparables.

Le support des tâches de type cron : il suffit de placer un fichier XML spécial dans son WEB-INF, avec une URL et une syntaxe type Cron. Au déploiement, le moteur de Google AppEngine voit que vous souhaitez qu’il appelle l’url /mail/sendMailingList.do par exemple… Bref il faut que votre service soit exposé sous la forme d’une URL. Nada sur la sécurité… je pense cependant qu’il est faisable de protéger cette url. Peut-on ne pas la déclarer dans le web.xml ? non. Je dois creuser ce sujet.

Concernant le support du stockage de données, Didier nous a montré sur une petite application le principe de l’utilisation de JDO. Basé sur DataNucleus, un projet en license Apache v2, le support JDO permet de vraiment écrire du code portable. C’est plutôt une bonne nouvelle. Plus de détails sur cette page.

Vient ensuite un sujet intéressant. Si je code demain une application pour mon client, et que je la déploie sur Google AppEngine, se pose alors le problème de l’accès aux donnés du SI. Google propose le Secure Data Connector (SDC).

SDC est un logiciel client déployé de l’autre côté de votre firewall qui communique via HTTPS avec la plate-forme Google AppEngine. Ce système permet de construire un pont entre le SI de l’entreprise et le monde de Google. Du coté de votre SI, il faut que vos services soient exposés sous la forme d’URL. J’ai donc compris qu’il faut que votre système d’information s’expose sous forme d’url HTTP, avec une architecture de type REST. Je vois déjà les administrateurs de sécurité avec un lance-roquette sur l’épaule… C’est pas gagné, même si la solution d’un point de vue technique est bonne.
Le code du client SDC est libre, open-source. Tout le monde peut le regarder, ce qui permet aussi à tout le monde de trouver des failles de sécurité. Ce sera bien entendu le point le plus sensible, même s’il n’y a pas d’autres solutions pour l’instant.

Enfin pour le 5ème point, le support de Java et de Groovy. J’ai discuté ensuite avec Guillaume Laforge, qui m’a expliqué le travail réalisé avec les équipes de Google, situées à Atlanta. Avec l’aide des équipes de Google AppEngine, les développeurs de Groovy ont adapté la dernière version afin qu’elle fonctionne sur l’AppEngine. La difficulté, comme Guillaume l’explique, c’est que Groovy étant un langage dynamique, il a besoin de certains droits avec le SecurityManager afin d’instrumenter le code. Par contre il semble que le support de Grails ne sera pas possible, vu la complexité et les efforts à fournir. Je pense que Guillaume pourra expliquer mieux que moi les détails techniques.

Didier a ensuite fait plusieurs démonstrations. Google AppEngine vous propose un plugin pour Eclipse, afin de démarrer rapidement l’écriture de sa première application. Je pense à Maven2 dans ma tête quand Nicolas de Loof précise qu’un plugin pour l’appEngine est dans son sac à dos et devrait être disponible d’ici quelques jours. Nicolas propose un petit plugin maven afin de faciliter le déploiement d’une application à partir de maven. Allez sur son blog, hop, et revenez après j’ai pas terminé.

J’ai vu que les équipes de SFEIR ont sacrément bossé sur un moteur de Blog écrit en Java, hébergé sur Google AppEngine. L’idée est de basculer les blogs de SFEIR vers cette plateforme si j’ai bien compris. Le projet est open-source, à quand un Touilleur Express sur l’AppEngine ? Si j’avais un peu de temps, mais pour l’instant je préfère attendre encore un peu. Peut-être d’ici 6 mois.

Est-ce que Google AppEngine est pour vous ?
Oui définitivement si votre service Web doit gérer une charge fluctuante de visites, si vous avez développé un Gadget pour Facebook ou une application Open-Social par exemple. C’est un moyen de déployer sur une grosse machine énorme votre application, sans vous soucier de devoir réinstaller un jour votre machine. Vous n’aurez plus à gérer la sécurité, la mise à jour, les patches, les sauvegardes… Zéro administration système.

J’ai pour l’instant un peu de mal à imaginer une application d’entreprise type extranet, ou une application CRM. Comment s’interfacer avec un Siebel ou un SAP ? Nous avons ce connecteur SDC pour connecter notre SI à Google AppEngine. Mais avouez que pour convaincre l’équipe sécurité… C’est pas gagné.

Les services Google
La plateforme AppEngine offre des services tels que l’authentification ou l’envoi des emails. La page « Services API » donne la liste des services que nous pouvons utiliser dans nos applications Java déployées sur Google AppEngine:

* Memcache est un cache mémoire simple et partagé
* URL Fetch permet d’utilser java.net.URLConnection pour parler avec d’autres applications, HTTP et HTTPS
* Mail permet d’envoyer des emails avec l’api Java Mail
* Images est un service pour manipuler des photos ou des images : retailler, améliorer, agrandir, basculer etc.
* Google Accounts permet d’authentifier les utilisateurs avec le système de Google. Cela vous décharge de la gestion des users, des mots de passes.

Il y a un énorme écosystème autour de Google : Calendar, Blogs, News, Recherche, Traduction, Paiement, Photos… j’attends maintenant que Google nous offre des services plus intégrés. Certes nous pouvons tous prendre la doc de chacune de ces APIs puis commencer à coder. Mais rêvons un peu, et imaginons un peu de code qui permet de prendre rendez-vous chez votre Coiffeur en prépayant par carte bleu votre séance…

public class TouilleurHairCutServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
                                        throws IOException {

          GoogleCalendarService calendarService = GoogleRepository.getCalendarService(); 

          Rendezvous rd=RendezvousHelper.fetch(req);

          calendarService.createEvent(rd.getDate(),rd.getSubject());

           //........

          GoogleCheckOutService checkoutService=GoogleRepository.getCheckoutService();
          try{
                checkoutService.bill(req);
          }catch(GoogleCheckoutServiceException e) {
                // cancel event in calendar and say bye
                .....
          } 

         // Send an email with Google Calendar event, Google Map for address...
         ...
         ...

        // Fin
          resp.setContentType("text/plain");
          resp.getWriter().println("Votre rendez-vous est confirmé et payé... ");

    }
}

Rêvons un peu… une application Web où vous pourriez consommer facilement différents services Google. Je pense plus particulièrement à tout ce qui est OpenSocial afin de créer des gadgets pour HiFive, Salesforce.com, LinkedIn.com ou MySpaces…

J’écris ce code (bien timbré il faut le reconnaître) et je repense à ce que disait Nicolas : où est Google Guice ? A priori rien ne nous empêche d’utiliser Guice, Spring ou autre. Il y a cependant un dernier point, et après je vous laisse : toutes les APIs de Java ne sont pas supportées. Et bien oui… pas possible de créer une Thread ou de vous balader sur le filesystem… qui n’existe pas au sens classique. Il va donc y avoir un sacré effort pour lister les frameworks supportés et ceux non supportés, ce qui va alimenter la blogoshpère rapidement. C’est donc un facteur important à prendre en compte : tout n’est pas supporté, car comme toute application hébergé sur une plateforme de type PaaS, vous êtes sur un système virtuel. Oubliez l’idée de créer des fichiers plats, des sockets. Utilisez URL Fetch ou BigTable. Il y a un sujet d’architecture intéressant.

Si j’étais didier, je profiterai bien de l’USI pour parler un peu du type d’application que l’on peut faire avec Google AppEngine.

Merci à Google et à SFEIR pour l’organisation de la soirée, et à bientôt.

J’ai entendu sur The Java Posse que Google avait ajouté à la fonction Google Spreadsheets la possibilité de créer des PivotTables. Google Docs intègre un module développé par de la société Panorama dans Google Spreadsheets. Mes premiers tests avec Safari et Firefox ne sont pas très concluants car l’interface est en partie traduite en français. Il manque quelques icônes. Mais c’est assez prometteur.





Pour tester, voir le tutorial en anglais.

Parmis les liens les plus sympas à regarder, la liste des recherches les plus populaires sur Google par pays et par mois. On appelle cela Zeitgeist. Les Francophones sont plutôt branchés Noël, Darty, Nintendo WII et SFR en décembre. Ouf on a évité « Paris Hilton nude » et autres blondes à petite poitrine (la fameuse paris précedemment citée).

Pour terminer sur des histories de belle courbe, en voici une qui en dit long et qui fait réflechir. D’après cette courbe la societé Google emploie 10670 employés dans le monde au 31 décembre 2006. La societé Reuters fondée en 1870 emploie environ 13500 personnes dans le monde…

Peut-être qu’un jour Google s’offrira un groupe comme Reuters. Après tout, nous avons plus de bureaux dans chaque pays qu’il n’y a de pays à l’ONU… Google couvrirait alors toute la Terre, Google everywhere… Je l’aurai mon teeshirt Google, je l’aurai…