Réunion Dev@LAL 57

mercredi 19 avr. 2017, 10:30 → 11:30 Europe/Paris

101 (LAL)

Arrivée de Maxime Bescond & frameworks Web

Maxime Bescond nous rejoint pour faire un stage avec Oleg sur le thème de la visualisation web de données. La technologie choisie est le framework Javascript sigmajs. Interrogé par Antoine sur le choix de ce framework par rapport à D3.js, Oleg a défendu son choix en invoquant la trop grande complexité de ce dernier. Pour le reste, le choix s'est fait en fonction de la popularité perçue des différents framework, mesurée par l'ordre des résultats Google.

Au-delà des frameworks, d'autres solutions existent en Javascript pour des besoins de visualisation plus simples. Par exemple, Google propose toutes sortes de widgets indépendants, l'intégration Google Maps étant un exemple parmi d'autres. Ils ont aussi un framework plus construit, Materialize CSS, que Julius et Oleg ont déjà testé.

Dans ses projets avec des interfaces Web, Sébastien Binet utilise également beaucoup Bootstrap.

Olivier a également eu une brève expérience avec les interfaces Web en Javascript, mais en est un peu revenu, lassé de devoir composer avec l'incompatibilité permanente des différents navigateurs.

HTML5 et autres technos web modernes

Via David, la discussion s'engage sur les possibilités offertes par le HTML5. C'est l'occasion pour Hadrien de faire un petit rappel des principaux langages utilisés pour le développement web côté client:

• HTML pour le contenu brut de la page (texte et images, structure sémantique, audio et vidéo)
• CSS pour la présentation "statique" (avec toutefois des possibilités limitées d'animation)
• Javascript pour les interactions avec l'utilisateur (ex: génération ou import dynamique de contenu)

Ces trois technologies ont été assez récemment rénovées via les normes HTML5 (2014), CSS3 (standard très morcelé, certains fragments sont finalisés et d'autres à un stade très préliminaire), et ECMAScript 6 (2015, dialecte de Javascript standardisé auprès de l'ECMA). ECMAscript 7, finalisé en 2016, n'est qu'une évolution mineure d'ECMAScript 6, fruit d'une volonté du comité de standardisation de laisser les implémentations digérer un peu la révolution ES6.

Oleg est particulièrement intéressé par deux évolutions du Javascript, Web Workers et Web Sockets. Le premier permet d'écrire des programmes Javascript multitâches, le second d'avoir des communications avec le client web initiées par le serveur (en mode "push"). Mais la dernière fois qu'il avait examiné ces technologies, elles étaient encore loin d'être matures.

Hadrien a l'impression que la situation a bien évolué, au moins pour ce qui est du WebSocket. Par exemple, le CSNSM développe des applications combinant un backend Ada avec un frontend Web communiquant par WebSockets sans soucis particulier. Les notebooks Jupyter utilisent également cette technologie, notamment dans le cadre du projet "ipywidgets" qui vise à offrir plus d'interactivité en supprimant partiellement les aller-retours constants entre le client et le serveur.

Hadrien se demandait si Sébastien Binet n'utilisait pas aussi cette technologie pour ses projets en Go. Christian explique qu'il utilise Polymer, comme Atrium.

David s'interroge sur la place de Node.js dans tout ça. Il s'agit d'une technologie permettant de programmer en Javascript côté serveur, souvent dans l'optique d'éliminer la complexité du traditionnel quatrième langage de programmation web pour la programmation back-end (PHP, Python, Java...).

Une innovation plus récente semble être de stocker carrément du code Javascript dans la base de données d'une application web et de l'exécuter à la demande. Hadrien s'interroge sur les implications d'une telle pratique en termes de sécurité, la très grande permissivité du Javascript et l'usage de données exécutables étant souvent un problème à ce niveau. Mais du point de vue de Jean-Noël, le vrai danger en termes de sécurité réside surtout dans l'utilisation d'un environnement fortement interprété basé sur la génération de code à la volée et le copier-coller.

Vis à vis de la surface accrue de vulnérabilité d'injection de code, Philippe se demande pourquoi on ne pourrait pas simplement détecter la présence de code dans les entrées utilisateur. Hadrien rappelle que dans un environnement très hétérogène comme le web, où l'application typique utilise au moins 5 langages de programmation différents (HTML, CSS, Javascript, PHP/Python, SQL), dont plusieurs ont une grammaire complexe se prêtant à toutes sortes d'abus, détecter du code est loin d'être un problème simple. Il invoque également l'exemple de PHP, qui dans l'analyse de ce problème a échoué à maintes reprises en produisant des solutions incomplètes et remplies d'effets pervers (mysql_escape_string, addslashes/stripslashes, magic quotes...). Philippe y répond qu'à force d'essayer, les développeurs PHP ont dû acquérir une certaine expérience qui devrait être réutilisable par la communauté Node.js.

De son côté, Hadrien s'intéresse plutôt à des évolutions comme asm.js et WebAssembly qui visent à éliminer le monopole de Javascript pour le développement web front-end en permettant de transpiler toutes sortes d'autres langages de programmation sous une forme exécutable par les navigateurs web. Il pense qu'à terme, ces efforts permettront l'émergence d'applications web plus performantes et plus fiables. Plus performantes grâce à l'élimination de constructions dynamiques difficiles à optimiser par le navigateur web, lorsque ces dernières ne sont pas nécessaires, et plus fiables grâce à l'émergence de langages davantage centrés sur la qualité logicielle que Javascript, qui rejetteront la philosophie du "poursuivre l'exécution à tout prix" de ce dernier en faveur d'un support accru du développeur cherchant à trouver les erreurs dans ses programmes.

Données ouvertes & préservation du logiciel

Wikimédia France et le Center for Data Science de l'université Paris-Saclay co-organisent le 24 avril un évènement autour de Wikidata, une base de connaissances initialement créée pour centraliser les données communes à plusieurs pages wikipédia (p.ex: dates de naissances, population d'un pays et autres données socio-économiques...).

L'idée est de discuter les applications possibles de cette technologie à l'ouverture de données scientifiques ("open data"). Christian, en particulier, s'interroge sur les collaborations possibles en astrophysique.

L'accent est principalement mis sur la diffusion scientifique, mais David s'interroge également sur l'application possible à des données scientifiques de travail, comme dans le challenge Machine Learning auquel travaille David Rousseau.

Les données Wikidata sont accessibles par de nombreux moyens: API REST pour l'accès aux données uniques, téléchargement des données pour analyse locale... et SPARQL, un langage de requête conçu pour des requêtes sur les bases de données orientées document, bien connu de Christian.

A l'échelle de l'Etat, on peut trouver d'autres initiatives pour l'ouverture de données administratives, telles que le site de données ouvertes data.gouv.fr ou la mission gouvernementale Etalab du Secrétariat général pour la modernisation de l’action publique. Cette dernière dépend du premier ministre et vise à centraliser les données de toutes sortes d'administrations publiques, des régions aux écoles doctorales. On y retrouve notamment des anciens de PLUME/FENIX.

Prochains événements (LoOPS, groupe Calcul)

David annonce la couleur des prochains café LoOPS. Le café de mai devrait être consacré au GDS Ecoinfo, qui cherche à limiter l'impact environnemental de l'informatique et des télécoms. Et sous réserve de confirmation par les orateurs, le café de juin devrait être consacré à l'initiative Software Heritage pour la préservation des codes sources de logiciels (à la manière du dépôt légal de la BNF ou de l'Internet Wayback Machine pour les documents).

Philippe s'interroge sur les économies d'énergies possibles sur une grille de calcul comme la LCG, sans plonger dans des extrêmes comme l'extinction massive de machines non utilisées (ce qui dégraderait la qualité de service, en termes de temps de réponse aux pics de requêtes par exemple).

Jean-Noël mentionne la nécessité de ne pas seulement se concentrer sur la préservation de logiciels, mais aussi des données scientifiques associées. Il raconte un exemple de cas où le CERN avaient mobilisé des moyens conséquents pour exécuter des logiciels datant de l'époque des PDP-11, pour ensuite se retrouver dans l'incapacité de lire les bandes magnétiques contenant les données que ces logiciels étaient censés traiter.

Hadrien surenchérit: préserver les données, cela signifie aussi les migrer régulièrement d'un support à l'autre, et même cette procédure de routine est loin d'être anodine. Ainsi, la BBC a accidentellement perdu les seuls originaux survivants de certaines émissions de télévision comme Doctor Who en faisant le ménage dans leurs archives sur bandes magnétiques.

Sur un tout autre sujet, le groupe Calcul co-organise des formations sur les erreurs de calculs et la stabilité numérique, les moyens par lesquels il est possible de les mesurer et de les optimiser... On peut trouver plus de détails sur le site FoCal, mais malheureusement, le sujet ne semble pas passionner l'audience de cette réunion dans l'ensemble.

Groovy, Scala, et le fonctionnel

Jean-Noël s'est pas mal intéressé à Groovy, un langage de programmation qui vise à offrir un environement de scripting "léger" comparable à Python sur la JVM. Il le voit comme une première étape vers l'apprentissage de Scala, mais aussi comme une bonne plate-forme pour la création de DSLs. En effet, en Groovy, tout est surchargeable et tout est dynamique, ce qui pourrait offrir la flexibilité nécessaire pour ce type d'applications.

Dans l'apprentissage de Scala, la principale difficulté rencontrée par Jean-Noël est l'utilisation intensive de techniques de programmation fonctionnelle. Hadrien suggère d'aborder ces techniques en commençant par un langage davantage centré sur la programmation fonctionnelle, comme Caml, plutôt que d'essayer tout de suite un langage "touche-à-tout" complexe comme Scala.

On peut trouver un MOOC de programmation fonctionnelle OCaml sur France Université Numérique, ainsi qu'un MOOC de programmation fonctionnelle basé sur Scala sur Coursera.

Jean-Noël pense qu'une combinaison Groovy/Java ou Groovy/Scala pourrait avoir un intérêt comparable à celui de la combinaison Python/C++ couramment utilisée en HEP, avec en bonus une meilleure intégration permise par la JVM.

Stage/Thèse de Lucas

Lucas a récemment écumé la documentation et les outils d'analyse de performance d'Intel afin d'optimiser un filtre de Kalman, avec une application envisagée à la bibliothèque de reconstruction d'événements ACTS.

Le filtre de Kalman est une technique de traitement du signal qui permet d'ajuster un modèle physique à des points de données de façon itérative, point par point, avec une propagation d'incertitudes permettant d'évaluer la qualité du résultat final. En physique des particules, il est utilisé pour la trajectographie, lorsque l'on simule la propagation d'une particule possible dans le détecteur afin d'évaluer la qualité de cette hypothèse physique.

Il utilise principalement Intel VTune pour le profiling, car ce logiciel fournit des informations utiles lorsqu'on effectue des micro-optimisations (ordonnancement des instructions à l'intérieur du processeur, etc...). Dans le cas du filtre de Kalman, de telles optimisations sont rendues nécessaires par la taille extrêmement réduite du code de calcul et les dimensions peu commodes du problème.

Il utilise aussi la documentation Intel et NVidia, riche en recommandations concernant les bonnes et mauvaises pratiques pour l'écriture de programme performants sur le matériel de chaque fabricant.

A plus long terme, un but de la thèse est de produire un mécanisme de génération de code de plus haut niveau, qui permettrait de s'abstraire des caractéristiques de performances de chaque architecture matérielle en travaillant à plus haut niveau, tout en conservant des performances raisonnables sur chaque matériel.