Repères

p.10 Les impacts fiscaux des cryptomonnaies

Dossier : Les cryptomonnaies en pratique

p.24 Introduction au dossier
p.26 À la base des cryptomonnaies : la blockchain
p.50 À la découverte d'Ethereum
p.68 Créez votre propre blockchain privée
p.88 Tester des stratégies d’investissement dans les cryptomonnaies à l’aide d’un bot

Bonus

p.106 Petit glossaire des cryptomonnaies

Qui n’a jamais été confronté à des mises à jour silencieuses ? Si l’on ne prend pas garde à la configuration du système sur lequel on déploie une application ou plus simplement si l’on comment l’erreur d’utiliser une librairie en ligne, il est possible que du jour au lendemain votre application cesse de fonctionner. Dans ce cas-là, la logique veut que l’on s’interroge sur le cas particulier qui n’aurait pas été traité et qui aurait fait dérailler le programme. Le message d’erreur paraîtra complètement obscur, signalant des paramètres manquants ou un mauvais type de paramètre... mais non, nous continuerons à chercher vainement la faute du côté de notre travail, de notre réflexion. Après des heures de recherches infructueuses, il faudra se rendre à l’évidence : non ce n’est pas de notre faute ! La correction en elle-même prendra cinq minutes, le temps de consulter la documentation de l’API (en supposant qu’elle ait été mise à jour quand même) et de modifier le passage de paramètres.

J’ai été confronté de nombreuses fois à cette situation et j’avoue que maintenant je considère le problème à l’envers : lorsqu’une erreur survient après des mois en production, je commence par regarder les mises à jour des bibliothèques.

Les développeurs ne jurant que par les langages de bas niveau trouvent souvent détestable le fait de signaler explicitement les numéros de version des librairies employées dans une application. C’est le cas en Python par exemple avec la gestion des dépendances de Pip indiquant les versions des modules : == pour indiquer précisément la version à employer, <= pour la version maximale, etc. On retrouve le même système pour NodeJS avec NPM. Pourtant, ce mécanisme permet de s’assurer que si vous utilisez la fonction fct(param_1 : int) de la bibliothèque A en version 1.2.5 et que celle-ci passe en version 1.3 où l’appel à fct est désormais fct(param_1 : int, param_2 : str), tout continuera à fonctionner correctement. Bien entendu, il n’est pas possible de mettre en place cette méthode avec tous les langages, mais a minima, lorsqu’elle est disponible, il ne faut surtout pas la négliger ! D’autant plus lorsque les développeurs de librairies font fi de la compatibilité ascendante...

Ce numéro de GNU/Linux Magazine, même hors-série, restant compatible avec le précédent, vous trouverez le sommaire en page suivante... Bonne lecture !

Tristan Colombo