Présentation LoOPS de Vue.js

On en a déjà parlé à la dernière réunion, LoOPS re-joue sa présentation sur Vue.js le 19 décembre.

Bien que le développeur de Vue, Evan You n’ait aucun lien particulier avec la France (il est d’origine chinoise et vit dans le New Jersey), le site officiel est extrêmement bien traduit en français, ce qui suggère qu’il existe une communauté francophone active.

Serge a entendu parler de Vue dans une réunion INRIA, où les utilisateurs d’Angular et React présents se sont montrés assez sceptiques. Ces utilisateurs de frameworks Javascript étant eux-même minoritaires dans l’assemblée… Il y avait une question muette sous-jacente: avec un écosystème du web qui évolue très rapidement, c’est difficile de savoir sur quel cheval parier quand on bâtit un site ou une application destiné être maintenu pendant de longues années.

Christian se demandait quelles applications web connues sont écrites avec Vue.js. Des éléments de réponse à cette question peuvent être trouvés dans le dépôt Github « Awesome Vue.js », section « Projects using Vue.js ».

Réunion RI3 « Outils collaboratifs »

Il y a eu le 11 décembre une réunion RI3 sur le thème des outils collaboratifs. Cette dernière a été principalement centrée sur les services mutualisés du CCIN2P3, mais il y avait aussi des infos intéressantes pour des développeurs utilisant les services du CC comme Gitlab. Concernant ce dernier:

• Une mise à jour vers une version plus récente de Gitlab 9 surviendra prochainement. La mise à jour vers Gitlab 10 ne peut pas encore être effectuée car il faut d’abord que le CC mette à jour le server de bases de données PostgreSQL sous-jacent.
• Le CCIN2P3 travaille actuellement sur la possibilité de déployer automatiquement les nouvelles versions d’une application lorsque l’intégration continue réussit.
• L’activation de la fonctionnalité « Gitlab Pages » qui permer de gérer un site web statique au sein d’un dépôt Git est aussi prévue prochainement.
• Il est d’ors et déjà possible de mettre des images Docker en ligne au CC, via un « registry » local, et la possibilité de les construire automatiquement dans l’intégration continue est à l’étude.
• La limite du nombre de projets privés sur Gitlab (qui détermine par exemple combien de « forks » un développeur peut posséder) a été montée à 50 pour les nouveaux utilisateurs. Cette modification sera propagée aux anciens utilisateurs ultérieurement.
• Il est maintenant possible d’activer une intégration Mattermost dans Gitlab, ce qui soulève une question: est-ce qu’il y a de la demande pour que l’on monte une instance Mattermost (un chat persistent façon Slack) au CC ?

Jean-René a aussi discuté de l’avenir de l’application web de sondages LimeSurvey. Elle fonctionne bien et connaît une certaine popularité, mais le logiciel est distribué sous un modèle économique freemium où certaines fonctionnalités sont payantes. L’une d’elle est la mise à jour automatique, qui serait un confort appréciable pour les administrateurs du CC. C’est pourquoi le CC envisage d’acheter une licence premium.

Le cahier de manip numérique ELog a aussi été discuté. Il existe au CC une instance de ce logiciel populaire chez les physiciens, peut-être pourrait-on la mutualiser. Ce n’est certes pas l’application web la plus moderne et ergonomique qui existe, mais Serge rappelle qu’il existe toujours pire (ex: OSN, imposé par Nicolas Leroy dans CALVA).

Dans la même famille des applications web que les utilisateurs aiment beaucoup, mais dont ne peut pas s’empêcher d’être un peu insatisfait quand même, il y a aussi TWiki. Sa maintenance au LAL est très difficile, et Serge adorerait arrêter ce service en faveur d’une solution plus moderne, éventuellement mutualisée au CC. Mais la migration du contenu accumulé dessus est un problème encore irrésolu.

La réunion RI3 a aussi abordé la question plus générale des infrastructures sous-jacentes aux applications web, que sont les certificats HTTPS et les noms de domaines. Ce sont deux domaines qui nécessitent un effort conséquent de maintenance manuelle à l’heure actuelle, et où une politique plus unifiée et automatisable serait souhaitable. Pour le HTTPS, le CC propose un usage plus intensif de l’autorité de certification Let’s Encrypt, pensée dès le départ pour l’automatisation. Mais pour les noms de domaines, la réponse reste encore à trouver. Serge pense qu’une première étape serait pour le SI d’apprendre à dire davantage « non » aux utilisateurs, au lieu de toujours accepter de prendre en charge la maintenance à long terme de leurs infrastructures mises en place à la hâte sans concertation préalable avec l’exploitation.

Un autre sujet abordé était la gestion de tickets pour l’exploitation. Il y a quelques temps, le CCIN2P3 avait essayé de proposer une solution mutualisée à ce problème avec OSRF, mais le moment semble venu d’admettre que ce projet n’a pas abouti: seul un laboratoire de Clermont-Ferrand (le LPC?) y reste attaché. L’argument généralement invoqué est la trop grande complexité de la solution au OSRF, qui semble surdimensionné et trop peu ergonomique. Si c’était à refaire, le gagnant de cette bataille technologique serait plutôt GLPI à l’heure actuelle.

Enfin, un dernier point qui a été abordé est la gestion des ressources humaines, et la possibilité de mutualiser les outils web développés pour cet usage. Des collaborations possibles pour Justine, qui est spécialiste de ce type de développements au LAL ?

Autres sujets

François mentionnait la manière dont on peut être perdu face aux questions de la gestion de version distribuée moderne, par exemple « J’ai accidentellement ajouté un commit sur la branche develop, que puis-je faire pour le transformer en branche de développement ? ». Une piste pour organiser des formations futures ?

L’école de programmation fonctionnelle et distribuée avec Spark a suscité un grand intérêt, avec en particulier une forte participation du LAL (10 personnes, soit environ un quart des étudiants). Elle se déroulera en deux parties, une partie plutôt centrée programmation fonctionnelle du 15 au 17 janvier, et une partie plutôt centrée Spark du 29 au 31 janvier.

Philippe mentionne une bonne idée de Microsoft et Canonical dans les versions récentes de Windows 10, le Windows Subsystem for Linux (WSL). Cet outil permet d’exécuter des applications Linux sous Windows en utilisant une émulation des appels systèmes, similaires à ce qu’offre Wine dans l’autre sens. Ce serait potentiellement intéressant pour des applications online, où on utilise beaucoup Windows et on a parfois des difficultés à y construire un environnement de développement confortable dès qu’on sort de l’écosystème Visual Studio. On se retrouve ainsi par exemple souvent avec plusieurs installations de Python qui se battent en duel, chaque projet fournissant son propre gestionnaire de paquet.

En janvier, le LAL organise un séminaire qui discutera de machine learning avec l’ASIC de recuit simulé quantique de D-Wave. Ce sera une bonne occasion d’approfondir ce que cette machine sait faire, et en quoi elle diffère des systèmes basés sur des qubits intriqués que l’on met plus généralement derrière le mot « ordinateur quantique ».