Contents

Avenir des piscines

Lors des dernières JI (Journées Informatiques de l’IN2P3 et de l’IRFU), en 2016, un nouveau format pédagogique avait été essayé: la « piscine ». C’est un format dont on a entendu parler car il est pratiqué à l’EPITA, qui a inspiré par la suite l’école 42. Il s’agit de proposer des tutoriels sur un format de 20-25 minutes, appelés « plongeons », ayant vocation à être utilisables de manière plus ou moins autonome, chacun travaillant sur sa propre machine. L’idée n’est pas de faire un cours, mais de se familiariser rapidement avec une nouvelle technologie à laquelle on ne souhaite pas accorder un grand budget temps. La limite de temps d’environ 20 minutes est choisie pour coller au temps maximal pendant lequel une personne peut se concentrer en continu : si l’on a davantage de choses à dire que cette limite de temps ne le permet, il faut découper en plusieurs plongeons.

Les prochaines JI ayant été annoncées pour octobre 2018, il est temps de se demander ce que l’on va faire de ces tutoriels, actuellement disponibles sur le dépôt « PiscineJI » du Gitlab du CCIN2P3. Est-ce qu’on se contente d’un nettoyage des tutoriels existants, sans rien changer d’autre ? Est-ce qu’on renomme le dépôt existant en « PiscineJI2016 » et on crée un nouveau dépôt pour les plongeons 2018 ? Est-ce qu’on conserve une organisation basée sur un dépôt unique, ou est-ce qu’on change d’organisation pour l’occasion ?

La première chose à faire semble être de tester les plongeons existants pour voir si ils fonctionnent encore. A priori, on souhaite préserver tous ceux qui sont fonctionnels, ou que l’on peut remettre en service facilement. Par la suite, il serait peut-être pertinent d’avoir plusieurs dépôts de plongeons thématiques à l’avenir, au lieu d’un dépôt unique, car ce dernier est rapidement devenu un grand fatras, tant dans sa hiérarchie de fichiers que dans son historique Git. Dans cette optique, David a déjà lancé deux nouveaux projets GitLab liés au Master-Projet IN2P3 DécaLog :

Le premier projet est centré sur les conteneurs (ex: Docker, Singularity…). Il s’appelle « EnBarque » car l’idée est que l’on essaie d’aller dans l’eau en se mouillant moins. Ce dépôt de tutoriels est lié par ses thématiques au projet IN2P3 ComputeOps et à l’école d’informatique en cours d’organisation par Cécile Cavet (voir ci-après).
Le second projet est centré sur les problématiques et technologies liées au calcul numérique (ex: kokkos, xtensor…). Il s’appelle « NatationSynchronisee » et se rapproche, dans ses thématiques, du projet IN2P3 Reprises.

Une autre piste serait de développer de nouveaux plongeons. Par exemple, Julien et Christian sont attendus au tournant pour le développement d’un plongeon Scala/Spark. Pour ceux qui seraient intéressés, les activités liées à la piscine sont regroupées au sein du groupe « MaitreNageurs » sur le GitLab du CCIN2P3, et il suffit de contacter David pour en devenir membre.

Il existe aussi, depuis la création du format piscine, une ambiguïté quand à sa mise en pratique. Veut-on, au-delà de son utilisation présentielle dans une session dédiée des JI, le promouvoir comme un didacticiel en ligne utilisable à tout moment de l’année ? Sur le principe, ça semble être désirable, mais le diable est dans les détails :

Que veut-on faire des sujets qui ne peuvent pas être enseignés à distance parce qu’ils nécessitent une infrastructure ou un matériel dédié ? (ex: Arduino)
À partir du moment où l’on prévoit cette utilisation ex-situ, au rythme de l’apprenant, l’utilisation d’un format segmenté par 20 minutes ne devient-elle pas une contrainte arbitraire ? En effet, il a déjà été observé que ce format peut décourager certains enseignants potentiels, car il n’est pas toujours simple de faire tenir un savoir dans un ou plusieurs blocs de 20 minutes…
Si l’on se dirige vers de l’enseignement à distance, n’existe-t-il pas des technologies plus adaptées que notre combinaison image Docker + dépôt GitLab actuelle (ex : notebooks, plate-formes MOOCs) ? Et à l’inverse, un tutoriel pensé pour un usage autonome est-il optimal en présentiel ? N’est-il pas difficile de préparer un tutoriel qui soit adapté aux deux situations ?
Si l’auto-formation est jugé préférable, doit-on continuer à préserver un créneau horaire dédié pendant les JI pour les piscines « présentielles » ? Ou bien est-ce que les JI pourraient n’être qu’un point de ralliement pour fixer une date limite à la préparation des plongeons et faire de la pub pour ces derniers ? En d’autres termes, les avantages du format présentiel compensent-ils ses inconvénients ?

Plus généralement, on se rend compte dans cette discussion qu’il y a un important besoin de veille technologique, de formation, et d’assistance autour de l’enseignement en ligne et de l’auto-formation. C’est un sujet complexe, qui part des questions de portabilité du code (machines virtuelles, conteneurs, et leurs limites dans des scénarios nécessitant un contrôle fin sur le matériel et le système), et s’étend jusqu’aux nouvelles technologies pour l’enseignement en ligne comme les notebooks et les MOOCs. Sur ces dernières technologies, il y a aussi des questions d’infrastructures: on ne peut plus se contenter de dire aux gens d’installer Docker ou VirtualBox et de télécharger une image, il faut aussi souvent préparer et maintenir des serveurs équipés de plate-formes logicielles complexes avec la charge supplémentaire que ça implique pour l’exploitation. Un exemple type à ce niveau est celui du notebook en ligne: derrière son apparente simplicité, ce format nécessite l’installation et la maintenance d’un logiciel dédié par langage de programmation supporté (voire un système de notebook à part comme dans le cas de Zeppelin pour Scala + Spark), ainsi qu’une infrastructure de machines virtuelles pour les TPs nécessitant des manipulations shell.

En parlant de machines virtuelles, d’ailleurs, un autre problème que l’on doit régler dans le cadre de nos activités d’enseignement est le trafic réseau occasionné par l’utilisation des VMs et des conteneurs. En effet, l’emploi de ces technologies est à la base guidé par un constat, qui est que les apprenants dans un TP d’informatique n’ont souvent ni l’envie, ni les connaissances techniques, pour mettre en place l’environnement logiciel parfois complexe d’un enseignement sur leurs machines. Mais en répondant à ce besoin par l’utilisation d’une grosse boîte noire contenant la quasi-totalité d’un système d’exploitation moderne, on se retrouve avec des téléchargements de plusieurs gigaoctets que les apprenants n’essaient souvent de récupérer qu’au moment du cours. Par conséquent, le jour J, on fait face à des dizaines de machines qui cherchent simultanément à télécharger d’énormes fichiers depuis internet, via une connection souvent peu performante, ce qui entraîne naturellement une énorme contention réseau et de longs délais avant le démarrage des TPs. Le moins que l’on puisse dire, c’est que ça ne semble pas encore optimal.

On peut envisager différentes stratégies :

encourager les maîtres-nageurs à partir d’un socle logiciel commun (VM ou image docker de référence bien remplie) afin de mutualiser davantage de données entre les plongeons ;
encourager les maîtres-nageurs à mettre leurs images à disposition avec une bonne avance, afin qu’un téléchargement préalable soit possible ;
encourager les apprenants à préparer l’environnement logiciel des plongeons à l’avance, idéalement par simple installation de docker et « docker pull » ;
reconnaître qu’aucune de ces mesures ne sera un remède à l’inattention et à la paresse des apprenants, et fournir sur place des serveurs de fichiers performant et une bonne bande passante locale pour éviter de trop dépendre de la connexion Internet.

À la fin de cette discussion, l’on s’est aussi interrogé sur la pertinence de créer une zone de piscine dédiée aux langages de programmation. D’un côté, c’est très clairement une thématique populaire et un peu à part par rapport aux autres. Mais de l’autre, il peut être maladroit de trop vouloir séparer les langages de programmation de leurs écosystèmes. En effet, il est très courant qu’une technologie ne soit aisément utilisable que depuis un seul langage de programmation, ainsi l’utilisation de Spark est bien plus naturelle depuis Scala que depuis les autres langages, la majorité des bibliothèques de vectorisation et de parallélisme de la dernière décennie ne sont utilisables que depuis C++, le développement web front-end n’est pas envisageable sans avoir un minimum de notions de HTML/CSS/Javascript, et Python et R détiennent un monopole absolu sur les bibliothèques libres d’informatique scientifique pour non-spécialistes. Peut-être qu’une solution possible serait de faire ce qu’Olivier Girardot a fait dans la formation Spark, et de proposer une formation « langage » et une formation « techno » en expliquant clairement que la première est un préalable nécessaire à la seconde ?

Autres activités de formation

École informatique sur les conteneurs en production

La prochaine école informatique sera sur les conteneurs en production. Elle se déroulera du 4 au 8 juin au Centre de Calcul de l’IN2P3. Elle est piloté par Cécile Cavet, qui a proposé un programme, mais depuis que tout le monde est tombé d’accord, il n’y a plus de nouvelles. Il reste encore à définir le programme, trouver des intervenants, et lancer les inscriptions. Vu le calendrier, le délai est court est la question se pose de relancer Cécile.

Des sujets variés pourraient être abordés, tels que l’orchestration de conteneurs et Singularity. David a proposé de rejouer sa piscine, déjà jouée aux Journées Informatiques de l’IN2P3, mais il risque d’être indisponible, il cherche donc un renfort pour le remplacer en cas d’absence. Toute bonne volonté est aussi bienvenue pour faire évoluer ce plongeon sur https://gitlab.in2p3.fr/MaitresNageurs. Plus globalement, ce peut être l’occasion de réutiliser des piscines des JI précédentes Cela a été proposé à Gérard, intéressé par les sujets Docker et Singularity, mais il est un peu trop occupé.

Liste de formations en ligne

L’intérêt d’une liste de formations disponibles en ligne pourrait être utile, autour du développement. Le format plongeon de 20 minutes peut s’avérer adapté mais tout format est utile. Actuellement, sont disponibles plusieurs types de ressources :

Cette liste pourrait apparaître dans le wordpress sous forme de page statique recensée dans le site du SI, pour rassembler toutes les informations utiles au même endroit, et faciliter la découverte des outils par les nouveaux arrivants.

Petite formation à Python au LAL

On a noté qu’il existe un besoin de formation python au LAL. Un cas d’utilisation basique serait le début d’un développement python, quand on ne connaît pas la langage. Christien remarque qu’au delà de la syntaxe d’un langage, les outils de l’environnement (maven, SBT, etc.) sont une base importante pour aborder un langage. Le réflexe d’Antoine est de créer un environnement virtuel avec virtualenv avant tout. On pourrait aussi y ajouter l’interface de développement PyCharm.

En résumé, un guide de démarrage qui voit plus large que le langage lui-même serait nécessaire. L’idée serait d’adopter un format court, informel, pour mettre le pied à l’étrier pour des personnes qui n’ont pas le temps et les références. À la fin d’un tel cours, d’autres ressources seraient comme toujours données, pour aller plus loin.

Questionnaires dans le cadre pédagogique

Un séminaire du café pédagogique de Paris-Sud a abordé les quizz dans le cadre de l’enseignement.

Les questionnaires pré-formation permettent de s’assurer que les pré-requis sont maîtrisés. C’est un effort immense mais cela peut valoir le coup dans certains cas.
Les questionnaires post-formation se révèlent aussi utiles après une formation : les retours d’expériences montrent qu’une révision quivie d’un questionnaire est plus efficace que deux révisions.

C’est une manière différente de réfléchir au matériel pédagogique, les questionnaires peuvent être vus comme le TD en présentiel. Pour créer de tels questionnaires, les services limesurvey de l’IN2P3 ou du LAL pourraient être utilisés.

Formation à Git

Hadrien prépare une formation Git pour la DR4 du CNRS. Elle se déroulera les 31 mai et 1er juin 2018. La question du format piscine s’est posée, mais semblait ici moins adapté : l’ambition n’est pas seulement de donner une liste de commandes utiles, mais aussi que les participants sortent avec une bonne compréhension du fonctionnement de l’outil.

Le principal prérequis demandé est la connaissance des commandes de gestion de fichier de base d’Unix (cd, mkdir, ls, touch, etc.), puisque les TPs sont sous Linux et utilisent principalement la ligne de commande. Aucun prérequis ne sera demandé en gestion de version, et le contenu pourra peut-être être adapté à l’expérience des participants.

Les deux types de didacticiels (les «tutorials») ont leur utilité, mais il existe déjà de nombreux didaticiels introductifs à Git, ce qui laisse songeur quand à la nécessité d’en créer un de plus. Quelques exemples pour les intéressés:

Par ailleurs, la documentation de référence est complémentaire de ces didacticiels, c’est une différence dont il faut être conscient.

Communauté dev@LAL et outils

Idées d’animation

Tout part du constat suivent: nous ne sommes pas nombreux aux réunions développeurs du LAL par rapport au nombre total de développeurs au laboratoire. Il a été proposé plusieurs idées pour palier à ce problème.

Faire des petites présentations d’outils de 20 min. ? Ou encore des annonces brèves sur des outils récemment découverts ?
Partager régulièrement des URLs intéressantes collectées durant les deux semaines de travail écoulées ?
Fournir enfin, après l’avoir souvent évoqué, un annuaire des listes de diffusion utiles ?

La question du partage d’URL a été plus longuement discutée. Par exemple, un format possible serait que chacun présente deux URLs par réunion. Ces URLs apparaîtraient sur le compte rendu, et pourraient éventuellement être intégrées à un annuaire plus pérenne sous forme de page statique.

Dans ce dernier cas, il faudrait cependant gérer le problème de l’accumulation des actualités et de leur obsolescence. Sans maintenance régulière, une page statique a tôt fait de devenir un fatras.

On pourrait, à la place, préférer partager nos trouvailles au fur et à mesure. Se pose alors la question du moyen de communication. L’e-mail est peut-être un peu sur-utilisé, dans la mesure où il ne passe pas bien à l’échelle : quand on est abonné à des listes de diffusion très actives, les retours de vacances sont difficiles…

A ce niveau, on pourrait préférer des outils davantage basés sur la notion de flux continu d’information qu’on peut aisément ignorer pendant un temps, à la manière de Twitter ou des chats persistants comme Slack et son clone libre Mattermost. Sur ce sujet, il est d’ailleurs intéressant de noter qu’il existe un groupe Slack RI3 et que le CCIN2P3 s’interroge sur la pertinence d’héberger une instance de Mattermost.

Outil: Trello

Un des exemples d’utilisation de l’outil Trello fourni par les développeurs, c’est un tableau dédié à l’accueil des nouveaux entrants. Cela semble être une bonne idée dont nous pourrions nous inspirer.

Les intégrations pour Github, Bitbucket, ou encore des outils de workflow Scrum sont potentiellement intéressantes, mais il peut y avoir besoin de développements custom pour ajouter les intégrations désirées, comme celles avec les services du CC par exemple.

Plus généralement, un problème existant avec les intégrations Trello par défaut, c’est qu’elles concernent principalement des logiciels qui ne sont pas très utilisés dans notre communauté. Pour en tirer profit, il faut peut-être avoir pensé le projet dès le départ pour un workflow Trello et avoir choisi les outils de gestion de projet en fonction.

Il existe un clone libre de Trello, Kanboard (service gratuit : Framaboard), qui dispose de modules similaires (module bitbucket, module gitlab).

Outil: Framework Python Dash

Dash est un outil qui sert à construire des applications web orientées Data Science. Il est basé sur Plotly, et est lié à PyData.

En le présentant, son auteur citait Guido von Rossum: « Python a été créé comme langage d’enseignement, pour combler le vide entre bash et C ».

Du point de vue de l’auteur de Dash, PyData est la prochaine page de l’histoire du Python numérique, après l’ère SWIG et l’ère Numpy/Matplotlib.

Journal: Software and Computing for Big Science

Software and Computing for Big Science est un nouveau journal, créé en Septembre 2017, pour des publications ayant trait au logiciel scientifique.

Michel, qui fait partie de son Editorial Board, a confié un exemplaire du premier numéro de la revue à Antoine. Ce dernier est désormais disponible dans la salle détente !

Développements informatiques au LAL

Réunion du 21 février 2018