Science Reproductible avec un grand

.title[
# Science Reproductible avec un grand <svg viewBox="0 0 581 512" style="height:1em;position:relative;display:inline-block;top:.1em;" xmlns="http://www.w3.org/2000/svg"> <path d="M581 226.6C581 119.1 450.9 32 290.5 32S0 119.1 0 226.6C0 322.4 103.3 402 239.4 418.1V480h99.1v-61.5c24.3-2.7 47.6-7.4 69.4-13.9L448 480h112l-67.4-113.7c54.5-35.4 88.4-84.9 88.4-139.7zm-466.8 14.5c0-73.5 98.9-133 220.8-133s211.9 40.7 211.9 133c0 50.1-26.5 85-70.3 106.4-2.4-1.6-4.7-2.9-6.4-3.7-10.2-5.2-27.8-10.5-27.8-10.5s86.6-6.4 86.6-92.7-90.6-87.9-90.6-87.9h-199V361c-74.1-21.5-125.2-67.1-125.2-119.9zm225.1 38.3v-55.6c57.8 0 87.8-6.8 87.8 27.3 0 36.5-38.2 28.3-87.8 28.3zm-.9 72.5H365c10.8 0 18.9 11.7 24 19.2-16.1 1.9-33 2.8-50.6 2.9v-22.1z"></path></svg>
]
.subtitle[
## slides : <a href="https://tinyurl.com/ycktp4kv">tinyurl.com/ycktp4kv</a>
]
.author[
### Maxime Jaunatre
]
.institute[
### UR LESSEM | INRAE
]
.date[
### 2022-03-17 (updated: 2024-02-21)
]

---

# Introduction

---
exclude: true

# Science Reproductible avec un grand R

**Résumé :** Le logiciel R est un outil indispensable aux recherches menées au sein d'AMURE.
Dans le contexte du mouvement de la science ouverte, Qu'il s'agisse d'analyse de données, de statistique ou de modélisation,  se pose la question de la reproductibilité de la science  : sommes nous tous capables de réutiliser les outils développés il y a 6 mois, un an ou plus ? Ces outils sont-ils suffisament ouverts pour permettre une utilisation par tout à chacun ? Enfin, à quoi peuvent bien servir des données ouvertes si les outils qui les utilisent ne le sont pas ?
Cette présentation fera un tour d'horizon des bonnes pratiques sous R et des outils qu'il propose afin de faciliter une production quotidienne de science reproductible et ouverte. Au programme : Rstudio, packages, Git/Github, données, documentation.

---
exclude: false

# Objectif : bonnes pratiques en R

## <svg viewBox="0 0 581 512" style="height:1em;position:relative;display:inline-block;top:.1em;" xmlns="http://www.w3.org/2000/svg">  <path d="M581 226.6C581 119.1 450.9 32 290.5 32S0 119.1 0 226.6C0 322.4 103.3 402 239.4 418.1V480h99.1v-61.5c24.3-2.7 47.6-7.4 69.4-13.9L448 480h112l-67.4-113.7c54.5-35.4 88.4-84.9 88.4-139.7zm-466.8 14.5c0-73.5 98.9-133 220.8-133s211.9 40.7 211.9 133c0 50.1-26.5 85-70.3 106.4-2.4-1.6-4.7-2.9-6.4-3.7-10.2-5.2-27.8-10.5-27.8-10.5s86.6-6.4 86.6-92.7-90.6-87.9-90.6-87.9h-199V361c-74.1-21.5-125.2-67.1-125.2-119.9zm225.1 38.3v-55.6c57.8 0 87.8-6.8 87.8 27.3 0 36.5-38.2 28.3-87.8 28.3zm-.9 72.5H365c10.8 0 18.9 11.7 24 19.2-16.1 1.9-33 2.8-50.6 2.9v-22.1z"></path></svg> : Construit par et pour des statisticiens.

- Majorité d'utilisateurs non informaticiens.

- Bonne pratiques de *software engineering* diffusent dans la communauté.

???

Peu d'utilisateurs sont des informaticiens et n'ont pas les réflexes 
de développement logiciel.
L'apprentissage se fait par la communauté et toutes les ressources disponibles 
(présentations, blogs, livres).

Bonnes pratiques viennent des échanges, de la communauté et de la pratique.
]

.pull-right[
<img src="CSU_RepRo_files/figure-html/primula.jpg" width="100%" style="display: block; margin: auto;" />
]

???

Exemple : mon parcours de biologie ne m'a pas donnée les bases d'informatique
par rapport a mon expérience de terrain en écologie.
Beaucoup de formation indépendante en autonomie.
Importance de travailler sur de petits projets persos et de se tenir au courant
des nouveautés de la communauté. S'impliquer.

Je vais aussi présenter plein de choses que j'ai apprises, ou qui existents.
L'important n'est pas de tout tester d'un coup mais d'incorporer aux méthodes 
de travail au fur et a mesure.

???

Et les diapos contiennent le minimum de code.

---

# Reproductibilité ?

##Principe FAIR :

???

Le principe FAIR a été expliqué auparavant pour l'ouverture des données
mais de nombreux parallèles peuvent être utilisés pour le code source.

La présentation va suivre l'ordre FAIR et partir du niveau dossier vers 
une organisation en fichiers.

.pull-right[
<img src="CSU_RepRo_files/figure-html/repro_meme.jpg" width="65%" style="display: block; margin: auto;" />
]

.footnote[
Figure : [Peng. "Reproducible Research in Computational Science". In: *Science* (2011).](https://www.science.org/doi/10.1126/science.1213847)
]

???

Encore une fois, chaque projet se place sur ce spectre et peut s'améliorer par 
de petits ajouts. Pas besoin d'utiliser toute ce qui est présenté.
Le mieux est d'inserer ces bonnes pratiques dès le début des projets.

---

# Findable &#x1F50D;

**Un donnée ou une figure non liées au code qui l'a produit n'est pas reproductible.**

L'emplacement du code doit être explicite. Le trouver ne doit pas être une aventure.

- Noms de scripts explicites. <br/> (on évite les noms comme **test**, **test2**)

- Structure de dossier, **Compendium**

- Disque réseau et/ou en ligne

- Dossier avec noms de **projets** <br/> (sans espaces et accents !)

]

.pull-right[
<img src="CSU_RepRo_files/figure-html/find_source.jpg" width="90%" style="display: block; margin: auto;" />

- Logiciel de control de version (**git**)
]

```r
list.files()[1:4]
```

```
## [1] "CSU_RepRo_files" "CSU_RepRo.html"  "CSU_RepRo.pdf"   "CSU_RepRo.Rmd"
```

???

Bien nommer et placer ses dossiers est important, il ne faut pas perdre de temps
à chercher ses petits scrips.

Les espaces et les accents sont pénibles quand on partage nos dossiers
avec d'autres gens (norme anglophone) et pour l'utilisation d'outils de recherche
d'information (outils linux, grep et scripts R -> norme ASCII)

L'organisation en compendium est détaillée dans la partie "accessible"
Git est detaillé dans les diapos suivantes.

Trouver "géographiquement" le code mais aussi temporellement avec git.

---
exclude: false

# Pourquoi utiliser un CVS ?

Est-ce que vous avez déjà :

- **Fait un changement de code et voulu revenir en arrière ?**
- **Perdu du code ou une sauvegarde trop ancienne ?**
- Voulu voir la difference entre 2 versions ?
- Voulu vérifier l'historique d'un script ?
- **Voulu travailler sur un script a plusieurs ?**
- **Voulu partager votre code à quelqu'un ?**
- Voulu tester une nouveauté sans modifier du code déjà utile ?

Si oui, et dans plein de cas, un système de version control aurait pu vous simplifier la vie.

???

Diapo dite à l'orale avec le comic suivant.

---
background-image: url(./CSU_RepRo_files/figure-html/phd101212s.png)
background-size: contain

# Pourquoi utiliser un CVS ?

???

Multiplier les versions sur un ordi n'aide pas à retrouver facilement le code

---
layout: true

# Git : comment ça marche ?

---

## 3 commandes à retenir : commit, push, and pull

- commit: enregistre une snapshot du code à un certain point temporel. 
<br/>(permet d'associer du texte pour expliquer les modifications)

???

Installation de git sur l'ordinateur et initialisation de dépots dans un dossier
rejoint la notion de compendium (un projet = un dépot git = un dossier)

commit permet un enregistrement d'une étape temporelle pour les fichiers textes
permet de travailler sur tout fichier texte simple (md, tex, R, code...)

Important de bien nommer ses commits pour se retrouver temporellement

- pull: met a jour le projet local avec la dernière version du projet<sup>*</sup>

- push: met en commun les modifications locales avec le projet principal<sup>*</sup>

???

Important : git est indépendant de github et peut s'utiliser en solitaire.
pull et push permet de mettre à jour un dépot par rapport à un autre, 
souvent en ligne.

---

???

commit = doc temporelle, important de pas nommer n'importe comment sinon on s'y 
perd.

---

## Sauvegarder en ligne ?

???

Github est juste un serveur web avec git d'installer dessus et qui peut 
fonctionner comme un drive.

Permet de travailler à plusieurs ordinateurs (une personne) ou du coup à
plusieurs.

Important de commencer seul sur un petit projet pour appréhender le systeme

Github = Microsoft (GAFAM)

---
exclude: true
<img src="CSU_RepRo_files/figure-html/gitlab/gitlab_ifremer.png" width="100%" style="display: block; margin: auto;" />

**Connection avec login extranet**, possibilité de partager à des membres externes.

???

gitlab est une alternative, moins répandue mais plus souveraine.
Ifremer héberge un gitlab et quelques universités également.

quoi qu'il arrive les dépots github/gitlab peuvent être totalement privés.

---
exclude: true
<img src="CSU_RepRo_files/figure-html/gitlab/create_proj.png" width="100%" style="display: block; margin: auto;" />

---
exclude: true

???

On peut gérer l'acces aux projets et l'ouvrir au public ou non.
Permet de travailler sur des manuscrits par exemple.

---
layout: false

# Ressources Git

- [Tutoriel ThinkR : R and Git](https://thinkr.fr/travailler-avec-git-via-rstudio-et-versionner-son-code/)

- [Advance R &#x1F4D4;, H. Wickham](http://r-pkgs.had.co.nz/git.html)

- [Happy Git and GitHub for the useR](http://happygitwithr.com/)

- [Git cheatsheet](https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf)

- [Quand ça part en vrille](https://github.com/k88hudson/git-flight-rules)

- [Réparer une erreur](http://ohshitgit.com/)

- [Créer une nouvelle branche avec git et merge des branches](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches)
]

.pull-right[
<img src="CSU_RepRo_files/figure-html/git.png" width="90%" style="display: block; margin: auto;" />
]

???

Beaucoup d'information est disponible.
Encore une fois, il vaut mieux commencer sur un petit projet où l'on est à
l'aise.

---
layout: true

# Accessible &#x1F4C2;

---

## COMPENDIUM &#x1F4E6;

[Marwick et al. "Packaging Data Analytical Work Reproducibly Using R (and Friends)". In: *The American Statistician* (2017).](https://peerj.com/preprints/3192/)
]

.pull-right[
<img src="CSU_RepRo_files/figure-html/mar_ucompd.png" width="65%" style="display: block; margin: auto;" />
]

???

Vraiment lire l'article de Marwick 2017.
Le package R est l'exemple typique de code reproductible et distribuable.

A gauche on a l'exemple minimal d'un compendium et à droite la structure la 
plus complete. Cela dépend de quelques fichiers clés que je vais détailler,
mais on peut y rajouter des dossiers comme data, raw_data, test etc.

Organiser nos projets comme des packages permet d'utiliser des outils
de développement et d'avoir accès à des outils reproductibles (test, doc etc.)

---

- Aide à l'installation et l'utilisation

- Pour ajouter à un projet : `usethis::use_readme_md()`

<img src="CSU_RepRo_files/figure-html/readme.png" width="90%" style="display: block; margin: auto;" />
]

???

Générallement le premier fichier à lire quand on ouvre un projet.
Format de présenter du code et du texte pour montrer des exemples.

.pull-right[
- **`LICENCE`** : sans licence, un code est théoriquement inutilisable. <br/>(**MIT**, **GNU GPL**, **CC**)

Dicte les droits d'utilisation, de copie, de modification d'un code.

[Loi Numérique n°2016-1321](https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000033205142/2020-09-21/) impose une licence libre pour tout logiciel produit avec des fonds publics.

A nuancer avec les questions de publications, de tutelles etc.
]

???

Faire le lien avec la notice Licence écrite pour IAM.
Prendre le temps de lire la Licence CeCILL en Fr peut être bénéfique
pour comprendre les enjeux et s'ouvrir à l'open source.

---

## Projet = Package &#x1F4E6;

```
Package: todormd
Type: Package
Title: Using todonotes in rmarkdown package
Version: 0.1.0
Authors@R: c(
    person('Maxime', 'Jaunatre', 
    email = "maxime.jaunatre@yahoo.fr", 
    role = c('aut', 'cre'))
    )
Description: Personnal project number x
License: CeCILL-2
Encoding: UTF-8
Imports:
    knitr, 
    rmarkdown
RoxygenNote: 7.1.1
Suggests: 
    testthat (>= 3.0.0)
```

???

Diapo davantage tournée vers la structure de package.

DESCRIPTION est un fichier pensé pour être lue par l'ordi également
ajoute la notion des dépendances d'un package.

]

Permet d'informer sur un changement majeur ou des nouveautés. Important d'avoir un cycle de version avec :<br/> `0.1.1` > `0.1.0`

[Why and how maintain a NEWS file for your R package?](https://blog.r-hub.io/2020/05/08/pkg-news/)

- Pour ajouter une dépendances au projet : `devtools::use_package("tidyr")`

<div class="figure" style="text-align: center">
<img src="CSU_RepRo_files/figure-html/devtools.png" alt="   " width="15%" />
<p class="caption">   </p>
</div>
]

???

NEWS permet d'informer l'utilisateurs des changements entre différentes versions
d'un projet. Bien tenu à jour, il complète git.

---

## Documentation &#x2139;

- Rédiger en amont (`{Roxygen2}`)

```r
#' half_life
#' 
#' compute half_life percentage.
#' 
#' @param period period in minute
#' @param time time elapsed (min)
#'
#' @return percentage.
#' @author M. Jaunatre <mail>
#' 
#' @examples
#' half_life(20, 20)
#' half_life(20, 40)
#' 
half_life <- function(period, time){
  return((1 - 2^(-time/period)) * 100)
}
```
]

???

Il vaut mieux documenter en amont comme cela on réfléchis à ce que l'on code.
Permet de clairement identifier ce que l'on prend en entrée et ce que l'on 
retourne.

Permet également d'écrire quelques exemple.

.pull-right[
<img src="CSU_RepRo_files/figure-html/document-all-the-things.jpg" width="100%" style="display: block; margin: auto;" />
]

???

La redondance dans la documentation est bénéfique !

---

## Documentation &#x2139;

**Forme longue de documentation**

- `{Rmarkdown}` ! Permet de mélanger texte (**md**, `$\LaTeX$`) et code **R**.

- Vignettes pour les packages

- Rédaction d'articles -> `{rticles}`

- Diapos -> `{xaringan}`

- Livre -> `{bookdown}`

- Site web -> `{pkgdown}`

<div class="figure" style="text-align: center">
<img src="CSU_RepRo_files/figure-html/rmarkdown.png" alt="   " width="15%" /><img src="CSU_RepRo_files/figure-html/knitr.png" alt="   " width="15%" /><img src="CSU_RepRo_files/figure-html/rticles.png" alt="   " width="15%" /><img src="CSU_RepRo_files/figure-html/xaringan.png" alt="   " width="15%" /><img src="CSU_RepRo_files/figure-html/bookdown.png" alt="   " width="15%" /><img src="CSU_RepRo_files/figure-html/pkgdown.png" alt="   " width="15%" />
<p class="caption">   </p>
</div>
]

.pull-right[
<img src="CSU_RepRo_files/figure-html/markdown.png" width="100%" style="display: block; margin: auto;" />
]

???

Rmarkdown permet de tout lier et de ne fournir qu'un seul document contentant
l'analyse et la rédaction. Permet de s'assurer que tout tourne,
exemple des scripts stochastiques !
moins de fichiers annexe comme les png et jpeg etc. Juste un fichier et des données

Diapo faites avec Xaringan

rticles est très efficaces pour produire des pdfs au format de soumissions.
Intéressant car cela supprime l'export de figures et assure qu'elles sont
toujours à jour.

---

## Lisibilité

```r
# Title ####
# Author, date, contact (?) etc
# Description

## Depends ####
library(matreex)
# remotes::install_github(
#   "github.com/gowachin/todormd"
# )

# sources 
sources("R/hello_world.R")
# functions
foo <- function(){cat("Don't panic !")}

## Datasets ####
read.csv(file = "raw_data/P_abies.csv")

## Edit Dataset ####

## Plots ####
## Export ####
```
]

???

Organisation d'un script présenté ainsi permet au lecteur de 
s'assurer qu'il peut le reproduire
par exemple les librairies au début facilite la vie au lecteur, 
il ne faut plus chercher les dépendances

functions au début permet d'utiliser le principe DRY

- **KISS** (Keep it Simple, Stupid) <br> plein de petits fichiers > script infini

- `{cleanR}`: nettoyer les lignes inutiles.

- `{styleR}`: reformate le code.

<img src="CSU_RepRo_files/figure-html/unreadible.png" width="100%" style="display: block; margin: auto;" />
]

???

si beaucoup de fonctions apparaissent -> faire un script externe
si beaucoup de librairie apparaisent -> KISS et nouveau script.

---

## Lisibilité

```r
#                 Bad                 #
if(`T`){print(10)}
 `T` <- FALSE
 `mean` <- function(x) sum(x)

if (y < 0 && debug) 
*  message("y is negative")
*  stop("error for in y test")

*function_with_many_argument("that", many)

function_with_many_argument(x = "that", 
*  many)

x` = `5
i = 0` ; y=12`
```
]

```r
#                 Nice                #
if(TRUE){print(10)} # Full logical
testing <- FALSE # name conflict
use_sum <- function(x) sum(x)

if (y < 0 && debug) {
  message("y is negative")
  stop("error for in y test")
} # Braces

function_with_many_argument(
  x = "that",
  y = many # name args
) # line limit = 80

x <- 5 # arrow
i <- 0
y <-12
```
]

"**Code needs a lot of whitspace. That is how it breathes.**" Roger Peng

???

Toujours mettres les valeurs logiques en entier.
Attention a ne pas renommer des fonctions qui existent déjà, R est trop gentils.

Pas d'obligation d'indentation ou d'acollades, mais simplifie la lecture.

Pas de limites de lignes mais autant se limiter à 80 charactères (origine des cartes perforées IBM)
Les retours à la lignes après les virgules sont très lisibles.
Nommer les arguments des fonctions maisons permet aussi de faciliter la lecture.

Attribuer variable à une valeur est plus lisible avec "<-", "=" étant reservé pour les appels de fonction.
Préferer une attribution de variable par ligne.

---
layout: true
# Interopérable &#x1F4CE;

---

**Un projet ne doit pas dépendre de l'ordinateur qu'il utilise** -> Portabilité

Cela signifie l'oublis de ces commandes maudites :

```r
*setwd("C:/home/maxime/Documents/Projet magnifique/mouette/analyse/bob/modèle/Tset/")
```

```r
rm(list = ls()) # -> Supprime uniquement les objects "utilisateurs"
                # -> Ne supprime pas des dépendances chargées.
                # -> Indique une sesssion R ouverte depuis 30 ans
                # -> Vide l'environnement des copains qui veulent aider
                # -> Fait aussi disparaitre les bébés phoques
```

Si votre script possède ces lignes, **Jenny Bryan viendra bruler** votre ordinateur. &#x1F525;

Solution ? Utiliser les **Projets Rstudio** ou `{here}`

???

Non vraiment il ne faut pas s'en servir...
Liens vers le blog de Jenny Bryan à la fin du diapo

Je n'ai pas testé le package {here} mais il semble une bonne alternative pour
ceux qui n'utilisent pas Rstudio.

---

`File -> New Project -> New Directory`

???

Comment créer un projet

---

Dans un project, tout les chemins sont basés sur la racine du projet (où ce situe `.Rproj`)

Désactiver la sauvegarde automatique !

`Tools -> Global options -> General -> un-tick "always save history"`

???

Désactiver la sauvegarde automatique permet d'assurer la reproducibilité car
chaque session devient indépendante et doit donc être reproductible.

---
layout: true

# Reusable &#x1F503;

---

## Données

Un script ne doit dépendre que des données présentes dans son projet.

- Eviter les `.RData` ! Indice de données trop complexes et de script pas clair.

Seule exception : les données de type cache : faire tourner les scripts plus facilement.

Package `{targets}` pour refaire tourner que les parties modifiées ou dépendantes d'un script.

???

On doit pouvoir supprimer les .RData et le dossier data car ce sont des données
temporaires et donc reproductibles.

Le mieux étant de privilégier l'export vers des données de type CSV, excell, etc.
Il faut penser à la reproductibilité même en dehors de R, et laisser la possibilité
d'utiliser d'autres outils que R comme python ou excell.

---

Parfois les données sont complexes et **non distribuables**.

- **ReprEx** : Avoir un **exemple** reproductible simplifié pour chaque script.

Exemple : ici la fonction prend un object en entrée...mais quel format doit-il avoir ?

```r
rm_dups <- function(data){
  data <- data[! duplicated(data$x), ]
  data
}
```
]

???

Cette fonction marche sur mon ordi mais je ne peux pas prouver cela sur un ordi
externe car le jeu de donnée est sensible.

```r
df <- data.frame(x = c(0,1,1,0), 
                 y = c(2,1,0,0))
rm_dups(df)
```

```
##   x y
## 1 0 2
## 2 1 1
```
]

???

Un exemple reproductible permet de démontrer que cela marche.

Fournir un exemple est un très bon début de documentation.

Exemple = niveau 0 du test !

---

## Test !

Nous testons tous nos codes à la main, et ça marche sur le coup...mais 2 semaines après ?

- Ecrire des tests unitaires qui font tourner le code tout seul. <br/> -> Dossier `test/`

- `usethis::use_testthat()` charge automatiquement `{testthat}`

<img src="CSU_RepRo_files/figure-html/testthat_logo.png" width="20%" style="display: block; margin: auto;" />
]

.pull-right[
<img src="CSU_RepRo_files/figure-html/test_doc.jpg" width="70%" style="display: block; margin: auto;" />
]

**Il vaut mieux prévenir que guérir !**

???

Vérifier manuellement que le code marche est une première chose,
mais on risque d'oublier ce que l'on fait à la main après 6 mois.

Un test écrit n'oublis pas ce qu'il faut tester.

---

## Test !

Utiliser `{usethis}` pour simplifier la vie !

```r
library(testthat)
add <- function(y,x){
  x+y
}
```

- `usethis::use_test("add")`

```r
tests
├── testthat
│   └── test-add.R
└── testthat.R
```
]

???

usethis crée directement le fichier test au bon endroit et 
me l'ouvre pour l'éditer.

```r
test_that("add works", {
  expect_equal(add(39, 3), 42)
})
```

```
## Test passed 😀
```

```r
test_that("add str error", {
  err = paste("non-numeric argument",
              "to binary operator")
  expect_error(
    add("hello", "world"), err
    )
})
```

```
## Test passed 🌈
```
]

???

Deux tests, un pour vérifier qu'il marche et un autre pour vérifier qu'il 
donne les bonnes erreurs.

Rédiger des tests n'est jamais agréable mais sauve du temps plus tard.

**Retour rapide** lors de la modification du code + assurance de rien casser.

???

Prendre une méthode de travail où l'on exécute tout les tests après chaque 
modification du code.

---
layout: false

# A retenir

.pull-left[
<img src="CSU_RepRo_files/figure-html/mar_ucompd.png" width="65%" style="display: block; margin: auto;" />
]

- **Lisibilité** (structure script)

- **ReprEx** (exemples)

- **Tests**

<img src="CSU_RepRo_files/figure-html/document-all-the-things.jpg" width="70%" style="display: block; margin: auto;" />
]

---
layout: false

# Trouver de l'aide pour R &#x1F64F;

.pull-left[
## RTFM<sup>*</sup>
- utiliser les aides `help(sum)` ou `?sum`
- lire les **manuels** de packages [ggplot2](https://ggplot2.tidyverse.org/)
- avoir les **cheatsheet** quelque part !

## [Stack overflow <svg viewBox="0 0 384 512" style="height:1em;position:relative;display:inline-block;top:.1em;" xmlns="http://www.w3.org/2000/svg">  <path d="M290.7 311L95 269.7 86.8 309l195.7 41zm51-87L188.2 95.7l-25.5 30.8 153.5 128.3zm-31.2 39.7L129.2 179l-16.7 36.5L293.7 300zM262 32l-32 24 119.3 160.3 32-24zm20.5 328h-200v39.7h200zm39.7 80H42.7V320h-40v160h359.5V320h-40z"></path></svg>](https://stackoverflow.com/questions/tagged/r)
## Issue Github <svg viewBox="0 0 496 512" style="height:1em;position:relative;display:inline-block;top:.1em;" xmlns="http://www.w3.org/2000/svg">  <path d="M165.9 397.4c0 2-2.3 3.6-5.2 3.6-3.3.3-5.6-1.3-5.6-3.6 0-2 2.3-3.6 5.2-3.6 3-.3 5.6 1.3 5.6 3.6zm-31.1-4.5c-.7 2 1.3 4.3 4.3 4.9 2.6 1 5.6 0 6.2-2s-1.3-4.3-4.3-5.2c-2.6-.7-5.5.3-6.2 2.3zm44.2-1.7c-2.9.7-4.9 2.6-4.6 4.9.3 2 2.9 3.3 5.9 2.6 2.9-.7 4.9-2.6 4.6-4.6-.3-1.9-3-3.2-5.9-2.9zM244.8 8C106.1 8 0 113.3 0 252c0 110.9 69.8 205.8 169.5 239.2 12.8 2.3 17.3-5.6 17.3-12.1 0-6.2-.3-40.4-.3-61.4 0 0-70 15-84.7-29.8 0 0-11.4-29.1-27.8-36.6 0 0-22.9-15.7 1.6-15.4 0 0 24.9 2 38.6 25.8 21.9 38.6 58.6 27.5 72.9 20.9 2.3-16 8.8-27.1 16-33.7-55.9-6.2-112.3-14.3-112.3-110.5 0-27.5 7.6-41.3 23.6-58.9-2.6-6.5-11.1-33.3 2.6-67.9 20.9-6.5 69 27 69 27 20-5.6 41.5-8.5 62.8-8.5s42.8 2.9 62.8 8.5c0 0 48.1-33.6 69-27 13.7 34.7 5.2 61.4 2.6 67.9 16 17.7 25.8 31.5 25.8 58.9 0 96.5-58.9 104.2-114.8 110.5 9.2 7.9 17 22.9 17 46.4 0 33.7-.3 75.4-.3 83.6 0 6.5 4.6 14.4 17.3 12.1C428.2 457.8 496 362.9 496 252 496 113.3 383.5 8 244.8 8zM97.2 352.9c-1.3 1-1 3.3.7 5.2 1.6 1.6 3.9 2.3 5.2 1 1.3-1 1-3.3-.7-5.2-1.6-1.6-3.9-2.3-5.2-1zm-10.8-8.1c-.7 1.3.3 2.9 2.3 3.9 1.6 1 3.6.7 4.3-.7.7-1.3-.3-2.9-2.3-3.9-2-.6-3.6-.3-4.3.7zm32.4 35.6c-1.6 1.3-1 4.3 1.3 6.2 2.3 2.3 5.2 2.6 6.5 1 1.3-1.3.7-4.3-1.3-6.2-2.2-2.3-5.2-2.6-6.5-1zm-11.4-14.7c-1.6 1-1.6 3.6 0 5.9 1.6 2.3 4.3 3.3 5.6 2.3 1.6-1.3 1.6-3.9 0-6.2-1.4-2.3-4-3.3-5.6-2z"></path></svg>
]
.pull-right[
## Livres et blogs
- [Advance R, Hadley Wickham](https://adv-r.hadley.nz/)
- [Git et Rstudio, ThinkR](https://thinkr.fr/travailler-avec-git-via-rstudio-et-versionner-son-code/)
- [Project-oriented workflow, Jenny Bryan](https://www.tidyverse.org/blog/2017/12/workflow-vs-script/)

## Conférences
- [Code smells and feels, Jenny Bryan](https://youtu.be/7oyiPBjLAWY)
- Toutes les conférences UseRs <svg viewBox="0 0 576 512" style="height:1em;position:relative;display:inline-block;top:.1em;" xmlns="http://www.w3.org/2000/svg">  <path d="M549.655 124.083c-6.281-23.65-24.787-42.276-48.284-48.597C458.781 64 288 64 288 64S117.22 64 74.629 75.486c-23.497 6.322-42.003 24.947-48.284 48.597-11.412 42.867-11.412 132.305-11.412 132.305s0 89.438 11.412 132.305c6.281 23.65 24.787 41.5 48.284 47.821C117.22 448 288 448 288 448s170.78 0 213.371-11.486c23.497-6.321 42.003-24.171 48.284-47.821 11.412-42.867 11.412-132.305 11.412-132.305s0-89.438-11.412-132.305zm-317.51 213.508V175.185l142.739 81.205-142.739 81.201z"></path></svg>
]

## Communauté francophone de R : 
.pull-left[
- [frrrenchies](https://github.com/frrrenchies/frrrenchies) : list de doc fr
]
.pull-right[
- [slack grrr](https://join.slack.com/t/r-grrr/shared_invite/zt-46utbgb9-uvo_bg5cbuxOV~H10YUX8w) : question, news...
]

---

# Merci! Des questions &#x2753;

Slides en ligne [https://gowachin.github.io/R_presentation/CSU_RepRo.html](https://tinyurl.com/ycktp4kv)

[Fichiers source <svg viewBox="0 0 581 512" style="height:1em;position:relative;display:inline-block;top:.1em;" xmlns="http://www.w3.org/2000/svg">  <path d="M581 226.6C581 119.1 450.9 32 290.5 32S0 119.1 0 226.6C0 322.4 103.3 402 239.4 418.1V480h99.1v-61.5c24.3-2.7 47.6-7.4 69.4-13.9L448 480h112l-67.4-113.7c54.5-35.4 88.4-84.9 88.4-139.7zm-466.8 14.5c0-73.5 98.9-133 220.8-133s211.9 40.7 211.9 133c0 50.1-26.5 85-70.3 106.4-2.4-1.6-4.7-2.9-6.4-3.7-10.2-5.2-27.8-10.5-27.8-10.5s86.6-6.4 86.6-92.7-90.6-87.9-90.6-87.9h-199V361c-74.1-21.5-125.2-67.1-125.2-119.9zm225.1 38.3v-55.6c57.8 0 87.8-6.8 87.8 27.3 0 36.5-38.2 28.3-87.8 28.3zm-.9 72.5H365c10.8 0 18.9 11.7 24 19.2-16.1 1.9-33 2.8-50.6 2.9v-22.1z"></path></svg>](https://github.com/gowachin/R_presentation) &nbsp;&nbsp;|&nbsp;&nbsp; [Fichier pdf <svg viewBox="0 0 384 512" style="height:1em;position:relative;display:inline-block;top:.1em;" xmlns="http://www.w3.org/2000/svg">  <path d="M369.9 97.9L286 14C277 5 264.8-.1 252.1-.1H48C21.5 0 0 21.5 0 48v416c0 26.5 21.5 48 48 48h288c26.5 0 48-21.5 48-48V131.9c0-12.7-5.1-25-14.1-34zM332.1 128H256V51.9l76.1 76.1zM48 464V48h160v104c0 13.3 10.7 24 24 24h104v288H48zm250.2-143.7c-12.2-12-47-8.7-64.4-6.5-17.2-10.5-28.7-25-36.8-46.3 3.9-16.1 10.1-40.6 5.4-56-4.2-26.2-37.8-23.6-42.6-5.9-4.4 16.1-.4 38.5 7 67.1-10 23.9-24.9 56-35.4 74.4-20 10.3-47 26.2-51 46.2-3.3 15.8 26 55.2 76.1-31.2 22.4-7.4 46.8-16.5 68.4-20.1 18.9 10.2 41 17 55.8 17 25.5 0 28-28.2 17.5-38.7zm-198.1 77.8c5.1-13.7 24.5-29.5 30.4-35-19 30.3-30.4 35.7-30.4 35zm81.6-190.6c7.4 0 6.7 32.1 1.8 40.8-4.4-13.9-4.3-40.8-1.8-40.8zm-24.4 136.6c9.7-16.9 18-37 24.7-54.7 8.3 15.1 18.9 27.2 30.1 35.5-20.8 4.3-38.9 13.1-54.8 19.2zm131.6-5s-5 6-37.3-7.8c35.1-2.6 40.9 5.4 37.3 7.8z"></path></svg>](https://github.com/gowachin/R_presentation/raw/main/CSU_RepRo.pdf)