reprise des exos jusqu'à l'appli 2 (#16)

R/script.R

@@ -17,7 +17,7 @@ df <- readr::read_csv2(
 df <- df %>%
   mutate(aged = as.numeric(aged))
 
-summarise(group_by(df, aged), n())
+df %>% group_by(aged) %>% summarise(n())
 
 decennie_a_partir_annee    = function(ANNEE){ return(ANNEE - ANNEE %%
                                                        10) }
@@ -45,9 +45,8 @@ p <- # part d'homme dans chaque cohort
 ggsave("p.png", p)
 
 library(forcats)
-df$sexe <- df$sexe %>%
-  as.character() %>%
-  fct_recode(Homme = "1", Femme = "2")
+df <- df %>% mutate(sexe = as.character(sexe)) %>%
+  mutate(sexe = fct_recode(sexe, Homme = "1", Femme = "2"))
 
 #fonction de stat agregee
 fonction_de_stat_agregee<-function(a,b="moyenne",...){
@@ -73,8 +72,7 @@ api_token <- "trotskitueleski$1917"
 # modelisation
 # library(MASS)
 df3=df%>%select(surf,cs1,ur,couple,aged)%>%filter(surf!="Z")
-df3[,1]=factor(df3$surf, ordered = T)
-df3[,"cs1"]=factor(df3$cs1)
+df3 <- df3 %>% mutate(surf = factor(surf, ordered=T), cs1 = factor(cs1))
 df3 %>% 
   filter(couple == "2" & aged>40 & aged<60)
 polr(surf ~ cs1 + factor(ur), df3)

index.qmd

@@ -34,6 +34,7 @@ Elle a bénéficié des contributions de : [Romain Avouac](https://github.com/av
 [Pierre Lamarche](https://github.com/pierre-lamarche),
 [Romain Lesur](https://github.com/rlesur)
 [Olivier Meslin](https://github.com/oliviermeslin),
+[Julien Pramil](https://github.com/jpramil),
 [Olivier Pucher](https://github.com/Evargalo),
 [Clément Rousset](https://github.com/clerousset),
 Mohamed Seikouri et

slides/_r_fundamentals.qmd

@@ -127,7 +127,7 @@ portion de code plus de deux fois ([**_don't repeat yourself_ (DRY)**]{.red2})
 
 👎 La documentation pallie des mauvais nommages
 
-```
+```{.r}
 # Utilise string si x est non manquant et non vide
 if (!is.na(x) && nzchar(x)) {
   use_string(x)
@@ -136,7 +136,7 @@ if (!is.na(x) && nzchar(x)) {
 
 👍 Les nommages suffisent à comprendre le code
 
-```
+```{.r}
 x_is_not_empty_string <- (!is.na(x) && nzchar(x))
 if (x_is_not_empty_string) {
   use_string(x)
@@ -208,17 +208,26 @@ if (x_is_not_empty_string) {
 
 ## Bilan
 
+
+::::: {.columns}
+
+:::: {.column width="60%"}
+
 - Un code mal structuré
   - Limite la lisibilité du projet
   - Est très coûteux à maintenir (dette technique)
 
-. . .
-
-![](img/reproducibility-lazy.png){fig-align="center"}
-
+- Les petits gestes peuvent économiser un temps précieux
 
+::::
 
+:::: {.column width="40%"}
+::: {layout="[[-1], [1], [-1]]"}
+![](img/reproducibility-lazy-no-bg.png){fig-align="center"}
+:::
+::::
 
+:::::
 
 
 

slides/applications_r/_application0.qmd

@@ -7,19 +7,26 @@
 :::{.callout-tip collapse="true" icon=false}
 ## Préparation de l'environnement de travail
 
+
+
+
 ::: {.nonincremental}
-1. Créer un nouveau dépôt public sur `GitHub`
-2. Lancer un service `RStudio`. Dans l'onglet de configuration `Git` du service, fixer la durée du `Cache` pour le stockage des identifiants `GitHub` à une valeur suffisamment élevée
+1. Application préliminaire: forker le dépôt d’exemple {{< fa brands github >}} [`InseeFrLab/formation-bonnes-pratiques-exo-correction`](https://github.com/InseeFrLab/formation-bonnes-pratiques-exo-correction)[^1]
+2. Lancer un service `RStudio`. Dans l'onglet de configuration `Git` du service, fixer la durée du `Cache` pour le stockage des identifiants `GitHub` à une valeur suffisamment élevée (conseil: 36000)
 3. Cloner le dépôt distant sur votre environnement local (ici, le `RStudio` du `Datalab`):
     + `File` → `New project` → `Version Control` → `Git`
 4. Créer un script `get_data.R` en copiant le contenu de [ce fichier](https://raw.githubusercontent.com/InseeFrLab/formation-bonnes-pratiques-git-R/main/R/get_data.R), puis l'exécuter
-5. Créer le script `script.R` dans votre dépôt en copiant le contenu de [ce fichier](https://raw.githubusercontent.com/InseeFrLab/formation-bonnes-pratiques-git-R/main/R/script.R)
+5. Créer le script `script.R` dans votre dépôt en copiant le contenu de [ce fichier](https://raw.githubusercontent.com/InseeFrLab/formation-bonnes-pratiques-git-R/main/R/script.R). __Ne l'exécutez pas, c'est l'objet de l'exercice suivant__.
 6. Ajouter la règle "individu_reg.*" au fichier `.gitignore`. Que signifie-t-elle ?
-7. *Commit*/*push* les changements
+7. *Commit*/*push* les changements (tous les fichiers, y compris ceux que `Git` a ajouté)
 :::
 
 :::
 
+[^1]: Forker le dépôt vous permet d'avoir les _tags_ permettant d'appliquer les _checkpoints_ si besoin. 
+La démarche pour reproduire ceci est de créer un nouveau dépôt sur `GitHub` en **incluant un fichier `README`** et un `.gitignore` (chercher le modèle `R` dans les suggestions). Mais si vous faites cela vous ne serez pas en mesure d'appliquer les _tags_ des _checkpoints_.
+
+
 ## {{< fa brands gitlab >}} insee
 
 :::{.callout-tip collapse="true" icon=false}
@@ -39,5 +46,6 @@
 :::
 
 
-
 :::
+
+

slides/applications_r/_application1.qmd

@@ -3,27 +3,44 @@
 :::{.callout-tip collapse="true" icon=false}
 ## Partie 1 : vérification du bon fonctionnement du code
 
-Un code reproductible est avant toute chose un code fonctionnel ! Repérez les erreurs qui empêchent le script `script.R` de s’exécuter correctement, et les corriger.
+Un code reproductible est avant toute chose un code fonctionnel !
+
+Repérez les erreurs qui empêchent le script `script.R` de s’exécuter correctement, et les corriger. 
 
 :::
 
+:::{.callout-important collapse="true"}
+## Les pièges que cet exercice vous montre
+
+:::: {.nonincremental}
+- Les fonctions utilisées sans import des _packages_
+- Les chemins et le _working directory_
+- L'ordre des imports
+- Les mauvaises pratiques de gestion de l'environnement (les bonnes pratiques arrivent dans les prochains exercices !)
+::::
+
+:::
+
+
 ## Application 1 {.smaller}
 
 :::{.callout-tip collapse="true" icon=false}
 ## Partie 2 : premiers standards de qualité
 
 ::: {.nonincremental}
-1. Installer les _packages_ `R` [`lintr`](https://github.com/r-lib/lintr) et [`styler`](https://github.com/r-lib/styler).
-2. Définir le _linter_ à utiliser comme étant de type `tidyverse` : `lintr::use_lintr(type = "tidyverse")`
-3. Diagnostiquer le script `script.R` : `lintr::lint("script.R")`.
+1. Installer les _packages_ `R` [`lintr`](https://github.com/r-lib/lintr) et [`styler`](https://github.com/r-lib/styler)[^install].
+2. Définir le _linter_ à utiliser comme étant de type `tidyverse` avec `lintr::use_lintr(type = "tidyverse")`
+3. Diagnostiquer le script `script.R` avec `lintr::lint("script.R")`.
     + Comprenez-vous la nature des problèmes détectés par le _linter_?
-4. Appliquer le _formatter_ au `script.R` : `styler::style_file("script.R")`.
+4. Appliquer le _formatter_ au `script.R` avec `styler::style_file("script.R")`.
 5. Refaire tourner le _linter_. Il reste encore un certain nombre d'erreurs de formattage, car `styler` est un _formatter_ peu intrusif.
-6. Regarder les différents problèmes repérés par le _linter_, et en corriger quelques uns (un pour chaque type de problème).
+6. Regarder les problèmes restants repérés par le _linter_, et en corriger quelques uns (un pour chaque type de problème).
 :::
 
 :::
 
+[^install]: Les `install.packages` sont à faire en console et ne doivent pas être mis dans le script (justification dans la prochaine partie de cet exercice). 
+
 ## Application 1 {.smaller}
 
 :::{.callout-tip collapse="true" icon=false}
@@ -33,6 +50,25 @@ Un code reproductible est avant toute chose un code fonctionnel ! Repérez les e
 1. Limiter les ambiguités sur les *packages* en utilisant la syntaxe `package::fonction` pour les *packages* rarement utilisés dans le script.
 2. L'installation des *packages* dans un script n'est pas une bonne pratique. Supprimer les instructions correspondantes.
 3. Importer le `tidyverse` au complet est rarement utile. N'importer à la place que les *packages* effectivement utilisés dans le script.
+
+<details>
+<summary>
+
+A propos du `rm(list = ls())` (le supprimer !)
+
+</summary>
+
+Cette commande est une mauvaise pratique. 
+
+On la retrouve encore dans trop de scripts car elle est utilisée pour de mauvaises raisons. Elle ne remets pas à 0 votre environnement: elle supprime juste les données de celui-ci, sans toucher au reste (packages importés, etc.).
+
+Il vaut mieux gérer cela en changeant les options de {{< fa brands r-project >}} puis redémarrer la session {{< fa brands r-project >}} (<kbd>CTRL</kbd>+<kbd>SHIFT</kbd>+<kbd>F10</kbd>)
+
+![](img/rdata-setup.png)
+
+
+</details>
+
 :::
 
 :::
@@ -43,12 +79,18 @@ Un code reproductible est avant toute chose un code fonctionnel ! Repérez les e
 ## Partie 4 : (auto-)documentation du code
 
 ::: {.nonincremental}
+
+L'objectif de cet exercice est de remettre de l'ordre dans le script, cela le rendra bien plus lisible.
+
 1. Déplacer les `library` pour les mettre tous ensemble au début du script.
 2. Le script n'est pas construit dans un ordre logique. Déplacer les parties 
 pour adopter une structure plus lisible : 
     + Gestion de l'environnement -> Définition de fonctions -> Import des données -> Retraitement des données -> Statistiques descriptives -> Graphiques -> Modélisation
 3. Donner des titres aux parties/sous-parties en utilisant les standards de documentation reconnus par RStudio :
     + `# TITRE NIVEAU 1 ------------` et `## TITRE NIVEAU 2 ==========`
+4. Documenter la fonction `fonction_de_stat_agregee` selon le standard `roxygen`. Vous pouvez vous aider d'une IA assistante comme `ChatGPT`, `Claude` ou `Copilot`, rien n'est sensible dans ce code (d'ailleurs rien de sensible ne doit être dans du code !). Utiliser les exemples d'utilisation de `fonction_de_stat_agregee` dans cette documentation.
+
+_Au passage, vous pouvez changer les noms de certains objets pour les rendre moins cryptiques (`df3` n'est pas très clair)._
 :::
 
 :::
@@ -82,11 +124,17 @@ Dans cette application, on va explorer deux manières possibles de gérer les se
 
 ## Checkpoint
 
-::: {layout=[30,70]}
-:::{.nonincremental}
+::: {.callout-caution}
+## Checkpoint
 
-- [script.R](https://raw.githubusercontent.com/InseeFrLab/formation-bonnes-pratiques-git-R/main/R/checkpoints/application1/script.R)
+En ligne de commande:
+
+```{.bash}
+git stash
+git checkout appli1
+```
+
+![](checkpoint.jpg){width="30%"}
 
-![](checkpoint.jpg){width=60%}
-:::
 :::
+

slides/applications_r/_application2.qmd

@@ -1,15 +1,17 @@
 ## Application 2 {.smaller}
 
+
 :::{.callout-tip collapse="true" icon=false}
 ## Partie 1 : modularisation du projet
 
 ::: {.nonincremental}
 1. Déplacer toutes les fonctions dans un fichier `R/functions.R`.
-2. Donner à la fonction `fonction_de_stat_agregee` un nom plus pertinent et des noms d'arguments plus transparents.
+2. Donner à la fonction `fonction_de_stat_agregee` un nom plus pertinent et des noms d'arguments plus transparents. N'oubliez pas de mettre à jour la documentation.
 3. Dans `script.R`, appeler en début de chaîne ces fonctions avec `source("R/functions.R", encoding = "UTF-8")`.
-4. Documenter la fonction principale au [format attendu](https://cran.r-project.org/web/packages/roxygen2/vignettes/roxygen2.html) par `roxygen2`.
-5. Ajouter les tests unitaires de la fonction comme exemples d'utilisation et les retirer de `script.R`.
-6. Tester le bon fonctionnement de `script.R`.
+4. Tester le bon fonctionnement de `script.R`.
+5. Si votre chaîne écrit des _outputs_ ou utilise des _inputs_ (par exemple des données), restructurer l'aborescence du projet pour le rendre plus lisible et adaptez votre code en fonction. 
+6. Renommer (voire déplacer) les scripts `get_data.R` et `script.R` pour rendre plus intelligible la chaîne de production 
+7. Mettre à jour le `.gitignore` puis _commit_/_push_
 :::
 
 :::
@@ -33,16 +35,16 @@
 
 ## Checkpoint
 
-::: {layout=[30,70]}
-:::{.nonincremental}
-
-- [script.R](https://raw.githubusercontent.com/InseeFrLab/formation-bonnes-pratiques-git-R/main/R/checkpoints/application2/script.R)
+::: {.callout-caution}
+## Checkpoint
 
-- [functions.R](https://raw.githubusercontent.com/InseeFrLab/formation-bonnes-pratiques-git-R/main/R/checkpoints/application2/functions.R)
+En ligne de commande:
 
-- [Package R](https://github.com/InseeFrLab/formation-bonnes-pratiques-git-R/tree/main/package)
+```{.bash}
+git stash
+git checkout appli1
+```
 
+![](checkpoint.jpg){width="30%"}
 
-![](checkpoint.jpg){width=60%}
-:::
 :::

slides/formation_full.qmd

@@ -31,6 +31,7 @@ css: custom.css
 from: markdown+emoji
 ---
 
+
 ## Introduction
 
 ::: {.nonincremental}
@@ -40,8 +41,10 @@ from: markdown+emoji
 ![](https://inseefrlab.github.io/formation-bonnes-pratiques-git-R/cards/version-full/eagle.png){fig-align="center" height=400}
 :::
 
+
 # Introduction
 
+
 {{< include _intro.qmd >}}
 
 # Partie 1 : contrôle de version avec `Git`
@@ -62,7 +65,6 @@ from: markdown+emoji
 
 {{< include _git_resources.qmd >}}
 
-
 # Partie 2 : bonnes pratiques avec `R`
 
 ## Plan de la partie
@@ -84,8 +86,6 @@ from: markdown+emoji
 {{< include _r_resources.qmd >}}
 
 
-
-
 # Conclusion
 
 {{< include _conclusion.qmd >}}