Environnement de Dev PHP avec VS Code

Nous allons aujourd’hui créer un environnement de Dev PHP avec debugger.

Pré requis

Il faudra installer :

Configuration Wnmp

Vous avez ici le choix d’utiliser la version de PHP préinstallée, ou d’utiliser vontre version de PHP. Si vous installez une version supplémentatio

Installation PHP (Optionnel)

Télécharger une version VS16 x64 Non Thread Safe au format Zip et dézipper la dans le dossier Wnmp / php-bins dans un dossier avec le nom de votre version 8.x.y

Installation XDebug (Optionnel)

Ouvrir la page https://localhost

Copier coller le contenu dans l’outil de configuration XDebug :

https://xdebug.org/wizard

Suivez les steps proposés en téléchargeant le fichier dll et en le déposant dans le dossier mod du dossier de votre version de PHP.

PHP.ini

Dans la section « Dynamic Extensions », Activer le module zend :

zend_extension=xdebug

Dans la section « xdebug » (Fin du fichier),

Commenter toute la configuration XDebug (Les lignes par défaut concernent l’ancienne version 2 de XDebug)

Ajouter à la place les 2 configs de XDebug 3:

[xdebug]
;xdebug.default_enable=1
;xdebug.remote_enable=1
;xdebug.remote_handler=dbgp
;xdebug.remote_host=localhost
;xdebug.remote_port=9000
;xdebug.extended_info=1
;xdebug.remote_autostart=1

xdebug.mode=debug
xdebug.start_with_request=yes

Votre Projet

Avec GitHub Desktop récupérer les fichiers de votre dépôt Git et déposez les dans le dossier www du serveur Web

Configuration VSCode

  1. Ouvrer le dossier OGSpy ou tout autre projet que vous avez téléchargé.
  2. Si vous ne l’avez pas encore, installez le Module PHP Extension Pack

Configuration du Debugger PHP

Sélectionner le Debugger dans le menu vertical et choisissez le type de debugger à executer.

Dans notre cas ce sera : « PHP: Listen for XDebug »

Cela va générer un fichier launch.json avec les paramètres suivant :

{
    // Utilisez IntelliSense pour en savoir plus sur les attributs possibles.
    // Pointez pour afficher la description des attributs existants.

    "version": "0.2.0",
    "configurations": [
        
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003
        }
    ]
}

Testez votre debugger

Lancez votre Debugger depuis un fichier avec F5

Posez un point d’arrêt et parcourez votre site web pour l’atteindre.

Si tout va bien vous devrier vous arrêter sur la ligne avec le Debugger et toutes les informations de vos variables :

Je n’ai plus qu’à vous souhaiter une bonne session de Debug 🙂

Autres liens

PHP Programming with Visual Studio Code

Pourquoi répéter les Tests ?

On dit souvent qu’un bon testeur a une certaine chance de tomber dans les Bugs que personne ne voit où trouve. Cela fait parfois la différence entre le bon et le mauvais testeur (ou chasseur 🙂 ).

Voici un article qui décrit un peu la méthodologie du Monkey Test qui en fait est plutôt une recherche du bon chemin en répétant les scénarios.

Reasons to Repeat Tests – Satisfice, Inc.

 

Microsoft Azure : Modifier la configuration d’une Application Web avec Azure CLI

Pour modifier avec Azure CLI la configuration des journaux d’une application

Il est possible de le faire avec la commande : az webapp log config

#/bin/bash

# Variables
myResourceGroup='my-ressource-group'
appname='appname-wa'

# Enable all logging options for the Web App
az webapp log config --name $appName --resource-group $myResourceGroup --application-logging 'azureblobstorage' --detailed-error-messages true --failed-request-tracing true --web-server-logging 'filesystem'

Pour vérifier vos modifications :

az webapp log show --name 'appname-prod-wa' --resource-group 'my-ressource-group'

Pour de multiples applications :

#/bin/bash

# Variables
myResourceGroup='my-ressource-group'

APP_NAMES=('appname1-prod-wa' 'appname2-prod-wa' 'appname3-prod-wa')

for appName in "${APP_NAMES[@]}"
do
        # Enable all logging options for the Web App
        az webapp log config --name $appName --resource-group $myResourceGroup --application-logging 'azureblobstorage' --detailed-error-messages true --failed-request-tracing true --web-server-logging 'filesystem'
done

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