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.

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 à 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”, la gestion 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 comprend une multitude de fichiers que vous ne devez pas comprendre (pour le moment ;) ). Ce projet comprend 7112 commits. Pour le moment, retenez qu’un commit est un état de sauvegarde du projet. Ce projet traite de la manipulation de données et comprend un site web 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 cette page, on peut voir une première barre d’outils comprenant les sections Code, Issues, Pull requests, Actions, Security et Insights (toutes les sections ne seront pas détaillées dans cet ouvrage).

Dépot dplyr de l’organisation tidyversesur 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 comprend 70 issues ouvertes et 4281 issues fermées. On peut en déduire que 70 idées ou bugs 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 la structure de cet espace de réflexion.

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 !

Utilisez vos nouvelles connaissances afin de répondre à 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 avec GitHub dans le contexte d’exercices de niveau III ou de niveau IV à 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 2 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 de gagner du temps) avec le Markdown. Dans un premier temps, on va s’intéresser uniquement au fond. Ensuite, on va déterminer une fiche de style qui va s’attarder sur la forme de notre document.

Le 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) et de se concentrer sur l’écriture dans un premier temps en dissociant le fond de la mise en forme.

À vous de jouer !

Utilise la flèche pour découvrir la forme de ce court paragraphe rédigé en Markdwon.

En partant du fond proposé ci-dessus, on peut également obtenir les formes suivantes.

Ce langage est utilisé dans les issues sur GitHub, sur des forums comme Reddit ou encore pour la rédaction de document avec des éditeurs professionnels de projets.

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

À vous de jouer !

Cet exercice H5P comprend plusieurs exercices. N’oubliez pas de faire l’ensemble des exercices.

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 a cette tâche, qui est ici un travail de groupe.

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 2021-12-24 23:59:59.

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 des experts 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.

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.

Lors de la rédaction de projets 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

Lors de différents essais, on aura tendance à tout garder dans différents fichiers afin de ne rien supprimer 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 projet, 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 projet. Ils vont, par exemple, s’échanger par email différentes versions du travail avec chacun qui y place ses commentaires et modifie différentes parties du texte. 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.

Différents 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 fichier.

• L’utilisation d’un programme d’édition collaboratif 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 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 de versions est gérée par Git. Cet outil remplacera les nombreuses copies d’un même fichier par une sorte d’arbre que l’on peut représenter schématiquement comme ci-dessous :

Représentation de la gestion de fichiers via Git

Comme vous pouvez le voir ci-dessus, on peut suivre la progression de notre projet via un nombre d’étapes représentées sur le schéma par des boules bleues. Chaque étape capture l’état de notre projet au moment où nous avons décidé de l’enregistrer. Pour enregistrer une nouvelle version de votre projet, vous réalisez un commit qui sera accompagné d’un message spécifiant les modifications apportées. Git comprend de nombreux outils très intéressants pour la gestion de versions que vous utiliserez par la suite.

Lorsque l’on travaille seul tout en utilisant GitHub, l’évolution de notre projet ressemblera à l’arbre 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”.

À 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 représentées par des boules bleues et des boules vertes) 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 (boules oranges). Son collaborateur (boules vertes) clône (clone en anglais) ensuite le dépôt sur son ordinateur afin de pouvoir y travailler en local sur son PC. 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 des modifications en local il effectuera à 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 :

• 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 appliqué 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.

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.

• Installation et première utilisation de Git et GitHub dans R. En anglais.

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

• GitHub pour les nuls : pas de panique, lancez-vous !.

1.2.4 Renku

Dans ce cours, nous utiliserons différents logiciels qui nécessitent une installation et un configuration en plusieurs étapes. Afin de vous économiser ces étapes fastidieuses, nous utiliserons un système complètement pré-configuré. Il s’agit d’une machine virtuelle, un ordinateur complet mais dématérialisé en quelque sorte. Nous utiliserons l’une de ces deux formes :

• un système fonctionnant sur un serveur distant et appelé Renku,

• un système local installé sur votre ordinateur et appelé SciViews Box

Renku 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. Par contre, nous utilisons (et développons) la SciViews Box depuis 2015, et pourrons donc passer à cette seconde solution en fonction des besoins. Si Renku ne fonctionne pas bien et/ou si votre ordinateur permet un travail plus rapide avec la SciViews Box, vous pourrez choisir cette seconde option plus tard. Pour le moment, nous allons donc créer notre instance Renku. Suivez le guide…

1. Assurez-vous d’être bien reconnu•e dans le site du cours https://wp.sciviews.org. Pour cela, vous avez suivi les instructions et vous avez cliqué sur le bouton bleu pour lier votre compte GitHub ou cours. Ensuite (et dans cet ordre !) vous avez cliqué dans la bannière supérieure sur l”item “Moodle”, et de là, vous vous êtes connecté avec votre compte GitHub étudiant, vous avez sélectionné votre cours Science des Données I : visualisation, et enfin, vous avez cliqué sur le lien vers le cours depuis cet espace Moodle. Ainsi, le site a reçu maintenant toute l’information nécessaire sur votre identité UMONS. Vous pouvez vérifier cela en allant lire l’encadré d’identification dans le préambule de Science des données Biologiques I. Normalement, ces opérations doivent être familières si vous avez bien suivi la première séance (sinon, demandez de l’aide).

2. Cliquez sur le bouton bleu RStudio dans la bannière supérieure. Le browser web ne trouve pas la machine virtuelle. C’est normal puisque vous ne l’avez pas installée. Vous êtes redirigé•e vers une page qui explique comment installer Renku ou SciViews Box.

3. Suivez les instructions concernant Renku. Vous devez ouvrir une page pour créer un nouveau projet après vous être enregistré•e via GitHub. Attention : les trois derniers champs doivent être remplis avec des informations précises. Suivez les instructions. Tout ceci est à faire une seule fois. Une fois votre projet créé, nommé par défaut “mybox”, vous pourrez repartir de l’étape (4) ou (5) plus tard.

4. Une fois le projet créé, vous allez dans l’onglet Environments. Vous en créez un nouveau (bouton New) s’il n’y en a pas. Sinon, passez à l’étape (5)

5. Si un environnement existe et qu’il est disponible, une icône verte apparaît en début de ligne, et un bouton Connect est disponible à droite… Sinon, attendez que votre machine virtuelle soit prête : cela peut prendre plusieurs minutes. Cliquez sur ce bouton Connect pour ouvrir une fenêtre pour travailler dans votre machine virtuelle via le logiciel RStudio (voir ci-dessous).

Renku “tue” les environnements inutilisés pendant plus de 24h. Pensez donc à toujours bien sauvegarder vos fichiers, et faites bien vos commits et pull/push en fin de session au minimum. Lorsque Renku tue une machine, il fait un backup de certains fichiers et il vous prévient de cela lorsque vous recréerez à nouveau un environnement (étape 4), mais ne vous fiez pas à 100% à ce mécanisme !

Pour sauvegarder durablement la configuration de sa machine Renku, vous pouvez entrer dans l’onglet console l’instruction suivante : renku_save(), suivie de la touche <entrée> pour valider la commande.

Si vous avez une machine virtuelle Renku opérationnelle, vous pouvez passer à la section suivante et vous familiariser avec RStudio. Si pas, pas de panique : nous installerons la SciViews Box qui offrira des services similaires à partir d’une installation locale sur votre PC. Suivez les instructions de vos enseignants dans ce cas.

Contrairement à la SciViews Box, la machine dans le projet Renku est figée. si une mise à jour est nécessaire, il faut créer un nouveau projet comme ci-dessus. Pour éviter de conserver des vieux projets inutilisés, vous pouvez les éliminer, … mais ce n’est pas évident à faire. Voyez la vidéo ci-dessous…

1.2.5 RStudio

Il nous manque encore un outil afin de pouvoir réaliser la rédaction de nos rapports et pouvoir y intégrer des graphiques, des tableaux ou encore des analyses statistiques. Des éditeurs classiques comme Google Docs ou Microsoft Word ne permettent pas d’ajouter facilement des graphiques ou des analyses. Nous vous proposons d’utiliser un environnement complet et optimisé pour réaliser vos analyses, vos graphiques et vos rapports : R. Nous complétons cet environnement par un éditeur de documents appelé RStudio. Ce logiciel travaille main dans la main avec R. Il est lié à git et GitHub. Il permet également des connexions simplifiées à des bases de données. RStudio propose quatre sous-fenêtres que vous pouvez découvrir ci-dessous.

À vous de jouer !

Cliquez sur les symboles + pour découvrir le rôle de chaque 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 comprenant 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 oeuvre, ses ressources. Un autre site web consacré à RStudio en français.

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 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. Tentez de trouver les 4 différences avant de lire la section suivante.

Cliquez sur les symboles + pour découvrir le rôle de chaque fenêtre 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.
2. Le chemin d’accès spécifié dans la fenêtre Console change et spécifie le chemin d’accès du projet. Le dossier du projet devient le dossier racine.
3. La fenêtre Environment change et un nouvel onglet nommé Git vient s’ajouter. Lorsque l’on est dans un projet, il est possible de réaliser des commits, des pull ou encore des push depuis RStudio via cet onglet.
4. La fenêtre contenant l’onglet Files change de dossier pour afficher le dossier lié à mon_projet. Deux fichiers sont ajoutés par défaut au projet.

• .gitignore : Ce fichier permet de spécifier les fichiers que l’on souhaite exclure de gestionnaire de version. Ce fichier est très utile pour exclure de gros fichiers ou bien les versions compilées des R Markdown par exemple.
• mon_projet.Rproj : À la base d’un projet RStudio, on retrouve un mon_projet.Rproj. Ce fichier est placé automatiquement par RStudio. Il s’agit du nom du projet avec l’extension .Rproj. Ce fichier contient les paramètres de configuration de votre projet. Il ne faut pas le modifier. Il est utile pour s’assurer que l’on se trouve dans un projet.

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 comprend toutes les données
  docs               # Le dossier qui comprend toutes les analyses (rapport, présentation,...)
  mon_projet.Rproj   # Fichier de configuration du projet créé par RStudio
  R                  # Le dossier qui comprend tous les scripts d'analyse

À vous de jouer !

Des explications détaillées se trouvent dans l’annexe B.1 qui présente les bases de l’utilisation de RStudio et des projets.

Il est temps d’auto-évaluer votre apprentissage via un tutoriel learnr dans RStudio.

Note : les tutoriels learnrs vous permettent d’auto-évaluation votre progression dans la matière et sont marqués d’une icône en forme de toque verte. Ils s’exécutent directement dans RStudio à l’intérieur de la SciViews Box

Effectuez maintenant les exercices du tutoriel A01La_outils (Les différents outils).

BioDataScience1::run("A01La_outils")