English version available

Comme annoncé dans mon précédent article, voici un tour d’horizon de la conférence Fosdem 2013 (Free and Open source Software Developers’ European Meeting). Le dimanche étant un peu la journée sacrée pour faire la lessive et plus simplement récupérer de sa semaine. Vous comprendrez pourquoi mon compte-rendu se limite à la journée du samedi.

La conférence se tient dans les locaux de l’ULB (Université Libre de Bruxelles), je retrouve donc pour un temps les couloirs de la fac, qui sont très similaires aux facultés françaises avec des bâtiments vétustes et une décoration marron/vert du plus bel effet à en faire pâlir Valérie Damidot.

Ouverture

J’arrive juste à temps pour la keynote d’ouverture, il y a déjà pas mal de monde dans ce grand amphi et je ne suis pas étonné de voir une très grande majorité d’hommes dans la salle.

Après un discours d’introduction, le staff Fosdem n’oublie pas de présenter l’équipe vidéo et finit par quelques… pas de danse! Tout le public est invité à descendre sur la scène pour participer à la chorégraphie (moi je prenais des photos, je ne pouvais pas tout faire). C’est la traditionnelle « Fosdem Dance » dont voici une vidéo qui a lieu tous les ans, danse qui est complétée au fil des ans avec de nouveaux mouvements si j’ai bien compris. Des fois, on se demande ce que l’organisation peut fumer! Mais c’est frais et c’est bonne ambiance, on aime et puis, qui sait? Peut-être que la Fosdem Dance sera la dernière danse à la mode après le Ganma Style et le Harlem Shaker.

La communauté Jenkins

Dans la même salle, j’enchaîne avec la keynote de Kohsuke Kawaguchi, le créateur de Jenkins. J’en profite pour me rapprocher. En fait, c’est la raison principale de ma venue. Après plusieurs années d’utilisation de sa plateforme d’intégration continue, je voulais absolument le voir.

Sa présentation était orientée sur la communauté Jenkins avec un titre plutôt intrigant: comment collaborer sans communication? Car finalement, c’est ce qui se passe avec Jenkins. Des centaines d’extensions, des milliers de commiters, pour un logiciel dont le succès ne s’essouffle pas. Kohsuke nous dévoile sa recette de la potion magique.

Il y a 2 ingrédients primordiaux: l’extensibilité et la modularité. Ces ingrédients ont un coût en terme de développement, mais le retour sur investissement est élevé, et c’est ce qui a permis le succès de Jenkins.

Extensibilité:

• Donner le « pouvoir » aux extensions
• Faire de l’extension récursive (autrement dit, possibilité de faire des extensions d’extensions)
• Le Core de Jenkins est lui-même un ensemble d’extensions « déguisées »
• Il y a actuellement plus de 600 extensions

Pour vous donner une idée, voici la liste des points d’extension du Core de Jenkins. Kohsuke ne nous a donc pas menti!

Modularité:

• Fournir des API claires et bien documentées
• Implémenter le concept de Silo. Un commiter travaille toujours sur des petites portions de code. Travailler sur 5 fichiers ou 500 sera complètement différent en termes de complexité!
• Avec les Silos, on comprend que le Core ne contient pas tout.

L’extensibilité et la modularité apportent de la lisibilité, de la flexibilité et de la stabilité dans votre application. Le logiciel devient plus facile à prendre en main pour vos futurs collaborateurs.

Après les ingrédients, parlons des chefs cuisiniers. En fait, vous, moi, tout le monde peut devenir chef commiter sur Jenkins (Kohsuke s’amuse en nous disant qu’il y a même un bot IRC qui gère cela de façon automatique). Le principe est à l’opposé du noyau Linux et son gourou Linus Torvalds qui sera toujours la dernière personne à valider et commiter vos changements (j’exagère un peu, mais on s’en approche). Ce n’est pas pour autant l’anarchie sur Jenkins! Au pire, si vous faites des dégâts ou cassez un truc, le périmètre sera restreint (limité à celui de l’extension). De plus, il y a toujours la possibilité de faire un rollback à la précédente version. Cela reste des cas très rares d’après Kohsuke, car les gens font attention quand ils ont le « pouvoir » entre les mains.

Abandonnons le monde de la cuisine et entrons dans celui de l’espace. Quel est le centre de gravité de Jenkins, la petite chose qui fait que l’application ne s’effondre pas? Réponse: la communication. Les canaux sont variés: IRC, meetups, hackathons, événements, twitter, blog, wiki, conférences. Pourtant, cette communication est volontairement restreinte, dans le sens où elle se limite à des groupes spécifiques organisés par extension. Les commiters sont nombreux, oui, mais ils se parlent peu. Souvenez-vous du vieil adage: Pas besoin de documentation, le code parle de lui-même! C’est un peu de cela qu’il s’agit. Lorsqu’il y a trop de discussion, l’information utile se noie dans le flux de messages, et ça devient rapidement le chaos ou le trou noir puisque c’est notre métaphore.

Continuons la corrélation avec le système solaire, le Core de Jenkins correspond au soleil et les extensions aux planètes qui gravitent autour. L’Update center représente la clé de voûte du soleil, son noyau. Heureusement, il n’est pas explosif dans le cas de Jenkins, il s’agit d’une interface graphique qui permet aux utilisateurs de gérer leur liste d’extensions.

Un dernier aspect de Jenkins que l’on peut noter: l’auto-renforcement.
Davantage d’extensions attirent davantage d’utilisateurs. Davantage d’utilisateurs alimentent une collaboration plus active (plus d’idées, plus de besoins, plus de commiters). Davantage de collaborateurs permettent donc d’avoir davantage d’extensions. Et la boucle est bouclée!

En guise de conclusion, Kohsuke nous rappelle le maître mot de sa présentation: extensibilité, ainsi que 3 éléments à prendre constamment en considération:

• Des développements au périmètre réduit
• Une communication réduite
• Laisser les gens innover

Première keynote très intéressante, je ne suis pas déçu! Il me reste encore un peu de temps avant d’aller manger, je décide d’aller voir une présentation sur l’utilisation des personas. Cette fois, le format est court: 40 minutes, questions/réponses incluses. Les intervenants sont même chronométrés pour libérer la place à temps pour la session suivante.

Les personas

Je me retrouve dans une salle de cours, j’arrive à trouver une assez bonne place (dérangeant au passage une poignée de geeks avec leurs ordinateurs dopés à Linux). Petit aparté, je n’ai pu m’empêcher d’esquisser un sourire quand j’ai vu un Macbook booter sous Ubuntu.

Bref, revenons au sujet. Les personas sont des personnages fictifs. Il faut cependant avoir suffisamment de détails pour qu’il soit réel (un nom, une photo, un âge, un job et des centres d’intérêt). C’est une sorte de profil.

Les personas représentent l’audience de votre application, ce sont les utilisateurs. Ils permettent d’apporter débats et discussions au sein de l’équipe.

Quelles sont les étapes pour créer un persona?

• Réaliser des interviews et des sondages auprès de votre population d’utilisateurs
• Faire des clusters pour identifier les caractères communs (grouper ensemble une sous-population)
• Simplifier les groupes pour former des archétypes

Attention, il ne faut surtout pas tomber dans la caricature, nous précise l’intervenant.

Les personas vous aident à connaitre mieux vos utilisateurs en les personnifiant et donc finalement à mieux connaitre votre application, dans le sens des fonctionnalités attendues.

Les résultats que l’on obtient:

• Mieux connaitre les attentes de vos utilisateurs
• Des utilisateurs contents!

La présentation finie, je reste quand même un peu dubitatif, mais il est temps de manger. Habitant en Belgique, pas de frites pour moi, ce qui me permet d’éviter une longue file d’attente, des sandwichs en triangle classiques feront l’affaire. Dans le même temps, je retrouve Tugdual Grall qui travaille maintenant chez Couchbase. Ca fait toujours plaisir de parler de Nantes et de prendre des nouvelles!

On partage le même avis sur cette conférence, à savoir qu’elle est très orientée développement bas-niveau. En lisant ce compte-rendu, vous ne le ressentirez pas, car j’ai minutieusement choisi mon programme. Voici quelques exemples de ce que j’aurais pu choisir:

• ARM support in the Linux kernel
• Open ARM GPU drivers
• Introduction to C++11 and its use inside Qt
• A Continuous Packaging Pipeline
• Bootstrapping Debian-based distributions for new architectures

C’est donc un peu (beaucoup) trop technique pour moi. J’utilise Ubuntu mais en interface graphique la plupart du temps. D’ailleurs, si vous utilisez Ubuntu et Gnome Shell, voici le tutoriel pour personnaliser votre interface graphique comme la mienne. Le fait de patcher le kernel ou d’obtenir un kernel panic me fait peur tout comme le titre de ces talks! Pour le Kernel panic, j’ai subi ce message suite à une mise à jour du noyau, ce qui m’a obligé à tout réinstaller, autant dire que j’étais un utilisateur heureux.

Loin de ces talks compilo-assembleur, on décide d’aller voir la présentation sur le testing mis en place pour MediaWiki. MediaWiki, vous connaissez? Mais si! C’est la plateforme wiki utilisée par Wikipédia.

Comment le projet MediaWiki est-il testé?

L’équipe de MediaWiki utilise Watir pour faire des tests automatisés de l’interface utilisateur, et plus exactement Watir web driver qui se base sur Selenium. J’avais écrit un article sur Watin (un dérivé de Watir) il y a plusieurs années. Watin s’utilise en .NET, Watir en Ruby. Wat étant l’acronyme de Web Application Testing.

En résumé, cela vous permet de lancer des commandes depuis votre terminal et d’interagir directement avec votre navigateur. Vous pouvez ainsi lancer une recherche Google sans utiliser votre souris… Le pied, non? Bon OK, pas très utile au quotidien, mais dans le contexte d’une intégration continue, c’est bien. En plus, ils utilisent Jenkins!

Ils ont différents builds sous Jenkins, pour chacune des plateformes et navigateurs cibles (Chrome, Firefox, IE 6, 7, 8, 9, Android, iPad, iPhone). Un peu avant, j’avais justement vu Kohsuke entrer dans la salle, peut-être a-t-il un 6ème sens pour assister aux conférences impliquant son application!

L’équipe MediaWiki a donc écrit un ensemble de scripts correspondant à des scénarios haut-niveau. Nous sommes un peu dans le BDD (Behaviour Driven Development), le speaker en profite pour nous parler de Cucumber. Puis, il nous fait une démo avec comme scénario la connexion de l’utilisateur. Si un utilisateur a le profil administrateur, il peut accéder à des boutons additionnels dédiés aux tâches administratives. Pas d’effet démo, ça marche, le script a dû être testé et retesté.

Ce talk me rappelle l’expérience Selenium qu’on avait pu avoir dans mon ancienne boite et qui ne s’était pas révélée très concluante. On avait toujours des tests en échec à cause d’un timeout ou d’une raison inconnue, alors que les tests passaient encore la veille. Finalement, on ne les regardait même plus alors qu’ils pouvaient réellement signaler la présence d’une erreur. De plus, dès que l’on modifie l’application (CSS, structure html des pages), il faut revoir les tests IHM et cela devient vite chronophage.

Mais, le cas de MediaWiki est un peu différent. L’application est très stable en termes de fonctionnalités. Pour caricaturer, vous aurez toujours plusieurs profils d’utilisateur qui vont écrire des articles. L’application ne va pas être refondue du jour au lendemain. L’application est légère et simple dans le sens où vous n’avez pas de traitements asynchrones complexes type AJAX (cela est toujours dur à tester). Il y a des thèmes et les tests sont réalisés sur le thème par défaut. Celui-ci ne changera pas car le module de thèmes est justement là pour cela, les tests IHM sont donc peu impactés.

Enfin, j’assiste à un dernier talk qui, je dois le dire, m’a littéralement achevé. Le titre « Doit-on adopter les App Stores? » m’a paru séduisant, mais le fait qu’il fasse partie du parcours juridique aurait dû éveiller mes soupçons.

Doit-on adopter les App Stores?

Pas de slides projetés, 2 speakers, une discussion en anglais d’une heure autour des App stores sur des questions juridiques et légales. J’aurais dû m’enfuir, mais j’étais placé en face des speakers, hum, je suis resté par respect. Les mots-clés que j’ai pu griffonner avant de m’évanouir: Copyleft, GPL Licence V2-3, Warrantly…

Vous l’aurez compris, je n’ai pas suffisamment de matière pour faire un résumé sur ce sujet. Cela me fait quand même penser à un article que j’avais lu sur les App Stores. Sur le fait que dans le futur, ce qui rapportera le plus d’argent ne sera pas le développement des applications en tant que tel, mais leur distribution. Apple l’a bien compris en prenant un certain pourcentage sur la vente des applications payantes disponibles sur son App Store, ou bien Google avec Google Play. Et cela peut se généraliser à d’autres médias comme la musique avec la plateforme Apple iTunes. Sujet à méditer.

Un petit tour et puis s’en va…

Avant de partir, je rassemble mes dernières forces pour faire un tour du côté des stands.

Le cadre de Fosdem étant Open-source, on retrouve les différentes distributions Linux comme Ubuntu, Debian, OpenSuse, mais aussi Firefox, Gnome, KDE et j’en passe. Au passage, j’en profite pour glaner quelques stickers…

Je passe aussi par le stand d’Open Street Maps, la cartographie open source. J’avais écrit un article il y a quelque temps. Comme il m’arrive de mettre de l’huile sur le feu, j’engage une petite discussion OSM versus Google Maps.

Finalement, mise à part la partie App Stores, la journée est passée vite. Et je suis vraiment content d’avoir assisté à cette conférence, de surcroît gratuite et ouverte à tous. Je regrette un peu de ne pas pouvoir y être allé le dimanche. J’ai raté la présentation de Tug sur Couchbase, des sessions sur les « jeux sérieux » (serious games) et d’autres talks noSQL, mais on ne peut pas tout faire.

Rendez-vous en février 2014 pour apprendre quelques nouveaux pas de Fosdem Dance (entre autres)!