Réunion Dev@LAL 53

mercredi 14 déc. 2016, 10:30 → 11:30 Europe/Paris

166 (LAL)

Veille technologique et réseaux sociaux

Le sujet principal de cette réunion était la veille technologique, et plus précisément les outils que chacun d'entre nous utilise pour se tenir au courant de l'évolution de l'informatique.

Veille technologique

Dans le comité de pilotage LoOPS de la veille, où Antoine et David étaient présents, il a été évoqué la création possible d'un comité de veille technologique pour le réseau. Cette idée dérivait de la constatation que chacun d'entre nous voit passer beaucoup d'informations intéressantes, mais les partage peu.

Historiquement, partager les infos de veille était une des missions de PLUME au CNRS. Mais actuellement, l'application est en arrêt, et son successeur FENIX n'est pas encore là. Pour se tenir informé de son développement, on peut s'inscrire à la mailing list fenix-news.

Hadrien a mentionné le fait que vu le flux d'information dont on se fait bombarder tous les jours, si on veut mettre en place un outil de partage, il doit être aussi simple que possible pour que les gens l'utilisent, du genre copier-coller un lien et ajouter une toute petite légende. C'est aussi l'expérience d'Antoine, qui voit passer beaucoup d'informations intéressantes via Twitter.

Cette question du flux est un problème plus général de la veille technologique:

• On voit passer énormément d'infos, et on n'en étudie que la petite fraction qui nous intéresse (choix personnel)
• Il est très facile de se retrouver débordé par les nouvelles infos au point de devoir abandonner les anciennes, et certaines plate-formes comme Twitter vont jusqu'à supprimer ces dernières automatiquement de façon assez agressive.
  • Pour les sources d'information qui ont un flux RSS, on peut échapper à ce dernier problème en utilisant à la place de Twitter un aggrégateur comme Thunderbird (Windows/OSX/Linux) ou Feedly (Web/Tablette).

Facebook peut aussi être intéressant pour des besoins de veille, dans la mesure où il n'est pas arbitrairement limité à 140 caractères et laisse donc ses utilisateurs s'exprimer dans un français correct et compréhensible, avec un message aussi long que le sujet l'exige. Hadrien l'utilise pour suivre ses sources "hardware" (Ars Technica, WCCFTech, AnandTech et Tom's Hardware).

Oleg utilise Reddit, notamment pour s'informer sur les blockchains. Ce réseau social est organisé un petit peu différemment des deux précédents : on a une série de communautés d'intérêts très variés, dans laquelle les gens partagent des liens avec une petite légende et parfois une description plus longue (cette dernière est très utilisée par la communauté blockchain, moins par d'autres). Les gens peuvent réagir à ces liens en votant pour ou contre les sujets qui leur semblent intéressants, et en discutant via un système de commentaires hiérarchiques.

Un tel système de vote, qu'on retrouver aussi sur d'autres sites, est une arme à double tranchant. En principe, il met en valeur les sujets jugés intéressants ou pertinents par beaucoup de monde, ce qui tend à améliorer l'accès aux meilleures infos. Cela fonctionne bien sur StackOverflow, par exemple. Mais en contrepartie, le vote a aussi un certain nombre d'effets pervers. Par exemple, une mise en valeur de l'information basée sur le nombre de votes a une plus grande inertie face aux informations nouvelles, qui peinent à rejoindre et dépasser les infos anciennes "établies", fortement votées et donc mises en valeur, avec amplification via l'effet mouton, mais peut-être fausses à la base ou devenues obsolètes depuis.

Un autre problème que l'on doit gérer dans ce type de site où ce sont les utilisateurs qui trient et modèrent l'information, c'est les utilisateurs malhonnêtes. La solution la plus fréquemment employée pour diminuer le pouvoir de nuisance de ces derniers consiste à donner un plus grand pouvoir aux utilisateurs présents de longue date, comme sur StackOverflow. Mais encore une fois, cela ajoute aussi une certaine inertie au système en conduisant à la création d'une oligarchie modératrice indétrônable, parfois plus ignoble envers les nouveaux entrants qu'un despote autoproclamé.

Documentation de référence

Puisqu'on parle de StackOverflow, il convient de mentionner que c'est une autre source d'information très intéressante, qui sort du cadre de la veille technologique et tient plutôt de la documentation de référence. Il s'agit d'un service de question-réponse collaboratif où les réponses sont triées par popularité selon un système de vote à la Reddit. On tombe souvent dessus en cherchant une solution à des problèmes techniques dans un moteur de recherche, et le diagnostic et les solutions qu'on y trouve est souvent de très bonne qualité pour les questions de développement logiciel.

L'expérience de David est cependant que ce type de plate-forme est moins utile quand on cherche une réponse à des questions relevant davantage de l'administration système, par exemple la bonne manière de faire marcher Docker sous OSX. Cela procède sans doute du fait que dans ce domaine, on est beaucoup plus sensible à la multiplicité des configurations matérielles et logicielles, ce qui fait qu'il y a moins de problème universels dotés de réponses universelles.

Oleg et Hadrien ont tous deux contribués à StackExchange, mais le faire en permanence est un investissement de temps assez significatif qu'on ne peut que rarement se permettre sur la durée. Plus souvent, ce qui se passe, c'est qu'on tombe par hasard sur une question intéressante dont on connaît la réponse, portant sur un sujet auquel on s'intéresse sur le moment, et on contribue au sujet "en passant".

Quora est un autre site de questions-réponses, qui ressemble à StackOverflow à première vue mais diffère pas mal dans son organisation:

• Il est plus fastidieux de le consulter sans ouvrir un compte (le site tente de l'empêcher à coup de popups qui obscurcissent la page)
• Selon Adrien, il faut une invitation d'un autre utilisateur pour obtenir un compte.
• Le site couvre une palette de sujets plus faible que StackOverflow, mais il les couvre en général de façon plus détaillée.

Les sites d'information et de documentation de référence sont complémentaires. Ainsi, Antoine utilise Twitter pour se maintenir au courant de l'arrivée de nouveaux contenus sur IBM DeveloperWorks.

Communication directe

Les sites de question-réponse publics comme StackOverflow ne sont pas très adaptés quand on utilise des outils (relativement) obscurs, ni quand on souhaite une réponse rapide. Dans ce cas, il peut être plus pertinent d'utiliser un support de communication direct avec les développeurs : e-mail, IRC, Slack/Mattermost...

Par exemple, ça a été l'expérience d'Hadrien dans l'école de parallélisme lorsqu'il travaillait sur un portage de code vers le framework de programmation parallèle HPX: les développeurs s'arrangeaient pour être toujours disponibles sur IRC, et c'était de loin le moyen le plus fiable d'avoir une réponse à une question urgente.

Beaucoup de projets essaient de maintenir une présence sur un chat, notamment dans le milieu de l'OpenSource. Certaines expériences HEP ont aussi, comme on l'a mentionné à la dernière réunion, un shifter en permanence sur Slack. Le RI3 serait aussi, depuis les JI, en train de mettre en place une instance de Mattermost, clone libre et self-hosté de l'application web Slack.

Sur le sujet du mail, une info importante: plusieurs utilisateurs Mac ont constaté qu'après avoir mis à jour leur système vers El Capitan, l'application Apple Mail a commencé à avoir un comportement très erratique, avec notamment une tendance à déplacer sans raison des mails dans la corbeille. Mieux vaudrait donc, pour les utilisateurs Mac, basculer vers un autre client mail comme Thunderbird en attendant qu'Apple résolve ce problème.

Vers un partage d'information

Au terme de cette discussion, il apparaît qu'on aimerait pouvoir partager non pas des nouvelles individuelles (comme "NVidia sort une énième carte graphique"), mais des sources d'information (comme Twitter, Facebook, Reddit, StackOverflow, Quora, IBM DeveloperWorks...). On aimerait aussi, ce faisant, être précis : ne pas juste citer un réseau social tout entier, mais un fil d'information précis sur ce réseau.

Pour cet usage, on pourrait peut-être mettre en place une page statique tenant lieu d'annuaire sur le site wordpress des développeurs du LAL. Cette page pourrait commencer par une bête liste de liens avec légende, puis être graduellement organisée au fur et à mesure que la liste croît (et donc qu'on a besoin d'orga, et sait quelle information on veut organiser).

L'expérience a commencé sur https://groups.lal.in2p3.fr/devatlal/veille/.

Autres discussions

Logging en C++

Antoine se demandait quelle bibliothèque de logging utiliser en C++. Malheureusement, dans ce domaine, il n'y a pas vraiment de standard établi, et chaque gros projet tend à fournir sa solution maison incompatible avec celle des autres. Mais deux bibliothèques bien établies dans ce domaine sont Boost::Log et Log4CPP.

De la compilation à la gestion de configuration

Une autre question d'Antoine concernait les équivalents de Maven dans l'écosystème C++. Cette question a lancé une petite discussion sur les systèmes de compilation et de gestion de configuration.

Make est un système de compilation automatisée. On lui donne la liste des fichiers sources, les dépendances entre ces derniers, et la manière de compiler chaque fichier, et il s'arrange pour gérer le processus de compilation. Les autres outils de compilation tentent généralement de faire mieux sur les points suivants, grossièrement triés par niveau croissant de complexité:

• Meilleure portabilité du service de base entre OS (ex : Apache Ant)
• Meilleure performance à service équivalent (ex : Ninja, tup)
• Génération automatique du graphe de dépendances interne (ex : automake)
• Gestion portable des dépendances externes (ex : CMake, SCons, Waf)
• Installation et configuration automatique desdites dépendances (ex : Apache Maven)

On a aussi abordé les outils de compilation pour Java, où on a d'une part Ant qui se veut très minimaliste (grosso modo des Makefiles en XML), et d'autre part Maven qui fait énormément de choses, mais est assez "lourd", tant en termes d'interface que de performance. Gradle serait une tentative de fournir une alternative plus efficace à Maven.

Sur le sujet de la gestion de configuration et de dépendances, David s'est amusé du yoyo constant dans le milieu du développement logiciel entre les méthodes de déploiement lourdes, où on lie statiquement toutes les dépendances du programme, voire inclut le reste de l'OS avec, et les déploiements plus légers où on essaie autant que possible de partager les dépendances entre programmes, mais au prix d'une complexité bien plus grande dans la gestion de paquets logiciels.

Programmation fonctionnelle

La prochaine école IN2P3 discutera du système de fichiers distribué Ceph, mais pour l'école suivante, Antoine souhaiterait organiser une école de programmation fonctionnelle.

Hadrien s'est porté volontaire pour aider à sa préparation. Il lui semble qu'il serait désirable de centrer l'enseignement sur deux axes complémentaires:

1. Programmer de façon idiomatique dans un langage fonctionnel (comme OCaml, Haskell)
2. Utiliser une approche fonctionnelle dans un langage impératif (comme C++, Python)

Sur ce dernier point, il y a eu une petite discussion sur Scala, qui était à la base conçu comme une surcouche fonctionnelle à Java. Julius et Jean-Noël se sont demandé si ce langage était toujours utile maintenant que Java 8 intègre en standard des éléments fonctionnels comme les lambdas.

Hadrien en est convaincu, car il pense que pour que l'approche fonctionnelle soit utilisée régulièrement, elle doit être bien intégrée via une syntaxe légère et agréable d'utilisation. Or, à ce niveau, Scala a encore beaucoup d'avance: pattern matching, usage de "_" comme référence au paramètre de la fonction, différenciation claire de val et var pour l'immutabilité...