Qu’est-ce que la Droidcon ?

Business Design Center de nuit

La Droidcon, c’est une conférence autour de la plateforme mobile de Google, elle a une renommée européenne et est organisée dans 4 grandes villes chaque année : Amsterdam, Berlin, Bucarest et Londres. Les 6 et 7 octobre 2011, ce sont près de 600 personnes qui se sont réunies lors de la Droidcon au Business Design Center, à Islington, au coeur de Londres.

Le premier jour s’est organisé à la façon d’un barcamp. Lors de la keynote d’ouverture, toutes les personnes qui souhaitaient aborder des sujets particuliers ont proposé leurs idées. C’est ainsi qu’une trentaine d’ateliers ont été créés autour de sujets tant pour les développeurs –  comme la performance et la sécurité – que pour les non développeurs avec des sujets autour de la monétisation des applications Android par exemple.

Les présentations de la seconde journée étaient quant à elles déjà prévues, on a aussi retrouvé divers sujets autour du développement, du business, de l’entreprise etc.

Les organisateurs de cet événement étaient Skills Matters, société londonienne spécialisée dans la formation informatique, et Wireless Industry Partner connector (WIP), société canadienne spécialisée dans la mise en relation d’entreprises dans le domaine mobile.

Les exposants

En parallèle de ces ateliers et conférences, divers exposants sont venus présenter leurs produits ou services. Voici une liste non exhaustive des exposants présents lors de cette conférence et les raisons de leur présence.

Les constructeurs

Stand HTC Dev

La société taïwanaise HTC est venue pour présenter plusieurs nouveautés :

• Un nouveau smartphone, le Sensation XL équipé de la technologie beats by dre qui offre une qualité sonore supérieure ;
• Une nouvelle tablette sous honeycomb : la Jetstream avec son stylo. HTC en a profité pour nous présenter son API nommée Pen permettant d’utiliser ce stylo sur la tablette afin de transformer la tablette en véritable papier électronique.

La société japonaise Sony Ericsson était également présente pour nous présenter son dernier smartphone le Xperia Play, qui est un mélange de console de jeu et de smartphone.

Enfin, un dernier constructeur était présent, et, bien que pouvant surprendre, il s’agissait de RIM. En effet, la société canadienne est venu courtiser les développeurs Android car leur tablette Playbook embarquera une nouvelle technologie nommée Android player. Ce player permettra aux applications Android de fonctionner sur la tablette Blackberry.

Les solutions à destination des professionnels

L’entreprise Cisco était présente afin de montrer sa tablette Cius à destination des professionnels. Celle-ci dispose d’un OS basé sur Android et est vendue avec les services de communication de Cisco pré installés (Webex par exemple). A destination des professionels, elle dispose d’une connectivité plus importante que les tablettes grand public, on notera particulièrement le support de la 4G et la connectivité filaire.

Autre technologie représentée, Mobile Infrastructure by Sybase qui permet de réaliser de la haute disponibilité pour les données d’applications mobiles au sein d’une entreprise.

Autres stands

Photo d'autres stands

Un des grands thèmes de la Droidcon était la monétisation des applications Android : comment gagner de l’argent grâce à son application ? Plusieurs plateformes publicitaires sont donc venues faire leur promotion : Inneractive, VServ, …

L’éditeur O’Reilly était présent le deuxième jour et proposait aux participants de la Droidcon des rabais sur ses livres. Les organisateurs possédaient également leurs stands afin de promouvoir leurs activités, Skills Matters propose d’ailleurs gratuitement un magazine trimestriel sur les technologies open source. Stackoverflow.com, site web très connu chez les développeurs, est venu présenter son site Careers 2.0, plateforme de recrutement pour les métiers de l’informatique.

Enfin, deux solutions technologiques étaient représentées, il s’agit de Testdroid (dont je parlerai dans un prochain article) et de Mopapp. La première est une solution de test pour les applications Android, la seconde, quant à elle, est une solution de suivi des ventes d’applications mobiles.

Voila pour la présentation de la Droidcon, promis, les prochains articles seront plus croustillants, et on y trouvera peut-être même des lignes de code

Une fois n’est pas coutume, ce deuxième mardi du mois a été l’occasion pour les Javaïstes parisiens d’assister au Paris JUG, consacré cette fois aux processus de build, share et deployment. Pas de chance, la salle était déjà bien pleine quand je (Bastien) suis arrivé… vite, une chaise tout devant !

De mon côté (Pierre-Yves), ayant posé ma tente devant la salle la veille au soir, j’ai eu accès aux premiers rangs. Allez, je vous livre un petit secret : pour avoir un placement correct au Paris Jug, il faut arriver à 19h (ou être une JDuchess ). Je (Pierre-Yves) vais donc vous parler des trois premières présentations, et je (Bastien) continuerai avec les deux dernières.

Les secrets de fabrication du W3C

Par Alexandre Bertails

Qui connaît réellement le W3C ? En dehors des outils de validation et des spécifications HTML 5, peu d’entre nous en savent plus sur cet acteur historique du Web. Alexandre Bertails nous en dit plus, dans un temps imparti relativement court.

Saviez-vous que le site web du W3C vient d’être refait à neuf, après un an et demi de travail ? Ce n’est pas juste une CSS, le contenu et l’arborescence ont été revus, sans cependant casser aucun lien. Allez-y, visitez-le (bien plus joli qu’en 2008, 2002 et même 1996).

J’ai aussi découvert que le W3C est composé à 40% de français. Que les outils avec lesquels travaillaient les salariés n’étaient pas forcément orientés Web, mais que les choses ont bien évolué récemment.

On regrettera le flux permanent des retardataires (ça va, je (Bastien) le saurai pour la prochaine fois !), qui ont quelque peu perturbé notre attention à tous, sans toutefois départir Alexandre de ses moyens (et c’est tout à son honneur !).

DVCS

Par Sébastien Douche

Speaker hors pair, Sébastien Douche nous a donné envie de nous jeter à l’eau (pardon… facile celle-là) et de nous mettre immédiatement aux DVCS (Distributed Version Control System, système de gestion de versions distribué).

Auparavant, lorsqu’il intégrait un nouveau groupe de travail, Sébastien avait l’habitude d’y déployer sa boîte à outil habituelle : SVN, et Trac. Jusqu’au jour où il s’est retrouvé chef de projet sur un projet from scratch.

J’aime beaucoup la métaphore qu’il nous a donné : la maintenance d’une application, c’est du ski sur pistes, il y a des dizaines de développeurs qui sont passés avant toi et qui ont tracé la piste. Le développement à partir de zéro, c’est du ski hors piste, tu sais la direction que tu veux prendre, mais tu es en haut de la montagne, ya du brouillard, il faut se lancer, et tu n’as pas de repères immédiats.

Avec le temps, le projet, pourtant “agile”, a eu de plus en plus de mal à livrer dans les temps, et la qualité de travail s’est progressivement dégradée. Pourquoi ? Parce que les développeurs passaient leur temps à faire des micro-commit/micro-merge et à intégrer le travail des autres, au lieu de pouvoir se consacrer au développement des fonctionnalités.

C’est une sale habitude que nous donne SVN : merger le code est vécu comme une expérience difficile. On préfère donc commiter le plus vite possible pour que ce soient les autres développeurs qui aient à merger. Les micro-commit sont aussi bien moins difficiles à merger. Quand aux branches SVN, elles sont aussi faciles à créer que complexes à merger…

SVN ne sert plus au final qu’à faire de l’historisation, c’est un super “Annuler / Répéter”.

Les DVCS récents permettent à chaque développeur de travailler en local (fonctions d’historisation) et en isolation, et de pousser le code sur un repository central uniquement lorsque la fonctionnalité est terminée. Leur grande force est la flexibilité qu’ils introduisent, permettant à chacun de bosser comme il l’entend tout en respectant les règles d’organisation du groupe.

Il est aujourd’hui possible de passer à un DVCS en douceur, sur son poste de travail, en important un repository SVN qui peut rester le repository principal, mais en disposant des avantages d’un Git ou d’un Mercurial en local.

Sébastien en a aussi profité pour nous présenter la manière dont travaille son équipe : le repository central comporte uniquement du code “livrable” (au sens livraison de fin de Sprint). Chaque fois qu’une fonctionnalité a été codée par un développeur, une revue de code est réalisée par un autre développeur, une démo est réalisée, et si tout va bien alors seulement les modifications sont poussées sur le repository central.

Sa conclusion : si vous ne devez apprendre qu’une techno en 2010, ce n’est pas Scala, JEE 6, Maven 3… apprenez à utiliser un DVCS !

Git

Par David Gageot

Plutôt que de faire de sa présentation un énième tutoriel sur Git et tous les concepts associés, David Gageot a préféré nous montrer la puissance de Git en quelques exemple pratiques.

Tout d’abord, git bisect. Cette fonctionnalité permet d’automatiser la recherche du commit qui a créé une régression. Le fonctionnement est simple : on fournit à Git un script permettant de déterminer, pour une version donnée, si le bug est présent ou non. git bisect va ensuite réaliser une recherche dichotomique entre deux numéros de versions, et identifier très rapidement le commit coupable.

Cette fonctionnalité n’a pas grand chose à voir avec le fait que Git soit un DVCS (distribué), mais reste un argument de poids pour adopter cet outil. C’est aussi possible grâce à la rapidité avec laquelle un Git ou un Mercurial peuvent réaliser un checkout ou changer de version sur une copie locale.

David nous a ensuite montré un script qu’il a réalisé, qui permet de conditionner automatiquement le push vers le repository au fait que le build et les tests passent. Il peut donc tranquillement bosser et commiter pendant qu’en tâche de fond le build et les tests sont exécutés, et ainsi se passer d’un Hudson.

La présentation s’est terminée par des démonstration sur l’évolution de dépôts Git à l’aide de Gource, qui permet de représenter dans le temps les modifications effectuées sur un dépôt de sources, et le travail de chacun.

Le Gource du projet Linux

En conclusion, quelques conseils :

• testez Git le plus vite possible,
• n’essayez pas de faire du SVN avec Git, il faut oublier comment SVN fonctionne, désapprendre les mauvais réflexes,
• un bon moyen pour démarrer, c’est de jouer avec github,
• n’hésitez pas à utiliser Git dans le cadre de vos projets, au moins en local, il vous apportera une forte plus value même si votre équipe continue d’utiliser SVN.

Pause Buffet

Le buffet était gracieusement offert par Nicolas Martignole, suite à un défi lancé sur Twitter. Il en a profité pour faire de la pub pour l’eXpress Board, un job board pour les passionés. J’ai (Pierre-Yves) aussi pu croiser Emmanuel Bernard, apprenant ainsi que si l’équipe Hibernate n’utilise pas de DVCS pour le moment, ils songent à y passer, notamment pour faciliter l’intégration de contributions externes.

Build it with Maven 3!

Par Nicolas de Loof & Arnaud Héritier

Invités surprise, Fred et Jamy nous ont montré que Maven, c’est pas sorcier ! Certains se souviennent encore des migrations longues et périlleuses des Makefile vers Ant, puis vers Maven 1 et Maven 2. Cette fois, les développeurs du célèbre gestionnaire de build ont voulu éviter cela : la compatibilité de Maven 3 avec des projets en version 2 est en théorie de 99.99% (hormis maven site qui n’est pas encore au point).

Première rencontre avec Maven 3

Les mots-clé de la première release stable seront donc les suivants :

• compatibilité : en prenant n’importe quel projet Maven 2, sans aucune modification on pourra le builder avec Maven 3,
• modularité/extensibilité : le socle de l’application a été entièrement repensé (en évitant les problèmes de rigidité et de complexité de la version 2). Au menu, utilisation de Java 5, apparition d’APIs simples et intuitives, de la doc… Bref, de quoi faire des plugins sans se prendre la tête,
• Mercury : ce système voué à remplacer le mécanisme d’artifacts… a finalement été abandonné .

Maven 3 introduit la notion de build plan, qui permet de savoir à l’avance toutes les actions qui vont être effectuées dans un build (une sorte de contexte d’exécution). Ainsi, un plugin sera au courant de ce que feront les autres, donnant la possibilité d’avoir des builds intelligents (où les tests ne seront pas lancés deux fois par deux plugins différents par exemple).

Au niveau des descripteurs de build, la structure des pom.xml a été améliorée et Maven 3 devient polyglotte. On peut à présent écrire des descripteurs en groovy ou en python par exemple. Les exclusions globales de dépendances sont maintenant possibles (on va enfin pouvoir se débarrasser de cette *$#~ de dépendance sur un logger qui plante toujours… ).

Toujours dans les descripteurs, la notion de mixins est apparue :

Essentially it will be a POM consisting of plugins and configurations that can be externally parameterized. These mixins will be deployed to a repository and be referenced with a standard coordinate. Basically it will be an intelligent import with validation which will allow composition in your POMs.

On va pouvoir décomposer notre POM en différents morceaux, un peu à la manière des web-fragments.

Les builds parallèles vont bientôt faire leur apparition, pour ne pas que vos 7 autres cores s’ennuient (edit: Mathieu nous signale en commentaire que les builds parallèles sont déjà disponibles depuis la version 3.0-beta-1). Cette fonctionnalité sera très intéressante sur les serveurs d’intégration continue utilisant un modèle maitre/esclave (Hudson, pour ne citer que lui). Techniquement, le processus de build sera découpé en différentes phases qui se rejoindront en des points de synchronisation.

Mais au final, qu’apporte Maven 3 par rapport à Maven 2 à l’heure actuelle ? Rien, enfin presque :

• un shell (avec des jolies couleurs !) permet de faciliter les builds (notamment sous Windows),
• un gain de rapidité lors des builds.

Comme la migration de M2 vers M3 est très simple et rapide, nos deux speakers encouragent vivement les développeurs à tester Maven 3 chez eux, ne serait-ce que pour les gains en terme de rapidité de build. A vos pom, donc !

Deploy it with… DeployIt!

Par Guillaume Bodet & Benoit Moussaud

Guillaume et Benoit nous ont présenté les fondamentaux du bébé développé par XebiaLabs, DeployIt. Cet outil part du constat qu’un déploiement ne consiste pas en une simple copie d’EAR/WAR. Il y a généralement d’autres éléments à configurer (DataSources, JMS), des scripts SQL à lancer, des batches à mettre en place, etc.

DeployIt permet de gérer toutes ces étapes de manière intelligente et de faciliter l’installation d’une application. Il est repose sur trois briques principales :

• le cœur,
• des interfaces (Flex, console, Maven, Eclipse, dashboards…),
• des plugins permettant le support de JBoss, Apache, .NET etc.

La préparation d’une installation se fait en deux étapes. Dans un premier temps, on configure le Configuration Item Repository (CIR), qui est un référentiel d’informations sur les différents environnements de déploiement (test, performances, etc.). Ensuite, l’ensemble des opérations à effectuer est décrite dans des runbooks : déploiement d’un EAR, configuration d’une DataSource, installation d’un script SQL…

A partir de ces deux sources d’information, l’Intelligent Runbook Resolution Engine va se charger d’interroger les différents runbooks pour constituer un scénario de déploiement, en se basant sur les caractéristiques de l’environnement décrites dans le CIR.

Un des aspects intéressants dans DeployIt est sa faible intrusion :

• Il est agent-less, et va utiliser les moyens existants tels que ssh, sftp, scp.
• Il utilise les interfaces natives lorsqu’elles sont disponibles (wsadmin, JDBC…).
• Un plugin Maven permet de lancer les déploiements au sein d’un processus de build (au sens Maven) déjà existant dans le projet.

Seul bémol : DeployIt est un outil commercial, il existe une version gratuite mais qui n’intègre aucune notion de sécurité… XebiaLabs a ainsi la volonté de permettre aux gens de tester ce produit chez eux, tout en empêchant la possibilité de l’utiliser pour faire de vrais déploiements en production (sauf si vous êtes kamikaze).

Cependant, XebiaLabs songe à relâcher son outil en Open-Source. La majorité absolue des personnes présentes dans la salle a d’ailleurs voté positivement pour une telle action, en réponse à un sondage improvisé d’Antonio .

Conclusion

Ce Paris JUG fût riche en enseignements et en conférences de qualité. D’autres compte rendus ont été publiés sur le web : sur le blog du Touilleur Express, et sur le blog des JDuchess.

Le prochain Paris JUG aura lieu le 8 juin, avec une invitée à l’honneur : Holly Cummins.

Présentation d’Android

(Stéphane Lietaed + Gabriel Kastenbaum) @ Oxiane

L’engouement pour les smartphones débute en 2002 avec l’apparition du BlackBerry (le téléphone de chef, pour continuer à recevoir des mails pendant les réunions). Le téléphone élitiste par excellence.
Il faudra attendre 2007 et l’iPhone, le pari réussi d’Apple, pour voir le marché évoluer. Et un deuxième boom avec l’AppStore, qui vient de dépasser les 100000 applications disponibles.
Le téléphone portable est omniprésent (3x plus de téléphones que d’ordinateurs personnels dans le monde), cela représente donc un secteur d’avenir en termes de développement.

Android est une plateforme, initiée par Google. Le point clef est l’ouverture (vis-à-vis de l’iPhone certes, mais pensez également au paysage du développement d’applications ayant accès aux fonctionnalités avancées des téléphones avant celà !)

En france, Bouygues et SFR (les perdants côté iPhone) se rattrapent sur les téléphones Android et proposent très rapidement des terminaux. Aux US, le premier téléphone équipé d’Android 2.0 (Motorola Droid) est sorti récemment.

Cette version de l’OS apporte entre autres le support d’exchange, avec de manière sous-jacente la technologie ActiveSync qui permet les “push” (également adoptée par Google pour Google Calendar et la synchronisation des contacts).

Parlons un peu technique

Android est un OS fondé sur Linux (noyau 2.6) et équipé d’une VM java spécifique (Dalvik VM). Ceci permet d’écrire en java, mais d’exécuter du bytecode Dalvik (fichier .dex). Il ne s’agit donc pas à proprement parler d’une JVM mais tous les avantages liés à la technologie java sont là (outillage, librairies et large panel de connaissances en termes de développement). C’est ce qui en fait une plateforme idéale pour l’entreprise. A ce sujet, je vous recommande la lecture de la série d’articles présents sur ce blog : Android pour l’entreprise.
La machine virtuelle java est optimisée pour des processeurs lents et pour une taille de RAM dérisoire à côté de ce que l’on a l’habitude de manipuler sur des ordinateurs personnels ou des serveurs.

Contrairement à une JVM classique, Dalvik ne fonctionne pas avec une stack, mais directement avec des registres.

Disposer d’une plateforme liée à Java permet certes de s’appuyer sur tout un ensemble de librairies existantes, mais l’on est ici dans l’impossibilité de faire quoi que ce soit qui fasse de la manipulation de bytecode java au runtime (langages alternatifs tels groovy, etc) ou des fonctionnalités AOP.

En ce qui concerne l’outillage, celui-ci n’est pas forcément lié à Eclipse (outils en ligne de commande disponibles ?) mais Eclipse est l’environnement de référence. Le jeu de plugins incite aux mises à jour (et contient la documentation en local).

Nos deux intervenants nous font ensuite une démonstration rapide du SDK, où l’on peut voir l’émulateur hébergeant une application “hello world” tourner en quelques secondes.

A propos des éléments graphiques

Le framework permettant de créer des IHMs est un framework “maison” mais les concepts sont similaires à awt, swing, etc.

Le tooling permet de travailler soit en mode graphique (drag & drop de composants), soit en mode édition d’un fichier “layout xml” (inspiré du couple html + css) décrivant les composants sur l’écran. De plus, on peut mélanger à loisir l’approche déclarative via fichier xml et la manière programmatique.

On nous montre également la possibilité de débugger au sein d’Eclipse. A ce sujet, je m’étonne de voir des appels sous forme de stacks si la VM utilise des registres. A creuser, si quelqu’un connait la réponse à ce mystère, cela m’intéresse.
Au sein de la plateforme, l’outil LogCat permet de voir toutes les logs du système (et pas forcément uniquement celles de l’application).

C’est la fin de la démonstration et nous revenons à un contenu plus formel sous forme de slides :

Il existe 4 types de “composants” dans le système Android

1. Les Activités, qui permettent d’afficher des choses,
2. les Services (n’ont pas de représentation graphique, équivalents plus ou moins directs de “Threads” effectuant des traitements en tâche de fond),
3. les Broadcast Receivers : permettent de recevoir des messages envoyés par le système (ex: notification de batterie faible, ou notification d’appel entrant),
4. les Content Providers : accès aux données (mais qui peuvent être partagées, ex: accès aux contacts).

Toutes les applications* sont logées à la même enseigne. Corollaire : vous pouvez remplacer certains morceaux de l’OS.
(*) Il n’y a pas a proprement parler d’applications, les 4 types de composants ci dessus pouvant être une “application”.

Pour faire le lien entre ces concepts, il manque un mécanisme de communication par événements : ce sont les Intents.
Il ne s’agit pas juste d’invoquer une méthode sur une autre instance “d’Application”. Le mécanisme des Intents permet notamment de mettre en place la notion d’autorisation. Ceci permet donc un couplage lâche. Gabriel fait un parallèle avec l’association de fichiers au sein de Windows : un .doc peut s’ouvrir avec Word ou OpenOffice.

C’est déjà la fin, place aux questions

Comment le market gère la sécurité des applications publiées ?
R : L’application est chiffrée par un certificat identifiant la machine ayant créé l’application

Quels sont les composants graphiques disponibles dans le SDK ?
R : Le framework est assez riche, y compris possiblité de faire de la 3D

Comment Google entend-il prévenir la fragmentation du marché en termes de capacités des téléphones (notamment avec l’arrivée du HTC Hero ?)
R : Question plus ou moins éludée…

Peut-on repasser de .dex à “java” plus classique (bytecode ou source) ?
R : Possible, certains s’étant amusés à retro-engineerer le format (mais celui-ci n’est-il pas ouvert ?)

En conclusion, on avait affaire à une présentation très bien menée (même si l’un des deux intervenants ne semblait pas très à l’aise, ce que l’on peut comprendre vu la taille du public). Le défi de présenter la plateforme dans son ensemble à un public supposé novice est relevé.

Instant promo

Arnaud Héritier vient nous présenter le premier ouvrage sur Maven disponible en français (sortie le 20 novembre).

Ai-je besoin de préciser qu’il en est le co-auteur (avec Nicolas de Loof)

Google App Engine

Groovy and Gaelyk
Guillaume Laforge @ SpringSource/VMWare & (Marc Antoine Garrigue + Gaël Lazzari) @ Octo

Nos trois intervenants introduisent la présentation en nous rappelant les trois modèles disponibles dans le Cloud :

• Saas : GMail, salesforce.com
• PaaS : Google App Engine
• IaaS : Amazon EC2

Au début de l’année, le service GAE s’est donc ouvert à Java (la plateforme était initialement réservée à un développement en python). On a ici affaire à une JVM sandboxée et un conteneur de servlet jetty. Puisqu’il s’agit d’une vraie VM java, il est possible de faire tourner d’autres langages compatibles avec la JVM (dont groovy qui nous intéressera ce soir).

Le principe est d’écrire votre application (web) et Google App Engine gère la scalabilité pour vous. Le service est gratuit en dessous de certains quotas (ressources CPU, bande passante, envoi de mails, etc)

Toutes les APIs java ne sont pas forcément disponibles, mais pour pallier cela, GAE offre des services de haut niveau :

• Memcache (pour mettre en cache tout ce que vous voulez, utilisable à différents niveaux de votre architecture)
• URL Fetch (pour récupérer le flux présent à une certaine URL)
• Mail (pour l’envoi de … mails)
• Images (resize, crop, etc) : permet la manipulation d’images côté serveur
• XMPP : envoi et réception de messages sur le protocole utilisé par jabber entre autres
• User : authentification via un google account
• Cron + Task Queues : permet le traitement programmé de tâches
  

Pour autant, la plateforme connaît certaines “limitations” (ou du moins diffère en certains points d’un développement de webapps auquel on peut être habitué). Par exemple, on ne dispose pas d’une base de données relationnelle. De même, chaque requête doit répondre en moins de 30 secondes, sous peine de se faire couper la chique par la plateforme. On est également limité sur la taille et le nombre des fichiers que l’on peut déployer. Enfin, certaines actions sont interdites, par exemple :

• écrire sur le filesytem,
• créer des Threads,
• utiliser les sockets natives,
• AWT et Swing évidemment, la plateforme se destinant au traitement côté serveur, mais donc indisponibilité pour certaines classes de manipulation.

En terme d’administration, GAE donne accès à un joli dashboard pour le monitoring de l’application (et permet le suivi des fameux quotas).

La “BDD” s’appuie sur BigTable : imaginez une immence HashMap distribuée. Ce système supporte les transactions (avec subtilités) et le partitionnement, mais ne connaît pas la notion de schéma (ie une entité peut avoir des “colonnes” différentes de sa voisine).

On n’utilise pas le SQL pour la requêter : pas de jointures, pas de contraintes, pas de fonctions d’aggrégations. Au chapitre des limitations, on peut ajouter :

• on ne peut ramener que 1000 enregistrements à la fois,
• impossibilité de faire des filtres d’inégalité sur plusieurs critères (ie les inscrits au JUG avant telle date ET qui ont plus de 31 ans).

Passons au celtique

Les intervenants nous font à présent découvir Gaelyk : une fine surcouche à GAE pour l’interfacer avec Groovy (et notamment les Groovlets et templates).

Gaelyk donne accès aux classiques request, session, etc mais aussi aux services GAE (urlfetch, etc). Guillaume Laforge nous montre par exemple l’envoi de mails en version java et en version Gaelyk, et évidemment, la réduction de code est bluffante.

Gaelyk permet par exemple de manipuler les entités BigTable (qui sont vues comme des “maps” en java) comme des POGO (Plain Old Groovy Object) en groovy : notation pointée pour les propriétés et ajout de méthodes membres save(), delete(), etc.

S’ensuit une démonstration ayant pour but de montrer une application complète mettant en jeu le plus de services de Google App Engine possible. Pari réussi sous la forme d’un service totalement inutile (ou du moins à contre-sens de l’histoire) : une application qui récupère des feeds RSS et envoie des mails quand des mises à jour sont disponibles.

Cette démonstration est l’occasion d’aborder le casse-tête d’architecture qu’est le développement GAE pour de “vraies” applications : tout est initié par une requête http, mais une requête ne doit pas durer plus de 30s. Comment faire pour traiter mes 10000 flux ?

La démo s’achève et avec elle la présentation peu après. Au final, une très bonne présentation même si l’on peut craindre une certaine confusion entre Gaelyk et GAE pour les personnes qui ne connsaissaient pas du tout Google App Engine.

Je ne reste pas pour la présentation de Google Wave, ce qui est bien dommage puisque le contenu était très intéressant techniquement d’après les échos que j’ai eus par la suite. Qu’importe, les occasions ne manquerons pas de découvrir cette plateforme.

Pour ceux qui ne connaissent pas le JUG pour Java User Group est une conférence gratuite mensuelle organisée (en ce moment du moins) dans les locaux de l’ISEP à Paris.

L’objectif de ce post est de faire un compte rendu de la scéance du mardi 13 octobre sur JSF 2.0 et servlet 3.0.

Tout d’abord précisons que les slides de la précédente session du JUG, celle du 15 septembre sur la qualité logicielle, sont disponibles en téléchargement sur le site du Paris JUG.

Il est également possible de visionner les conférences en vidéo, en streaming sur le site beta.parleys.com.

JSF 2.0

Damien Gouyette, François Petitit

La conférence était divisée en deux parties, séparées par un buffet. La première partie, présentée par Damien Gouyette, qui s’occupe actuellement des normes et des pratiques JSF à Generali et par François Petitit, de Octo, portait sur les nouveautés de JSF 2.0. Ces messieurs ont fait un bref rappel de l’historique et des fonctionnalités de JSF puis ont présenté les nouveautés, assaisonnées de petites démonstrations.

Historique :
JSF est le framework MVC de JEE, dont la première version (1.0) est sortie en 2004 (JSR 127 ). La version 1.2 (JSR 252) sortie en 2006 apportait quelques améliorations. Et la version 2.0, sortant donc en 2009  et correspondant à la JSR 314, inclut pas mal de nouveautés.

Nouveautés de JSF 2.0 :

• Inclusion de facelets en natif (mais une implémentation de JSF valide doit toujours supporter les JSP).
• Import de ressources statiques dans le répertoire resources.
• Possibilité de forwarder les validations de hibernate validator (ou autres implémentations de la JSR 303) jusqu’aux pages JSF avec la balise f:validateBean.
• Possibilité de configurer les managed beans avec des annotations, ce qui rend le fichier faces-config.xml facultatif. Pour transformer un bean en manager bean JSF il suffit de l’annoter avec @ManagedBean. On peut lui donner le scope request avec @RequestScoped.
• Ajout du scope “view”, pratique pour les applications utilisant Ajax.
• Facilitation de l’ajax un peu dans l’esprit de ajax4jsf (richfaces) avec (entre autres je suppose, mais c’est celle qui a été présentée) une balise f:ajax.
• Possibilité d’utiliser des profils d’utilisation : dev, prod, unit test
• Possibilité de faire des requêtes get, ce qui permet de faire de faciliter les bookmarks.

JSF 2.0 est inclus dans JEE6 et compatible avec JEE5.

Nous avons eu droit à une démonstration de ezcomp, outil fourni avec JSF 2.0 pour faciliter la création de composants. L’idée est de créer un fichier dans le répertoire resources, de le configurer avec un peu de xml pour préciser par exemple les paramètres qu’il peut utiliser, et de le réutiliser ailleurs ensuite.

Puis ils ont fait une démonstration de l’utilisation des validations avec hibernate validator basée sur un formulaire de contact (avec des tableaux de présentation ). Le même formulaire a ensuite été utilisé pour montrer qu’on peut utiliser les mêmes validations, cette fois en ajax avec f:ajax.

Au moment des questions, Emmanuel Bernard, spec leader de la JSR 303 (bean validation), est venu apporter des précisions sur son sujet. Il conseille d’utiliser un seul bean en tant que managed bean JSF et en tant qu’EJB chargé de requêter la base. Lorsque quelqu’un dans l’assistance a parlé de la différentiation du conteneur de servlet et du conteneur d’EJB, la réponse fuse :

On s’en fout de celà ! Dans 99% des cas ils sont dans la même VM.

Il est remarquable que le nom de seam n’ait jamais été prononcé alors que beaucoup de ces fonctionnalités (il faut le dire, des manques de JSF 1.2) sont inspirés de ce framework. Web Beans (qui ne s’appelle plus comme ça) a tout de même été évoqué par E. Bernard.

(Buffet : J’ai eu le plaisir, au buffet entre les deux conférences, de goûter une boisson semblant être un mélange de jus de raisin et de miel … un peu surprenant (je m’attendais à du vin) mais intéressant)

Servlet 3.0

Rémy Maucherat

La seconde partie de la conférence, portant sur Servlet 3.0, a été assurée par le fort sympathique Rémy Maucherat, travaillant pour Redhat sur JBoss Web, le conteneur web de JBoss AS. Rémy a précisé qu’il était commiteur sur tomcat depuis 2000, membre de l’apache software foundation et membre de l’expert group pour la JSR 315 (servlet 3.0 donc).

La présentation était très technique, avec beaucoup de morceaux de code (une mise à jour prochaine liera les slides quand ils auront été publiés). Elle a suscité pas mal de réactions.

Ce qui ressort dès le départ c’est que le sujet concerne surtout les éditeurs de frameworks. Ce qui peut se comprendre : qui fait encore des servlets dans le cadre de ses développements ?

L’intérêt pour les frameworks est d’être importé en tant que jar et ne pas réclamer de configuration supplémentaire (sachant que l’utilisateur peut ensuite écraser les configurations introduites par le framework).

Voici la liste des nouveautés :

• Possibilité de configurer les servlets, des filtres, des listeners par des annotations. Il faut toujours implémenter les interfaces, la configuration dispense uniquement de la configuration dans le fichier web.xml. L’utilité des annotations est de pouvoir configurer les mappings (entres autres) sans passer par le descripteur de déploiement. Le présentateur s’est montré un peu ironique sur l’ajout des annotations comme @WebServlet, @WebFilter ou @WebListener  :

Je vais dire un peu de mal de Sun … Sun voulait des annotations, alors on a mit des annotations.

• Possibilité d’ajouter et/ou de supprimer des servlets, des filtres ou des listeners de façon programmatique dans un Listener ou dans le ServletContextInitializer
• Gestion de l’upload de fichiers :

Un peu comme dans commons-fileupload … d’ailleurs c’est ce qu’on a fait

• Overlays : possibilité d’importer des jars de ressources (par exemples des CSS, javascript, …). Ce sera clairement un soulagement pour beaucoup de monde : plus besoin de copiés/collés de ressources pour utiliser le thème graphique de la boite, ou de web app mappées sur un contexte conventionné “on suppose que c’est là”. Il faut les ajouter dans le répertoire META-INF/resources du jar (qui est lui dans WEB-INF/lib).
• Possibilité d’exécuter des opérations de manières asynchrone. L’API est selon Rémy Maucherat le plus gros morceau. Il a décrit en détail l’API, avec les méthodes à utiliser, le système de listener, précisé qu’il ne fallait pas faire d’IO bloquante, etc … avant de conclure qu’il fallait éviter d’utiliser directement cette fonctionnalité, sauf si absolument nécessaire.
• Gestion de “web fragments”. Un web fragment est en gros un descripteur de déploiement secondaire, qui peut être présent dans un jar (dans META-INF). D’ailleurs la balise racine est web-fragment au lieu de web-app, le reste étant assez similaire.
• Amélioration de la gestion de la sécurité. L’api fournit une méthode authenticate ainsi que des méthodes login et logout.
• Pluggabilité des implémentations de JSP. L’idée est de pouvoir changer d’implémentation de JSP. Selon Remy Maucherat cette fonctionnalité est utile pour tester les différentes implémentations mais déconseillée en prod.
• Gestion de la session configurable : on peut maintenant changer le nom du paramètre jsessionid, mais avec prudence toutefois, beaucoup d’outils l’utilisant (comme modjk). Il est également possible de choisir le tracking mode : Cookie, URL ou SSL ce dernier étant :

très bien en théorie mais en fait ça marche pas.

On le voit la plupart de ces fonctionnalités sont clairement destinées aux frameworks, l’idée étant que l’on puisse importer un jar, par exemple de spring mvc, et ne toucher à aucun autre fichier, même pas le descripteur de déploiement, pour l’utiliser.

Rémy a également précisé que la plupart de ces features allaient d’après lui prendre du temps a devenir mainstream, sauf l’asynchronicité et l’import des ressources.

Cette présentation a été suivie de pas mal de réactions. Quelqu’un a par exemple demandé s’il serait possible de récupérer des “paramètres du path” pour faire des URL à la REST (comme dans seam) (la réponse est non). Quelqu’un d’autre a demandé si les responsables de la JSR 315 étaient en contact avec des développeurs de frameworks. La réponse est, là encore, non.

Malheureusement pour une question de timing la salle a du être libérée et la séance suspendue.

Conclusion

Au final, comme je ne connaissais pas les nouveautés, j’ai personnellement trouvé les deux présentations assez intéressantes. Je précise qu’il valait mieux bien connaître JSF pour suivre la première. Emmanuel Bernard m’a impressionné par son talent oral : il a prit la parole sans préparation particulière à la suite de Damien et François et a su capter l’attention et préciser quelques points avec aisance. De même Rémy Maucherat a un style détendu où l’humour tient une place importante, que j’ai plutôt apprécié.

Je ne suis pas allé à la troisième mi-temps au pub, ayant prévu d’aller me coucher. Je me rattraperai la prochaine fois.

Le rendez-vous était fixé à 14h à La Cantine, mais à 14h45 personne n’avait encore pris la parole (on comptait plus de 120 inscrits), chacun se réfugiant dans un coin, tapotant sur son notebook (de préférence avec un pomme). Je plaide coupable.

Les différentes sessions retenues

Puis enfin, vers 15h00 tout se met en branle et chacun se présente rapidement (nom, prénom et 3 tags pour se définir – ce qui a vite tourné en 3 tags concernant ce que l’on aimerait voir abordé à la conf, mais tant mieux ceci a permis de monter les sessions plus rapidement)

Une fois le tour de salle effectué (je ne saurais dire combien de personnes étaient présentes, mais la cantine était bien remplie), Patrick Chanezon (Google) et quelques autres essaient de grouper les tags les plus fréquemment cités et proposent des sessions. Il faut avouer que l’assistance (très nombreuse) restait relativement passive, si bien que cette phase a pu ressembler à une prise d’otage, mais sans cela on y serait encore. Finalement, environ 5 ou 6 sessions sont définies et je décide de participer à celles-ci :

Session GWT

pilotée par Didier Girard (SFEIR)

En petit groupe, s’adressant à un public plutôt néophyte et pas forcément orienté Java/Entreprise, Didier nous déroule une présentation similaire à celle-ci http://www.slideshare.net/dgirard/gwt-gears-the-browser-is-the-platform

En deux mots :

• Il y a un avant et un après “vague Ajax” (2005)
• Le javascript “à la main” devient vite invivable :
  • Problèmes de compatibilité Cross Navigateur
  • Maintenabilité vs Performance : il faut choisir
• Le Manifeste GWT : je veux une technologie à la fois user friendly (sexy, performant) et dev friendly (outillage (re)connu, debugger, support de gros projets)

La phrase vendeuse que Didier présente aux décideurs (et avec laquelle j’adhère) : “aussi simple de développer un application en GWT pour le web qu’une application Windows avec VB”

Nous discutons ensuite des extensions autour de GWT et de l’outillage. Didier mentionne GWTDesigner (que je n’avais jamais vu tourner auparavant) pour commencer à découvrir GWT et prototyper rapidement des applications. Un autre projet que je découvre lors de cette session est gwtquery, un portage de jQuery en GWT.

Une session intéressante, même si nous avons été pris par le temps (personnellement, j’aurais aimé aborder un peu plus les nouveautés apportées par GWT 2.0 – Didier et moi tombons d’accord sur un point : GWT 2.0 apporte des changements radicaux et les bonnes pratiques de la version 1.x seront certainement à revoir. Je pense personnellement que la v2.0 prouve la maturité de la technologie pour de grosses applications, ne serait-ce que grâce à l’ajout de la fonction runAsync())

Session Hackabilité

(Paul Rouget + Tristan Nitot)@Mozilla.org +Patrick Chanezon@Google

Une session dans le plus grand espace de la cantine, avec projection sur grand écran, nos 3 compères sur scène et micros dans les mains afin d’accommoder un public très nombreux.

Ce n’était pas la première session sous ce format (une session sur html5 pendant que je participait à GWT avait déjà eu lieu), mais c’est à ce moment que je réalise que l’esprit BarCamp dans sa forme originelle n’aura pas lieu aujourd’hui : on a plus affaire ici à une présentation asymétrique (certes plus ou moins improvisée) avec questions réponses qu’à une discussion autour d’une table. Qu’importe, d’autant que la fin de la session dérive gentiment vers la mobilité avec Fennec. Je dois également préciser que cette session était l’unique option pour ce créneau horaire (l’alternative offerte initialement par Patrick Chanezon ayant mystérieusement disparu).

Après quelques démos sur les possibilités offertes en terme de bidouillabilité de Firefox lui-même (dont par exemple un moteur firefox sans la “coque” : pas de bouton, tout piloté par des raccourcis clavier), on aborde les points de bidouillage possible sur le web :

• html
• css (ex: Stylish)
• javascript (GreaseMonkey)

A droite, plus ou moins cachés : T. Nitot, P. Rouget & P. Chanezon

Tristan Nitot (prés. Mozilla Europe) précise que pour lui, la hackabilité est importante car elle garantit la liberté de l’utilisateur. Il cite par exemple la possibilité via GreaseMonkey d’ajouter un bouton “vraiment supprimer sur gmail” ou la suppression de l’enregistrement d’un click sur moteur de recherche Google.

Patrick mentionne la hackabilité (prototypage) d’un bugtracker en entreprise : permet de “contourner” les planning de release des applis en interne : si je veux rajouter une fonctionnalité relativement simple à mon bugtracker mais que la prochaine release est dans 6 mois, GreaseMonkey peut m’aider (apparemment, c’est du vécu).

Il évoque ensuite l’évolution au cours des 4 dernières années des librairies chez Google : il y a 4 ans, une seule API ouverte sur l’extérieur (AdWords) en SOAP (la mode à l’époque) : bien en java/net, mais pas top dans les autres langages.

Le premier Mashup n’est il pas la réunion (illégale) de Google Maps avec Craig’s List ? (par Paul Rademacher, aujourd’hui employé chez Google). GMaps a ensuite fournit ses APIs (puis le reste des APIs de google a suivi). Conclusion : les APIs de WebServices ont de plus en plus tendance à évoluer vers quelque chose d’exploitable sur le client (au sens navigateur) : ceci est dû d’après Patrick à cette notion de bidouillabilité.

Quelqu’un dans l’auditoire mentionne la hackabilité via les fonctions gmail labs omniprésentes alors qu’un hack du navigateur est perdu dès que l’on change de navigateur. La réponse des équipes Mozilla : Weave. Dans un premier temps, synchroniser la “awesome bar” entre tous ses navigateurs (Fennec dans sa poche et Firefox sur son desktop).

Nous en venons donc à parler de Fennec et des extensions possibles : le moteur de Fennec 1.0 est celui de FF3.6. Même principe d’extensions (mais non compatibles, ne serait-ce que parce qu’il faut repenser totalement la user experience).

Si la hackabilité est acquise sur le desktop, le monde du mobile est encore très fermé (à cause de la main mise des opérateurs télécom). La première brèche fut iPhone et le store (mais fermeture et non transparence de la part d’Apple). Android et son Market vont plus loin, le but de Fennec est d’aller encore plus loin.

Didier Girard mentionne le fait qu’html5 promet bcp, mais quid de l’intéraction avec les fonctions natives des téléphones (eg. prendre des photos, etc). La réponse des équipes de Mozilla : c’est implémenté de façon “standard” dans Fennec (standard, quel standard?).

Une possibilité (déjà implémentée ?) qu’évoque Tristan Nitot est d’avoir l’équivalent d’une balise html <input type=’photo’>. Exemple : je prends ma photo de profil facebook avec la caméra en direct. L’utilité d’avoir une fonction de capture de vidéo en html est limitée d’après lui.

Mozilla aimerait qu’il n’y ait qu’une plateforme pour le mobile, idéalement le web. De fait Palm et son Palm Pré reviennent souvent. C’est également intéressant d’entendre Patrick Chanezon soutenir une telle initiative, alors que Google a lancé la plateforme Android…

Quelqu’un dans l’assistance rappelle qu’Apple avait initialement sorti l’iPhone sans la possibilité de faire des applis natives et “misait” sur le web. C’est exactement l’inverse qui s’est produit. On mentionne également le projet Prism, qui permet en gros à des applis d’embarquer le moteur de Mozilla pour des applis dédiées et de le rebrander à leur sauce, afin d’obtenir une pseudo-application “lourde”.

Au final une session intéressante pour les geeks, même si le lien avec le sujet initial peut paraitre flou

Session Cloud Computing

Didier Girard, Patrick Chanezon
Le Cloud Computing est certainement le buzzword de 2009, et la mise à disposition récente de l’offre Google pour Java (ainsi que les événements de cet été concernant SpringSource/VMWare/CloudFoundry) n’ont fait que renforcer la tendance.

Cette session commence par quelques sondages sur les connaissances du public et mentionne les différentes façons de percevoir le Cloud. On cite notamment les 3 niveaux {infrastructure, platform, software} as a Service. On pourrait également ajouter le StaaS (Stockage as a Service).

En un mot, le Cloud Computing est la possibilité technique (et le business associé) offerte par des providers à des clients (souvent des entreprises) de déporter leur SI sur des machines fortement mutualisées. Le Cloud est souvent associé à une architecture largement distribuée, sensée apporter une forte disponibilité et de bonnes performances.

L’exemple typique en IaaS est Amazon EC2 : la possibilité de provisionner des machines, des disques, etc. C’est au client de construire (ou de décrire) l’architecture logicielle par dessus. Ceci permet de faire ce que l’on veut avec les machines.

L’approche Google, avec Google App Engine (prononcez “end’jin” et pas “end’jailleneu” ) : exposer un ensemble de services sous forme d’APIs (URLfetch, BigTable, manipulation d’images, jobs) puis Google assure le scaling de l’appli. Notez qu’il n’y a pas officiellement de SLA à l’heure actuelle. Cette solution se limite à des applications web (ce qui est radicalement différent des possibilités de EC2), même s’il existe (notamment dans la version python) des librairies pour ne voir GAE que comme un “backend”.

Une question se fait entendre dans le public : Google doit sûrement avoir un équivalent de EC2, mais ne l’expose pas. Pourquoi ? Est-ce la stratégie, ou une incapacité à le faire ? En tous cas, Patrick mentionne qu’en entreprise les clients évoquent des fonctionnalités manifestement trouvées chez EC2, mais que Google n’a pas. Pas mal de personnes présentes estiment qu’il est plus facile de “monter” la stack que de la redescendre (ie. il serait beaucoup plus facile pour Amazon de fournir une approche à la GAE que l’inverse). En effet, tout le monde semble dire qu’Amazon dispose d’une avance considérable dans le domaine.

Beaucoup de questions autour des quotas (GAE est gratuit pour les “petits” volumes alors qu’Amazon est (certes peu cher) mais payant dès la première requête : un avantage pour Google a priori). Pour avoir du succès en entreprise, peut-être que Google n’a qu’à faire payer dès la première requête. Les entreprises adooorent payer. J’avoue ne pas comprendre tous ces questionnements de l’assistance : soit l’on est en dessous des quotas et l’on peut déjà s’estimer heureux de disposer d’une infrastructure gratuite, soit l’on est au dessus et on commence à peine à payer pour un service rendu. Et à ce moment (les quotas sont tout de même hauts), on peut espérer que l’on aura trouvé un moyen de faire rentrer des revenus.

Le reste de la session ne concernera plus que Google App Engine. Avec des retours d’expérience par exemple : le comportement en environnement de dev local n’est pas forcément similaire à ce qui se passe une fois déployé.

A propos des plus grosses GAE (celles qui dépassent les quotas), Patrick cite http://www.buddypoke.com/

On mentionne également l’utilisation de JDO avec BigTable (la solution de base non relationnelle qui équipe GAE) qui reste problématique et ne semble pas encore mature (le mapping JDO, pas BigTable). En python, cela se passe mieux (de façon plus bas niveau a priori) : Est-ce que finalement BigTable ne serait pas plus adapté aux langages dynamiques ?

A propos de l’adhérence à GAE : si l’on veut s’éloigner de Google App Engine demain, quelles sont les options ? Sur le moment, je retiens le mot Eucalyptus, mais a priori c’est du côté d’appscale qu’il faut aller voir, Eucalyptus étant une couche entre par exemple EC2 et appscale. Tout cela fait beaucoup de couches

Un souci avec les base de données non relationnelles (non spécifique à GAE) : impossible de comparer deux colonnes, ce qui pose problème avec la géolocalisation par exemple (longitude ET latitude) : des solutions existent à ce problème particulier et me permettent de découvrir l’algorithme GeoHash.

Je mentionne la liste des choses qui semblent acquises et qui disparaissent dans le cloud (par exemple la notion de session). Mon voisin anglophone (un californien fraichement débarqué à Paris) m’envoie vers un article écrit par ses soins : page 14-20 de ce pdf. C’est ça aussi l’esprit BarCamp.

Conclusion

Il est 21h et alors que les pizzas commencent à refroidir, nous quittons les lieux. Je retiendrais de ce “BarCamp” un propos intéressant (même s’il ne collait pas forcément à l’idée que l’on pouvait s’en faire à la lecture de l’intitulé), dans une forme détournée (un BarCamp avec tant de personnes me parait difficile dans les locaux de la cantine, et toutes les personnes avec lesquelles j’ai pu discuter s’accordent à dire qu’elles ont eu un tel ressenti). Mais encore une fois, je pense que la forme n’est pas une fin en soi, seul le fond importe.