Le Bon et le mauvais Bug

Intro

Le mot Bug est souvent mal pris par les développeurs car certains le ressentent comme une attaque sur la qualité de leur travail. Pourtant un humain ne peut pas penser à tous les cas d’utilisation et la diplomatie et le dialogue sont alors nécessaires pour que les deux parties soient heureuses à la fin 🙂

La Petite Histoire

Le Bug provient du mot anglais « Bug » : la petite bête qu’on ne veut pas avoir chez soi. Il y souvent une sur utilisation de ce mot et aussi des mauvaises utilisations. Par moment, le mot est utilisé pour des changements que l’on veut avoir dans son application, il peut être utilisé aussi quand l’ensemble ne fonctionne pas alors que l’on serait plus sur un problème d’infrastructure. L’utilisation du mot Bug est souvent faite sur un large domaine alors que c’est un terme qui devrait être très ciblé et précis en terme de contexte.

Création du Bug : Un seul Objectif !

Le seul objectif d’un bug est qu’il soit corrigé à la fin 🙂

Pour faciliter le travail du développeur, le plus important est que le Bug soit facile à reproduire grâce à la description fournie dans la fiche de Bug.

En général le Bug contient les données suivantes :

  • Titre : La description du Problème
  • Les étapes pour reproduire
  • Le résultat Observé
  • Le résultat attendu

Titre : Description du Problème

Le titre permet de comprendre en une ligne ce qui ne va pas. Il doit être concis et clair pour toutes les personnes amenées à lire le titre de bug.

Quelques Exemples :

Enregistrement impossible des paramètres utilisateurs

Affichage incorrect des planètes sur l’écran Espace Personnel -> Simulation

Etapes pour reproduire

Les différentes étapes doivent être indiquées pour reproduire le problème. Une vidéo sous forme de gif peut être aussi utilisée.

Exemple :

Si le problème n’est pas reproductible à chaque essai, il faudra le préciser : 1/10, 1/5 etc

Une fois les étapes écrites, il ne faut pas hésiter à vérifier que le problème est bien reproduit avec ce que l’on a écrit dans le Bug.

Il s’agit de la partie la plus importante pour le développeur. Si les étapes sont claires et précises, le développeur passera moins de 5min à reproduire. Sachant que le temps passé pour reproduire un problème représente environ 75% du travail de correction : on peut presque dire que le dicton suivant :

« Bug reproduit : Bug Corrigé ! »

Le résultat observé

Décrivez ici ce qui vous semble incorrect. Tout simplement 🙂

Le résultat attendu

Indiquez dans cette section le résultat que vous attendez. Si vous avez un doute, n’hésitez pas à proposer des idées.

Résultat

Si le développeur corrige le problème directement sans votre aide : c’est gagné !! Vous n’aurez qu’à attendre la prochaine publication pour voir le correctif 😉

Par contre s’il n’arrive pas à le corriger ou s’il manque d’information, il vous laissera un message sur le bug. Faites donc attention à vos mails et à vos notifications GitHub ou autres.

Ensemble vous arriverez à trouver la correction sans aucun doute et à faire profiter à toute la communauté le correctif qui probablement gênait plus de personnes qu’on ne le pense 🙂

Conclusion

Un Bug est parfois difficile à identifier que ce soit du côté de celui qui le signale ou du côté du développeur : il est donc important de travailler ensemble pour réussir à décider de l’avenir du Bug. Parfois il pourra être corrigé immédiatement, il pourra aussi être planifié pour une prochaine version ou bien complétement abandonné car il concernera une partie de code qui sera bientôt supprimée.

Dans tous les cas la fiche de Bug ou le ticket aide le produit à devenir meilleur. Car même si aucune action directe n’est requise il amène la réflexion de ce qu’il faudrait améliorer et dans l’innovation toutes les idées sont à prendre 🙂

Transifex : La plateforme de traductions

Présentation

Transifex est une solution pour gérer les traductions de vos applications ou site Web. Gratuit pour les particuliers ou les projets OpenSource il est néanmoins payant pour les entreprises.

L’outil permet une intégration avec Github, ce qui permet d’automatiser la mise à jour des ressources facilement.

Description d’un Projet

Un projet se défini comme par son type de fichiers (Ici on prendra pour exemple un projet PHP) et ses ressources à traduire.

Résumé du Projet Autoupdate

La page Overview présente les statistiques du projet avec les langues traduites et leur avancement.

Utilisation

Pour commencer à traduire, il faut sélectionner une langue puis un fichier de ressources.

Choix de la ressource à traduire
Détails de la la ressource

Lors de l’affichage des détails de la ressource, il est possbile de lancer l’interface de traduction via le bouton translate.

Ecran de traduction

L’écran de traduction est très bien fait :

  • Sur la partie gauche, vous avez l’état des traductions de la ressource avec la possibilité de sélectionner la langue de destination
  • Sur la partie droite, l’édition de la ressource avec les suggestions qui proposent des mots traduits dans les autres fichiers

Intégration GitHub

L’intégration Github permet de recupérer les fichiers directement sur votre dépôt. Lors d’une mise à jour faite par l’équipe de développement, la chaine de caractère modifiée sera remise à zéro dans transifex.

Pour remonter les informations à votre dépôt Github, un petit script sera nécessaire pour préciser la source et la destination des fichiers traduits :

Script permettant de configurer l’emplacement des fichiers dans votre dépot Git

Enfin vous pourrez sélectionner à quel moment repousser vos fichiers vers Git. Soit à la fin de la revue ou uniquement dès que tout le fichier est traduit : c’est au choix.

Pour ce qui est de la forme, Transifex peut pousser les modifications sous forme de commit ou de Pull request.

Vous pourrez ensuite vérifier sur votre dépôt Git que toutes les modifications ont bien été prises en comptes.

Conclusion

Merci d’avoir lu l’ensemble de l’article. je n’ai pas détaillé tous les écrans car il s’agissait dans mon esprit d’une présentation de ce qu’on faisait à l’OGSteam. N’hésitez pas à commenter l’article si vous avez des questions !

Scanner ses Documents avec NAPS2

NAPS2 est un outil permettant de numériser ses documents facilement. Il gère le multipage, peut rogner et retoucher facilement les couleurs ou la luminosité.

Enfin il permet d’enregister le tout dans un fichier PDF (Possibilité de réordonner les pages) ou une multidude de fichiers images.

Une fonction que je n’ai pas encore essayé : l’OCR pour insérer en texte les fichiers scanné dans un fichier PDF. Ce qui rends le contenu indedxable pour la recherche.

Gratuit et OpenSource c’est un super outil pour gérer ses documents 🙂

https://www.naps2.com/

Ventoy : Le multi Boot pour les iso

Un bel outil vu sur le net pour avoir une clé usb avec tous ces OS prêt à installer dessus : Ventoy

Après avoir installé l’outil sur votre clé USB ( Formattage nécessaire)

Vous pouvez tous simplement déposer vos Iso sur la clé USB 🙂

Au boot sur la clé USB vous aurez alors de choix de démarrer sur l’ISO de votre choix 🙂

Profitez en bien !

www.ventoy.net

Utilisez NPM et Gulp pour éviter les CDN

L’idée est ici de garder votre application complètement indépendante, et d’éviter mes CDN sur votre page Web.

Nous allons utiliser le couple npm gulp pour ne prendre dans notre package que le nécessaire.

Présentations

NPM est le gestionnaire de package le plus connu de nodeJS

Gulp est une librairie très utilisée pour personaliser le déploiement et parfois préparer le package de livraison.

Création du Projet

Nous allons utiliser dans notre application les librairies JQuery et Loglevel. Pour ne pas les utiliser nous allons les récupérer avec NPM

Préparez un fichier package.json à la racine du projet comme suit : (Nous allons expliquer les scripts embarqués juste après)

{
  "name": "mon-extension",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "node-clean": "npm prune && npm install",
    "build": "gulp build",
    "test": "echo 'no test'"
  },
  "keywords": [],
  "author": "DarkNoon",
  "license": "GPL-2.0",
  "devDependencies": {
    "gulp": "^4.0.2"
  },
  "dependencies": {
    "jquery": "^3.5.1",
    "loglevel": "^1.6.8"
  }
}

Puis lancez npm install pour installer les packages dans le dossier node_modules.

npm install

Vous obtenez :

Gulp est mon ami

Nous allons créer une simple tâche de copie de fichiers avec Gulp. Nous faisons ça pour éviter de déployer le dossier node_moules qui est souvent bien trop rempli de dépendances que l’on n’utilise pas.

Voici le script :

const {  src, dest } = require('gulp');

function update_jquery() {
    return src(["node_modules/jquery/dist/jquery.min.js"]).pipe(dest("contribs"));
}

function update_loglevel() {
    return src(["node_modules/loglevel/dist/loglevel.min.js"]).pipe(dest("contribs"));
}

function build(cb) {
    update_jquery();
    update_loglevel();
    cb();
}
exports.build = build;

Le script va simplement copier les fichers nécessaires dans notre dossier contribs aveec la command build.

Ce qui nous permettra par la suite de produire un package sans Node Modules et de rester léger 🙂

J’espère que ce petit tutoriel vous a plu : vous pourrez le trouvez sur GitHub à cet endroit : Github

Créer ou Extraire une Archive avec tar

Pour la gestion des archives sous Linux le format le plus courant est le tar.gz à l’opposé du format Zip sous Windows.

Nous allons voir ensemble le détail de 2 commandes simples :

  • Compression d’un Dossier/ Fichier
tar czvf <archive>.tar.gz <dossier source>

Détails des paramètres :

c comme create : Défini l'action que va effectuer Tar
z comme gzip : Défini le format de compression
v comme verbose : Affiche les fichiers extraits dans la console
f comme Archive : Type de fichier
  • Décompression d’un Dossier/Fichier
tar xzvf <archive>.tar.gz

Détails des nouveaux paramètres utilisés :

x comme extraire : Défini l'action que va effectuer Tar
  • Décompression d’un Dossier/Fichier dans un dossier cible
tar xzvf <archive>.tar.gz  -C /home/john/<folder>

L’option C permet de choisir à quel endroit le fichier sera extrait

Source : https://linux.die.net/man/1/tar