Archives des En passant

L’objectif de cet article est d’étudier une étude de cas pratique : mettre en place un nœud IPFS sous une distribution Linux basé sur debian.

Installation du serveur IPFS

sudo apt install golang -y
wget https://dist.ipfs.io/go-ipfs/v0.14.0/go-ipfs_v0.14.0_linux-amd64.tar.gz$
tar xvfz go-ipfs_v0.14.0_linux-amd64.tar.gz

La configuration d’un nœud local se fait simplement en suivant les instructions données par l’exe.

./ipfs init
./ipfs cat /ipfs/XxXX/readme
./ipfs daemon

Le nœud est ensuite opérationnel et consultable sur l’url local suivante :



L’ajout d’un fichier à l’aide de la ligne de commande se fait via : ./ipfs add ../merle.jpg

Cette commande vous affichera le hash correspondant à votre fichier :


Cette valeur ( QmXrMP1aHHQHpuGoGioDbdKcnGtij6yx418Xb9wwoGwgue ) correspond à l’identifiant unique de votre fichier. Il peut ensuite être utilisé pour localiser ou faire des actions dessus.

Depuis l’interface Web, il est possible de vérifier l’enregistrement de votre fichier :

Toutes les actions faisables en ligne sont réalisables depuis la console.
La suppression via rm, l’étiquetage, via pin add pour l’étiquetage de fichier.

La mise en place de ce type de service est ultra-basique. Il est recommandé d’utiliser un service d’étiquetage centralisé pour faciliter la diffusion de ses fichiers. Une fois ceci fait, on peut se lancer dans d’autres expériences : la publication d’un site web statique directement en IPFS, l’hébergement d’une collection de NTF.

L’objectif est de pouvoir proposer de manière simple ces fichiers au plus grand nombre sans risque de défaillance d’un serveur centralisé.

Nota : cet article est assez court mais a pour objectif d’être le premier dans ma découverte du web3. A suivre donc ^^

Référence :

Abyss-project blog

Qu’est-ce que la dette technique ?

La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham. … Cette définition reste vague mais pose le principe d’un coût représenté par un logiciel ou un SI relativement à sa qualité, sa maintenance ou son cycle de vie.

Un métaphore souvent utilisée pour illustrer ce phénomène est celle de la grenouille plongée dans l’eau bouillante : si l’augmentation de la température est lente, les grenouilles resteront tranquillement à leur place jusqu’à se trouver complètement cuites lorsque l’eau sera bouillante. En revanche, si vous jetez une grenouille directement dans l’eau bouillante, celle-ci trouvera immédiatement la force de s’extraire de ce milieu hostile.

Quand produit-on de la dette ?

Les causes de production de la dette technique sont multiples. Mais le critère le plus important est sur le type de production. Cette production est-elle prise en connaissance de cause (suite à des contraintes temporelles ou techniques), ou est-elle produite de manière passive (quand le choix est basée sur des bases non maîtrisées ou suite à des évolutions techniques non suivie).

Dans tous les cas, et surtout dans le second, il faut prendre le temps de faire l’audit des solutions mises en œuvre pour identifier toutes les sources de production de cette dette. Cette dette, tel un produit financier, à un coût. Ne pas le gérer,risque, à très court terme de rendre la solution beaucoup moins rentable qu’escomptée.

Conséquence de la dette technique

Contrairement à une croyance, même avec des équipes au top, il n’est pas possible d’avoir un projet rapide, pas cher et de qualité.

Les conséquences sur les projets

  • L’explosion du coût de la maintenance :
    Ajouter de la dette sans la prendre en compte risque de souvent complexifier le code de votre solution (duplication de code, de schéma, suppression de test (ou non écriture).
  • La non évolutivité du produit :
    L’ajout de la petite modification penser comme un simple héritage d’un mode de fonctionnement proche revient à modifier plusieurs fonctions utilisées jusqu’à lors telle des boites noires … Attention danger
  • La notion de risque à chaque déploiement :
    Les tests sont souvent les premiers à sauter … et dans ce cas, c’est uniquement lors de la mise en production que l’on risque de s’apercevoir que la boite noire est utilisée dans un autre module … sans aucun rapport fonctionnel …

null

Les conséquences sur les développeurs

  • Le découragement, la démotivation :
    C’est un élément rarement pris en compte mais travailler sur un logiciel instable est vite usant. Perdre beaucoup de son temps car le développement n’est pas ce qu’il aurait du être … ou que la modification simple doit juste être refaite à 10 endroits suite à des duplications de code … supprime vite toute envie de travailler sur un logiciel.
  • La perte de créativité :
    A perdre son temps dans la maintenance, le développeur va limiter l’impact de son travail au strict minimum, c »est à dire la correction de bogue sans avoir l’envie de prendre du recul sur son travail …
  • l’érosion des compétences :
    le pire qu’il peut arriver, à partir d’un certain temps, le développeur risque de se faire une raison … et de perpétuer les mauvaises pratiques qui sont en place dans la solution qu’il est entrain de maintenir.

Comment s’en prémunir?

L’importance de la conception initiale : Laisser le KISS (Keep It Simple and Stupid) pour le poc

L’entretien du code

  • La mise en place d’un PAQL, le plan d’assurance qualité est le document qui va permettre à un développeur de travailler dans un univers cohérent. Il ne s’agit pas de brider la créativité des développeurs, mais simplement de poser un ensemble de règle qui vont permettre à un nouveau développeur de savoir comment s’intégrer dans la structure.
  • Et de son application : c’est le pendant de toute documentation,, après sa rédaction, il faut se donner les capacités de s’assurer de son application … sinon, rapidement, le respect du PAQL ne sera qu’un lointain souvenir.
  • La mise en place d’une revue de code : l’objectif est de discuter du code produit et en aucune façon de le critiquer. Cette revue peut être le moment de mettre à jour le PAQL et de voir comment les stratégies de développement peuvent évoluer.

L’importance de l’automatisation

  • Pour toutes les tâches répétitives : export, admin, …
  • Pour les tests : unitaire ou fonctionnel
  • Pour la qualité du code

Et surtout : L’intégration de la dette dans le backlog des projets … car toute dette se rembourse … sinon d’elle même, elle causera la ruine du projet.

Quelques références

Livre :
– The Pragmatic Programmer,
– Code Legacy

Blog

C’est connu et reconnu mais avec la libéralisation des données, avoir un référentiel géographique prêt à l’emploi et actualisé est maintenant très rapide.

Le site de l’INSEE met les données dispositions l’ensemble de ces référentiels en libre accès sous forme de fichier dbf ou txt. Le travail d’actualisation des données est pré-mâché (puisqu’une liste de données d’actualisation est disponible).
Il n’y a donc plus aucune excuse à fournir un outil ne permettant pas de faire des statistiques fines sur le positionnement de ces utilisateurs.

Lien sur les référentiels : http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement.asp

Bonne intégration