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

Ship It Day Antidot – première édition !

Les 19 et 20 mars derniers se tenait le premier “Ship It Day” dans les locaux de la R&D d’Antidot à Lambesc (13).

Le Ship … quoi ?

A l’origine initié par la société Atlassian, le Ship It Day est une opportunité donnée aux employés de travailler en 24 heures sur un projet de leur choix, en rapport avec le produit et l’activité de l’entreprise, en vue de le livrer à l’issue de la journée, avec une seule règle : « Pas de règles ! ».

Cette manifestation est une occasion pour l’entreprise de promouvoir l’innovation en mettant différentes équipes en concurrence. Oui, mais dans quel but ?

La raison est simple : qui n’a jamais entendu ce genre de remarques à la machine à café ?

« Ce serait vraiment pratique que cet outil permette de faire ça, ça et puis aussi ça »

« Je ne comprends pas, ce produit là ne se vend pas autant qu’on aimerait »

« Pfff, je ne me souviens jamais comment fonctionne cette appli… en même temps elle n’est pas vraiment intuitive ! »

En effet, pendant le Ship It Day, ces équipes vont enfin pouvoir développer ce plugin qui manque depuis si longtemps, repenser une fonctionnalité que personne n’utilise, redessiner une interface, etc.

Or le pilotage quotidien de ces équipes, la pression liée aux cycles de développements dans le respect scrupuleux de la roadmap ne permet guère de laisser parler la créativité des collaborateurs…

Pourquoi c’est cool ?

ShipItDayLe Ship It Day est avant tout une aventure humaine, ludique, faisant de l’évènement un vecteur d’émulation très fort. Cela permet de faire une pause dans le train-train quotidien, tout en avançant rapidement sur des projets, au final relativement aboutis.

C’est également l’occasion pour les collaborateurs, en sortant du cadre de travail habituel, de travailler et d’échanger avec des personnes qu’ils n’ont pas toujours l’habitude de côtoyer. Une réelle synergie inter-équipes se crée alors dans une ambiance très conviviale.

Enfin, certains prototypes réalisés au cours du Ship It Day pourront devenir des fonctionnalités du Produit, qui, une fois industrialisées, seront déployées en production.

Une première chez Antidot ?

Antidot est cependant coutumier du fait, puisqu’il s’agit en réalité du troisième évènement de ce type en trois ans, avec deux précédentes éditions sous la forme de “Hackathon”. À deux reprises déjà, il s’agissait de proposer un prototype destiné à faire avancer le Produit, réalisé à l’issue d’un marathon de développement d’une semaine,.

Néanmoins, bien que suscitant un réel intérêt au sein des équipes de développement, la durée pour ces hackathons s’est finalement avérée trop longue pour pouvoir les maintenir et les renouveler à un rythme régulier.

Cette année, la société a donc adopté le format Ship It, plus court, pouvant ainsi être reconduit régulièrement.

Comment ça marche ?

Le Ship it se déroule en plusieurs phases :

J – 2 mois : Lancement

La date à laquelle aura lieu le Ship It est annoncée aux collaborateurs.

J – 1 mois : Ship It order

Les collaborateurs peuvent proposer des projets. Il n’y a pas de contraintes sur le nombre de projets soumis par personne, ni sur le thème sur lequel ils vont participer.

Un projet peut même être proposé 5 min avant le début du Ship It Day, le jour J.

J – 1 semaine : Brown bag

Les personnes porteuses d’un ou plusieurs projets et ayant besoin d’autres collaborateurs peuvent, uniquement s’ils le souhaitent, présenter leur projet à l’ensemble de la société afin de recruter et constituer leur équipe.

Jour J :

Chaque équipe annonce le thème de son projet et la composition de l’équipe

Le concours débute un jeudi matin à 11 h pour se terminer le lendemain à la même heure.

Durant ces 24 h, ce sont les managers qui se chargent de l’intendance : pauses avec café / gâteaux / bonbons, pizza party le soir, petit déjeuner le matin, etc.

C’est une occasion unique de pouvoir se faire servir une bière par son manager !  😉

Les équipes constituées préparent ensuite des démonstrations de 5 min sur leurs prototypes, en vue de les présenter à l’ensemble de la société. Une fois les démonstrations terminées, l’ensemble des collaborateurs peut voter pour élire le projet vainqueur du Ship It Day. S’en suit alors une “party” digne de ce nom, afin de célébrer les vainqueurs et l’ensemble des participants à l’évènement.

A quand le prochain?

KeepCalmShipItAprès cette première édition fin mars, la prochaine est prévue les 18 et 19 juin prochains. Au total, ce seront donc quatre Ship It Day qui seront organisés par an, au rythme d’un par trimestre.

Lors du Ship It Day du mois de mars, entre les collaborateurs sur les pistes de ski, en déplacement professionnel ou tout simplement indisponibles, les projets ont principalement été réalisés par les équipes de la R&D.

Mais le Ship It Day a bien évidemment vocation à faire interagir le maximum de collaborateurs, quelles que soient leurs équipes de rattachement : chefs de projet, staff marketing, support client, etc. Nul doute que la prochaine édition verra encore plus de collaborateurs dans les équipes engagées.

Vivement la prochaine édition !

Et vous, dans votre entreprise, ça se passe comment le Ship It Day ? 🙂

P.S. : si notre approche autour des Ship It Days ou des brown bags vous intéresse et si vous êtes tenté de nous rejoindre cela tombe bien, on recrute ! Et pour ne rien vous cacher, nous avons expliqué sur ce blog comment se déroule le processus de recrutement à la R&D d’Antidot.

Architecture multi-tenant, une fausse bonne idée ?

Chez Antidot, nous avons une équipe R&D qui rassemble des développeurs de profils assez variés. Le terme de « développeur » ne doit pas être pris dans un sens réducteur, car ce sont des hommes et des femmes passionnés par leur métier, et qui non seulement codent bien des logiciels complexes mais qui, en plus, sont capables de prendre du recul sur leur métier et s’intéressent à l’évolution des technologies de l’informatique et de l’Internet, qu’elles impactent directement leur activité ou pas.

Aujourd’hui, nous avons choisi de partager sur le blog Antidot un billet écrit par Benoît Sautel, l’un de ces ingénieurs, qui partage depuis plus d’un an ses idées de « développeur passionné », comme il se définit lui-même, sur son blog « Fier de coder ».


 

Les concepts de Software as a Service ou de Cloud Computing sont de plus en plus répandus dans l’informatique d’aujourd’hui. Cela a pour conséquence que les éditeur de ogiciel ne vendent plus directement un logiciel mais le service que rend leur logiciel. Cette nouvelle façon de déployer du logiciel a changé la donne dans la façon dont sont conçus ces mêmes logiciels.

Vers un déploiement simplifié

Les architectures multi-tenant (multi-entités ou multi-locataires en français) ont vocation à faire en sorte qu’un logiciel soit capable de gérer un certain nombre de clients en une seule installation. Au lieu d’installer le logiciel une fois pour chaque client, ce dernier est capable de créer des environnement virtuels distincts pour chaque client de sorte à ce que de l’extérieur les autres environnements ne soient pas du tout visibles. En fin de compte, le logiciel répond lui-même aux problématiques de déploiement.

Dans le contexte d’un prestataire de service qui souhaite vendre son service à différents clients, l’architecture multi-tenant semble être la réponse évidente. Il suffit de déployer le logiciel une fois et de créer autant d’environnements que nécessaire, et le tour est joué. L’administration d’un tel système est, du coup, relativement simple.

Au prix d’une grande complexité dans le code

Je travaille en ce moment sur une application web basée sur une architecture multi-tenant. Et clairement ce type d’architecture a un coût dans le développement. Ce coût étant principalement dû à la complexité engendrée. C’est la raison pour laquelle je m’interroge à ce sujet.

Pour assurer l’isolation et l’indépendance des différentes instances, il me semble assez important de séparer les données de chaque instance dans une base de données dédiée. C’est une meilleure garantie de l’indépendance des données, mais c’est également pratique lorsqu’il s’agit de récupérer les données d’une instance pour transférer l’instance sur un autre serveur.

Tout cela implique qu’il n’est pas possible de considérer la base de données comme unique. On ne peut donc pas y accéder via un singleton dont on délègue d’ailleurs volontiers la gestion à notre outil de gestion de dépendances. Le connecteur à la base de données n’est plus un singleton, ce qui signifie que tous les composants qui s’en servent ne peuvent plus non plus être des singletons. D’ailleurs, la configuration du logiciel ne peut plus être non plus un singleton puisqu’il y en a une par instance. Bref, la perte de cette unicité limite très franchement le gain apporté par les outils et principalement ceux qui se chargent de l’injection de dépendance. Un peu comme si on retournait dans le passé.

Le code métier a bien souvent besoin de connaître sur quelle instance il travaille. Un objet représentant l’instance actuelle est ainsi passé en paramètre de la plupart des appels métier. La complexité de l’ensemble du code augmente ainsi fatalement et la testabilité prend du plomb dans l’aile. Difficile de faire du code simple dans une telle architecture.

De plus, une architecture multi-tenant ouvre une nouvelle gamme de risques de sécurité. Il n’est en effet pas envisageable qu’on puisse accéder à des données d’un autre environnement et encore moins de pouvoir les modifier. Pourtant, c’est le même code sur la même machine qui va gérer l’ensemble des environnements. Le risque est bien présent.

SaaS et architecture multi-tenant sont-ils vraiment compatibles ?

L’architecture multi-tenant a de nombreuses qualités quand il s’agit d’exploiter le logiciel en Software as a Service. Le logiciel sait nativement gérer lui-même l’ensemble des instances. Mais cela implique des contraintes auxquelles on ne pense pas forcément au départ.

Lors d’une mise à jour, si une régression est introduite, elle affectera immédiatement l’ensemble des clients. C’est un risque qu’il faut accepter de prendre, mais il peut être largement réduit en travaillant sur la qualité du logiciel. De la même façon, il est préférable de mettre à jour un logiciel à un moment où il est peu utilisé. Un logiciel multi-tenant implique de mettre tout le système à jour en même temps. Si les clients sont localisés un peu partout dans le monde, il est difficile de trouver un moment où tout le monde dort.

En général, un logiciel en SaaS est régulièrement mis à jour et évolue au fur et à mesure. Dans certains cas c’est tout à fait acceptable, si on considère par exemple que le service fourni par le logiciel se présente sous la forme de web services dont la rétrocompatibilité est assurée, les clients n’ont pas de raison de ne pas accepter les mises à jour. C’est davantage problématique quand le produit se présente sous la forme d’une interface graphique qui évolue régulièrement. Certains clients refusent catégoriquement que leur instance évolue et donc soit mise à jour.

Une architecture multi-tenant ne permet pas de mettre à jour certaines instances et pas d’autres. Il faut alors créer différentes installations du logiciel, chacun sur une version donnée. Et si on n’a pas de chance et qu’on n’arrive pas à trouver un petit nombre de versions pour satisfaire tout le monde, on se retrouve vite à déployer chaque client dans une installation distincte. Et là on a tout perdu. On a payé le surcoût lié à la complexité d’une telle architecture et on ne peut pas en profiter. Pire encore, on se retrouve à devoir quand même gérer une multitude d’installations, précisément ce qu’on souhaitait éviter au début.

Dev ou Ops ?

Se demander si les architectures multi-tenant sont pertinentes revient finalement à se demander où nous devons placer le curseur entre les parties Dev et Ops.

Dans les débuts de l’informatique, la moindre machine coûtait tellement cher qu’il était important d’optimiser chaque ligne de code assembleur des programmes de façon à économiser la moindre instruction processeur. Un gros investissement dans le développement des logiciels était nécessaire pour qu’ils soient capables de tourner sur des machines coûtant un prix raisonnable.

Mais, depuis ce temps-là, le monde de l’informatique a beaucoup changé. Les machines coûtent de moins en moins cher alors que leur puissance augmente, les réseaux se sont énormément développés, si bien qu’on n’achète même plus nous-même les machines mais qu’on paie un service d’hébergement (Infrastructure as a Service).

La virtualisation est venue ajouter une nouvelle dimension dans l’hébergement. Aujourd’hui, Docker est en passe de révolutionner une nouvelle fois ce domaine. On parle de plus en plus de Platform as a Service.

Tout cela est possible parce que le prix du matériel baisse sans cesse alors que sa puissance augmente. L’outillage s’est également adapté à ces changements et il est maintenant possible de gérer un parc de machines de manière quasiment automatique.

En parallèle de cette évolution en terme de technique, l’informatique est également de plus en plus populaire et même omniprésente. Mais le nombre de développeurs n’augmente pas aussi vite. Et jusqu’à nouvel ordre, il n’existe pas vraiment d’outils permettant d’automatiser le travail du développeur. Et heureusement pour nous !

Le curseur entre Dev et Ops s’éloigne petit à petit du développement. Il n’a jamais été aussi facile de déployer et d’exploiter du logiciel en masse (et ça sera certainement encore plus simple dans le futur).

Quel est le bon choix ?

Si la tendance actuelle se poursuit dans la même direction (ce qui me semble tout à fait probable), le déploiement sera de plus en plus automatisé et coûtera de moins en moins cher. Il me semble donc que dans le futur les architectures multi-tenant seront de moins en moins intéressantes.

Mais dès aujourd’hui, il me semble que le choix de partir sur une architecture multi-tenant n’est plus une évidence. Le logiciel en lui-même doit-il porter toutes les contraintes liées à son déploiement et la complexité qui va avec ? Grâce aux évolution des outils de déploiement, il est maintenant tout à fait possible de mettre en place en parallèle du logiciel une infrastructure de déploiement automatisée associée qui se charge de gérer ses différentes instanciations avec à chaque fois une configuration et une version bien précise. Ne vaut-il pas mieux développer deux systèmes distincts pour ne pas accumuler toute la complexité au même endroit ? Cela permet d’avoir à la fois un logiciel simple et toute la souplesse nécessaire au niveau du déploiement et de la gestion des différentes versions. N’est-ce finalement pas le moyen d’avoir le beurre et l’argent du beurre ?

L’image d’en-tête provient de Flickr.


Retrouvez les autres billets de Benoît sur son blog.

Et si vous avez envie de travailler chez Antidot, regardez les postes à pourvoir et écrivez-nous !