lundi 4 février 2013

Fosdem 2013, coté code


Tests automatiques, revues de code, refactoring et debuggage, voici le programme de cette première partie de mon compte rendu de FOSDEM 2013, le plus grand rassemblement européen de développeurs du logiciel libre. J’ai fait cette année le déplacement avec une troupe de Pythonistes dont beaucoup n’ont jamais atteint la track consacrée à Python, tellement il y avait de monde. Clairement cette manifestation croît d’années en années.

How MediaWiki is tested - Željko Filipin

Željko Filipin est en charge des tests fonctionnels sur MediaWiki, le logiciel qui motorise Wikipédia. Son challenge est  de créer et de maintenir des tests sur les différentes plateformes et browsers. La technique qu'il utilise est l'animation de browsers en utilisant Selenium avec un ensemble d'outils supplémentaires pour accélérer et simplifier le développement de tests. Son outillage est en Ruby, en parti parce que RVM facilite la mise en place de l'environnement de test. Il utilise la librairie watir.webdriver au dessus de Selenium et la classe PageObject qui simplifie grandement l'écriture des interactions avec la page. Les tests sont écrits sous la forme de scénarios de comportements Cucumber où chaque step est motorisé par un script Ruby manipulant ces PageObjects. Les scripts qu'il nous montre sont ceux réellement utilisés pour MediaWiki et sont pourtant véritablement très simples. La liste des tests est ainsi très lisible puisqu'elle est écrite sous la forme de scénarios fonctionnels en anglais. De la même façon lorsque leur intégration continu Jenkins hébergé sur CloudBees montre qu'un test est cassé sur une plateforme, le scénario complet est affiché. Pour plus de rapidité, Željko mets en place des tests en parallèle, ce qui nécessite des tests véritablement indépendants. Le plan de tests s'exécute en 8 à 12 minutes. Les tests sont effectués dans de vrais browsers et aussi pour plus de performance dans un phantom.js, un browser headless c'est à dire sans affichage. Ce dernier est en moyenne trois fois plus rapide qu'un browser normal mais aussi un peu plus difficile à debugger puisque, par définition, on ne voit pas l'écran. Željko indique que l'on peut tout de même tricher et demander à phantom.js de prendre un screenshot en cas d'erreur. De la même façon il utilise Saucelabs pour exécuter les tests et prendre des screenshots et des vidéos en cas de problème. Željko nous montre un exemple de bug sur la plateforme iOS ou une icône représentant une chaussure s'est ajoutée à un mot recherché. Il montre que ce bug provient d'une mauvaise interprétation par cet os d'un code spécial de touche, autant dire que sans screenshot ni vidéo la chance qu'un développeur songe à ce cas était très mince. Željko indique que son projet est disponible sur GitHub et est ouvert à des contributions, spécialement pour debugger IE ! 

The development infrastructure of the TYPO3 project - Steffen Gebert

Typo3 est un CMS en PHP qui est déjà un vieux projet puisqu'il a été créé en 1997. Il est piloté par la communauté et ce même si beaucoup de sociétés y contribuent. Typo3 s'est doté d'un environnement de développement collaboratif assez complet qui est le sujet de ce lightning talk. Pourquoi ne pas utiliser GitHub ? Typo3 préfère jouer les vieux sages et se souvenir des problèmes que faisait subir Sourceforge à ceux qui avaient choisi cette solution. Ils souhaitent posséder les données et l'infrastructure. Depuis plus de 10 ans, Typo3 utilise des mailing lists pour communiquer et prendre des décisions. Depuis une semaine seulement, ce projet s'est doté d'un forum qui est synchronisé de manière bi-directionnelle avec les listes. La forge à proprement dit est basée sur Redmine et comporte 2400+ projets. Steffen dit qu'une fonctionnalité importante est l'annuaire de la communauté que constitue la liste des membres de chaque projets. Il admet par contre avoir certains soucis avec le bug tracker qu'ils utilisent. Le code source est partagé par Git depuis 2010. Cela leur a permis de mettre en place un portail de revue de code basé sur Gerrit Code Review. Avant chaque merge ce portail permet de valider les contributions mais aussi de les améliorer en les commentant. Cette étape permet à tout le monde de contribuer et facilite l'apprentissage par les retours de la communauté puisque chaque revue est publique et transparente. En complément ils utilisent sur leur intégrateur continu TravisCI des logiciels tels que PHPLint et PHP CodeSniffer pour assurer la qualité et l'homogénéité du code. Leur infrastructure porte également l'effort de traduction et de documentation du projet. Voilà qui peut expliquer la vitalité de ce vieux projet, tout a été fait pour que l'on puisse y contribuer.

LibreOffice: cleaning and re-factoring a giant code-base - Michael Meeks


LibreOffice est l'un des rares logiciels qui aient le pouvoir de me faire gueuler devant mon ordinateur, c'est une vraie peine à utiliser et une pierre dans le jardin du logiciel libre puisqu'il n'existe pas d'alternative crédible (non, Apache OpenOffice n'est pas une alternative crédible). Imaginez la peine que ce vieux code fait à tous ceux qui ont la folie d'y coder ! Dans une présentation menée tambour battant, Michael Meeks nous offre un tour d'horizon des efforts de refactoring réalisés pour la sortie de LibreOffice 4, pour enfin payer la dette technique. En préambule, il dit que le plus important dans un projet n’est pas son code ou son outillage mais bien la culture partagée par sa communauté. Une culture devenant trop frileuse et ayant peur du changement peut tuer une communauté. Les équipes souhaitent inverser la tendance et rendre facile et fun le fait de contribuer au projet. Tout le monde peut dorénavant proposer un patch sans en demander l’autorisation, sans même avoir à créer un compte puisqu’ils utilisent un portail Gerrit couplé à une authentification OpenID pouvant être faite avec un simple compte Gmail par exemple. Gerrit permet la revue du code proposé par la communauté et son intégration dans le produit. Autre moyen mis en œuvre, un ferme de build est disponible et le builder a été migré du spécifique dmake au standard gnumake. Michael commence alors une énumération de dizaines de petites mesures prises pour rendre le code lisible et hackable. Le nouveau LibreOffice a par exemple plus de deux fois moins de commentaires en langue allemande, sachant qu’il en reste tout de même encore 20.000 lignes. LibreOffice avait le luxe de comporter quatre classes distinctes pour représenter une simple chaine de caractères, il n’en comporte maintenant plus que trois. En utilisant massivement CppCheck ils ont réussi à générer et appliquer 1000 patchs. Ils ont en même temps retiré une bonne part du code mort de l’application. Un effort commence a faire un meilleur usage des structures, en se reposant sur la STL et Boost. Il apparaît pour qui analyse la structure même de LibreOffice que des choix anciens et inappropriés faits à l’époque où ce projet était une simple démo sont toujours là par fétichisme, dit Mickael. Sa démarche est de montrer ces changements et de remercier tous ceux qui y ont contribué afin de démontrer que le projet est vivant et abordable. Ils ont aussi simplifié grandement le Bugzilla afin de ne pas intimider les utilisateurs lorsqu’ils souhaitent déclarer un problème. Alors que par le passé les problèmes de qualité avaient poussé la gouvernance du projet à rigidifier le processus de contribution et de correction des bugs, la nouvelle culture est au contraire de ne rien interdire à moins d’avoir vraiment une excellente raison et de corriger très vite, même si c’est au coût de régressions. Un outil de recherche de régressions a été mis en place basé sur le concept de git bisect mais utilisant directement des binaires afin de gagner du temps. Alors que 90% des chaines de caractères sont en UTF16, gdb ne le supportait pas et on ne pouvait pas lire ces chaînes dans le debugger, c’est à présent corrigé. Le projet reçoit en moyenne 50 commits par jour créant 2,5 régressions chaque jour. Avec un meilleur outillage et une communauté réactive le temps de vie des bugs diminue et le coût des régressions est contre balancé par le bénéfice d'une communauté forte. Mickael termine sa présentation par un tour des nouveautés fonctionnelles de LibreOffice 4 qui sortira prochainement. Une présentation riche et inspirante car démontrant beaucoup de pistes sur un chemin difficile

Finding and fixing performance problems in Calc - Markus Mohrhard 

La performance est un sujet difficile et ingrat, spécialement lorsque c’est dans LibreOffice ! La preuve ? C’est devant une salle quasiment vide que Markus Mohrhard a courageusement débuté sa présentation. Il indique que la difficulté principale est qu’un logiciel tel que Calc a des usages très différents : une ou mille feuilles ? 10 ou 10.000 cellules ? Avec le temps, 10 moyens différents de stocker la référence d’une cellule ou d’un range ont été inventés, Markus dit qu’il ne les connaît pas tous. Pour identifier la cause d’un problème de performance, faire une supposition n'est pas une bonne méthode. Il recherche à expérimenter quelle est la partie du code qui est la plus exécutée. Les méthodes pour identifier les goulots sont classiques. Dans un premier temps il exécute le code dans un debugger et l’interrompt en cours de traitement et examine la stacktrace afin de trouver où se passe le temps d’exécution. Une autre stratégie consiste à utiliser un profiler, Callgrind en l’occurrence, pour mesurer le temps d’exécution et rechercher ce qui consomme le plus. Après une démo de l’outil, je suis persuadé que Markus a montré comment il corrige ces problèmes avec brio, mais, mais... j'ai dû partir avant la fin pour prendre mon train, délestant ainsi la salle de 20% de son audience ;)

Vous trouverez bientôt la suite de ce compte rendu. A suivre !
crédit photo : Stéphane Bagnier

1 commentaire:

  1. Des conférences sur la programmation très intéressant, peu importe qui enseigne. Si vous voulez la connaissance, c'est la meilleure façon pour lui. Si vous voulez résoudre un problème technique, vous avez besoin de http://fr.fix4dll.com/msvcr100_dll. Vous pouvez l'utiliser dans le travail du testeur.

    RépondreSupprimer