Guide du développeur

Bienvenue à toi,

Cette page a 2 rôles : * lister les liens vers l'ensemble de la documentation technique ; * présenter le B-A-BA que doit connaître toute personne désirant participer au projet (le « welcom guide » donc).

Documentation

  1. Généralités
  2. Modèle de données
  3. Regovar Core
  4. API Rest
  5. API cli

Organisation du projet et des sources

Regovar est une application client-serveur. * Regovar désigne en général le serveur ou l'application serveur, mais peut aussi désigner l'équipe qui travaille sur le projet ou « l'organisation » du projet ; * QRegovar désigne le client officiel de Regovar développé en Qt.

Les sources de ces projets sont open-source et accessibles sur les dépôts GitHub: * Regovar * QRegovar

Les dépôts du projet Regovar s'organisent ainsi:

/Regovar
   /docs
   /install
   /regovar               <- tout le code source se trouve ici
       /api_rest             le module pour l'api web (rest)
       /api_cli              le module pour l'api CLI (pour l'instant vide car pas besoin)
       /core                 le module principal (model + core)
       /tests             <- tout le code source additionnel pour les tests
       Makefile
       regovar_server.py  <- run le serveur (api REST)
       regovar_cli.py     <- run Regovar en tant qu'application Python standard
       tests.py    <- run les tests unitaires
   README.md
   LICENSE
   requirements.txt       <- généré par pip

D'une manière générale, l'arborescence de fichier doit respecter le plus fidélement possible l'architecture de Regovar, expliquée ci-dessous.

Architecture système de Regovar

Vue d'ensemble du systeme: Architecture de l'application Regovar Tout est dans le réseau local du CHU. Les utilisateurs accèdent au serveur régovar via le réseau local du CHU grâce au client Regovar prévu à cet effet. Un système de batch et de dossier partagés entre les séquenceur et le serveur Regovar peut être mis en place pour automatiser la récupération des "RUN" dans l'application Regovar, Des mails peuvent être automatiquement envoyé pour prévenir les biologistes que leurs données sont prêtes à être analysées. Selon le même principe, un batch peut être mis en place pour que tout les weekend par exemple les données n'étant plus utilisées depuis un certains temps soient archivés et supprimé du server Regovar afin de libérer de la place. Ces mêmes batchs peuvent surveiller l'état du serveur et envoyer des alertes par mails aux administrateurs si nécessaire. * Les batchs ne font qu'utiliser les services proposés par le serveur Regovar afin d'automatiser certaines tâches. L'ensemble de ses tâches (d'ajout et de suppression de données) peuvent être faites manuellement par les utilisateurs.

Config actuellement prévu pour les serveurs :

CPU 2x (10 coeurs / 20 threads) INTEL XEON E5-2630V4 2.20GHZ SKT2011-3 25MB CACHE BOXED
RAM 128 Go KINGSTON DDR4 4x32 ECC REG KVR21R15D4K4/128
Disques dur 2x 4 T0 CONSTELLATION ES.3 4TB SAS 3.5IN 7200RPM 128MB 6GB
Carte mère oui GIGABYTE MD80-TM0 CARTE MERE SERVEUR
Carte graphique oui SAPPHIRE R7 240 2G DDR3 PCI-E
Total ~ 4 700€

Architecture de l'application Regovar

Architecture de l'application Regovar Les données sont stockées dans la base de donnée. (voir la doc sur la DB) L'application Regovar est découpée en deux parties : * le Core, qui est composé du Model et des Managers ; * l'API, qui va définir un certains nombre de Handlers afin de pouvoir aider le Client à interagir avec Server. Actuellement deux API sont prévues : * l'API Rest pour interagir à distance avec le serveur via Internet ou un réseau local; * L'API Cli pour interagir en local directement avec le serveur via des lignes de commandes. Le Model est la couche donnée de l'application. Ce sont des objets Python qui vont permettre d'interagir facilement avec la base de données. Et qui vont se charger notamment des opérations de sérialisation et de désérialisation entre l'application et la base de données. Elle repose sur SQLAlchemy. Pour chaque table de la base de données, des class Python dédiées vont être créées. Quand on raisonne en "API", on appelle ces données des Resources. Les Manager sont la couche métier de l'application. Ce sont des objets Python qui vont s'occuper de manipuler les ressources du Model.

Nomenclature et règles de codage

Pour ceux qui connaissent, nous respectons la convention Python PEP8. Pour ceux qui ont la flemme de tout lire, au moins lire le résumé par Sam&Max Cependant, nous tolérons les entorses suivantes : - sauter plusieurs ligne entre définition de class ou de fonction car ça permet d'avoir un code plus aéré; - avoir des lignes de code faisant plus de 80 caractères... Faut pas déconner non plus, on a des écrans larges maintenant.

Documentation

Il est important de bien documenter le code. Chaque fonction et chaque classe doit avoir un commentaire en-tête (entre triple """).

Penser aussi à mettre à jour la documentation en ligne une fois que vous avez terminé ce que vous avez commencé. Ne pas hésiter à mettre un ticket GitHub pour ne pas oublier de faire la traduction dans les autres langues si vous ne le faites pas.

Si vous créez de nouvelles erreurs, se référer à la documentation pour y associer un code et intégrer correctement ces erreurs dans le système mis en place.