Cette partie du site contient des résumés d’articles, des opinions, des astuces et des guides sur des sujets très divers :
industrialisation
développement - langages / outils
développement - pratiques & patterns
développement - astuces & frameworks
documentation
site et outils à connaître
La page ‘guide du développeur’ est présente plusieurs fois dans ce menu car c’est un élément central de tout projet.
La dette technique
Ces imperfections/violations se séparent en 3 groupes :
La dette se traite
J’en ai ras le bol de ce débat stérile sur les tests unitaires. Chacun a sa petite définition et, en fonction du contexte, utilise mal l’adjectif unitaire.
D’un côté, les tests sont unitaires quand le SUT (System Under Test) se limite à une classe voire une méthode. L’avantage de ces tests est qu’ils sont assez simples à rédiger car le code à tester se limite à celui de la classe (inutile de connaître le comportement de tous les autres composants du système qui peuvent être mis en jeu). Le problème est qu’il faut justement arriver à isoler le SUT et donc utiliser des techniques de bouchonnage (encore un framework que les collaborateurs du projet doivent apprendre à maîtriser).
De l’autre côté, les tests sont unitaires du moment qu’ils participent à la construction de l’application durant les travaux du développeur (j’aime les chefs de projet définissant un nombre de jours de “programmation et tests unitaires”). Dans cette définition, n’est pas pris en compte la granularité du SUT.
La troisième définition (la pire à mon sens) est le test basé sur JUnit.
Et si, pour se simplifier la vie, on parlait de tests de développement utilisant des TU, TI et TA ?
Et là, on me pose la question “Et les tests de non-régression ?”. Ma réponse est simple “Un test de non-régression a été un test de développement mais le développement est fini et le test est resté.”
Une console Hibernate est un environnement de développement (IDE) permettant de requêter en HQL (ou JPQL) une base de données.
L’intérêt de cette console est de tester une requête HQL sans avoir à déclencher du code Java dans l’application ou dans un test de développement.
Où se trouve la difficulté ? Un peu partout en fait :
Pour installer le plugin, démarrer Eclipse puis
Pour paramétrer la connexion à la base de données, depuis Eclipse
Pour rassembler la configuration dans un même endroit, il faut créer un projet Java dans Eclipse utilisant le même JDK que celui utilisé pour démarrer Eclipse.
La configuration de la console Hibernate demande la création de deux fichiers. Donc, dans ce projet, créer les deux fichiers :
Pour une BDD HSQL :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory name="sessionFactory">
<property name="hibernate.connection.driver_class">org.hsqldb.jdbcDriver</property>
<property name="hibernate.connection.password">login</property>
<property name="hibernate.connection.url">jdbc:hsqldb:file:C:/monCheminVersMaBaseDeDonnees/idDeMaBase;readonly=true;files_readonly=true;hsqldb.lock_file=false</property>
<property name="hibernate.connection.username">username</property>
<property name="hibernate.dialect">org.hibernate.dialect.HSQLDialect</property>
<mapping class="mon.package.MonEntite" />
<mapping class="mon.package.EtToutesMesAutresEntitesSansEnOublier" />
</session-factory>
</hibernate-configuration>Pour une BDD PostgreSQL :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory name="sessionFactory">
<property name="hibernate.connection.driver_class">org.postgresql.Driver</property>
<property name="hibernate.connection.password">pwd</property>
<property name="hibernate.connection.url">jdbc:postgresql://localhost:5432/mybdd</property>
<property name="hibernate.connection.username">login</property>
<property name="hibernate.dialect">org.hibernate.dialect.PostgreSQL82Dialect</property>
<mapping class="mon.package.MonEntite" />
<mapping class="mon.package.EtToutesMesAutresEntitesSansEnOublier" />
</session-factory>
</hibernate-configuration>Toujours dans ce projet, il faut ajouter les répertoires des entités :
Pour paramétrer la console Hibernate, il reste maintenant à
Après un petit clic sur la flèche à coté de votre configuration pour l’étendre, puis un clic sur Session Factory, vous devriez voir toutes vos classes persistantes.
Il est maintenant possible d’ouvrir un HQL Editor depuis un clic droit sur la configuration.
A partir du même endroit, il est possible de créer un schéma de votre mapping.
A une lontaine époque, la librairie guava-retrying était pratique pour définir des méthodes à réessayer en cas d’échec. Mais ce projet n’est plus maintenu.
Documentation : ici
SpringFramework fournit, depuis 2011, une librairie pour faire ça.
En voici la documentation : ici
En voici le projet : ici
Et, enfin, voici un article Baldung : ici.
La relecture de code est le travail de tout développeur juste avant de commiter son travail. Tous les outils de gestion de version permettent d’afficher le contenu du commit (git diff par exemple).
Une relecture permet de s’assurer
La revue de code est un processus outillé qui permet de systématiser une relecture de code par un tiers entre la fin du développement et l’intégration du dit code dans les sources de l’application.
Le processus peut être le suivant :
Attention, ce processus n’intègre pas le build de la branche, le déploiement du(es) livrable(s) généré(s) et les tests à réaliser pour valider le développement réalisé.
L’audit de code est un processus consistant à faire une relecture de code de tout le code de la branche principale. Ce processus n’est pas lié à un développement précis. Mais il peut être judicieux d’en réaliser un avant ou après un évènement précis (réversibilité de TMA, montée de version majeure d’un framework, …).
Cette pratique est tout à fait compatible avec les deux autres pratiques précédentes.
Attention, on parle ici de la qualité du code. La conception, les librairies/framework utilisés, … sont une autre affaire !!
Quelques soient les pratiques du projet (revue ou audit ou les deux), l’élément central et primordial est l’échange entre le développeur et le relecteur. Cet échange est le seul garant du bon fonctionnement de ces pratiques !!
Sans lui :
Certaines règles de développement sont aisément vérifiables (avec une petite expression régulière par exemple). Pourquoi ne pas utiliser un outil pour contrôler le code ? Il existe quantité d’outil de qualimétrie pour tous les langages. Ils ne remplacent pas la relecture humaine mais ils peuvent la simplifier en réduisant le nombre de règles et de points d’attention à contrôler.
En plus des contrôles de qualité automatiques, les actions automatiques sur le poste du développeur peuvent simplifier les relectures de code. Tous les IDE proposent de formatter le code, réorganiser les imports, … à chaque sauvegarde de fichier.
Pour mettre en oeuvre ces bonnes idées en poussant l’interaction un cran plus loin, il faudrait que le relecteur soit à côté du développeur pour réfléchir avec lui. Le relecteur aurait alors la possibilité de faire des remarques de conception aussi. C’est du pair programming !
GitHub:Pages est une fonctionnalité très utile de GitHub permettant d’héberger un site WEB en le déposant, tout simplement, dans un dépôt Git.
Hugo est un outil de génération de site WEB à partir de template et de Markdown.
Réunis, ces deux outils permettent de réaliser un site très simplement. Les usages sont nombreux. Mais le premier qui me vient est la documentation d’un projet : installation du poste, règles de conception/développement/test, pratiques du projet, … bref, un guide du développeur.
Les objectifs de cette page sont :
Hugo est un exécutable. Il faut donc le télécharger (depuis la page officielle) et le déposer dans un répertoire.
Attention, cet exécutable est dépendant de l’OS. Donc, pour construire le site sur Windows et sur Unix, il faut déposer les deux exécutables.
La première étape est donc de
Pour créer un site avec le thème LEARN (celui utilisé par ce site), exécuter les commandes suivantes (en adaptant le numéro de version si vous souhaitez le conserver dans le nom de fichier) :
hugo-0.140.1 new site monProjet
cd monProjet
git init
git submodule add https://github.com/McShelby/hugo-theme-relearn.git themes/hugo-theme-relearn
echo "theme = 'hugo-theme-relearn'" >> hugo.toml
mv ../hugo-0.140.1 ./
hugo-0.140.1 serverLe site disponible en local n’affiche qu’une page d’accueil vide et aucun contenu.
Le fichier hugo.toml peut être très vide ou très riche selon les besoins. A mon avis, sont obligatoires les informations suivantes :
# L'URL de base du site
baseURL = 'https://mon.serveur.de.doc/'
# Le nom du thème
theme = 'hugo-theme-relearn'
# La langue du site
languageCode = "fr-fr"
# Le titre du site
title = "Mon super site"De plus, chaque thème apporte des fonctionnalités. Voici la documentation du thème relearn
Par exemple, il est utile/possible de :
[params]
# Thème bleu par défaut mais autres thèmes disponibles
themeVariant = ['blue', 'relearn-light', 'relearn-dark']
# Désactiver le lien 'Home' dans le menu
disableLandingPageButton = true
# Définir l'auteur
[params.author]
email = 'talbotgui@gmail.com'
name = 'Guillaume TALBOT'
# Activer l'impression
[outputs]
home = ['html', 'print']
page = ['html', 'print']
section = ['html', 'print']Pour créer une page dans Hugo, il suffit de créer une arboresence dans le répertoire ./content.
Chaque répertoire doit contenir un fichier index.md dont le contenu commence par :
---
title: Titre de ma page
description: La description de ma page
weight: 101
---
## Voici le premier chapitre de ma pageHugo est un outil de génération et pas un outil de build.
Pour ne pas avoir à retenir les paramètres de ligne de commande à utiliser pour démarrer un serveur local ou générer l’application, il est préférable de stocker les scripts quelque part. Comme un outil de build (Maven ou NPM) est toujours utile, autant en utiliser un. Donc il faut créer un package.json minimal :
{
"name": "monProjet",
"version": "1.0",
"scripts": {
"start": "hugo-0.140.1 serve --bind 0.0.0.0 ",
"build": "hugo-0.140.1.exe"
},
"dependencies": {
}
}Pour démarrer le serveur, il suffit donc d’exécuter la commande npm run start.
Pour générer le site, il suffit donc d’exécuter la commande npm run build.
La plus simple des solutions de publication dans Gitbug-Pages est de créer un répertoire ./docs dans la branche principale du dépôt avec le contenu du site.
Or ce répertoire est utilisé, par défaut, par Hugo, pour stocker les pages HTML générés par le serveur local. Il est donc préférable de séparer ce répertoire de génération temporaire (hugo serve) du répertoire de génération réel (hugo).
De plus, la génération ajoute ou modifie les fichiers du répertoire ./docs mais ne supprime rien. Donc il faut que le répertoire soit vidé avant de faire générer les pages HTML à Hugo.
Donc le package.json doit être enrichi :
{
"name": "monProjet",
"version": "1.0",
"scripts": {
"start": "hugo-0.140.1 serve --bind 0.0.0.0 -d docsServe",
"build": "rm -rf ./docs/* && hugo-0.140.1.exe"
},
"dependencies": {
}
}Le plus simple est toujours de partir d’une base de travail simple. Pour cela, sont disponibles plusieurs base :
L’idée d’Hugo est de générer un site WEB statique avec une jolie mise en forme sans se prendre la tête avec la mise en forme.
Donc le contenu du site est codé en Markdown et Hugo génère les pages WEB.
L’avantage d’un site statique est qu’il est extrêmement performant. Cette solution est utilisée en production pour générer des pages WEB dont la fréquence de modification des contenus est faible (1 à 2 fois par jour).
Le site se démarre en double-cliquant sur “/bin/startServer.cmd”. Le site est alors disponible sur l’adresse http://localhost:1313.
Toute modification d’une page existante déclenche automatiquement son rafraîchissement dans le navigateur. Mais l’ajout d’une nouvelle page n’est pas pris en compte à chaud. Il faut couper le serveur et le redémarrer.
Les premières lignes de chaque page (les fichiers “.MD” du répertoire “docs”) sont des propriétés :
Un site avec Hugo utilisant “prev” et “next” contient donc beaucoup de lien. Il faut les vérifier. Pour le faire automatiquement et rapidement, il existe des outils comme “Broken Link Checker” outil de check des liens …
Ce pattern est dédié à la création d’objets de données utilisés dans des tests codés.
Ce pattern se base sur le pattern Factory. Il propose la création d’une classe dont la responsabilité est de créer des objets. La particularité de ce pattern est que les données créées sont dédiés aux tests.
Extraire le code de création de ces objets améliore la lisibilité des tests (à condition que le nom des méthodes de l’ObjectMother soit explicite). De plus, le fait d’utiliser systématiquement un jeu de données particulier permet de créer des données “familières”. Par exemple : Jean est un nouvel utilisateur, Arnaud est un utilisateur avec des droits d’administration, … A l’usage, ces persona (ou leurs pendants quel que soit le type d’objets manipulés : facture, usine, paie, compteur, …) finissent pas être connus de tous les développeurs. Ceci facilite la conception, le développement et la mise au point des tests.
Sources :
Exemples :
Ce pattern ne doit pas dérivé en anti-pattern “God Class”. Un ObjectMother ne doit pas devenir un composant trop gros ni dépendant de trop d’autres composants. Pour cela, il suffit de créer un ObjectMother par groupe de données (par exemple : SecuriteObjectMother, FacturationObjectMother, …). Et pour limiter le volume de code d’un ObjectMother, il suffit de respecter quelques règles :
Le Guide Du Développeur est l’espace de partage d’une équipe. Il contient toutes les informations utiles aux membres de l’équipe.
Chaque question posée par un collaborateur doit donner lieu à un nouveau paragraphe dans le GDD.
Il est inutile d’imposer un guide du développeur. Il faut le proposer et le faire adopter. C’est un outil pour l’équipe construit par l’équipe. Si personne ne le consulte avant de se mettre en quête d’une réponse (sur Internet ou au près d’un leader), alors il est inutile.
La première astuce est à destination des Lead (les membres de l’équipe qui ont tout dans la tête). Dès qu’un collaborateur vient vous poser une question, demandez-lui s’il a consulté le GDD. Si ce n’est pas le cas, qu’il retourne à son poste pour vérifier si la réponse n’est pas dans le GDD (même si vous savez que ce n’est pas le cas). Il faut que cela devienne un réflexe pour toute l’équipe. Et quand il reviendra vous poser la question et qu’il aura obtenu sa réponse, dîtes lui d’ajouter un paragraphe dans le GDD !!
Bien souvent, à ce moment-là, le collaborateur vous dit qu’il n’a pas le temps. Pour beaucoup de gens, toutes les tâches sont prioritaires à la documentation (même le café). Mais il est vrai qu’on n’a pas toujours le temps. Pas de soucis, il vous suffit d’un tableau blanc (ou d’un paperBoard). A chaque réponse obtenue, le collaborateur inscrit son prénom ainsi que les mots clefs de sa question et de sa réponse. Charge à lui de remplir le GDD dans un délai raisonnable puis de venir effacer (ou barrer) son nom.
Valoriser les contributeurs est aussi une bonne idée. Bien souvent, le dernier arrivé sur le projet est le principal contributeur. Il est aussi celui qui doit s’approprier le GDD. Un petit mail avec le meilleur contributeur du mois peut aider à faire adopter le GDD.
Question outil, un fichier MS Word sur un serveur FTP est une solution à proscrire car l’édition à plusieurs est impossible et la gestion des versions (avec un cartouche, …) est lourde. Un document partagé dans une bonne GED (Gestion Electronique de Documents) est une solution. Mais le plus simple reste un WIKI ou un site statique généré (comme le présent site avec Hugo). Les fonctions nécessaires sont :
Enfin, il n’existe aucun modèle de GDD. Chaque GDD est unique car les préoccupations, les questions et les réponses changent d’un projet à un autre (technologies différentes, clients différents, organisations différentes, équipes différentes). Il est préférable de démarrer avec une simple page faisant office de foire aux questions. Quand la page devient indigeste, il suffit de regrouper les questions par thème puis de les extraire dans des pages différentes. Ainsi le GDD émergera petit à petit.
Ceci n’est pas un menu de GDD mais juste une liste de sujets à traiter sur la plus part des projets ! Votre GDD, vos questions, votre sommaire !!!
référence documentaire
exigences
test
conception
développement
industrialisation
environnements
Lorsqu’un développeur code une nouvelle méthode, il doit savoir s’il fait confiance au code qui fera appel à cette méthode. Ou pas.
Une méthode peut valider les valeurs des paramètres d’entrée. Ce n’est pas une mauvaise chose en soit. Bien au contraire dans le cas de la validation des données lues dans un fichier envoyé par une application tierce. Même s’il existe un contrat définissant le format des données échangées, personne n’a envie d’intégrer des données de mauvaise qualité dans son système. Mais une question se pose : “doit-on utiliser la programmation défensive partout ?”. L’ajout de code vérifiant chaque paramètre de chaque méthode de chaque composant du système coûte du temps de développement (du code applicatif et des tests associés). De plus chaque ligne de code ajoute potentiellement un bug dans l’application. Et surtout la maintenabilité d’une application décroit avec l’augmentation du volume de code.
Mais il ne faut pas faire l’amalgame entre la programmation défensive et toutes les validations de données. Par exemple, la validation des données d’un formulaire saisies par un être humain est réalisée par une méthode dont c’est l’objectif. Dans ce cas, ce n’est pas de la programmation défensive. Mais, si le service métier appelé après la validation du formulaire vérifie lui aussi une donnée, là, ce sera de la programmation défensive.
Le choix entre programmation défensive et confiance absolue n’est pas du seul ressort du développeur. C’est un choix fait par l’équipe qui prend en compte le type de composant, le type de données, les contraintes techniques, … Cela doit donner lieu à un chapitre dans le guide du développeur.
Références :
Eclipse est un IDE, un environnement de développement intégré. A ce titre, il propose un éditeur de texte et des centaines de fonctionnalités autour. Basé sur un système de plugin, il est très extensible et très personnalisable.
Eclipse n’est pas le seul IDE disponible sur le marché. NetBeans, IntelliJ sont d’autres solutions. Mais je ne fournirais pas de comparatif car je n’ai que très peu utilisé NetBeans et jamais utilisé IntelliJ. C’est une bêtise (je le sais) car il est toujours intéressant de découvrir un nouvel outil pour voir s’il n’est pas meilleur sur certains points.
Mais quel que soit l’outil, une fois choisi, encore faut-il savoir s’en servir !
Si vous utilisez un IDE à la place de MS WordPad, il doit y avoir une raison !
(Ces illustrations ne sont pas le fruit de mon imagination mais viennent de mes observations durant les formations Java que j’ai dispensées en 2016 et 2017 auprès de jeunes développeurs)
A plusieurs occasions, cette question m’a été posée “Comment apprendre à utiliser pleinement Eclipse ?”.
Ma première réponse était de prendre 30 à 45 minutes pour parcourir les nombreux formulaires de paramétrage d’Eclipse pour découvrir toutes les fonctions que l’outil propose :
Oui, en effet, il existe un très grand nombre de formulaires de paramétrage. Non, vous n’utiliserez certainement jamais toutes les fonctionnalités de l’outil mais il faut en connaître un minimum.
Dernièrement (en mai 2017), un collègue m’a fait découvrir MouseFeed. Ce plugin d’Eclipse, au clic sur un bouton ou un menu contextuel, affiche quelques instants le raccourci clavier
Le minimum du minimum :
La première à configurer : le formateur de code car chaque client/projet a ses contraintes. Et le formatage ne doit pas être fait à la main !!!!!!!
La plus belle des fonctionnalités natives d’Eclipse se nomme “Save Actions”. Son but : à chaque sauvegarde d’une classe Java, il exécute un certain nombre d’action telle que :
Le plugin JBoss Tools contient les Hibernate Tools. Ce plugin permet de configurer un éditeur de requête HQL lié à une base de données et une configuration JPA (ou Hibernate) et permet l’exécution et le débogage de requêtes. (cf. billet décrivant l’usage de ce plugin)
L’intégration continue a pour objectif de valider que le code actuellement présent dans le repository de source est valide.
La fréquence de la validation et même la définition de cette validation sont très variables d’un projet à un autre :
L’erreur est humaine. Un développeur peut, par inadvertance et très rarement (bien entendu), pousser sur le repository du code invalide (qui ne compile pas ou qui casse des tests).
A cet instant-là, le projet n’est plus en mesure de livrer la solution. Ce qui est très gênant pour les projets en MCO dont le délai de livraison d’un correctif n’est que de quelques heures. Et surtout les autres développeurs de l’équipe ne peuvent plus récupérer les modifications poussées sur le repository.
Il faut donc corriger cette situation au plus vite. Mais encore faut-il détecter le problème. L’Intégration Continue est là pour ça !!
Si l’IC est capable d’exécuter des tests d’intégration voire des tests de bout en bout, elle est donc capable de déployer la solution sur un environnement. Pourquoi ne pas utiliser ce script/outil pour mettre à disposition des testeurs un bouton déclenchant un déploiement de la dernière version du code valide sur l’environnement de test de leur choix ?
Si l’IC peut déclencher n’importe quel script/outil, pourquoi ne pas automatiser les tâches récurrentes et pénibles comme le déplacement des livrables sur le serveur FTP du client ou l’extraction de la liste des bugs corrigés dans une version de la solution ou extraire la liste des commits ou même générer un bon de livraison ?
Bon, arrivé à ce point, qu’a-t-on :
Mais les analystes fonctionnels, les développeurs et les testeurs ont des interactions plus importantes que ça !
Et pourtant, le référentiel des exigences existe certainement (HP ALM par exemple), le référentiel des tests existe aussi (encore HP ALM par exemple) et l’outil de revu/relecture de code est installé. Il est certainement possible de lier tout ce petit monde.
Une fois tous les membres de l’équipe outillés, il est possible de décrire le processus de production de l’équipe par un tuyau dans lequel entre une (ou un petit groupe d’) exigence(s) qui enchaîneront une série d’étapes jusqu’à être terminées.
Ce processus dépend totalement de l’équipe mais commence toujours avec une exigence (ou un petit paquet). Donc la première étape est toujours la description de cette (ces) exigence(s). Peuvent suivre, la conception détaillée, le développement, la qualification interne, la recette client, le déploiement en pré-production puis celui en production.
Certaines équipes vont y ajouter de la relecture de code ou des revues de conception ou arrêter leur pipeline à la livraison de leur client (s’ils ne gèrent pas ni la recette ni la production).
Et enfin, chaque exigence ne donnant pas lieu à une mise en production, s’ajouteront des étapes conditionnées par une promotion manuelle : une action manuelle qui autorisera une instance du pipeline à avancer.
Voici un exemple de Pipeline très simple et très singulier : le pipeline de mon projet personnel ‘Mariage’
La Qualimétrie est la mesure de la qualité d’un projet.
Or, qualité veut tout et rien dire. Donc, ici, je vais me limiter à la qualité du code.
Mais pour évaluer le code d’un projet, encore faut-il qu’il existe des règles de conception/développement sur le projet. Sans règle, il ne peut y avoir de qualité.
Et oubliez l’expression “les standards de qualité” !!! Vous en voulez des standards ? On prend les règles de développement de SUN ? Ou celles d’Eclipse ? Ou les règles de nommage de la convention JavaBean ? Ou celles du client (s’il en a défini et qu’elles ne sont pas obsolètes) ?
Donc, par pitié, que chaque projet définisse ses règles ! En s’appuyant sur des éléments existants bien entendu et sans redécouvrir la roue !
A partir de là, on peut commencer à mesurer la qualité du code.
“La qualité ne sert à rien.” Si vous le pensez, quittez ce site !
Vous continuez à lire. Tant mieux. Désolé de paraître dur mais il n’est pas acceptable d’ignorer la qualité d’un projet. Elle peut ne pas être prioritaire. Mais ça se paiera tôt ou tard.
Pourquoi ? Car un code moche est un code compliqué à faire évoluer !
Les développeurs prendront des raccourcis et feront du code moche car le code est déjà moche et que tout le monde le sait et s’en moque. Et du moche dans du moche, au milieu du moche, … donnera un code incompréhensible, incohérent et très difficile à maintenir.
Ce jour-là, apparaîtront des bugs en pagaille et les corrections prendront de plus en plus de temps.
Les règles de conception/développement portent sur beaucoup d’aspects du code. Donc la qualimétrie aussi :
L’outil le plus connu est SonarQube.
Ce n’est pas à proprement parlé un outil de qualimétrie. C’est un portail de restitution et agrégation des violations détectées par d’autres outils comme Checkstyle, FindBugs, PMD, CPD, Clover, Cobertura, … De plus, SonarQube permet d’administrer le paramétrage de ces analyseurs et d’exécuter les analyses.
C’est donc un outil très complet et indispensable !
SonarQube propose une plateforme en ligne, gratuite et publique pour les projets Open Source.
Que votre projet démarre tout juste, ou que vous ayez déjà des milliers de lignes de code, il est toujours temps de commencer à mesurer la qualité.
Le premier objectif de la mesure est de faire un point. Est-ce une catastrophe ? Ou pas ? Attention, il faut que le paramétrage des outils d’analyse corresponde à vos règles !! Si vous prenez le paramétrage par défaut de SUN sur votre projet sans l’adapter à votre contexte, vous obtiendrez des milliers de violations.
Vous avez votre première mesure ? Très bien ! Première chose à faire, que la dette soit petite ou grande, ne pas la dégrader ! Surveiller les violations et, à chaque nouveau problème détecté, trouvez le développeur, apprenez/rappelez lui les règles du projet et faites-lui corriger sa coquille.
Une fois toute hémorragie contenue, on peut s’attaquer à réduire les violations. Il existe plusieurs stratégies et deux d’entre elles me semblent pertinentes à mener en parallèle :
La mesure de la qualité doit être une aide. Pas un frein !
SonarQube analyse le code présent sur le serveur hébergeant les sources.
Mais, le mieux serait qu’un outil prévienne le développeur dès qu’il code une bêtise !
La réponse : SonarLint ! Cet outil (sous forme de plugin dans les IDE) se connecte à SonarQube, télécharge les règles de validation et vérifie le code directement dans l’environnement du développeur.
Avec cet outil, si un développeur crée encore des violations, c’est qu’il se moque de son équipe. Là, très chères collègues, je vous laisse lui expliquer votre point de vue entre gens courtois et polis (dans la mesure du possible ;) ).
Quelques notes sur les incontournables choses à connaître en JS.
Au sommaire :
Astuce :
function toto(a = 1, b = 2) { return a * b; }
une belle explication ici
Un JS ne doit pas être déclaré dans le head mais à la fin du body (source 1, source2).
Au pire, si le JS ne dépend d’aucun autre, il peut être chargé avec ASYNC. Mais attention aux dépendances entre scripts d’une même page (source).
He oui, ça existe. Mais c’est pénalisant en performance. Donc à utiliser avec modération.
try {
throw {"name":"monException", "message":"momMessage"};
} catch (e) {
}solution 1 : la fonction
function MaClasse(args){
this.prop = args;
this.maMethode = function() {
alert(this.prop);
};
}
var monInstance = new MaClasse(true, "bonjour");
monInstance.maMethode();solution 2 : la description
let monInstance = {
prop: args,
maMethode: function() {
alert(this.prop);
}
}solution 3 : le prototype
function MaClasse(args){ ... }
MaClasse.prototype.prop = ...;
MaClasse.prototype.maMethode = function() { alert(this.prop); };
var monInstance = new MaClasse(true, "bonjour");
monInstance.maMethode();solution 4 : l’héritage
// Type Rectangle avec une largeur et une longueur
function Rectangle(largeur, longueur) { this.largeur = largeur; this.longueur = longueur; };
Rectangle.prototype.largeur = 0;
Rectangle.prototype.longueur = 0;
Rectangle.prototype.calculSurface = function() { return this.largeur * this.longueur; };
// Type Carre avec une largeur (la longueur et la largeur sont égales)
function Carre(largeur) { Rectangle.call(this, largeur, largeur); };
Carre.prototype = Object.create(Rectangle.prototype);
Carre.prototype.constructor = Carre;
// Test du Rectangle
let monRec = new Rectangle(3, 10);
let surfaceMonRec = monRec.calculSurface(); //30
// Test du Carre
let monCarre = new Carre(5);
let surfaceMonCarre = monCarre.calculSurface(); //25
let monInstance = {
get prop() {
return ...;
}
set prop(value) {
...
}
}Si le getter n’existe pas, la valeur retournée est undefined
var MonModule = ( function() {
// privé
const compteur = 18;
function maMethodePrivee() {
...
}
// public
let module = {};
module.methodePublique = function() {
...
}
return module;
})();Créer une machine de type small chez Amazon EC2 avec l’OS Ubuntu xx.xx de votre choix.
Dans le groupe de sécurité, ouvrir les ports HTTP HTTPS SSH (ouverts à tous)
Se connecter en SSH et exécuter
sudo apt-get update
sudo apt-get -y upgradesudo apt-get -y install default-jdk
@see https://www.jenkins.io/doc/book/installing/linux/#weekly-release
wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
sudo sh -c 'echo deb https://pkg.jenkins.io/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get -y install jenkinsPour définir le rootContext de Jenkins, exécuter sudo vi /etc/default/jenkins et modifier la dernière ligne pour ajouter “–prefix=$PREFIX” (attention au double tirets)
Pour prendre en compte la modification, redémarrer Jenkins
sudo apt-get -y install apache2
sudo a2enmod proxy proxy_http
sudo a2enmod headers
sudo a2enmod sslCréer le fichier sudo vi /etc/apache2/sites-available/monHttp.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName me.guillaumetalbot.com
ServerAlias ci
</VirtualHost>sudo a2ensite monHttp
sudo /etc/init.d/apache2 restart@see https://certbot.eff.org/instructions et sélectionner Apache et le bon OS
Penser à configurer le nom de domaine pour pointer sur la machine auprès du DNS avant
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot --apacheModifier le fichier sudo vi /etc/apache2/conf-available/security.conf et changer les valeurs :
Modifier le fichier sudo vi /etc/apache2/sites-available/monHttp-le-ssl.conf et y ajouter
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
ProxyRequests Off
ProxyVia Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPreserveHost on
ProxyPass /jenkins http://localhost:8080/jenkins nocanon
ProxyPassReverse /jenkins http://locahost:8080/jenkins
ProxyPassReverse /jenkins http://me.guillaumetalbot.com/jenkins
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
AllowEncodedSlashes NoDecode
<IfModule mod_headers.c>
Header set X-Content-Type-Options nosniff
Header set X-Permitted-Cross-Domain-Policies "none"
# pour ne pas bloquer Jenkins
# Header set Content-Security-Policy "child-src 'none'; object-src 'none'"
# Header set X-Frame-Options DENY
Header set X-XSS-Protection "1; mode=block;"
Header set Strict-Transport-Security "max-age=300; includeSubDomains; preload; always;"
Header set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
</IfModule>Puis exécuter :
sudo /etc/init.d/apache2 restart
sudo rm /var/www/html/index.htmlCréer le fichier sudo vi /var/www/html/index.html avec le contenu suivant :
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="refresh" content="3; url=https://talbotgui.github.io" />
</head>
<body>
Redirection en cours...
</body>
</html>Aller à l’adresse https://…../jenkins et suivre les instructions
sudo apt-get install postfix
me.guillaumetalbot.com
sudo vi /etc/postfix/main.cf
myhostname = me.guillaumetalbot.com
sudo service postfix restartsudo mkdir /usr/share/m2repo
sudo chmod a+rw /usr/share/m2repo
sudo apt-get -y install mavenModifier le fichier sudo vi /usr/share/maven/conf/settings.xml pour définir le repo local
Vérifier la dernière version disponible du setup et remplacer les YY (version 14 en aout 2021).
curl -sL https://deb.nodesource.com/setup_YY.x | sudo -E bash -
sudo apt-get install -y nodejsPremier accès et paramétrage de base
Installer les plugins nécessaires
Déclarer les outils
Déclarer les clefs
Si votre serveur héberge aussi des applications déployées automatiquement depuis votre Jenkins
sudo mkdir /var/www/html/xxx
sudo chmod a+rw /var/www/html/xxxLa machine va manquer de RAM. Pour ajouter une partition de SWAP (dans un fichier) (http://tecadmin.net/add-swap-partition-on-ec2-linux-instance/)
sudo dd if=/dev/zero of=/var/myswap bs=1M count=2048
sudo mkswap /var/myswap
sudo swapon /var/myswap
sudo chmod 0644 /var/myswapParmis les outils utiles dans les scripts SHELL, il faut bien souvent installer
sudo apt-get -y install zip/var/lib/jenkins/.npm/_logs/
Ressources :
Installation :
wrapper.java.command=C:/Program Files/Java/jdk1.8.0_151/bin/javaarchiva install puis archiva startPour rechercher les répertoires prenant de la place : sudo du -cha --max-depth=1 / | grep -E "[0-9]M|[0-9]G"
Et un petit script permettant de faire le ménage régulièrement :
apt clean all
rm /var/log/**/*.gz
rm /var/log/journal/*/*-00000*.journal
rm -rf /var/lib/jenkins/workspace/*
rm -rf /var/lib/jenkins/.sonar/*
rm -rf /var/lib/jenkins/.m2/*
rm -rf /var/lib/jenkins/.npm/*Installation :
export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)"
echo "deb http://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo apt-get update && sudo apt-get install google-cloud-sdkConnexion :
gcloud auth activate-service-account --key-file=LE_FICHIER_JSONgcloud init et renseigner toutes les informations
Pour cloner un dépot : git clone https://xxxxxxxxx
Pour ajouter une modification : git add rep1/monFichier.xxx
Pour ajouter toutes les modifications : git add -A
Pour annuler les ADD : git reset
Pour annuler le ADD d’un fichier : git reset rep1/monFichier.xxx
Pour annuler les modifications d’un fichier : git checkout rep1/monFichier.xxx
Pour commiter : git commit -m "mon message"
Pour commiter les fichiers modifiés (pas les ajouts) sans faire de ADD : git commit -am "mon message"
Pour pousser ces commits sur le repository : git push
Pour récupérer toutes les modifications réalisées depuis le dernier PULL : git pullou git pull --rebasesi des commits ont été réalisés depuis le dernier PULL
En cas de problème durant un rebase, la commande git rebase --abortannule tout.
Pour voir le statut du dépot local : git status
Pour voir les modifications d’un fichier : git diff rep1/monFichier.xxx
Pour voir toutes les modifications : git diff
Pour obtenir les logs : git logou git log --pretty=oneline
Pour afficher les informations du repository distant : git remote show origin
Pour sauvegarder dans un espace temporaire des modifications (sans les commiter) : git stash
Pour lister les sauvegardes : git stash list
Pour récupérer la sauvegarde la plus récente : git stash pop
Pour annuler tous les commits locaux : git reset HEAD^
Pour modifier l’historique sur les 5 derniers commits (à ne faire que si aucun push n’a été fait depuis) : git rebase --interactive HEAD~5
Dans l’éditeur qui s’ouvre, remplacer les pick par :
Pour pousser sur le repository distant un rebase qui modifie l’historique déjà poussé /!\ attention quand on travaille en équipe /!\ : git push --force
Pour modifier l’auteur des commits d’un dépôt, il est possible d’utiliser la commande suivante :
git filter-branch -f --env-filter "
GIT_AUTHOR_NAME='Guillaume TALBOT'
GIT_AUTHOR_EMAIL='talbotgui@gmail.com'
GIT_COMMITTER_NAME='Guillaume TALBOT'
GIT_COMMITTER_EMAIL='talbotgui@gmail.com'
" HEADMais, ensuite, il ne faut pas oublier de modifier l’auteur dans le dépôt (pour ne pas recommencer la même erreur) :
git config user.name "Guillaume TALBOT"
git config user.email "talbotgui@gmail.com"Pour lister les branches locales : git branch
Pour passer d’une branche à l’autre : git checkout maBranche
Pour créer et passer à une autre branche : git checkout -b maBranche
Pour supprimer une branche : git branch -d maBranche
Pour afficher les différences entre deux branches : git dif maBranche...lAutreBranche
Pour fusionner simplement une branche vers la branche courante : git merge monAutreBranche
Pour pousser dans le master les modifications d’une autre branche en un seul commit :
git checkout master
git merge --no-ff maBrancheFeaturePour pousser sur le dépot distant toutes les branches : git push --all
Pour lier une branche locale à une branche distante existante (après avoir fait un push -all créant une branche par exemple) : git branch --set-upstream-to origin/maBranche
[diff]
tool = pdiff
[difftool "pdiff"]
cmd="wscript.exe \"c:\\Program Files\\TortoiseSVN\\Diff-Scripts\\diff-ppt.js\" \"`pwd`/$REMOTE\" \"$LOCAL\""git difftool -Y -t pdiff maPresentation.pptx[alias]
diffP = difftool -Y -t pdiffgit diffP maPresentation.pptxgit config --global http.proxy http://mon.proxy:8080
git config --global https.proxy https://mon.proxy:8080git config --global --unset http.proxy
git config --global --unset https.proxygit config --global alias.setProxy '!sh $GIT_EXEC_PATH/../../../setGitConfigProxy.sh'
git config --global alias.unsetProxy '!sh $GIT_EXEC_PATH/../../../unsetGitConfigProxy.sh'# setGitConfigProxy.sh
# Proxy pour GIT
git config --global --unset http.proxy
git config --global --unset https.proxy
# Proxy pour NPM
npm config rm proxy
npm config rm https-proxy
# Proxy pour MAVEN
sed "s/active>true/active>false/" -i C:/outils/apache-maven-3.5.2/conf/settings.xml```# unsetGitConfigProxy.sh
# Proxy pour GIT
git config --global http.proxy https://mon.proxy:8080
git config --global https.proxy https://mon.proxy:8080
# Proxy pour NPM
npm config set proxy https://mon.proxy:8080
npm config set https-proxy https://mon.proxy:8080
# Proxy pour MAVEN
sed "s/active>false/active>true/" -i C:/outils/apache-maven-3.5.2/conf/settings.xmlsources :
sources :
Pour simplifier l’usage de ce modèle, GitFlow propose de nouvelles commandes qui font les merges, les créations de branche et les cheryPick :
ssh git flow initssh git flow feature start maFonctionnalité et ssh git flow feature finish maFonctionnalitéssh git flow release start 0.1.0 et ssh git flow release finish 0.1.0Pour traiter le problème “multi-version” du modèle, gitFlow propose une fonction ssh git flow support. Mais la gestion des cherryPick des bugFixes est à faire manuellement !
ssh git flow hotfix start est impossible (au risque de livrer la 1.1 en production directement).source :
sources de réflexion :
Les featureBranch sont bien pratiques. Associées aux PullRequest qui permettent une relecture du code, on a un bon process de relecture obligatoire. Mais comment s’assurer à tout moment que ma branche featureBranch_xx n’est pas incompatible avec la featureBranch_zzz d’un collègue ?
Dans tous les cas, avant de vouloir faire quelque chose d’intelligent avec les données collectées, il faut déjà avoir une idée des éléments à collecter :
Classiquement, 3 types d’outils sont mis en oeuvre :
D’autres outils sont aussi disponibles :
bin/elasticsearch-plugin install x-pack bin/kibana-plugin install x-packcluster.routing.allocation.disk.threshold_enabled: falsecluster.routing.allocation.disk.watermark.high: 99 bin/elasticsearch bin/kibanaLes configurations suivantes ont été testées pour une version particulière des outils :
Un fichier de logs tout bête dans donneesSources\mesLogs.log
coucou madame
bonjour monsieur
coucou monsieur
bonjour madame
hello mademoiselle
hello mademoiselleUne configuration FileBeat dans configFileBeat\mesLogs_filebeat.yml :
filebeat.prospectors:
- input_type: log
# Déclaration des fichiers sources
paths:
- D:/Projets/Enedis/protoElk/donneesSources/mesLogs.log
# Pour ajouter une information dans tous les logs
fields:
maSource: monFileBeat
output.logstash:
hosts: ["localhost:5043"]Une configuration LogStash dans configLogStash\meslogs_pipeline.conf :
input {
# Pour prendre les éléments envoyés par Beats
beats { port => "5043" }
}
filter {
# Petit filtre simpliste
grok {
match => { "message" => '%{WORD:formulePolitesse} %{WORD:personneCiblee}' }
}
}
output {
# Pour logger le contenu des messages uniquement dans la console de LogStash
#stdout { codec => plain { charset => "ISO-8859-1" } }
# Pour logger les messages avec leurs metadata
stdout { codec => rubydebug }
# Pour envoyer les logs à ElasticSearch
# @See https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html
elasticsearch {
hosts => [ "localhost:9200" ]
# Le nom de l'index doit être en minuscule pour elasticsearch
index => "meslogs"
template => "D:/Projets/Enedis/protoElk/configLogStash/meslogs_template.json"
template_name => "meslogs"
template_overwrite => true
}
}Un template LogStash dans configLogStash\meslogs_template.json :
{
"template": "meslogs",
"settings": {
"index.refresh_interval": "5s"
},
"mappings": {
"_default_": {
"dynamic_templates": [
{
"message_field": {
"mapping": {
"index": "analyzed",
"omit_norms": true,
"type": "string"
},
"match_mapping_type": "string",
"match": "message"
}
},
{
"string_fields": {
"mapping": {
"index": "analyzed",
"omit_norms": true,
"type": "string",
"fields": {
"raw": {
"index": "not_analyzed",
"ignore_above": 256,
"type": "string"
}
}
},
"match_mapping_type": "string",
"match": "*"
}
}
],
"properties": {
"geoip": {
"dynamic": true,
"properties": {
"location": {
"type": "geo_point"
}
},
"type": "object"
},
"@version": {
"index": "not_analyzed",
"type": "string"
}
},
"_all": {
"enabled": true
}
}
}
}Et des commandes pour démarrer les outils et nettoyer les répertoires pour répéter le test à l’infini :
rmdir filebeat-5.6.0-windows-x86_64\data /Q /S
rmdir logstash-5.6.0\data /Q /S
rmdir elasticsearch-5.6.0\data /Q /S
rmdir kibana-5.6.0-windows-x86\data /Q /S1-elasticsearch.cmd : elasticsearch-5.6.0\bin\elasticsearch
2-kibana.cmd : kibana-5.6.0-windows-x86\bin\kibana
3-startLogStash.cmd :
title Logstash
logstash-5.6.0\bin\logstash -f configLogStash/mesLogs_pipeline.conf --config.reload.automatictitle FileBeats
filebeat-5.6.0-windows-x86_64\filebeat -e -c configFileBeat/mesLogs_filebeat.yml -d "publish"Une fois la première exécution réalisée sans erreur sur aucune console, sont disponibles :
On obtient ainsi le tableau de bord suivant (après quelques minutes de manipulation dans Kibana) :
Quand on développe à la maison et au bureau avec Git, rapidement, apparait le besoin de disposer de plusieurs clefs SSH pour s’authentifier auprès des serveurs.
Créer les clefs (en reprenant le chemin complet du fichier proposé !!) :
ssh-keygen -t rsa -C "premier@email.com" avec /c/Users/xxxx/.ssh/id_rsa_boulotssh-keygen -t rsa -C "second@email.com" avec /c/Users/xxxx/.ssh/id_rsa_persoCréer le fichier ~/.ssh/config avec
# Compte perso
Host github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_perso
# Compte boulot
Host qsd.mon.boulot
HostName qsd.mon.boulot
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_boulotPour déclarer les clefs :
ssh-add ~/.ssh/id_rsa_perso
ssh-add ~/.ssh/id_rsa_boulot
Pour démarrer l’agent SSH (ou s’assurer qu’il fonctionne)
eval `ssh-agent -s`
Supprimer le cache des clefs
ssh-add -D
Pour tester (si besoin, accepter la connexion en répondant ‘yes’) :
ssh -T git@github.com
ssh -T git@qsd.mon.boulot
ET NE PAS OUBLIER DE FAIRE DES CLONES EN UTILISANT LE PROTOCOLE SSH et non https !!!!
Exécuter les commandes :
sudo adduser new_user --disabled-passwordsudo su new_usercdmkdir .sshchmod 700 .sshtouch .ssh/authorized_keyschmod 600 .ssh/authorized_keysssh-keygen -f /home/ubuntu/xxx.pem -y >/home/new_user/.ssh/authorized_keysUn tout petit billet pour référencer l’article de Fowler sur ce sujet : https://martinfowler.com/articles/feature-toggles.html
Bonnes pratiques d’implémentation des toggles à retenir :
Festures.isFeatureActive("version-2.0")Festures.isEnvoiMailConfirmation() { return isFeatureActive("version-2.0"); }if. Si plusieurs sont nécessaires, il est préférable de faire des méthodes différentes voire des classes différentes.Cette procédure a été mise à jour en décembre 2024 lors de la recréation des instances de mes serveurs.
Depuis le portail EC2 d’Amazon,
sudo apt-get update
sudo apt-get -y upgradePour obtenir, à coup sûr, l’IP publique de la machine, exécuter la commande :
curl ifconfig.meDepuis votre fournisseur de DNS, créer l’entrée suivante :
Pour installer apache2, exécuter les commandes :
sudo apt-get -y install apache2
sudo a2enmod proxy proxy_http headers ssl rewrite
sudo systemctl restart apache2Pour vérifier que le service est démarré et le serveur accessible, ouvrir un navigateur avec l’adresse http://xxx.xxx.xxx.xxx avec xxx.xxx.xxx.xxx l’IP obtenue de la commande précédente.
Pour déclarer un premier vhost HTTP écoutant sur le port 80 (temporaire évidemment), créer le fichier sudo vi /etc/apache2/sites-available/vHostHttp.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName me.guillaumetalbot.com
ServerAlias ci
</VirtualHost>Pour activer le nouveau vhost et désactiver le vhost par défaut
sudo a2ensite vHostHttp
sudo a2dissite 000-default.conf
sudo a2disconf localized-error-pages.conf charset.conf serve-cgi-bin.conf
sudo systemctl reload apache2Pour limiter les informations fournies par le serveur dans les entêtes de réponse, modifier la configuration de sécurité via la commande
sudo vi /etc/apache2/conf-available/security.confPuis modifier (en commentant, décommantant ou modifiant les lignes) pour obtenir
sudo systemctl reload apache2** Il faut que la configuration DNS soit active et propagée pour installer CertBot. **
Pour tester la configuration DNS, tenter d’accéder au site http://me.guillaumetalbot.com et vérifier que la page par défaut d’Apache2 s’affiche.
Puis suivre les instructions du site https://certbot.eff.org/instructions en y sélectionnant Apache et le bon OS.
Si la procédure n’a pas changée, cela se résume aux commandes suivantes (à vérifier tout de même) :
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot --apachePour tester le bon fonctionnement du site en HTTPs, tenter d’accéder au site https://me.guillaumetalbot.com et vérifier que la page par défaut d’Apache2 s’affiche.
Pour désactiver l’accès HTTP, réaliser les actions :
sudo vi /etc/apache2/ports.conf pour en supprimer la ligne Listen 80sudo a2dissite vHostHttp
sudo systemctl reload apache2** Une bonne procédure de référence est disponible sur le site ubuntu-fr.org*
Pour installer des utilitaires précieux, exécuter la commande :
sudo apt-get install unzipPour installer MySQL, exécuter la commande :
sudo apt install mysql-serverPour paramétrer MySQL, exécuter les commandes :
sudo mysql
> CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> CREATE USER 'wordpressuser'@'localhost' IDENTIFIED BY 'un_mot_de_passe_a_choisir_et_stocker_dans_keepass';
> GRANT ALL ON wordpress.* TO 'wordpressuser'@'localhost';
> FLUSH PRIVILEGES;
> EXIT;Pour installer PHP, exécuter la commande :
sudo apt install php php-mysql php-curl php-gd php-intl php-json php-mbstring php-xml php-zip libapache2-mod-phpPour paramétrer Apache2,
sudo vi /etc/apache2/sites-enabled/vHostHttp-le-ssl.conf pour y ajouter, sous ServerAlias, les lignes suivantes : DocumentRoot /var/www/wordpress
<Directory /var/www/wordpress>
AllowOverride all
Require all granted
</Directory>sudo systemctl reload apache2Pour installer WordPress, exécuter les commandes :
cd
pwd
wget https://fr.wordpress.org/wordpress-latest-fr_FR.zip
sudo unzip wordpress-latest-fr_FR.zip -d /var/www
sudo chown www-data:www-data /var/www/wordpress -R
sudo chmod -R -wx,u+rwX,g+rX,o+rX /var/www/wordpressPour paramétrer WordPress, accéder à la page https://me.guillaumetalbot.com/ et laisser WordPress guider via son interface de paramétrage.
Une fois l’interface d’administration affichée, voici quelques étapes incontournables :
La (grande?) majorité des développeurs utilisent aujourd’hui GIT pour sauvegarder et partager leurs développements. Tout y est stocké. Et, parfois, même les mots de passe (clefs, secrets, …) !!
La solution optimale serait de ne pas les insérer dans le dépôt GIT. Mais cela signifie ne plus les partager avec le reste de l’équipe.
Une autre solution consiste à chiffrer ces informations avant de les partager sur le repository commun sans oublier de les déchiffrer sur le repository local.
Une solution (parmis d’autre) est Transcrypt.
Transcrypt est un outil permettant d’initialiser le chiffrement de certains fichiers dans un dépôt Git.
Une fois le dépôt paramétré, Transcrypt n’est plus nécessaire et peut être désinstallé.
La liste des fichiers à chiffrer avant (et déchiffrer après) chaque commit est paramétrée dans le fichier .gitattributes
La toute première chose à faire est d’identifier les fichiers contenant des secrets dans l’historique GIT. Pour cela, l’outil GitLeaks est bien utile.
xxx/gitleaks_xxxx/gitleaks.exe git --report-path gitleaks-report.json^.*"(File|Secret)".*$sed -i "s#LE_SECRET_ISSU_DE_GITLEAK#xxxxxxxx#g" "LE_NOM_DE_FICHIER_ISSU_DE_GITLEAK"La seconde étape est de faire disparaître de l’historique GIT le(s) secret(s). Pour cela, il suffit
==>xxxxxxxxjava -jar /d/xxxx/bfg.jar --replace-text /d/xxx/password.txt "/d/cheminVersDepot"
cd /d/cheminVersDepot
git reflog expire --expire=now --all && git gc --prune=now --aggressivegit clone https://github.com/elasticdog/transcrypt.gittranscrypt --helptranscryptgit add le/chemin/du/fichier.extensionle/chemin/du/fichier.extension filter=crypt diff=crypt merge=cryptVoici un exemple pour un fichier environment d’Angular :
projects/coupeDesMaisons/src/environments/environment.prod.ts filter=crypt diff=crypt merge=crypt
Cette page contient des notes prises durant la refonte d’un site WordPress d’une association dont je fais partie.
R1/ Si l’information est effémère ou liée à un évènement ponctuel, l’information doit faire l’objet d’un ARTICLE. Sinon ce sera une PAGE.
R2/ Si une image doit être publiée, il faut :
R3/ Si toutes les images d’un répertoire doivent être insérées dans une unique galerie, le bloc FileBird Galery est à utiliser de préférence car il permet d’afficher toutes les images d’un répertoire
R4/ Si seules quelques images d’un répertoire doivent être insérées, le bloc Galerie doit être utilisé.
R5/ Si une unique image doit être insérée et qu’un texte doit y être associée, le bloc Média & texte doit être utilisé.
R5/ Avant toute publication, doivent être vérifiés les éléments suivants :
R6/ Tous les liens pointant vers un autre site doivent s’ouvrir dans un nouvel onglet.
Ra1/ Le titre d’un article commence par la date de l’évènement ou, à défaut, par le date de publication.
Ra2/ Si l’information est une copie d’un article de presse, l’article de notre site doit :
Source : https://www.leberry.fr/baugy-18800/travaux-urbanisme/une-premiere-tranche-des-travaux-de-renovation-de-l-eglise-de-baugy-achevee_14562797/Ra3/ Avant de publier un article,
Rp1/ A la création de la page, dans la barre latérale droite, dans l’onglet Page, il est préférable de, tout de suite, saisir la page parente dans le paramètre Parent.
Rp2/ Toute page parente dont introduire les pages filles. Pour créer une liste de lien vers les pages filles, insérer un bloc Code court avec le contenu [child_pages list="true" orderby="title" order="ASC"]
Pour insérer une image avec du texte dessus (utile en début d’une page), il faut utiliser un bloc bannière.
Pour mettre en forme des contenus les uns à côté des autres, existe le bloc colonnes (attention, pour une image et un texte, utiliser le bloc Média & texte).
Pour mettre en place des onglets, il suffit
[tabby title="Titre du premier onglet"][tabby title="Titre du second onglet"][tabbyending]Pour permettre de cliquer sur une image pour qu’elle s’affiche en grand, il suffit de
Si, après avoir enregistrer des modifications, ces dernières ne sont pas visibles, il suffit de cliquer sur le bouton *Purger le cache" présent tout en haut des pages d’administration de WordPress (hors de l’éditeur de page ou d’article).
Quelques trucs à lire