1.2 Découverte des outils

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 grâce au regard que vous deviendrez capable d’apporter à l’information de base : les données biologiques issues d’observations de terrain ou d’expériences en laboratoire.

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).

1.2.1 Machine virtuelle

La SciViews Box est une machine virtuelle (un ordinateur complet, mais totalement indépendant du matériel -le hardware- et qui peut être déployé sur pratiquement n’importe quel ordinateur physique). Cette SciViews Box est complètement configurée et dédiée à la sciences des données biologiques. Elle contient tout ce qu’il faut pour importer et analyser vos données, et ensuite écrire des rapports ou d’autres documents prêts à publication ou à présentation. Elle vous servira également à collaborer avec d’autres chercheurs qui peuvent facilement utiliser exactement la même machine virtuelle (aspect reproductible de vos analyses).

Logo de la SciViews Box

Figure 1.1: Logo de la SciViews Box

Des explications détaillées se trouvent dans l’annexe A dédiée à l’installation, la configuration et l’utilisation de la SciViews Box.

À vous de jouer !

Note : lorsque vous voyez le petit logo “H5P” comme ci-dessous, cela signifie que vous avez maintenant un exercice interactif. Cet exercice peut prendre différentes formes (quiz, présentation ou vidéo contenant des questions, vrai ou faux, cliquer sur une image, …).

h5p

1.2.2 RStudio

RStudio est l’outil au sein de la SciViews Box que vous allez utiliser le plus fréquemment durant ce cours.

Il fournit un environnement complet et optimisé pour réaliser vos analyses, vos graphiques et vos rapports. RStudio travaille main dans la main avec le logiciel R qui effectue l’ensemble des traitements.

À vous de jouer !
h5p

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

1.2.3 Markdown

Dans RStudio, les rapports sont rédigés en utilisant le langage Markdown dans la zone d’édition. 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. En effet, vous vous préoccupez de l’aspect final du document dans un second temps, et même, vous pouvez changer radicalement d’avis pratiquement sans rien changer dans le texte (par exemple, il est possible de passer d’une page Web à un document PDF ou Word, ou même encore à une présentation).

Markdown est relativement simple et intuitif à l’usage, même si un petit effort est nécessaire, naturellement, au début. Quels sont les commandes et instructions indispensables lorsque l’on rédige un rapport ? Des titres et sous-titres, une mise en évidence (texte en italique ou en gras), des listes,… Il ne faut au final que très peu de commandes pour réaliser un rapport de qualité avec une mise en page sobre et épurée qui caractérise les travaux professionnels.

Vous avez à votre disposition deux aide-mémoires pour apprendre Markdown : R Markdown Cheat Sheet et R Markdown Reference Guide plus détaillé.

Après avoir rédigé votre document, vous devez cliquer sur le bouton Preview ou Knit (selon le type de document édité) dans la barre d’outils de la zone d’édition pour obtenir la version finale formatée.

À vous de jouer !
h5p
Pour en savoir plus

1.2.4 Gestionnaire de version Git

Lors de la rédaction de travaux un petit peu conséquents, comme un travail de fin d’étude, une publication scientifique ou un rapport volumineux, on se retrouve rapidement avec plusieurs fichiers correspondant à 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.4.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 successives 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éressant pour la gestion de versions que vous utiliserez par la suite.

1.2.4.2 GitHub

Un réseau social a été conçu autour de Git pour sauvegarder vos projets sur le “cloud”, les partager et collaborer avec d’autres personnes. Ce système se nomme GitHub (tout comme Facebook ou LinkedIn). GitHub rassemble donc “Git”, la gestion de version et “Hub” relatif au réseau. D’autres réseaux équivalents existent comme Gitlab ou Bitbucket, mais dans ce cours, nous utiliserons GitHub ensemble, sachant que les notions apprises ici seront réutilisables ailleurs.

Une description plus détaillée de GitHub est présente dans l’annexe B.2 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é.

h5p

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…

h5p

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ées 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

1.2.4.3 GitHub Classroom

GitHub Classroom est une extension de GitHub qui facilite le travail avec GitHub dans le contexte d’exercices à réaliser dans le cadre d’un cours. Vous serez amené à cloner et modifier des dépôts issus de GitHub Classroom pour réaliser vos exercices. Ces dépôts seront privés. Cela signifie que, seuls vous-mêmes et vos enseignants auront accès à ces dépôts, mais vous pourrez aussi les rendre publics, si vous voulez valoriser votre travail de manière plus large.

À vous de jouer !
h5p