La culture de l’innovation chez Antidot : les conférences

Un éditeur de logiciels innovants se doit d’entretenir une culture de l’innovation au sein de ses équipes. Chez Antidot, nous utilisons plusieurs outils pour cela : les Brown Bags, les Ship It, le développement de prototypes, la publication de logiciels en Open Source

Il est important de compléter cette palette en ajoutant de l’entropie – être ouvert à d’autres idées, à des méthodes de travail alternatives – et en veillant à rester informé des dernières évolutions des techniques, langages et frameworks que nous utilisons. Pour cela nos développeurs participent à des évènements, grands ou petits, locaux ou internationaux, tout au long de l’année.

L’objectif de ce billet est de vous présenter les nombreux évènements auxquels nous avons participé en 2015. Chacune de ces manifestations est illustrée par le témoignage d’un développeur qui y a participé :

FOSDEM – 31 janvier et 1er février 2015, Bruxelles

Aurélien : « J’ai eu l’occasion d’assister au FOSDEM à Bruxelles en 2012/2013/2014/2015.Un moment formidable pour rencontrer et échanger avec la communauté open source et les représentants de ses projets les plus populaires : Linux, Firefox, Gnome, KDE, Python, … Tout ça autour d’une bonne bière belge et d’environ 5000 amis barbus. Vivement le FOSDEM 2016 et son 5ème t-shirt pour tenir toute la semaine. »

Devoxx France – 8-10 avril 2015, Paris

Hervé : « Devoxx France, c’est l’occasion de découvrir de nouveaux outils, de nouvelles bibliothèques mais aussi d’avoir des retours d’expériences. »

Mix-It (16-17 avril 2015, Lyon

Mathias : « Outre le fait que Mix-It permet de prendre du recul sur son travail quotidien, les diverses conférences et ateliers sont des lieux pour rencontrer des gens passionnés et passionnants. Alors n’hésitez pas à participer à ce type d’événement ! »

Riviera Dev – 11-12 juin 2015, Sophia-Antipolis

Jonathan : « 2015, l’année du reboot de Riviera Dev. Après une dernière édition annulée faute de participants, la conférence du soleil renaît, poussée par un crowdfunding auquel nous autres sudistes nous devions de contribuer.

Si petite en renommée elle est encore, grande en qualité Riviera Dev est déjà ! Durant deux jours, les tracks sur Java et le Web s’enchainent. Et parmi les intervenants, on retrouve des pointures de Java (Rémi Forax, Emmanuel Bernard…) et de son écosystème (Tugdual Grall…), mais on découvre aussi de très prometteurs speakers (Hubert Sablonnière…). Et pour varier les plaisirs, il était aussi possible de s’attaquer aux ateliers sushis et DJaying !

Et puis parce que dans le Sud on sait recevoir, on retiendra aussi l’excellent buffet et la socca à volonté, le tout sous un soleil brûlant ! Riviera Dev, à suivre et à soutenir ! »

DockerCon – 16-17 novembre 2015, Barcelone

Charles : « Faire le déplacement à Barcelone pour la DockerCon 2015 m’a permis de sortir de mon cadre de travail habituel pour découvrir d’autres façons de travailler et échanger avec des développeurs du monde entier !

Liste des points positifs : une prise de recul sur son travail et l’environnement qui va avec, de nouvelles idées à mettre en place dans l’entreprise, l’envie de partager avec les collègues, un regain de motivation pour améliorer la qualité de son travail et sa productivité, une synergie accrue avec les développeurs qui ont fait le déplacement ensemble. »

Agile Grenoble – 19 novembre 2015, Grenoble

Benjamin : « Agile Grenoble 2015, une conférence qui permet de découvrir des méthodes utiles au quotidien pour plus d’efficacité et de convivialité dans le développement, et également pour se poser plein de questions sur nos habitudes quotidiennes! »

DevOps Day – 20 novembre 2015, Marseille

Franck : « Il est agréable dans notre région d’avoir désormais un évènement avec des intervenants de qualité, sans trop de langue de bois, et qui amène à une réflexion sur l’évolution de nos métiers et de leurs outils.

Le discours est plutôt orienté technique, avec des retours d’expériences concrets qui donnent une valeur inestimable à ce genre d’évènement. J’espère que la sauce va prendre et que la prochaine édition sera aussi bien que cette première édition. »

NDLR: le terme "bull*t" du texte original a été remplacé par "langue de bois" :-)

Nous participons également à des réunions « locales » plus courtes, en soirée,

Mars Jug – environ tous les deux mois

Olivier : « J’aime aller au MarsJug car on se fait une ou deux voitures de développeurs et on débat entre nous pendant toute la route Lambesc – Marseille !! Souvent, on trouve un speaker sympa et très accessible car c’est un JUG où nous sommes peu nombreux. Ensuite on refait un roadtrip pour rentrer avec en plus le défi de trouver un Quick ou un MacDo ouvert tard le soir. C’est la belle vie !! »

NDLR : Et les Burger King alors ? :-)

Meetups Docker – 16 avril et 16 juillet 2015, Aix en Provence

Benoit : « Les meetups Docker nous ont permis de rencontrer d’autres industriels de la région qui travaillent sur des problématiques proches des nôtres. Le retour d’expérience a été enrichissant. Ces rencontres nous ont même permis de recruter ! »

Nous avons par ailleurs présenté des sessions dans les conférences suivantes :

Agile Aix/Marseille 2015 – Aix en Provence

« Vos tests on besoin d’amour » par Benoit Sautel, qui tient le blog « Fier de coder« .

Blend Web Mix 2015  – 28-29 octobre 2015, Lyon

« Web sémantique, web de données : et si on passait à la pratique » par Pierre Col et
Julien Homo.

Julien Homo : « Pour moi l’originalité de BlendWebMix repose principalement sur sa capacité  à proposer des conférences à un public très hétérogène avec un contenu au périmètre très large. On peut à la fois écouter par exemple Laure Wagner nous raconter l’impressionnante croissance de sa société Blablacar et inversement assister au touchant témoignage de Simon Dawlat qui raconte la chute de son entreprise AppGratis et la vertigineuse descente aux enfers subie ensuite par son équipe. D’un point de vue plus technique, Stéphane Bortzmeyer nous apprend qu’il est possible de hacker directement des registres de noms de domaines tandis que le graphiste Christophe Tauziet de Facebook nous met en garde sur l’impact qu’engendre la moindre modification d’une interface vue par des milliards d’utilisateurs. Autant de sujets à la fois riches, variés et animés par des présentateurs souvent très dynamiques font pour moi de cette conférence un rendez-vous incontournable des différents acteurs du Web d’aujourd’hui et de demain. »

Enfin notre pôle Recherche a animé deux sessions pédagogiques en la personne de Ludovic Samper :

« En 2015, j’ai eu l’occasion de présenter nos travaux à deux occasions : aux élèves de l’ENS de Lyon et lors de l’école d’été WISS. C’est très plaisant de présenter nos travaux au monde de la recherche. Le travail de préparation permet toujours de mieux cerner son sujet. Et surtout, les chercheurs et les étudiants sont intéressés par les problématiques que l’on rencontre dans un contexte plus industriel que le leur. Cet échange peut être l’occasion de commencer des collaborations ou des stages. »

Conférences auxquelles Antidot a participé en 2015

Si vous êtes tentés par l’aventure, si vous voulez participer avec nous à ces évènements…

Antidot recrute !

Antidot à la Web Intelligence Summer School

WISS 2015
La Web Intelligence Summer School 2015 a eu lieu du 31 août au 4 septembre à l’Université de Saint Étienne.

La thématique cette édition 2015 était « Répondre à des questions avec le Web » :

  • Publication de données web : données liées Linked Data,  normes et techniques du web sémantique / web des données
  • Comprendre et analyser une question en langage naturel : NLP / traitement du langage naturel
  • Trouver des données pour répondre à la question et à justifier la réponse : intégration / curation / extraction de données
  • Présenter les réponses : représentation graphique et  visuelle

Vous trouverez ici le programme complet de la Web Intelligence Summer School.

Membre de l’équipe Recherche d’Antidot, Ludovic Samper y a donné mardi 1er septembre de 10h30 à 12h30 un cours de 2 heures sur les techniques d’apprentissage automatique – machine learning. Il y a parlé plus spécifiquement de classification supervisée utilisant scikit-learn, et détaillé certains algorithmes comme NB  – Naïve Bayesian, classification naïve bayésienne – et SVM – Support Vector Machine, machine à vecteurs de support.

Résultats de différents classifieurs avec scikit-learn – cliquez sur l’image pour l’agrandir

Si vous n’avez pas pu y assister, en voici le contenu (en anglais) :


This is all the materials for the course:

The tutorial is about supervised classification of text documents. I’ve presented some classical algorithms (Multinomial Naïve Bayes, Support Vector Machine) and the maths behind. To illustrate the course, I used scikit-learn library and the 20newsgroups dataset.

The slides are here:

And you’ll find here the code I shown using iPython notebook:


 

Partenaires de cet événement :

Université Jean Monnet Laboratoire Hubert Curien École des Mines de Saint Étienne Telecom Saint Étienne CNRS Bonn Universität Fraunhofer Institut

Continuous integration, Continuous delivery, Continuous deployment : où en est-on chez Antidot ?

L’équipe Delivery a la responsabilité de la mise en place des outils et des process de l’équipe technique chez Antidot. Dans ce cadre, elle développe puis opère les chaînes d’intégration continues de nos produits logiciels.

Je me propose de vous faire un retour d’expérience basé sur notre pratique.

De quoi parle t-on ?

L’intégration continue (continuous integration dans la littérature anglo-saxonne) implique que les développements logiciels sont régulièrement intégrés sur une branche commune sur laquelle sont automatiquement déroulées toutes les étapes de compilation et de validation.

La livraison continue (continuous delivery) est la suite logique de l’intégration continue : elle implique qu’à chaque moment on est « prêt à livrer » une version. La sortie de l’intégration continue devient donc le livrable attendu.

Le déploiement continu (continuous deployment) représente le Graal des équipes DevOps : chaque commit, s’il n’introduit pas de régression, finit automagiquement en prod.

(source IamOnDemand)

Continuous Integration

Depuis 5 ans, nous avons mis en place des chaines d’intégration continues, de plus en plus complètes.

A ce jour, chaque commit dans git sur une des branches de référence déclenche séquentiellement :

  • La compilation et les tests smalls,
  • le packaging (.deb et .rpm) et la création de dépôts dédiés à la validation,
  • des tests dits « medium » puis des tests dits « larges ».

Les dénominations de tests « small », « mediums » et tests « larges » viennent de l’excellent livre « How Google tests software », dont vous trouverez ici un résumé en français et qui propose une classification des tests en small, medium et large.

  • Un test small valide une unique fonction, avec une granularité très fine
  • Un test medium implique un ensemble de « modules » qui collaborent pour réaliser une fonction
  • Un test large implique le système entier.

Les problèmes que nous avons rencontrés lors de la mise en place de ces chaines d’intégration continue tournent autour de deux thèmes :

  • L’instabilité chronique des chaines,
  • Le temps d’exécution de ces chaines.

La solution au premier point réside dans l’analyse systématique des erreurs pour essayer d’en éliminer les causes racines. Je pense qu’on pourrait faire un article entier (et d’ailleurs je le ferai peut être) sur toutes les raisons, bonnes ou mauvaises, qui font qu’une chaine d’intégration continue est instable.

Pour le second point, nous n’avons pas à ce jour de solution satisfaisante : après avoir facilité l’écriture de tests, mis en place des outils pour les jouer automatiquement, réussi à convaincre tout le monde de l’intérêt de produire un maximum de tests, nous sommes aujourd’hui confrontés au problème de l’adhésion de tous à ces principes, et donc nos suites de tests augmentent et leurs temps d’exécution s’allongent.

D’aucuns diront que c’est un problème de riche, mais il faudra assez rapidement que nous nous attaquions à ce problème.

Continuous Delivery && Continuous Deployment

Les chaines d’intégration continue installent toutes les nuits la meilleure version disponible (RC pour « Release Candidate ») dans un environnement simulant la production.

À tout instant, une version est donc prête à livrer, et en ce sens nous respectons le Continuous Delivery.

En pratique, nous livrons une version toute les semaines et chacune de ces versions est mise en production.

Qu’est ce que signifie livrer pour nous ?

  • positionner un numéro de version sur un SHA-1 git,
  • communiquer sur la disponibilité de cette version (mail, tweet),
  • communiquer (Release Notes) sur le contenu fonctionnel de la version : nouvelles fonctionnalités, corrections de bugs…
  • mettre à disposition des paquets dans un dépôt stable.

Pourquoi doit on livrer ?

La question peut surprendre, mais dans un monde où une part significative des développements est exploitée en mode Cloud, la notion de numéro de version peu avoir un coté archaïque. Si l’on applique à la lettre les principes du Continuous Deployment, la version en production est la dernière qui a passée toutes les validations, et la notion de livraison telle que décrite ci dessus s’estompe.

Pour autant, nous ne somme pas prêt à abandonner la notion de livraison car en plus d’opérer notre propre solution dans notre datacenter, nous livrons aussi  nos logiciels en licence et nous fournissons notre plateforme à des partenaires qui construisent des solutions par dessus.

Dans ces deux derniers cas, les clients peuvent attendre des fonctionnalités ou des corrections de défauts, qui doivent être corrélées à des versions.

Le Delivery Train

La pratique de livrer systématiquement toutes les semaines la meilleure version possible (la dernière ayant passée avec succès tous les tests disponibles) est inspirée du « Delivery train » prôné par Spotify. Par ailleurs, c’est un premier pas vers le « Continuous Deployment ».

Avant la mise en place du Delivery Train :

  • la livraison d’une version, son périmètre fonctionnel, sa date de sortie était le résultat d’âpres négociations entre développeurs et chefs de projet, arbitrées par l’équipe Delivery.

Depuis la mise en place du Delivery Train, la livraison est systématique le vendredi et cela a :

  • enlevé du travail inutile et chronophage de négociation de date et de contenu,
  • rassuré tout le monde : si on rate un créneau pour une correction, le suivant n’est jamais que dans une semaine dans le pire des cas,
  • fortement amélioré l’automatisation du mécanisme de livraison : ce sont les effets bénéfiques du classique : « if it hurts, do it more often » cher à toutes les pratiques d’automatisation
  • et donc bien évidemment, facilité le non respect de la règle : en cas d’urgence (bug critique…), nous relivrons immédiatement. Et les gains en automatisation du processus de livraison facilitent cette livraison supplémentaire.

Continuous Deployment

Antidot ne fait donc pas aujourd’hui de Continuous Deployment. Mais un des effets bénéfiques du Delivery Train est que l’on y va doucement mais sûrement, poussés par le train.

En effet, la mise à disposition toutes les semaines d’une nouvelle version, nous a poussé à essayer de la mettre en production dans la foulée.

Nous sommes à nouveau dans un mode « if it hurts do it more often » :

  • nous avons mis à plat les processus de mise en production,
  • nous avons systématisé un calendrier,
  • nous sommes actuellement en train de travailler à rendre ce process aussi automatique que possible.

À moyen terme notre objectif sera donc une livraison hebdomadaire de version et le déploiement automatique de cette version sur notre production.

Je ne sais pas dire aujourd’hui si nous irons vers le Continuous Deployment au sens strict de la définition. Je dirais que nous n’en n’avons jamais été aussi près, et je vous en reparlerai dans quelques mois, lorsque nos objectifs moyens termes seront atteints.

Références :