Accueil > J'y étais ! > Compte rendu BarCamp OpenWeb/Cloud/Geo/Social

Compte rendu BarCamp OpenWeb/Cloud/Geo/Social

Ce mardi avait lieu un BarCamp intitulé “OpenWeb + Cloud + Geo + Social” (l’annonce ici), auquel j’ai participé. Je vous en propose un compte rendu à la fois sur le fond, et la forme. Pour mémoire, un BarCamp est une “non conférence” où l’on privilégie la discussion et l’échange, sur des sujets pas forcément définis à l’avance.

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

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 :

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

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é.

Mozilla Fennec
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.

Share
  1. Pas encore de commentaire
  1. 26/09/2014 à 19:23 | #1