SonarLint, codez connecté avec SonarQube

sonarlint-black-256

Lors d'un projet, la qualité est aujourd'hui devenue une des priorités. Concernant celle du code source, de nombreux outils existent pour nous guider. Aujourd'hui nous allons aborder le sujet du plugin SonarLint en lien avec SonarQube.

Mais avant d'aborder ce qu'est SonarLint par rapport à SonarQube et en quoi celui-ci peut nous aider lors des phases d'amélioration du niveau de qualité du code de nos projets, voici un bref rappel sur SonarQube.

Vérifier les emails avec www.mail-tester.com pour éviter d’être considéré comme spammeur

keep-calm-and-stop-spamming

Sur un site web, il est assez fréquent que l'on soit amené à envoyer des mails suite à diverses actions. Dans nos développements, il nous incombe de faire l'habillage de ces mails, et ensuite de les tester sur différents clients de messagerie. Mais voilà, certains mails peuvent être considérés comme spams, je vous propose donc dans cet article de découvrir l'outil www.mail-tester.com qui vous permet de voir si vos mails sont considérés comme spams mais aussi d'améliorer vos envois.

Audit PHP : sécurité et bonnes pratiques

PHP_LOGO

Créé en 1994, PHP (Hypertext Preprocessor) est un langage de programmation très répandu sur Internet.

C'est un langage puissant, facile à aborder et permissif.
De ce fait, il est fréquent de retrouver des codes PHP qui ne respectent pas les normes élémentaires de sécurité et de bonnes pratiques.

Cet article est un aide-mémoire qui dresse une liste (non exhaustive) des points à contrôler dans le cadre d'une revue de code.

Devoxx France 2013 – Implémenter la qualité sur un projet Java

A l'occasion de Devoxx France 2013, j'ai assisté à la conférence intitulée « Implémenter la qualité sur un projet Java » présentée par Vincent Massol (profil github), contributeur du projet XWiki.

Vincent nous parle des bonnes pratiques dans la gestion d'un projet Java, en prenant comme modèle son expérience sur XWiki.

Stabilité de l'API

Il faut faire attention aux utilisateurs et même aux développeurs du framework.

Clirr est un outil qui casse la construction d'un projet s'il y a un changement dans une API. La comparaison peut se faire au niveau binaire ou au niveau du code source. Lorsque l'on a intentionnellement changé l'API, il faut documenter le changement pour qu'il soit ignoré par l'outil, qui signalera cela dans son rapport.

Voici quelques pratiques mise en place sur le projet XWiki pour la gestion de ses API :

  • Création d'un package 'internal' : Les classes/méthodes/attributs présents dans ce paquetage peuvent être visibles au sens Java mais le développeur ne doit pas les utiliser. S'il le fait quand même, il prend le risque que son code ne compile plus ou ne s'execute plus lors d'une nouvelle version de la librairie. Il ne faut pas oublier d'exclure ce paquetage de la javadoc et de l'analyse Clirr.
  • Gestion de la dépréciation dans l'API
    • Version courante : Utiliser l'annotation @Deprecated dans le code et le tag @deprecated dans la javadoc (voir aussi la documentation Oracle sur le sujet).
    • Future version : Déplacer le code déprécié vers des artefacts dont le nom se termine par "-legacy". Les classes dépréciées sont déplacées. Les méthodes dépréciées sont déplacées en utilisant AspectJ.
  • Gestion des nouvelles API : Celles-ci sont potentiellement instables. Il faut utiliser l'annotation @Unstable et préciser une limite de validité.

Attention à l'ajout de méthodes dans une interface ! Mais cela ne sera plus un problème à partir du jdk8, qui permet d'ajouter une implémentation par défaut sur une interface.

L'enfer des jars

Il arrive parfois que certaines classes soient dupliquées à l'exécution (même classes dans 2 jars présents dans le classpath). Lorsque les classes sont différentes, cela constitue un véritable problème qui peut être résolu en utilisant les plugins maven suivants :

  • duplicate-finder pour détecter les classes dupliquées.
  • enforcer pour forcer l'application de certaines règles (version du jdk, version des artefacts ...).

Tests de couverture

La librairie JaCoCo mesure la couverture des tests et, si la valeur est en dessous d'un certain seuil, la construction du projet échoue.

Attention : Certains tests peuvent être non déterministes et le taux de couverture peut varier d'une exécution à l'autre, sans modification du code. C'est notamment le cas lorsqu'on utilise la classe ConcurrentHashMap avec plusieurs threads. Vincent propose de rajouter un paramètre nommé threshold (voir la discussion sur le projet github de JaCoCo) pour définir une marge de tolérance par rapport au seuil.

Faux positif/négatif

Un faux positif correspond à un test qui passe alors qu'il aurait dû échouer. A l'opposé, un faux négatif correspond à un test qui ne passe pas alors qu'il aurait dû passer. Exemple de faux négatif : crash, lenteur du système. Voici quelques plugins Jenkins qui peuvent servir dans ces situations :

  • Groovy Postbuild : Ce plugin permet de contrôler le résultat d'un build et éventuellement rajouter un badge sur le sommaire du build et/ou l'historique des builds. Dans notre cas, il peut rechercher du texte dans les logs afin de vérifier qu'un test passe réellement.
  • Email-ext : Ce plugin permet d'étendre la fonctionnalité de notification par email. On pourrait, par exemple, annuler l'envoi d'email lorsque le système est lent (mais l'interface web de jenkins continuerait de montrer le problème).
  • Scriptler : Ce plugin permet de centraliser les scripts Groovy d'une instance Jenkins. On peut aussi jouer un script sur tous les jobs jenkins ou sur tous les noeuds/esclaves. Remarque : le plugin gère 2 sites de partage de scripts : jenkins-scripts ou scriptlerweb.

Bug tracking

Avec le temps, les courbes de bugs ouverts et bugs corrigés tendent à diverger. Pour atténuer cette divergence, le jeudi a été déclaré jour de correction des bugs par les contributeurs du projet XWiki. Afin de diminuer rapidement les bugs ouverts, ceux-ci commencent par fermer les bugs corrigés et les bugs en doublon. Ensuite, ils corrigent les bugs faciles et requalifient certains bugs en évolution. Pour voir le résultat, consulter le tableau de bord du projet XWiki.

Pour terminer, Vincent souligne qu'il faut paramétrer les outils afin qu'ils fassent échouer un build lorsqu'une mesure est mauvaise. Sans cela (paramétrage pour émettre un simple avertissement), on va avoir tendance à ignorer le message, puis laisser le problème empirer et finalement ne jamais le corriger.

Intégration à Eclipse d’outils d’assurance qualité pour PHP

L’écosystème PHP regorge d’outils permettant d’augmenter sensiblement la qualité du code produit par les équipes de développement. On peut noter les travaux avancés de Sebastian Bergmann et plus généralement des contributeurs de la PHP Quality Assurance Toolchain qui fournissent à la communauté un outillage précieux.

Ce billet explore les outils les plus couramment utilisés lors d’une analyse du code PHP. Souvent plébiscités dans un cycle d’intégration continue ; ils sont rarement intégrés à l’environnement de développement : lancement manuel via un terminal, pre-hook sur un serveur de versionning. L’objectif est ici d’augmenter l’interactivité de ces outils avec les développeurs et de leur permettre d’aborder des méthodologies comme le Test Driven Development (TDD) plus sereinement.

Design pattern : Un Singleton PHP

Le design pattern Singleton vous permet, en tant que développeur, de vous assurer qu'une classe n'est instanciée qu'une seule fois durant toute l'exécution de votre script. Ce cas de figure se présente notamment lorsqu'il s'agit de stocker une connexion à une base de données ou de charger un fichier de configuration. Voici un gabarit simple et commenté qui vous permettra de maitriser le concept... pour ceux qui ne le savent pas déjà !