1.2 Découverte des outils

À la fin de ce premier module, vous aurez réalisé votre première analyse complète en biologie. Nous avons cependant besoin d’outils (logiciels) pour y arriver.

La science des données requiert d’employer des outils performants que nous avons sélectionnés pour vous parmi la multitude de logiciels disponibles parce que nous faisons le pari que ce seront les outils qui vous seront les plus utiles… dans les 30 prochaines années, c’est-à-dire pendant une bonne partie de votre carrière (voir un poster présentant la philosophie du cours).

Les outils logiciels que vous apprendrez à utiliser dans ce cours vont littéralement vous transformer. Vos capacités d’analyse et de compréhension du vivant seront transcendées.

1.2.1 GitHub

Pour bien débuter ce cours, vous avez été guidé pour créer un compte sur GitHub. Il est temps de définir ce premier outil. GitHub est un réseau social permettant de sauvegarder vos projets sur le “cloud”, les partager et collaborer avec d’autres personnes. Les utilisateurs peuvent se regrouper sous une organisation afin de faciliter la collaboration. Ce réseau social a la particularité d’être centré sur les projets et utilise un gestionnaire de version de projet nommé Git (nous aborderons Git plus loin dans ce module). Ce nom provient de l’association “Git”, le gestionnaire de version et “Hub” relatif au réseau.

Découvrons un projet qui s’intéresse à la manipulation de tableau de données (filtrer des lignes spécifiques, calculer de nouvelles colonnes, trier le tableau en fonction d’une colonne spécifique…). Nous utiliserons ce projet dans ce cours. Le projet dplyr est partagé par l’organisation tidyverse. Ce projet va nous permettre d’explorer quelques éléments de GitHub. Nous nous attardons uniquement sur certains éléments clés.

À vous de jouer !

Cliquez sur les symboles + pour découvrir les éléments importants d’un projet sur GitHub

Ce projet héberge une multitude de fichiers que vous ne devez pas comprendre pour le moment ;). 7112 “commits” y ont été réalisés (au moment où la capture d’écran a été faite : le projet a évolué depuis et les nombres cités ne sont certainement plus d’actualité par rapport au site aujourd’hui). Pour le moment, retenez qu’un “commit” est un état de sauvegarde du projet. Ce projet traite de la manipulation de données. Un site Web lui est associé <dplyr.tidyverse.org>. Un grand nombre de contributeurs ont participé à ce projet (plus de 240). Un fichier README.md sert de page de présentation.

En haut de la page, on peut voir une première barre d’outils présentant les sections Code, Issues, Pull requests, Actions, Security et Insights (toutes les sections ne seront pas détaillées ici).

Dépôt dplyr de l’organisation tidyverse dans GitHub

Lors d’un travail en équipe, vous allez vous poser des questions et avoir envie d’échanger vos idées. GitHub met à votre disposition un espace dédié à la discussion et à la collaboration. Il s’agit des Issues. La section Issues permet de mettre en avant un problème ou une idée afin d’améliorer ce projet. Une issue est un espace de discussion et de collaboration centré autour d’une question. Par exemple, le projet dplyr a 70 issues ouvertes et 4281 issues fermées. On peut en déduire que 70 idées ou bogues sont en cours de correction ou de réflexion et que 4281 sont considérés comme terminés. Ce projet est assez dynamique. Cliquez sur l’une de ces issues et observez comment la page se présente.

Quand vous aurez un problème ou une idée, utilisez donc les issues pour discuter avec vos encadrants ou vos collaborateurs.

À vous de jouer !

Testez vos nouvelles connaissances en répondant à la question ci-dessous.

GitHub n’est pas le seul réseau social centré sur Git. D’autres réseaux équivalents existent comme Gitlab ou Bitbucket. Cependant, nous utiliserons GitHub ensemble, sachant que les notions apprises ici seront réutilisables ailleurs.

1.2.1.1 GitHub Classroom

GitHub Classroom est une extension de GitHub qui facilite le travail dans le contexte d’exercices de niveau III ou de niveau IV (les projets individuels et en groupes) à réaliser dans le cadre d’un cours. Vous serez amené à modifier des dépôts issus de GitHub Classroom pour réaliser vos exercices. Ces dépôts seront privés. Seuls vous-mêmes et vos enseignants aurez accès à ces dépôts, mais vous pourrez aussi les rendre publics, si vous voulez valoriser votre travail de manière plus large.

1.2.2 Markdown

Lorsque l’on rédige un document, on perd beaucoup de temps à décider de l’interligne, de choisir la taille et la police… On peut diviser en deux grandes étapes la rédaction d’un document. Il y a le fond et la forme. Nous vous proposons un outil pour booster votre productivité (et donc pour gagner du temps) avec Markdown. Dans un premier temps, on va s’intéresser uniquement au fond. Ensuite, on va déterminer comment le document sera mis en forme.

Markdown est relativement simple et intuitif à l’usage, même si un petit effort est nécessaire, naturellement, au début. Il permet de baliser le texte pour indiquer le sens des différentes parties (par exemple, pour indiquer les différents niveaux de titres). L’apparence finale du titre sera, quant à elle, définie dans une feuille de style séparée.

À vous de jouer !

Déplacez de droite à gauche le curseur sur l’image ci-dessous pour découvrir la forme finale que pourra prendre ce court paragraphe rédigé en Markdown (fond noir = vue dans l’éditeur, fond blanc et forme finale dans un navigateur Web).

En partant du document Markdown ci-dessus, on peut également obtenir différentes présentations et différents formats finaux. Ci-dessous, deux feuilles de style différentes ont été appliquées sur ce même document. La présentation diffère (police de caractères, couleurs, taille du texte …)

Le langage Markdown est utilisé dans les issues sur GitHub, sur des forums comme Reddit ou encore pour la rédaction de document avec divers éditeurs de textes, dont celui inclus dans RStudio que vous utiliserez durant ce cours.

Consultez les liens Mastering Markdown et la première section de R Markdown Reference Guide afin d’en apprendre plus sur la syntaxe de Markdown.

À vous de jouer !

Cet exercice H5P comprend plusieurs questions. Assurez-vous de les passer toutes en revue l’une après l’autre.

Pour en savoir plus

• Le Markdown comme langage d’écriture universel ?

• Markdown Cheat Sheet : A quick reference to the Markdown syntax. Les bases de la syntaxe en Markdown.

• Markdown. Explication en anglais de l’intérêt d’employer Markdown ainsi que la syntaxe à employer.

• Un guide pour bien commencer avec Markdown

• Comment écrire confortablement et professionnellement ? Le Markdown !. Utilisation de Markdown afin de revenir à l’essence de la rédaction.

À vous de jouer !

Nous allons mettre en pratique les nombreuses nouvelles notions vues jusqu’à présent. Nous travaillerons tous ensemble dans un dépôt bac à sable afin de poser des questions via des Issues sur GitHub en utilisant les formatages de texte Markdown.

Note : les “projets GitHub Classroom” sont marqués du logo “Octocat” (mascotte mi-chat mi-poulpe de GitHub). Il s’agit généralement d’exercices de niveau 3 ou 4. L’accès à cette tâche, qui est ici un travail de groupe se fait via un encadré bien identifiable.

Réalisez en groupe le travail A01Ga_biology_challenge.

Travail en groupe de 100 pour les étudiants inscrits au cours de Science des Données Biologiques I : visualisation à l’UMONS à terminer avant le 2022-09-30 13:00:00.

Initiez votre projet GitHub Classroom

Voyez les explications dans le fichier README.md.

Si vous souhaitez plus d’information sur GitHub Classroom, vous pouvez vous référer à l’Appendice B.3. Après avoir réalisé cet exercice, vous serez plus aguerris dans l’utilisation des “issues” GitHub. À ce stade, vous pourrez rejoindre le dépôt dédié aux issues de ce cours présenté dans le préambule (voir Issues). C’est là que vous poserez vos “vraies” questions relatives à votre apprentissage de la science des données. Attention ! Ne mélangez pas les deux dépôts. Celui de l’exercice n’est à utiliser que durant la première séance du module 1 et le dépôt A00Qa_22M_issues-a22 est celui où vous poserez vos “vraies” questions sur le cours tout au long de l’année (accessible via “Issues dans le bandeau supérieur des pages) !

1.2.3 Gestionnaire de version

Nous avons jusqu’à présent utilisé la partie collaborative de GitHub. Nous allons maintenant nous intéresser à Git, le gestionnaire de version de projet utilisé par GitHub et par RStudio.

Lors de la rédaction d’un court document ou de travaux un petit peu conséquents, comme un travail de fin d’études, une publication scientifique ou un rapport volumineux, on se retrouve rapidement avec plusieurs fichiers correspondants à des états d’avancements du travail :

• TFE_final
• TFE_final1
• TFE_final2
• TFE_final3
• TFE_final…
• TFE_final99

On aura tendance à tout garder dans différents fichiers afin de ne rien perdre d’important. Cette pratique, bien que très courante, comporte le gros désavantage de prendre énormément de place sur le disque de votre ordinateur et de n’être pas pratique. Les questions suivantes peuvent se poser :

• Que se cache-t-il dans la version TFE_finalX ? Après un mois sans travailler sur le fichier, seriez-vous encore capable de faire facilement la différence entre TFE_final2 et le TFE_final3 ?

• Cela se complique encore plus lorsque plusieurs personnes collaborent sur un même document. Ils vont, par exemple, s’échanger par email différentes versions du travail avec les modifications et commentaires de chacun. Cela peut donner quelque chose comme ceci :

• TFE_final

• TFE_final1

• TFE_final1_jacques

• TFE_final1_pierre

• TFE_final2

• TFE_final2_jules

• TFE_final…

• TFE_final99

Dans quel fichier se trouve la dernière version de chaque personne ayant collaboré sur le projet ? Un petit peu dans différents fichiers, sans doute. Plusieurs outils informatiques existent pour faciliter le travail collaboratif comme :

• Le partage de fichiers en ligne (Dropbox, Google Drive, OneDrive). Ces espaces de stockage sur le “cloud” ne règlent toujours pas le problème de collaboration sur le même document.

• Les logiciels d’édition collaborative en temps réel (Etherpad, Google Drive - Docs, Gobby). Il est possible de travailler en même temps sur un même fichier. Cette option ne règle pas le problème du retour vers une ancienne version. Lorsqu’une modification a été réalisée, l’ancienne version est tout simplement écrasée.

• La meilleure combinaison pour gérer ses versions et collaborer : Git et GitHub. Ces outils sont plutôt considérés comme écrits par et pour des geeks. Cependant, ils permettent de gérer et de collaborer de manière efficace sur un même projet contenant du code ou non, et des interfaces facilitant leur utilisation apparaissent comme GitHub Desktop, ou même, les outils Git intégrés dans RStudio.

1.2.3.1 Git

La gestion des versions de vos documents est prise en charge par Git. Cet outil remplacera les nombreuses copies d’un même fichier par différents états de votre document ou dossier que l’on peut représenter schématiquement comme ci-dessous (chaque boule bleue représente une version enregistrée dans le système et les flèches indiquent d’où provient chaque version et où elle est utilisée ensuite) :

Représentation de la gestion de fichiers via Git

Dans ce schéma simple, le flux est linéaire. Mais il est parfaitement possible de créer plusieurs branches différentes, et même de les fusionner plus tard comme on veut. Pour enregistrer une nouvelle version de votre document, vous réalisez un commit qui sera accompagné d’un message explicitant les modifications apportées. Git met de nombreux outils à disposition pour la gestion de ces différentes versions. Vous en utiliserez un certain nombre dans ce cours.

Ce gestionnaire Git peut être couplé à un hébergement sur le cloud, soit pour simplement faire un backup de nos projets, soit pour pouvoir échanger et collaborer. Nous utiliserons GitHub à cette fin dans le cours. Lorsque l’on travaille seul avec GitHub, l’évolution de notre projet ressemblera au schéma ci-dessous :

Représentation des versions successives d’un projet avec GitHub.

On réalise un envoi (push) lorsque l’on souhaite synchroniser nos changements locaux avec la version sur le “cloud”. Plusieurs commits peuvent être envoyés avec un seul push sur le réseau, et c’est d’ailleurs généralement comme cela que l’on procède. L’inverse (rapatrier localement les changements que d’autres collaborateurs ont envoyés sur la version réseau de notre projet) s’appelle faire un pull. Par conséquent, synchroniser complètement notre dépôt GitHub avec la version locale consiste à faite les trois actions dans l’ordre : d’abord un commit pour créer un nouveau point d’enregistrement de l’état du système et y inclure tous les fichiers qui ont été modifiés, ensuite faire un pull pour rapatrier localement les changements qui ont été réalisés par d’autres ou par GitHub lui-même, et enfin, faire un push pour envoyer nos propres modifications dans notre projet GitHub. Les autres utilisateurs feront aussi commit-pull-push de leur côté. Quelquefois, des conflits apparaissent lorsque deux utilisateurs différents ont modifié la même partie d’un fichier. Nous apprendrons à gérer une telle situation. C’est plus facile à faire si on pense bien à faire un pull avant notre push, donc, faites les opérations toujours dans le même ordre.

À vous de jouer !

Note : l’image suivante est interactive. Il vous est maintenant demandé de cliquer dessus pour indiquer quelles flèches représentent une action particulière dans le schéma présenté.

L’avantage principal de GitHub ne réside pas vraiment dans la possibilité de réaliser une sauvegarde en ligne, mais plutôt dans la possibilité de collaborer avec d’autres personnes présentes sur ce réseau comme l’illustre la figure ci-dessous. Deux scientifiques (les versions locales sur leurs ordinateurs respectifs sont indiquées en bleu pour l’un et en vert pour l’autre) collaborent sur un même projet que l’on appelle un dépôt (repository en anglais) lorsqu’il est en ligne. Le premier chercheur (boules bleues) initie le dépôt et réalise un push pour rendre son travail accessible sur le réseau (les versions GitHub sont représentées par des boules orange). Son collaborateur (boules vertes) clone ensuite le dépôt sur son ordinateur afin de pouvoir y travailler. Après avoir fait des changements, il réalise également un push sur le réseau. Le premier scientifique, avant de travailler à nouveau sur le projet, devra donc réaliser un pull afin d’obtenir en local l’ensemble des modifications fournies par son ou ses collaborateurs. Après ses propres modifications, il devra ensuite effectuer à nouveau un push.

À vous de jouer !

Pour être certain que vous ayez bien compris, encore une image interactive à cliquer…

Vous venez d’apprendre le B-A-BA de la terminologie nécessaire à la bonne compréhension de Git et GitHub :

• dépôt ou repository : espace de stockage sous gestion de version Git.

• commit : enregistrer une version du projet.

• clone : créer un double local d’un dépôt GitHub.

• push : envoyer ses modifications locales vers le dépôt GitHub.

• pull : rapatrier les modifications que les autres utilisateurs ont réalisé dans le dépôt GitHub vers sa propre version locale.

Ceci n’est qu’une explication très succincte. Vous trouverez plus de détails dans les liens ci-dessous et dans les Appendices. Il est, par exemple, possible de travailler sur une version en parallèle d’un dépôt original pour lequel vous n’avez pas de droits en écriture. Dans ce cas, il faudra faire une copie dans notre propre compte GitHub du dépôt. Cela s’appelle faire un fork. Il n’est pas possible de faire un push vers le dépôt d’origine puisque vous ne possédez pas les droits en écriture. Dans ce cas, vous ferez un pull request, suggérant ainsi à l’auteur d’origine que vous avez fait des modifications qui pourraient l’intéresser. Si c’est effectivement le cas, il pourra accepter votre pull request et intégrer vos suggestions dans le dépôt d’origine. Vous serez amenés à forker des dépôts GitHub lors de vos exercices, et vous effectuerez également un pull request lorsque vous serez suffisamment aguerris avec les autres techniques de gestion de vos projets sous Git et GitHub.

À vous de jouer !

Effectuez maintenant les exercices du tutoriel A01Lb_git (Gestion de versions avec Git).

BioDataScience1::run("A01Lb_git")

Pour en savoir plus

• Gérez vos codes sources avec Git. Explication en français sur l’utilisation de Git.

• Quel logiciel de gestion de versions devriez-vous utiliser ?. Explication en français sur l’utilisation des logiciels de gestion de versions.

• Git : comprendre la gestion de versions. Explication en français sur ce qu’est Git et comment cela s’utilise en pratique.

• Happy Git and GitHub for the useR. Complet, mais un peu technique et en anglais.

• Git. Site en anglais rassemblant toute la documentation de Git.

• GitHub pour les nuls : pas de panique, lancez-vous !. En français.

1.2.4 SciViews Box

Dans ce cours, nous utilisons différents logiciels qui nécessitent une installation et une configuration en plusieurs étapes. Afin de vous économiser ces étapes fastidieuses, nous employons un système complètement préconfiguré : la SciViews Box pour laquelle une nouvelle version est préparée avant chaque nouvelle année académique. Il s’agit d’une machine virtuelle, un ordinateur complet, mais dématérialisé en quelque sorte. Nous utilisons l’une de ces deux formes :

• un système fonctionnant sur le cloud et nommé SaturnCloud,

• un système local installé sur votre ordinateur et utilisant Docker ou Pacman.

SaturnCloud ne nécessite pas un ordinateur puissant pour fonctionner, mais il faut une bonne connexion Internet. Il faut aussi que le serveur distant soit disponible et offre les ressources suffisantes pour travailler. Cette année, nous l’utiliserons pour la première fois… c’est un peu expérimental, en somme. La version locale avec Docker ou Pacman ne sera utilisée que si nous rencontrons des problèmes avec SaturnCloud. Elle nécessite, en effet, un ordinateur plus puissant et beaucoup plus de place sur le disque pour l’installer.

1.2.5 RStudio

Il nous manque encore un outil afin de pouvoir réaliser la rédaction de nos rapports dans les meilleures conditions et pouvoir y intégrer des graphiques, des tableaux ou encore des analyses statistiques. Des éditeurs de texte classiques comme Google Docs ou Microsoft Word ne sont pas orientés vers la production de documents techniques ou scientifiques. Nous utiliserons donc un logiciel complet et optimisé pour produire de tels documents : RStudio. Celui-ci s’appuie lui-même sur R qui est un langage taillé pour traiter des données, produire des graphiques et des tableaux et réaliser des analyses statistiques.

L’interface de RStudio se présente en quatre sous-fenêtres (on dit aussi des “panneaux” ou panes en anglais) que vous pouvez découvrir ci-dessous.

À vous de jouer !

Cliquez sur les symboles + pour découvrir le rôle de chaque sous-fenêtre de RStudio.

Des explications détaillées se trouvent dans l’annexe B.1 qui présente les bases de l’utilisation de RStudio. Vous avez également à votre disposition un aide-mémoire afin d’appréhender cette interface RStudio IDE Cheat Sheet.

Pour en savoir plus

• RStudio. Site Web de RStudio qui rassemble un ensemble de ressources en anglais

• RStudio, un environnement de développement pour R. Brève explication de RStudio en français.

• RStudio : sa vie, son œuvre, ses ressources. Une autre courte page en français qui présente RStudio.

1.2.5.1 Projet RStudio

RStudio permet de gérer des projets efficacement. Un projet va regrouper l’ensemble des jeux de données, des blocs-notes, des rapports, des présentations, des scripts d’une analyse généralement en relation avec une ou plusieurs expériences ou observations réalisées sur le terrain ou en laboratoire.

À vous de jouer !

Observez les deux images et tentez de repérer chaque différence entre les deux interfaces, l’une hors projet, et l’autre dans un projet nommé mon_projet. Tentez de trouver les quatre différences avant de lire la section suivante.

Cliquez sur les symboles (+) pour découvrir le rôle de chaque panneau de RStudio.

1. Dans la barre d’outils supérieure, on passe de Project (None) vers mon_projet. On peut donc facilement repérer si l’on est dans un projet ou non, et si oui, quel est son nom.
2. Le chemin d’accès spécifié dans la fenêtre Console change et correspond au départ au chemin d’accès vers le projet. Le dossier de base du projet devient le répertoire actif de R à l’ouverture (mais cela peut bien sûr être changé plus tard).
3. Le panneau en haut à droite change et un nouvel onglet nommé Git vient s’ajouter, mais uniquement si les versions du projet sont gérées par Git. Lorsque l’on est dans un tel projet, il est alors possible de réaliser des commits, des pull ou encore des push depuis RStudio.
4. Le panneau en bas à droite contenant l’onglet Files change de dossier pour afficher le dossier de base du projet. Dans ce dossier, nous retrouvons obligatoirement un fichier à l’extension .Rproj ainsi qu’éventuellement un second, .gitignore.

• mon_projet.Rproj : À la base d’un projet RStudio, on retrouve un fichier à l’extension .Rproj. Ce fichier est placé automatiquement par RStudio. Ce fichier contient les paramètres de configuration de votre projet. Il ne faut pas le modifier soi-même. Il est utile aussi pour repérer tout de suite que l’on se trouve dans un dossier de base d’un projet RStudio.
• .gitignore : Ce fichier permet de spécifier les fichiers que l’on souhaite exclure du gestionnaire de version, par exemple, les gros fichiers de jeux de données ou bien les versions compilées des documents R Markdown.

Nous avons donc la structure suivante :

/mon_projet          # Le répertoire de base du projet
  .gitignore         # Fichier relatif à la gestion de version
  mon_projet.Rproj   # Fichier de configuration du projet créé par RStudio

On retrouve trois dossiers principaux dans un projet en science des données. Il y a le dossier data, le dossier docs et le dossier R.

/mon_projet          # Le répertoire de base du projet
  .gitignore         # Fichier relatif à la gestion de version
  data               # Le dossier qui contient les données
  docs               # Le dossier avec les documents de type rapport, présentation, ...
  mon_projet.Rproj   # Fichier de configuration du projet créé par RStudio
  R                  # Le dossier où sont rassemblés les scripts R

À vous de jouer !

Des explications plus détaillées sur les projets dans RStudio et la façon de les créer et de les gérer se trouvent dans l’annexe B.1.1. Il est temps de passer maintenant à un tutoriel learnr pour autoévaluer plus en profondeur votre compréhension de la matière.

Effectuez maintenant les exercices du tutoriel A01La_tools (Vos outils logiciels).

BioDataScience1::run("A01La_tools")