Google s’invite au JUG

 English version available

Avec un peu de retard, voici le compte rendu du dernier JUG nantais. Le sujet abordé est un sujet bien connu, puisqu’il s’agissait, ni plus ni moins, du géant Google. Une fois de plus, la démesure de Google a encore frappé et de surcroît un vendredi soir. En effet, la salle était pleine à craquer, comme le témoigne la photo.

Il faut dire que le succès de Google fascine. En France et dans beaucoup de pays à travers le monde, des millions d’internautes utilisent quotidiennement son moteur de recherche.

Cet article ne fait pas l’apologie de Google, mais présente quelques technologies et savoir-faire qui se cachent sous la « bête », et qui ont contribué à son succès depuis plusieurs années.

Une infrastructure technologique globale singulière

Google concentre sa force sur quelques grands principes.

Tout d’abord, la firme se base sur une architecture orientée ressource (ROA, Resource Oriented Architecture). Concrètement, une ressource correspond à une URL pour y accéder. Si vous êtes un utilisateur de Gmail, vous êtes-vous déjà fait la réflexion qu’un email était identifiable et retrouvable par une adresse unique ? Ce couple URL-ressource est généralisable à l’ensemble des applications Google : un document sous Google docs, une coordonnée sous Google Maps, une image sous Picasa, etc. Voici quelques exemples d’URL.

• http://docs.google.com/Doc?docid=0Ad7BNmFSF7hvZGzYm03dzJfNGhkdeZrbmc0
• https://mail.google.com/mail/#inbox/12537bz86989ed71
• http://picasaweb.google.com/fabian.piau/MonAlbum#5409584261851169554
• http://www.youtube.com/watch?v=LafUQYHSnhU

Google se base sur un standard du Web : HTML 5. Le format est très récent et utilise une multitude de nouvelles balises comme l’intégration native des vidéos, des documents audios, les canevas pour dessiner par scripting ou bien encore la géolocalisation.

De plus, Google ne développe principalement que sur deux langages de programmation : le Java et le Javascript. La technologie est donc bien délimitée pour une plus grande maitrise.

Ensuite, l’infrastructure informatique de Google est éclatée et se base sur le Cloud computing. Vous connaissez très certainement une des utilisations du Cloud computing. La plus connue est sans doute la mise en commun de la puissance de calcul (processeur) de plusieurs ordinateurs éloignés afin de former un super calculateur (par exemple, le logiciel SETI@home utilise ce procédé, plus spécifiquement appelé « Grid computing » , le but est d’analyser la quantité phénoménale de données provenant de l’espace pour, peut-être, y découvrir la présence d’une vie extraterrestre…). On peut généraliser ce partage de ressource à l’ensemble des pièces d’une machine, comme sa mémoire physique.

Ce type de Cloud computing n’est pas le seul qui existe. Il y a deux autres utilisations qui font parties intégrantes de Google. Le PAAS (Platform As A Service) permet de louer un serveur d’application complet pour héberger ses programmes. Il y a aussi le SAAS (Software As A Service) qui permet de louer un logiciel. Les applications Google entrent clairement dans la catégorie SAAS. Par exemple, quand on utilise Google Documents, c’est comme si on loue le logiciel malgré sa gratuité. On a accès à un tableur, un traitement de texte complet, un espace de stockage pour ses documents, le tout depuis le navigateur.

Dernier standard chez Google, les applications (à quelques exceptions près) sont placées sous licence Open-Source. Récemment, la compagnie a dévoilé l’ensemble du code source de son système d’exploitation Chrome OS à la communauté.

AppEngine, l’offre PAAS par Google

Google fait du SAAS, mais aussi du PAAS. Il propose ainsi d’héberger vos applications en vous fournissant tout le matériel nécessaire. L’offre est déclinée en deux versions pour deux langages de programmation : Java et Python.

Pour Java, l’offre est composée de :

• Un conteneur de servlets (Jetty);
• Une base de données de type BigTable (structure hiérarchique, NOSQL);
• Un serveur de mails;
• XMPP (pour la messagerie instantanée);
• Cron (tâches de fond);
• La possibilité d’écrire des tests unitaires (si !);
• Un déploiement en un clic.

Vous pouvez consulter cette page pour avoir plus d’information sur AppEngine.

L’offre est gratuite, mais comporte quelques limitations. Par exemple, il y a des quotas (CPU par jour, nombre de requêtes, nombre de pages vues, espace disque, etc.). Pour un simple particulier, on comprendra que cela sera amplement suffisant. Quoique, d’après l’intervenant, il semblerait que la limitation la plus contraignante serait le quota sur la bande passante qui est rapidement atteint. Quoiqu’il en soit, pour une entreprise, il sera plus judicieux de se tourner vers l’offre payante, qui vous permettra d’augmenter les quotas, mais aussi de choisir votre propre solution de stockage (base de données relationnelle SQL hébergée chez vous par exemple)…

Pour la présentation d’AppEngine, nous avons eu le droit à une petite démonstration de la fameuse application « Hello World ». Rien de très impressionnant, mais cela a l’avantage d’être déployé et disponible sur internet en quelques minutes. La démonstration a été réalisée sous Eclipse en GWT, avec le plug-in Google Eclipse Plugin. Ce plug-in permet notamment de tester l’application en locale sans avoir besoin de la déployer sur le serveur, un indispensable donc.

Si des fournisseurs d’accès internet comme Free vous permettent d’héberger gratuitement vos sites en PHP/SQL, Google va plus loin en vous permettant d’héberger vos programmes Java. Google est un des précurseurs dans ce domaine. Le SAAS/PAAS semble se développer de plus en plus, ainsi d’autres géants informatiques lui emboite le pas, comme un certain Microsoft avec sa plateforme Azure ou encore SpringSource.

GWT, le langage de programmation par Google

Le principe est simple à comprendre, avec GWT, on fait de la RIA (Rich Internet Application, AJAX…) sans avoir besoin de programmer en Javascript.

La création de l’application se fait principalement par glisser/déposer, le code Java/Javascript est généré automatiquement. Bien sûr, c’est toujours à vous de faire le code métier.

C’est un langage qu’on l’on peut qualifier de swing-like, car en regardant de plus près le code généré, on s’aperçoit qu’il est assez similaire à Swing avec des événements, des labels, etc. Avec GWT, on code son interface en Java et le code généré n’est pas très propre (donc peu maintenable) et surtout très lourd (malgré des optimisations).

De plus, la richesse des librairies de la communauté s’oppose à la pauvreté des librairies disponibles par défaut. Ces dernières étant les seules vraiment maintenues par Google. Allez expliquer à un client, qu’on lui a développé une belle application avec pleins de drag & drop et du web 2.0 à tout va, mais que dans 6 mois, les composants ne seront peut-être plus maintenus… Bien sûr, ce risque peut être pris pour des petites applications qui ne sont pas amenées à évoluer dans le temps.

Autre ombre au tableau, par défaut, le développeur n’a pas d’autres choix que de tester son application dans un navigateur web interne à Google (c’est le « hosted mode »). Cela est très contraignant, car vous pouvez dire adieu à vos plug-ins préférés comme Firebug. Heureusement, on peut contourner cette difficulté en utilisant un plug-in dédié par navigateur qui va s’occuper d’émuler le « hosted mode » de Google.

Une contrainte de taille pour GWT : pour lancer une application, l’utilisateur doit obligatoirement télécharger l’application dans sa globalité avant de pouvoir commencer à l’utiliser. Télécharger un mégaoctet pour afficher l’écran de login peut paraitre un peu démesuré…

GWT 2, un GWT 1 sans les inconvénients ?

GWT 1 a quand même des atouts, mais il peut en effrayer plus d’un pour les raisons que j’ai évoqué précédemment. C’est pour cela que Google travaille depuis près d’un an sur la seconde version de son langage.

Pour l’instant disponible à l’état de RC (Release Candidate), l’objectif de GWT 2 est de faire disparaitre tous ces inconvénients. Espérons que le pari sera réussi.

Parmi les évolutions, notons :

• La simplification du code avec l’utilisation d’annotations;
• La possibilité de tester son application avec n’importe quel navigateur;
• Grâce à UIBinder, la gestion du layout sera externalisée dans un fichier XML. La collaboration entre le développeur et le designer sera ainsi grandement facilitée;
• Le chargement différé : l’utilisateur ne télécharge que ce dont il a besoin (code-spliting);
• La prise en charge des tests unitaires.

Android, le mobile par Google

Android a été le dernier sujet traité au cours du JUG, il commençait à se faire tard… Nous avons eu le droit, une fois n’est pas coutume, au développement d’un « Hello World » sur la plateforme mobile Android.

Les applications sont en Java, il y a un SDK spécial pour Android.

Concrètement, on développe son programme sous Eclipse. Pour exécuter et tester son programme, on peut émuler un téléphone à l’aide d’un plug-in Eclipse.

Ensuite, si le programme convient, on peut le mettre sur son portable, ou bien encore le mettre en ligne sur la Market place. Pour que la démo soit complète, l’intervenant a mis en ligne son « Hello World » pour 0€ (heureusement !) et une personne du public a ainsi pu télécharger et exécuter avec succès l’application sur son téléphone. Plutôt bluffant, la mise à disposition sur internet a été très rapide.

Il ne vous reste plus qu’à vous décider entre un iPhone et un portable Android pour Noël…

Le modèle de management selon Google (conclusion)

Contrairement à certains modèles standards de management, chez Google la frontière entre développeur et utilisateur est totalement invisible. La hiérarchie est très aplatie entre les deux.

Vous l’aurez sûrement remarqué, lors des Google I/O ou lors d’autres conférences, ce sont toujours des développeurs ou des team leaders qui présentent les nouvelles applications, ce ne sont jamais des équipes de marketing…

Le développeur devient l’innovateur, il a un rôle central chez Google. Google fonctionne ainsi et, à en voir le résultat, ça m’a tout l’air de bien fonctionner!