Ce document est en cours de créations

Introduction

Cette librairie a pour but premier de simplifier mon workflow. En effet, il est difficile de s'organiser pour travailler correctement sur des serveurs à distance. Les serveurs peuvent devenir indisponibles à cause d'un problème ou tout simplement d'une surchage d'utilisation. De plus, il n'est pas toujours possible d'utiliser nos outils de développement sur ces serveurs et les potentielles solutions entraîne la mise en oeuvre d'un workflow plus que douteux. Par exemple, une mauvaise pratique à laquelle j'ai pu m'essayer est de créer un tunnel de fichier grâce à la commande sshfs et d'ouvrir ces fichiers avec notre IDE préféré sur notre machine tout en exécutant le code sur notre machine ou sur le serveur. Cette méthode comportement plusieurs problèmes comme : le manque de gestion de version, le travail sur deux machines en simultannée qui prend une partie de notre concentration nous empêchant de nous focaliser sur ce qui est important.

Ce dépôt est alors une manière pour moi de proposer une méthodologie de travail basée sur python. Cette méthodologie est bien sûr adaptable à d'autres langages de programmation.

Travail local et à distance

Il est important pour moi d'introduire la problématique du travail à distance. Très souvent, les jeunes développeurs, dont j'ai fait parti, ne savent pas comment s'organiser. Il y a ceux qui travaillent directement via VIM sur les serveurs, et d'autres qui utilisent la méthode du SSHFS sur leur machine (laptop ou desktop). D'autres aussi utilisent leur IDE qui crée directement un tunnel vers le serveur. Le problème des deux dernières méthodes est qu'elles solicitent constamment des interactions avec le serveur distant pouvant aider à la saturation du NFS, le protocole de transfert de fichier dans le réseau. De plus, certains effets de bords peuvent apparaître à cause de la synchronisation entre serveur distance et machine locale.

Pour moi, la bonne méthodologie est alors de bien différencier travail en local et travail à distance. Pour cela, je suggère de travailler en développement sur la machine local, qui travaille sur des petits jeux de données par exemple, pour ensuite mettre en application les scripts sur la machine distante. Un très bon outil pour faire cela est git.

Le versionning

C'est là où intervient git. Git permet de réaliser un versionning de ses fichiers. En cas de perte, vous pourrez toujours retrouver toutes vos versions dans les différents clones que vous aurez créés. C'est à la fois une solution centralisée et distribuée du versionning. Grâce à Git, vous pourrez facilement revenir en arrière et mettre à jour vos fichiers sur votre serveur distant.

Organisation des branches

Git permet de faire du versionning mais il permet aussi de créer des branches pour séparer différents aspects du développement. Je vous conseille de créer deux branches différentes au minimum : la branche dev et la branche prod. Cela évitera sur votre serveur distant de mettre à jour l'outil avec des scripts encore non éprouvés, cassant potentiellement ainsi une partie de votre framework.

Il faut donc organiser les branches par dev et prod. Il faut d'abord tester sur dev avant de mettre en prod. Plus d'information sur ce lien : [lien à mettre ici]

Le cas de Jupyter Notebook

Il faut éviter Jypyter Notebook pour les raisons suivante : [écrire les raisons]

Les scripts et la librairie

Cet aspect là de ma méthode de travail est très personnel. Je passe mon temps à créer des scripts qui lisent dans mes fichiers. Ces fonctions de lecture sont toujours les mêmes. J'ai donc créé une librairie qui permet de définir et d'implémenter un ensemble de fonctions qui me sont tout le temps utile. J'ai voulu alors m'en servir dans mes scripts python tout en séparant l'aspect library de l'aspect script. J'ai fini par trouvé une manière de m'organiser.

Ce qui est important est de bien identifier les deux cas pour organiser correctement votre code. Une fois Volia installée, grâce à mon organisation, je peux appeler des scripts facilement :

python -m volia.test

Ces scripts sont enregistrés à la racine de ma bibliothèque Volia et se servent des modules présents dans le reste des dossiers de la bibliothèque. J'ai préféré m'organiser ainsi pour tout encapsuler dans une seule librairie plutôt que d'ajouter dans la première ligne du fichier #!/bin/python, chose qui ne fonctionne d'ailleurs pas avec Windows.

Ce document est en cours de création