Confoo est une conférence web à Montréal. Organisée au départ par le groupe PHP de Montréal, 11 ans plus tard la conférence s’est ouverte à toutes les communautés. Ruby, Python, JS, HTML5, Microsoft .NET et donc aussi Java. Cependant nous sommes vraiment minoritaires. Cela donne à la première impression, le sentiment de faire un Devoxx PHP. Cependant j’ai rapidement changé de vision en débutant les conférences. Pendant 3 jours c’est plus de 100 conférences, 10 salles en parrallèle. Environ 20% en Français et le reste en Anglais. Sur les thèmes, uniquement du Web, du Web et du Web. Du Cloud Computing au dernier framework Javascript, en passant par les techniques de refactoring en Java ou en Ruby… Les sujets sont très ouverts.
En arrivant sur Montréal (où il fait le même temps qu’à Paris en ce moment) nous découvrons avec David Gageot, une ville très nord-américaine… mais où tout est écrit en Français. L’espace de conférence est vraiment vaste. David a codé en quelques heures un « Carpet Showdown » pour travailler avec AngularJS. Au passage vous découvrirez les moquettes de l’hôtel Hilton, nous avons trouvé 16 variétés différentes. Et nous continuons à essayer de trouver de nouveaux échantillons.
Plus sérieusement, nous commençons la journée par une plénière d’ouverture dans une salle immense. Assis autour de tables rondes de 10 personnes, c’est très nord-américain. Le peu d’espace disponible pour 1400 personnes à Paris rendrait cela impossible. Mais le set-up est très sympa. Le déjeuner (on dit dîner ici) est servi à table, ce qui permet de discuter aves ses voisins. En France, à part le JUG SummerCamp à la Rochelle, je n’ai jamais vu ce set-up.
La conférence est organisée sur 3 jours. Il y a environ 600 personnes. Les organisateurs ont utilisé un « appel à contributeur » ouvert cette année. Au total c’est plus de 800 sujets (et pas 500 comme j’ai tweeté) qui ont été reçus par les organisateurs. L’organisateur principal, Yann Larrivee, explique que le processus de sélection a été difficile. Les organisateurs ont imprimé toutes les propositions et ont ensuite construit un programme complet sur 3 jours. Cela nous rappelle aussi la sélection à Devoxx France avec David.
Première présentation
Après l’ouverture, je débute ma journée par la présentation de Derrick KO (@derrickko). Le sujet est « How to build team that ship ». Sur la forme tout d’abord, encore une fois je me dis que les speakers nord-américains sont plutôt bons. Les slides sont simples, un ou deux mots par écran. Un code couleur permet de séquencer la présentation. Le plan ou les sections sont présentées sur fond noir. Chaque chapitre a son code couleur. Enfin il coupe sa présentation plusieurs fois et demande à l’assemblée de partager un témoignage. Sans aucuns soucis, toute l’assemblée participe volontairement, la prise de parole et l’écoute fonctionnent mieux selon moi qu’en France. Nous avons encore, nous Français, à apprendre à écouter plutôt que de s’écouter…
Sur le contenu, Derrick partage son expérience chez KickSend. Il a travaillé auparavant chez Pivotal Labs. Il confirme tout d’abord le fonctionnement des startups Webs à San Francisco. Chaque Startup qui se lance est maintenant constitué de 3 équipes. D’une part le développement business, d’autre part le développement UX/Produit et enfin seulement, le développement technique. Depuis le succès d’Apple, il est impossible de réussir un projet de startup web sans donner autant d’importance à l’expérience utilisateur, qu’à la solution technique.
Ce que j’ai retenu de la présentation : il est primordial de comprendre le comportement des visiteurs de votre site Internet. Derrick cite KissMetrics et MixPanel. Le suivi des clients est aussi important que la mise en oeuvre du CloudComputing pour l’exploitation. Ne pas prendre trop de décisions, mais valider rapidement des hypothèses. Etre aussi piloté par les données, ce qu’il appelle en Anglais « Data Driven Decisions ». Il est inutile de chercher une version parfaite au bout de quelques mois. Nous reconnaissons ici ce que l’on appelle la « Béta Eternelle« . Les visiteurs de votre site se fichent de la version 2 ou 3… Ils utilisent un service web, et celui-ci est amené à changer en permanence.
Sur la partie expérience utilisateur, il témoigne aussi de son expérience sur la validation des adresses de courrier électronique. Imaginez que votre application comporte un champ d’email libre. Il a été constaté que presque 10% des personnes se trompent dans le nom de domaine, par exemple gnail au lieu de gmail (sur un clavier qwerty cela arrive souvent). Pour palier à ce problème, demander de saisir une deuxième fois est ennuyant. De plus, les utilisateurs font alors un copier/coller. Pour résoudre ce problème, Derrick a développé une petite librairie JS très simple et très populaire. Elle est utilisé par Dropbox, Minecraft, KickSend et bien d’autres. Il s’agit de mailcheck.js. Dès que je rentre, je l’ajouterai sur la page d’arrivée de ZapTravel.
Après cette présentation, j’ai assisté à la présentation sur les failles de sécurité dans le monde Javascript. OWASP (Open Web Application Security Project) Top 10 pour le développeur Javascript. J’ai préféré partir au bout de quelques minutes, car finalement le contenu le plus intéressant était déjà dans les slides. Je le répète si vous venez à Devoxx France comme présentateur : ne mettez pas de diapositives avec plus de 3 lignes de textes. Si vous affichez du code, faîtes attention à utiliser un fond blanc et à afficher le texte en noir (et pas l’inverse, le code blanc sur fond noir se lit mal sur écran). Enfin utilisez le modèle de présentation de la conférence. C’est un cadre qui permet à l’assemblée de vous écouter… plutôt que de lire le contenu des diapositives.
Pause déjeuner
La pause déjeuner permet de se retrouver autour de plusieurs personnes, le temps d’un repas assis. Je regrette de ne pas avoir beaucoup discuté, et de n’avoir pas non plus rencontré beaucoup de développeurs Java. Quant à d’hypothétiques développeurs Groovy ou Scala… à part moi je ne vois pas.
Sur le contenu de la conférence, les thèmes sont très ouverts. Le programme couvre les sujets suivants sur 3 jours :
- Accessibilité
- API
- Architecture
- Cloud
- Persistence des données
- Devops
- Commerce électronique
- Front-end
- Java
- Javascript
- Mobile
- Performance
- PHP
- Python
- Ruby
- Assurance Qualité
- Gestion de projet
- Sécurité
- Web Social
Au lieu d’avoir 4 ou 5 thèmes, les organisateurs demandent aux présentateurs de sélectionner 1 ou 2 thèmes. Ceci permet de construire un programme plus simple à lire, une idée que nous pourrions reprendre pour l’organisation de Devoxx France je pense.
Le dessert est offert par PayPal, un des sponsors de la conférence. Idée vraiment originale, qui permet de faire un peu de buzz et d’offrir un gâteau bleu, chose plutôt original pour nous 🙂
Après-midi
J’ai ensuite repris l’après-midi avec différentes conférences. Je suis retourné voir Derrick Ko sur le thème « Building rich, real-time web application » puis ensuite j’ai assisté à une excellente présentation de Ross Tuck sur le protocole HTTP. Une présentation que chaque développeur devrait voir dans sa vie au moins une fois.
Mais tout d’abord un mot sur la session de Derrick Ko, sur l’architecture de KickSend. Backend en Ruby, données montées en cache avec memcached. Ensuite une partie asynchrone et temps réelle assez compliquée pour remonter des notifications temps réels. La complexité montre que ce problème n’est pas simple à résoudre. Il a fait le choix d’utiliser un serveur XMPP. Il parle ensuite de BOSH (Bidirectional-streams over synchronous HTTP) dont je n’avais jamais entendu parler. Durant sa présentation il évoque aussi HTML5 Server Sent Event, que nous avons mis en oeuvre sur Zaptravel en août avant de tout arrêter pour revenir à du Long-polling HTTP. Autant Play2 fonctionnait sans soucis avec cette architecture, autant nous nous sommes plantés avec Backbone.JS et la complexité du métier à gérer côté client. C’était une usine à gaz, aussi lié au fait que nous découvrions le métier tout en codant. La nouvelle version basée sur AngularJS et du long-polling HTTP via un serveur nginx+PHP est certes, moins sexy, mais a le mérite de bien fonctionner.
Derrick partage aussi dans son retour d’expérience ses soucis avec Backbone. Cela confirme ce que j’ai vu durant plusieurs semaines sur notre projet. Il manque par rapport à AngularJS une structuration plus stricte. C’est un bon framework mais il est plus difficile à mettre en oeuvre qu’AngularJS, pour un résultat plus compliqué. Que le lead-developer de KickSend le dise confirme mon expérience sur ZapTravel. Pour en avoir le coeur net, prototypez sur votre application Web. Vous verrez si AngularJS, BackBone ou Ember.JS sont adaptés.
Il termine sa présentation en conseillant d’éviter la complexité. Une startup web doit pouvoir changer rapidement de stack technique. Ne créez pas une cathédrale mais codez simplement quelque chose qui fonctionne. A ce moment de la présentation, oui, j’ai souri.
HTTP and Your Angry Dog
Sans doute la session que j’ai préféré de cette première journée. Ross Tuck est américain, il vit en Hollande depuis 5 ans. Honnêtement, il faudrait qu’il vienne à Devoxx. En une heure, 120 slides plus tard, vous repartez avec les idées claires sur le protocole HTTP. C’est vraiment une présentation que j’aimerai faire en Français. Combien de développeurs webs connaissent les bases et le principe du protocole HTTP ?
Prenez cet exemple : comment gérer la version d’une API REST ? Comment demander au serveur d’envoyer un résultat au format JSON ou XML ?
Première approche : pourquoi ne pas ajouter le numéro de version dans l’URI ? Par exemple /api/v1/travel, puis ensuite /api/v2/travel. Mauvaise idée, il y a pour cela le header HTTP « Accept » qui permet à un client HTTP de spécifier le niveau de l’API qu’il utilise. Accept est un pattern qui permet à votre code JS ou votre client mobile de forcer la version du protocole de votre API.
Vous pouvez par exemple envoyer ce message pour recevoir ensuite une réponse au format JSON:
GET /api/travels HTTP/1.1 Host: www.demo.com Accept: application/json
Le client de votre API peut aussi très bien spécifier la version de l’API qu’il souhaite utiliser :
GET /api/travels HTTP/1.1 Host: www.demo.com< Accept: application/vnd.travel-v1+json
Et ceci, n’est qu’un extrait de son excellente présentation qui a duré 1 heure. Courrez voir les 199 slides de sa présentation sur SlideShare, vous devriez pouvoir rejouer la présentation chez vous, en attendant que je l’adapte en Français.
Fin de la journée
La journée se termine par d’autres conférences, mais rien qui ne mérite un article sur le Touilleur Express. Enfin nous partons diner en ville entre speakers. Plus d’une centaine de personnes. J’ai aussi noté qu’aucun présentation n’est effectuée à deux à Confoo. Lisez bien ceci : sur les 100 conférences, il n’y a pas de « binômes » ou de présentation à deux. Intéressant non ?
Le temps de découvrir aussi ce que « neiger » veut dire, nous rentrons avec David pour qu’il termine la mise en prod de son projet. Je vous laisse avec quelques photos de nos belles moquettes.
Merci pour ce résumé.
Merci pour le résumé et les photos de moquettes!
Si je comprends bien, le problème évoqué pour les Server Sent Events concernent uniquement l’intégration avec Play et Backbone et non pas la techno SSE en elle même?
Oui, l’idée d’intégrer des flux asynchrones dans Backbone était mauvaise. Cela a complexifié énormément le code. Si tu vas maintenant sur Zaptravel.com et que tu sélectionnes un voyage, tu verras la nouvelle version avec AngularJS.