Journal de bord MOOC RR - Victor Elhomsy 09/02/2021 : Début prise de note # Module 1 : cahier de notes, cahier de laboratoire ## 0. Introduction - Objectifs : - Importance de la traçabilité - Fonctionnement d'un cahier de laboratoire - Gestion d'un cahier de labo électronique - Maîtriser un outil de suivi de gestion - Prise de notes : Nécessité, historique, outils info (langage de balisage léger), gestion de version (gitlab), étiquettes et indexation - Cahier de notes : infos rangées par chronologie ## 1. Nous utilisons tous des cahiers de notes - Imposer une structure à nos notes après coup ? - Indexer les notes ? - Les rendre pérennes tout en les faisant évoluer ? ## 2. Aperçu historique de la prise de notes - Aspect concret : "matérialité" - Aspect organisationnel - Lien entre les deux -> Vision occidentale de toutes ces notions (données de sautres civilisations peu disponibles) -> Support numérique : flexibilité, (ré)organisation, structuration, outils d'archivage/indexation ## 3. Du fichier texte au langage de balisage léger - Editeur de texte sous Windows : Notepad++ (libre) - "Traitement de texte" : donne des fichiers non lisibles par un éditeur de texte (.pdf) - Fichiers texte : souvent codés en __UTF-8__ : toujours possible de les lire plus tard, et exploité par les logiciels d'indexation et de gestion de version MAIS pas d'hyperlien et de mise en forme - Langage de balisage (ex : HTML) : pour pallier ça - LdB "léger" : combiner la simplicité des fichiers "texte" et le confort de lecture des langages de balisage -> Markdown - Début des fichiers non textes (ex: pdf) contient du texte : métadonnées, souvent au format XMP - TEI : rend intelligentes les données textuelles par du balisage fort ## 4. Pérennité et évolutivité des notes avec la gestion de version (Gitlab) - Evolutivité : corriger nos notes, tout en suivant ces corrections - Pérennité : multiplier les copies (numériques) - Pb de corriger en traitement de texte : pas de fichier texte en sortie + sauvegarde séparée de la gestion de versions - Moteur de Wiki : facile, format texte MAIS sauvegarde à la charge de l'utilisateur, et modif d'une seule page à la fois -> Solution : logiciel de gestion de version : consacré à ça : peut corriger plusieurs fichiers simultanément + sauvegarde centralisée - Travailler à plusieurs = gérer des historiques distribués - GitHub = réseau social de développeurs : stats, portfolio, commu, _issues_, ... - Fork : copie perso du projet -> modif dans dépôt perso -> pull request dans le projet de base - Intégration continue + déversement dans des archives : traité dans un MOOC plus tard - GitHub, Gitlab : serveurs d'hébergement gratuits de projets publics - GitHub : projets privés payant si pas étudiant/académique - GitLab : logiciel libre, plusieurs instances - Choix : - GitHub : visibilité, grosse commu MAIS pas propriétaire (lois ?) - GitLab : confidentialité pour l'entreprise - Interfaces graphiques : - Au jour le jour : interfaces qui vont avec notre environnement de travail (JupyterLab pour Python 3) -> Extensions pour interagir avec Git - Fonctionnalités plus avancées (branches, merge, ...) : GitHub Desktop par ex ## 5. Etiquettes et logiciels d'indexation pour s'y retrouver - Abondance de résultat -> Etiquettes (MarkDown) pour associer un contexte aux mots - Exiftool : afficher des métadonnées de fichiers non texte + afficher des commentaires/étiquettes que l'on peut rechercher 12/02/2021 : début module 2 # Module 2 : La vitrine et l'envers du décors : le document computationnel ## 0. Introduction - Objectifs : - Extension de la traçabilité aux calculs et à ses résultats - Intégration code/résultats dans rapport technique/article scientifique - 3 outils pour écrire un document computationnel - Emacs/Org-mode : puissant sous Linux ou Mac, utile pour combiner plusieurs langages ## 1. Exemples récents d'études assez discutées - Economie : erreurs de calcul, traitement de données douteux (exclusion, pondération), statistiques non conventionnelles, calculs font peu de sens => Austérité décidée comme nécessité pendant 3 ans par les politiques -> Non publication des procédures de calcul et des données + manque de pression médiatique - IRM : données bruitées, procédure mal calibrée (faiblesses méthodologiques). Données très volumineuses -> Pas archivées. Méhtodes statistiques à améliorer - Cristallographie : "erreur de programmation" - __Dans la plupart des controverses : manque de rigueur ET de transparence__ => Blocage de la communauté dans un état erroné ## 2. Pourquoi est-ce difficile ? - Manque d'information : sources et données, choix (protocoles, hypothèses, données écartées, ...) -> __Cahier de labo__ - Ordinateur, erreurs de calcul : trop simple d'utilisation, tableurs (programmation, manipulation de données), pile logicielle (boite noire), bugs - Manque de rigueur et d'organisation : backup, historique, contrôle qualité - Dimension culturelle et sociale : personne n'exige/n'inspecte les données et les choix, cacher les faiblesses - Volonté d'éviter les outils propriétaires ## 3. Le document computationnel : principe - Objectif essentiel : permettre un max de transparence (explications, code, résultats au même endroit) - Sciences modernes : données presque que numériques -> analyse, visualisations (longue navette entre les deux) -> Publication (après les galères : partie immergée) - Obectifs méthodo : inspecter (justifier, comprendre), refaire (vérifier, corriger, réutiliser) - Notebook Jupyter : console Python en interne. On choisit les zones à afficher dans le document final ## 4. Prise en main de Jupyter - Pour réinitialiser l'état du notebook (effacer la mémoire des variables) : "Kernel" > "Restart and run all" - Aide : raccourcis clavier - "%matplotlib inline" : insérer la figure matplotlib directement dans le document - "%lsmagic" : autres commandes pratiques comme ça (interagir avec d'autres langages) - Partage du document : directement commitable via gitlab, ou exportable au format HTML par ex - "View > Cell toolbar > Hide code" : masquer certaines cellules (fragments de code, sorties, ...) : tout est disponiblae, mais pas visible à l'export ## 5. Travailler avec les autres - Produire un PDF direct : difficulté : environnement parfaitement configuré, compatibilité entre différents environnements - Partager : Rpubs, Dropbox : facile mais pas pérenne (hébergé sur Amazon) - Git : tout est disponible ! - Sites compagnons : services d'hébergement, archives ouvertes (HAL : soutenu par l'Etat) : déposer document principal et annexes ## 6. Analyse comparée des trois outils - Type de documents : Jupyter facile et dynamique - Emacs/orgmode pour un journal (seul à rédiger, chronologique, étiquettes puissantes, mélange texte/code), ou un cahier de labo (sémantique, étiquettes pour les auteurs), un article (export LaTeX facile) - Rédiger un article : difficile dans Jupyter, courant en Rstudio et org-mode - Reporting : rendre compte régulièrement de notre activité : - Réfléchir avec du recul, énoncer clairemet les problèmes - Permettre à l'encadrant de suivre l'avancement - Garder une trace (utile pour un rapport) # Module 3 : La main à la pâte, une analyse réplicable ## 1. Une analyse réplicable, c'est quoi ? - Traditionnellement : focus sur les **résultats**, résumé méthodo des méthodes, discussion sur conclusions - Réplicable : résumé méthodo remplacé par **code complet** + explications des choix - Raisons : plus facile à refaire, modifier, inspecter, vérifier ## 2. Etude de cas : incidence de syndromes grippaux - Réseau sentinelles : données relevées par des médecins généralistes - Erreur fréquente dans l'importation des données : données manquantes -> Ne pas supprimer à la main dans l'éditeur, non réplicable, faire avec code - Définition des dates : cf norme ISO 8601 ## 3. Importer les données avec Jupyter/Python 3 - Bibliothèques : pandas (gestion des données), matplotlib (figures), isoweek (pandas ne comprend pas le format iso des semaines) - Point technique : Supprimer données avec pandas => Nécessité de faire une copie ## 4. Inspection et validation des données - Pré-traitement pour adapter les données aux conventions des logiciels. Ex : gestion du format pour les semaines entre isoweek et pandas - Vérification : inspection visuelle, code de validation ## 5. Questions et réponses avec Python - Doit contenir toutes les étapes du traitement de données sous forme **exécutable**, les explications des choix, les détails techniques (là qu'on trouve les erreurs) # Module 4 : Vers une étude reproductible : la réalité du terrain ## 0. Introduction Objectifs : - Répliquer le travail de qqun d'autre - Comprendre les difficultés techniques IRL - Etudier qq pistes de solutions ## 1. L'enfer des données - Taille, structure, diversité, ... - 2 "nouveaux" problèmes : nature "diverse" (non homogènes), grand espace mémoire (-> convertir en binaire : moins gros et ça se passe de toute façon) - Métadonnées : format texte intéressant pour les stocker - Boutisme (petit : 1er nombre=bit de poids le plus faible) : doit être spécifié si on stocke en binaire - FITS : blbiothèque C facile d'emploi - HDF : plus récent, hiérarchique, aucune structure imposée (data, metadata), mais du coup bibli C plus compliquée - HDFView : vient avec la bibli C, pour explorer et visualiser - Interface très complète avec Python : h5py - Stockage, archivage, distribution : Zenodo (CERN), Figshare (privé) ## 2. L'enfer du logiciel ### 2.1. Passage à l'échelle : les codes complexes - Même en structurant/dépliant le code, **pas de vision d'ensemble** à cause de la structure linéaire/séquentielle, et de l'interaction entre différents langages - **Workflow** : bien identifier entrée/sortie de chaque fonction, vue d'ensemble en représentant en graphes, mouvements de données explicites, partages de fragments de workflows - Mais peu de vision sur les données et les détails techniques, surtout pour visualiser ; et investissement lourd - **Checkpoints** dans le calcul : permet de tester étape par étape, évite de refaire les parties couteuses ### 2.2. Passage à l'échelle : les environnements complexes - Librairies **dépendant** de paquets, qui dépendant eux-mêmes de plein de librairies : pas de standard pour la gestion de paquets - Besoin de contrôler l'environnement de travail : connaître les paquets/versions, les partager, ne pas écraser ce qui est déjà installé ### 2.3. L'épreuve du temps - Evolution hyper rapide des écosystèmes en compatibilité ascendante. A contrôler régulièrement (Popper) - Se restreindre à ce qui est maitrisable (code en C) - Archivage : - Code source : SOftware Heritage, HAL - Environnements : technologie Docker (pérenne ?) ## 3. L'enfer du calcul - Compromis entre temps d'exécution et reproductibilité - **Arrondis** différents suivant l'ordre des opérations, qui dépend du compilateur - Calcul parallèle : exécution plus rapide, mais qui dépend du nombre de processeurs - Calcul = logiciel + données + plateforme (matériel + infrastructure logicielle) - Pb des **nombres aléatoires** : définir la "graine" dans le code, pb de l'arithmétique avec des flottants # Conclusion - Recherche reproductible : enjeu pour la méthodologie scientifique, et pour l'inspectabilité et la réutilisation des travaux - Des outils existent : documents computationnels, workflows, gestionnaires de suivi de version, archives, intégration continue, ...