GNU/Linux Magazine 213

Actus & Humeur

p. 06 Faut s’démener au FOSDEM !

IA, Robotique & Science

p. 14 La logique du Jeu de la Vie : exercices amusants de pensée latérale

Système & Réseau

p. 28 Les subtilités de l’équilibrage de charge avec le DNS
p. 36 Gérez vos tickets GitHub en ligne de commandes

IoT & Embarqué

p. 40 Solutions temps réel avec Yocto et Buildroot

Kernel & Bas niveau

p. 50 Détectez les fuites mémoire dans vos programmes
p. 60 Réagir à un kernel panic quand on est développeur

Hack & Bidouille

p. 70 Effectuez automatiquement des captures d’un PDF

Libs & Modules

p. 76 Gérez les dates comme un pro avec SQL

Mobile & Web

p. 82 Modifiez l’ergonomie d’une page web avec Tampermonkey

Sécurité & Vulnérabilité

p. 94 Sécurisez vos applications PHP avec Snuffleupagus

Nous sommes nombreux à développer différents outils dans notre coin. Ces outils pourraient intéresser la communauté et pourtant, bien que convaincus de leur utilité et de la philosophie du logiciel libre, nous ne le faisons pas… Pourquoi ?

Nous voulons tous que notre programme soit le plus abouti possible en termes de fonctionnalités, mais pas toujours nécessairement en termes de qualité et de couverture de la documentation ou des tests. Écrire rapidement une preuve de concept et la documenter c’est une chose, distribuer un outil finalisé dont le code aura été nettoyé, qui sera correctement commenté, qui aura une couverture de tests minimale et une documentation fournie, agrémentée de tutoriels est une tout autre chose. Je suis bien placé pour en parler : de nombreux articles pourraient aboutir à des outils concrets, mais le manque de temps et les articles qui suivent m’empêchent d’aller au-delà. Bien entendu mon code est disponible sur le GitHub  du magazine, mais il ne « vit » plus et n’est utile qu’en lien avec l’article auquel il est rattaché.

Nous sommes donc face à trois cas possibles :

1. ne pas partager notre code et le garder jalousement (mon précieuuuux !) : notre notoriété n'en souffrira pas puisque personne ne verra ce que nous faisons ;
2. ne partager qu'un code parfaitement optimisé, documenté et avec une couverture de tests parfaite : ne nous leurrons pas, ce cas se rapprochera très fortement du premier cas, car nous ne pourrons partager que très peu de projets ;
3. partager le code alors qu'il est fonctionnel, mais n'est pas intégralement commenté, qu'il est documenté a minima  pour pouvoir être installé et utilisé, et qu'il ne possède peut-être pas le moindre test unitaire.

Dans le troisième cas, il sera possible d' « essaimer » de nombreux projets qui seront sans doute des projets « mort-nés » à vos yeux, mais n'en seront pas pour autant inutiles : vous aurez eu le mérite de partager votre méthode pour répondre à un problème. D'autres développeurs pourront s'en inspirer, voire les forker  et ils pourront vous soumettre des remarques, soulever des problèmes ou proposer des corrections. Bien entendu, certains ne manqueront pas de critiquer sans aucune justification qu'une guerre d'église tel ou tel choix, de pointer l'absence de tests unitaires ou autre. Ces personnes-là sont généralement celles qui gardent leur code et ne font rien. Proposez-leur de soumettre un patch et vous n'en entendrez plus jamais parler...

Si l'un de vos projets prend le dessus sur les autres, car il suscite l'engouement de la communauté ou qu'il apparaît comme fondamental dans l'exercice de votre profession, vous pourrez alors lui consacrer le temps nécessaire pour le documenter de manière plus précise et améliorer la qualité du code.

Partagez donc votre code et votre expérience ! Si vous le souhaitez, vous pouvez même le faire au sein de votre magazine préféré : envoyez-moi vos idées ! En attendant, je vous souhaite une bonne lecture et je vous retrouverai le mois prochain...

Tristan Colombo