Pour ceux qui ont suivi ma trépidante carrière, je suis actuellement développeuse d’application dans un institut de biologie, au sein de sa plateforme informatique. En tant que développeuse, j’utilise différents outils pour faire mes différents programmes. Dans ce billet, je vous propose de passer en revue quelques outils, peut-être que ça pourra aider de jeunes développeuses et développeurs à tester et se lancer ?

Une question de langage

Qui dit développement, dit programmation et donc, langage. Les gens qui me connaissent savent que je suis un peu touche-à-tout et que je n’hésite pas non plus à apprendre de nouveaux langages ou de nouvelles méthodes. Mais avant d’utiliser tel ou tel langage, il faut surtout se poser la question suivante : ce langage me permet-il de répondre à mon besoin et est-il pertinent de l’utiliser ?

Bash (Bourne-again shell)

Je travaille essentiellement sous GNU/Linux, ou équivalent. Même pendant mon premier emploi, bien qu’étant sur un poste informatique avec Windows Seven, je travaillais majoritairement sur les serveurs sous Ubuntu. Par conséquent, il a bien fallu que je sois capable de réaliser des petits scripts rapides pour des analyses de fichiers, voire plus. Par conséquent, je ne peux que vous recommander d’apprendre le langage console de votre système d’exploitation de base !

Les plus

• Utilise les commandes natives du système
• De nombreuses options de vérification du type de fichier intégrées
• Possibilité de faire du bash en uniligne
• Possibilité de créer des scripts et de les automatiser facilement et rapidement via une tâche CRON

Les moins

• Proche du système, si vous n’êtes pas un minimum à l’aise avec la ligne de commande, vous risquez de souffrir un peu au début
• La gestion des scripts avec arguments est délicate à aborder

Pour aller plus loin

• Site officiel (en anglais) : https://www.gnu.org/software/bash/
• Documentation officielle (en anglais) : https://www.gnu.org/software/bash/manual/html_node/index.html

Perl

Étant bioinformaticienne de formation, je peux être amenée à manipuler des fichiers textes de différents formats et avec différents formatages, vous n’avez pas idée du nombre de formats VCF (Variant Call Format, un format de fichier spécifique en génétique) différents. Autant Bash peut me permettre d’effectuer des analyses et des extractions rapides, autant Perl peut vraiment sortir du lot pour ce qui est du traitement de fichier par lots et avec tout un tas de tests d’expressions régulières à effectuer. Même si sed et awk sont très performants, il se peut que vous soyez un jour bloqué par leurs limitations : pensez-y si vous manquez de temps !

Perl est un langage qui peut s’apprendre très vite et peut s’écrire de mille et une façons différentes. C’est ce qui en fait sa force et son défaut. Ceux qui sont passés derrière le script d’un biologiste ayant codé sur son coin de paillasse savent de quoi je parle.

Les plus

• Très versatile
• Une large communauté de mongueurs avec beaucoup de pragmas (package Perl, si je ne dis pas de bêtise) existants
• Idéal pour le traitement de gros fichiers
• Pensé initialement pour être une extension de la commande sed, il est maintenant un des, voire le, plus puissant langage d’expression régulière

Les moins

• Très versatile (bis repetita)
• Il existe autant de façons de faire un script Perl qu’il existe de développeurs, il peut parfois être délicat de reprendre de vieux scripts écrits sur un coin de table
• La notion de programmation orientée objet est assez floue voire obscure, au moins pour la version 5, pour le peu que j’ai pu en faire, n’ayant pas encore eu l’occasion de tester la version 6

Pour aller plus loin

• Site officiel (en anglais) : https://www.perl.org/
• La documentation officielle (en anglais) : https://perldoc.perl.org/
• Meta-CPAN, pour trouver tous les pragmas dont vous pouvez avoir besoin (en anglais) : https://metacpan.org/

Python

Je ne peux pas parler de bioinformatique, de Perl, et passer à côté de Python. Ça ne se fait pas ! Bien que cela fasse deux ans que je n’ai pas touché une ligne de code de ce langage, il reste un de mes outils préférés. Il peut même être utilisé en complément de Perl. Le gros avantage de Python, c’est qu’il a une grosse communauté scientifique qui produit beaucoup de modules ! Il est recommandé et de plus en plus utilisé pour le calcul scientifique, notamment pour tout ce qui est intelligence artificielle et blockchain, puisque ce sont les termes à la mode du moment.

Les plus

• La simplicité de sa syntaxe
• Très répandu dans le milieu scientifique
• De très nombreux modules
• Depuis la version 3, facilité de créer un virtualenv sans devoir passer par des outils tiers

Les moins

• Sa capacité à déstabiliser un système GNU/Linux si on ne fait pas attention aux modules installés et désinstallés : toujours prendre le réflexe de faire un virtualenv par projet !
• L’indentation forcée qui peut être rebutante au départ et peut occasionner des erreurs inattendues si on est distrait

Pour aller plus loin

• Site officiel (en anglais) : https://www.python.org/
• Documentation officielle : https://docs.python.org/fr/3/
• LE livre de référence (en anglais) : https://diveintopython3.problemsolving.io/

PHP

Depuis deux ans je fais de nouveau du PHP. Le manuel de PHP est toujours une bible pour qui se retrouve bloqué, et de nombreux commentaires émaillent chaque page de la documentation, ce qui est un excellent point de départ si vous devez réaliser une application web plus ou moins modeste. L’avantage c’est que vous gardez la maîtrise du langage, quoi qu’il arrive.

Les plus

• Un des langages web les plus supportés sur la plupart des offres d’hébergement
• De nombreuses fonctionnalités activables ou non sur le serveur en fonction des besoins

Les moins

• La lourdeur de sa programmation orientée objet
• Pas de système de gestion de paquets natif, il faut passer par un outil tiers comme Composer pour utiliser des bundles (paquet) existants

Pour aller plus loin

• Site officiel (en anglais) : https://www.php.net/
• Le manuel officiel : https://www.php.net/manual/fr/

Symfony

J’ai aussi dû me mettre à Symfony pour finir reprendre un projet terminé à 80% fini à la rache (non certifiée) façon démo. Si vous vous lancez dans une application web qui sera amenée à évoluer et à grossir, tournez-vous plutôt du côté de Symfony et des nombreux bundle (ou package) déjà existants. La communauté semble riche et active et j’ai rarement été réellement dans la panade, même si j’ai parfois dû me creuser les méninges pour réussir à faire un truc ou deux qui ne sont, de toute façon, pas forcément triviaux.

Les plus

• Des mises à jour fréquentes et régulières du framework, mine de rien, ça compte niveau sécurité
• Une documentation en ligne disponible et accessible (même s’il faut accepter certains domaines tiers si vous utilisez uMatrix)
• De très nombreux bundles, fournis par la communauté
• On peut faire du vrai MVC en PHP, sans devoir tout coder

Les moins

• Certaines fonctionnalités manquent parfois d’explications quant à leur utilisation (ingénierie inverse, bonjour !)
• Il faut maîtriser aussi bien Symfony que Doctrine et Twig, respectivement un ORM (outil pour faciliter l’interaction avec la base de données) et un moteur de template (ou squelette de la page à afficher), non natifs mais importés par défaut, ce qui alourdit parfois la recherche de documentation

Pour aller plus loin

• Site officiel (en anglais) : https://symfony.com/
• La documentation officielle (en anglais) : https://symfony.com/doc/current/index.html#gsc.tab=0

Ruby-On-Rails

Ne hurlez pas ! Non, Ruby-On-Rails n’est pas un langage, c’est un framework web. Mais il s’agit d’un framework pour le langage Ruby.

Connaissant déjà Django (framework Python) et Symfony (framework PHP), j’ai été surprise par ma vitesse d’apprentissage et la facilité déconcertante avec laquelle j’ai pu faire un premier jet rapide pour un projet.

Si vous avez besoin de réaliser rapidement une application web, et que vous êtes adepte du MVC, vous serez plus que comblé. Le système de gem (package) de Ruby permet d’avoir rapidement les outils nécessaires pour la construction d’un espace utilisateur, par exemple. Si vous devez interagir avec un LDAP, un système d’annuaire informatique, je vous recommande chaudement Devise !

La documentation de Ruby-On-Rails est bien faite, vous pourrez, en moins d’une journée de travail, comprendre comment faire une migration et des vues, pour faire un petit site de type blog, sans espace utilisateur toutefois. Le tutoriel est vraiment bien fait et vous ne serez pas frustré quand vous vous lancerez dans votre propre projet.

Pour le déploiement, tournez-vous du côté de puma et suivez le guide !

Les plus

• Guide bien rédigé, vous serez rarement bloqué longtemps
• Une bonne communauté de développeurs, de nombreux bundle existant pour couvrir l’ensemble des besoins avancés

Les moins

• Peut ne pas être installé par défaut chez votre hébergeur préféré
• Il peut être tentant d’installer plein de bundles, pensez bien votre projet avant d’en installer qui pourraient faire de la redondance

Pour aller plus loin

• Site officiel (en anglais) : https://rubyonrails.org/
• Les guides officiels (en anglais) : https://guides.rubyonrails.org/
• La documentation officielle (en anglais) : https://api.rubyonrails.org/

HTML, CSS et JavaScript/jQuery

Qui dit framework web dit, forcément, interface web. Étant donné que je travaille seul·e sur la majorité de mes projets, je dois faire aussi bien du back que du front. Certes, ça veut dire que je ne suis experte ni en back, ni en front, mais je dois tout de même être capable d’afficher les données aux utilisateurs.

HTML et CSS sont très utiles pour ce qui est de l’affichage statique pur des données, tandis que JavaScript (à l’aide du framework jQuery) va avoir surtout une utilité d’affichage dynamique. Une portion de la page ne doit s’afficher que si une certaine condition est remplie ? Plutôt que de forcer l’utilisateur à recharger la page à chaque fois, vous pouvez passer par du JavaScript pour faire ça dynamiquement ! Et s’il y a du post-traitement à faire, laissez faire le back (Ruby-On-Rails ou Symfony).

Les plus

• Séparation du fond (HTML) de la forme (CSS) depuis des années, forte robustesse des deux langages
• Possibilité de créer de l’interaction cliente avec JavaScript, pour pallier les limitations de HTML et CSS
• HTML et CSS sont des standards du web
• Accessibilité pour les aveugles et mal voyants

Les moins

• Tous les navigateurs ne respectent pas les normes établies par le W3C
• Apprentissage du CSS parfois délicat quand on veut faire des choses plus poussées
• Possibilité de détériorer l’expérience utilisateur si trop de JavaScript sur la page, certaines personnes bloquent le JS, et certains scripts cassent l’accessibilité, donc point trop n’en faut

Pour aller plus loin

• Les tutoriels du W3Schools (en anglais) : https://www.w3schools.com/default.asp
• Les tutoriels jQuery officiels (en anglais) : https://learn.jquery.com/
• D’autres tutoriels, une fois les bases maîtrisées, chez Alsacreations : https://www.alsacreations.com/tutoriels/

Édition de code source

Atom.io

L’éditeur de texte de GitHub. Il se veut une alternative libre au très connu Sublime Text. Le seul reproche que l’on pourrait faire c’est qu’il ne semble pas être packagé pour GNU/Linux, du coup, il vous faudra passer par le site officiel si vous souhaitez l’utiliser. Dans l’ensemble, que vous soyez sous Mac, GNU/Linux, ou même encore Windows, vous trouverez un installateur sur le site officiel.

Atom.io de base est agréable au premier coup d’œil et il vous permettra de rapidement commencer à travailler. Si vous trouvez qu’il lui manque une fonctionnalité ou deux, vous pouvez passer par le menu des extensions pour trouver votre bonheur auprès des outils mis à la disposition par la communauté. C’est une des fonctionnalités que j’ai trouvé des plus pratiques et agréables à prendre en main. Ça, et le raccourci clavier pour la visualisation en direct des fichiers au format MarkDown !

Seule véritable ombre au tableau : il est développé sous Electron (JavaScript), ce qui fait qu’il est plutôt long à lancer, mais c’est aussi ce qui en fait un outil multi-plateforme largement recommandé.

Les plus

• Une fenêtre de vue plus agréable à l’œil pour le MarkDown, intégrée nativement
• Une bibliothèque de greffons intégrée, facile d’utilisation
• Multi-plateforme

Les moins

• Lenteur au démarrage (merci Electron)
• Pas packagé par la communauté Linux, il faut récupérer le .deb ou le .rpm pour pouvoir l’installer et le mettre à jour.

Pour aller plus loin

• Site officiel (en anglais) : https://atom.io/
• La documentation ou livre de bord (en anglais, traduction approximative) : https://flight-manual.atom.io/

vim

Un éditeur qui fait peur, surtout quand on débute sous Linux. Anecdote et instant confidence !

La première fois que j’ai fait un git commit, je me suis retrouvée sur une fenêtre que je ne connaissais pas, je ne savais pas comment en sortir. Ah, si, en tuant le terminal… Non, le vrai jour où j’ai dû sortir de ma zone de confort c’est quand je devais coder à distance sur un serveur qui ne permettait pas de connexion SSH en mode graphique ! Du coup, mes deux ans à me dépatouiller tant bien que mal sous Emacs, envolées. J’ai pris une petite heure chez moi le soir, j’ai tapé vim tutor dans mon terminal, et j’ai suivi les explications. C’était il y a plus de huit ans, et je l’utilise désormais quotidiennement depuis plusieurs mois.

C’est un éditeur de texte qui se veut léger, multiplate-forme et personnalisable. Il propose de très nombreuses options et fonctionnalités qui peuvent être utilisées ou non, les fonctionnalités de base étant passées en revue dans le tutoriel et couvrant généralement la plupart des cas d’utilisation. Il est également possible de couper sa fenêtre en deux zones tampons (:split et :vsplit, utiliser CRL+W et une flèche directionnelle pour changer de tampon) ou de travailler sur plusieurs fichiers en onglets (taper g+t et/ou g+T pour passer d’un fichier à l’autre). Il existe de très nombreux greffons pour compléter ce qui pourrait vous manquer si vous faites beaucoup de développement : interfaçage avec votre répertoire git, affichage de l’arborescence de fichiers, autocomplétion…

Les plus

• Utilisable sur un large panel de système d’exploitation
• Léger et rapide à exécuter
• Possibilité de le customiser en commençant par l’affichage de la coloration syntaxique, pour aller vers l’implémentation de plugin, en passant par la personnalisation des raccourcis claviers

Les moins

• L’apprentissage se fait doucement, on est un peu (beaucoup) perdu quand on est habitué à l’utilisation massive de la souris
• Une interface très sobre et pas du tout intuitive quand on débute
• Brut de décoffrage quand on n’active pas certaines options, par exemple l’affichage de la coloration syntaxique et la numérotation des lignes

Pour aller plus loin

• Site officiel (en anglais) : https://www.vim.org/
• Un jeu sérieux pour apprendre à utiliser vim (en anglais), sur navigateur : https://vim-adventures.com/

Versionnement du code avec git

Qui dit développement dit production de code source. Et qu’est-ce qui peut arriver de pire quand on passe des heures sur du code ? Perdre, bêtement, la-version-d’avant-qui-marchait-mais-n’était-pas-finie ! Ça peut paraître idiot, mais c’est un cas relativement fréquent, surtout quand on débute. Et même quand on a plus de dix ans d’expérience, pouvoir revenir à la version précédente, c’est plus que du confort : c’est une question de survie !

Dans le monde du développement il existe plusieurs systèmes de gestion de version :

• CVS : pour Concurrent Version System, créé en 1990 par Dick Grune, la dernière release remonte à 13 ans
• (source Wikipédia) ;
• Git : très certainement l’un des plus connus, créé en 2005 par Linus Torvalds, toujours maintenu (source Wikipédia) ;
• Mercurial : créé par Matt Mackall en 2005, toujours maintenu (source Wikipédia) ;
• Subversion, aussi abrégé SVN : fondé en 2000 par CollabNet et maintenu par la fondation Apache.

Bien qu’ayant découvert les systèmes de gestion de version au cours de mes études, j’ai adopté Git quelques années après la fin de celles-ci. Il existe de très nombreuses ressources et de nombreux tutoriels pour apprendre facilement à créer un répertoire Git et comment l’utiliser, je n’ai pas souvenir d’avoir eu autant de facilité avec SVN mais ma mémoire peut me jouer des tours.

Avec Git vous serez en mesure de :

• créer un nouveau dépôt ou en cloner un directement ;
• ajouter des fichiers et les mettre à jour dans le suivi de version ;
• créer et manipuler des branches de travail, ce qui peut s’avérer très utile si vous avez une grosse mise à jour à faire ou si vous êtes plusieurs à développer différentes fonctionnalités et que vous ne voulez pas pourrir le travail commun ;
• revenir à tout moment à une version précédente de votre travail ;
• interfacer directement Git avec votre éditeur de code ou votre IDE préféré si ce dernier vous le permet…

Les plus

• La facilité de travailler à plusieurs sur le même projet
• La possibilité de naviguer entre différentes branches de développement, très pratique si vous faites une refonte graphique pendant qu’une autre personne revoit le cœur applicatif !
• Un seul fichier versionné avec la possibilité de remonter à la version de son choix, on peut revenir à la version précédente comme à la dixième version précédente !

Les moins

• L’apprentissage peut être plus ou moins rugueux
• En cas de conflit entre deux versions il peut être plus ou moins fastidieux de le résoudre
• Se souvenir de faire un git fetch et non pas un git pull quand on a prit une mauvaise habitude…

Pour aller plus loin

• Le site officiel (en anglais) : https://git-scm.com/
• La documentation officielle (en anglais) : https://git-scm.com/doc
• LE livre de référence : https://git-scm.com/book/fr/v2

Et la documentation ?

Si vous suivez ce blog depuis un moment, vous m’avez certainement déjà lu pester sur l’absence de documentation dans certains cas, sinon, je vous invite à lire de l’intérêt d’une bonne documentation.

Il existe différentes pratiques pour créer une documentation. Pour cela vous pouvez :

• utiliser les recommandations du langage principal (perldoc pour Perl, pydoc pour Python…) que vous utilisez et le combiner avec un outil d’auto-génération de la documentation, comme Doxygen, ou simplement utiliser la ligne de commande adéquate dans votre terminal ;
• créer et alimenter un wiki pour chaque outil ou application que vous développez, vous pouvez même le mettre directement sur votre projet sous GitHub si vous ne vous sentez pas assez à l’aise pour le déployer ;
• écrire la documentation avec votre traitement de texte préféré (coucou LibreOffice !) ou carrément
• le faire directement en LaTeX !

Pour ma part, je n’ai pas encore trouvé de recette miracle. Je vais même plutôt avoir tendance à faire un petit mélange des trois méthodes :

• dans mon code source, j’essaie de documenter les fonctions, c’est plus facile après quand on revient sur les sources pour savoir ce que la fonction est censée faire et ce qu’elle est sensée retourner ;
• nous avons un wiki interne (DokuWiki) avec une page personnelle par personne, je remplis donc mes pages de projet afin de garder une trace de comment sont déployées les applications et comment procéder pour les mettre à jour. Très pratique quand vous n’avez pas mis à jour depuis plusieurs mois et que vous avez pris les automatismes d’un autre framework !
• pour les utilisateurs, je prends des captures d’écran, quand c’est possible, et j’écris tout ce qu’ils doivent savoir sur l’application : sa finalité, comment l’utiliser, comment faire telle ou telle action.

Bref, pour les fois où j’ai fouillé dans les internets, il ne semble pas exister de recette miracle pour faire de la documentation facilement sans aucun effort. C’est comme pour coder, il faut se creuser les méninges et s’y mettre, avec parfois un bon coup de pied pour se lancer !

---

Source de l’image d’accroche : Des outils de travail pour la mécanique dans leur mallette. Photographie de NeONBRAND sur Unsplash

Source des images d’illustration :

• logo Bash : https://github.com/odb/official-bash-logo
• logo Perl : http://www.mongueurs.net/
• logo Python : https://fr.wikipedia.org/wiki/Fichier:Python_logo_and_wordmark.svg
• logo PHP : https://www.php.net/download-logos.php
• logo Symfony : https://symfony.com/logo
• logo Ruby-On-Rails : https://rubyonrails.org/
• logo HTML 5 : https://www.w3.org/html/logo/
• logo CSS 3 : https://commons.wikimedia.org/wiki/File:CSS3_logo_and_wordmark.svg
• logo non officiel JavaScript : https://commons.wikimedia.org/wiki/File:Unofficial_JavaScript_logo_2.svg
• logo jQuery : https://fr.wikipedia.org/wiki/Fichier:Jquery-logo.png
• logo Atom : https://upload.wikimedia.org/wikipedia/commons/8/80/Atom_editor_logo.svg
• logo vim : https://fr.wikipedia.org/wiki/Vim#/media/Fichier:Vimlogo.svg
• logo git : https://git-scm.com/images/logos/downloads/Git-Icon-1788C.png