[Fiches thématiques] Répartition des fiches thématiques #6

Closed linogaliana closed 3 years ago

In GitLab by @oliviermeslin on Mar 16, 2020, 17:03

Bonjour à tous,

Cette issue est un fil de discussion générale sur la répartition des fiches thématiques. Voici les questions qu'on peut discuter ici:

sur quelle tâche veut-on faire une fiche?
quels packages va-t-on recommander le cas échéant?
qui contribue à la fiche?
quels exemples souhaite-t-on présenter?
dans quel niveau de détail entre-t-on?
et toutes les autres questions que vous avez en tête.

In GitLab by @oliviermeslin on Mar 16, 2020, 17:03

changed the description

In GitLab by @linogaliana on Mar 17, 2020, 09:00

changed title from Répartition des fiches thématiques to {+[Fiches thématiques] +}Répartition des fiches thématiques

In GitLab by @oliviermeslin on Mar 17, 2020, 12:30

Voici une liste de tâches qui pourraient faire l'objet d'une fiche thématique (je reprends cela de 03_Fiches_thematiques/03-fiches_thematiques.Rmd):

Manipuler des données. Deux fiches possibles (à mon sens il faut faire les deux):
- dplyr pour les débutants et pour les petites données;
- data.table pour les utilisateurs plus expérimentés et les grosses données;
Créer ses propres fonctions en R: reprendre la partie 6 de la formation Travail collaboratif avec R;
Ecrire des tables intermédiaires en R (fst)
Importer des fichiers Excel: est-ce vraiment utile sachant qu'on couvre déjà les fichiers plats et les tables SAS?
Exporter des données (quels packages?)
Faire des graphiques (ggplot2)
Traiter des données textuelles (stringr et une introduction aux regex en R)
Utiliser un SGBD en R (DBI et autres drivers)
Rédiger des documents en R (Rmarkdown): reprendre la partie 5 de la formation Travail collaboratif avec R.
Réaliser des cartes: fiche en cours (ici)[https://gitlab.com/linogaliana/documentationR/-/merge_requests/5]
Faire de l'analyse spatiale (éventuellement fusionner avec Réaliser des cartes).

In GitLab by @gillesfidani on Mar 18, 2020, 10:46

@oliviermeslin , @linogaliana ,

on fait qque chose pour https://gitlab.com/linogaliana/documentationR/-/issues/9#note_306914490 ?

proposition :

`

Récupérer des données depuis R

Données ponctuelles

dowload.file

via le standard sdmx (package `rsdmx`)

Données "réparties" (webscrapping)

les licences (cc, etalab, ODbL, ...)

notions de xpath

exemples

`

Je pourrais contribuer pour la partie "données ponctuelles" (titre de la section provisoire, à redéfinir/préciser)

In GitLab by @oliviermeslin on Mar 18, 2020, 13:00

Oui, très bonne idée. Tu peux créer une branche et une issue si tu veux, et commencer la rédaction de la fiche.

In GitLab by @ggenin on Mar 28, 2020, 09:37

Bonjour, je vais tenter de travailler un peu ces jours-ci sur dplyr.

une remarque : "Importer des fichiers Excel: est-ce vraiment utile sachant qu'on couvre déjà les fichiers plats et les tables SAS?" Je dirais malheureusement oui, car la moitié des données viennent d'insee.fr, et... tout y est en XL ! Par exemple Estel niveau A38 région-dept : 144 onglets, avec en plus pas mal de boulot pour en faire une table exploitable. J'ai bien galéré !

In GitLab by @oliviermeslin on Mar 28, 2020, 11:03

@ggenin: c'est super si tu veux contribuer! Tu as raison, une fiche sur l'importation de fichiers Excel serait sûrement utile. En revanche, je m'interroge sur comment on peut avancer le plus efficacement:

Sur dplyr, je me demande si c'est une bonne idée de rédiger la fiche tout de suite. En effet, je me demande 1/ si on peut réutiliser des supports existants sur internet (j'ai trouvé plusieurs bons tutoriels en français et en licence libre); 2/ comment cette fiche s'articule avec les supports existants d'USSR (dont les codes sources ne sont pas publics à ma connaissance).
Si je devais faire une suggestion, ce serait d'avancer sur la fiche "Importer des données en Excel", plutôt que dplyr, en repartant soit de la fiche "Importer des fichiers plats" soit du modèle de fiche ("03_Fiches_thematiques/Modele_de_fiche.Rmd"). Ca permettrait de compléter les fiches fichiers plats et tables SAS.

Qu'en penses-tu? Si tu veux qu'on s'appelle aujourd'hui c'est possible.

In GitLab by @ggenin on Mar 28, 2020, 13:58

Une fiche sur l'import depuis XL ? Hmm... Je vous le dis, je corrige les noms de colonnes à la main, puis copie-colle dans Notepad et importe dans R avec rio. J'ai récupéré une table d'Insee.fr, "base-cc-serie-historique-2016.ods" et l'importe ainsi :

str_fichier <- "C:/INSEE/Insee/base-cc-serie-historique-2016.txt" tab_indic <- rio::import(file = str_fichier, colClasses = "character", header = TRUE) %>% mutate_at(.vars = -1, .funs = as.numeric)

Je vous le dis, rio + bidouille.

J'ai pris cette table car elle me semble pas mal pour faire du dplyr et des graphiques (avec ggformula). J'avais entendu des critiques sur la nouvelle formation qui passe 5 mn à charger une table SAS de 300 Mo (Naissances), là, cela fait 12 Mo en txt.

In GitLab by @ggenin on Mar 28, 2020, 14:11

C'est vrai qu'il y a des docs sur R un peu partout. La difficulté, c'est de s'y retrouver. Savoir quels packages on préconise, et comment on s'en sert. Et si un peu tout le monde dans notre entreprise pouvait utiliser le même langage, ce serait pas mal, car je ne vois déjà pas d'homogénéité dans ma propre DR. Tout simplement, on ne se coordonne pas, voire on ne se communique pas.

Mon idée était de repérer les fonctionnalités dont on a besoin (dans mon métier d'abord) et de donner des exemples avec des données Insee. Ou plutôt, car partir des besoins est le mieux, repérer des trucs intéressants que j'ai dû faire et montrer une solution simple. J'emploie du dplyr sur lequel j'empile un graphique (ggformula). Ça fonctionne bien si j'ai une bonne table bien fabriquée. Or c'est la fabrication de cette table par bidouillages et corrections qui me prend le plus de temps (ex Estel A38 reg-dept).

In GitLab by @oliviermeslin on Mar 28, 2020, 14:14

Je comprends ta méthode, et je ferais sûrement un truc similaire si j'avais à manipuler de l'Excel avec R (ça m'arrive mais vraiment pas souvent).

Là où je me pose des questions c'est: que voulons-nous recommander aux agents de l'Insee qui doivent fréquemment importer des fichiers Excel en R? Je comprends bien que la solution idéale serait que rien ne soit en Excel, mais comme tu le soulignes justement, tout est en Excel sur insee.fr, donc on est un peu forcés de dire quelque chose...

Voici les idées que j'ai:

Il me semble difficile de recommander aux agents de faire la même manip que toi, car c'est vraiment ad hoc comme méthode (même si je comprends que c'est sûrement plus rapide si tu es familière de R);
Je crois que le COPS (comité de certification des packages R) ne recommande pas l'usage de rio (mais ya pas de recommandation sur Excel à ma connaissance);
on pourrait axer une fiche sur l'un des packages permettant d'importer des fichiers Excel (je pense à openxlsx et xlsx, yen a sûrement d'autres), peut-être après avis du COPS.

Qu'en penses-tu?

In GitLab by @oliviermeslin on Mar 28, 2020, 14:20

@ggenin: je suis entièrement d'accord avec tes constats: il n'y a pas de doctrine d'emploi de R à l'Insee, et sans doctrine claire la transition vers R sera forcément difficile et aboutira à des codes hétérogènes.

C'est pourquoi l'objectif central de cette documentation est de 1/ expliquer comment se servir de R/Rstudio/git/Gitlab à l'Insee; 2/ lister les actions de base (importer, manipuler, faire des graphiques...); 3/ recommander les bons packages pour faire ces actions, avec des exemples faciles à réutiliser. C'est ce que j'ai essayé d'expliquer dans le Readme.md. N'hésite pas à proposer une modification si tu ne le trouves pas assez clair.

In GitLab by @ggenin on Mar 28, 2020, 15:18

Trop de doc à lire, je m'y perds.

Dans Readme.me plutôt que "Elle s'adresse spécifiquement aux agents qui sont débutants ou de niveau intermédiaire en R. En revanche, cette documentation ne s'adresse pas ni aux développeurs stricto sensu, ni aux utilisateurs avancés de R." j'aurais mis "Elle s'adresse à tous aux agents quelque soit leur connaissance de R, afin que nous ayons tous le même langage."

Car sinon, les bonnes pratiques, ce n'est valable que pour les novices ? Les expérimentés ne sont-ils pas aussi concernés, voire d'avantage, car ils devrrrraient donner le bon exemple. En fait, je ne vois pas de dichotomie. Qui dit un truc intelligent doit être capable de le dire de façon intelligible.

In GitLab by @oliviermeslin on Mar 28, 2020, 15:41

Tu as raison, la formulation est perfectible. Elle fait suite à plusieurs discussions avec @linogaliana, @rlesur et @gillesfidani (notamment #9) pour savoir quels sont nos objectifs et le public-cible. Après discussion, nous avons choisi de centrer la doc sur les utilisateurs novices, car il nous semble que c'est eux qui ont prioritairement besoin d'une documentation sur laquelle s'appuyer. La remarque sur les développeurs et les utilisateurs avancés veut juste dire que la doc ne couvre pas les sujets franchement pointus (C++, calcul parallèle, CI/CD sur Gitlab).

Je propose la formulation suivante: "Cette documentation s'adresse à tous aux agents, et en particulier à ceux qui sont débutants ou de niveau intermédiaire en R."

Qu'en penses-tu?

In GitLab by @gillesfidani on Mar 28, 2020, 18:45

Car sinon, les bonnes pratiques, ce n'est valable que pour les novices ? Les expérimentés ne sont-ils pas aussi concernés, voire d'avantage, car ils devrrrraient donner le bon exemple.

la documentation s'adresse à des débutants / intermédiaires. Pour les bonnes pratiques, on présuppose que les utilisateurs avancés les connaissent déjà.

In GitLab by @RLesur on Mar 28, 2020, 19:59

USSR (dont les codes sources ne sont pas publics à ma connaissance)

https://github.com/jllipatz/USSR

In GitLab by @oliviermeslin on Mar 28, 2020, 20:22

Merci Romain, je ne savais qu'ils utilisaient Github. Il faudra sûrement voir avec l'équipe USSR dans quelles conditions on peut réutiliser leurs codes sources (si tant est que nous souhaitions le faire).

In GitLab by @RLesur on Mar 28, 2020, 21:01

"Elle s'adresse à tous aux agents quelque soit leur connaissance de R, afin que nous ayons tous le même langage."

Car sinon, les bonnes pratiques, ce n'est valable que pour les novices ? Les expérimentés ne sont-ils pas aussi concernés, voire d'avantage, car ils devrrrraient donner le bon exemple. En fait, je ne vois pas de dichotomie. Qui dit un truc intelligent doit être capable de le dire de façon intelligible.

Excellentes remarques.

avoir tous le même langage

Je me permettrais d'être en désaccord avec cet objectif. L'intérêt d'un langage tel que R est de disposer d'une énorme boîte à outils (R-base et les packages). A ma connaissance, il n'existe pas, dans R, d'outil miracle qui permette de tout faire en toute circonstance. Suivant le contexte (self/prod, profils des devs, profils des mainteneurs, format/origine des données, nature des traitements, contexte d'exécution des traitements...), certains packages peuvent être formidablement bien adaptés dans un certain contexte et à proscrire dans d'autres.
C'est presque un sujet d'ingénierie.
Par exemple, si j'ai des données très volumineuses sous forme de csv, {data.table} est la solution. En revanche, si ces mêmes données sont déjà sous forme de base de données que je peux requêter alors utiliser {data.table} devient une très mauvaise idée.
Je prends cet exemple car c'est le même sujet qu'avec SAS : si j'ai des données très volumineuses dans une base de données de type big data, il faut faire du SQL pass-through et non une PROC SQL "standard" ou pire encore, une étape DATA.

je ne vois pas de dichotomie

Je suis :100: d'accord avec toi. La dichotomie, telle qu'elle est exprimée (et très certainement mal exprimée), est à relier avec mon point précédent.
Imaginons que les utilisateurs débutants et intermédiaires travaillent à peu près tous dans le même contexte (type de données utilisées, type des traitements réalisé, contexte d'exécution, etc.) alors on peut commencer à esquisser une façon commune de faire pour ces utilisateurs.
Je pense que par "utilisateurs avancés", il était entendu "utilisateurs qui doivent s'adapter à des contextes divers et variés" et donc adapter leurs pratiques au contexte. Dès lors, les recettes valables dans le contexte que rencontrent les "utilisateurs débutants et intermédiaires" peuvent ne plus l'être.
Cela ne veut pas dire que lorsqu'ils se retrouvent dans le même contexte que les "utilisateurs débutants et intermédiaires", les "utilisateurs avancés" ne doivent pas utiliser ces recommandations (bien au contraire).

Pour aller un peu plus loin dans la torture, les orientations prises jusqu'ici dans ce projet de documentation me semblent très bien adaptées au contexte de travail "standard" des utilisateurs R de l'Insee (pour faire court, qui travaillent sous AUS avec des données sous forme de tables SAS ou XLS), contexte de travail que je trouve absolument délirant soit dit en passant.
Pour autant, je peux vous assurer que je ne diffuserai pas ces recommandations au sein de ma structure car je ne voudrais pas que les utilisateurs de R travaillent ainsi dans mon organisation. Non pas que ces recommandations soient mauvaises mais simplement qu'elles ne sont pas du tout adaptées au contexte de ma structure.

Cela signifie également que si un jour le contexte de travail des utilisateurs de R de l'Insee venait à évoluer alors il faudrait faire évoluer les pratiques.

Peut-être qu'un rappel du contexte et de la motivation des choix en fonction du contexte fréquemment rencontré par les utilisateurs de R à l'Insee permettrait d'éclairer cet aspect.

In GitLab by @ggenin on Mar 29, 2020, 09:12

Bonjour !

Je ne disais pas que les expérimentés doivent se mettre des œillères et s'interdire d'employer telle ou telle méthode.

Mais de dichotomie entre débutants et experts, je maintiens qu'il faut l'éviter. D'abord parce que les cas spéciaux ne sont pas forcément moins fréquents chez les débutants (rien qu'avec ces fichiers XL issus d'insee.fr...). Les débutants se contenteront probablement de la première méthode assez simple qui fonctionne, sans chercher à optimiser s'il s'agit de besoins ponctuels. Surtout si ce genre de méthode fonctionne dans 90 % des cas. On pourra donc donner des pistes (valides) pour les autres cas.

Mais les experts, ce serait bien qu'ils respectent une certaine homogénéité de langage et une lisibilité pour tous. De ce que j'en vois dans mon entourage, c'est loin d'être le cas. Chacun fait ce qu'il veut comme il le veut et c'est parfois totalement illisible. Et pour les débutants, on leur propose même de retrouver la logique de SAS dans R..... Je ne parviens même pas à convaincre quiconque de mettre des espaces et de sauter des lignes : on a donc une série d'étapes data les unes à la suite des autres, chacune sur une ligne qui sort de l'écran. Avec table1, table2, ..... table 35...

In GitLab by @RLesur on Mar 29, 2020, 10:07

Mais les experts, ce serait bien qu'ils respectent une certaine homogénéité de langage et une lisibilité pour tous. De ce que j'en vois dans mon entourage, c'est loin d'être le cas. Chacun fait ce qu'il veut comme il le veut et c'est parfois totalement illisible. Et pour les débutants, on leur propose même de retrouver la logique de SAS dans R..... Je ne parviens même pas à convaincre quiconque de mettre des espaces et de sauter des lignes : on a donc une série d'étapes data les unes à la suite des autres, chacune sur une ligne qui sort de l'écran. Avec table1, table2, ..... table 35...

Bon, ben c'est le signe que ces experts n'en sont pas.
Il est vrai que pour ce genre de choses, il ne serait pas absurde que l'Insee impose l'utilisation de {lintr} et {styler}.
Par exemple, dans mon service, on met des cartons rouge à tous les setwd(). En fait, pour les nouveaux arrivants, on leur montre une liste de choses proscrites (dont interdiction du setwd() mais aussi interdiction de sauvegarder le .Rdata en fin de session, obligation d'utiliser les projets RStudio) et une proportion non négligeable de personnes sont "surprises".

In GitLab by @ggenin on Mar 29, 2020, 10:41

Un carton rouge pour tout setwd() ? Faudrait mettre cela dans la liste des courses.

Trouvé dans une formation donnée en local :

Et (je n'avais pas fait attention au contenu et c'est dans la formation nationale, arghh !) :

Comme quoi, il reste du boulot !

In GitLab by @RLesur on Mar 29, 2020, 12:29

Ah ! mais chacun sa liste de bonnes pratiques :smile:
Vous faites comme vous voulez. Je dis simplement que ce n'est pas permis dans mon service :wink:
Je n'ai pas envie que Jenny Bryan vienne y mettre le feu https://twitter.com/hadleywickham/status/940021008764846080

In GitLab by @oliviermeslin on Mar 29, 2020, 13:39

Vos contributions m’ont fait comprendre que certains points n’étaient vraiment pas clairs dans notre approche, et qu’il faut préciser tout ça. Voici mon opinion sur les différents points :

Sur l’objectif de la documentation : comme @RLesur le dit parfaitement, l’objectif est de faciliter la transition de SAS vers R à l’Insee en proposant une documentation adaptée au contexte de travail "standard" des utilisateurs de R de l'Insee. Ce choix a deux conséquences importantes:
- les recommandations ne portent pas sur les meilleurs outils en général, mais sur les outils les plus adaptés, étant donné les conditions d’utilisation de R à l’Insee;
- cette documentation devra être évolutive et s’adapter au contexte interne (exemple : la doc devra changer si l’Insee se met enfin à proposer les données en format bases de données).
Sur la dichotomie débutants/avancés:
- Je pense qu’il n’y a pas de dichotomie entre utilisateurs débutants et avancés en termes de bonnes pratiques, mais qu’il y en a une en termes d’outils utilisés (un
- la formulation maladroite du Readme.md signifie que les outils présentés sont ceux dont des agents débutants et intermédiaires pourraient avoir besoin (importer et manipuler des données, faire des graphiques, faire des cartes). En revanche, les outils destinés à des utilisateurs avancés (Rcpp, calcul parallèle, outils pour le développement de packages) ne sont pas présentés.

Qu’en pensez-vous ?

Je vous propose que nous réécrivions le fichier Readme.md pour arriver à quelque chose de plus clair et de plus consensuel.

In GitLab by @oliviermeslin on Mar 29, 2020, 14:48

mentioned in merge request !20

In GitLab by @ggenin on Mar 29, 2020, 16:53

J'enlèverais toute distinction entre les gens, pour ne garder que les fonctionnalités :

"les outils présentés ici sont des outils du quotidien du statisticien (importer et manipuler des données, faire des graphiques, faire des cartes). En revanche, les outils destinés à des utilisations avancées (Rcpp, calcul parallèle, outils pour le développement de packages) ne sont pas présentés."

In GitLab by @RLesur on Mar 29, 2020, 20:50

Je suis d'accord avec @ggenin : faire des distinctions entre les personnes peut inutilement heurter et donner l'impression qu'il y a les experts et les autres. Plutôt que de parler de "fonctionnalités", je parlerais plus volontiers d'"usage". En tout cas, c'est précisément ce que j'avais en tête dans https://gitlab.com/linogaliana/documentationR/-/issues/2#note_309209898 lorsque j'indiquais que j'utilisais le tidyverse lorsque je me comportais comme un "utilisateur final" (comprendre "usage courant de statisticien") et l'abandonnais pour des usages plus avancés tel que le développement de packages (quoique rlang me fait gagner du temps et me rassure).

In GitLab by @oliviermeslin on Mar 30, 2020, 06:36

@ggenin , @RLesur : merci pour vos suggestions, j'ai essayé de les intégrer. Vous avez raison, c'est inutile de de distinguer les personnes, mieux vaut se concentrer sur les usages.

Est-ce que la rédaction actuelle vous convient?

In GitLab by @RLesur on Mar 30, 2020, 09:15

@oliviermeslin La version qui est là (https://gitlab.com/linogaliana/documentationR/-/blob/64f16b7e2dacdd5e6e3d8675ab3498c9d6dee574/README.md) me convient très bien !

In GitLab by @linogaliana on Mar 30, 2020, 10:13

Je trouve ça mieux également, merci

In GitLab by @mathias.andre on Mar 31, 2020, 14:09

Cet issue me semble trop long / à usage trop large, non? J'ai vu que vous préférez ouvrir un issue à chaque idée de fiche, pour la décrire, en discuter, l'attribuer et le clore quand c'est terminé. Mais je poste quand même ici aussi l'idée proposée dans la ré-ouverture de l'issue #25 et dans ce commentaire

Proposer une liste de fiche tirée du manuel de langage SAS et dire comment le faire en R. La liste à la fin était la suivante (je récopie) : «Comment faire?» :

Des manipulations sur données
Des statistiques univariées
Des statistiques bivariées
Des modélisations
Des tests
Des graphiques
Autre chose

Et ça donnait l'instruction puis renvoyait à la fiche dédiée.

In GitLab by @oliviermeslin on Mar 31, 2020, 14:25

Ca me va. Je ferme cette issue. @mathias.andre : tu ouvres une issue avec la liste de tâches élémentaires à documenter?

In GitLab by @oliviermeslin on Mar 31, 2020, 14:25

closed

InseeFrLab / utilitR