diff --git a/journal/module_3.html b/journal/module_3.html
index 94eea11ddf61066af3b2862071cdd8a53897da89..3754c893b448573ce397358c6c084c27685ada75 100644
--- a/journal/module_3.html
+++ b/journal/module_3.html
@@ -169,8 +169,80 @@ pre code {
Module 3 : La main à la pâte, une analyse réplicable
-
-
pouet
+
+
0. Introduction
+
+
Objectifs
+
+
Apprendre à réaliser une analyse de données de façon reproductible et traçable
+
Maitrîser quelques bonnes pratiques pour la préparation des documents computationnels
+
+
+
+
+
1. Une analyse réplicable, c’est quoi ?
+
+
Dans une analyse traditionnelle
+
+
concentre sur les résultats
+
montre simplement un résumé méthodologique des méthodes utilisées
+
discussion pour exposer entre autres les conclusion de cette analyse
+
+
+
+
Dans une analyse réplicable
+
+
présentation des résultats
+
fournir le code qui à permit de génèrer ces résultats avec un explication détaillée du code et des choix fait
+
discussion (identique à l’analyse traditionnelle)
+
+
+
+
Pourquoi faire réplicable alors que c’est plus d’effort ?
+
+
Facile à refaire si les données changent
+
facile à modifier
+
facile à inspecter et vérifier (plus de confiance)
+
+
+
+
+
2. Etude de cas : l’incidence de syndromes grippaux
+
Présentation du jeu de données qui va servir comme exemple dans ce module
+
Données qui viennent du réseau sentinelles
+
Ne pas supprimer les lignes vides directement dans le fichier texte, pas de modification à la main Tout doit se faire dans le code
+
La date (en semaine) est au format ISO8601 dans le fichier:
+
+
il y a deux façons différentes de procéder : on peut donner l’année, le mois, et le jour du mois, ou on peut donner l’année, la semaine, et le jour de la semaine. Le 8 août 2018 peut donc être écrit 2018-08-08 ou 2018-W32-3, car il s’agit du troisième jour (mercredi) de la semaine 32 de l’année 2018.
+
+
+
+
3B. Importer les données avec RStudio/R
+
+
lecture des données directement depuis la source (url)
+
Faire attention aux données manquantes avant l’analyse
+
+
+
+
4B. Vérification et inspection avec RStudio/R
+
+
Pré-traitement des données
+
+
Adapter aux conventions des logiciels
+
Faciliter l’analyse
+
+
Vérifier autant que possible
+
+
inspection visuelle
+
code de validation
+
+
+
+
+
5B. Questions et réponses avec RStudio/R
+
Une analyse réplicable doit contenir toutes les étapes de traitement des données sous une forme exécutable.
+
Il est important d’expliquer tous les choix qui peuvent influencer les résultats.
+
Ceci nécessite d’exposer beaucoup de détail techniques, parce que c’est à ce niveau qu’on fait le plus d’erreur.
diff --git a/journal/module_3.md b/journal/module_3.md
index f5bb45156906ace64f65ebbe379dea7f1e2a5632..5e2dcb60cbe985f636abe860458acc843bfa9344 100644
--- a/journal/module_3.md
+++ b/journal/module_3.md
@@ -58,4 +58,4 @@ Une analyse réplicable doit contenir **toutes les étapes** de traitement des d
Il est important d'**expliquer** tous les choix qui peuvent influencer les résultats.
-Ceci nécessite d'exposer beaucoup de **détail techniques**, parce que c'est à ce niveau qu'on fait le plus d'erreur.
\ No newline at end of file
+Ceci nécessite d'exposer beaucoup de **détail techniques**, parce que c'est à ce niveau qu'on fait le plus d'erreur.
diff --git a/journal/module_4.html b/journal/module_4.html
new file mode 100644
index 0000000000000000000000000000000000000000..f47f5d800cdf21d82b58d3e2a9615a1422e02ca8
--- /dev/null
+++ b/journal/module_4.html
@@ -0,0 +1,305 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+module_4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Module 4 : Vers une étude reproductible, la réalité du terrain
+
+
0. Introduction
+
+
Objectifs
+
+
Repliquer le travail de quelqu’un d’autre
+
Comprendre les difficultés techniques qui se présentent lors du passage de l’exercice à la vraie vie
+
Etudier quelques pistes de solutions
+
+
Les enfers de la recherche reproductible
+
+
L’enfer des données
+
L’enfer du logiciel
+
L’enfer du calcul
+
+
+
+
+
1. L’enfer des données
+
Elles se présentent de nature diverse (non-homogéne) - colonne pas de même longueur - les données peuvent être des suites chronologique et des images, etc
+
Elles sont trop grosse -> besoin de les stocker au format binaire
+
Garder les métadonnées au format texte ! Pour rajouter des informations plus facilement. Ces metadonnées sont vitales pour une recherche reproductible.
+
Le boustime correspond à l’ordre d’encode au format binaire. Le petit-boutisme correspond à l’ordre croissant des valeur binaire (1,2,4,8,…) tandis que le grand boutisme correspond à l’ordre décroissant (…,8,4,2,1).
+
Ce boutisme peut changer en fonction du système d’exploitation ce qui pose des problème dans la reproductibilité.
+
Un stockage binaire doit spécifier le boutisme utiliser pour une recherche reproductible
+
Format binaires pour :
+
+
travailler sur de grosse données de nature différentes
+
stocker les métadonnées et les données
+
un boutisme fixé
+
+
Deux format repondent à ces critères: 1. FITS (1981 et toujours à jours, dev par des astrophysiciens) Format assez général pour être utilisé dans plusieurs contextes (bibliothéque vatican)
+
structure:
+
+
un ou plusieurs segments: Header/Data Units (HDUs)
+
contitution HDU:
+
+
une en-tête (header unit)
+
données (data Unit) : optionnelles
+
+
en-tête = paires mots clés / valeurs -> métadonnées
+
données tableaux binaire (une à 999 dimension) ou tables (texte ou bianire)
+
+
manipulation:
+
+
bibliothéque C
+
PyFITS pour python
+
FITSio pour R
+
+
2. HDF5 (dev par National Center for SuperComputing Applications, 5eme version) structure:
+
+
ressemble à une arboraissance de fichier
+
élément structurant est le group (répertoire) qui contient un ou plusieurs dataset (fichier)
+
les group peuvent être imbriqués
+
pas de structure imposé pour les métadonnées
+
idem pour les données (on peut y stocker un article)
+
+
manipulation:
+
+
bibliothéque C plus compliqué que celle pour le format FITS car le format HDF5 est plus “souple”
+
+
bibliothéque vient avec l’application HDFView (codé en java) pour l’exploration
+
+
h5py pour python
+
h5, hdf5r et rhdf5 pour R
+
+
+
L’archivage
+
+
zenodo -> cern
+
figshare -> privé
+
+
+
+
conclusion
+
les vraies données:
+
+
grosse et problème de structure
+
complexes et ont besoin de métadonnées
+
Format FITS et HDF5 sont des solution de formatage de ces données
+
En compléxité et fléxibilité: FITS < HDF5
+
archivage pour stockage pérenne et accessible
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/journal/module_4.md b/journal/module_4.md
new file mode 100644
index 0000000000000000000000000000000000000000..0036f4ce21a4262a9bf7f82e931e171df520eb98
--- /dev/null
+++ b/journal/module_4.md
@@ -0,0 +1,168 @@
+# Module 4 : Vers une étude reproductible, la réalité du terrain
+
+## 0. Introduction
+
+### Objectifs
+
+- Repliquer le travail de quelqu'un d'autre
+- Comprendre les difficultés techniques qui se présentent lors du passage de l'exercice à la vraie vie
+- Etudier quelques pistes de solutions
+
+**Les enfers** de la recherche reproductible
+
+- L'enfer des données
+- L'enfer du logiciel
+- L'enfer du calcul
+
+## 1. **L'enfer des données**
+
+Elles se présentent de nature diverse (non-homogéne)
+ - colonne pas de même longueur
+ - les données peuvent être des suites chronologique **et** des images, etc
+
+Elles sont trop grosse -> besoin de les stocker au format binaire
+
+Garder les métadonnées au format texte ! Pour rajouter des informations plus facilement. Ces metadonnées sont vitales pour une recherche reproductible.
+
+Le *boustime* correspond à l'ordre d'encode au format binaire. Le *petit-boutisme* correspond à l'ordre croissant des valeur binaire (1,2,4,8,...) tandis que le *grand boutisme* correspond à l'ordre décroissant (...,8,4,2,1).
+
+Ce *boutisme* peut changer en fonction du système d'exploitation ce qui pose des problème dans la reproductibilité.
+
+Un stockage binaire doit spécifier le boutisme utiliser pour une recherche reproductible
+
+Format binaires pour :
+
+- travailler sur de grosse données de nature différentes
+- stocker les métadonnées et les données
+- un boutisme fixé
+
+Deux format repondent à ces critères:
+**1. FITS (1981 et toujours à jours, dev par des astrophysiciens)**
+Format assez général pour être utilisé dans plusieurs contextes (bibliothéque vatican)
+
+structure:
+
+- un ou plusieurs segments: Header/Data Units (HDUs)
+- contitution HDU:
+ - une en-tête (header unit)
+ - données (data Unit) : optionnelles
+- en-tête = paires mots clés / valeurs -> métadonnées
+- données tableaux binaire (une à 999 dimension) ou tables (texte ou bianire)
+
+manipulation:
+
+- bibliothéque C
+- PyFITS pour python
+- FITSio pour R
+
+**2. HDF5 (dev par National Center for SuperComputing Applications, 5eme version)**
+structure:
+
+- ressemble à une arboraissance de fichier
+- élément structurant est le *group* (répertoire) qui contient un ou plusieurs *dataset* (fichier)
+- les *group* peuvent être imbriqués
+- pas de structure imposé pour les métadonnées
+- idem pour les données (on peut y stocker un article)
+
+manipulation:
+
+- bibliothéque C plus compliqué que celle pour le format FITS car le format HDF5 est plus "souple"
+ - bibliothéque vient avec l'application HDFView (codé en java) pour l'exploration
+- h5py pour python
+- h5, hdf5r et rhdf5 pour R
+
+
+### L'archivage
+- zenodo -> cern
+- figshare -> privé
+
+### conclusion
+les vraies données:
+
+- grosse et problème de structure
+- complexes et ont besoin de métadonnées
+- Format FITS et HDF5 sont des solution de formatage de ces données
+- En compléxité et fléxibilité: FITS < HDF5
+- archivage pour stockage pérenne et accessible
+
+
+## L'enfer du logiciel
+
+### Passage à l'échelle : les codes complexes
+
+Notebook long devient vraiment difficile à lire
+
+- un vrai plat de spaghettis
+ - pas de vision d'ensemble
+ - interaction entre plusieurs langages = **danger**
+
+Utilisation d'un workflow pour bien comprendre l'ensemble du code, avec représentation en graphe
+
+**Workflow**
+
+- vue de haut niveau plus claire
+- composition de codes et mouvements de données explicites
+- partage, réutilisation, et exécution plus sûre
+- le notebook en est une forme à la fois appauvrie et plus riche
+- pas de façon simple de passer d'un notebook à un workflow
+
+exemples:
+
+- galaxy, kepler, taverna, pegasus, collective knowledge, vistrails
+- **légers**: dask, frake, swift, snakemake, makefile...
+- **hybrides**: SOS-notebook, ...
+
+**L'usine à gaz des calculs coûteux**
+Calcul interminable qui peuvent rendre le notebook inutilisable
+
+- jupyter et les supercalculateurs : en dev
+- checkpoint et cache
+- workflow permet de passer à l'échelle (checkpoint naturel)
+
+
+### Passage à l'échelle: les environnements complexes
+l'horreur des dépendance
+
+Pas de standard pour la gestion des éco-systèmes
+
+gestionnaire de paquet:
+
+- linux: apt, rpm, yum
+- macOS X: brew, McPorts, Fink
+- Windows : Chocolatey, scoop
+
+Il faut controler l'environement dans lequel on travaille
+
+sur VM ou conteneur
+
+**Conserver le bazar**: capture automatique de l'environnement, CDE, ReproZip
+
+**Faire le ménage**: partir d'un environnment vierge, installer que le nécessaire et l'expliciter, docker/singularity, guix/nix
+
+conteneur: aucune bibliothéque de la machine sera utilisée
+
+### l'épreuve du temps
+Probleme de repro FreeSurfer -> resultat different entre windows/linux/!= os mac
+
+orgmode aussi
+
+outil à dev rapide
+
+- évolution rapide et peu poser problème
+ - besoin de vérifier la reconstructibilité et la fonctionnalité de ces environnements (intégration continue et test de non régression)
+
+ce restreindre a ce qui est maitrisable (c / cpp)
+
+L'archivage
+
+- git (hub, lab) stable mais pérenne ? code space fin a cause de pirate
+- software heritage
+- hal
+
+Gestion de l'environnement
+- périnité de l'accés à dockerhub, nix repo, code ocean ?
+- une fois environnement gelé, quelle est la pérennité d'une VM, d'une image docker ?
+
+Concerver le plus d'info possible en automatisant
+- logiciel, version, procédures d'installation
+