Juste avant les vacances d’été, Linus Torvalds a validé une modification portant sur les règles d’écriture de la documentation du code du noyau [1]. Cette modification vise à mettre en place une terminologie dite « inclusive », ce qui signifie qu’il ne faut plus utiliser les termes :

• blacklist (liste noire) / whitelist (liste blanche),
• ou encore master (maître) / slave (esclave).

En lieu et place de ces termes largement employés dans le monde de l’informatique, il est proposé d’utiliser des termes comme :

• denylist (liste de refus) / allowlist (liste d’autorisation),
• blocklist (liste de blocage) / passlist (liste de passage),
• initiator (initiateur) / target (cible),
• leader (chef) / follower (disciple, fidèle),
• ou encore director (directeur) / performer (interprète).

Nous sommes en présence d’une réplique de la frénésie de modification des codes de conduite de 2018 (relire à ce propos le très bon article de Jean-Pierre Troll [2]). Le fait, louable en soi, de vouloir introduire plus de tolérance et d’harmonie entre les développeurs prend une tournure extrémiste complètement irréfléchie. Admettons donc que l’on décide de ne plus employer les termes « maître » et « esclave » renvoyant pour certains aux traites négrières même s’il faut avoir un esprit particulièrement torturé pour penser à cela en se retrouvant par exemple devant deux disques durs branchés en maître / esclave. N’employons donc plus ces termes et imaginons des étudiants débutant leurs études. Comment vont-ils comprendre que les termes initiateur / cible employés par leur enseignant font référence à la même notion que directeur / interprète trouvée dans un livre ou encore à maître / esclave lu dans un magazine résolument rétrograde ? Il n’y a pas de consensus sur les termes à employer en remplacement ! Alors, comment faire pour se faire comprendre ? L’informatique est une science ! Nous sommes là pour transmettre et acquérir de nouveaux savoirs et non pour nous torturer l’esprit à savoir si chaque mot employé lors de la rédaction d’une documentation pourrait être interprété d’une manière différente de celle que nous avions envisagée si on le place dans un contexte différent. Parce que justement c’est le contexte, l’environnement du mot qui fait son sens et non le mot nu. Je viens d’ailleurs d’écrire le mot « nu », est-ce que pour autant le magazine va être placé dans les kiosques au rayon pornographie ? Va-t-il être interdit au moins de 18 ans ?

Pour reprendre la formule consacrée de Jean-Pierre Troll, y’en a marre de ce prosélytisme américain : ne nous laissons pas gagner par l’intoxication ! Continuez de lire GNU/Linux Magazine, nous ferons en sorte de rester compréhensibles pour ceux qui s’intéressent à la science et aux technologies.

[1] L. TORVALDS, Commit du 10 juillet 2020 sur la « terminologie inclusive » : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

[2] J. TROLL, « Après le code source, le code moral ! », GNU/Linux Magazine n°222, janvier 2019 : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-222/Apres-le-code-source-le-code-moral

Tristan Colombo

Retrouvez GNU/Linux Magazine Hors-série n°110 :

• en kiosque
• sur notre boutique en version papier et flipbook (pour vous abonner : https://boutique.ed-diamond.com/abonnements/3-gnu-linux-magazine)
• sur notre plateforme de lecture en ligne Connect 

Depuis quelque temps déjà il se dégage une tendance forte dans le développement logiciel : l’emploi de méthodes de développement dites agiles. De la plus petite TPE/PME à la plus grosse multinationale, il semblerait que désormais tout le monde ne jure plus que par les méthodes agiles. Mais pourquoi donc ?

Les méthodes agiles posent pour base une plus grande implication du client dans le projet et une meilleure réactivité des équipes de développement face à ses demandes. Ainsi, le nombre d’itérations (livraison de versions opérationnelles du projet) sera plus important qu’avec une méthode classique de développement, et le client sera régulièrement consulté pour orienter l’avancée du projet. Or donc, pour une entreprise désireuse de mettre en avant ses processus de développement à des fins purement marketing, il est très rentable de « vendre » de l’agilité : le client ne se sent plus dépossédé de son projet, il peut régulièrement participer à son élaboration… mais sait-il que grâce à lui l’équipe de développement va gagner un temps précieux et permettre à son employeur d’économiser beaucoup d’argent ? En effet, certains ont eu tôt fait de faire le raccourci entre nombreuses itérations/participations du client et délégation des tests utilisateur ! Pourquoi réaliser ce travail fastidieux quand le client peut s’en charger ? En plus ce dernier sera ravi :

• il y aura de nombreuses livraisons du projet ce qui, psychologiquement, aura un impact positif : « mon projet n’est pas mort, je vois bien que des gens travaillent dessus » ;
• le client sera véritablement impliqué et écouté : « je viens de noter un bug à tel endroit, il va être corrigé ».

Les bénéfices sont énormes pour l’entreprise en charge du développement : le client est heureux de payer pour être intégré à l’équipe de développement au rang le plus bas qui soit, celui de testeur. Vous connaissez beaucoup de gens qui payent pour travailler et qui en plus sont contents ? Les développeurs n’ont plus à tester les nouvelles fonctionnalités qu’ils viennent d’ajouter : il leur suffit de signifier à leur client une mise à jour de la version en préproduction et le tour est joué ! Ce dévoiement de l’Agile (avec un A majuscule) montre l’agilité du commercial qui arrive à vendre tout et n’importe quoi à ses clients, ce qui est bien loin de l’aspect technique et cadrant proposé initialement par la méthode…

En suivant la même logique, nous aurions pu vous proposer des articles non relus, non formatés et non mis en page pour « validation » par vos soins de manière à vous impliquer dans le processus de réalisation de chaque magazine. Ce n’est bien sûr pas le cas, alors je vous souhaite une bonne lecture, sans travail supplémentaire et surtout, si vous employez une méthode agile dans votre travail, respectez-en l’essence !

Tristan Colombo

Retrouvez GNU/Linux Magazine n°240 :

• • en kiosque
  • sur notre boutique (pour vous abonner : https://boutique.ed-diamond.com/abonnements/3-gnu-linux-magazine)
  • sur notre plateforme de documentation numérique Connect

Retrouvez ci-dessous la liste des références qui accompagnent l’article « Comment bien construire des applications ? », publié dans LMHS N°110 :

[1] Documentation du module argparse : https://docs.python.org/3/library/argparse.html

[2] Documentation de fileinput : https://docs.python.org/3/library/fileinput.html

[3] Cookbook pour le module logging : https://docs.python.org/3/howto/logging-cookbook.html

[4] Documentation avancée pour le module logging : https://docs.python.org/3/howto/logging.html#logging-advanced-tutorial

[5] Tutoriel pour le module logging : https://docs.python.org/3/howto/logging.html#logging-basic-tutorial

Retrouvez ci-dessous la liste des références qui accompagnent l’article « Gestion du système de fichiers », publié dans LMHS N°110 :

[1] Documentation du module fnmatch : https://docs.python.org/3/library/fnmatch.html

[2] Documentation du module tempfile : https://docs.python.org/3/library/tempfile.html

[3] Documentation du module mmap : https://docs.python.org/3/library/mmap.html

Ce nouveau hors-série de GNU/Linux Magazine vous propose de découvrir l’essentiel pour débuter en programmation avec Python 3. Vous apprendrez pourquoi et comment utiliser les environnements virtuels, les bonnes pratiques pour coder en Python, les modules indispensables à connaître absolument ainsi que les outils pour tester et optimiser vos programmes.

Ce hors-série vous attend en kiosque dès aujourd’hui, sur notre boutique (ports offerts pour toute livraison en France métro.) en version papier et flipbook et sur notre plateforme de documentation numérique Connect. Pensez à vous abonner pour ne manquer aucun numéro  

Au sommaire

Actus

p.06 Côté livres…
p.08 Tendance actuelle : la conteneurisation d’applications

Bas Niveau

p.20 Aller plus loin avec coreboot

Dossier : Python 3

p.30 Les environnements virtuels : pourquoi et comment les utiliser

p.40 Python « moderne » : comment coder en Python en 2020 ?

p.50 Les 10 modules à connaître !

p.72 Gérer les données temporelles, l’internationalisation et la localisation

p.80 Gestion du système de fichiers

p.86 Comment bien construire des applications ?

p.98 Les outils pour les développeurs Python

Web

p.116 Découvrez React Native en créant une liste de courses