Jérémy DECOOL (@jdecool), Ingénieur Etudes et Développement à Lyon

Qu'est-ce qu'un « bon code » à l'ère de l'IA ?

Sat, 06 Jun 2026 00:00:00 +0200

La semaine dernière, je faisais référence au mantra “code is cheap”. Depuis, j’ai trouvé le projet “Agentic Engineering Patterns” de Simon Willison qui documente les patterns pratiques pour travailler et obtenir les meilleurs résultats possibles avec l’IA.

On y retrouve une section “Writing code is cheap now” avec toute fois une nuance que je partage: “Good code still has a cost”. Ce qu’il y explique a pour moi toujours était vrai même avant l’IA. Écrire du code est facile, mais écrire du bon code, ça l’est moins et c’est ce point qui représente un coût.

Pour lui, un “bon code” a les caractéristiques suivantes:

il fonctionne réellement: il fait ce qu’il est censé faire, sans bugs majeurs.
on sait qu’il fonctionne: il existe des preuves (tests, validation, vérifications) qui inspirent confiance.
il résout le bon problème: produire une solution techniquement correcte, mais inutile reste un échec.
il gère les erreurs proprement: pas seulement le scénario idéal, mais aussi les cas d’échec, avec des messages exploitables pour le futur debugging.
il reste simple et minimal: éviter la complexité inutile et l’“over-engineering”.
il est protégé par des tests: pour éviter les régressions quand le code évolue.
il est documenté: et la documentation doit rester synchronisée avec le comportement réel du système.
il reste évolutif: il ne doit pas compliquer inutilement les changements futurs, tout en évitant d’anticiper des besoins hypothétiques (principe YAGNI).
il respecte les qualités non fonctionnelles: sécurité, maintenabilité, observabilité, accessibilité, fiabilité, scalabilité, etc., selon le contexte du projet.

Je vous recommande vivement d’aller jeter un coup d’oeil au projet: https://simonwillison.net/guides/agentic-engineering-patterns/

Profilez vos tests PHPUnit avec OpenTelemetry

Mon, 01 Jun 2026 00:00:00 +0200

Un projet de développement informatique qui grossit, c’est une base de code qui grossit par la même occasion et la batterie de tests qui évolue en conséquence. On ajoute des tests semaine après semaine, les temps d’exécution s’allongent. Et puis, à un moment, la CI s’arrête net: Allowed memory size exhausted. Le premier réflexe est alors d’augmenter la mémoire allouée à PHP. Et ce cycle peut continuer un certain temps, jusqu’au moment où l’on atteint des seuils critiques.

Je l’ai rencontré dans plusieurs expériences professionnelles. Corriger des problèmes de mémoire est compliqué et l’outillage restreint. On est donc aveugle, on ne sait pas quels tests consomment de la mémoire, lesquels prennent du temps à s’exécuter. Monitorer une application en production est une bonne pratique, pourquoi n’en serait-il pas de même pour nos tests ?

Pour l’observabilité de nos applications de production, un standard est en train de s’imposer: OpenTelemetry. Pourquoi, alors, ne pas utiliser ce dernier pour également suivre ce qu’il se passe sur nos tests: produire des traces et des métriques que nous pourrions analyser ?

Il existe d’ailleurs une bibliothèque pour intégrer de l’observabilité dans nos tests PHPUnit avec OpenTelemetry: flow-php/phpunit-telemetry-bridge. Il s’agit d’une extension PHPUnit qui collecte la télémétrie de votre suite de tests et l’exporte vers n’importe quel backend compatible OTLP.

Pour l’installer, rien de plus simple:

composer require --dev flow-php/phpunit-telemetry-bridge

Il restera ensuite à ajouter la configuration nécessaire dans PHPUnit:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit>
    <!-- ... -->
    <extensions>
        <bootstrap class="Flow\Bridge\PHPUnit\Telemetry\TelemetryExtension">
            <parameter name="service_name" value="phpunit-opentelemetry"/>
            <parameter name="transport" value="curl"/>
            <parameter name="endpoint" value="http://localhost:4318"/>
            <parameter name="emit_traces" value="true"/>
            <parameter name="emit_metrics" value="true"/>
            <parameter name="emit_test_spans" value="true"/>
            <parameter name="emit_test_case_spans" value="true"/>
            <parameter name="curl_connect_timeout_ms" value="1000"/>
            <parameter name="curl_timeout_ms" value="2000"/>
        </bootstrap>
    </extensions>
</phpunit>

Une fois configuré, il ne reste plus qu’à lancer vos tests, les données de télémétrie seront automatiquement envoyées, vous permettant ensuite de les visualiser dans des tableaux de bord.

On y retrouvera chaque suite de tests avec le détail de chaque test: sa durée, son empreinte mémoire, son statut.

Quelques points d’attention néanmoins. Instrumenter chaque test a un coût. Cela ne sera pas forcément intéressant sur une petite suite de test. C’est surtout lorsque le projet commence à grossir que ce type de donnée a de la valeur et que vous souhaitez arrêter de naviguer à l’aveugle.

Et si vous désirez en savoir plus, n’hésitez pas à consulter la documentation de l’outil.

L'IA accélère l'écriture du code, pas sa criticité

Wed, 27 May 2026 00:00:00 +0200

L’une des phrases que j’entends le plus ces derniers temps est: « code is cheap », à savoir que le code ne coûte plus grand-chose à produire et qu’il n’a plus de valeur. Je ne suis que partiellement d’accord avec ça.

On fait également beaucoup l’analogie du prompt qui génère du code, tout comme le code est transformé en assembleur. Au final, c’est une nouvelle couche d’abstraction qui permet de se concentrer sur l’essentiel, ce que l’on souhaite « produire ».

Là où je ne suis pas tout à fait d’accord, c’est qu’un compilateur est déterministe. Le même code source produira toujours la même sortie. Ce n’est pas forcément le cas des prompts avec les LLMs. Ces derniers ne sont pas déterministes et, un même prompt peut générer des résultats différents d’une exécution à l’autre. Et cela change fondamentalement la donne.

Le code généré reste l’artefact final, la source de vérité, ce qui est exécuté, déployée et maintenu. Réduire le code à quelque chose qui n’a pas (ou plus) de valeur, c’est faire un raccourci un peu rapide. L’IA accélère son écriture, mais ne change pas la criticité de ce dernier.

La meilleure technologie, c'est celle que l'équipe maîtrise

Sat, 23 May 2026 00:00:00 +0200

Lorsque l’on doit résoudre un problème technique, il est tentant de chercher la solution la plus adaptée. Celle qui répond le mieux aux contraintes identifiées. Pourtant, il peut arriver que la meilleure technologie ne soit pas celle qui colle parfaitement au problème.

Choisir une technologie, c’est prendre en compte plusieurs facteurs tels que: les compétences de l’équipe, le temps disponible et la tolérance au risque du projet.

Quand les délais sont contraints, le choix doit l’être aussi. La meilleure technologie devient celle que l’équipe maîtrise. C’est celle avec laquelle on saura avancer rapidement, déboguer efficacement et qui ne nécessitera pas plusieurs semaines ou mois de montée en compétence.

Introduire une nouvelle technologie, c’est ajouter du risque: temps d’apprentissage, erreurs de jeunesse, mauvaises pratiques liées à la méconnaissance de l’outil. Pour que cela se passe dans de bonnes conditions, il faut du temps pour assimiler les nouveaux concepts, ou un périmètre réduit pour limiter la casse.

Et ce constat est également vrai à l’ère de l’IA. L’IA ne permet pas de compenser le manque de maîtrise ni le manque de connaissance. Sans expertise, impossible de guider, challenger ou valider ce qui est produit. C’est accumuler du code que personne ne comprend réellement.

Choisir une techno, ce n’est pas uniquement répondre à un problème technique. C’est prendre en compte l’équipe, son expérience et le contexte du projet. La technologie idéale sur le papier ne vaut rien si personne ne sait la dompter dans les temps impartis.

Utiliser PHP avec Airflow

Mon, 18 May 2026 00:00:00 +0200

Je travaille actuellement sur un projet orienté BI pour lequel des scripts d’analyse et de visualisation de données sont écrits en Python et sont orchestrés par Apache Airflow. Airflow est un outil Python, initialement conçu et pensé pour l’écosystème Python. Mais travaillant essentiellement en PHP, je me suis demandé s’il était possible d’y faire tourner des scripts PHP.

En parcourant la documentation d’Airflow, on peut se rendre compte que l’outil permet bien plus que d’exécuter des scripts Python. Si Python y est fortement intégré, en réalité, Airflow est capable d’exécuter n’importe quelle commande d’un terminal. Il est donc possible d’orchestrer tout type de script, et donc du PHP.

Les tâches (appelées DAG pour Directed Acyclic Graph) Airflow sont lancées au travers d’opérateur. Parmi ceux disponibles, l’opérateur BashOperator permet d’exécuter une commande dans un worker Airflow sur lequel serait présent PHP et le script à lancer.

Prenons par exemple le script PHP suivant:

<?php

echo "Hello from PHP script!\n";
echo "Execution time: " . date('Y-m-d H:i:s') . "\n";

La création d’un DAG passe par l’écriture du script Python (c’est le seul moment où ce denier est nécessaire). La mise en place de notre tâche PHP pourrait se faire ainsi:

from airflow import DAG
from airflow.providers.standard.operators.bash import BashOperator
from datetime import datetime

with DAG(
    dag_id="run_php_script",
    description="A DAG that runs a PHP script",
    schedule=None,
    start_date=datetime(2024, 1, 1),
    catchup=False,
    tags=["php"],
) as dag:

    run_php_script = BashOperator(
        task_id="run_php_script",
        bash_command="php /path/to/scripts/hello.php",
    )

Avec ce simple code Python, Airflow déclenche notre script PHP (qui lui peut être bien plus complexe). Les sorties standard et d’erreur sont automatiquement capturées dans les logs Airflow. On peut également bénéficier de toute la mécanique de retry, de monitoring et d’alerting Airflow.

Si vous désirez tester par vous même, vous trouverez tout le nécessaire dans ce dépôt pour démarrer un environnement Airflow avec tout le nécessaire.

L'outil n'est pas la compétence

Tue, 12 May 2026 00:00:00 +0200

L’IA a changé (comme pour beaucoup, je pense) ma manière de travailler. Pas seulement dans ma façon d’écrire du code, mais aussi dans les outils que j’utilise au quotidien.

Je passe aujourd’hui beaucoup plus de temps dans mon terminal et dans des éditeurs comme Zed ou VS Code. Les outils, tels que Claude Code, Codex ou Mistral Vibe ont modifié mes habitudes. L’IDE que j’utilisais de manière systématique est (presque) devenu un outil parmi d’autres.

J’ai toujours cherché à utiliser l’outil le plus adapté au contexte plus que l’outil qui m’est familier. Sur des sessions de code où l’IA fait l’essentiel du travail, inutile de sortir l’artillerie lourde, un éditeur léger suffit amplement. Par contre, pour des sessions de refactoring ou de debug, l’IDE reste imbattable.

Ne pas utiliser un IDE est souvent perçu négativement. Pourtant, parmi les meilleurs développeurs que j’ai côtoyés, certains n’utilisaient pas et n’utilisent toujours pas un IDE. Certains utilisent Zed, d’autres VS Code et même Vim.

Et alors ? Ce n’est pas l’outil qui façonne le développeur.

Faire des requêtes CTE avec Doctrine ORM en PHP

Sat, 09 May 2026 00:00:00 +0200

J’ai déjà évoqué sur ce blog que le développement “moderne” avec les ORM masque les fonctionnalités avancées des SGBD au point que dorénavant les développeurs ne maitrisent et ne connaissent guère plus que le classique SELECT ... FROM ... WHERE ....

Dans les mécanismes méconnus et qui pourtant, pourrait permettre de soulager certains traitements applicatifs, on retrouve les CTE (Common Table Expressions). Voyons comment les utiliser avec Doctrine ORM en PHP.

Commençons par expliquer ce qu’est une CTE. Il s’agit d’une sous-requête utilisable comme une table temporaire. C’est une technique utile pour décomposer des requêtes complexes, éviter la duplication de sous-sélections ou écrire des requêtes récursives.

En presque 20 ans d’expérience professionnelle, j’ai très rarement eu l’occasion d’en voir dans le code que je peux être amené à parcourir quotidiennement. Prenons par exemple, un blog où les articles sont rattachés à des catégories, ces dernières organisées sous forme arborescente sous la forme Category(id, label, parent_id). Je suis certain que, si l’on demande à un développeur de récupérer toutes les catégories parentes d’une catégorie précise, ce dernier fera le traitement en PHP avec un code ressemblant au suivant:

// src/Repository/CategoryRepository.php
class CategoryRepository extends ServiceEntityRepository
{
    // ...

    /**
     * @return list<Category>
     */
    function getCatagoriesWithParents(int $categoryId): array
    {
        $category = $this->categoryRepository->find($categoryId);

        $categories = [
            $category,
        ];

        while ($parent = $category->getParent()) {
            $categories[] = $parent;
        }

        return $categories;
    }
}

L’inconvénient majeur ici est qu’en interne, Doctrine va faire une requête à chaque tour de boucle. C’est ce que l’on appelle le problème N+1. Pour résoudre ce problème, via une requête SQL, il n’est pas possible de faire un simple SELECT ... FROM ... WHERE, c’est exactement dans ce cas qu’une CTE récursive est utile. Cette dernière peut être écrite de la manière suivante:

WITH RECURSIVE cte_category AS (
    -- point de départ
    SELECT id, label, parent_id, 0 AS depth
    FROM category
    WHERE id = :id

    UNION ALL

    -- récursivité
    SELECT c.id, c.label, c.parent_id, cp.depth + 1
    FROM category c
    INNER JOIN cte_category cp ON c.id = cp.parent_id
)
SELECT id, label, parent_id FROM cte_category
ORDER BY depth DESC

La requête commence par récupérer la catégorie identifiée par :id, puis se joint récursivement à elle-même en remontant via parent_id jusqu’à ce qu’il n’y ait plus de parent. La colonne depth permet ensuite de trier du plus ancien ancêtre jusqu’à la catégorie cible.

Le problème pour faire cette requête avec un ORM tel que Doctrine, c’est que ce dernier ne permet pas de gérer les CTE nativement au travers de son QueryBuilder ni même en DQL. Il est alors nécessaire de passer par une requête native où le résultat final sera mappé sur un objet.

// src/Repository/CategoryRepository.php
class CategoryRepository extends ServiceEntityRepository
{
    // ...

    public function findAllWithParents(int $categoryId)
    {
        $rsm = new ResultSetMappingBuilder($this->getEntityManager());
        $rsm->addRootEntityFromClassMetadata(Category::class, 'c');

        $sql = <<<SQL
            WITH RECURSIVE with_categories AS (
                SELECT id, label, parent_id, 0 AS depth
                FROM category
                WHERE id = :id

                UNION ALL

                SELECT c.id, c.label, c.parent_id, cp.depth + 1
                FROM category c
                INNER JOIN with_categories cp ON c.id = cp.parent_id
            )
            SELECT id, label, parent_id FROM with_categories
            ORDER BY depth DESC
        SQL;

        return $this->getEntityManager()
            ->createNativeQuery($sql, $rsm)
            ->setParameter('id', $categoryId)
            ->getResult();
    }
}

Dans le code précédent, le ResultSetMappingBuilder se charge de faire correspondre les colonnes retournées avec les propriétés de l’entité Category. On obtient alors en sortie une liste d’instances de Category ordonnés de la racine jusqu’à la catégorie demandée.

Avec ce type de requête, on peut faire énormément de choses, il est par exemple, possible de récupérer tous les articles appartenant à une catégorie enfant en réutilisant la requête précédente:

WITH RECURSIVE category_path AS (
    SELECT id, label, parent_id
    FROM category
    WHERE id = :id

    UNION ALL

    SELECT c.id, c.label, c.parent_id
    FROM category c
    INNER JOIN category_path cp ON c.id = cp.parent_id
)
SELECT a.id, a.title, a.category_id
FROM article a
INNER JOIN category_path cp ON a.category_id = cp.id
ORDER BY a.published_date DESC

En une seule requête, on récupère tous les articles liés à la catégorie cible ou à n’importe lequel de ses ancêtres. Sans CTE récursive, il faudrait soit faire plusieurs requêtes successives pour parcourir la hiérarchie une approche bien moins efficace. Un point d’attention néanmoins, étant donné que l’on exécute une requête SQL native, il faudra faire attention à la portabilité de cette dernière, les CTE pouvant ne pas être disponible sur toutes les bases de données supportées par Doctrine.

De plus, l’utilisation du ResultSetMappingBuilder nécessite que le SELECT de la requête contienne l’ensemble des colonnes nécessaire à l’alimentation de l’objet. À défaut, l’entité sera hydratée de manière incomplète sans qu’aucune erreur explicite ne soit levée.

Être développeur, c'est résoudre des problèmes, pas écrire du code

Wed, 06 May 2026 00:00:00 +0200

Je constate que de plus en plus de développeurs s’interrogent sur leur avenir face à l’IA. Je ne parle pas de simplement s’inquiéter de la perte de leur emploi, mais une remise en question qui va jusqu’à changer de métier.

Ce n’est pas mon cas. Ce qui m’a toujours attiré, c’est de résoudre des problèmes, de réfléchir à une solution, de faire émerger des idées et aller jusqu’à sa concrétisation. Et c’est dans ce cheminement que l’IA prend place, elle permet d’implémenter et de challenger les solutions pensées.

C’est cette réflexion et le processus lié qui m’intéressent. Écrire le code était un des moyens d’y arriver, mais pas une fin en soi (même si j’aimais bien cette partie). Et je pense que c’est ce qui change tout.

Si, en tant que développeur, la seule chose qui vous animait, c’était le code en lui-même, alors je comprends que l’IA remet en question un bon nombre de choses.

L’IA (tel qu’elle existe aujourd’hui tout du moins) ne remplace pas les développeurs. Elle ne remplace pas le jugement, la capacité à comprendre un problème de fond, à choisir la bonne approche et à concevoir une architecture qui tient dans le temps. Ce sont ces compétences qui ont toujours compté et qui comptent toujours autant, voire même plus qu’auparavant.

Se former à un nouveau langage à l'ère de l'IA

Sat, 02 May 2026 00:00:00 +0200

C’est une habitude que j’ai depuis longtemps, je m’intéresse de manière plus ou moins assidue, chaque année à un langage de programmation autre que mon langage principal que j’utilise professionnellement. Ruby, Elixir, Rust, Go, Python ou encore Typescript. Cette année, ça sera C#.

Mais à une période où l’intelligence artificielle écrit de plus en plus de code à notre place, est-ce qu’apprendre et explorer un nouveau langage a-t-il encore du sens ?

Pour moi, la réponse est clairement oui. Oui l’IA est omniprésente dans notre quotidien aussi bien personnel que professionnel. Je l’utilise pour explorer et générer du code, me challenger sur des solutions et/ou architectures techniques, accélérer certaines implémentations de code ou de prototype. Mais le problème que l’on constate de plus en plus, c’est la perte de connaissance, de maitrise des concepts de bases de notre métier, autrement dit, au plus on utilise l’IA et au plus nos compétences/connaissances se réduisent.

Il est donc essentiel de rester actif, d’entretenir notre savoir-faire et d’apprendre un nouveau langage est un des moyens pour que les bases restent ancrées de mon esprit. Même si écrire des lignes de code manuellement tend à disparaître, c’est quelque chose que j’ai toujours aimé. Réfléchir à ce que je souhaite mettre en place, modéliser un problème et mettre en place une solution. Cela me permet de conserver ma capacité de jugement de la qualité de code produit par l’IA.

De plus, apprendre un nouveau langage est l’occasion de voir ce qui se fait ailleurs, de découvrir d’autres principes, d’autres pratiques. Chaque langage a une philosophie et ça permet parfois d’aborder des problèmes différemment.

J’ai choisi C# cette année, car c’est un langage qui a beaucoup évolué et qui, malgré le fait qu’il ne soit plus cantonné à l’environnement Microsoft et Windows, souffre toujours de cette image. Ce sera l’occasion de me faire ma propre idée. Au delà du langage lui-même, je fais beaucoup de veille et je vois régulièrement des développeurs autour de cet écosystème partager un tas de choses intéressantes. J’ai l’impression qu’il y a une culture très “craft” qui se dégage de la communauté et que j’apprécie.

Alors oui, l’IA peut écrire du code à ma place, elle peut l’écrire en C#, elle peut générer une application dans n’importe quel langage. Mais comment conserver un esprit critique, comment prendre du recul sur ce qu’elle a produit, si on n’est pas capable ou si l’on a oublié nos bases fondamentales. C’est aussi ce que je recherche quand j’apprends ou que je pars à la découverte d’un nouvel écosystème. Parce que je pense que je ne le répéterai jamais assez, mais connaitre les fondamentaux à l’ère de l’IA, c’est primordial pour ne pas décrocher.

Quand personne ne répare la CI, ce n'est pas un bug. C'est un choix.

Wed, 29 Apr 2026 00:00:00 +0200

J’ai connu des équipes dans lesquels, quand on arrivait le matin, on pouvait constater que la branche principale était cassée depuis plusieurs jours. La CI (eg. l’intégration continue) échouait en continu, et personne dans l’équipe ne semblait s’en inquiéter.

Quand on vit cette situation, ce n’est plus un problème technique, c’est un problème de culture.

Quand une CI cassée devient la norme (et ça arrive plus souvent qu’on ne le croit), c’est que l’équipe a progressivement appris à l’ignorer. J’en ai déjà parlé plusieurs fois, mais ce que l’on tolère devient un standard.

Une pipleine rouge que personne ne corrige, c’est un signal silencieux envoyé à toute l’équipe: “ce n’est pas grave”. Et ce signal s’installe durablement.

Pourtant, une intégration continue est le filet de sécurité collectif. C’est ce qui garantit que le code partagé est dans un état stable et déployable à tout moment. Laisser ce filet trouvé, c’est avancer sans protection en espérant que rien ne tombe.

Le problème n’est pas la CI qui casse, cela peut arriver et c’est presque normal et rassurant. Ce qui est inquiétant, c’est l’absence de réaction. Une branche principale cassée devrait déclencher une mobilisation immédiate, pas une résignation silencieuse.

Restaurer l’état de la branche principale devrait être LA priorité numéro une de toute équipe. C’est une règle simple, mais elle en dit beaucoup sur la manière dont une équipe traite la qualité au quotidien.

Une CI verte en permanence, ce n’est pas du perfectionnisme. C’est l’assurance de travailler sereinement et de livrer avec un minimum de confiance.

L'IA accélère la valeur et les erreurs

Wed, 22 Apr 2026 00:00:00 +0200

L’IA permet de livrer plus vite, même parfois beaucoup plus vite. Mais livrer vite, ce n’est pas sans conséquences. Car si l’IA permet d’aller plus vite, elle accentue aussi les erreurs et les problèmes qui vont avec.

Un mauvais choix d’architecture, une logique métier mal comprise, une dette technique ignorée: tout cela va arrive désormais plus vite, à plus grande échelle et donc avec des impacts potentiellement plus importants.

L’IA est un accélérateur, elle amplifie le bon comme le mauvais. C’est pour cela qu’il est important d’avoir des équipes avec des bases solides, une vision claire et une organisation bien structurée. Une équipe sans fondation, c’est aller dans le mur plus vite.

L’avènement de l’IA ne rend pas les fondamentaux obsolètes, elle les rend indispensables. Organisation, vision, qualité et clarté sont les éléments à faire émerger dans les organisations.

La qualité est une responsabilité collective

Mon, 20 Apr 2026 00:00:00 +0200

Dans la plupart des équipes où je suis passé, les responsabilités étaient souvent fortement découpées. Le product owner définit, le développeur code, la Q/A valide. Sur le papier, ça semble fonctionner, chacun à son rôle et ses responsabilités sont bien définies. Ce que l’on constate dans la pratique, c’est exactement l’inverse.

Dans cette chaîne de valeur, la qualité est alors l’étape finale. Elle devient un filet de sécurité plutôt qu’une culture d’équipe. Pourquoi le développeur va-t-il s’assurer dans les moindres détails de l’impact de son travail, puisque la validation est la responsabilité du testeur ?

Les bugs remontent alors tardivement et coutent alors plus cher à corriger. Les uns et les autres vont se renvoyer la responsabilité. Le testeur renvoie la balle au développeur, qui va potentiellement remettre en cause la spécification.

Pourtant, j’ai eu la chance de travailler dans des équipes où la qualité est ancrée dans la culture de l’équipe. Et je parle bien de l’équipe entière, pas seulement de quelques membres. Et ça change tout !

Tout le monde travaille main dans la main. Toute l’équipe est intégrée dans le processus de définition et de validation des spécifications produit. Le développeur va intégrer les tests (qu’ils soient automatisés ou manuels) dans son travail en coordination avec les PO et les testeurs. La QA n’intervient pas uniquement en phase finale, mais est intégré en amont pour challenger la conception et les cas à prendre en compte.

La qualité, ce n’est pas une phase du cycle de développement, c’est une responsabilité partagée. La qualité, ça commence avant même l’écrire des premières lignes de spécifications et ça ne s’arrête qu’une fois la fonctionnalité dans les mains des utilisateurs satisfaits.

Déployer et livrer: et si c'était deux choses différentes ?

Wed, 08 Apr 2026 00:00:00 +0200

Dans de nombreuses équipes de développement, déployer c’est livrer des fonctionnalités aux utilisateurs. Pourtant, il est tout à fait possible de dissocier déploiement et livraison. Cela peut même avoir de nombreux avantages.

Déployer du code est un acte technique: on dépose du code sur un serveur. Livrer une fonctionnalité est un acte produit: on ajoute ou modifie le fonctionnement de l’application pour les utilisateurs.

Dissocier les deux, c’est permettre de déployer fréquemment sans impact utilisateur (ou de manière limitée). C’est pouvoir choisir quelles fonctionnalités livrées et à quel moment. C’est aussi activer une fonctionnalité de manière progressive afin d’observer son impact, ses conséquences en utilisation réelle et ainsi pouvoir relever les éventuels problèmes sur un panel restreint.

Pour que cela se fasse dans de bonnes conditions, il est essentiel de ne pas basculer l’ensemble des utilisateurs d’un coup, mais d’exposer les changements progressivement. On mesure et on ajuste.

Cela permet aux équipes de développement de limiter les développements longs en mode tunnel. On peut alors mettre en place des itérations courtes et déployer des changements incomplets. La fonctionnalité finale ne sera activée qu’une fois complètement terminée ou dans un état réellement utilisable par les utilisateurs finaux.

C’est ainsi que se met en place une stratégie de “Continuous Delivery”. Avoir un code qui soit toujours livrable en production sans accumuler plusieurs semaines de développement. Le déploiement ne doit pas un événement redouté: c’est une opération contrôlée, dont le risque est modéré et facilement réversible ou corrigible.

Le biais de nos choix techniques

Wed, 01 Apr 2026 00:00:00 +0200

À mon sens, la compétence essentielle d’un développeur, ce n’est pas d’écrire du code (surtout à l’ère de l’IA), mais c’est de savoir choisir la bonne solution au bon problème et de savoir défendre ce choix.

J’en parle régulièrement, je suis un défenseur des technologies “ennuyantes” (les « boring technologies ») et j’observe un schéma qui se répète régulièrement: lorsqu’une équipe choisit une technologie classique, elle sera remise en cause au premier problème venu. À l’inverse, une solution plus moderne sera rarement questionnée de la même manière.

Le choix initial biaise le regard que l’on porte sur les difficultés qui suivent. Tout d’abord parce que utiliser une technologie en vogue est intellectuellement stimulant. Mais aussi parce que beaucoup ont l’impression de maitriser sur le bout des doigts les technologies que l’on utilise « tous les jours ». Pourtant, la réalité c’est que nous avons beaucoup à apprendre.

Ce qui devrait guider une décision technique, ce n’est pas l’attrait d’une technologie ni l’envie qu’elle soit valorisante sur un CV. Ce devrait être le problème à résoudre, les compétences de l’équipe en place et la question de savoir si les outils actuels ont réellement été explorés dans leur profondeur.

Déploiement continu et cycles de développement longs

Wed, 25 Mar 2026 00:00:00 +0100

Lorsque l’on travaille sur des applications web orientées SaaS, on a la chance de pouvoir livrer rapidement et régulièrement de nouvelles fonctionnalités aux utilisateurs. C’est ce qui se cache derrière les concepts de livraison ou de déploiement continu. Pourtant, beaucoup d’équipes font des mises en production qui concentrent des semaines de développement. Et c’est à mon sens un problème.

Plus un déploiement est rare, plus il embarque de changements et plus le risque d’incidents augmente. Le volume de modifications impliqué peut drastiquement complexifier l’identification et la correction des bugs, car les développements liés peuvent parfois remonter à plusieurs semaines ou mois.

Les utilisateurs en sont les premiers impactés: apparition de nombreux bugs du fait de l’accumulation des développements et nouvelles fonctionnalités qui arrivent tardivement.

Côté développeur, les cycles longs sont souvent liés à des branches de développement avec une longue durée de vie. Si le travail est isolé le temps de conception, c’est lorsqu’il faut tout mettre en commun que les choses se compliquent: conflits de code à gérer et effets de bord potentiellement détectés à la dernière minute.

La réponse à ce problème est peut-être contre-intuitive, mais elle réside dans le fait de déployer plus souvent, des changements progressifs et incrémentaux. Les petits changements sont alors plus faciles à surveiller et à corriger. De plus, l’impact d’un bug se fait sur une surface réduite.

Déployer plus souvent, c’est également se poser moins de questions sur les potentiels impacts de ce que l’on va livrer. J’ai, par exemple, vu des équipes devoir « patcher » la version d’un outil datant de plusieurs mois et être effrayées à l’idée de devoir déployer les nouveaux changements.

Il est pourtant possible de limiter les erreurs. Il existe de nombreuses techniques permettant de livrer du code progressivement. On peut, par exemple, évoquer le mécanisme de « features flags » qui permet d’activer (ou non), de manière progressive (ou non), des fonctionnalités pour un périmètre d’utilisateur défini.

Il ne faut pas oublier que moins on déploie et plus on a peut de déployer. Et plus on a peur de déployer, moins on déploie. Il est donc essentiel de livrer petit et souvent.

Période difficile pour les conférences développeur

Wed, 18 Mar 2026 00:00:00 +0100

Avec l’avènement de l’IA, notre métier de développement logiciel doit se réinventer et avec lui, son écosystème. Je pense notamment aux conférences pour développeurs.

Cela fait quelque temps que de nombreuses conférences, qui sont essentielles à notre métier, étaient en difficulté. Avec une économie compliquée, le sponsoring en baisse, difficile de rentrer dans les frais nécessaires à leurs survies.

Si l’on commence à voir les emplois de « développeurs » chuter, je constate de plus en plus l’arrêt des conférences du fait d’un manque de financement et de participation.

Les conférences sont des espaces où se transmettre le savoir et les retours d’expérience. C’est également un moment social de rencontre et d’échange. Il est à mon sens essentiel que ce genre d’événement puisse perdurer.

Les profils T-Shaped

Thu, 12 Mar 2026 00:00:00 +0100

Il y a un type de profil qui performe particulièrement bien dans les équipes projet. Des profils spécialisés, mais qui ont un truc en plus: des compétences transverses complémentaires. C’est ce que l’on retrouve derrière la notion de profil “T-Shaped”.

Ce type de profil possède une expertise poussée dans un domaine, à laquelle s’ajoute un large base de connaissances et de compétences transverses.

Vous en avez sûrement déjà croisé. C’est par exemple un développeur backend capable de comprendre les aspects de l’expérience utilisateur, tout en prenant en compte les contraintes d’infrastructures et les besoins produit. Il ne maîtrise pas tout, mais il a conscience de ce qui l’entoure et des enjeux liés.

C’est le genre de profil qui limite les frictions et les malentendus lorsque des métiers différents collaborent. Il traduit, facilite et aligne, aidant ainsi l’équipe à prendre des décisions collectives éclairées.

Cultiver ce type de profil dans une équipe est essentiel. Une équipe trop spécialisée tend à créer des silos par compétence et limite les interactions transverses. Les profils T-Shaped sont ce qui permet de collaborer efficacement sur le long terme.

Arrêtez de blâmer vos utilisateurs

Fri, 06 Mar 2026 00:00:00 +0100

On a tous des phrases qui nous font réagir intérieurement. Parmi celles qui me font certainement le plus réagir, il y a les réactions du style « la plateforme est plantée, c’est la faute du client, il a fait n’importe quoi ». Parce que dans bien des cas, si le client a pu faire n’importe quoi, c’est parce que l’outil le lui a permis.

Ce n’est pas l’utilisateur le problème, c’est l’absence de contraintes, de validations et de contrôles qui auraient dû empêcher l’applicatif d’atteindre cet état. Un outil ne se contente pas de fonctionner dans les cas nominaux, il « ne fait pas confiance » à l’utilisateur. Il anticipe les erreurs et les mauvaises manipulations. Il doit guider l’utilisateur et l’empêcher de se retrouver dans une situation difficile.

Je suis convaincu que nombreux sont ceux qui ont des exemples en tête. Un formulaire qui accepte une valeur « non autorisée », un clic sur un bouton de suppression sans confirmation ou encore une API sans restriction d’usage. Autant d’exemples qui autorisent les données à être dans un état incohérent.

Rejeter la faute sur le client, c’est passer à côté de l’essentiel: l’expérience utilisateur. Les outils que l’on conçoit doivent nous faciliter le quotidien, mais aussi nous guider dans les actions que nous réalisons pour que tout se passe au mieux.

Ne confondez pas dette technique et préférence personnelle

Wed, 25 Feb 2026 00:00:00 +0100

Quand on évolue dans la tech, on entend souvent parler de « dette technique ». Je trouve ce terme assez galvaudé, car souvent, lorsque l’on me parle de dette technique, ce que l’on m’explique c’est que le code ne correspond pas au « standard » du développeur qui en parle.

Qui n’a jamais rencontré cette situation ? Un développeur arrive sur un projet et découvre une architecture qu’il ne connaît pas, des conventions qui diffèrent de celles qu’il a l’habitude d’utiliser. Bien souvent, on va qualifier ça de « dette technique ». Pourtant le code est fonctionnel, correctement maintenu et répond au besoin utilisateur.

En informatique et en développement, il n’y a pas de recette universelle. Une méthode ou façon que l’on peut appliquer partout de la même manière. Tout est une question de contexte et d’équipe. Ce n’est pas parce qu’un choix technique diffère de nos habitudes qu’il est mauvais.

Mais alors la dette technique c’est quoi ? C’est un compromis conscient et assumé entre vitesse et qualité. Autrement dit, c’est un choix délibéré, une solution imparfaite pour livrer du code plus vite avec l’intention d’y revenir plus tard.

Le problème survient lorsque la dette n’est pas identifiée, ni suivie. Lorsque les compromis établis s’accumulent sans que personne n’en ait conscience. C’est à ce moment que la dette devient toxique, lorsqu’elle devient durable et ralentit les équipes.

La dette technique, il faut l’identifier et la suivre, mais il ne faut pas confondre un choix intentionnel d’un choix qui diffère de nos pratiques personnelles.

Boring technology: les bases de données relationnelles

Wed, 18 Feb 2026 00:00:00 +0100

La semaine dernière, j’évoquais les « boring technologies » et le fait qu’elles soient sous-cotées dans l’esprit collectif. Les bases de données relationnelles et le langage SQL en sont probablement l’exemple le plus courant. Très largement utilisées dans les projets nécessitant de stocker des informations, elles sont pourtant régulièrement boudées par les développeurs au premier problème.

C’est le constat que je fais depuis plusieurs années et la cause est que de moins en moins de développeurs en maîtrisent le fonctionnement ou ne connaissent réellement le langage SQL. Je ne pense pas que cela soit réellement dû à un manque d’intérêt, je pense surtout que les frameworks et les ORM que nous utilisons au quotidien ont leur part de responsabilité.

De nombreuses couches d’abstraction sont conçues de manière générique pour permettre d’interchanger rapidement et simplement le système relationnel. Cela se fait au détriment des fonctionnalités avancées, des optimisations spécifiques ou des mécanismes évolués permettant d’améliorer drastiquement les performances de nos applications (colonnes générées, gestion des vues, index partiels, CTE, requêtes récursives, partitionnement, …).

Cela ne se remarque pas à charge ou volumétrie réduite. Mais dès que l’on change un peu d’échelle, c’est là que les problèmes commencent. Les temps de réponse se dégradent, les performances chutent et si l’on ne s’intéresse pas à ce qu’il se passe sous le capot du SGBD, cela devient très compliqué de s’en sortir.

Les ORM ne sont pas le problème. Ce sont des outils très pratiques qui permettent de gagner du temps. Mais eux aussi, il convient de les maîtriser pour optimiser les requêtes générées et savoir comment tirer parti des fonctionnalités avancées des bases de données. La plupart d’entre eux ont des couches « bas niveau » et permettent généralement de faire des requêtes SQL directement et éventuellement de « mapper » la réponse dans des objets.

Comme je le dis régulièrement, il est essentiel, voire indispensable, de s’attacher aux fondamentaux, de comprendre et maîtriser les outils que l’on utilise. Le langage SQL et le fonctionnement des bases de données en font partie. C’est ainsi que l’on peut se donner les moyens de construire des applications qui tiennent la charge sur le long terme sans multiplier les technologies.

Simplifier vos objets immuables avec PHP 8.5

Mon, 16 Feb 2026 00:00:00 +0100

PHP 8.5 a été publié le 20 novembre 2025 et, dans les nouvelles fonctionnalités proposées par cette version, on trouve notamment la possibilité de mettre à jour des propriétés lors du clonage d’objets. Une amélioration qui va permettre de simplifier nos objets immuables.

En programmation orientée objet, un objet immuable est un objet dont l’état ne peut pas être modifié après sa création. Ainsi, toute “modification” visant à changer l’état de ce dernier conduit à la création d’une nouvelle instance avec les valeurs mises à jour. Cela représente un réel avantage, car leur état ne changeant jamais, les effets de bord et bugs liés à des modifications inattendues de l’objet sont ainsi limités.

Avant PHP 8.5, la modification d’un objet immuable pouvait s’avérer fastidieuse, car il était nécessaire de créer une nouvelle instance avec les nouvelles valeurs. Cela pouvait être d’autant plus contraignant si l’objet avait de nombreuses propriétés.

Par exemple:

readonly class GPSLocation
{
    public function __construct(
        public float $latitude,
        public float $longitude,
        public float $altitude,
        public DateTimeImmutable $timestamp,
    ) {
    }

    public function withCoordinates(float $latitude, float $longitude): GPSLocation
    {
        return new GPSLocation(
            $latitude,
            $longitude,
            $this->altitude,
            $this->timestamp,
        );
    }

    public function withAltitude(float $altitude): GPSLocation
    {
        return new GPSLocation(
            $this->latitude,
            $this->longitude,
            $altitude,
            $this->timestamp,
        );
    }
}

PHP 8.5 nous permet de simplifier cette opération en permettant de cloner l’objet tout en autorisant de mettre à jour certaines propriétés lors du clonage. Seules les propriétés devant être modifiées doivent être précisées:

readonly class GPSLocation
{
    public function __construct(
        public float $latitude,
        public float $longitude,
        public float $altitude,
        public DateTimeImmutable $timestamp,
    ) {
    }

    public function withCoordinates(float $latitude, float $longitude): GPSLocation
    {
        return clone($this, [
            'latitude' => $latitude,
            'longitude' => $longitude,
        ]);
    }

    public function withAltitude(float $altitude): GPSLocation
    {
        return clone($this, [
            'altitude' => $altitude,
        ]);
    }
}

Ce site est de retour en France

Sat, 14 Feb 2026 00:00:00 +0100

Cela fait plusieurs années que je m’intéresse beaucoup à la souveraineté numérique et la dépendance technologique que l’on peut avoir (principalement concentré sur des acteurs américains). J’en parlais dans un précédent article, mais à ce titre, je souhaite réduire ma dépendance aux GAFAM au profit d’acteurs français (ou européens).

J’ai l’année dernière quitté la galaxie Google pour basculer chez Proton. Toutes mes applications et serveurs sont actuellement hébergés chez Scaleway avec les noms de domaines gérés par OVH.

Mais ce site et quelques autres contenus statiques étaient hébergés depuis plusieurs années sur Github Pages. Pratique et gratuit, mais cela faisait “tâche” pour quelqu’un qui souhaite défendre la souveraineté numérique française.

Après quelques recherches et recommandations, j’ai trouvé la solution qui me convient parfaitement. Ce site est donc de retour en France, hébergé par Alwaysdata, un hébergeur français qui m’a grandement été recommandé. Et je dois dire que je valide complètement ce choix aussi bien par la facilité d’utilisation, de migration que par la qualité et l’offre de services proposés.

Une migration faite sans difficulté et j’ai maintenant un sentiment de cohérence entre ma volonté de défendre la souveraineté numérique française et les choix que je fais moi-même pour les solutions informatiques que je mets en œuvre.

Savoir jusqu'où utiliser les "boring technologies"

Thu, 12 Feb 2026 00:00:00 +0100

Je milite activement pour l’utilisation des « boring technologies », les technologies ennuyeuses, mais maîtrisées par rapport aux solutions « tendances ». Le plus dur étant de savoir où s’arrêter et de déterminer à quel moment il est temps de changer de solutions.

Choisir une technologie « ennuyante », c’est par exemple pousser une base de données relationnelle dans ses retranchements avant de vouloir passer sur une technologie NoSQL. C’est aussi concevoir un monolithe modulaire bien structuré au maximum de ses capacités avant de basculer sur des microservices.

L’idée dans tout ça, c’est de pousser les technologies jusqu’à leurs limites avant de changer de solution technique. Cela signifie qu’il est essentiel de se former et de se documenter sur ces dernières pour connaitre l’ensemble de leurs capacités et pas forcément s’arrêter à notre cercle de connaissance.

Le piège, c’est l’anticipation et le marketing. Pour prendre l’exemple de la base de données, bien souvent on démarre avec une base de donnéee relationnelle. Le produit grandit, les données s’accumulent et aux premiers signes de charge, on souhaite passer à l’échelle et introduire une nouvelle technologie.

Le problème que je vois, c’est qu’on a souvent exploré un minimum de ce que les SGBD peuvent offrir. En tant que développeur, les ORM nous éloignent du monde des bases de données, la couche d’abstraction tue nos compétences SQL et les performances de nos applications.

Maîtriser les ORM, optimiser des requêtes, ajuster les index, utiliser des fonctionnalités SQL avancées (telle que les CTE, les index fulltext, la mise en cache…). Poncer une technologie jusqu’au bout, c’est accepter de ne pas toujours choisir la solution la plus élégante, mais la plus pragmatique. C’est repousser le moment où l’on va devoir introduire de la complexité supplémentaire.

Le plus dur dans tout ça, c’est d’identifier le moment où l’on atteint la limite. Quand optimiser coûte plus cher que de changer une partie du système.

Bien souvent dans ces cas-là, c’est l’expérience et la connaissance approfondie des outils qui font la différence.

Siloter les équipes, c'est effriter la cohésion

Wed, 04 Feb 2026 00:00:00 +0100

J’évoque régulièrement la thématique du silotage des équipes. Aujourd’hui, j’aimerais revenir sur les barrières invisibles que cela crée pour la collaboration et le partage des connaissances.

Découper les équipes, les isoler, c’est faire en sorte que ces dernières puissent se concentrer sur leur périmètre. Mais c’est aussi complexifier et réduire les interactions avec les autres équipes. Moins de communication, c’est plus d’incompréhensions. On perd ainsi progressivement la vision globale où les objectifs directs vont primer.

Le fonctionnement en silos freine les opportunités de développement, aussi bien pour l’entreprise que les collaborateurs eux-mêmes. Moins d’interactions, ce sont des connaissances qui ne sont plus partagées, c’est moins de découvertes de compétences différentes.

Et au final: une cohésion qui s’effrite.

Pour atténuer ces effets, il est possible d’activer plusieurs leviers. Organiser et favoriser la rotation des membres entre équipes pour casser les habitudes et ouvrir de nouvelles perspectives. Mettre en place des projets transverses nécessitant la collaboration de différentes équipes pour renforcer l’esprit d’équipe et avoir des enjeux partagés.

Mais surtout, il est indispensable de créer et maintenir des canaux de communication ouverts à tous. Des espaces où chaque équipe peut partager ses idées, ses problématiques et ses apprentissages avec les autres. Et c’est ainsi que pourra se construire une culture de la collaboration et du partage.

La réunion d'équipe la plus importante

Fri, 30 Jan 2026 00:00:00 +0100

La réunion d’équipe que je considère comme indispensable est certainement la rétrospective. C’est un point essentiel pour favoriser l’amélioration continue et renforcer la dynamique d’équipe.

La rétrospective permet de mettre en place un espace dédié pour réfléchir et prendre du recul sur le travail récent. Identifier ce qui a bien ou mal fonctionné. Décider et mettre en place des pistes d’amélioration pour la suite.

Pour qu’elle se déroule au mieux, il est important de faire des rétrospectives de manière régulière, généralement à la fin de chaque itération. Ne pas faire ce point, c’est manquer l’opportunité de s’améliorer et de corriger les problèmes qui retardent un projet.

Si ces dernières sont trop espacées les unes des autres, certains aspects ne seront plus frais dans la tête des participants, ce qui occultera des éléments qui pourraient être essentiels.

Il est également fondamental de prévoir le temps nécessaire pour avoir des discussions significatives et permettre d’approfondir les points abordés. Cela ne pourra se faire efficacement que via la mise en place d’un cadre et d’une structure telle que « Démarrer, Arrêter, Continuer » dans lequel chaque participant pourra donner son point de vue.

Et bien entendu, la rétrospective ne s’arrête pas une fois la réunion terminée. Dans le cadre de l’amélioration continue, il sera nécessaire de suivre les actions décidées d’une rétrospective à une autre.

La rétrospective est donc pour moi le rituel qui, bien mené, permet de transformer les difficultés rencontrées en axes d’amélioration. Ne pas prendre le temps de regarder en arrière, c’est avancer avec des œillères et potentiellement aller dans le mur.

Documentation vivante

Wed, 21 Jan 2026 00:00:00 +0100

N’importe qui ayant déjà écrit de la documentation sait que le principal problème, c’est qu’elle devient rapidement obsolète une fois écrite.

Il n’y a qu’à parcourir les README des projets sur lesquels vous travaillez pour probablement y trouver des informations qui ne correspondent plus à la réalité du projet. Il y également fort à parier que vous ayez déjà vu des schémas d’architecture qui décrivent un système qui n’existe plus. Ou alors des procédures d’installation qui échouent, car plus à jour.

Pour éviter ces décalages, il est intéressant de créer une documentation capable de vivre et d’évoluer avec le projet. C’est le concept de “Living Documentation”. L’idée est simple: plutôt que de maintenir manuellement des documents décorrélés du code, la documentation est directement générée à partir de ce dernier.

C’est moins compliqué qu’il n’y paraît, et vous avez probablement les premières briques nécessaires à sa mise en place. Les tests peuvent décrire les spécifications implémentées. Des annotations peuvent servir à générer de la documentation technique. Les diagrammes d’architecture peuvent être générés à partir de l’analyse du code source. Il est possible d’automatiser énormément de choses, encore plus aujourd’hui à l’ère des IA génératives.

L’approche de “Living Documentation” permet ainsi d’avoir une documentation toujours à jour, une source de vérité fiable au cours du temps. Pour y parvenir, il est essentiel que la gestion de la documentation soit intégrée dans le processus de développement, que cela fasse partie de la culture d’équipe.

Une documentation qui ne suit pas le rythme du code est vouée à mourir. Investir dans une documentation vivante, c’est s’assurer de sa pérennité et d’améliorer durablement la maintenabilité de vos projets.

La formulation d'un message n'est pas un détail

Wed, 14 Jan 2026 00:00:00 +0100

La manière dont on transmet un message est tout aussi importante que le fond du message lui-même.

Les équipes techniques discutent et débattent régulièrement d’idées et de concepts, de différentes solutions pour répondre à un problème. Une proposition d’architecture mal formulée, un retour de revue de code maladroit ou un feedback technique confus et le message est atténué. Le fond s’efface au profit de la forme.

Le résultat: des personnes qui se braquent ou se ferment. Le sens du message passe au second plan. On oublie l’idée, on ne retient que la manière dont elle a été exprimée. C’est également quelque chose que j’observe lors de conférences avec des speakers qui ne sont pas à l’aise à l’oral. Le contenu peut être excellent, mais la transmission est difficile et l’audience décroche.

La communication n’est pas uniquement une question de contenu, c’est aussi une question de perception et réception. La manière dont on dit les choses est tout aussi importante que ce que l’on dit.

Que l’on soit développeur, product owner ou manager, la communication est une compétence essentielle. Un message mal transmis perd de sa valeur, aussi pertinent puisse-t-il être.

La forme n’est pas un détail, c’est ce qui permet à votre message d’être compris et entendu.

Les bonnes pratiques sont contextuelles

Wed, 07 Jan 2026 00:00:00 +0100

Ce qui fonctionne pour une équipe et un projet donné peut ne pas fonctionner ailleurs. L’architecture, la méthodologie, les pratiques en place qui ont fonctionné dans un contexte précis ne sont pas nécessairement transposables telles quelles d’une équipe à une autre ou d’un projet à un autre.

Il n’est pourtant pas rare de vouloir tout uniformiser en entreprise, parfois à l’extrême. Je vois et j’entends régulièrement des développeurs dire « il ne faut pas faire comme ça » ou « ça c’est une bêtise » en voyant telle ou telle pratique de code. Pourtant, ce sont des pratiques qui fonctionnent (parfois très bien) dans le contexte dans lequel elles sont utilisées. Simplement, cela sort des standards habituels connus des personnes qui font la remarque.

Il n’y a pas de recette universelle, pas de vérité absolue en informatique. « There’s no silver bullet » comme disent nos amis anglo-saxons. Une équipe de quelques développeurs sur un projet qui démarre n’a pas les mêmes contraintes qu’une équipe de dizaines de développeurs sur un produit mature.

Il est essentiel de comprendre le pourquoi derrière chaque pratique avant de la juger. C’est en comprenant les éléments qui ont conduit à sa mise en place qu’il sera possible de déterminer si elle est pertinente dans un autre contexte.

Les équipes qui fonctionnent le mieux ne cherchent pas à appliquer aveuglément ce qu’elles ont appris ailleurs. Elles questionnent, s’adaptent et font évoluer leurs pratiques en fonction de la maturité du projet et des personnes qui le composent.

Récapitulatif 2025

Sun, 04 Jan 2026 00:00:00 +0100

Je ne suis pas coutumier du traditionnel récapitulatif de l’année écoulée, néanmoins cela ne fait pas de mal de regarder un peu en arrière de temps en temps.

Partage de contenu

Je m’étais fixé comme objectif de relancer un peu ce blog et de publier de manière plus régulière. J’avais en tête un objectif de faire une publication par semaine. Avec 45 publications sur l’année, je ne suis pas loin de mon objectif. 2025 est l’année où j’ai le plus partagé sur le blog.

Depuis la création de ce blog, je publie avant tout pour moi. Il s’agit de partager mes réflexions, de poser des notes et de creuser certains sujets. Voici les trois articles qui ont été le plus consultés sur l’année:

Structurez votre code explicitement avec la “Screaming Architecture” (2025)
La notion d’agrégat en DDD (2020)
Le design pattern “Unit of Work” (2025)

Je partage régulièrement du contenu depuis 2009. J’ai eu différents blogs avant celui-là où j’ai pris l’habitude de diffuser ma veille technique. Cette dernière est disponible sur différents réseaux sociaux (Bluesky, Mastodon et X).

Je partage également depuis peu et chaque semaine sur LinkedIn. La ligne éditoriale est un peu différente, puisque j’y partage un contenu moins technique. Il s’agit généralement d’une idée ou un concept sur une thématique de gestion et structuration d’équipe. Comme pour le contenu technique, l’idée est de partager, d’échanger, me forcer à creuser et structurer mes pensées sur des sujets humains et/ou organisationnels. J’ai de plus en plus envie de comprendre et progresser sur les mécanismes humains et organisationnels qui permettent d’améliorer la performance et la cohésion des équipes.

À ce titre, voici le top 3 des publications LinkedIn 2025:

La révolution de l’IA dans le développement logiciel

L’IA est certainement le plus grand changement que j’ai connu depuis le début de ma carrière. Je pense que c’est une révolution majeure qui est en train de s’opérer. La manière dont nous travaillons est en train de radicalement évoluer.

Comme de nombreuses personnes, je ne souhaite pas passer à côté. Je suis utilisateur régulier d’outils basés sur l’IA, de LLM. C’est une technologie qui est maintenant intégrée dans mon quotidien, que ce soit personnel ou professionnel.

La courbe d’apprentissage et le changement d’habitude ne sont pas simples. Mais comme souvent, une fois la technologie et les concepts sous-jacents assimilés, c’est un vrai gain de qualité et de productivité qui en découle.

Je vois difficilement comment l’avenir ne peut continuer dans cette direction. Je pense qu’il est important de s’y mettre avant de rater le train et qu’il ne soit trop tard. Je pense aussi, qu’il est plus que jamais important, d’acquérir les bases techniques et de revenir aux fondamentaux dans un monde où l’on va de plus en plus déléguer de responsabilités à l’IA. Il est essentiel de conserver notre capacité à suivre et comprendre ce qui est fait par les machines.

Participations aux conférences

J’apprécie beaucoup de participer à des conférences. Ce sont des moments essentiels pour découvrir de nouveaux sujets, assister à des retours d’expérience d’autres professionnels et entreprises. C’est un moment qui permet de rencontrer et d’échanger des idées, des expériences et des connaissances avec d’autres personnes.

Ces derniers temps il est devenu plus difficile de trouver du temps en semaine pour participer à des meetups en fin de journée. Heureusement, mon employeur me permet d’assister à des salons professionnels.

Comme depuis plusieurs années maintenant, j’ai pu assister cette année à la grande messe des développeurs PHP: le Forum PHP organisé par l’AFUP. C’est pour moi l’événement le plus important de la communauté PHP que je ne souhaite pas louper.

J’ai d’ailleurs eu l’occasion cette année avec Marion de présenter la société où je travaille actuellement: Activinnov qui fait partie des sponsors de l’événement (merci à eux, le sponsoring étant essentiel pour faire vivre ce genre d’événement).

L’ensemble des conférences du ForumPHP est maintenant disponible en replay sur YouTube.

À côté de ça, j’ai également eu le plaisir et l’occasion d’assister au premier DevFest de Lyon.

Un pas de plus vers une tech plus européenne

Cela fait maintenant quelques années que je m’intéresse de plus en plus à la souveraineté numérique. J’ai l’envie et la volonté de moins dépendre des services techs américains. Je souhaite réduire ma dépendance à ces derniers et migrer le plus possible vers des solutions françaises ou à défaut européennes.

C’est un sujet qui me tient à cœur, d’autant plus qu’on a quelques sujets d’actualités qui peuvent faire réfléchir.

Même si ce blog est un mauvais élève, je fais héberger autant que possible mes services et sites Web sur des infrastructures françaises (notamment sur Scaleway). J’ai arrêté d’utiliser Google Analytics il y a quelques années maintenant au profit de Pirsch Analytics pour me détacher de Google.

J’ai cette année franchi un nouveau cap en quittant GMail et la galaxie d’applications liées. J’utilise dorénavant la suite proposée par Proton qui est une solution créée et hébergée en Suisse.

Pour conclure, il ne me reste qu’à vous souhaiter une très bonne année 2026.

Ce que l’on tolère devient un nouveau standard d’entreprise

Wed, 17 Dec 2025 00:00:00 +0100

Ce que l’on tolère devient un nouveau standard d’entreprise.

Du code sans tests qui est accepté un jour deviendra la norme de demain. Un raccourci technique validé une fois parce que cela arrange s’éparpillera dans le projet au cours du temps.

Ce qui est toléré devient une règle acceptée, c’est un signal qui dit à l’équipe que c’est « acceptable ». Et progressivement, les exceptions deviennent la norme.

Cela se fait au fil du temps qui passe sans prise de décision consciente parce que l’on aura tendance à reproduire ce qui est fait. Et c’est l’accumulation des petits raccourcis faits dans l’urgence ou par manque d’inattention qui au final, conduit à la perte de qualité.

Il est donc essentiel de bien faire attention et d’accepter que chaque situation où l’on ferme les yeux équivaut à une décision: « oui on peut fonctionner ainsi ». Dans le cas d’un test manquant dans du code, c’est dire que les tests sont optionnels.

Bien entendu, il ne faut pas être rigide. Il y a parfois des compromis à faire. Ces compromis doivent avant tout être explicites et temporaires. Un écart ponctuel est bien entendu possible, le problème c’est si cet écart perdure dans le temps.

C’est donc pour cela qu’il est indispensable de documenter ses standards, conventions et fonctionnement d’équipe. Plus important, de les maintenir au cours du temps. Si l’effort de maintenance est constant, la douleur est moindre que de devoir le traiter ponctuellement. C’est ainsi que pourra se mettre en place une culture d’équipe solide et pérenne.

L'onboarding développeur en 1 étape

Fri, 12 Dec 2025 00:00:00 +0100

L’onboarding d’un nouveau développeur sur un projet est une étape cruciale. Rien de plus frustrant que de devoir passer plusieurs heures à configurer un environnement de développement avant de pouvoir écrire la moindre ligne de code.

Pour résoudre ce problème, j’aime mettre en place une commande unique qui installe, configure et lance l’ensemble du projet. Une simple commande make install (ou un équivalent) et le projet est opérationnel avec la configuration de développement adéquate et les dépendances systèmes requises.

On pourrait penser que l’investissement demandé est superflu. Après tout c’est une commande que l’on va exécuter une seule fois lorsque l’on arrive sur le projet. Mais cette dernière peut également être utilisée au quotidien pour réinitialiser l’environnement de travail, dans le cas d’un changement de machine ou tout simplement pour maintenir une configuration à jour entre l’ensemble des intervenants du projet.

De plus, ce script d’installation et de configuration peut servir de documentation du projet. Et puisqu’automatisé restera toujours à jour.

Démarrer un projet en une seule commande, c’est faciliter l’intégration des développeurs en maximisant le temps entre l’installation du projet et la première contribution. C’est également fournir un onboarding de qualité sur le projet qui donnera une très bonne première impression.

Les réunions hybrides (présentiel/distanciel)

Wed, 03 Dec 2025 00:00:00 +0100

Quand on commence à faire du télétravail, on se rend rapidement compte que les réunions « hybrides » (à la fois en présentiel et distanciel) sont compliquées à gérer: les personnes à distance peuvent rapidement être oubliées et devenir invisibles si certaines règles ne sont pas mises en place.

J’ai souvent observé des réunions où les personnes en distanciel étaient effacées par celles en présentiel. Il n’est pas rare de ne même pas les voir, l’écran utilisé pour la réunion étant généralement monopolisé pour projeter du contenu. Et cela s’accentue si le matériel (son, micro, image) n’est pas de bonne qualité. Tout cela combiné entraîne une mauvaise dynamique de groupe.

Au-delà du matériel, pour qu’une réunion hybride puisse se passer dans les meilleures conditions, j’ai remarqué qu’il était essentiel de maintenir un lien visuel permanent avec l’ensemble des participants. Cela passe par « couper » un écran en deux pour avoir d’un côté les participants à distance et de l’autre le contenu présenté. Il m’est même arrivé, dans certaines expériences, de positionner des avatars dans les salles de réunions représentant physiquement les personnes absentes.

L’objectif est de faire en sorte que chacun reste visible, et donc présent dans la conscience collective. Quand on voit quelqu’un, il est plus facile de capter ses réactions, de l’inclure dans les échanges et de lui donner la parole.

Une réunion hybride n’est pas une simple réunion présentielle auquel des personnes se connectent à distance. Il est essentiel que chaque participant puisse être « physiquement » présent pour prendre place dans la discussion.

Les "boring technologies", un choix sous-estimé

Wed, 26 Nov 2025 00:00:00 +0100

Les “boring technologies” (comprendre les technologies ennuyantes) sont clairement les technologies les plus sous-cotées actuellement.

D’un côté, il y a les technologies “à la mode”, celles que l’on voit partout, dont tout le monde parle, récentes, innovantes et modernes. Celles avec lesquelles la plupart des développeurs aimeraient travailler. Et il y a les autres, les technologies « standard » sans hype, matures, éprouvées et bien comprises. Celles pour lesquelles il n’y a plus de surprises.

Ce que je vois le plus souvent, c’est que les technologies éprouvées sont souvent délaissées au profit de solutions plus récentes alors qu’elles résolvent efficacement la grande majorité des problèmes rencontrés. La mise en place d’un serveur Elasticsearch, là où une requête SQL optimisée pourrait faire l’affaire. Mais cela ne fait pas rêver, ni forcément vendre sur un CV ou intellectuellement.

Le problème avec les technologies récentes, ce n’est pas qu’elles sont mauvaises ou qu’elles ne répondent pas à un besoin. C’est surtout qu’elles ajoutent un niveau de complexité et de risque supplémentaire, qui n’est pas toujours justifié. Elles impliquent également des temps d’apprentissage et manquent parfois de prise de recul.

Choisir une technologie éprouvée et connue, c’est privilégier la fiabilité et la maintenabilité plutôt que la nouveauté. C’est pouvoir tirer parti de nombreuses ressources et connaissances sur le sujet. Et ainsi minimiser les coûts à long terme.

Lorsque l’on souhaite résoudre un problème, il est essentiel de se poser la question de la nécessité d’introduire une nouvelle brique technologique. C’est ainsi que l’on peut construire une architecture et un environnement robustes et pérennes plutôt que de courir après la nouveauté.

La taille d'une équipe est importante

Wed, 19 Nov 2025 00:00:00 +0100

Pour être efficiente, la taille d’une équipe ne devrait pas dépasser 12 personnes. Elle devrait même idéalement se situer entre 5 et 9 personnes. C’est l’idée que l’on retrouve derrière la règle de la « pizza team » popularisée par Jeff Bezos (le fondateur d’Amazon) et également un concept au cœur du mouvement agile.

Cette règle prend tout son sens, car plus une équipe est grande, plus la communication devient difficile. Par exemple, dans une équipe de 5 personnes, il y a 10 canaux de communication possibles. À 10 personnes, cela monte à 45 et, dans une équipe de 20, il y en a 190.

Avoir des équipes de taille réduite permet ainsi de fluidifier la communication. Cela accélère les prises de décision, facilite le partage d’une vision commune et favorise la responsabilité collective. Les petites équipes sont également plus agiles, car elles conservent leur capacité à décider et réagir rapidement.

Il est néanmoins nécessaire de bien positionner le curseur pour allier efficacité et performance. Les équipes doivent rester autonomes et pluridisciplinaires. Elles doivent être dimensionnées et structurées de manière à maîtriser leur périmètre de travail et disposer de l’ensemble des compétences nécessaires à sa bonne réalisation.

Équipe et individualité

Thu, 13 Nov 2025 00:00:00 +0100

Une équipe n’est pas uniquement la somme d’individualité qui travaille conjointement. Une équipe, c’est un ensemble de personnes qui avance à un but commun et qui partage les responsabilités de leur travail.

C’est ce qui différencie une équipe d’un groupe de personnes. Un groupe de personnes est une collection d’individus qui coordonnent leurs efforts en travaillant chacun de leur côté.

Dans les équipes les plus efficaces, chaque membre comprend et partage l’objectif à atteindre, pourquoi cet objectif existe et est également aligné sur la manière d’y parvenir.

Le rôle du management est clé dans cette dynamique, car c’est lui qui a la responsabilité de la mise en place de l’environnement nécessaire à l’atteinte de l’objectif de l’équipe. Il doit créer les conditions indispensables à la cohésion en définissant et partageant la vision et la direction technique.

Car c’est l’alignement de tous sur cette vision partagée et les moyens d’y parvenir qui permettra de mettre en place l’environnement favorable au partage de la responsabilité qui incombe à l’équipe et la différencie de simples personnes qui collaborent ensemble.

Les équipes de développement ne sont pas immuables

Wed, 05 Nov 2025 00:00:00 +0100

Les équipes de développement ne sont pas immuables. Lorsqu’elles se retrouvent modifiées par l’arrivée ou le départ d’un nouveau membre, c’est une nouvelle équipe qui se crée.

Modifier la composition d’une équipe n’est pas anodin. Lors d’un départ, c’est une partie des connaissances du groupe qui s’en va. Des connaissances potentiellement non documentées et des décisions implicites qui sont perdues. À l’inverse, lors d’une nouvelle arrivée, c’est une nouvelle vision des choses qui émerge, mais aussi la nécessité de reconstruire une compréhension et vision commune du projet.

C’est dans cette situation qu’avoir une documentation, une vision et des standards de développement clairement établis devient essentiel. Ils ne sont pas là pour contraindre le fonctionnement, mais pour constituer une connaissance commune et partagée permettant d’avancer ensemble dans la même direction.

Documenter d’où vient et là où l’on veut aller. Décrire l’architecture, les choix effectués et pourquoi les choses ont été réalisées de telle ou telle manière. Expliciter la façon de travailler, les patrons de conceptions privilégiés, le processus de revue de code, la stratégie de tests. Autant d’éléments qui définissent le fonctionnement de l’équipe et permettent de limiter les frictions lors des changements de composition du groupe.

Sans standards clairement établis et partagés, chacun avance dans sa propre direction. Les décisions sont régulièrement discutées et remises en question. Les approches divergent et la cohérence de l’ensemble s’effrite. Le projet devient alors le reflet du passage de chaque équipe.

Définir et maintenir ces standards peut-être long. Cela devrait être un processus continu qui doit être mis à jour au fil des évolutions du projet. L’idéal (et le Graal à atteindre) serait que la documentation et les règles du projet soient automatisées, permettant que personne ne puisse passer à côté.

Définir et documenter permet ainsi d’assurer la stabilité de l’équipe projet au fil du temps.

Le problème n'est pas humain, il est organisationnel

Wed, 29 Oct 2025 00:00:00 +0100

Une des phrases que j’ai le plus entendue depuis le début de ma carrière est « l’équipe X n’a pas conscience des problèmes de l’équipe Y ». Et dans la plupart des cas où elle est prononcée, le problème est rarement humain. Il est plutôt organisationnel.

Cette situation apparaît généralement lorsque les équipes évoluent en silos, chacune avec ses propres objectifs, sans alignement ni vision commune. Des équipes de développement qui n’ont pas conscience des problématiques du support client parce que leurs objectifs et les indicateurs de performance associés sont uniquement basés sur le développement de nouvelles fonctionnalités.

Ou alors, des équipes de développement qui n’ont pas conscience des problèmes de l’infrastructure (et vice versa) parce qu’elles n’ont pas dans leur périmètre le déploiement et le suivi opérationnel des mises en production. Des exemples comme cela, il en existe une multitude.

Un découpage par expertise technique conduit inévitablement à ces silos. Chaque équipe défend ses intérêts, optimise ses indicateurs, mais perd de vue l’objectif qui devrait être commun aux différentes équipes: la valeur pour l’utilisateur.

C’est là qu’une organisation en équipe produit est intéressante. Une équipe produit s’organise autour de compétences pluridisciplinaires (PO, UX, développeurs, ops, QA…) qui possèdent toutes les compétences nécessaires: analyser, concevoir, développer, tester et déployer. Une équipe capable de gérer un cycle produit dans sa globalité, de la création jusqu’à la mise à disposition aux utilisateurs tout en assurant son suivi opérationnel. Elle incarne le mantra « You build it, You run it ».

À la fois, autonome, auto-organisée et responsable d’un périmètre fonctionnel entier. Chaque membre de l’équipe aura ainsi conscience des problématiques des autres. Tout le monde avance à un objectif commun où la satisfaction de l’utilisateur final est la clé du succès.

Expliquer un concept avant de le nommer

Wed, 22 Oct 2025 00:00:00 +0200

Au fil des années, j’ai appris à expliquer un concept avant de le nommer.

Partir d’un problème, décrire les différentes solutions envisagées, leurs avantages et inconvénients. Ce n’est qu’une fois que l’équipe a compris et adhéré à l’approche que l’on peut nommer cette dernière. Mais pourquoi fonctionner ainsi ?

Car derrière chaque pratique se cache des « buzzwords ». De mon expérience, ces derniers sont généralement perçus négativement, indépendamment de ce que les pratiques associées peuvent apporter (ou non). Entendre des termes « marketing » ou popularisés peut entrainer biais et préjugés, mais peuvent aussi générer des prises de décisions précipitées et sans réelles réflexion.

Par exemple, dans une équipe précédente, nous avions des problèmes de couplage fort entre les différentes couches de code d’un projet. Nous avons donc réfléchi aux différentes solutions possibles. Nous avons commencé à modifier l’architecture du projet. Séparer le fonctionnement de l’application, des règles à appliquer sans dépendre du framework que nous utilisions.

Le résultat ? Une architecture projet qui avait une adhésion naturelle de l’équipe. Chacun avait le « pourquoi » avant de connaitre le « comment ». Le nom de cette architecture: l’architecture hexagonale. Pourtant, nombreux sont les membres de l’équipe qui voyaient cette dernière comme inutilement complexe et sans intérêt.

Les buzzwords ne sont pas forcément le problème. Ils le deviennent quand ils biaisent la réflexion et qu’ils servent d’arguments d’autorité plutôt que de support à la conversation. Expliquer avant de nommer c’est comprendre ce qu’on souhaite mettre en place plutôt que de réagir sur la forme.

Et, comme j’aime souvent à le dire: « il est essentiel de comprendre les différents outils et pratiques, savoir pourquoi ils ont été créés » afin d’être en mesure de les challenger. C’est ainsi que l’on peut juger de leur bien-fondé dans une situation donnée.

Comment arbitrer les développements prioritaires ?

Wed, 15 Oct 2025 00:00:00 +0200

Comment arbitrer les développements prioritaires ? Quelles fonctionnalités prioriser ? La réponse à ces questions peut être trouvée dans le développement piloté par le métier (Domain Driven Design), qui nous propose des outils utiles permettant de classer les domaines métier selon trois catégories: Core, Support et Generic.

Le “core” correspond au cœur du métier. C’est ce qui différencie l’entreprise de ses concurrents. C’est l’aspect le plus important d’une entreprise. Il devrait idéalement être développé en interne avec une attention particulière à la qualité, l’innovation et la maintenabilité.

La catégorie support regroupe les fonctionnalités nécessaires au business, mais non différenciantes. On y retrouve des développements qui peuvent être externalisés ou mis en place avec des solutions clés en main.

Pour finir, la catégorie générique représente toutes les fonctionnalités standardisées, sans valeur stratégique et bien souvent semblable d’un outil à l’autre. Il est ici primordial d’utiliser des solutions existantes et des modules génériques. L’investissement doit être minime.

À chaque typologie de domaine métier doit correspondre un niveau d’effort et d’investissement à y consacrer. Prenez le recul nécessaire pour identifier où se situe réellement votre valeur ajoutée et allouez vos ressources en conséquence. C’est ainsi que se construira la cohérence de votre stratégie de développement.

Build vs Buy

Tue, 07 Oct 2025 00:00:00 +0200

Dans ma publication de la semaine dernière, j’évoquais le fait que la solution à un problème logiciel ne provient pas nécessairement du code. Mais concrètement, que cela signifie-t-il ?

Pour illustrer le propos, prenons un exemple concret: un logiciel de gestion pour lequel nous souhaitons mettre en place des tableaux de bord métier pour les utilisateurs. Création de graphiques, filtres dynamiques, export de données, gestion des droits d’accès, etc. Une charge de travail conséquente.

Pourtant, est-ce réellement nécessaire ? N’existe-t-il pas de solution existante et intégrable répondant à ce besoin ? C’est le genre de questions et de réflexions qui peut transformer des mois de développement en quelques semaines d’intégration.

C’est le concept du “build vs buy”, construire ou acheter. Et la réponse est moins simple qu’il n’y paraît puisqu’il y a de nombreuses variables à prendre en compte.

Si une équipe décide de construire une solution sur-mesure, il faut que cela représente un réel avantage concurrentiel, une différenciation forte. Idéalement, il faut que le développement se rapproche du cœur de métier de la solution. Si ce n’est pas le cas, c’est de l’investissement qui ne serait pas optimisé pour apporter une réelle valeur à l’utilisateur finale.

C’est une vraie décision stratégique à arbitrer et il est pourtant fort probable que le réflexe de toute équipe de développement sera de développer sa propre solution. C’est là que la prise de recul et une vision business suffisante sont indispensable pour faire la différence.

Les meilleures solutions ne proviennent parfois pas du code

Tue, 30 Sep 2025 00:00:00 +0200

Dans les équipes de développement, les meilleures solutions ne proviennent parfois pas du code.

Pour que cela soit possible, il faut pouvoir prendre le recul nécessaire. Il faut avoir la vision globale qui permet de comprendre le problème de fond et d’aller plus loin que ce qui est spécifié dans un ticket.

Comprendre la véritable douleur de l’utilisateur est clé. C’est aller chercher le “pourquoi” derrière le “quoi”. Cela s’avère difficile lorsque l’on court après la livraison de nouvelles fonctionnalités. Difficile de trouver la solution qui aura un impact maximum avec le moins de compromis.

Pour y parvenir, il faut des équipes avec un ownership élevé. Des équipes qui ne se contentent pas d’exécuter, mais qui questionnent et proposent. Des développeurs suffisamment proches du métier et du business pour en saisir les véritables enjeux.

C’est ainsi qu’on peut se rendre compte que la meilleure solution ne passe pas forcément par le code. L’impact d’un produit ne se traduit pas uniquement à travers les lignes de code qui sont nécessaires à son fonctionnement.

Et pour être proche du métier et du business, pas besoin d’assister à toutes les réunions orientées produit. Mais il est indispensable que les développeurs soient assez proches des product owners et des utilisateurs pour comprendre les douleurs rencontrées, ce qui permettra de proposer les meilleures solutions.

Le langage de programmation n'est qu'un outil pour arriver à ses fins

Sun, 28 Sep 2025 00:00:00 +0200

Cela fait plusieurs années que j’entends régulièrement “je suis développeur X” (insérer n’importe quel langage de programmation ou framework). Cette tendance à se définir par rapport à un langage ou framework spécifique est de plus en plus commune et n’est à mon sens pas sans conséquence.

Pour ma part, je considère que les langages de programmation et les frameworks ne sont que des outils permettant de résoudre des problèmes. Et comme tout outil, ils doivent être choisis en fonction de la tâche à accomplir. S’enfermer dans un écosystème et ne pas en sortir peut être un obstacle à notre croissance professionnelle.

Pourtant, cela me semble de plus en plus à contre-courant de “l’époque actuelle”. On retrouve aujourd’hui de nombreuses équipes projet travaillant avec les mêmes outils, indépendamment des spécificités du problème à résoudre. Toujours le même framework, toujours les mêmes outils, même quand ce dernier n’est pas le plus adapté au contexte.

Et tout cela n’est pas sans conséquence. Le risque étant de créer des solutions complexes ou inadaptées. J’ai vu des équipes refuser d’utiliser des librairies parce qu’elles attendaient des solutions proposées par les frameworks ne voulant pas dépendre d’autres composants. J’ai vu des développeurs mettre en place une usine à gaz pour utiliser des solutions types Symfony LiveComponents ou Laravel Livewire là où quelques lignes de JavaScript auraient suffi, uniquement pour rester le plus possible dans du code backend. Techniquement, ça fonctionne, mais ce n’est pas optimal. Et puis quand un problème survient, il est plus difficile à résoudre.

L’effet pervers de cette approche “framework-centrique” c’est aussi qu’actuellement de nombreux développeurs ne connaissent pas les fondamentaux du développement. Je ne parle pas de savoir faire du C (et jouer avec les pointeurs) mais, lors d’entretien de recrutement, je vois de nombreux développeurs exceller dans l’utilisation d’un framework et puis complètement perdus une fois que “l’on sort du cadre”.

Personnellement, je préfère privilégier une approche consistant à partir du problème pour aller vers une solution technique. On commence par identifier le besoin et quelles sont les contraintes du projet. C’est seulement une fois la réponse à ces questions que l’on peut commencer à se questionner sur quel langage et quel framework est le plus adapté. Et dans ce choix, bien entendu que les compétences de l’équipe qui va travailler dessus ont leur importance et peuvent influencer le choix final.

Cette philosophie rejoint d’ailleurs le principe que j’ai déjà évoqué dans ce blog: se concentrer sur les principes plutôt que sur la technologie. Les concepts fondamentaux du développement logiciel (architecture, patterns, bonnes pratiques) sont transversaux et peuvent s’appliquer indépendamment du langage utilisé.

Il est également important de noter que cette approche pragmatique ne doit pas conduire à l’anarchie technologique. Dans le contexte d’une équipe ou d’une entreprise, il est nécessaire de trouver un équilibre entre la diversité des outils et la cohérence de l’écosystème technique. L’objectif n’est pas d’utiliser un langage différent pour chaque projet, mais de faire des choix éclairés et justifiés.

Au-delà de tout ça, un développeur capable de s’adapter à différents langages et frameworks saura également s’adapter à tout type de situations, ce qui est un avantage non négligeable pour l’évolution de carrière.

Si vous n’aviez qu’une seule chose à retenir, c’est que notre métier consiste avant tout à résoudre des problèmes et à créer de la valeur pour les utilisateurs. Pour arriver à nos fins, nous avons une multitude de solutions pouvant être mises en place. Il est essentiel de choisir celle qui sera la plus adaptée à notre situation, que ce soit en choisissant un langage, un framework. Et pour cela, il est primordial de rester curieux, ouverts aux nouvelles technologies et surtout, de ne pas s’enfermer dans une seule approche technique.

Le meilleur outil est celui qui permet de résoudre efficacement le problème posé, pas celui que nous maîtrisons le mieux.

La loi de Conway

Tue, 23 Sep 2025 00:00:00 +0200

L’organisation interne d’une entreprise a un impact direct sur la manière dont y sont développés les outils. L’organisation et les interactions au sein des équipes influencent l’architecture des projets. C’est l’illustration de la loi de Conway.

La loi de Melvin Conway stipule que “toute organisation qui conçoit un système produira une conception qui est la copie de la structure de communication de cette organisation”.

J’ai déjà évoqué les problèmes qui peuvent être liés au découpage des équipes centrées sur des compétences techniques et qui à mon sens, tendent à générer des problématiques de communication et de performance de l’entreprise du fait d’une perte de vision d’ensemble.

Un exemple concret que l’on rencontre fréquemment est une organisation dans laquelle les équipes responsables du développement d’un projet sont séparées de celles qui en assurent le déploiement. Dans ce contexte, il est probable que l’on retrouve une scission entre le code du projet et le code associé à son déploiement (deux équipes = deux dépôts de code la plupart du temps).

Dans ce genre de situation, gérer la cohérence des deux dépôts demande beaucoup d’organisation, de rigueur et de communication. Cela peut s’avérer difficile, car les équipes étant séparées, chacun peut ne pas avoir conscience des problématiques des autres.

De plus, chaque équipe ayant ses propres objectifs, il est possible qu’elles ne partagent pas la même vision, ce qui peut nuire à la qualité du logiciel.

Dans ce cas, la loi de Conway nous enseigne que le développement logiciel n’est pas uniquement une histoire de code. Que pour améliorer la qualité et la déliverabilité d’un outil, il est essentiel d’aligner la structure organisationnelle de l’entreprise avec l’architecture souhaitée pour le produit.

You run it, You build it

Tue, 16 Sep 2025 00:00:00 +0200

Mon expérience a montré que les équipes qui assurent l’ensemble du cycle de vie d’un produit (de la conception au déploiement en passant par sa maintenance) obtiennent de meilleurs résultats et conçoivent des solutions de meilleure qualité.

C’est l’approche que l’on retrouve derrière le mantra “You build it, You run it”, central dans la culture DevOps. L’équipe qui développe un projet en assure son maintien opérationnel. Elle fait ainsi directement face aux différents problèmes d’exploitation, ceux rencontrés par les utilisateurs ainsi qu’aux incidents de production. Cette proximité incite naturellement chacun à s’engager dans une démarche d’amélioration continue.

Ce type de fonctionnement nécessite des équipes de développeurs pluridisciplinaires, autonomes et ayant de nombreuses compétences techniques et opérationnelles (conception, développement front & back, monitoring, gestion d’incident, sécurité …). Mais cette organisation responsabilise énormément les équipes techniques, améliore la qualité produit ainsi que la satisfaction client.

Cela permet de créer un cercle vertueux où l’équipe de développement est au plus proche de l’utilisation de son produit. Cette proximité permet d’obtenir au plus vite le résultat de son travail, accélérant ainsi la boucle de feedback permettant de se rendre compte plus rapidement de ses erreurs et d’itérer rapidement sur les solutions à mettre en place.

Dans ce mode de fonctionnement, il n’y a plus de retranscription des problèmes, ces derniers sont directement vécus par l’équipe. De ce fait, la qualité augmente non pas à cause des pratiques mises en place, mais parce que l’équipe vit avec ce qu’elle livre.

On ne peut pas améliorer ce que l'on ne mesure pas

Tue, 09 Sep 2025 00:00:00 +0200

Au cours de ma carrière, j’ai vu de nombreuses équipes de développement avancer en “mode tunnel”, à l’aveugle, avec comme seule vision la liste des tâches à accomplir. Pourtant, il est essentiel de regarder en arrière pour visualiser l’impact de notre travail.

Il est commun de dire que “l’on ne peut pas améliorer ce que l’on ne mesure pas” (Lord William Thomson KELVIN). On a parfois le sentiment d’avancer en réalisant de nombreuses tâches, mais sans mesurer l’impact de ces dernières, il est impossible de démontrer l’impact de notre travail.

C’est un des fondements du Lean Startup qui repose sur une boucle de feedback “Build - Measure - Learn”. Un processus itératif, où l’on expérimente en construisant notre produit, on collecte les données et/ou retours d’utilisation afin de persévérer dans la direction choisie ou au contraire effectuer un pivot.

Ne pas mesurer, ne pas avoir de données, c’est naviguer à l’aveugle. C’est supposer que le travail que l’on réalise apporte la valeur escomptée. C’est ne pas apprendre de ces erreurs et passer à côté du principe d’amélioration continue.

Idéalement, les outils de mesure nécessaire doivent être intégrés dès la conception. Il est primordial de définir les indicateurs de succès avant de partir tête baissée. Collecter les données, quantifier les objectifs et prendre le temps d’analyser les résultats une fois livrés.

En somme, nous parlons de comment travailler sur de l’amélioration continue de manière quantifiable, c’est remplacer l’intuition par des données chiffrées.

Partager sa vision

Tue, 19 Aug 2025 00:00:00 +0200

Après les congés d’été et avec la rentrée de septembre qui approche, c’est le bon moment pour définir ou repartager sa vision stratégique.

Trop souvent, les équipes se focalisent dans l’exécution et l’opérationnel sans avoir d’objectif ou de but à atteindre (autre que le développement de la fonctionnalité sur laquelle elles travaillent) perdant de vue la direction à suivre. La vision permet de (re)donner du sens aux équipes, elle permet de savoir pourquoi on travaille.

J’ai longtemps réfléchi à comment en mettre une en place, et je dirai que cela s’articule autour de 3 axes:

Décrire où l’on va afin de pouvoir prendre les bonnes décisions et de faire les choix techniques nécessaires et correspondant à l’objectif.
Planifier comment on y va afin de tracer le chemin pour y arriver et matérialiser des étapes concrètes.
Mesurer, suivre et ajuster si nécessaire. Aucune vision et planification n’est parfaite. Pouvoir suivre sa mise en place et rectifier en cours de route est indispensable.

Ces éléments sont d’autant plus importants quand une entreprise grandit afin de pouvoir aligner tout le monde et aller dans la même direction avec le même objectif.

La rentrée, c’est l’occasion de partager ses ambitions.

Testez votre documentation OpenAPI (avec PHP)

Mon, 28 Jul 2025 00:00:00 +0200

Il n’y a rien de plus frustrant que d’utiliser une API qui ne se comporte pas de la manière qui est décrite dans sa documentation. Nombreux sont les développeurs ayant déjà vécu cette situation. Et pour cause, maintenir une documentation précise et à jour peut s’avérer être une tâche complexe et laborieuse (et ce, même si cette dernière est générée automatiquement). Pour éviter ces désagréments, il est primordial de pouvoir comparer ce qui est décrit dans la documentation avec le comportement réel du code.

Dans le cadre d’une API, une partie de ce travail consiste à s’assurer de la conformité de la documentation OpenAPI. Une solution pouvant être mise en place consiste à intégrer la validation et la vérification de la documentation au sein de tests fonctionnels. L’objectif de cette approche est de vérifier que la requête HTTP effectuée, ainsi que la réponse retournée lors du test correspondent à ce qui est spécifié. Ainsi, si les tests s’exécutent à chaque modification du code, cela permettra de garantir que l’API se comporte bien tel que décrit dans la documentation OpenAPI tout au cours de la vie du projet.

Pour mettre en place ces tests dans un projet PHP, j’utilise généralement la bibliothèque league/openapi-psr7-validator qui permet de valider des requêtes et réponses HTTP par rapport à une spécification OpenAPI.

Pour faciliter leur intégration dans vos bases de code, je recommande généralement d’utiliser une classe abstraitre pour mutualiser le code de vérification nécessaire et qui sera dédié aux tests de l’API. Cela pourrait ressembler au code suivant:

// ...
use Symfony\Bundle\FrameworkBundle\KernelBrowser;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

abstract class ApiTestCase extends WebTestCase
{
    protected static KernelBrowser $client;

    protected function setUp(): void
    {
        parent::setUp();

        static::$client = static::createClient();
    }

    protected function makeRequest(
        string $method,
        string $uri,
        array $parameters = [],
        array $files = [],
        array $server = [],
        ?string $content = null,
        bool $changeHistory = true,
    ): Response {
        static::$client->request($method, $uri, $parameters, $files, $server, $content, $changeHistory);
        $response = static::$client->getResponse();

        // TODO: insérer le code de validation de la requête
        // TODO: insérer le code de validation de la réponse

        return $response;
    }
}

Le code précédent est basé sur l’utilisation du framework Symfony, mais sa logique est universelle. L’idée étant d’avoir une méthode dans laquelle on puisse faire un appel HTTP, récupérer la requête HTTP effectuée ainsi que la réponse retournée afin de pouvoir effectuer des contrôles sur ces dernières.

Ajoutons maintenant le code permettant d’effectuer la vérification des données avec la spécification OpenAPI.

// ...
use League\OpenAPIValidation\PSR7\OperationAddress;
use League\OpenAPIValidation\PSR7\ValidatorBuilder;
use Nyholm\Psr7\Request as Psr7Request;
use Nyholm\Psr7\Response as Psr7Response;

abstract class ApiTestCase extends WebTestCase
{
    private const OPENAPI_SPECIFICATION_FILE = '/path/to/specification.json';

    private static ?ValidatorBuilder $validatorBuilder = null;

    // ...

    protected function makeRequest(
        // ...
        bool $enableOpenApiSpecificationRequestCheck = true,
        bool $enableOpenApiSpecificationResponseCheck = true,
    ): Response {
        // ...

        if ($enableOpenApiSpecificationRequestCheck) {
            $this->validateOpenApiRequestSpecification($method, $uri, static::$client->getRequest());
        }

        if ($enableOpenApiSpecificationResponseCheck) {
            $this->validateOpenApiResponseSpecification($method, $uri, static::$client->getResponse());
        }

        return $response;
    }

    private function validateOpenApiRequestSpecification(string $method, string $endpoint, Request $request): void
    {
        $validator = $this->getValidatorBuilder()->getRequestValidator();
        $validator->validate(
            new Psr7Request(strtolower($method), $endpoint, $request->headers->all(), $request->getContent()),
        );
    }

    private function validateOpenApiResponseSpecification(string $method, string $endpoint, Response $response): void
    {
        $validator = $this->getValidatorBuilder()->getResponseValidator();
        $validator->validate(
            new OperationAddress($endpoint, strtolower($method)),
            new Psr7Response($response->getStatusCode(), $response->headers->all(), (string) $response->getContent()),
        );
    }

    private function getValidatorBuilder(): ValidatorBuilder
    {
        return self::$validatorBuilder ??= new ValidatorBuilder()->fromJsonFile(self::OPENAPI_SPECIFICATION_FILE);
    }
}

De cette manière, à chaque appel à votre API, vous avez la possibilité de vérifier la documentation qui lui est associée. Vous remarquerez au passage qu’il est possible de désactiver la vérification soit de la requête soit de la réponse. Si la désactivation de la vérification de la réponse peut-être discutable, pouvoir désactiver la vérification de la requête est indispensable pour pouvoir tester les cas d’erreurs avec des appels HTTP invalides (afin de pouvoir tester le comportement d’un client qui effectuerait un mauvais appel).

L’intégration de la validation OpenAPI dans vos tests fonctionnels vous permettra de faire “d’une pierre deux coups”: vous aurez la possibilité d’écrire des tests fonctionnels pour tester le comportement de votre code tout en permettant d’assurer sa cohérence avec votre documentation. Cette approche renforcera la qualité de votre API et évitera des désagréments auprès de vos utilisateurs. N’hésitez pas à adapter cette méthode à votre contexte et les différents frameworks que vous utilisez.

C'est quoi un test unitaire ?

Thu, 22 May 2025 00:00:00 +0200

Depuis que je fais de l’informatique, lorsque l’on parle de tests automatisés, je remarque que tout le monde a une définition différente de ce qu’est un test. Qu’ils soient dits unitaires, d’intégration, fonctionnels ou de bout en bout, je n’ai quasiment jamais vu deux équipes en avoir la même définition. J’aimerais ici donner une définition, la définition que j’adopte dorénavant et qui est actuellement partagée par les équipes avec lesquelles je travaille.

Les tests unitaires sont aujourd’hui considérés comme le Graal par les développeurs. Ce sont les tests qu’il faut absolument écrire. Considérés comme simples à écrire et rapides à s’exécuter, ils doivent permettre de s’assurer du bon fonctionnement d’une partie d’un projet. On les retrouve à la base de la fameuse pyramide des tests:

Un test unitaire est souvent défini comme une procédure automatisée qui vérifie le bon fonctionnement d’une unité de code. L’unité de code présente la plus petite partie testable d’une application. Cela est, la plupart du temps, une fonction, une méthode ou une classe. L’objectif étant de vérifier le comportement de chaque composant indépendamment du reste du système.

De mon point de vue et d’expérience, la définition précédente est ambigüe. Personne n’arrive réellement à définir ce qu’est une unité de code. Tout le monde donne sa propre définition et le résultat est de voir des débats interminables au sein des équipes de développeurs.

Parmi les questions que l’on se pose et qui ne trouvent pas de réponse universelle, doit-on bouchonner (mocker) tout élément extérieur au code que l’on teste ? Un test peut-il être considéré comme unitaire s’il utilise une instance d’une autre classe ? Cette question pourtant simple ne trouve pas de réponse unniverselle. Certains défendront l’idée qu’il faut isoler au maximum le code testé. D’autres pourront considérer qu’on peut voir l’ensemble comme une unité de code.

Dans les équipes avec lesquelles je travaille, nous nous sommes accordés sur une définition n’ayant que très peu d’ambigüité et qui mets l’ensemble des développeurs d’accord. Cette définition n’est pas unique et je l’ai également rencontré dans la formation de Charles DESNEUF sur les tests automatisés. Ainsi, actuellement, je considére qu’un test est unitaire s’il respecte les conditions suivantes:

s’il ne communique pas avec la base de données,
n’interagit pas avec le réseau,
ne touche pas au système de fichier,
peut s’exécuter en même temps que n’importe quel autre test unitaire,
ne nécessite pas de modification de l’environnement pour fonctionner.

L'IA comme catalyseur de création des side-projects

Tue, 20 May 2025 00:00:00 +0200

C’est une réalité indéniable, l’intelligence artificielle est désormais présente dans notre quotidien professionnel. Nous (développeurs) utilisons dorénavant de nombreux outils toujours plus puissants (ChatGPT, Claude, Cursor, Windsurf, …). Il en résulte que la création de projet devient désormais plus simple, plus rapide. En tant que développeurs, nous aimons explorer de nouvelles idées, tester de nouvelles technologies, expérimenter au travers de projets personnels (side project). L’arrivée des assistants intelligents nous permet désormais d’itérer et de créer de manière plus ou moins efficace.

Ce billet est là pour partager mon expérience, expliquer comment je tente de tirer profit de ces outils, que je considère aujourd’hui comme incontournables, pour créer les idées qui me passent par la tête.

Des idées de création d’outils, de sites Web, d’application, j’en ai régulièrement. Pour résoudre une problématique que moi ou des proches avons, pour expérimenter sur des outils ou technologies. Ce ne sont pas les sujets qui manquent, mais le temps (et parfois la motivation). J’ai aujourd’hui trouvé en l’IA, l’aide qui me permet de tester et itérer plus rapidement.

Généralement, je commence par mettre mon idée par écrit et je commence à itérer sur ce que j’aimerai mettre en place, les technologies que je souhaite utiliser. Pour commencer à lui faire prendre vie, je vais généralement démarrer un prototype avec V0 de Vercel. Si vous ne connaissez pas V0, il s’agit d’une plateforme de développement boosté à l’IA. Elle est conçue pour générer rapidement des interfaces utilisateurs (en React) à partir de descriptions en langage naturel.

À cette étape, je m’en sers vraiment comme prototype, l’objectif étant de commencer à matérialiser ce que j’ai en tête. Une fois suffisamment abouti et que je suis satisfait du résultat, je vais généralement demander à l’IA de dumper l’ensemble des écrans de l’application dans de purs fichiers HTML. Je ne fais pas de React, et je ne connais (aujourd’hui) pas suffisamment la technologie pour pouvoir travailler sereinement dessus. Pour moi, il est indispensable de comprendre ce que produit l’IA et les maquettes générées en HTML me permettent de créer l’outil dans une technologie que je vais maîtriser.

Pour la suite du développement du projet, je bascule sur Cursor. Ce dernier est l’un des éditeurs de code nouvelle génération les plus en vogue. C’est certainement l’un des outils que j’utilise et que j’explore le plus. Aujourd’hui, au travers de règles personnalisées (règle de développement, architecture), j’ai réussi à trouver un bon équilibre entre écriture de code et génération de code assisté. Habitué aux IDE de Jetbrains, revenir sur un éditeur type Visual Studio Code a demandé un peu d’adaptation, mais le gain de temps est aujourd’hui palpable. Cela nécessite de mettre en place quelques extensions pour avoir un éditeur aux petits oignons, mais ce fut également l’occasion de découvrir de nouveaux plugins, tels que cette extension “PHP Tools for Visual Studio Code” dédiée au langage PHP (qui reste aujourd’hui mon langage principal).

À titre d’information, j’aimerais sur mes prochains projets tenter de retourner sur un IDE Jetbrains et de tester Junie l’agent IA Jetbrains et/ou l’extension Windsurf.

En plus des deux outils dont je viens de parler, j’utilise aussi régulièrement Claude dans de nombreuses tâches. J’utilise beaucoup Claude comme un collègue avec qui je peux échanger, réfléchir ou être challengé sur des tâches de code ou des tâches/questions annexes. Je fais également de nombreuses recherches au travers de Perplexity, un moteur de recherche basé sur l’intelligence artificielle et qui, contrairement à des moteurs “classiques” ne va pas me retourner une simple liste de liens, mais fournit des réponses directes, sourcées et conversationnelles.

Et tout cela à quel coût ? Pas besoin de sortir son porte-monnaie pour profiter de la plupart des outils cités ici. La plupart, voire la totalité sont accessibles gratuitement si vous en avez une utilisation basique et peu intensive. Vous aurez la possibilité de sortir la carte bancaire pour les services que vous utilisez le plus et pour lesquels le plan gratuit ne vous suffirait pas.

Si au final, s’y mettre n’aura pas été une tâche facile, il n’est pas simple de changer ses habitudes, l’utilisation d’outils boostés à l’IA est en train de transformer de manière radicale la façon de développer. Concevoir des projets personnels n’a jamais autant été à la portée de tous. Moins de barrière à l’entrée, des temps de développement et d’idéation réduits permettent d’explorer de nombreuses idées.

Pour moi, l’IA est la révolution technologique incontournable. Si vous n’avez pas encore intégré ces outils dans votre quotidien, je vous encourage vivement à les explorer. D’autant plus, que je considère que ce sont des compétences qui vont devenir indispensables à l’avenir et que cela va directement influer sur votre employabilité.

Il est également important de noter que si l’IA va générer de plus en plus de code, qu’elle va résoudre des bugs et problèmes à notre place, il n’aura jamais été aussi important de comprendre les outils que l’on utilise, de comprendre ce qui est fait ou généré. Le risque étant à terme de perdre les compétences et la compréhension du système, rendant le fonctionnement, le débogage ou toute autre tâche impossible sans aide d’un outil tiers.

Évaluez la qualité de vos tests avec les tests de mutation

Sun, 11 May 2025 00:00:00 +0200

Très souvent, lorsque l’on souhaite mettre en place des indicateurs sur les tests d’un projet, la première mesure que l’on va mettre en place est celle de la couverture de code. Et pour beaucoup, il s’agit de la métrique principale permettant d’avoir une idée de qualité des tests d’un projet. Cette dernière sous-entend que plus la couverture est élevée et plus les tests assurent la sécurité du fonctionnement de notre code. Il s’agit pourtant d’un indicateur qui peut être trompeur.

Il s’agit d’un sujet que j’ai déjà abordé dans ce blog, expliquant que ce n’est pas parce qu’un test exécute une ligne de code que la vérification du comportement associé est efficace et pertinente. C’est dans ce cadre-là, qu’il est possible de mettre en place des tests de mutation (du mutation testing en anglais).

Les tests de mutation introduisent volontairement des défauts dans le code source d’un projet dans le but de vérifier si les tests permettent de détecter les changements de comportement introduits. Ces “défauts” sont appelés des “mutants” (d’où le nom de tests de mutation) et correspondent à des modifications mineures du code tentant de simuler des erreurs de programmation courantes. À la suite de l’exécution de ces tests, un score de mutation est retourné. Ce dernier représente le pourcentage de mutants tués. Plus le score est élevé, plus les tests sont efficaces pour détecter les erreurs.

Parmi les mutations les plus courantes, on retrouve:

le remplacement des opérateurs mathématiques: un + qui devient un -,
la modification des opérateurs de comparaison: une condition d’égalité === qui devient une négation !==,
la suppression de lignes de code,
la modification des valeurs booléennes: un true qui devient false,
la modification de valeurs de retour dans les fonctions.

Les tests de mutation permettent alors d’évaluer la capacité des tests à détecter des erreurs et pas simplement à exécuter du code. Ils mettent en évidence les parties du code où les tests sont insuffisants ou inefficaces. Cela permet ainsi d’ajouter des tests aux endroits les plus pertinents. Au final, ils permettent d’améliorer la confiance envers la suite de tests.

En PHP, l’outil le plus connu pour cela est certainement Infection. Ce dernier supporte PHPUnit, PhpSpec et Codeception, nécessite PHP 7.4 au minimum avec au moins une des extensions suivantes: Xdebug, phpdbg ou pcov installée. Son installation est extrêmement simple, puisqu’il suffira de faire un composer require --dev infection/infection. Une configuration de base sera automatiquement créée au premier lancement d’Infection permettant un démarrage extrêmement rapide.

Prenons un exemple simple pour illustrer le principe. Une classe Calculator qui permet d’effectuer des opérations de calcul:

class Calculator
{
    public function add(int $x, int $y): int
    {
        return $x + $y;
    }

    public function divide(int $x, int $y): float
    {
        if ($y === 0) {
            throw new \InvalidArgumentException('Division by zero is not allowed.');
        }

        return $x / $y;
    }
}

Cette classe est associée aux tests suivants:

use PHPUnit\Framework\TestCase;

final class CalculatorTest extends TestCase
{
    public function testAdd(): void
    {
        $addition = new Calculator();

        $result = $addition->add(2, 3);

        $this->assertEquals(5, $result);
    }

    public function testDivide(): void
    {
        $addition = new Calculator();

        $result = $addition->divide(6, 2);

        $this->assertEquals(3, $result);
    }
}

En lançant les tests de mutation (via la commande vendor/bin/infection), nous obtenons le rapport suivant:

Metrics:
   Mutation Score Indicator (MSI): 71%
   Mutation Code Coverage: 85%
   Covered Code MSI: 83%

Le Mutation Score Indicator représente le pourcentage de mutants tués par rapport au nombre total de mutants générés. Un mutant tué correspond à au moins un test qui échoue après l’application d’un mutant. Elle constitue la métrique principale des tests de mutation. Elle qui permet de mesurer l’efficacité des tests à détecter des erreurs. Le score doit alors être le plus élevé possible.

Le Mutation Code Coverage correspond au pourcentage de code parcouru par les tests de mutation. Cette métrique est similaire à la couverture de code “classique”, mais du point de vue des mutations.

La dernière métrique, le Covered code MSI est un calcul effectué uniquement sur le code couvert par les tests. Elle permet notamment d’isoler l’efficacité des tests existants. Cet indicateur répond à la question: “Parmi le code que mes tests exécutent, quelle est leur efficacité à détecter des erreurs”. Cet indicateur permet de détecter si vos tests sont suffisamment présents (indicateur élevé) ou si ces derniers ne permettent pas de détecter les problèmes de manière efficace (indicateur bas).

Pour améliorer le score des tests de mutation et par rebond la qualité de vos tests en général, il faudra tester tous les chemins d’exécution de votre code (incluant les cas limites et les exceptions). De plus, il ne faut pas se contenter de tester les cas nominaux, il est important de tester les cas d’erreurs.

Par exemple dans les tests que nous avons écrit précédemment, nous n’avons pas testé le cas d’erreur de la division par zéro. Modifions le code précédent, pour ajouter ce dernier:

use PHPUnit\Framework\TestCase;

final class CalculatorTest extends TestCase
{
    public function testAdd(): void
    {
        $addition = new Calculator();

        $result = $addition->add(2, 3);

        $this->assertEquals(5, $result);
    }

    public function testDivide(): void
    {
        $addition = new Calculator();

        $result = $addition->divide(6, 2);

        $this->assertEquals(3, $result);
    }

    public function testDivideByZero(): void
    {
        $addition = new Calculator();

        $this->expectException(\InvalidArgumentException::class);
        $this->expectExceptionMessage('Division by zero is not allowed.');

        $addition->divide(6, 0);
    }
}

Nous obtenons alors le résultat ci-dessous:

Metrics:
   Mutation Score Indicator (MSI): 100%
   Mutation Code Coverage: 100%
   Covered Code MSI: 100%

Si mettre en place un calcul de la couverture de code de vos tests est un bon premier point, si vous souhaitez aller plus loin et avoir une métrique pertinente pour avoir une idée de la qualité de vos tests, les tests de mutation sont une très bonne approche. Vous aurez alors les outils pour identifier et combler les “trous” de vos tests. Et comme toute solution, il sera nécessaire de prêter attention à quelques points.

Tout d’abord, il est important de noter que les tests de mutation sont des tests qui sont coûteux en termes de performance. La création et la mise en place de mutants sont consommatrices de ressources de calcul et de temps d’exécution. La génération de mutants peut ne pas être parfaite et peut ne pas changer le comportement observable du code. Dans ce dernier cas de figure, les mutants ne peuvent être tués, faussant ainsi le calcul final. On parle alors de “mutants équivalents”. Ces derniers entraînent alors de faux positifs, car ils ne changent pas réellement le comportement attendu.

La "Clean Architecture", bien plus qu'une arborescence de fichier

Fri, 18 Apr 2025 00:00:00 +0200

Une grande partie des projets informatique, que j’ai pu voir au cours de ma carrière, conçue autour d’une architecture hexagonale, était bien souvent plus proche d’une clean architecture en pratique. Cette dernière, est souvent découpée en plusieurs couches qui sont Domain, Application ou UseCase, Infrastructure et plus rarement UserInterface, sont une représentation physique des couches évoquées par Robert C. Martin qui a théorisé cette architecture.

Beaucoup sont attachés à la représentation physique de ces couches. Pour autant, la clean architecture ne se résume pas à un simple découpage du code. Le principe fondamental de cette architecture repose en réalité sur le sens des dépendances et non sur la matérialisation des couches du code.

Preuve en est, si vous prenez le livre de référence “Clean Architecture: A Craftsman’s Guide to Software Structure and Design: A Craftsman’s Guide to Software Structure and Design” (lien non affilié), sur les un peu plus de 370 pages du livre, 8 pages sont consacrées au découpage des couches représenté par le diagramme ci-dessous et qui pourtant sert à résumé ce qu’est la clean architecture dans 90% des articles du Web.

Les couches présentes sont généralement représentées par l’arborescence suivante:

.
└── src
    ├── ContexteMetier1
    │   ├── Application
    │   ├── Domain
    │   ├── Infrastructure
    │   └── UserInterface
    └── ContexteMetier2
        ├── Application
        ├── Domain
        ├── Infrastructure
        └── UserInterface

Et pour beaucoup, la clean architecture se résume à ce découpage.

Pourtant, comme je l’ai rapidement indiqué en introduction de ce billet, le principe fondamental de la clean architecture est le sens des dépendances, ces dernières devant pointer vers l’intérieur du cercle. Dis autrement, les couches métiers (Domain) contenant les règles métier ne doivent pas dépendre du code qui implémente les détails techniques (les couches extérieures). Concrètement, cela signifie que vos objets métiers (tel qu’une Commande ou une Facture) ne devraient avoir connaissance ni de l’ORM, ni du Framework utilisé. La couche Application qui orchestre les cas d’utilisation peut connaître les objets métier, mais reste indépendante des éléments d’infrastructure, tels que le client HTTP utilisé. Seule cette dernière couche, la couche se trouvant à l’extrémité des dépendances peut dépendre de frameworks et autres outils techniques (tel que Guzzle ou Symfony HTTP Client dans le cas d’un client HTTP).

Ce sens des dépendances est notamment illustré par le principe SOLID donc les différentes notions sont présentées de manière détaillée dans le livre. C’est le cas du principe d’inversion des dépendances qui contribue à la flexibilité et à la modularité du code face aux changements et aux évolutions du code.

Respecter les principes précédents permet de mieux découper et isoler la logique métier permettant de faciliter l’écriture des tests. Les éléments techniques étant isolés, il devient facile de remplacer une implémentation d’une base de données ou d’un composant technique offrant une résistance au changement. La compréhension du code est facilitée du fait que le cœur de l’application est mis en valeur par l’absence de bruit technique et se concentre sur ce qui a de la valeur pour le métier.

Si la clean architecture ne repose finalement pas sur une arborescence de dossier, cela reste néanmoins un outil pratique pour matérialiser, visualiser et se repérer dans les différents éléments du code. L’arborescence permet de rendre visible la séparation des différentes couches qui composent l’architecture. Elle permet de créer une convention d’équipe qui simplifie la revue du code, la collaboration entre développeurs et participe à l’uniformisation des pratiques. Elle permet également de faciliter la mise en place des contrôles de cohérence d’architecture avec des outils tels que Deptrac.

Ne résumez pas la clean architecture a une arborescence de fichier. Cherchez avant tout à isoler le métier des dépendances techniques. Créez une architecture et un code résilient face au changement et qui soit capable d’évoluer sans friction au cours du temps. Néanmoins, je reste convaincu qu’il est important que votre architecture puisse se rattacher à des principes et concepts de base et connu d’un grand nombre, permettant de trouver facilement de l’information dans la littérature.

Un projet cohérent sur le long terme grâce aux tests d'architecture

Tue, 15 Apr 2025 00:00:00 +0200

L’architecture d’un projet joue un rôle crucial dans sa maintenabilité et son évolution. Si généralement au début d’un projet, il est facile de bien structurer son code, l’ajout successif de nouvelles fonctionnalités, l’arrivée ou le passage de nouveaux développeurs peuvent dégrader la qualité des fondations du projet au cours du temps. C’est dans ce cadre que les tests d’architecture vont nous aider à documenter et à garantir la cohérence de notre architecture sur le long terme.

Les tests d’architecture permettent de vérifier que le code d’un projet respecte les règles et contraintes architecturales qui ont été définies. Ils sont là pour s’assurer que le code et ses interactions sont correctement structurés. Ils permettent de maintenir la cohérence du code au fil des évolutions. Si des règles sont enfreintes, les tests permettront de relever les erreurs.

De plus, ces tests pourront également servir de documentation, puisqu’il sera nécessaire de matérialiser explicitement les règles applicables. Cela permettra ainsi de faciliter l’intégration des nouveaux développeurs qui pourront prendre connaissance des règles d’architecture du projet tout en ayant un filet de sécurité qui les empêcheront de faire des erreurs.

Pour mettre en place ce type de tests, il existe une multitude d’outils. Je vais dans ce billet en présenter quelques-uns provenant de l’écosystème PHP.

Parmi les outils existants, l’un des plus anciens (et peut-être l’un des plus connus) est certainement Deptrac. Il s’agit d’un outil d’analyse statique qui permet de définir des règles de dépendance entre les différentes couches de code qui sont ensuite vérifiées par l’outil. La configuration s’effectue au travers d’un fichier YAML (ou PHP), comme celui-ci :

paths:
  - ./src
exclude_files:
  - '#.*test.*#'
layers:
  - name: Controller
    collectors:
      - type: className
        regex: .*\\Controller\\.*
  - name: Service
    collectors:
      - type: className
        regex: .*\\Service\\.*
  - name: Repository
    collectors:
      - type: className
        regex: .*\\Repository\\.*
ruleset:
  Controller:
    - Service
  Service:
    - Repository
  Repository: ~

On peut également présenter PHPArkitect comme alternative à Deptrac. Tout comme Deptrac, PHPArkitect permet de faire respecter les règles d’architecture. Ce dernier se distingue par son approche de configuration qui se veut expressive via du code PHP.

use Arkitect\ClassSet;
use Arkitect\CLI\Config;
use Arkitect\Expression\ForClasses\HaveNameMatching;
use Arkitect\Expression\ForClasses\NotHaveDependencyOutsideNamespace;
use Arkitect\Expression\ForClasses\ResideInOneOfTheseNamespaces;
use Arkitect\Rules\Rule;

return static function (Config $config): void {
    $mvcClassSet = ClassSet::fromDir(__DIR__.'/mvc', __DIR__.'/lib/my-lib/src');

    $rules = [];

    $rules[] = Rule::allClasses()
        ->that(new ResideInOneOfTheseNamespaces('App\Controller'))
        ->should(new HaveNameMatching('*Controller'))
        ->because('we want uniform naming');

    $rules[] = Rule::allClasses()
        ->that(new ResideInOneOfTheseNamespaces('App\Domain'))
        ->should(new NotHaveDependencyOutsideNamespace('App\Domain'))
        ->because('we want protect our domain');

    $config
        ->add($mvcClassSet, ...$rules);
};

Il existe également PHPat (alias PHP Architecture Tester) qui est un outil basé sur PHPStan. L’approche de configuration est très similaire à l’outil précédent, la différence essentielle étant que PHPArkitect peut fonctionner de manière autonome, alors que pour utiliser PHPat, il sera nécessaire d’installer PHPStan.

use PHPat\Selector\Selector;
use PHPat\Test\Builder\Rule;
use PHPat\Test\PHPat;
use App\Domain\SuperForbiddenClass;

final class MyFirstTest
{
    public function test_domain_does_not_depend_on_other_layers(): Rule
    {
        return PHPat::rule()
            ->classes(Selector::inNamespace('App\Domain'))
            ->shouldNotDependOn()
            ->classes(
                Selector::inNamespace('App\Application'),
                Selector::inNamespace('App\Infrastructure'),
                Selector::classname(SuperForbiddenClass::class),
                Selector::classname('/^SomeVendor\\\.*\\\ForbiddenSubfolder\\\.*/', true)
            )
            ->because('this will break our architecture, implement it another way! see /docs/howto.md');
    }
}

Le dernier outil que je vais présenter pour faire des tests d’architecture est Pest. Pest est un outil largement utilisé dans l’écosystème Laravel. S’il a été initialement conçu pour écrire des tests unitaires/fonctionnels, il permet également de vérifier les règles architecturales d’un projet. L’avantage d’utiliser ce dernier est d’avoir un outil qui permet à la fois de gérer vos tests unitaires et d’architecture en utilisant une syntaxe similaire.

arch()
    ->expect('App')
    ->toUseStrictTypes()
    ->not->toUse(['die', 'dd', 'dump']);
arch()
    ->expect('App\Models')
    ->toBeClasses()
    ->toExtend('Illuminate\Database\Eloquent\Model')
    ->toOnlyBeUsedIn('App\Repositories')
    ->ignoring('App\Models\User');
arch()
    ->expect('App\Http')
    ->toOnlyBeUsedIn('App\Http');
arch()
    ->expect('App\*\Traits')
    ->toBeTraits();
arch()->preset()->php();
arch()->preset()->security()->ignoring('md5');

Peu importe l’outil que vous utiliserez (ce n’est finalement qu’un détail d’implémentation), les tests d’architecture représentent une étape cruciale de vos pratiques de développement. Grâce aux outils présentés dans cet article, vous aurez la possibilité de garantir le respect de vos règles d’architecture, limitant ainsi les dérives naturelles qui arrivent au cours de la vie d’un projet.

En plus de la garantie que vos règles soient respectées, la mise en place de ce genre de tests vous permettra de rendre les règles explicites, pouvant ainsi servir de documentation. Le Graal étant bien entendu que ces tests soient lancés dans un environnement d’intégration continue.

Structurez votre code explicitement avec la "Screaming Architecture"

Mon, 07 Apr 2025 00:00:00 +0200

Vous est-il déjà arrivé d’ouvrir un projet, de regarder la structure de son code, l’organisation des différents répertoires et de n’avoir aucune information sur les fonctionnalités, les cas d’utilisation ou encore le métier géré par ce dernier ? En ce qui me concerne, c’est le cas de nombreux projets que j’ai pu voir, car bien souvent, la structure des projets est organisée par couches techniques orientées dont la structure dépendra généralement du framework utilisé. C’est exactement pour éviter ce genre de déconvenues qu’est né le concept de Screaming Architecture.

La Screaming Architecture (que l’on pourrait traduire par l’Architecture Criante en français) est un principe d’architecture logicielle théorisé par Robert C. Martin (alias Uncle Bob) et qui stipule que la structure de code d’un projet devrait révéler clairement l’intention et la fonction d’un logiciel sans avoir à entrer dans les détails d’implémentation.

Or, bien souvent, lorsque l’on démarre un nouveau projet avec son framework préféré, nous utilisons le squelette par défaut proposé par ce dernier. Par exemple, la structure d’un projet Symfony se présente généralement sous la forme suivante:

src
├── Command
├── Controller
├── DataFixtures
├── Entity
├── Event
├── EventSubscriber
├── Form
├── Pagination
├── Repository
├── Security
├── Twig
├── Utils
└── Kernel.php

Il serait préférable de regrouper les différents éléments au sein de dossiers représentant des contextes métier et fonctionnels, ce qui permettra de rendre plus facile la compréhension globale d’une fonctionnalité en évitant de devoir naviguer dans le code pour comprendre ou modifier un comportement.

src
├── Authentication
├── Inventory
├── Order
├── Reporting
├── Shipping
├── User
└── Kernel.php

Libre à vous ensuite, de choisir le découpage de chacun des contextes. Vous pouvez utiliser une structure orientée Clean Architecture ou architecture hexagonale, mais aussi du Vertical Slice ou un découpage plus courant en CRUD ou RAD. Le choix pouvant être fait selon les besoins et la complexité de chacun des contextes.

Ce mode de fonctionnement possède de nombreux avantages:

la structure révèle l’intention métier rendant l’organisation du projet plus expressive et facilitant la compréhension de ce dernier par un nouveau développeur,
le code devient un peu plus indépendant du framework car vous organisez votre code en fonction de votre métier et non pas en fonction de la couche technique que vous utilisez,
les détails d’implémentation sont relégués au second plan mettant en avant la logique métier.

Lorsque vous tentez de mettre en place une Screaming Architecture, le plus important est de commencer par vous focaliser sur les cas d’utilisation que vous allez résoudre. Séparez ces derniers autour de concepts métier sans réfléchir aux détails techniques.

La Screaming Architecture n’est pas seulement une façon d’organiser du code, c’est une philosophie qui place l’intention du logiciel au premier plan. Avec ce principe, créez des projets plus compréhensibles et maintenables. Attention cependant à ne pas tomber dans l’over engineering, ne multipliez pas les couches ou classes. Trouvez le bon équilibre entre principe de base et pragmatisme, c’est le secret de tous les projets qui durent.

Le principe d'Exponential Backoff

Tue, 18 Mar 2025 00:00:00 +0100

La majorité des applications modernes sont amenées à communiquer avec des systèmes tiers, tels que des services Web, des bases de données, des systèmes de messagerie ou de files d’attente, etc. Ces derniers peuvent rencontrer des pannes temporaires liées à des facteurs externes, perte de connexion réseau, pic d’activité ou panne entraînant une interruption temporaire de service. Un des moyens possibles permettant d’améliorer la résilience de nos projets est d’appliquer le principe d’exponential backoff.

L’exponential backoff est un algorithme qui est utilisé pour gérer les tentatives de reconnexion ou de réexécution d’une opération après un échec. Le principe consiste à effectuer plusieurs tentatives d’une opération en appliquant un temps d’attente entre chaque nouvelle tentative. Ce temps d’attente sera de plus en plus important après chacun des essais infructueux. Cette approche permet notamment de réduire la pression sur le système en défaillance et d’augmenter les chances de succès lors de défaillances temporaires.

Le principe de fonctionnement de base est très simple à mettre en place, puisqu’après chaque échec, on attend un délai qui va augmenter selon une fonction exponentielle avant de retenter l’opération. Cela peut se traduire par le code suivant: $delay = $initialDelay * ($factor ^ $attempt). Le délai augmentera ainsi jusqu’au nombre maximal de tentatives que vous souhaitez effectuer. Il peut également être intéressant de définir un nombre maximal de tentatives autorisées.

Les algorithmes d’exponential backoff permettent généralement de définir un paramètre nommé jitter. Il s’agit d’un élément aléatoire qui va permettre de faire varier le délai calculé afin d’éviter que plusieurs tentatives d’opérations simultanées n’aient lieu au même moment dans le cas de traitements effectués en parallèle. Incluant ce paramètre, la formule de calcul du délai d’attente pourrait être la suivante: $delayToApply = $delay * 1 + (mt_rand(-$jitter, $jitter)).

Une implémentation complète en PHP pourrait se traduire ainsi:

function executeExponentialBackoff(
    callable $fn,
    int $maximumAttempt = 5,
    int $initialDelay = 100,
    float $factor = 2,
    float $jitter = 0.25,
    int $maximumDelay = 30_000
) {
    $attempts = 0;

    while ($attempts < $maximumAttempt) {
        try {
            return $fn();
        } catch (Exception $e) {
            $attempts++;

            if ($attempts == $maximumAttempt) {
                throw new Exception("Failed after {$maximumAttempt} attempts: " . $e->getMessage());
            }

            $delay = min($initialDelay * pow($factor, $attempts - 1), $maximumDelay);

            $delayWithJitter = $delay * (1 + mt_rand(-$jitter * 100, $jitter * 100) / 100);

            $delayToApply = (int)($delayWithJitter * 1000);

            echo "Attempt {$attempts} failed. New attempt in " . round($delayWithJitter / 1000, 2) . "s\n";

            usleep($delayToApply);
        }
    }
}

Afin de pouvoir mettre en place ce mécanisme dans les meilleures conditions, il sera essentiel de veiller à ce que les opérations effectuées soient idempotentes et qu’elles puissent être exécutées plusieurs fois tout en ayant le même résultat à chaque appel. Il faudra également veiller à bien configurer les paramètres qui vont influer sur les temps d’attente.

L’exponential backoff est une technique à la fois simple et efficace. Elle est aujourd’hui mise en place dans de nombreux projets et est implémentée dans la plupart des frameworks. On retrouve par exemple ce principe dans Symfony ou encore Laravel. Mais il existe également des bibliothèques indépendantes, telles que eventsauce/backoff.

Les tests automatisés à eux seuls ne garantissent pas le bon fonctionnement de vos applications

Wed, 12 Mar 2025 00:00:00 +0100

Lorsque l’on commence à écrire des tests, nous avons souvent un sentiment de sécurité vis-à-vis du bon fonctionnement de nos applications. Une fonctionnalité a été conçue, une série de tests automatisés (qu’ils soient unitaires, fonctionnels, d’intégrations, parfois même en parallèle de tests manuels) a été mis en place. Tous les voyants sont au vert, vous êtes confiants, et pourtant, une fois en production… tout ne se passe pas comme attendu.

Il est indéniable qu’écrire des tests automatisés est essentiel lorsque l’on développe des projets informatiques. Ces derniers peuvent être joués à chaque modification d’un projet, participent à l’amélioration de la qualité et permettent de détecter des changements de comportement d’une application lors de modification dans le code.

Néanmoins, il est faux de penser qu’un projet avec des tests, indépendamment de leurs qualités, fonctionnera sans faille. La mise en place de tests ayant des limites.

Tout d’abord, le taux de couverture du code est un élément à prendre en compte lorsque l’on souhaite mesurer la qualité de nos tests. J’ai déjà évoqué la couverture de code dans ce blog, expliquant que c’est un indicateur à prendre avec précaution. Mais même avec la meilleure volonté du monde, il sera impossible de tester toutes les combinaisons possibles d’état de votre système.

Ensuite, quand on écrit des tests, de la même manière que lorsque l’on écrit du code applicatif, il est possible de faire des erreurs. Un test mal écrit, des jeux de données irréalistes, incomplets ou tout simplement biaisés peuvent aussi rendre nos tests imparfaits.

De plus, les tests sont généralement exécutés dans un environnement contrôlé ayant peu de dépendance avec l’extérieur. Les interactions avec des systèmes tiers sont généralement bouchonnées (mock en anglais). Cela crée un écart entre l’environnement de test et l’environnement réel d’exécution. Bien qu’il soit possible de créer des environnements au plus proches de la production, l’environnement et les conditions identiques de production ne pourront jamais être totalement rassemblés.

Et pour finir, si l’on considère que le développement d’une fonctionnalité résulte de la compréhension de cette dernière par le ou les développeurs qui l’implémente, alors une fonctionnalité mal comprise pourra entrainer l’écriture d’un test qui validera le fonctionnement compris sans pour autant répondre au besoin utilisateur.

Si les tests automatisés constituent un outil puissant, ils ne suffisent pas à garantir le bon fonctionnement d’une application. J’entends pourtant de nombreux développeurs garantir que leur développement est OK “parce qu’il est testé”. Certes les tests permettent de limiter les erreurs et les régressions, comme nous avons pu le voir, de nombreux facteurs sont à prendre en compte.

Des objets autovalidants avec le "Self-Validating Object" pattern

Sat, 01 Mar 2025 00:00:00 +0100

J’ai déjà évoqué dans ce blog la notion de cohérence des données au sein d’un modèle orienté objet. Ce principe est connu sous le nom de Self-Validating Object (objet autovalidant). On le retrouve également sous le nom de Validated Domain Object ou Invariant-Enforcing Object dans la littérature proche du Domain Driven Design. Il s’agit d’un modèle de conception consistant à ajouter une logique de validation directement dans les objets.

Cette approche possède de nombreux avantages. Tout d’abord, elle permet de garantir la cohérence des données, tout en renforçant l’encapsulation de nos objets, puisque ce sont ces derniers qui sont responsables de leurs propres validations. De plus, en cas d’erreur d’une donnée ou d’une règle de validation précise, il est possible de générer des erreurs précises.

Prenons un exemple. Le plus évident et commun est certainement celui du constructeur d’un objet. Nous allons donc modéliser un horaire que l’on va construire autour de 3 propriétés que sont: l’heure, la minute et la seconde.

readonly class Time
{
    public function __construct(
        public int $hour,
        public int $minute,
        public int $second,
    ) {
    }
}

Pour que l’objet soit autovalidant, nous allons y ajouter les contrôles nécessaires sur nos propriétés:

readonly class Time
{
    public function Time(
        public int $hour,
        public int $minute,
        public int $second,
    ) {
        if ($this->hour < 0 || $this->hour > 23) {
            throw new InvalidArgumentException("Hour value should be between 0 and 23: {$this->hour} given.");
        }

        if ($this->minute < 0 || $this->minute > 59) {
            throw new InvalidArgumentException("Minute value should be between 0 and 59: {$this->minute} given.");
        }

        if ($this->second < 0 || $this->second > 59) {
            throw new InvalidArgumentException("Second value should be between 0 and 59: {$this->second} given.");
        }
    }
}

La classe ci-dessus est autovalidate. Elle vérifie que les données qu’on lui donne correspondent effectivement à un horaire conforme. Dans le cas contraire, une exception est levée avec un message d’erreur explicite. Nous avons ici pris l’exemple d’un constructeur, mais le principe serait exactement le même sur une méthode de notre objet.

Il s’agit de l’implémentation la plus courante que l’on retrouve dans les bases de code. Elle est simple et rapide à mettre en place. Néanmoins, elle présente un inconvénient majeur: chaque donnée est validée individuellement, et la vérification s’arrête à la première erreur détectée. Ainsi, si on tente de créer l’instance new Time(25, 120, 0), on obtiendra d’abord l’erreur Hour value should be between 0 and 23: 25 given., mais sans aucune information sur les minutes, qui sont pourtant invalide. Ce n’est qu’après la correction de cette première erreur qu’on remarquera celle concernant les minutes.

Sur un objet simple comme celui que nous utilisons ici, ce n’est pas très grave, car il contient peu de propriétés. Cependant, sur des applications métiers plus complexes, cela peut s’avérer plus contraignant. L’idéal serait donc de mettre en place un mécanisme de validation permettant de vérifier l’intégrité de l’ensemble des données et de remonter l’ensemble des erreurs d’un seul coup. Nous pouvons alors imaginer un nouveau pattern.

Commençons par créer un conteneur pouvant stocker plusieurs erreurs:

class ValidationException extends InvalidArgumentException
{
    /**
     * @param list<string> $errors
     */
    public function __construct(
        string $message,
        public private(set) array $errors,
    ) {
        parent::__construct($message);
    }
}

L’idée est ensuite d’effectuer chacune des vérifications de nos propriétés en ajoutant les erreurs dans un tableau et lever l’exception précédente si ce dernier n’est pas vide:

readonly class Time
{
    public function __construct(
        public int $hour,
        public int $minute,
        public int $second,
    ) {
        $errors = [];
        if ($this->hour < 0 || $this->hour > 23) {
            $errors[] = "Hour value should be between 0 and 23: {$this->hour} given.";
        }

        if ($this->minute < 0 || $this->minute > 59) {
            $errors[] = "Minute value should be between 0 and 59: {$this->minute} given.";
        }

        if ($this->second < 0 || $this->second > 59) {
            $errors[] = "Second value should be between 0 and 59: {$this->second} given.";
        }

        if (!empty($errors)) {
            throw new ValidationException('Invalid time data.', $errors);
        }
    }
}

Maintenant, lorsque nous tentons d’instancier notre objet avec plusieurs propriétés invalides, nous obtenons une exception qui contient toutes les erreurs:

$time = new Time(25, 120, 0);

// class ValidationException#2 (8) {
//   protected $message =>
//   string(18) "Invalid time data."
//   public array $errors =>
//   array(2) {
//     [0] =>
//     string(38) "Hour value should be between 0 and 23: 25 given."
//     [1] =>
//     string(40) "Minute value should be between 0 and 59: 120 given."
//   }
// }

Ce mécanisme de validation peut être très intéressant même s’il est un peu plus complexe à mettre en place. Il fonctionne pour des objets ou structures de données relativement simples. Si un objet nécessite une validation contextuelle ou dépendante de plusieurs objets extérieurs, il sera peut-être préférable de sortir la logique de validation de l’objet lui-même.

Tester les implémentations d'une interface avec le "Behavioral Contract Testing"

Sun, 16 Feb 2025 00:00:00 +0100

Lorsque l’on doit écrire plusieurs implémentations d’une interface, il est crucial de veiller à ce qu’elles aient le même comportement. Par exemple, une interface PaymentProcessor permettant de s’interfacer avec plusieurs plateformes de paiements possède trois implémentations, il est important que chacune d’entre elles se comporte de la même manière. Pour cela, il est possible d’utiliser le principe du Behavioral Contract Testing.

Le Behavioral Contract Testing (qui est également appelé Interface Contract Testing) est un sous-ensemble du Contract Testing. C’est une technique de test qui permet de vérifier les contrats (ou interfaces dans notre cas) entre différents composants d’un système. Cette approche va nous permettre de garantir que le comportement de chaque implémentation va être identique, tout en mutualisant le code nécessaire à la mise en place des tests. Comme souvent avec les tests, le Contract Testing peut servir de documentation vivante, chacun des tests décrivant un comportement attendu.

Pennons maintenant un exemple concret: une abstraction permettant de gérer un système de cache. Commençons par définir notre contrat d’interface:

interface Cache
{
    public function get(string $key): mixed;

    public function set(string $key, mixed $value, ?int $ttl = null): void;

    public function delete(string $key): void;
}

Cette dernière pourrait être déclinée en de multiples implémentations, telles que: un cache mémoire, fichier ou encore en base de données…

final class InMemoryCache implements Cache
{
    // ...
}

final class FileCache implements Cache
{
    // ...
}

final class RedisCache implements Cache
{
    // ...
}

Mettre en place du Behavioral Contract Testing, c’est créer des tests qui vont être exécutés sur les différentes instances d’implémentations de notre interface. Nous allons donc commencer par définir la structure de nos tests au sein d’une classe de test abstraite:

abstract class CacheContractTest extends TestCase
{
    abstract protected function createCacheInstance(): Cache;

    public function testGetItem(): void
    {
        $cache = $this->createCacheInstance();

        // test implementation [...]
    }

    public function testCacheExpiration(): void
    {
        $cache = $this->createCacheInstance();

        // test implementation [...]
    }

    #[Test]
    public function testCacheDeletion(): void
    {
        $cache = $this->createCacheInstance();

        // test implementation [...]
    }

    // ...
}

Une fois notre classe abstraite définie, il faut créer les classes de tests correspondant à chacune des implémentations:

class InMemoryCacheTest extends CacheContractTest
{
    protected function createCacheInstance(): Cache
    {
        return new InMemoryCache();
    }
}

class FileCacheTest extends CacheContractTest
{
    protected function createCacheInstance(): Cache
    {
        return new FileCache(sys_get_temp_dir());
    }
}

class RedisCacheTest extends CacheContractTest
{
    protected function createCacheInstance(): Cache
    {
        return new RedisCache(/* ... */);
    }
}

Il ne vous restera plus qu’à exécuter les tests pour vous assurer que tout est OK.

Comme nous venons de le voir, mettre en place du Behavioral Contract Testing dans sa version la plus simple (et qui couvre un large cas d’utilisation) n’est pas quelque chose de compliqué. Et pourtant, c’est un mécanisme d’une grande puissante. Nous vérifions que chaque implémentation respecte et se comporte de manière identique pour un même contrat. Si cela s’avère nécessaire, il est également possible de gérer les cas particuliers de chaque type de cache dans sa classe de test respective.

La force de cette approche est également que, si vous avez besoin de créer une nouvelle implémentation de cache, cette dernière bénéficiera automatiquement de tous les tests que vous avez pu écrire en amonts.

Gérer des raccourcis clavier dans des projets Web

Wed, 12 Feb 2025 00:00:00 +0100

Il peut parfois être utile d’ajouter des raccourcis clavier dans nos applications Web afin de simplifier ou d’accélérer l’accès à certaines fonctionnalités. Mettre en place une gestion des raccourcis dans son projet est très facile : cela ne nécessite que quelques lignes de code JavaScript.

Il suffit pour cela de se brancher sur l’événement keydown qui est déclenché lorsque l’utilisateur appuie sur une touche du clavier. Ensuite, il faut vérifier les touches qui ont été enfoncées et lancer la fonction que vous souhaitez exécuter.

document.addEventListener('keydown', (event) => {
    if (
        event.shiftKey
        && event.key.toLowerCase() === 'u'
    ) {
        event.preventDefault();

        myFunc();
    }
});

Le code d’exemple ci-dessus vous permettra ainsi d’exécuter l’action de la fonction myFunc lorsque l’utilisateur presse à la fois la touche Shift et U. L’exécution de votre code se fera en désactivant le fonctionnement standard prévue par le navigateur (au travers de l’instruction event.preventDefault(); effectué en amont).

Le design pattern "Unit of Work"

Mon, 10 Feb 2025 00:00:00 +0100

Le design pattern Unit of Work est au cœur de nombreux projets du fait qu’il s’agit d’un modèle utilisé par de nombreux ORM (parmi lesquels on peut citer Hibernate pour Java, EntityFramework pour l’environnement Dotnet ou encore Doctrine pour PHP). Ce dernier a pour objectif de tenir à jour une liste d’objets et coordonne l’écriture des modifications en gérant les problèmes de concurrence.

Le cas des ORM (Object-Relational Mapping) est un cas d’école de l’utilisation de ce pattern. Lorsque l’on récupère des données (en base de données), qu’on les modifie, qu’on les supprime ou que l’on en insère des nouvelles, il est important de conserver une trace de ce qu’il s’est passé pour pouvoir ensuite les retranscrire dans la base de données.

L’avantage de l’Unit of Work est qu’il travaille par transaction. C’est-à-dire qu’il accumule les modifications pour ensuite les exécuter au moment voulu. De ce fait, si une erreur survient durant la transaction, toutes les modifications peuvent être annulées. Un autre avantage qui découle de la gestion transactionnelle est qu’il est alors possible de regrouper plusieurs opérations, réduisant ainsi le nombre d’accès à la base de données.

Dans sa version la plus simple, on pourrait définir une interface de travail comme celle-ci:

interface UnitOfWork
{
    public function registerNew(object $object): void;

    public function registerDirty(object $object): void;

    public function registerDeleted(object $object): void;

    public function commit(): void;
}

Et dont l’implémentation la plus simpliste pourrait ressembler à:

class UnitOfWorkImplementation implements UnitOfWork
{
    private array $newObjects = [];
    private array $dirtyObjects = [];
    private array $deletedObjects = [];

    public function __construct(
        private readonly Connection $db,
    ) {}

    public function registerNew(object $object): void
    {
        $this->newObjects[] = $object;
    }

    public function registerDirty(object $object): void
    {
        $this->dirtyObjects[] = $object;
    }

    public function registerDeleted(object $object): void
    {
        $this->deletedObjects[] = $object;
    }

    public function commit(): void
    {
        $this->db->beginTransaction();

        try {
            foreach ($this->newObjects as $object) {
                $this->insertIntoDb($object);
            }

            foreach ($this->dirtyObjects as $object) {
                $this->updateDbData($object);
            }

            foreach ($this->deletedObjects as $object) {
                $this->deleteFromDb($object);
            }

            $this->db->commitTransaction();

            $this->newObjects = [];
            $this->dirtyObjects = [];
            $this->deletedObjects = [];
        } catch (Exception $e) {
            $this->db->rollbackTransaction();

            throw $e;
        }
    }

    private function insertIntoDb(object $object): void
    {
        // ...
    }

    private function updateDbData(object $object): void
    {
        // ...
    }

    private function deleteFromDb(object $object): void
    {
        // ...
    }
}

C’est un des pattern décrit dans l’excellent livre de Martin Fowler Patterns of Enterprise Application Architecture (lien non affilié) qui date de 2002 mais qui contient l’essentiel des design patterns les plus populaire de nos jours.

Quelle différence entre le pattern CQS et CQRS ?

Mon, 03 Feb 2025 00:00:00 +0100

Ces dernières années, on a entendu de plus en plus souvent parler du pattern CQRS (pour Command Query Responsibility Segregation) du fait de sa démocratisation croissante. Mais on entend beaucoup moins parler du pattern CQS (pour Command Query Separation). Et pour cause, les deux concepts sont souvent assimilés à la même chose. Bien qu’ils partagent une même idée, il existe quelques différences fondamentales que nous allons voir dans ce billet.

Commençons par le pattern Command Query Separation (CQS). Ce dernier repose sur l’idée que chaque méthode/fonction de notre code doit soit modifier l’état du système (on parlera alors d’une commande), soit retourner une information (on parlera de requête), mais qu’aucune action ne devrait faire les deux à la fois.

J’avais déjà un peu évoqué cette notion dans un article précédent sur le nommage des messages dans le code.

Voici un exemple d’implémentation:

class OrderService
{
    // Command
    public function createOrder(string $customer, array $items): void
    {
        // ...
    }

    // Command
    public function addItemToOrder(string $orderId, string $productId, int $quantity, float $unitPrice): void
    {
        // ...
    }

    // Query
    public function getOrder(string $orderId): ?Order
    {
        // ...
    }
}

Même si d’un point de vue purement théorique, une commande ne doit pas retourner de données, il peut être pratique dans des cas précis d’enfreindre cette règle. C’est le cas des commandes qui vont créer une information en base de données et pour laquelle il est utile de pouvoir récupérer l’identifiant de la donnée qui a été insérée.

Si on reprend l’exemple précédent, la commande OrderService::createOrder pourrait être adaptée de cette manière:

class OrderService
{
    // Command
    public function createOrder(string $customer, array $items): int
    {
        $order = new Order(/* ... */);

        // ...

        return $order->getId();
    }

    // ....
}

Ce principe peut paraître simple et insignifiant, il est pourtant d’une efficacité redoutable et possède de nombreux avantages. Il permet de se concentrer sur la responsabilité unique de vos méthodes (le fameux S du principe S.O.L.I.D.). Ce qui permet de tendre à un code plus compréhensible (parce qu’il fait moins de choses) et facilitant ainsi la mise en place de tests.

De plus c’est une technique facile à mettre en place, il serait dommage de s’en priver.

Le pattern Command Query Responsibility Segregation (CQRS) peut quant à lui, être considéré comme une évolution du CQS puisque ce dernier reprend la même idée, mais en poussant le concept de séparation des lectures et des écritures au sein d’un système.

Reprenons notre exemple précédent de création de commande, cela reviendrait à avoir deux services distincts pour créer la commande et la récupérer:

// Command
class CreateOrderCommandService
{
    public function create(string $customer, array $items): int
    {
        $order = new Order(/* ... */);

        // ...

        return $order->getId();
    }
}

// Query
class GetOrderQueryService
{
    public function getOrderById(string $orderId): ?Order
    {
        // ...
    }
}

Comme on peut l’apercevoir dans l’exemple précédent, c’est un pattern plus lourd à mettre en place, puisqu’il va falloir découper le code plus finement. Néanmoins cette approche présente certains avantages très intéressants. Tout d’abord, le découpage supplémentaire permet de structurer son code tout en continuant de respecter le principe de responsabilité unique. Mais, la plus grande force du pattern CQRS est l’optimisation des performances qu’il est capable de mettre en place sur le projet.

En permettant de séparer lecture et écriture, il est possible de gérer chacun des modèles dans des tables, des bases de données, voire des moteurs de bases de données distincts. Si au démarrage d’un projet (le pragmatisme étant de rigueur), il est fort probable (et même conseillé pour éviter l’optimisation prématurée) que les commandes et les requêtes (au sens CQRS) tapent la même table de votre base de données, lorsque vous allez avoir de la volumétrie et/ou un trafic important, il sera intéressant de pouvoir mettre en place une version optimisée de chacun des modèles. Les écritures pouvant se faire dans une table relationnelle et les lectures sur une table dénormalisée par exemple. Suivant le niveau de performance requis, il est même possible de sortir un modèle dans une base de données distincte qui sera optimisé pour de la lecture. Faire ce travail de découpage est facilité avec ce pattern.

Cela permettra également par rebond d’améliorer votre scalabilité du fait que les opérations sont effectuées de manières séparées. Vous aurez ainsi la possibilité de faire évoluer les choses de manières indépendantes.

En résumé, CQS et CQRS sont des approches similaires qui vous permettent de tendre vers un code simple, découpé, tout en facilitant l’écriture de test. La mise en place des principes sous-jacents n’est pas complexe à mettre en place et peut être effectuée au démarrage d’un projet. Dans le cas du CQRS, on peut séparer les opérations de lecture et d’écriture dans le code, tout en partageant dans un premier temps les mêmes repositories qui manipulent une même table dans une base de données unique. Le découpage des modèles dans des tables ou des bases de données distinctes ne doit se faire qu’au fil du temps et des besoins d’un projet.

Chacune des approches a sa place et j’ai presque envie de dire que le CQS est un must have. Il y a juste une chose essentielle à retenir, c’est que la complexité du découpage de vos modèles doit se faire en fonction de vos besoins et non pas parce que vous souhaitez utiliser un principe jusqu’au bout.

Soyez pragmatique et ne soyez pas dogmatique!

La notion de message en programmation

Mon, 27 Jan 2025 00:00:00 +0100

Au début de l’informatique, le concept de message était assez large, désignant une transmission de données entre des objets (appels de fonctions, système événementiel, etc.). De nos jours, un message se définit plutôt comme une communication émise dans un bus (généralement asynchrone, mais pas exclusivement).

Bien qu’un message émis sur un bus soit un concept générique, il est important de le nommer correctement, comme tout élément du code. Tout comme il est préférable d’éviter de nommer des services de manière générique, tels que UserService ou ProductManager, il est important de nommer un message en fonction de sa responsabilité.

Partant de ce principe, on peut distinguer trois grandes familles de messages ayant chacune leur raison d’être :

Les commandes (Command): il s’agit de messages qui vont permettre de modifier l’état du système. Ces derniers sont généralement traités par un seul récepteur. Ce type de message est généralement nommé en commençant par un verbe permettant d’indiquer l’action qui va être effectuée (exemple: CreateClientAccount).
Les requêtes (Query): les requêtes permettent de lire et récupérer de la donnée. Tout comme les commandes, elles sont généralement également traitées par un seul récepteur et vont également commencer par un verbe (exemple: GetUsersListing).
Les événements (Event): ce dernier type de message permet d’indiquer que “quelque chose” s’est passé dans le système. Ils sont généralement nommés au participe passé et peuvent être gérés par plusieurs écouteurs (exemple: OrderShipped). Les événements peuvent également servir à la communication entre plusieurs systèmes informatiques.

Accordez une attention particulière au nommage de vos messages. Nommez ces derniers en fonction de leur intention et responsabilité et non pas en fonction de l’état de votre système. Cela permettra de rendre votre code plus explicite et donc plus facilement compréhensible.

Intégrer un moteur de recherche dans un site statique

Sat, 25 Jan 2025 00:00:00 +0100

Un moteur de recherche est disponible depuis quelques mois sur la page des articles de ce blog. Ce dernier étant généré par Jekyll, un générateur de sites statiques, mettre en place un moteur de recherche sur un site non dynamique n’est pas chose aisée. Heureusement, il existe Lunr.js: une bibliothèque JavaScript permettant de créer un moteur de recherche côté client.

L’utilisation de Lunr est très simple, puisqu’une fois l’avoir installé via NPM son utilisation va se passer en deux temps.

Dans un premier temps, il sera nécessaire de lui indiquer quels sont les éléments qui peuvent apparaître dans la recherche. C’est la phase d’indexation. Ensuite, nous allons utiliser la fonction lunr pour construire notre index en spécifiant sur quels champs de notre document la recherche va s’effectuer.

var idx = lunr(function () {
  // définition des champs qui seront utlisés lors de la recherche
  this.field('title')
  this.field('body')

  // ajout d'un document dans l'index
  this.add({
    "id": "1"
    "title": "Intégrer un moteur de recherche dans un site statique",
    "body": "Un moteur de recherche est disponible depuis quelques mois[...]",
    "url": "https://jdecool.fr/blog/2025/01/25/integrer-un-moteur-de-recherche-dans-un-site-statique.html",
  })
})

Après avoir créé l’index de notre moteur de recherche construit, il est alors possible d’appeler la fonction search lui transmettant les termes de la recherche. Le résultat contiendra la liste des documents correspondants avec un score correspondant à leur degré de pertinence.

[
  {
    "ref": "1",
    "score": 0.3535533905932737,
    "matchData": {
      "metadata": {
        "termes de la recherche": {
          "body": {}
        }
      }
    }
  },
  [...]
]

Un peu de HTML, de mise en forme et du JavaScript pour intégrer les données dans la page affichée et vous avez un moteur de recherche sur un site statique.

Les constructeurs nommés comme alternative aux constructeurs multiples en PHP

Mon, 20 Jan 2025 00:00:00 +0100

En PHP et, contrairement à d’autre langage, il n’est pas possible d’avoir plusieurs constructeurs dans une classe. Pouvoir définir plusieurs constructeurs peut-être intéressants dans de nombreux cas, comme par exemple, pouvoir construire un objet à partir de différents types de données. Si cela n’est pas possible en PHP, il est possible d’utiliser des constructeurs nommés pour avoir un fonctionnement similaire.

Mais qu’est-ce qu’un constructeur nommé? Il s’agit d’une méthode statique que l’on va pouvoir appeler afin de construire une instance de classe. Ces méthodes ont l’avantage d’être potentiellement plus explicites que le constructeur de base parce qu’elles vont pouvoir ajouter une sémantique lors de la construction de notre objet.

Prenons un premier exemple:

readonly class Color
{
    public function __construct(
        public int $red,
        public int $blue,
        public int $green,
    ) {}
}

Le code précédent définit un objet permettant de stocker une couleur. Cette dernière est composant d’un niveau de rouge, de bleu et de vert. Le constructeur principal permet ainsi de renseigner les valeurs correspondantes. Mais dans certains cas d’utilisation, nous pourrions avoir envie de créer une couleur depuis sa valeur hexadécimale. Pour cela, nous pouvons imaginer introduire un constructeur nommé fromHexCode pour réaliser cette tâche:

readonly class Color
{
    public static function fromHexCode(string $code): self
    {
        $code = ltrim($code, '#');

        $red = hexdec(substr($code, 0, 2));
        $blue = hexdec(substr($code, 2, 2));
        $green = hexdec(substr($code, 4, 2));

        return new self($red, $blue, $green);
    }

    public function __construct(
        public int $red,
        public int $blue,
        public int $green,
    ) {}
}

Les utilisations de constructeur nommé sont multiples et permettent de simplifier la création d’objets, de fournir des valeurs par défaut en fonction d’un contexte d’utilisation tout en encapsulant la logique de création potentiellement complexe au sein de l’objet lui-même. Cela améliore ainsi la lisibilité et la compréhension du code.

C’est également une technique appréciée en Domain Driven Design pour expliciter le processus métier qui a conduit à la création de la donnée. Prenons par exemple la création d’un utilisateur dans une application, nous pourrions imaginer la modélisation suivante:

class User
{
    public static function fromRegistration(string $name, string $email, string $password): self
    {
        $user = new self($name, $email, $password);

        // additionnal business logic related to registration

        return $user;
    }

    public static function fromSocialLogin(string $name, string $email): self
    {
        $user = new self($name, $email);

        // additionnal business logic related to social login

        return $user;
    }

    private function __construct(
        public string $name,
        public string $email,
        public ?string $password = null,
    ) {}
}

Ce dernier exemple définit une classe User avec un constructeur privé. Pour pouvoir créer une instance de notre objet, il sera nécessaire d’utiliser un des constructeurs nommés définis dans cette même classe. Le constructeur nommé à utiliser se fera en fonction du contexte métier dans lequel le traitement est effectué. Il y a ici un réel avantage à utiliser cette méthodologie, car elle permet de voir les éléments nécessaires à la création de notre utilisateur en fonction de l’action effectuée dans l’application.

Car si un utilisateur se doit d’avoir un nom, un email et potentiellement un mot de passe, le code précédent rend visible le fait qu’il est obligatoire de renseigner toutes ces informations dans le cas d’un enregistrement de l’utilisateur depuis notre projet, alors que le mot de passe n’est pas nécessaire dans le cas d’une connexion d’un réseau social.

Le concept de constructeur nommé est très puissant et peut se révéler extrêmement utile pour la maintenance et la compréhension d’une base de code. Le principe a été très brièvement introduit dans cet article et je vous recommande vivement de vous y intéresser plus en profondeur, ces derniers étant bien souvent sous-exploités.

Écrire une API idempotente (exemple en PHP avec Symfony)

Mon, 13 Jan 2025 00:00:00 +0100

D’après la RFC 9110 qui spécifie la sémantique d’une requête HTTP, une requête est considérée comme idempotente si elle peut être effectuée plusieurs fois et obtenir un résultat identique lors de chaque appel. Par exemple, si l’on tente d’accéder à une ressource REST GET /resource/42, deux appels à cet endpoint retourneront toujours le même résultat. Les appels GET à une API REST sont alors considérés comme idempotents (il en va de même pour des appels PUT ou DELETE par exemple). Mais ce n’est pas le cas d’un appel POST /resource qui créera alors une nouvelle ressource à chaque appel. Nous allons voir dans ce billet comment rendre un appel POST idempotent.

Pour rendre une API idempotente, il va falloir être en mesure d’identifier de manière unique un appel à une ressource. Généralement, le client API va générer une clé unique et l’ajouter à l’appel effectué. La clé est ensuite vérifiée par le serveur pour qu’il puisse savoir si la requête reçue a déjà été traitée ou non:

Si la clé n’est pas connue, le traitement va être effectué et le résultat sauvegardé avant de retourner la réponse HTTP.
Dans le cas contraire, le serveur va retourner la réponse précédemment enregistrée.

La plupart du temps, la clé d’idempotence est envoyée dans les en-têtes de l’appel HTTP afin d’éviter de polluer le corps de la requête.

Prenons par exemple, le code source d’une API permettant de créer un billet de blog:

class BlogController extends AbstractController
{
    #[Route('/api/articles', methods: ['POST'])]
    public function create(Request $request): JsonResponse
    {
        $post = new stdClass();
        $post->id = Uuid::v7();
        $post->title = $request->request->get('title', 'Default title');
        $post->createdAt = new DateTimeImmutable();
        // [...] enregistrement en base de données

        return new JsonResponse($post, JsonResponse::HTTP_CREATED);
    }
}

Comme expliqué précédemment, cette API n’est pas idempotente. Car si une même requête est effectuée deux fois de suite, un même article My awesome article sera ajouté en base de données.

Nous allons maintenant ajouter à notre API la gestion d’une clé permettant de s’assurer de l’unicité du traitement d’une requête. Cette clé doit être envoyée par le client dans une en-tête que nous nommerons X-Idempotent-Key. Cette clé sera stockée dans un système de cache (via le composant symfony/cache) pendant une durée d’une heure. Si la clé n’existe pas, elle sera créée et dans le cas contraire, la réponse du traitement de la requête sera renvoyée une nouvelle fois depuis les données mises en cache.

Cela pourrait conduire à l’implémentation suivante:

class BlogController extends AbstractController
{
    public function __construct(
        private readonly Psr\Cache\CacheItemPoolInterface $cache,
    ) {}

    #[Route('/api/blog', methods: ['POST'])]
    public function create(Request $request): JsonResponse
    {
        if (
            // si l'en-tête X-Idempotent-Key est présente
            ($idempotentKey = $request->headers->get('X-Idempotent-Key')) !== null

            // et que la donnée est en cache
            && ($postCache = $cache->getItem($idempotentKey))->isHit()
        ) {
            // on retourne la réponse présente dans le cache
            return new JsonResponse($postCache->get(), JsonResponse::HTTP_CREATED);
        }

        // dans le cas contraire, on effectue le traitement

        $post = new stdClass();
        $post->id = Uuid::v7();
        $post->title = $request->request->get('title', 'Default title');
        $post->createdAt = new DateTimeImmutable();
        // [...] enregistrement en base de données

        // dans le cas où la clé d'idempotence est définie
        if ($idempotentKey !== null) {
            // on enregistre le résultat du traitement en cache
            $item = $cache->getItem($idempotentKey);
            $item->set($post);
            $item->expiresAfter(3600)
            $cache->save($item);
        }

        return new JsonResponse($post, JsonResponse::HTTP_CREATED);
    }
}

De cette manière notre API pourra être idempotente, améliorant ainsi sa fiabilité ainsi que la cohérence des données du service. L’idempotence permet de garantir que les requêtes identiques produisent toujours le même résultat, évitant ainsi les doublons involontaires qui pourraient survenir en cas de problème réseau par exemple.

Faut-il mettre en place ce mécanisme partout ? Pas nécessairement. Focalisez les opérations les plus critiques de votre système et en particulier les opérations de modification de l’état de ce dernier.

Copier une image Docker d'une registry à une autre

Tue, 07 Jan 2025 00:00:00 +0100

J’ai récemment eu le besoin de copier plusieurs images d’une registry Docker à une autre. Bien que cette opération puisse sembler simple au premier abord, il y a quelques points auxquels il faut prêter attention.

La première solution à laquelle on pourrait penser serait de récupérer l’image sur sa machine afin de créer un nouveau tag pointant vers la registry de destination. Par exemple, si je souhaite copier l’image MySQL vers la registry Gitlab, je pourrais m’y prendre comme cela:

docker pull mysql:9.1.0-oracle
docker tag mysql:9.1.0-oracle registry.gitlab.com/jdecool/docker/mysql:9.1.0-oracle
docker push registry.gitlab.com/jdecool/docker/mysql:9.1.0-oracle

Le problème de cette approche est qu’elle va copier uniquement l’image récupérée par la machine qui effectue l’opération et qui est propre à son architecture. Dans le cas de l’image MySQL, si j’effectue l’opération depuis mon MacBook je ne copierai que la version ARM alors que, si je le fais depuis mon PC, je ne copierai que la version amd64.

Or, dans le cadre d’une migration, il est indispensable de prendre en compte les images multiarchitectures. Une solution envisageable serait de construire les images en mode multiarchitecture en se basant sur l’image d’origine. La commande docker buildx build permet par exemple de spécifier dynamiquement le contenu d’un Dockerfile. On peut alors modifier les commandes précédentes de la sorte:

docker buildx build --platform linux/amd64,linux/arm64/v8 \
  --tag registry.gitlab.com/jdecool/docker/mysql:9.1.0-oracle \
  --push \
  --build-context base=docker-image://mysql:9.1.0-oracle \
  - <<EOF
FROM base
EOF

Bien que verbeuse, cette solution est parfaitement fonctionnelle. Mais il est possible de se simplifier un peu la vie. Depuis peu, Docker a introduit une nouvelle fonctionnalité dans buildx permettant de copier directement les images entre Registry. L’opération peut alors être réalisée via une seule ligne de commande:

docker buildx imagetools create \
  --tag "registry.gitlab.com/jdecool/docker/mysql:9.1.0-oracle" "mysql:9.1.0-oracle"

Je n’ai évoqué dans ce billet que les outils officiels proposés par Docker, mais il existe également des outils créés par d’autres éditeurs et qui permettent également d’effectuer cette tâche.

Un environnement local Dockerisé en deux lignes de commande avec ddev

Wed, 06 Nov 2024 00:00:00 +0100

Construire un environnement de développement en local peut être fastidieux. Si l’on souhaite un environnement “natif”, il faudra installer tout le nécessaire en local. L’utilisation de machines virtuelles est pratique, mais gourmand en ressources matérielles. L’alternative à tout cela c’est bien évidemment les conteneurs qui ont été popularisés par Docker.

Néanmoins, tout n’est pas rose. Lorsqu’on travail sur de multiples projets, on peut se retrouver rapidement à copier/coller des configurations Docker Compose à droite et à gauche, ce qui peut ne pas être pratique. De plus, la configuration peut-être légèrement différente que l’on travaille sur Linux, Mac ou Windows ce qui ne facilite pas forcément le partage de configuration.

Mais c’était sans compter DDEV dont l’objectif est de simplifier la configuration des environnements locaux fonctionnant via des conteneurs.

Ddev offre une solution permettant de gérer des environnements locaux de développement entièrement conteneurisés de manière à ce qu’il ne soit pas nécessaire d’installer quoi que ce soit sur votre machine (mis à part Docker et Ddev lui-même). Disponible pour Linux, Mac & Windows, il est également capable de fonctionner dans des environnements cloud tels que Gitpod ou Github Codespaces.

Aussi simple que puissant, Ddev vous permettra en quelques lignes de commande d’installer, configurer et lancer tout le nécessaire au bon fonctionnement de votre projet PHP (de type CMS tel que Drupal ou WordPress, mais aussi vos projets Laravel, Symfony ou même CakePHP) ou Python (expérimental). Bien entendu, il ne se contente pas de fournir des images pour votre langage favori, au travers d’un système d’extension, vous aurez la possibilité d’ajouter à votre environnement un service préexistant (comme des CRONtab, de l’Elasticsearch, du Minio, des bases MongoDB ou Redis et même des systèmes de messages comme Beanstalk ou RabbitMQ) ou bien d’ajouter le vôtre.

En plus de toutes ces fonctionnalités, une fois le projet démarré, Ddev fournit une URL vous permettant d’accéder à ce dernier. L’expérience avec Docker, montre que bien souvent, nous autres développeurs avons des difficultés à gérer le mapping des droits entre notre conteneur et notre système de fichier. Là encore, tout est géré à notre place.

Pour ma part, Ddev commence à remplacer petit à petit l’environnement hybride que j’avais l’habitude de mettre en place à savoir un PHP natif installé sur machine et fonctionnement au travers de Symfony CLI qui était couplé avec des conteneurs Docker pour toutes les autres dépendances (base de données, RabbitMQ, gestion des emails…).

Vous n’êtes pas encore convaincu ? Je vous propose un petit test. Prenez 5 minutes pour installer Ddev. Une fois fait, je vous propose de créer le projet de démo de Symfony: symfony new ddev-demo --demo.

Puis pour configurer notre environnement, nous allons utiliser la commande ddev config et renseigner les différentes informations demandées:

$ cd ddev-demo
$ ddev config

Creating a new DDEV project config in the current directory (ddev-demo)
Once completed, your configuration will be written to ddev-demo/.ddev/config.yaml

Project name (ddev-demo): 'ddev-demo'

The docroot is the directory from which your site is served.
This is a relative path from your project root at ddev-demo
You may leave this value blank if your site files are in the project root

Docroot Location (public): 'public'
Found a php codebase at ddev-demo/public.

Project Type [backdrop, cakephp, craftcms, django4, drupal, drupal6, drupal7, laravel, magento, magento2, php, python, shopware6, silverstripe, typo3, wordpress] (php): 'php'

Configuration complete. You may now run 'ddev start'.

Il n’y a pas de projet type Symfony, nous nous contentons alors de spécifier le dossier public et d’indiquer qu’il s’agit d’un projet PHP.

Il ne reste maintenant plus qu’à démarrer notre environnement via la commande ddev start:

Starting ddev-demo...
 Container ddev-ssh-agent  Recreate
 Container ddev-ssh-agent  Recreated
 Container ddev-ssh-agent  Started
ssh-agent container is running: If you want to add authentication to the ssh-agent container, run 'ddev auth ssh' to enable your keys.
Building project images...
......Project images built in 6s.
 Network ddev-demo_default  Created
 Container ddev-demo-ddev-web  Created
 Container ddev-demo-ddev-db  Created
 Container ddev-demo-ddev-db  Started
 Container ddev-demo-ddev-web  Started
Waiting for containers to become ready: [web db]
Starting ddev-router if necessary...
 Container ddev-router  Created
 Container ddev-router  Started
Successfully started demo-ddev
Your project can be reached at https://demo-ddev.ddev.site
See 'ddev describe' for alternate URLs.

Vous avez maintenant un projet de démo fonctionnel au travers de l’URL https://demo-ddev.ddev.site

Bluffant non ?

Testez vos images Docker

Mon, 28 Oct 2024 00:00:00 +0100

Vous construisez des images Docker régulièrement ? Vous savez alors certainement que ce n’est pas parce que la construction de votre image s’est réalisée sans erreurs que cette dernière va se comporter comme vous vous y attendez. La construction d’une image Docker, tout comme n’importe quel code écris, doit être vérifiée et validée et pour cela, il est possible d’utiliser un outil qui va nous permettre de nous assurer du bon fonctionnement de notre image.

Pour ma part, l’outil que j’utilise se nomme Container Structure Test. Conçu par Google, il permet d’écrire des tests unitaires pour nos images Docker. Développé en Go, il est disponible sous la forme d’un binaire compatible sur la plupart des systèmes d’exploitation.

Grâce à Container Structure Test, vous aurez la possibilité de:

Exécuter des commandes à l’intérieur du conteneur et de vérifier la sortie ou l’erreur produite,
Tester l’existence d’un fichier
Vérifier le contenu d’un fichier (y compris la métadonnée qui lui est associée),
Et de vérifier la configuration du conteneur lui-même.

Une fois téléchargée, la mise en place des tests se fait via l’écriture de règle dans un fichier YAML. Voici par exemple, un exemple de configuration que j’utilise pour tester la construction d’image Docker faisant tourner des projets PHP:

schemaVersion: "2.0.0"

# Vérification de la présence de certaines variables d'environnement
globalEnvVars:
    - key: GITHUB_TOKEN
      value: github-token

commandTests:
    - name: "Symfony CLI installed"
      command: "which"
      args: ["symfony"]
      exitCode: 0
    - name: "Check PHP extensions"
      command: "php"
      args: ["-m"]
      expectedOutput:
          - "amqp"
          # ...


fileExistenceTests:
- name: 'Configuration PHP'
  path: 'etc/php/8.3/php.ini'
  shouldExist: false

fileContentTests:
- name: 'Linux Version'
  path: '/etc/os-release'
  expectedContents: ["VERSION_ID=3.14.2","NAME=\"Alpine Linux\""]

Une fois la configuration terminée, il ne vous reste plus qu’à exécuter les tests en spécifiant l’image à tester et la ou les configurations à prendre en compte:

container-structure-test test --image my-registry.jdecool.fr/php:8.3 --config php-tests.yaml

=======================================
====== Test file: php-tests.yaml ======
=======================================
=== RUN: Command Test: Symfony CLI installed
--- PASS
duration: 306.265278ms
stdout: [...]

=== RUN: Command Test: Check PHP extensions
--- PASS
duration: 303.302806ms
stdout: [...]

=== RUN: Command Test: Configuration PHP
--- PASS
duration: 276.503651ms
stdout: [...]

=== RUN: Command Test: Linux Version
duration: 276.503651ms
stdout: [...]

=======================================
=============== RESULTS ===============
=======================================
Passes:      4
Failures:    0
Duration:    789.707605ms
Total tests: 4

PASS

Le pattern Optional, le conteneur de valeur qui va remplacer vos données nullables

Fri, 25 Oct 2024 00:00:00 +0200

Nous manipulons tous au quotidien des données nullables, or manipuler des données qui peuvent être null implique de devoir effectuer de nombreuses vérifications afin de savoir si la donnée que l’on manipule contient bien une valeur avant de l’utiliser. Auquel cas, nous aurons une erreur de type:

PHP Warning:  Uncaught Error: Call to a member function method() on null in php shell code:1
Stack trace:
#0 {main}
  thrown in php shell code on line 1

Pour éviter l’utilisation de conditions de type if ($var !== null), il est possible d’utiliser le pattern Optional qui peut s’apparenter à la monade Maybe.

Un Optional est un conteneur permettant d’encapsuler une valeur qui peut être présente ou non. Ainsi, plutôt que d’utiliser une variable null pour représenter une valeur absente, nous allons pouvoir manipuler systématiquement un objet et appeler des méthodes sur ce dernier qui effectuera des opérations en fonction que la valeur soit présente ou non.

Prenons un exemple concret pour illustrer ce concept. Sur un site d’e-commerce, un événement est émis une fois un achat effectué par un utilisateur afin de lui envoyer un récapitulatif de sa commande. La gestion de l’envoi de l’email pourrait ressembler au code suivant:

class Customer
{
    public ?string $email;
}

readonly class OrderConfirmed
{
    public Customer $customer;
}

readonly class OrderNotification
{
    public function __construct(private EmailSender $email) {}

    public function sendConfirmatinEmailOnOrderConfirmed(OrderConfirmed $event): void
    {
        if ($event->getCustomer() == null) { // invite account
            return;
        }


        if ($event->getCustomer()->getEmail() == null) { // no email filled
            return;
        }

        $this->email->send($event->getCustomer()->getEmail(), 'Email content');
    }
}

Nous voyons dans ce cas d’exemple, qu’il est nécessaire de faire deux vérifications avant de pouvoir envoyer notre e-mail de confirmation:

Dans un premier temps, il est nécessaire de vérifier que la commande n’a pas été effectuée en “mode invité”, ce qui impliquerait d’avoir une commande sans notion d’acheteur,
Il est ensuite nécessaire de vérifier que l’on a bien une adresse de renseignée pour pouvoir envoyer l’e-mail.

Voyons maintenant ce que pourrait donner ce même code avec l’utilisation du pattern Optional:

class Customer
{
    /** @var Optional<string> */
    public Optional $email;
}

readonly class OrderConfirmed
{
    /** @var Optional<Customer> */
    public Optional $customer;
}

readonly class OrderNotification
{
    public function __construct(private EmailSender $email) {}

    public function sendConfirmatinEmailOnOrderConfirmed(OrderConfirmed $event): void
    {
        $event->customer
            ->flatMap(static fn (Customer $customer) => $customer->email)
            ->ifPresent(static fn (string $email) => $this->email->send($event->getCustomer()->getEmail(), 'Email content'));
    }
}

Dans cette seconde version, nous constatons que toutes nos vérifications (les if) ont été supprimées. Le code s’en retrouve plus concis et surtout se concentre sur les opérations utiles au traitement de l’envoi de notre e-mail, ce qui le rend plus expressif. Il n’est plus question de devoir vérifier si la donnée est présente ou non, la structure de données Optional va appliquer les transformations demandées uniquement si la valeur est présente et ne fait rien dans le cas contraire.

Les monades gagnant en popularité ces dernières années, on commence à voir des implémentations du pattern Optional directement dans les langages de programmation. Ce n’est (malheureusement) pas le cas en PHP. Mais on retrouve quelques implémentations sur Packagist.

Bien que son utilisation dans l’écosystème PHP reste marginale, à la vue des nombreux avantages qu’il représente, vous avez tout intérêt à regarder ça de plus près. Pour ma part, j’ai commencé à introduire cette notion en construisant ma propre implémentation qui se résume à quelques lignes de code.

Installer des extensions PHP facilement dans une image Docker

Wed, 23 Oct 2024 00:00:00 +0200

Si vous avez déjà construit des images Docker pour des applications ou projet PHP, vous avez certainement utilisé l’outil docker-php-ext-install. Ce dernier permet d’installer et configurer simplement des extensions PHP qui seront disponibles dans le conteneur. Néanmoins, cet outil se limite malheureusement aux extensions officielles fournies avec le langage.

Pour résoudre ce problème et permettre d’installer de nombreuses extensions PHP dans un conteneur Docker, il existe un outil disponible librement sur Github: mlocati/docker-php-extension-installer. Ce dernier met à disposition un script nommé install-php-extensions qui vous permettra d’installer et de configurer des extensions PHP au sein de votre image. À la différence du script officiel, il ne se limite pas aux seules extensions fournies directement avec PHP puisqu’il couvre un très large panel d’extensions parmi lesquelles: amqp, cassandra, ioncube_loader, jsonpath, newrelic, rdkafka, xdebug et bien d’autres encore.

Mais il permet d’aller encore plus loin en installer également les dépendances nécessaires à l’installation des extensions. Il installera par exemple la bibliothèque rabbitmq-c nécessaire au bon fonctionnement de l’extension amqp permettant entre autres de communiquer avec RabbitMQ.

Fonctionnant avec les images basées sur Debian et Alpine, vous aurez la possibilité d’installer les extensions pour les versions de 7.1 à 8.4 de PHP, de quoi couvrir un grand nombre de besoins et cas d’utilisation.

Et pour finir, voici un exemple d’utilisation:

FROM php:8.3-cli

ADD --chmod=0755 https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/

RUN install-php-extensions amqp gd xdebug

Si vous êtes passé à côté de cet outil et que vous utilisez encore une combinaison des utilitaires officiels et/ou pecl, je ne peux que vous encourager à tester cet outil.

Installer Cursor sur Ubuntu 24.04

Thu, 12 Sep 2024 00:00:00 +0200

Je ne sais pas pour vous, mais s’il y a bien un outil orienté IA dont j’entends beaucoup parlé en ce moment c’est bien Cursor, un fork de Visual Studio Code dont la promesse est de vous faire développez plus avec grâce à l’intelligence artificielle tout en restant dans un environnement connu. Par contre si comme moi, vous utilisez la version 24.04 d’Ubuntu, l’installation de l’outil peut ne pas se faire sans erreur.

Effectivement, bien que l’on se trouve avec un fichier de type AppImage (un format d’application portable) normalement voué à lancer une application facilement, vous avez certainement rencontré l’erreur suivante:

$ ./cursor-0.40.4x86_64.AppImage
[61312:0911/231002.352674:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_cursorlmVFH2/chrome-sandbox is owned by root and has mode 4755.
[1]    61312 trace trap (core dumped)  ./cursor-0.40.4x86_64.AppImage

Pour résoudre ce problème, je vous propose deux solutions. Visual Studio Code (et donc Cursor) sont basés sur Electron qui par défaut isole l’application dans un bac à sable. La dernière LTS d’Ubuntu (la 24.04 au moment de l’écriture de ce billet) ayant mis en place un nouveau mécanisme de sécurité, certaines applications n’ont pas encore fait les changements nécessaires pour leur bon fonctionnement. Heureusement il est possible de désactiver cette fonctionnalité en utilisant l’option --no-sandbox. Bien entendu cette dernière option n’est pas forcément conseillée étant donné qu’elle désactive des couches de sécurité.

Il existe heureusement une solution de contournement qui consiste à ajouter un fichier de configuration pour AppArmor, le logiciel de sécurité notamment utilisé par Ubuntu, permettant de lever la restriction sur la création de la sandbox nécessaire au bon fonctionnement de Cursor. Pour cela, il faudra créer un fichier /etc/apparmor.d/cursor-appimage avec le contenu ci-dessous (attention, vous devez modifier ce dernier afin de mettre à jour le chemin vers le fichier AppImage):

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile cursor /home/{YOUR-USER}/Applications/cursor*.AppImage flags=(unconfined) {
  userns,

  # Site-specific additions and overrides.  See local/README for details.
  include if exists <local/cursor>
}

Une fois fait, il ne reste plus qu’à informer apparmor de la présence de ce nouveau fichier via la commande: sudo apparmor_parser -r /etc/apparmor.d/cursor-appimage. Et voila, vous pouvez maintenant lancer Cursor sans problème.

À savoir également qu’une issue est ouverte auprès des équipes d’Anysphere et qui est à surveiller si vous souhaitez être informé de la correction de cette anomalie.

Comment récupérer le nombre d'erreurs ignorées dans une analyse PHPStan

Wed, 04 Sep 2024 00:00:00 +0200

Je travaille au quotidien avec PHPStan que ce soit pour mes projets personnels, mais également professionnels. Pour des projets complexes et ayant plusieurs années d’existence, il n’est pas rare d’ajouter des règles d’analyses graduellement afin d’éviter un trop grand nombre d’erreurs à corriger (ou à ignorer) d’un seul coup. Aussi dans une optique d’amélioration continue, il peut être intéressant de suivre le nombre d’erreurs ignorées afin de pouvoir s’assurer que le chiffre diminue (ou n’augmente pas de manière disproportionnée) au fil du temps.

Malheureusement, c’est une information que PHPStan ne permet pas de récupérer simplement.

J’ai donc cherché une solution, car c’est une métrique que je cherche à suivre. L’idée étant d’avoir une idée de l’état du code et de détecter si une équipe a tendance à ignorer des erreurs relevées par l’analyse statique ou si au contraire, elle est dans une optique d’amélioration continue du code.

Lors de mes recherches, j’ai trouvé le projet phpstan-baseline-analysis qui permet d’analyser une baseline PHPStan pour fournir un résumé de la typologie des erreurs qui sont présentes dans le fichier. C’est un outil intéressant, dont l’auteur Markus Staab, a publié un article pour présenter le projet. Bien qu’intéressant, il ne permet pas de déterminer le nombre d’erreurs réellement ignorées dans le projet. Se basant sur un fichier de configuration, le projet fait par exemple l’impasse sur les erreurs directement ignorées dans le code ou ne permet pas de compter avec précision les erreurs ignorées au travers d’une expression régulière.

Je me suis alors intéressé plus en détail au fonctionnement de PHPStan et à son mécanisme d’analyse. J’ai notamment pu découvrir le fonctionnement du système de cache. L’essentiel des informations est stocké dans un fichier unique (resultCache.php), lequel contient l’ensemble des erreurs détectées. Ainsi, en analysant le contenu du fichier, en lisant les informations telles que errorsCallback, locallyIgnoredErrorsCallback et linesToIgnore, il est possible de récupérer avec détails et précision, l’ensemble des erreurs présentes dans la base de code (et ainsi de pouvoir en extraire des métriques).

C’est ainsi qu’est né phpstan-report, une surcouche à PHPStan, capable de lancer une analyse et de lire le fichier de cache afin d’en extraire des métriques permettant de tracer et suivre l’évolution des erreurs de l’analyse statique.

Tester un bundle avec plusieurs versions de Symfony

Mon, 29 Jul 2024 00:00:00 +0200

Lorsque l’on travaille et maintient un bundle Symfony, il n’est pas rare de devoir gérer la compatibilité de ce dernier avec plusieurs versions du framework. Par exemple, au moment où je publie ces lignes, les versions 5.4, 6.4 et 7.1 sont officiellement maintenues. Exécuter sa batterie de tests automatisés sur plusieurs versions peut alors être fastidieux.

Le minimum que l’on puisse faire serait de tester le bundle en installant les dépendances Composer avec les options --prefer-stable et --prefer-lowest (pour récupérer les versions minimales des dépendances autorisées). Cela fonctionne, mais si une version du bundle supporte les trois versions courantes, ce dernier serait alors testé avec les versions 5.4 et 7.1.

Pour remédier à ce problème, on pourrait alors à l’installation des dépendances utiliser la commande composer require pour installer spécifiquement les versions désirées. Par exemple, si l’on souhaite installer une version 6.4, on pourrait utiliser la commande composer require symfony/framework-bundle:6.4.*. Cela fonctionne bien, mais peut rapidement être fastidieux si le nombre de dépendances Symfony est important.

Pour résoudre cette problématique, les équipes de Symfony ont intégré une fonctionnalité dans Symfony Flex permettant d’installer une version spécifique pour toutes les dépendances Symfony en une seule opération. Flex est une extension Composer bien connue des développeurs Symfony. Ainsi, pour mettre à jour vos dépendances sur une version spécifique, il vous suffira d’utiliser la variable d’environnement SYMFONY_REQUIRE.

Par exemple, la commande ci-dessous mettre toutes vos dépendances symfony/* en version 6.4:

$ SYMFONY_REQUIRE=6.4 composer update

À noter que symfony/flex peut être installé en tant que dépendance de votre projet, mais peut également être installé sur l’OS et donc en dehors de votre projet via la commande: composer global require --no-progress --no-scripts --no-plugins symfony/flex.

Cela vous permettra de grandement simplifier vos workflows d’intégration continue. Et pour conclure cet article, voici par exemple, une configuration Github Actions que vous pouvez utiliser sur vos projets:

name: Run tests
on: [ push ]
jobs:
    phpunit:
        runs-on: ubuntu-latest
        strategy:
            matrix:
                composer-prefs: [ '--prefer-stable', '--prefer-lowest' ]
                php-version: [ '8.2', '8.3' ]
                symfony-version: [ '5.4.*', '6.4.*', '7.1.*' ]
        name: 'PHPUnit - PHP/${{ matrix.php-version }} - SF/${{ matrix.symfony-version }} ${{ matrix.composer-prefs }}'
        steps:
            -   name: Checkout
                uses: actions/checkout@v2
            -   name: Setup PHP
                uses: shivammathur/setup-php@v2
                with:
                    php-version: ${{ matrix.php-version }}
                    coverage: xdebug
            -   run: composer global config --no-plugins allow-plugins.symfony/flex true
            -   run: composer global require --no-progress --no-scripts --no-plugins symfony/flex
            -   run: composer update --prefer-dist --no-interaction ${{ matrix.composer-prefs }}
                env:
                    SYMFONY_REQUIRE: ${{ matrix.symfony-version }}
            -   name: PHPUnit
                run: vendor/bin/phpunit

Le principe de verrouillage optimiste (optimistic locking) avec Doctrine ORM

Tue, 02 Jul 2024 00:00:00 +0200

Lorsque l’on travaille sur une application manipulant une base de données, il est possible de se retrouver dans un cas où une donnée va être modifiée par deux requêtes concurrentes. Cela peut-être problématique, car cela peut entraîner des incohérences dans les données d’un système.

Prenons l’exemple d’un système bancaire:

La première requête va récupérer le solde du compte du client (disons 100€), puis va effectuer un débit de 20€, il reste donc 80€ sur le compte du client.
La seconde requête va récupérer le solde du client (80€), puis va effectuer un débit de 50€, il restera donc 30€

Imaginons maintenant que les deux requêtes sont exécutées simultanément:

La requête 1 consulte le solde du compte: 100€
La requête 2 consulte le solde du compte avant que la requête 1 ne fasse l’opération de modification: 100€
La requête 1 débite le compte de 50€: il reste 50€
La requête 2 effectue le débit de 50€ sur le solde connu dans son contexte d’exécution (100€), il reste 50€

L’exemple précédent présente les problèmes d’incohérence de données que des requêtes simultanées peuvent introduire dans un système.

Pour corriger cela, la solution la plus simple et qui vient naturellement à l’esprit, est de vérouiller la donnée à manipuler le temps nécessaire à la réalisation des différentes opérations (consultation et débit) nécessaires au traitement. C’est ce que l’on appelle un verrouillage pessimiste (ou Pessimistic Locking en anglais), du fait que la donnée sera systématiquement verrouillée même s’il n’y a pas de requêtes concurrentes.

Cela pourrait être fait avec le pseudo-code ci-dessous:

function débiterCompte(string $numeroCompte)
{
    if ($this->isCompteVerrouiller($numeroCompte)) {
        throw new RuntimeException('Compte vérouiller');
    }

    $this->verrouillerCompte($numeroCompte);

    // ... on fait les traitements nécessaires ...

    $this->déverrouillerCompte($numeroCompte);
}

Si l’on travaille en PHP avec Doctrine ORM ce dernier met à disposition plusieurs méthodes permettant de mettre en place cette stratégie de verrouillage:

EntityManager::find($className, $id, LockMode::PESSIMISTIC_WRITE|LockMode::PESSIMISTIC_READ)
EntityManager::lock($entity, LockMode::PESSIMISTIC_WRITE|LockMode::PESSIMISTIC_READ)
EntityManager::refresh($entity, LockMode::PESSIMISTIC_WRITE|LockMode::PESSIMISTIC_READ
Query::setLockMode(LockMode::PESSIMISTIC_WRITE|LockMode::PESSIMISTIC_READ)

Cette approche est très simple. Elle est également rapide à mettre en place. Mais elle présente l’inconvénient de verrouiller l’accès à une donnée durant tout le temps du process de modification, et cela de manière potentiellement inutile. Si dans des traitements simple et rapide cela n’est pas un problème, sur des traitements nécessitant des calculs importants, verrouiller la donnée peut générer de potentiels incidents.

Pour éviter ces problèmes, il est possible de mettre en place un verrouillage optimiste (on parle alors d’optimistic locking en anglais) des données. Il n’est alors plus question de verrouiller une donnée de manière systématique. Le principe de fonctionnement est le suivant:

La requête va récupérer les informations dont elle a besoin en base de données. Les informations contiennent un numéro de version de la donnée (cela peut correspondre à un numéro, une date…),
La requête modifie les données nécessaires au traitement effectué,
Au moment de valider les modifications et de les enregistrer définitivement, une vérification du numéro de version va être effectuée afin de s’assurer qu’aucune donnée n’a été modifiée par une autre requête durant le traitement:
- Si la version ne correspond pas à l’état de la base de données, une erreur est renvoyée,
- Sinon, les modifications sont validées et persistées en base de données.

Ici encore, si vous utilisez un ORM, ce dernier offre les outils nécessaires pour vous simplifier le travail et vous éviter d’avoir à gérer cela manuellement. Avec Doctrine ORM, cela se fait simplement en ajoutant la métadonnée Version à la propriété correspondante de votre entité.

class CompteBancaire
{
    // ...

    #[Version, Column(type: 'integer')]
    private int $version;
}

Quelle différence entre DateTime et DateTimeImmutable en PHP ?

Mon, 27 May 2024 00:00:00 +0200

Il existe en PHP deux classes pour gérer et manipuler nativement les dates: DateTime et DateTimeImmutable. Je me rends compte que de nombreux développeurs ne maîtrisent pas la différence entre les deux notions. Ce billet est l’occasion de voir pourquoi et dans quel cas utiliser l’un ou l’autre.

Comme leur nom peut l’indiquer, la différence de fonctionnement est relative à la mutabilité de l’objet manipulé. Dans le cas de DateTime, l’instance de notre objet sera mutable. Cela signifie que la valeur de ce dernier peut être modifiée après sa création. Prenons le bout de code suivant qui va calculer une date prévisionnelle d’envoi d’une commande:

function getExpectedShippingDate(DateTime $orderDate): DateTime {
    return $orderDate->add(DateInterval::createFromDateString('3 day'));
}

$orderDate = new DateTime('2024-05-27');
$shippingDate = getExpectedShippingDate($orderDate);

// $orderDate = 2024-05-30
// $shippingDate = 2024-05-30

Dans l’exemple précédent, on peut voir que l’appel à la méthode getExpectedShippingDate a modifié la valeur de la date de notre objet $orderDate. En PHP les objets étant passés par référence et une instance de DateTime étant mutable, toute modification effectuée sur notre objet dans un bloc de code modifie la valeur de ce dernier dans le reste du code.

Pour éviter ce problème, vous l’aurez deviné, il faut utiliser une instance de DateTimeImmutable. Reprenons le code de notre fonction de calcul de la date prévisionnel d’envoi d’une commande:

function getExpectedShippingDate(DateTimeImmutable $orderDate): DateTimeImmutable {
    return $orderDate->add(DateInterval::createFromDateString('3 day'));
}

$orderDate = new DateTimeImmutable('2024-05-27');
$shippingDate = getExpectedShippingDate($orderDate);

// $orderDate = 2024-05-27
// $shippingDate = 2024-05-30

Contrairement à une instance de DateTime, DateTimeImmutable est un objet immuable. Cela signifie que lorsqu’une opération est effectuée sur ce dernier, PHP ne va pas modifier la valeur courante l’objet. Le moteur va créer une nouvelle instance de date avec la bonne valeur et la renvoyer comme résultat de la fonction. De ce fait, notre date $orderDate conserve sa valeur d’origine.

À partir de là, la question que l’on est en droit de se poser maintenant est: dans quel cas utiliser l’un ou l’autre ? Au risque de paraître un peu extrémiste, mon avis est que l’on ne devrait jamais utiliser DateTime. Le risque de créer un effet de bord est trop important, sans compter la difficulté à retrouver l’origine du problème. L’utilisation de DateTime étant à mon sens à proscrire, vous devriez systématiquement utiliser DateTimeImmutable.

Gérer les décisions d'architectures dans les projets

Mon, 13 May 2024 00:00:00 +0200

On me demande régulièrement comment sont gérées les décisions (et le suivi) d’architectures que l’on est amené à prendre dans les projets sur lesquels j’interviens. Dans la plupart des cas, cela va se dérouler en deux phases: la communication et le suivi.

La première étape que j’ai nommée “la communication” se fait en deux temps. Elle commence tout d’abord par une discussion d’équipe (ou des acteurs concernés) dans laquelle sont évoquées la ou les problématiques qui sont rencontrées. Cette discussion (réalisée de manière synchrone ou asynchrone) permet de s’aligner sur le problème rencontré, d’échanger sur les solutions qui peuvent être envisagées. Une fois ce travail réalisé, l’équipe pourra se mettre d’accord sur la solution finale à adopter.

Il est important de noter que l’ensemble des échanges doivent être tracés au sein d’un ADR (Architecture Decision Record) afin de conserver l’historique des échanges, discussions, contexte du problème, solutions envisagées et d’expliquer comment l’équipe (à cette date) en est arrivée à la solution convenue.

Une fois tout le travail de recherche et de concertation réalisé, l’équipe va alors pouvoir commencer à implémenter la solution finale. Se pose alors la question du suivi. Comment suivre et faire respecter la décision d’architecture qui a été prise ?

Au sein d’une équipe qui travaille avec de la revue de code, la première idée qui nous vient naturellement en tête est que l’équipe devra alors “faire attention” lors de la relecture du code. C’est une première étape, mais elle a l’inconvénient de reposer uniquement sur l’humain. Or, s’assurer du respect de toutes les règles qui ont été établies peut-être un véritable défi sur des projets d’envergures.

C’est pour cela que nous tentons (avec les équipes) d’automatiser au maximum la vérification des règles mises en place. Et pour cela, un certain nombre d’outils sont disponibles en fonction des besoins. Les principaux étant:

Deptrac: un outil qui va vérifier les dépendances et les interactions entre les différentes couches d’un projet pour s’assurer du respect des règles de couplages. Dans le cadre d’une Clean Architecture, nous pouvons vérifier les dépendances entre les couches Domain, Application, Infrastructure et Presentation ,
PHP CS Fixer: pour tout ce qui est vérification (et correction automatique) des règles liées aux conventions de nommages du code,
PHPStan: principalement conçu pour analyser le code PHP et détecter erreurs et problèmes dans le code, nous l’utilisons pour écrire des règles personnalisées pour vérifier des règles d’architectures qui ne peuvent être réalisées par les outils précédents.

Retrouvez ma veille sur Mastodon & Bluesky

Mon, 06 May 2024 00:00:00 +0200

Cela fait maintenant plusieurs années que je partage presque quotidiennement ma veille sur X (Twitter). Du lundi au vendredi, généralement entre 9h et 10h, je diffuse jusqu’à 5 publications sur le thème de développement et de l’informatique.

Malheureusement, ces derniers temps, l’écosystème Twitter s’est dégradé et de plus en plus de personnes se tournent vers de nouvelles alternatives.

C’est pour cela que depuis peu, l’ensemble de ma veille est maintenant également diffusé sur Mastodon et Bluesky.

Au plaisir de vous y retrouver.

Non, vous ne faites pas de la programmation objet

Sun, 05 May 2024 00:00:00 +0200

Si vous posez la question à n’importe quel développeur, il vous répondra très certainement que oui, il fait bien de la programmation orientée objet. Effectivement, les langages de développement les plus utilisés actuellement tels que Python, C++, Java, C#, JavaScript, PHP ou encore Ruby permettent d’écrire des objets et de nombreux frameworks utilisent ces notions pour fonctionner. Est-ce pour autant que l’on fait réellement de la programmation orientée objet ?

Pour moi la réponse est clairement non. Ce n’est pas parce que l’on écrit des classes et que l’on peut les instancier, que l’on fait de la programmation orientée objet. Le fondement de ce paradigme, c’est l’encapsulation. Il s’agit du principe qui fait qu’un objet n’est pas une simple structure de données. Un objet c’est l’association de données (les propriétés d’une classe) et des comportements (les méthodes) applicables à ce dernier.

Pourtant, la majorité des frameworks et des ORM (Object-Relational Mapping) nous ont habitués à avoir et à créer des objets dénués de sens. On se contente bien souvent de classes qui contiennent des propriétés que l’on définit et récupère unitairement sans sémantique particulière comme dans l’exemple suivant:

class User
{
    private string $username;
    private string $passwordHash;
    /** @var string[] $bans */
    private array $bans;

    public function getUsername(): string
    {
        return $this->username;
    }

    public function setUsername(string $username): void
    {
        $this->username = $username;
    }

    public function getPasswordHash(): string
    {
        return $this->passwordHash;
    }

    public function setPasswordHash(string $passwordHash): void
    {
        $this->passwordHash = $passwordHash;
    }

    /**
     * @return string[]
     */
    public function getBans(): array
    {
        return $this->bans;
    }

    public function addBan(Ban $ban): void
    {
        $this->bans[] = $ban;
    }
}

Des objets avec uniquement des getters et des setters. Même le constructeur semble oublié. C’est ce que l’on appelle des modèles anémiques.

C’est pour moi le point le plus négatif des développeurs à l’heure actuelle, car au-delà de ne pas respecter le paradigme initial, cela entraîne également une perte de sens dans le code de nos projets. Et non, modéliser nos objets ainsi ça ne vient pas du DDD (Domain Driven Design) comme j’ai pu l’entendre. Faire des objets qui mutent et qui ont des modèles riches, c’est le principe de base de la programmation objet. Le DDD ne fait que s’appuyer sur ces fondements.

Lorsque vous écrivez vos objets, pensez comportement. Écrivez des objets riches, appuyez-vous sur des mutations, utilisez des DTO (Data Transfer Object) si nécessaire. L’utilisation de getters et setters devrait être une exception. Implémentez des méthodes qui représentent le comportement de vos objets.

Si l’on reprend l’exemple précédent, ce dernier pourrait être modifié ainsi:

class User
{
    public function __construct(
        private string $username,
        private string $passwordHash,
        private array $bans = [],
    ) {
    }

    public function toNickname(): string
    {
        return $this->username;
    }

    public function authenticate(string $password, callable $checkHash): bool
    {
        return $checkHash($password, $this->passwordHash) && ! $this->hasActiveBans();
    }

    public function changePassword(string $password, callable $hash): void
    {
        $this->passwordHash = $hash($password);
    }

    public function ban(\DateInterval $duration): void
    {
        assert($duration->invert !== 1);

        $this->bans[] = new Ban($this);
    }
}

Cet exemple, aussi court puisse-t-il être, condense de nombreux concepts:

Un constructeur pour initialiser les propriétés obligatoires,
Des accesseurs métier qui permettent d’accéder uniquement aux informations utiles en dehors de l’objet,
Des mutations qui permettent de modifier l’état de notre objet en s’assurant que toutes les propriétés liées à un comportement soient spécifiées.

Et oui, cela fonctionne avec votre framework préféré même si ce dernier ne l’a pas décrit tel quelle dans sa documentation, préférant opter pour une approche RAD (Rapid Application Development) pour une prise en main simplifiée et des résultats plus rapides.

Concentrez-vous sur les principes, pas la technologie

Fri, 22 Mar 2024 00:00:00 +0100

Au détour d’une discussion sur les monolithes modulaires avec un collègue développeur ce matin, je lui explique être en train de regarder une formation en ligne intitulée “Modular Monoliths in .NET”. Il me demande alors: “Pourquoi regarder une formation orientée .NET ? Alors qu’au quotidien, tu travailles essentiellement en PHP.”.

C’est (malheureusement) un peu dans la tendance. Aujourd’hui beaucoup cherchent à se spécialiser sur une technologie précise. On voit souvent des développeurs se qualifier de “développeur [insérer ici une techno de votre choix]”. On cherche dorénavant à connaitre une techno sur le bout des doigts. Pourtant les langages, frameworks et bibliothèques vont et viennent. Je fais de l’informatique professionnellement depuis 15 ans et lorsque j’ai commencé, les frameworks PHP en étaient à leur tout début (j’ai encore les souvenirs de Copix). On était encore bien loin des frameworks type Zend, Symfony ou Laravel.

Pour autant, je travaillais avec des frameworks type Struts, qui reposaient sur une architecture modèle-vue-controleur (MVC) comme encore la plupart des frameworks existants. Or, si on comprend comment fonctionne ce pattern, passer de l’un à l’autre est relativement simple.

Bien entendu, cela ne se fait pas en un claquement de doigts. Il faudra (ré)apprendre les particularités du nouveau framework, éventuellement le langage de programmation utilisé, mais de nombreux principes restent communs à tous les outils.

Et c’est bien là que je veux en venir. Ne vous focalisez par sur une technologie précise, concentrez-vous sur les principes sous-jacents. Tout d’abord, cela vous permettra de bien comprendre les tenants et les aboutissants, vous donnant ainsi la capacité de juger de la pertinence de la mise en place de l’outil dans un contexte donné.

En plus de cela, vous ne serait pas enfermé dans un écosystème particulier. Ce dernier point est d’autant plus important si vous souhaitez avoir une carrière longue de développeur. Car si les technologies changent, les principes et les patterns restent souvent les mêmes. Vous n’aurez donc pas à continuellement repartir de 0 lorsque vous basculerez sur de nouvelles briques techniques.

Comprendre le fonctionnement des outils et les fondamentaux sur lesquels ils reposent est donc le secret de la longévité de votre carrière de développeur, mais également un des éléments clés pour avoir une analyse pertinente à un problème donné.

Ne faites pas confiance aux données de vos utilisateurs

Thu, 14 Mar 2024 00:00:00 +0100

S’il y a bien un proverbe que j’entends depuis que j’ai démarré l’informatique, c’est bien “never trust user input” (ne faites pas confiance aux données de vos utilisateurs). L’idée est simple: lorsque vous attendez des données utilisateurs en entrée d’un traitement, il est nécessaire au préalable de vérifier, valider, voir de nettoyer l’information reçue.

On pense alors généralement à de la donnée provenant de formulaires dans le cas d’applications Web, on vérifiera le format d’une adresse e-mail qui sera utilisée pour envoyer une communication électronique. Mais la validation des données peut aussi relever d’un aspect sécurité. Par exemple, si une donnée renseignée par l’utilisateur va être utilisée au sein d’une requête SQL, on cherchera alors à échapper cette dernière afin de se prémunir d’éventuelle injection SQL.

S’assurer de la validité et de la cohérence d’une donnée, c’est offrir une meilleure expérience utilisateur aux personnes qui utilisent vos outils. Une erreur de saisie, un doigt qui dérape et si vite arrivée.

Aussi, dans le cas d’erreurs, de bugs ou de demandes d’assistance, on aura souvent tendance à dire que si l’utilisateur fait et renseigne n’importe quoi n’importe comment. Mais peut-il être incriminé si l’application ne fait pas les vérifications nécessaires à son bon fonctionnement ? N’avons-nous pas, nous développeurs, un rôle à jouer là-dedans ?

Ne faites jamais confiance à la donnée qui provient d’un utilisateur qu’il soit bien intentionné ou non. Appliquer des techniques de validation, nettoyer la donnée pour garantir la meilleure expérience possible et la sécurité de vos projets.

IA: ne ratez pas la révolution qui est en marche

Fri, 16 Feb 2024 00:00:00 +0100

Hier soir (jeudi 15 février 2024), j’ai eu la chance de pouvoir participer à la soirée de lancement du livre Hyperprompt, le premier manuel français de prompt engineering écrit par Flavien CHERVET (auteur d’ouvrage et conférencier sur la thématique de l’intelligence artificielle). Durant cette soirée, ce fut l’occasion de discuter du fonctionnement des IA génératives, de comprendre les bases de leur fonctionnement afin de savoir comment “leur parler”. Tout cela avec un peu d’explication de sciences cognitives et de magie.

Mais pourquoi je vous parle de tout ça ? Parce que je considère que nous sommes actuellement dans un tournant technologique, un virage que je ne veux pas rater et auquel je pense qu’il est primordial de s’y intéresser. Tout d’abord parce que les IA génératives sont des outils extraordinaires qui nous permettent de nous aider dans notre travail quotidien. Que ce sont des outils incroyables pour appréhender des domaines que l’on ne maîtrise pas.

Ensuite parce que ces outils n’en sont qu’à leurs prémisses, ils se développent et évoluent à une vitesse incroyable. Que je reste convaincu qu’il sera plus facile d’acquérir les bases de leurs bonnes utilisations en s’y mettant tôt plutôt que dans quelques années où ces dernières seront devenues plus puissantes, mais aussi plus complexes et qu’il faudra acquérir les bases.

Je n’ai pas envie de laisser passer cette vague, de me faire remplacer. Je souhaite utiliser et comprendre ces outils pour faire un travail de qualité, plus efficace, et plus rapidement. Car comme l’a dit Eric DASPET sur les réseaux sociaux: nous avons longtemps craint que l’évolution des machines favoriserait le remplacement des “petits boulots”. Pourtant c’est bien nous, les travailleurs intellectuels, qui sommes peut-être le plus menacés.

Sauvegarder sa base de données MySQL sans perturber sa production

Tue, 06 Feb 2024 00:00:00 +0100

Dans la majorité des cas, pour sauvegarder une base de données MySQL, c’est la commande mysqldump, l’outil fourni par le SGBD, qui va être utilisé. Mais saviez-vous que cela n’est pas sans risque et que cette opération peut perturber les opérations en cours sur votre base de données ?

J’ai pu le constater à mes dépens en voulant effectuer la sauvegarde d’une base de données volumineuse. Lorsque la commande va commencer à récupérer les données, l’outil va mettre en place un verrou (LOCK) au niveau des tables ce qui va avoir pour conséquence de les rendre inaccessibles. Sur de petites volumétries, cela n’aura que peu d’incidence, mais si vous avez une grande quantité de données à récupérer, cela signifie que durant tout le temps de sauvegarde, votre application ne pourra pas accéder à la base de données de manière fluide. La conséquence dans mon cas, c’est plusieurs utilisateurs qui n’ont pu travailler sur l’outil en question, entraînant une interruption de service le temps de l’opération.

Pour éviter cela, mysqldump propose un certain nombre d’options qui vous permettra d’éviter ces déconvenues. Les deux plus importantes et que j’utilise dorénavant systématiquement sont:

--single-transaction qui va mettre en place une transaction (si cela est supporté par le moteur utilisé) afin de garantir la cohérence des données sans pour autant mettre en place un verrou
--skip-lock-tables qui comme son nom l’indique indique qu’il ne faut pas mettre en place de verrou.

Installer et utiliser un LLM en local

Sun, 28 Jan 2024 00:00:00 +0100

S’il y a bien un sujet tendance ces dernières années (surtout depuis l’arrivée de Chat GPT), c’est les Large Language Model (souvent appelé LLM). Personnellement, je n’échappe pas à ce “mouvement”. J’utilise Github Copilot au quotidien et Chat GPT régulièrement (qui a remplacé à la fois Google et Stack Overflow).

Faisant de la veille régulièrement, j’ai envie de comprendre comment ces outils peuvent révolutionner notre quotidien de développeur (et je pense sincèrement que c’est le cas quand on sait les manipuler correctement). Je pense même que c’est une erreur de ne pas s’y mettre.

Conscient et convaincu de l’importance de ces solutions, je n’ai pas envie de n’être qu’un simple utilisateur final. C’est pour cela que je me demande régulièrement ce que pourrait apporter l’intégration d’un LLM dans les projets sur lesquels je travaille. S’il existe de nombreuses plateformes permettant de s’interfacer avec une intelligence artificielle, je me suis demandé comment installer et utiliser un des nombreux LLM open source disponible (il y en a dorénavant pléthore sur le net).

Ce fut au final beaucoup plus facile que ce que j’avais imaginé. J’utilise pour ma part Ollama qui est une solution extrêmement simple d’utilisateur et qui permet d’exécuter localement un vaste choix de LLM open source. Disponible sur Linux, Mac OS et prochainement sur Windows, Ollama va installer un service sur votre machine qui permettra de télécharger les modèles et d’interagir avec.

Par exemple, j’ai pu tester Mistral AI le LLM made in France de la manière suivante:

$ ollama pull mistral # permet de télécharger le modèle
$ ollama run mistral # pour commencer à discuter avec le modèle

Et cerise sur la gâteau, il est possible d’interagir avec Ollama localement via une API HTTP qui s’utilise aussi simplement que les outils en ligne de commande.

C’est avec cette dernière que je peux alors commencer à intégrer des LLM dans mes projets simplement. J’ai d’ailleurs commencé à développer un composant PHP pour interagir simplement avec l’API Ollama. Ce dernier est dorénavant disponible publiquement sur Github.

Alors, qu’attendez-vous pour vous y mettre ?

Bouchon (mock) et implémentation mémoire dans les tests

Fri, 20 Oct 2023 00:00:00 +0200

Un projet sur lequel je travaille actuellement utilise dans ses tests des bouchons (ou mock en anglais), mais également des implémentations mémoires de service travaillant avec des objets. Aussi, on m’a demandé l’intérêt d’utiliser l’un ou l’autre et je trouvais le sujet assez intéressant pour en écrire un billet.

Lorsque l’on écrit des tests, il y a grosso modo deux écoles. La première va utiliser les bouchons (mock) pour décrire le fonctionnement attendu d’une méthode d’un objet. La seconde, quant à elle, va limiter leur utilisation au maximum (voir totalement). Ce sont ces derniers qui auront alors plus tendance à utiliser des implémentations mémoires des services. Chacune des deux méthodes a son lot d’avantages et inconvénients. À chacun de se faire sa propre opinion et d’utiliser l’approche qui lui convient dans le contexte qui lui est donné.

Commençons par les bouchons. Ces derniers sont généralement simples et rapides à créer. C’est d’ailleurs un de leur principal avantage et c’est aussi pour cela qu’on a tendance à beaucoup les utiliser. D’autant plus les frameworks de test proposent généralement de nombreux outils pour nous aider dans cette tâche. Derrière cette simplicité de mise en place et d’utilisation se cachent également quelques inconvénients. Tout d’abord, bien souvent la gestion des bouchons n’est pas centralisée, on se retrouve donc à dupliquer le(s) comportement(s) attendu(s) dans l’ensemble des cas de tests. De ce fait, lorsqu’un contrat d’utilisation change, il sera nécessaire de repasser sur chaque définition de bouchons pour la mettre à jour. Un autre inconvénient est que l’on peut généralement faire tout et n’importe quoi avec un bouchon, il n’est pas si rare de se retrouver à tester des comportements qui ne pourraient pas se produire dans la réalité.

Avec les implémentations mémoires et contrairement aux bouchons, on ne va pas créer une classe dans le but de simuler une implémentation d’un service. L’implémentation en mémoire est l’implémentation d’un service applicatif qui va travailler avec des données uniquement en mémoire. Bien qu’il soit un peu plus verbeux qu’un bouchon, on se retrouve donc indirectement à centraliser (plus facilement) la gestion du comportement dans une classe unique et en cas de modification, les tests pourront être adaptés plus facilement.

Autre aspect très intéressant, contrairement à un bouchon où l’on est obligé de connaitre le détail d’implémentation des services à simuler (la simulation du comportement étant nécessairement rattachée à l’appel d’une fonction), dans le cadre d’une implémentation mémoire on se contente de passer une instance du service que l’on souhaite utiliser. C’est un gros point, car le test va pouvoir se concentrer uniquement sur le comportement du test sans nécessiter d’avoir la connaissance de comment l’ensemble est implémenté. Il est alors dans ce cas plus facile d’avoir des tests pérennes dans le temps en les rendant moins fragiles. C’est d’autant plus intéressant qu’il sera possible d’écrire des tests de contrat afin de s’assurer que l’implémentation en mémoire (que l’on appelle également InMemory) se comporte exactement de la même manière que l’implémentation réelle. Un point qui est beaucoup plus difficile à mettre en place avec les bouchons.

À noter également que les implémentations mémoires sont généralement très utilisées dans les architectures hexagonales. Elles permettent de démarrer la mise en place d’un projet en amont d’avoir choisi les outils et/ou technologies qui seront utilisés. Par exemple, la mise en place d’un InMemoryRepository permet d’avoir une implémentation mémoire de la persistance de données avant d’avoir choisi le moteur de stockage qui sera utilisé dans le projet.

Comme je le disais en introduction, il y a donc deux écoles. À vous de choisir la vôtre en fonction du contexte. Comme toujours en informatique, il y a une multitude de choix d’implémentation à chacun de trouver la manière de travailler qui lui convienne.

Et en bonus voici un exemple pour illustrer ce billet:

interface CommandBus
{
    public function handle(object $command): void;
}

// implémentation mémoire
class InMemoryCommandBus implements CommandBus
{
    private array $handledCommands;

    public function __construct()
    {
        $this->handledCommands = [];
    }

    public function handle(object $command): void
    {
        $this->handledCommands = $command;
    }

    public function getHandledCommands(): array
    {
        return $this->handledCommands;
    }
}

// test utilisant les bouchons
class MockImplementationTest extends TestCase
{
    public function testCommandShouldBeHandled(): void
    {
        $expectedCommand = new stdClass;

        // ici le bouchon va simuler l'appel et faire l'assertion sur les données
        $bus = $this->createMock(CommandBus::class);
        $bus->expect(self::once())
            ->method('handle')
            ->with($exepectedCommand);

        $subject = new TestedClass($bus);
        $subject->doAction();

        // réalisation d'autres assertions
    }
}

// test utilisant l'implémentation mémoire
class InMemoryImplementationTest extends TestCase
{
    // on notera également que ce test respecte la structuration
    // Arrange, Act, Assert d'écriture des tests
    public function testCommandShouldBeHandled(): void
    {
        $bus = new InMemoryCommandBus();

        $subject = new TestedClass($bus);
        $subject->doAction();

        self::assertCount(1, $this->bus->getHandledCommands());
        self::assertContainsEquals(new stdClass, $this->bus->getHandledCommands());
        // réalisation d'autres assertions
    }
}

Utiliser PHPUnit 10 avec Symfony

Mon, 09 Oct 2023 00:00:00 +0200

Au moment où j’écris ce billet, PHPUnit 10 a été publié il y a près de 8 mois (le 3 février 2023). Et pourtant si on tente de l’utiliser dans un projet Symfony utilisant le bridge symfony/phpunit-bridge, nous obtenons l’erreur suivante: PHP Fatal error: Uncaught Error: Class "PHPUnit\TextUI\Command.

PHP Fatal error:  Uncaught Error: Class "PHPUnit\TextUI\Command" not found in /home/jdecool/Workspace/sandbox/test/bin/phpunit:11
Stack trace:
#0 {main}
  thrown in /home/jdecool/Workspace/sandbox/test/bin/phpunit on line 11

Fatal error: Uncaught Error: Class "PHPUnit\TextUI\Command" not found in /home/jdecool/Workspace/sandbox/test/bin/phpunit on line 11

Error: Class "PHPUnit\TextUI\Command" not found in /home/jdecool/Workspace/sandbox/test/bin/phpunit on line 11

Call Stack:
    0.0001     396248   1. {main}() /home/jdecool/Workspace/sandbox/test/bin/phpunit:0

La raison étant que le script fourni par Symfony utilise du code qui a été supprimé dans la dernière version majeure du framework de test.

Il y a plusieurs propositions en cours pour corriger ce problème, mais aucune n’est actuellement mergée.

Pour corriger cela, vous pouvez simplement modifier le fichier bin/phpunit en remplaçant la ligne ci-dessous:

-    PHPUnit\TextUI\Command::main();
+    exit((new PHPUnit\TextUI\Application)->run($_SERVER['argv']));

Les interactions: la clé de la réussite d'un développement logiciel

Fri, 28 Jul 2023 00:00:00 +0200

Au plus j’avance dans ma carrière et au plus je m’intéresse aux interactions entre individus. Je me rends compte au fil de mes expériences que la partie technique et produit ne sont qu’une partie de la clé de la réussite d’un logiciel. On peut avoir les meilleurs Product Owner, les meilleurs développeurs, cela ne suffit pas.

Par exemple, les équipes ont besoin d’interaction, ce ne sont pas des personnes qui travaillent au même endroit, mais des personnes qui poursuivent ensemble une mission. Et c’est de la responsabilité du management de faire en sorte de fournir le cadre de travail idéal afin de fluidifier ces échanges.

Comme le dit si bien Ludovic Girodon:

Un manager n’est pas là pour être un bon technicien, il est avant tout là pour avoir le recul nécessaire pour faire grandir son équipe

Faire communiquer les équipes, travailler ensemble, partager une même vision et le chemin pour y parvenir, voila ce qui fera la réussite de votre projet.

Être à l’écoute, juste, respectueux, pédagogue, savoir guider (sans imposer) donnera la confiance et l’autonomie nécessaire à une équipe pour grandir, être autonome et atteindre les objectifs qui lui sont fixés.

Rendez-vous le 12 mai 2023 à l'AFUP Day

Thu, 19 Jan 2023 00:00:00 +0100

L’AFUP (Association Française des Utilisateurs de PHP) vient de l’annoncer sur son blog (cache), Twitter & Mastodon:

La communauté PHP lyonnaise est en ébullition à l’idée du retour de l’AFUP Day dans sa ville. L’AFUP Day 2023 Lyon est SOLD-OUT, 4 mois avant l’événement !

Un peu plus de deux ans sans avoir eu l’occasion de participer à des conférences en présentiel et une participation fort agréable au Forum PHP 2022, j’aurai le plaisir d’assister aux retours des conférences de l’AFUP à Lyon !

On s’y retrouve en mai ? ;)

De l'utilité des réunions

Sun, 08 Jan 2023 00:00:00 +0100

La tendance (qui n’est pas nouvelle, je l’entends depuis plusieurs années maintenant) est à la limitation des réunions. Dernier exemple en date, Shopify qui envisage de supprimer toutes les réunions récurrentes de plus de deux personnes. J’ai vraiment l’impression qu’il s’agit là d’une tendance de fond.

Pourtant, bien que je sois loin d’être proréunion, que ces dernières puissent être improductives et une perte de temps potentielle pour les personnes qui y participent, il faut dire que c’est généralement à cause d’un manque de préparation. Un très bon article sur le sujet est certainement celui d’Eric DASPET: Faire plus de réunions. J’y partage l’ensemble des idées qui y sont exprimées.

Pour moi, le plus important est dit dès le début: “se réunir c’est communiquer et collaborer”.

Au sein d’une équipe, il est parfois utile et primordial d’avoir une communication synchrone, que tout le monde soit là pour discuter, échanger, entendre la même chose au même moment. C’est aussi cela qui forge des équipes, participe à la cohésion et à la mise en place d’une vision commune. Ce n’est pas travailler chacun dans son coin.

Bien entendu, ce n’est pas chose facile et comme on me le fait remarquer sur Twitter, en plus du manque de préparation, un des problèmes majeurs des réunions: ce sont toujours les mêmes personnes qui parlent, prennent la parole, écrase parfois les autres personnes (même de manière involontaire). C’est un biais pas toujours facile à éviter auquel il faut faire attention.

Oui il faut y faire attention, mais il y a de nombreuses techniques et outils pour faire attention à cela et éviter les pièges. Pour ma part, je puise beaucoup dans les outils et pratiques, rituels et cérémonies agiles.

À propos de la couverture de code

Tue, 03 Jan 2023 00:00:00 +0100

Lorsque l’on met en place des tests sur un projet et que l’on souhaite commencer à avoir des indicateurs sur ces derniers, c’est naturellement que l’on se tourne sur le taux de couverture de code (alias le code coverage en anglais). Pourtant, dans absolument toutes mes expériences professionnelles, cet indicateur a systématiquement été critiqué par certains développeurs.

Effectivement, le taux de couverture de code est la mesure du nombre de lignes de code source exécutées durant les tests. En d’autres termes, il s’agit de compter les lignes du code de production parcourues durant les tests. Le problème étant qu’un test peut ne faire aucune vérification et pour autant avoir un taux de couverture de code élevé.

Prenons par exemple le code suivant:

function calcul(string $op, int $x, int $y): int
{
    return match ($op) {
        '+' => $x + $y,
        '-' => $x - $y,
        '*' => $x * $y,
        '/' => $x / $y,
        default => throw new \InvalidArgumentException(),
    };
}

Avec le test associé:

class CalculTest extends TestCase
{
    public function testCalcul(): void
    {
        $resultat = calcul('+', 1, 5);

        $this->assertIsInt($resultat);
    }
}

Avec un tel test, nous obtenons le résultat ci-dessous:

Summary:
  Classes: 100.00% (1/1)
  Methods: 100.00% (1/1)
  Lines:   100.00% (7/7)

Nous avons donc un test qui ne fait aucune vérification et pourtant nous avons un taux de couverture de code de 100%. C’est pour cela que cette métrique est décriée.

C’est aussi pour cela qu’il faut considérer la couverture de code comme un indicateur négatif d’un projet et non pas comme un indicateur de mesure de qualité. Un projet ayant une couverture de code basse peut indiquer un nombre insuffisant de tests sur le projet. Alors qu’à l’inverse, cela indique qu’il y a des tests, mais cet indicateur à lui seul, ne donne pas de mesure sur la qualité de ces derniers. Pour cela, il faudra le corréler avec d’autres métriques.

À noter qu’il y a également une seconde métrique corrélée au taux de couverture de code, mais dont on parle beaucoup moins. Il s’agit du taux de couverture de branche (ou branch coverage). On parle également du taux de couverture des chemins d’exécution qui comme son nom l’indique permet de vérifier si chaque parcours de code possible a été exécuté ou non.

Si l’on reprend notre exemple précédent avec le code effectuant les opérations de calculs et le test associé que nous avions écrit, on se retrouverait avec la couverture suivante:

Summary:
  Classes:  0.00% (0/1)
  Methods:  0.00% (0/1)
  Paths:    20.00% (1/5)
  Branches: 42.86% (3/7)
  Lines:    100.00% (7/7)

Ici on peut clairement voir la différence. Toutes les lignes de code ont été exécutées, mais les tests n’ont permis d’explorer qu’un seul des cinq chemins d’exécution possibles. Cela indique clairement que notre test, s’il est pertinent, ne couvre que peu de comportements.

On peut donc voir le taux de couverture de branche comme un indicateur plus fiable que le taux de couverture de code. Néanmoins attention, le calcul de ce dernier est coûteux en termes de ressources (temps, CPU, mémoire) et cela peut ralentir drastiquement votre suite de tests.

Retrouvez les utilisateurs Twitter sur Mastodon

Tue, 06 Dec 2022 00:00:00 +0100

Comme je l’ai annoncé il y a peu de temps, je suis maintenant présent sur Mastodon. Comme sur Twitter, j’y partage ma veille, mes réflexions ainsi que mes différentes trouvailles. Mais il s’agit également d’une source de veille.

Migrer vers un nouveau réseau social n’est pas aisé, encore plus quand il s’agit d’un réseau décentralisé comme Mastodon: il faut reconstruire sa “communauté”. Et ici, pas d’algorithme de recommandation pour nous aider.

À noter ici, que quand je parle de communauté, je pense principalement aux personnes auxquelles je suis abonné et dont je peux suivre les publications plus qu’à l’inverse.

Étant donné qu’il y a un exode plus ou moins massif des utilisateurs Twitter sur Mastodon, il est intéressant d’essayer de retrouver les utilisateurs Twitter qui ont migré vers Mastodon. Et pour nous aider dans cette tâche, il existe de nombreux outils disponibles.

Pour ma part, j’ai utilisé l’outil développé par Amelia Wattenberger disponible à l’adresse suivante https://mastodon-bridge.vercel.app.

Mais il en existe bien d’autres, dont le plus connu/utilisé est Twitodon et dont le code source est disponible sur Github contrairement à l’outil précédent (ce qui est le comble pour une application conçue par une personne travaillant chez Github).

Donc si l’aventure Mastodon vous tente, après avoir choisi votre instance, commencez par retrouver vos utilisateurs Twitter.

Retrouvez-moi sur Mastodon

Mon, 14 Nov 2022 00:00:00 +0100

Depuis son rachat par Elon Musk, Twitter est un peu dans la tourmente: licenciement en masse, départs volontaires des employés et des utilisateurs “effrayés” qui fuient vers des réseaux alternatifs. Il n’y a pas de doute, Twitter est dans une très mauvaise période. Je ne suis (pour le moment) pas inquiet pour le réseau social, les semaines à venir seront difficiles, mais je pense que Twitter s’en remettra.

Néanmoins, cela ne m’empêche pas, comme de nombreux utilisateurs, d’aller explorer des solutions alternatives.

J’utilise Twitter essentiellement pour partager de la veille technique. Au-delà de la partager publiquement, c’est également un moyen de stocker de l’information que je peux retrouver plus tard. Sans grande originalité, j’explore aujourd’hui la solution qui connaît le plus d’engouement actuellement: Mastodon.

Ainsi, inspiré par l’exploration de Mastodon de Martin Fowler, j’ai donc créé un compte sur l’instance phpc.social, une instance dédiée à la communauté PHP.
Sur cette instance, n’hésitez pas à suivre mon compte @jdecool@phpc.social, vous y retrouverez mes différents partages.

Pour le moment, je ne quitte pas Twitter, je reste actif sur ce dernier. Ma veille sera publiée à la fois sur Twitter et Mastodon grâce à l’utilisation de Moa.

Nous verrons bien ce que l’avenir nous réserve et si les deux instances ont un avenir…

Quelle est la définition d'une équipe ?

Fri, 16 Sep 2022 00:00:00 +0200

Aujourd’hui, en consultant LinkedIn, j’ai eu l’occasion de voir passer une infographie de Catherine TESTA proposant une définition (que je trouve très juste) d’une équipe.

Je vous laisse apprécier.

Corriger un fichier UTF-8 mal encodé

Wed, 14 Sep 2022 00:00:00 +0200

J’ai une application qui me génère pour une raison que j’ignore des fichiers UTF-8 qui contiennent des caractères mal encodés. Si ce n’est visuellement pas dérangeant, certaines applications plantent à l’ouverture du fichier à cause de cela.

S’il vous arrive la même chose et que vous êtes sous Linux (ou Mac), sachez que corriger ce problème est très simple et ce fait au travers d’une ligne de commande avec iconv qui est généralement installé par défaut sur les machines.

Pour cela, il faudra préciser que l’encodage en entrée est de l’UTF-8 et faire de même pour l’encodage de destination:

iconv -f utf-8 -t utf-8 -c mon-fichier-en-erreur.ext > destination.ext

Le pattern "Parameter Object"

Sat, 26 Feb 2022 00:00:00 +0100

Après avoir publié mon billet concernant le pattern Commande hier, on m’a demandé s’il était possible d’utiliser une commande pour remplacer un groupe de paramètre d’une fonction ou d’une méthode avec pour objectif de simplifier le code et sa lisibilité sans pour autant mettre en place un bus de commande.

Pour répondre sans détour à cette question, oui il est tout à fait possible de remplacer des paramètres de fonction par un objet, cela correspond même à un autre patron de conception nommé le paramètre objet (ou Parameter Object en anglais).

Ce pattern permet de regrouper un ensemble de paramètres au sein d’un ou plusieurs objets qui seront transmis à votre fonction afin de rendre le code plus lisible en simplifiant les signatures de méthodes.

Il permet également de supprimer de la duplication de code dans le cas ou différentes méthodes définissent systématiquement un même groupe de paramètre parce que ces derniers sont fonctionnellement liés.

Par exemple, je travaille sur une application de calendrier dans laquelle j’ai énormément de méthodes qui travaillent avec des dates de début et des dates fins de période:

public function filterEventByDate(DateTime $start, DateTime $end);
public function getEvents(DateTime $start, DateTime $end);
public function getAvailableSlot(DateTime $start, DateTime $end);

On remarque ici que de nombreuses méthodes partagent les paramètres $start et $end qui partage une même sémantique fonctionnelle. On pourra alors regrouper ces deux paramètres au sein d’un object DateRange:

class DateRange
{
    public function __construct(
        public readonly DateTime $start,
        public readonly DateTime $end,
    ) {
    }
}
public function filterEventByDate(DateRange $dateRange);
public function getEvents(DateRange $dateRange);
public function getAvailableSlot(DateRange $dateRange);

Si l’exemple précédent est relativement simpliste, dans des cas d’utilisation réels, on peut facilement imaginer que notre objet paramètre pourra regrouper bien plus de données.

Le pattern "Commande"

Fri, 25 Feb 2022 00:00:00 +0100

Si je reprends la définition de wikipedia, il s’agit d’un patron de conception (ou design pattern en anglais) qui permet d’encapsuler la notion d’invocation. C’est un moyen très utile de rendre votre code modulaire et lisible en découpant votre code en différentes commandes, chacune ayant des responsabilités uniques et spécifiques.

Un objet Command est un DTO (Data Transfer Object) qui permet d’encapsuler toutes les informations nécessaires pour réaliser une action. La commande n’a aucune logique, elle s’utilise au travers d’un bus (command bus pattern) qui est chargé de recevoir une commande valide et de déclencher les actions associées. Son unique responsabilité est de gérer les différents cas d’utilisation en déléguant l’exécution de la commande à une classe spécifique au traitement en question. L’objectif est de permettre au développeur d’émettre une intention d’effectuer une action sans que ce dernier n’ait à se soucier de la manière dont elle va être traitée et/ou implémentée.

<?php

class CreateCustomer {
    public function __construct(
        public readonly string $name,
        public readonly string $phonenumber,
    ) {
        // assert data validity
    }
}

$this->bus->execute(new CreateCustomer(/* ... */));

Il existe de nombreux composants PHP qui vous permettent d’implémenter ce pattern dans vos projets. Mais concevoir un bus de commande n’est fondamentalement pas compliqué. Dans sa version minimaliste, il s’agit de faire un lien entre une commande et son gestionnaire (ou handler en anglais).

<?php

class CommandBus {
    /** Handler[] */
    public function __construct(
        private readonly array $handlers,
    ) {
    }

    public function execute(object $command): void
    {
        $commandClass = get_class($command);
        $handler = $this->handlers[$commandClass] ?? throw new RuntimeException("No handler for $commandClass command.");

        $handler($command);
    }
}

class MyCommand {}
class MyCommandHandler
{
    public function __invoke(MyCommand $command): void
    {
        echo "Hello World", PHP_EOL;
    }
}

$bus = new CommandBus([
    MyCommand::class => new MyCommandHandler(),
]);
$bus->execute(new MyCommand()); // will display "Hello World"

Si ce type d’architecture a été popularisé par la montée en puissance du Domain Driven Design ou des architectures CQRS, il est tout à fait possible de l’utiliser dans n’importe quel projet.

J’en suis pour ma part très friand car il y a de nombreux avantages à utiliser ce paradigme. Il permet de bien découper le code, d’avoir des petites classes avec des responsabilités uniques et isolées, donc faciles à tester. Au-delà de ces avantages purement techniques, cela permet également de pouvoir dresser simplement la liste de cas d’utilisation qui sont gérés par notre projet.

Un autre aspect que j’apprécie particulièrement est la facilité que l’on a d’étendre le comportement d’un bus de commande. Il est possible de décorer un bus afin de lui ajouter des comportements supplémentaires qui ne sont pas directement liéss à l’intention métier que l’on souhaite réaliser dans l’application. Il sera par exemple possible de créer un bus de commande qui gérera les transactions de base de données, de gérer des logs ou d’effectuer diverses tâches de monitoring, tout cela de manière complètement découplée de votre code orienté métier.

Gestion des identités et Domain Driven Design

Mon, 15 Nov 2021 00:00:00 +0100

Maîtriser la gestion des identités de nos entités dans une application dont la conception est pilotée par le domaine (Domain Driven Design) est un enjeu majeur. Cela permet notamment d’être découplé de son système de gestion de base de données et d’avoir une maîtrise totale de la gestion des données métier.

Il existe pour cela de nombreuses solutions possibles. Celle qui est certainement la plus commune (parce qu’il s’agit d’une des plus simples) est d’utiliser des identifiants uniques universels (Universally Unique IDentifier en anglais), plus couramment appelés UUID. Ce dernier peut être utilisé conjointement avec l’identifiant auto-incrémenté qui est généralement utilisé par défaut dans nos bases de données relationnelles. La plupart des ORM sont d’ailleurs capables de le gérer nativement. Mais il sera préférable de gérer la création de l’UUID soi-même pour éviter d’être dépendant du composant qui interagit avec votre base de données. En PHP, vous pourrez utiliser ramsey/uuid ou encore symfony/uid.

<?php

use Ramseu\Uuid\UuidInterface;

class MyEntity
{
    public function __construct(
        private UuidInterface $uuid,
    ){
    }
}

Il n’est pas toujours nécessaire d’utiliser un identifiant unique aléatoire. Selon le type de données que vous manipulez, vous travaillez peut-être avec des clés naturelles. Par exemple, si vous gérez une bibliothèque de livres ou que vous êtes amené à manipuler des numéros de sécurité sociale. Dans le premier cas, un livre est identifié par un numéro international normalisé: l’ISBN. Analysez donc bien les données que vous manipulez, car selon le métier que vous cherchez à modéliser, il n’est pas toujours nécessaire de passer une solution technique.

<?php

class Book
{
    public function __construct(
        private ISBN $isbn,
    ){
    }
}

Dans certains contextes, il est nécessaire d’utiliser des identifiants séquentiels. Dans ce cas précis, il est intéressant d’utiliser le mécanisme d’auto-incrément de la base de données. Afin de rester indépendant de notre système de base de données, il est alors primordial d’être capable de récupérer la valeur de l’identifiant avant d’écrire la donnée. Une technique pouvant être utilisée est de créer une table avec un identifiant auto-incrémenté, que l’on utilisera comme système de réservation. Pour obtenir la valeur, il faudra insérer une ligne dans cette table et l’utiliser l’identifiant généré comme identifiant de notre entité.

Nous venons de voir les 3 approches les plus couramment utilisées pour gérer les identités de nos entités dans un projet piloté par le domaine. Les approches listées ici ne sont pas exhaustives, mais ont pour but de vous montrer les solutions les plus simples et courantes. Peut-être vous demandez-vous laquelle utiliser ?

Comme toujours en informatique, il n’y a pas de recette universelle, cela dépendra de votre contexte. Si dans une grande majorité des cas, l’utilisation d’UUID sera suffisant, il y a des cas plus complexes qui nécessiteront une approche alternative. À vous de choisir la bonne solution en fonction de votre contexte métier.

Quand utiliser des interfaces?

Sun, 14 Nov 2021 00:00:00 +0100

J’ai récemment découvert le concept de Interface-based programming (également appelé Interface-based architecture). Il s’agit d’un modèle d’architecture reposant sur des interfaces plutôt que des implémentations. J’ai notamment eu l’occasion d’expérimenter cette technique de manière dogmatique où toute classe d’un projet (service, DTO, value object, entité de base de données, modèle métier…) devait être liée à une interface. L’objectif d’une telle architecture est de concevoir une application par “contrat” et d’avoir du code entièrement découplé de toute implémentation.

Malheureusement, avoir une approche dogmatique qui pousse à appliquer un concept de manière systématique sans se poser de questions sur le contexte dans lequel il est utilisé peut annuler les bénéfices qu’il serait possible d’en tirer. Ce fut l’occasion pour moi de me poser la question: quand est-il judicieux d’utiliser des interfaces de classe?

J’ai donc beaucoup réfléchi à cette question et fait de nombreuses recherches sur le sujet. Je suis finalement tombé sur un article de Mathias NOBACK “When to add an interface to a class” qui résume tellement bien mon point de vue sur le sujet que je vous recommande vivement de le lire. À défaut vous trouverez les principales lignes directrices ci-dessous:

Une classe définit de manière implicite un contrat d’utilisation au travers de ces méthodes publiques. Créer une interface peut-être utile si ces dernières ne devraient pas être accessibles.
Lorsque du code interagit avec le système de fichier, du réseau ou n’importe quel système tiers, la mise en place d’une interface est essentielle pour se découpler de l’implémentation et faciliter l’écriture de tests.
De la même manière que le point précédent, si votre code utilise du code que vous ne maintenez pas vous-même, mettre en place une interface vous permettra de changer simplement l’implémentation que vous avez utilisée.
Si vous travaillez sur un système informatique ou des développeurs tiers peuvent surcharger ou remplacer le fonctionnement par défaut, une interface permettra de définir le contrat attendu pour fonctionner.

Lire du code est une compétence

Thu, 23 Sep 2021 00:00:00 +0200

À ce sujet, je vous recommande la lecture de l’article de Trisha GEE où elle explique bien le sujet et d’où je tire le titre de ce billet.

Ecrire du code lisible et/ou facilement compréhensible est compliqué à juste titre, car c’est avant tout quelque chose d’extrêmement subjectif.

Nous avons tous une vision (potentiellement différente) de ce qu’est un code lisible. Nous n’en avons pas tout la même définition.

Nous écrivons d’ailleurs tous du code différemment. Cela peut se voir lorsque nous travaillons en équipe et nous sommes parfois capables de reconnaître qui a écrit un morceau de code à la manière dont il a été codé.

C’est pour cela que je trouve l’article assez juste sur le fait que “lire du code” est une compétence à part entière. Bien entendu, comme le souligne Trisha, il est bien évident qu’un développeur devrait tout faire pour écrire du code le plus lisible possible, qui est cela dit au passage une autre compétence à part entière.

Cela n’est pas toujours quelque chose de simple, surtout si l’on reste “enfermé” dans sa bulle. C’est pour cela qu’il est d’autant plus important de regarder ce qui se fait dans les autres langages ou frameworks, de lire du code de différents projets, de s’ouvrir à d’autres communautés.

Cela n’est pas facile et concerne tous les développeurs. Il m’est arrivé de rencontrer des développeurs avec une dizaine d’années d’expérience et ultracompétent, mais qui était dans une grande difficulté quand ils étaient amenés à lire du code qu’ils n’avaient pas écrit eux-mêmes et qui ne respectait pas leurs standards de code.

Lire du code est une compétence à part entière, ne la négligez pas.

Ne soyez pas passif, créez

Thu, 04 Mar 2021 00:00:00 +0100

Hier, je vous incitais à vous lancer et à passer l’action. Si l’on y réfléchit, cela va de pair avec le fait d’arrêter d’être passif au quotidien et de passer à l’action.

C’est aussi cette idée que m’a inspiré l’article Less Twitter, more building. Je me retrouve un peu dans ce dernier, j’ai récemment changé d’employeur, je travaille maintenant dans un domaine que je trouve extrêmement stimulant et passionnant. À côté de ça, je trouve de moins en moins le temps de faire tout ce que j’aimerais faire en dehors de mon travail. C’est pour cela que j’ai décidé de passer plus de temps à créer des choses plutôt qu’à recevoir du contenu ou de l’information de manière passive.

J’ai par exemple longtemps utilisé Twitter afin de partager la veille que je fais. J’ai toujours considéré qu’il était important de se tenir à jour de l’état de l’art de notre métier pour pouvoir proposer les meilleures solutions aux problèmes que l’on rencontre. Je suis également un grand adepte de Udemy que j’utilise régulièrement pour me former sur divers sujets.

Mais au final, tout ça n’a que peu de sens si ce n’est pas mis en pratique. Tout ce savoir théorique n’a pas de valeur, que si l’on sait comment l’appliquer, dans quelle situation, les différents avantages et inconvénients. Or pour être certain de pouvoir mesurer correctement tout ça, il faut de la mise en pratique.

C’est donc pour cela qu’il est primordial de créer, de créer des choses, de créer du contenu afin de vous permettre d’expérimenter, d’appliquer, de tester ce que vous avez en tête, de créer de la valeur ou tout simplement de vous confronter aux réelles problématiques de ce que vous pensez avoir acquis comme savoir.

Lancez-vous !

Wed, 03 Mar 2021 00:00:00 +0100

Je viens de lire Just Start de Guy TORBET, un étudiant de 17 ans qui explique que peu importe ce que l’on souhaite faire et peu importe le moment où l’on a l’idée de faire quelque chose, ce n’est jamais le bon moment de se lancer.

On est trop jeune, on n’a pas assez d’expérience, on a une famille à gérer, on est trop vieux et après il est trop tard ! C’est ce que tente de nous expliquer Guy, peu importe ce que l’on voudra faire, ce ne sera jamais LE meilleur moment. C’est donc pour cela que le meilleur c’est maintenant !

C’est un peu l’idée que l’on retrouve dans l’excellent livre Execute qui n’est malheureusement plus disponible à la vente. L’idée que lorsque vous avez une idée, un projet, le meilleur moment pour tenter de le concrétiser, c’est d’agir maintenant, c’est-à-dire au moment où votre motivation est la plus importante. À l’inverse, au plus vous attendrez, au plus vous vous trouverez des excuses pour ne pas arriver au bout des choses.

Modéliser une relation plusieurs à plusieurs (n:n) dans un agrégat

Mon, 19 Oct 2020 00:00:00 +0200

J’ai publié hier un article sur la notion d’agrégat, si le principe peut paraître relativement simple, il peut soulever quelques questions comme par exemple, comment modéliser une relation type n:n (plusieurs à plusieurs).

Prenons un exemple que je suis amené à manipuler régulièrement: le cas de la gestion d’un lead dans une application de type CRM. Prenons un cas où une affaire peut être liée à une ou plusieurs entreprises (dans le cas d’achat groupé par exemple). L’affaire étant l’objet de base, nous allons en faire un agrégat.

Si nous cherchons à modéliser notre agrégat, nous pouvons créer un objet Affaire qui sera donc lié à une collection d’objets Entreprise:

class Affaire
{
    // ...

    /** @var Entreprise[] */
    private array $entreprises;
}

Dans notre contexte métier (que l’on pourrait représenter par un Bounded Context), lorsqu’une entreprise est reliée à une affaire, nous souhaitons conserver la date à laquelle l’entreprise a été ajouté au lead en cours.

La solution la plus simple est alors d’ajouter la date directement à notre objet entreprise comme ceci:

class Entreprise
{
    private Siren $siren;
    private string $nom;
    private Adresse $adresse;
    private DateTimeImmutable $dateAjout;

    // ...
}

Dans notre métier, il est possible d’avoir plusieurs leads différents avec une même entreprise. Si la modélisation précédente était simple et intuitive, elle a un défaut majeur: elle va nous obliger à dupliquer les informations des entreprises.
Or, on souhaiterait que si une entrepise A, qui est liée à une affaire L1 et L2, est mise à jour, les informations soient mises à jour dans les deux affaires.

Ici, les développeurs vont en général modéliser une association de la manière suivante:

class Affaire
{
    /** @var AffaireEntreprise */
    private array $entreprises;
}

class Entreprise
{
    private Siren $siren;
    private string $nom;
    private Adresse $adresse;
}

class AffaireEntreprise
{
    private Affaire $affaire;
    private Entreprise $entreprise;
    private DateTimeImmutable $dateAjout;
}

Cette modélisation est très courante car elle reflète en réalité la manière dont les données seraient modélisées dans un système de base de données relationnelle (notamment lorsque l’on travaille sur une application CRUD).

De plus, les structures de données précédentes semblent indiquer qu’une même entité Entreprise peut être partagée entre plusieurs agrégats Affaire. On enfreint ici l’un des principes fondamentaux des agrégats, à savoir que les objets qui constituent un agrégat doivent lui être propre et ne peuvent être partagés (sinon ce dernier n’est plus indépendant et il ne peut assurer la cohérence de ces données puisque les objets partagés peuvent évoluer sans qu’il en ait connaissance).

À cela s’ajoute que la manipulation d’une affaire dans notre code va conduire à une utilisation qui n’est pas des plus intuitives:

$affaire = $repository->get($id);
foreach ($affaire->getEntreprises() as $entrepriseAffaire) {
    // ici la variable `entrepriseAffaire` représente en réalité une classe
    // d'association entre un objet `Affaire` et un objet `Entreprise`
    // il est alors nécessaire de passer par un accesseur supplémentaire pour
    // accéder à notre entreprise
    $entreprise = $entrepriseAffaire->getEntreprise();
}

// cela est d'autant plus visible sur on cherche à accéder à la première
// entreprise de l'affaire
$affaire->getEntreprises()[0]->getEntreprise();

Personnellement, je trouve cette écriture complètement contre-intuitive. Et surtout, il y a fort à parier que les développeurs ne comprennent pas réellement ce qui est manipuler lorsque l’on accède à $affaire->getEntreprises().
Si on en revient au DDD, cette notion de AffaireEntreprise n’est pas une notion métier, c’est une glu technique. Tout cela semble indiquer que nous faisons une erreur de modélisation de notre domaine.

Mais comment écrire proprement cette relation alors ? Avant de répondre à cette question, prenons le temps de réfléchir aux données que nous manipulons. Disons que nous travaillons dans un contexte métier (Bounded Context) type CRM. Ce que nous venons de mettre en évidence, c’est que dans ce contexte, nous travaillons avec des Entreprise qui peuvent vivre de manière indépendantes. Ces dernières ont un cycle de vie qui n’est pas lié à notre contexte de vente.

Dans notre contexte de gestion de vente, nous souhaitons simplement modéliser un lien entre une affaire et une entreprise. De ce fait, la seule information sur une société qui nous intéresse est son SIREN (son identifiant unique). Dans notre contexte de gestion des ventes, nous n’avons pas à nous préoccuper de comment sont gérées les informations attachées à une entreprise (soit via un système tiers, soit via un autre contexte de notre application).

Concrètement, la modélisation d’une entreprise dans le cadre de notre lead peut alors se modéliser ainsi:

class Affaire
{
    /** @var Entreprise[] */
    private array $entreprises;
}

class Entreprise
{
    private Siren $siren;
    private DateTimeImmutable $dateAjout;
}

Ce code nous permettra ainsi de manipuler nos objets avec une API intuitive:

$affaire = $repository->get($id);
foreach ($affaire->getEntreprises() as $entreprise) {
    // je peux accéder directement aux informations utiles à mon contexte
    $entreprise->getSiren();
}

$affaire->getEntreprises()[0]->getSiren();

Comme je l’ai rapidement évoqué précédemment, l’obtention des détails d’une entreprise (ainsi que leurs mises à jour) n’est pas de la responsabilité de notre contexte (ces informations ne sont pas utiles et doivent/peuvent évoluer de manière indépendante à notre système).

Au travers de cette nouvelle modélisation, notre agrégat ne travaille dorénavant plus avec des données partagées et dont il n’a pas la maîtrise. Il n’est plus dépendant de modifications extérieures puisqu’il n’y a plus d’objets en commun.

Si maintenant notre code doit être amené à afficher des informations concernant des informations additionnelles aux données traitées par notre agrégat (comme par exemple le nom de la société que nous ne stockons pas) cela pourra se faire à la demande au moyen de sources données externes. Ces dernières ayant la responsabilité de gérer la donnée et de la mettre à jour, garantissant ainsi que notre contexte accédera toujours à une donnée à jour.

La notion d'agrégat en DDD

Sun, 18 Oct 2020 00:00:00 +0200

La notion d’agrégat est un principe essentiel de la conception pilotée par le domaine (Domain Driven Design). L’agrégat désigne un groupe d’objets du domaine qui doit être manipulé comme une seule unité métier et dont les relations enfants ne peuvent être utilisées de manière indépendante.

Prenons par exemple le cas d’une facture. Une facture est composée de différentes propriétés: un émetteur, un destinataire, une date, un identifiant ainsi qu’une liste de produits ou prestations. Dans une modélisation orientée DDD, la facture est un agrégat car les différents éléments qui la composent n’ont pas de raison d’exister unitairement.

De ce fait, toute modification de notre facture doit se dérouler au sein de notre agrégat. Il ne devrait par exemple, pas être possible d’ajouter une nouvelle ligne sans passer pas notre objet de base Facture. De la même façon, il ne devrait pas être possible de récupérer des éléments de notre facture sans passer cette dernière. Cela implique que lorsque l’on récupère ou enregistre un agrégat, toutes les données de ce dernier sont traités en un seul bloc.

Ci-dessous un exemple de comment nous pourrions modéliser l’ajout de ligne à notre Facture:

class Facture
{
	/** @var FactureLigne[] */
	private array $lignes;

	public function lignes(): array
	{
		return $this->lignes;
	}

	public function ajouterLigne(FactureLigne $ligne): self
	{
		// règles de validations
		// ...

		$this->lignes[] = $ligne;

		return $this;
	}
}

// utilisation dans le code applicatif
$facture = new Facture(/* ... */);
foreach ($produits as $produit) {
	$facture->ajouterLigne(/* ... */);
}

$entityManager->save($facture);

L’un des principaux avantages de ce mode de fonctionnement est que l’on garantie ainsi la cohérence de notre objet tout au long de son utilisation. Il est seul responsable des règles de validation, qui sont alors centralisées au sein de notre agrégat et assure ainsi la cohérence des données.

Si cette modélisation peut paraître logique pour certains, on trouve de nombreuses applications CRUD qui ne modélisent pas les données de cette manière. La facture et les lignes associées étant parfois gérées indépendamment.

class Facture
{ /* ... */ }

class FactureLigne
{ /* ... */ }


// utilisation dans le code applicatif
$facture = new Facture(/* ... */);
$entityManager->save($facture);

foreach ($produits as $produit) {
	$ligne = new FactureLigne(/* ... */);
	$entityManager->save($ligne);
}

Dans l’exemple précédent, les lignes de facture étant ajoutées en dehors du contexte de notre facture, rien n’assure que les données des lignes soient cohérentes avec l’état de notre facture. Par exemple, si la facture est payée, il ne devrait pas être possible de pouvoir la modifier. Or si les actions de modification se déroulent en dehors de notre agrégat, il sera difficile de garantir ces règles métiers (cela ne sera pas impossible, mais les règles de validation risquent de se retrouver éparpillées dans le code au lieu d’être centralisées dans l’objet qui a la connaissance de son contexte).

Dans son article sur le sujet, Martin Fowler ajoute:

Les agrégats sont parfois confondus avec les classes de collection (telles que les listes). Les agrégats sont des concepts du domaine, tandis que les collections sont génériques. Un agrégat contient souvent des collections et des champs simples. Le terme “agrégat” est commun et est utilisé dans différents contextes, mais il ne fait pas forcément référence au même concept que les agrégats dans un contexte de conception pilotée par le métier.

Les agrégats permettent de garantir la consistance des objets de votre application. Que vous développiez une application DDD ou CRUD, je ne peux que vous conseillez d’utiliser ce pattern.

–

Make or buy

Wed, 15 Jul 2020 00:00:00 +0200

J’adore quand une boite qui fait plusieurs millions de CA te dis qu’un outil à 8€/mois pour 10 personnes c’est pas donné...
— Jérémy DECOOL (@jdecool) 15 juillet 2020

Voici un tweet que j’ai publié il y a quelques heures et qui peut paraître un peu abrupte. C’est pourtant une situation que j’ai pu constater et que je constate encore fréquemment en entreprise: faire toutes les économies possibles.

Et ce, même s’il s’agit de somme relativement dérisoire à l’échelle de l’entreprise. Dans le cas de ce tweet, l’outil en question avait un coût de 8€/mois/utilisateur et concerne grosso modo 10 utilisateurs (soit un coup de 80€/mois, environ 960€/an). La société en question emploie quasiment une centaine de personnes et réalise plusieurs millons de chiffre d’affaire chaque année. Que représente ce coût à l’échelle de la société au final ? Une goutte d’eau.

Il est important de se poser les bonnes questions et de raisonner correctement. La vraie question, c’est le make or buy. Combien de temps, d’économie (de temps et/ou d’argent) fait gagner l’outil que l’on souhaite mettre en place ? Si on décidait de le faire soi-même, quel serait le vrai coût au final ? Dans ces cas-là il faut penser au salaire des personnes qui vont travailler sur la conception, la réalisation et la maintenance de l’outil. Quel en serait le coût d’exploitation ?

Je pense qu’au final, sur un coût aussi dérisoire, pour un outil qui n’est pas stratégique et n’a aucune valeur ajoutée pour l’entreprise, on ne devrait même pas se poser la question.

Pour la petite anecdote, cela me rappelle une situation vécue il y a quelque temps. Une équipe de développeurs utilisait un outil dans le cadre de son travail. Un outil qui avait été remis en cause à cause d’une tarification qui “n’était pas justifiée”. L’outil en question avait donc été remplacé par une alternative Open Source (car considérée comme gratuite).

Au final, la solution nouvellement en place, n’a pas réellement conquis l’équipe car jugé plus complexe à utiliser. Et chose que je trouve assez paradoxale, c’est rien que le serveur nécessaire pour faire tourner la plateforme coutait deux fois plus cher que la solution initiale (sans compter le temps passer par les personnes pour la mise en place et l’exploitation).

En me relisant, je trouve que ce billet fait incroyablement écho à un article d’Eric DASPET sur toutes ces petites économies qui coûtent un pognon de dingue.

Utiliser MinIO comme stockage de données objets en PHP

Tue, 07 Jul 2020 00:00:00 +0200

Je travaille sur un projet où il est question de stocker un grand nombre de fichiers. Ce dernier devrait être hébergé dans le Cloud et notamment sur des infrastructures orientées Serverless. Il est donc impensable d’utiliser un système de fichiers “classique” pour stocker des fichiers. Je me suis donc tourné vers les systèmes de stockage objet (type Amazon S3). C’est alors qu’en effectuant quelques recherches, j’ai découvert MinIO. Il s’agit d’un serveur de stockage open source compatible Amazon S3.

Pour utiliser MinIO avec PHP, vous pouvez simplement utiliser le SDK d’AWS. Après avoir créé votre bucket dans le serveur MinIO, vous pouvez commencer à travailler avec le système de fichier comme vous le feriez avec S3:

$s3 = new Aws\S3\S3Client([
    'version' => 'latest',
    'region'  => 'eu-east-1', // cette configuration n'a pas d'importance pour MinIO
    'endpoint' => 'http://localhost:9000',
    'use_path_style_endpoint' => true, // ce paramètre doit obligatoirement être actif
    'credentials' => [
        'key'    => 'ACCESSKEYID',
        'secret' => 'SECRETACCESSKEY',
    ],
]);

// enregistrer un fichier
$insert = $s3->putObject([
     'Bucket' => 'bucket',
     'Key'    => 'key',
     'Body'   => 'Hello from MinIO!!',
]);

// récupérer un fichier
$retrive = $s3->getObject([
     'Bucket' => 'bucket',
     'Key'    => 'key',
     'SaveAs' => 'key_local',
]);

Voila, ce n’est guère plus compliqué.

Pour ma part, lorsque je travaille avec le système de fichiers, j’ai pour habitude d’utiliser la bibliothèque Flysystem. Si vous ne connaissez pas Flysystem, je vous recommande vivement de vous y intéresser. Il s’agit de composant permettant d’abstraire l’accès à tout système de fichiers. Cela vous permettra d’écrire un code qui sera automatiquement compatible avec votre système de fichiers local, un FTP, mais également un grand nombre de fournisseur Cloud tel que Amazon S3 ou Azure Blob Storage.

Une fois le composant de base league/flysystem et l’extension league/flysystem-aws-s3-v3 installé avec l’aide de Composer. Il vous suffit de créer l’adapteur qui va bien:

$s3 = new Aws\S3\S3Client([
    'version' => 'latest',
    'region'  => 'eu-east-1', // cette configuration n'a pas d'importance pour MinIO
    'endpoint' => 'http://localhost:9000',
    'use_path_style_endpoint' => true, // ce paramètre doit **obligatoirement** être actif
    'credentials' => [
        'key'    => 'ACCESSKEYID',
        'secret' => 'SECRETACCESSKEY',
    ],
]);

$adapter = new League\Flysystem\AwsS3v3\AwsS3Adapter($client, 'bucket');
$filesystem = new League\Flysystem\Filesystem($adapter);

// enregistrer un fichier
$filesystem->put('my-file.txt', 'Hello from MinIO!!');

// récupérer un fichier
$object = $filesystem->get('my-file.txt');

Si vous utilisez Symfony, en ce qui me concerne j’utilise le bundle oneup/flysystem-bundle. Pour Laravel le composant le plus complet semble être graham-campbell/flysystem.

Tout ça pour dire, que si vous souhaitez utiliser un système de stockage objet et que vous souhaitez héberger vous même ce dernier, je ne peux que vous conseiller de jeter un coup d’oeil à MinIO.

Définition du rôle de Tech Lead

Mon, 01 Jun 2020 00:00:00 +0200

Je me suis déjà exprimé plusieurs fois sur le rôle de lead dev. Je découvre aujourd’hui la définition de Patrick KUA (si vous ne le connaissez pas, je vous recommande vivement de vous intéresser à son blog) sur le sujet.

Si ce n’est pas déjà fait, je vous recommande vivement la lecture du billet avec lequel je suis assez en phase et que Patrick résume de la manière suivante:

“A Tech Lead is a software engineer responsible for leading a team and alignment of the technical direction.”

On est donc bien dans ce que je qualifiais d’assistant du CTO. Ce dernier est donc une personne technique (un développeur) qui s’implique pour communiquer une vision technique et gérer la qualité des livrables de l’équipe.

Toujours selon la définition de Patrick, c’est aussi à lui qu’incombe de résoudre les désaccords techniques qu’il peut y avoir. Bien que sur cette dernière partie, j’avais estimé que le lead dev ne devait pas avoir de missions managériales, on peut y voir ici un aspect de management pour lequel je ne peux qu’admettre que cela doit faire partie des attributions du poste.

Cela ne doit pas empêcher de trouver une solution collégialement avec les différents membres de l’équipe, mais en cas de forts désaccords, il faut bien que quelqu’un puisse trancher. D’ailleurs à propos de trancher, je ne peux que vous renvoyer vers l’excellent article de Gilles ROUSTAN toujours aussi pertinent. Trancher, ce n’est pas forcément aller dans le sens que l’on avait initialement imaginé.

Cohérence des données dans un modèle orienté objet

Sat, 04 Apr 2020 00:00:00 +0200

On ne présente plus la programmation orientée objet, c’est aujourd’hui l’un, si ce n’est le paradigme de programmation informatique le plus utilisé. Le concept central de ce paradigme: “les objets représentent un concept, une idée ou toute entité du monde physique” (définition Wikipédia). Le principal avantage de la programmation orientée objet (POO en abrégé) est de permettre de rassembler au sein d’une structure de données, les propriétés et les actions (méthodes) qui sont liées au concept que l’on manipule. Une des règles essentielles de la POO est que toute action/modification d’un objet doit laisser ce dernier dans un état cohérent.

Mais qu’entend-on par état cohérent ? La cohérence d’un système peut être définie comme une exigence selon laquelle toute modification de l’état de ce dernier doit conserver la validité des données selon les règles et contraintes qui le déterminent.

C’est une jolie définition mais concrètement, ça veut dire quoi ? Prenant comme exemple, un objet Facture. Une facture est composée de 4 propriétés: une date, un montant HT, une TVA et un montant TTC (cette dernière est discutable, mais l’exemple vous permettra de bien comprendre). On pourrait donc écrire une première version de notre objet comme ceci:

class Facture
{
    private DateTime $date;
    private float $montantHT;
    private float $tva;
    private float $montantTTC;

    public function __construct(DateTime $date, float $montantHT, float $tva, float $montantTTC)
    {
        $this->date = $date;
        $this->montantHT = $montantHT;
        $this->tva = $tva;
        $this->montantTTC = $montantTTC;
    }

    public function getDate(): DateTime
    {
        return $this->date;
    }

    public function getMontantHT(): float
    {
        return $this->montantHT;
    }

    public function getTVA(): float
    {
        return $this->tva;
    }

    public function getMontantTTC(): float
    {
        return $this->montantTTC;
    }
}

Vous voyez ce qui ne va pas avec cette classe ? Cette dernière nous permet de créer une facture qui pourrait être $facture = new Facture(new DateTime('2020-04-02 18:00:00'), 10.0, 0.1, 50.0) ce qui ne serait pas du tout logique, les trois propriétés de notre facture sont liées entre elles et ne peuvent pas prendre n’importe quelles valeurs. Notre facture est donc dans un état incohérent.

En POO, le constructeur est une fonction appelée lors de l’instanciation d’un objet. Le rôle du constructeur est double, il doit initialiser les propriétés de notre objet, mais il doit également s’assurer que les données sont cohérentes. Dans notre exemple, il doit s’assurer que le montant TTC de notre facture correspond au montant HT auquel s’ajoute le pourcentage de TVA et renvoyer une erreur si ce n’est pas le cas.

class Facture
{
    public function __construct(DateTime $date, float $montantHT, float $tva, float $montantTTC)
    {
        if (($montantHT * (1 + $tva)) !== $montantTTC) {
            throw new DomainException();
        }

        $this->date = $date;
        $this->montantHT = $montantHT;
        $this->tva = $tva;
        $this->montantTTC = $montantTTC;
    }
}

Nous l’avons rapidement mentionné dans l’introduction de ce billet, il est possible de créer des actions sur nos objets. Dans notre exemple, nous souhaiterions par exemple pouvoir modifier le taux de TVA. Dans la plupart des projets informatiques, cela se fait via la création d’une méthode setTVA dont l’implémentation pourrait ressembler à :

class Facture
{
    // ...

    public function setTVA(float $tva): void
    {
        $this->tva = $tva;
    }
}

Rien ne vous choque ? Si cette méthode nous permet effectivement de modifier le taux de TVA de notre facture, cette dernière peut mettre dans un état incohérent notre facture. Par exemple:

// nous construisons un objet valide,
// la cohérence des données est assuré par le constructeur
$facture = new Facture(new DateTime('2020-01-01 00:00:00'), 10.0, 0.1, 11.0);

// nous modifions la TVA (= 20%)
$facture->setTVA(0.2);

// notre objet est maintenant dans un état incohérent
// si nous le montant HT est de 10€, la TVA à 20%
// le montant TTC devrait être de 12€, or voici les
// valeurs portées par notre facture :
//
// class Facture#1 (3) {
//   private $date => class DateTime#2 (3) {
//     public $date => string(26) "2020-01-01 00:00:00.000000"
//     public $timezone_type => int(3)
//     public $timezone => string(13) "Europe/Berlin"
//  }
//   private $montantHT => double(10)
//   private $tva => double(0.2)
//   private $montantTTC => double(11)
// }

Comme nous l’avons déjà dit, toute modification de notre objet doit le laisser dans un état cohérent. Cela signifie donc que s’il est effectivement possible de modifier la TVA de notre facture, le montant TTC doit également être mis à jour en conséquence pour que notre valide soit toujours valide.

class Facture
{
    // ...

    public function setTVA(float $tva): void
    {
        $this->tva = $tva;

        $this->montantTTC = $this->montantHT * (1 + $this->tva);
    }
}

Imaginons maintenant que cette classe est issue d’une application en production et que l’on nous demande d’implémenter une nouvelle fonctionnalité: à partir du mois d’avril 2020, la TVA aura un taux constant de 30%. Lors du développement de cette fonctionnalité, il est primordial que le fonctionnement des factures antérieures à cette date ne soit pas modifié.

Si l’on souhaite effectuer ce changement rapidement, en modifiant un minimum de code, une solution naïve pourrait alors être implémentée comme ceci :

class Facture
{
    private DateTime $date;
    private float $montantHT;
    private float $tva;
    private float $montantTTC;

    public function __construct(DateTime $date, float $montantHT, float $tva, float $montantTTC)
    {
        if (($montantHT * (1 + $tva)) !== $montantTTC) {
            throw new DomainException();
        }

        $this->date = $date;
        $this->montantHT = $montantHT;
        $this->tva = $tva;
        $this->montantTTC = $montantTTC;
    }

    public function getDate(): DateTime
    {
        return $this->date;
    }

    public function getMontantHT(): float
    {
        return $this->montantHT;
    }

    public function getTVA(): float
    {
        if ($this->date->after('2020-04-01')) {
            return 0.3;
        }

        return $this->tva;
    }

    public function getMontantTTC(): float
    {
        return $this->montantTTC;
    }
}

Si le code permet effectivement de répondre à la demande qui a été formulée, ce dernier va poser de nombreux problèmes.

Tout d’abord le code précédent enfreint la première règle que nous avons évoquée sur le constructeur. Effectivement, dans le cas présent, rien ne nous empêcherait de créer l’objet facture suivant $facture = new Facture(new DateTime('2020-04-02 18:00:00'), 10.0, 0.1, 50.0). Or, il y a ici une incohérence, puisqu’il ne devrait pas être possible de créer un tel objet, le taux de TVA devant être à 30% à partir du mois d’avril. Il est probable que les données renseignées proviennent d’une interface utilisateur ou d’une API, ce qui signifierait ici que l’utilisateur n’est en plus pas averti d’une erreur de saisie.

Pire encore, si cette solution est une source de confusion pour l’utilisateur final, le code est également une source d’erreurs pour les développeurs. En effet, lorsqu’on lit le nom de la méthode getTVA, on est en droit de s’attendre à ce qu’elle renvoie la valeur de la propriété correspondante. Or ce ne serait pas le cas ici, puisque la donnée peut potentiellement être modifiée à la volée selon la valeur des autres propriétés de la facture.

Voilà qui conclut cette introduction à la notion de cohérence dans un modèle objet. Si ce sujet vous intéresse et que vous souhaitez aller plus loin, je ne peux que vous encourager à fouiller du côté du Domain Driven Design (DDD). Matthias NOBACK a également écrit un livre où il présente des techniques pour écrire un code orienté objet de qualité et pérenne (où il est notamment question de cohérence de données) que je ne peux que vous recommander.

La confusion entre symptôme et problème

Mon, 16 Mar 2020 00:00:00 +0100

Dans mon travail de développement logiciel, il m’arrive régulièrement de parler de causes et conséquences. Il n’est en effet pas rare, lors de la correction d’un bug, de résoudre la conséquence d’un problème sans pourtant autant en corriger la cause de ce dernier. Ce qui implique qu’en réalité l’anomalie est toujours présente dans l’application et resurgira tôt ou tard sous une autre forme.

J’ai toujours souhaité écrire un billet à ce sujet, mais je n’ai jamais réussi à trouver les mots pour exprimer le message que je souhaitais faire passer. Je découvre aujourd’hui (merci Serge) une vidéo sur le sujet que je souhaite donc vous partager :

Interroger un serveur DNS

Tue, 18 Feb 2020 00:00:00 +0100

Le protocole DNS (Domain Name System) est un protocole central du web. C’est ce dernier qui est chargé de communiquer l’adresse IP associée à un nom de domaine. Pour gérer au mieux la croissance de cet “annuaire”, le protocole s’appuie sur un système distribué. Comme Wikipédia le décrit assez simplement, la résolution d’un nom de domaine peut nécessiter d’interroger plusieurs serveurs pour obtenir la réponse finale. De manière simplifiée, ce système implique donc une synchronisation de données entre les différents serveurs. C’est notamment pour cela que lorsque l’on déclare un domaine, ce dernier n’est pas instantanément disponible. C’est ce que l’on appelle la propagation des DNS.

Je travaille actuellement sur un projet qui met à jour un grand nombre de DNS de manière relativement régulière. La propagation des DNS pouvant mettre un certain temps à être pris en compte, je souhaite pouvoir interroger directement un serveur DNS afin de pouvoir savoir si la modification que j’ai effectuée à été propagée sur ce dernier.

Pour cela, j’utilise la commande nslookup qui me permet d’envoyer une requête sur le serveur DNS utilisé par ma machine:

$ nslookup jdecool.fr

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	jdecool.fr
Address: 51.15.134.254

Mais je peux également spécifier à la commande, le serveur DNS que je souhaite requêter. Par exemple, les DNS de Google:

$ nslookup jdecool.fr 8.8.8.8

Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	jdecool.fr
Address: 51.15.134.254

De cette manière, je peux cibler les principaux serveur DNS afin d’avoir un aperçu de la propagation des domaines qui m’intéressent.

La gestion des enums en PHP

Mon, 07 Oct 2019 00:00:00 +0200

Un enum, on parle également de type énuméré ou énumération en français, “est un type de donnée qui consiste en un ensemble de valeurs constantes” (source Wikipédia). Il s’agit d’une structure très pratique, mais qui n’existe malheureusement pas nativement dans PHP.

Si l’on se réfère à la documentation officielle de PHP, il existe bien un type similaire au travers de la classe SplEnum. Mais cette structure de données a le défaut de nécessiter l’installation d’une extension supplémentaire ce qui peut ne pas être une opération triviale pour une application de production si cela n’est pas prévu en avance.

C’est pour cela qu’il existe de nombreux composants qui permettent de mettre en place un système qui se rapproche d’un enum. Pour ma part, j’utilise régulièrement myclabs/php-enum. Une bibliothèque qui m’a rendu de nombreux services à maintes reprises et qui fait très bien le travail.

Elle a pourtant un défaut qui m’a posé un problème sur un projet récemment. La plupart des composants d’enum en PHP fonctionnent suivant le même principe. Il s’agit d’une classe de base qui est étendue dans notre code et à laquelle on attache des constantes. Par exemple:

class WeekDay extends Enum
{
    public const MONDAY = 'monday';
    public const TUEDAY = 'tuedsay';
    // ...
}

Il est ensuite possible dans notre code, d’utiliser la notation WeekDay::MONDAY() pour récupérer une instance de notre enum.

Le problème que j’ai par exemple rencontré avec myclabs/php-enum est que chaque appel à WeekDay::MONDAY() retourne une nouvelle instance de classe. Cela signifie que lorsque l’on récupère deux fois le même enum.

WeekDay::MONDAY() == WeekDay::MONDAY() // true
WeekDay::MONDAY() === WeekDay::MONDAY() // false

Cela peut-être problématique car dans mon cas, il m’arrive par exemple d’utiliser la classe SplObjectStorage pour stocker des associations de données.

Par exemple, si je conçois une application qui permet à des utilisateurs d’indiquer leur humeur de la journée, je souhaite par exemple pouvoir associer un jour de la semaine (via notre enum WeekDay) avec une humeur (qui serait également géré au travers d’un enum Mood). Or si chaque élément de mon énumération est systématiquement une instance d’objet différente, il est alors impossible de travailler avec le code suivant:

$userMood = new SplObjectStorage();
$userMood->attach(WeekDay::MONDAY(), Mood::GOOD());

$userMood->contains(WeekDay::MONDAY()); // false

Pour remédier à cette problématique, j’ai découvert le composant marc-mabe/php-enum qui permet également de gérer un système d’énumération. À la différence de myclabs/php-enum, cette bibliothèque renverra toujours la même instance pour une même donnée de notre enum. Ce qui en reprenant notre code précédent, donnerait la chose suivante:

WeekDay::MONDAY() == WeekDay::MONDAY() // true
WeekDay::MONDAY() === WeekDay::MONDAY() // true

À ce stade, vous vous dites certainement que mon choix est maintenant fait et que dorénavant j’utiliserai de manière systématique marc-mabe/php-enum. Pourtant tout n’est pas aussi simple. Si on a vu un avantage d’une des bibliothèques par rapport à l’autre, il y a une fonctionnalité de myclabs/php-enum que j’affectionne tout particulièrement: le fait de pouvoir mettre les constantes en privées.

class WeekDay extends Enum
{
    private const MONDAY = 'monday';
    private const TUEDAY = 'tuedsay';
    // ...
}

C’est pour moi un énorme avantage car lorsque j’utilise un enum, je ne souhaite pas savoir comment il est construit à l’intérieur, comment il fonctionne. Je veux simplement l’utiliser. Or si les constantes sont publiques, cela signifie que la donnée est visible par le développeur et pire encore, qu’il est possible qu’il l’utilise en dehors de l’énumération.

Comme toujours dans l’ingénierie logicielle, il vous faudra faire le bon choix selon votre problématique et le choix de votre implémentation technique.

Tout ce que vous devez savoir sur PHP 7.4

Thu, 03 Oct 2019 00:00:00 +0200

La fin de l’année approche à grand et comme d’habitude, nous autres développeurs PHP auront sous le sapin une nouvelle version de PHP à notre disposition. La version 7.4 est une version que j’attends avec impatience notamment pour la possibilité de pouvoir typer les propriétés de classe. Ce changement s’inscrit dans la continuité du langage d’avoir un typage fort.

Comme avec l’arrivée de chaque nouvelle version, les équipes de PHP ont publié un guide de migration de la version 7.3 vers la version 7.4 incluant notamment les nouvelles évolutions du langage, les nouvelles classes, interfaces fonction et constante à disposition des développeurs, mais aussi les fonctionnalités dépréciées, les changements non rétro-compatibles ainsi que les extensions supprimées.

Je vous conseille fortement d’y jeter un coup d’oeil, mais attention le guide est tout frais et n’est actuellement disponible qu’en anglais !

Mettre en place une Review App d'application statique

Fri, 23 Aug 2019 00:00:00 +0200

J’ai décidé d’écrire une série de quelques billets sur la gestion des Review Apps. Ces dernières représentent aujourd’hui une partie du Saint Graal des équipes de développement et DevOps. Le concept de Review Apps a été popularisé par Gitlab et consiste à déployer automatiquement du code applicatif depuis une branche de développement. Cela permet entre autres, de pouvoir tester une fonctionnalité avant d’intégrer le code de cette dernière dans une branche de production. La boucle de feedback est alors réduite à son maximum puisqu’il est possible de tester un développement pendant sa réalisation. Dans ce billet, nous allons nous intéresser au cas le plus simple de déploiement d’une Review Apps, à savoir déployer une application web statique.

Commençons tout d’abord par expliquer concrêtement ce qui va être mis en place. Lorsque nous écrivons du code, nous travaillons généralement sur une branche (d’un système de versionning) dédiée. Une fois notre développement terminé, le code est revu, validé puis intégré dans une branche de production commune à toute l’équipe. L’objectif de la mise en place de notre Review App sera de créer un environnement fonctionnel de notre application qui sera rattaché à la branche de travail du développeur. Cela va se traduire par un déploiement de la branche qui sera accessible via une adresse de type application.[nom-de-la-branche].domaine.tld.

Avant toute chose, je vais partir du principe que nous avons déjà une machine en place, configurée et opérationnelle avec un serveur HTTP installé. Dans ce billet, j’utiliserai NGINX, mais le principe est transposable sur n’importe quel autre serveur. Je suppose également que les DNS de votre domaine est également déjà configuré de manière à ce que les requêtes vers application.*.domaine.tld soit redirigé vers le serveur HTTP qui va accueillir notre Review App.

Maintenant que ces prérequis sont en place, attaquons le vif du sujet. Nous allons tout d’abird configurer le serveur HTTP pour que les requêtes de type application.[nom-de-la-branche].domaine.tld accède aux sources présentes dans le dossier suivant le motif /var/www/application/[nom-de-la-branche]. Avec NGINX, cela se fait relativement simplement en configurant la directive server_name au travers d’une expression régulière:

server {
    listen 80;

    server_name ~^application.(?<sname>.+?).domaine.tld$;
    root /var/www/application/$sname;

    index index.html;
}

Une fois la configuration du serveur HTTP réalisé, nous allons nous occuper du déploiement de l’application. Cette dernière étant statique (c’est par exemple le cas de ce blog qui est généré par Jekyll), nous pouvons imaginer d’utiliser une commande telle que rsync pour copier les fichiers source dans le répertoire qui doit accueillir notre Review App. Cette commande serait idéalement lancer par votre CI (si vous en avez une), par un webhook configuré au travers de votre gestionnaire de code source ou (mais je ne vous le souhaite pas) à la main.

Pour ma part, j’utilise un script Bash prenant 2 paramètres en entrée: l’adresse du serveur sur lequel je souhaite déployer mon code et le dossier de destination. Le script s’assure alors que le dossier de destination existe, en le créant à défaut et effectue ensuite la copie des fichiers. Une version simplifiée de ce dernier pourrait ressembler à:

#!/bin/bash

HOST=$1
DIR=$2

ssh user@$HOST "mkdir -p $DIR"
rsync -azv dist/ user@$HOST:$DIR

La gestion de notre Review App est presque terminée. Il ne faudra pas oublier de gérer le cycle de vie de cette dernière, en synchronisant les fichiers lors de la mise à jour de la branche et de supprimer le dossier de travail lors de la suppression de la branche (ou de la validation de la merge request).

Et voilà, ce n’est pas plus compliqué que cela ! Si le terme de Review Apps peut faire peur et sembler complexe, il est possible de mettre en place des solutions simples, rapides et efficaces. Nous verrons dans un prochain billet comment mettre en place ce système avec une application nécessitant une base de données.

Vous êtes lead dev ? Et maintenant ?

Tue, 13 Aug 2019 00:00:00 +0200

Il y a quelques mois, j’écrivais un article sur le rôle de lead developer afin de donner ma vision sur le travail qui en découle. Je découvre aujourd’hui une présentation de Eryn O’Neil sur le sujet.

The tech lead is the owner of the technological vision for a project, and the technical leader ot the project team

Lorsque l’on devient lead tech ou tech lead, nous avons alors plus de responsabilité que de simplement “coder”. Dans ce cas, il faut faire encore plus attention à la conception et au respect de l’architecture logicielle que l’on souhaite mettre en place. Avec le rôle de lead dev peut également venir des responsabilités supplémentaires comme avoir une vision technique globale du projet, une gestion humaine pour motiver et former l’équipe avec laquelle on est amené à travailler et bien d’autres choses.

It’s fine to admit not knowing something, but never ever as an excuse. “I don’t know”, should burst joyfully from your lips, followed by “but I will find out!”.

Là encore un élément-clé pour moi dans ce rôle. On ne peut pas tout savoir sur tout, mais cela ne doit pas vous empêcher de prendre la ou les bonnes décisions. Trop souvent, les entreprises et les personnes qui la composent n’ose pas s’aventurer en dehors de ce qu’il ne connaisse pas et/ou n’ont jamais pratiqué.

Je ne sais pas pour vous, mais je ne compte plus les fois ou une personne à refuser de faire une tâche parce que cela la faisait sortir de sa zone de confort. Et quand je parle de zone de confort, cela peut très bien être quelque chose comme écrire un bout de code en utilisant un pattern non connu.

Donc si vous vous reconnaissez dans ces quelques lignes, que vous souhaitez en savoir plus ou tout simplement que vous vous intéressez au poste de lead, je vous commande vivement de regarder la présentation Congrats! You’re the tech lead - now what? présentait lors de la conférence The Lead Developer à New York en 2017.

Mettre à jour automatiquement une description sur le Docker Hub

Sun, 28 Jul 2019 00:00:00 +0200

Le Docker Hub c’est le registre officiel d’image Docker. L’annuaire où toutes les personnes qui créent et maintiennent des images Docker peuvent les mettre à la disposition de tous. Pour avoir le plus de succès possible, il est alors important de bien remplir la description de son image, en expliquant ce qu’elle contient, dans quel objectif a-t-elle était créée et surtout comment l’utiliser !

Pour les images évoluant de manière régulière, il peut être fastidieux de maintenir cette description à jour. Cette dernière étant généralement versionnée dans un dépôt avec les fichiers Dockerfile. C’est un cas que je rencontre avec les nightly builds des versions en développement de PHP où je dois maintenir à la fois le README du projet et la description sur le Docker Hub.

Pour simplifier ce travail et éviter la double intervention, j’ai récemment découvert les possibilités offertes par l’API de Docker Hub. Il existe ainsi une API permettant de mettre à jour les informations d’une image disponible dans l’annuaire. J’ai donc créé un script Shell qui lit le fichier README du dépôt et qui met à jour la description de l’image directement sur le Docker Hub.

#!/bin/bash

set -e

TOKEN=$(curl -s -X POST \
    -H "Content-Type: application/json" \
    -d '{"username": "'"$DOCKER_USERNAME"'", "password": "'"$DOCKER_PASSWORD"'"}' \
    https://hub.docker.com/v2/users/login/ | jq -r .token)

CODE=$(jq -n --arg msg "$(<README.md)" \
    '{"registry":"registry-1.docker.io","full_description": $msg }' | \
        curl -s -o /dev/null -L -w "%{http_code}" \
           https://cloud.docker.com/v2/repositories/"${DOCKER_IMAGE}"/ \
           -d @- -X PATCH \
           -H "Content-Type: application/json" \
           -H "Authorization: JWT ${TOKEN}")

if [[ "${CODE}" = "200" ]]; then
    printf "Successfully pushed README to Docker Hub\n"
else
    printf "Unable to push README to Docker Hub, response code: %s\n" "${CODE}"
    exit 1
fi

Ce dernier s’utilise comme ceci:

DOCKER_USERNAME=username \
  DOCKER_PASSWORD=password \
  DOCKER_IMAGE="user/image" \
  ./script.sh

Et voilà le tour joué !

Et pour rendre à Caesar ce qui appartient à Caesar, je n’ai aucun mérite. C’est en réalisant quelques recherches sur Internet que je suis tombé sur un projet qui avait la même problématique et que j’ai adapté le code à ce que je voulais en faire.

Déployer un projet PHP depuis un monorepo

Sun, 19 May 2019 00:00:00 +0200

Je parlais dans un billet précédent de comment publier des composants PHP sur Packagist depuis un dépôt de code monolithique. Une autre question récurrente venant des équipes projet qui souhaitent mettre en place ce type de structure est: comment déployer un sous-projet du dépôt de manière indépendante ?

En effet, il y a quelques années un formidable outil, Capistrano, a modifié la manière dont nous déployons nos applications. Capistrano est un outil Open Source développé en Ruby qui permet d’automatiser le processus de création et de publication d’une application sur un ou plusieurs serveurs Web (source Wikipédia). L’outil a eu un tel succès que différentes alternatives basées sur le même principe sont apparues. On peut par exemple citer Deployer en PHP ou Ansistrano une solution équivalente fonctionnant avec Ansible.

Nous avons donc avec ces solutions pris l’habitude de déployer nos applications en clonant directement le dépôt de sources (que ce soit Git ou Subversion auparavant) afin de déployer le tag ou la branche de production de nos projets. Or lorsque l’on souhaite opter pour une approche monorepo, cela signifie que notre déploiement va cloner tous les projets composant notre dépôt de code. Bien que cela puisse être envisagé dans certains cas, c’est loin d’être une solution optimale (notamment quand vous allez vouloir mettre vos applications sur différents serveurs).

Cloner un dépôt de source n’est qu’une solution parmi tant d’autres pour déployer nos projets. C’est également omettre que les outils qui font ce travail pour nous sont un peu plus intelligents que cela et offrent de nombreuses autres possibilités. En plus de pouvoir cloner un dépôt Git, les solutions d’automatisations sont bien souvent capables de copier des fichiers localement sur un système de fichiers, par FTP ou encore via SSH. C’est donc une stratégie de copie qui peut ne pas remettre en cause votre processus de déploiement ni même la configuration (ou très peu) de ce dernier.

Prenons par exemple une configuration de base générée par Deployer (le principe sera le même pour l’ensemble des outils, mais la syntaxe de configuration variera):

<?php

namespace Deployer;

require 'recipe/common.php';

set('application', 'my_project');
set('repository', 'https://github.com/foo/bar.git');

set('git_tty', true);

set('shared_files', ['shared-files.php']);
set('shared_dirs', ['var/log']);
set('writable_dirs', ['data/uploads']);

host('project.com')
    ->set('deploy_path', '~/');

desc('Deploy your project');
task('deploy', [
    'deploy:info',
    'deploy:prepare',
    'deploy:lock',
    'deploy:release',
    'deploy:update_code',
    'deploy:shared',
    'deploy:writable',
    'deploy:vendors',
    'deploy:clear_paths',
    'deploy:symlink',
    'deploy:unlock',
    'cleanup',
    'success'
]);

after('deploy:failed', 'deploy:unlock');

Comme je l’ai évoqué juste avant, par défaut la configuration se base sur un dépôt Git pour déployer (ici https://github.com/foo/bar.git). Lors du processus de déploiement l’ensemble des tâches deploy seront exécutées. C’est au niveau de la tâche deploy:update_code que tout se joue. C’est cette dernière qui va mettre à jour le code sur notre serveur project.com en clonant le dépôt spécifié dans la configuration repository.

Nous devons donc modifier cette tâche afin de déployer non plus via Git, mais en effectuant une copie de fichier en SSH (via rsync dans notre cas). Pour cela, nous allons installer les recettes additionnelles de Deployer via Composer : composer require --dev deployer/recipes. Nous pourront ensuite ajouter la configuration nécessaire au fonctionnement de cette dernière:

<?php

namespace Deployer;

require 'recipe/common.php';
require 'recipe/rsync.php'; // inclusion de la recette

set('application', 'my_project');
set('repository', 'https://github.com/foo/bar.git');

set('git_tty', true);

set('shared_files', ['shared-files.php']);
set('shared_dirs', ['var/log']);
set('writable_dirs', ['data/uploads']);

// configuration de rsync
set('rsync',[
    'exclude'      => [
        '.git',
        'var',
        'vendor',
        'deploy.php',
    ],
    'exclude-file' => false,
    'include'      => [],
    'include-file' => false,
    'filter'       => [],
    'filter-file'  => false,
    'filter-perdir'=> false,
    'flags'        => 'rzcE',
    'options'      => ['delete'],
    'timeout'      => 60,
]);

// configuration du répertoire devant être copié et sa destination
set('rsync_src', __DIR__);
set('rsync_dest', '');

host('project.com')
    ->set('deploy_path', '~/');

desc('Deploy your project');
task('deploy', [
    'deploy:info',
    'deploy:prepare',
    'deploy:lock',
    'deploy:release',
    'rsync', // pour finir nous remplaçons la tâche de déploiement Git
    'deploy:shared',
    'deploy:writable',
    'deploy:vendors',
    'deploy:clear_paths',
    'deploy:symlink',
    'deploy:unlock',
    'cleanup',
    'success'
]);

after('deploy:failed', 'deploy:unlock');

Et voilà ! Nous avons maintenant notre projet dont le fonctionnement est identique à la première version mis à part que la copie des fichiers ne se fait plus via un clone du dépôt Git, mais via une copie de fichier en SSH.

Il se peut que vous ne souhaitiez pas modifier ce qui est fait par la tâche deploy. C’est le cas, si par exemple vous déployez un projet Symfony en utilisant la recette fournie par Deployer. Dans ce cas, remplacer la tâche update_code par rsync vous obligerez à redéfinir l’ensemble des opérations de déploiement, ce qui peut-être gênant.

Il est alors préférable de redéfinir uniquement le fonctionnement de la tâche update_code.

<?php

namespace Deployer;

require 'recipe/symfony4.php';
require 'recipe/rsync.php';

set('application', 'my_symfony_project');

add('shared_files', ['.env']);
add('shared_dirs', ['var/log']);
add('writable_dirs', ['var']);

set('rsync',[
    /* configuration rsync */
]);

set('rsync_src', __DIR__);
set('rsync_dest', '');

// surchage de la tâche `deploy:update_code`
task('deploy:update_code', function() {
    invoke('rsync'); // appel de la tâche `rsync`
});

host('symfony-project.com')
    ->set('deploy_path', '~/');

Avec ce genre de configuration, vous avez donc la possibilité de déployer les projets présents dans votre monorepo de manière complètement indépendante.

J’ai dans ce billet, principalement évoqué comment configurer Deployer, mais comme je l’ai précisé au début de ce billet, les autres outils peuvent fonctionner avec le même principe. Par exemple, si vous utilisez Ansistrano, vous devrez rajouter les configurations ci-dessous à votre playbook Ansible pour effectuer une copie de fichier rsync:

vars:
    # ...
    ansistrano_deploy_via: "rsync"
    ansistrano_rsync_extra_params: ""
    ansistrano_rsync_set_remote_user: yes
    ansistrano_rsync_path: ""
    ansistrano_rsync_use_ssh_args: no

Publier des dépendances PHP sur Packagist dans un projet monorepo

Sat, 18 May 2019 00:00:00 +0200

Les dépôts monolithiques (on parle également de dépôt monorepo ou monorepository) consistent tout simplement à avoir un dépôt de code unique regroupant plusieurs projets. Cela peut être des applications distinctes (dans le cas de microservices), des composants d’un même projet (une API, avec son interface et éventuellement des bibliothèques de code autonomes) ou tout le code appartenant à une société.

À la différence d’un projet de type monolithe, chaque projet gère de manière indépendante ses propres dépendances. Cela permet d’avoir une gestion plus fine des dépendances de chaque projet, mais également de pouvoir utiliser des technologies différentes si le besoin le nécessite. On peut par exemple imaginer: une UI de type SPA développée en Javascript fonctionnant avec un backend composé d’une API PHP et d’un service de gestion des utilisateurs développé en Go. Tout cela centralisé au sein d’un même dépôt.

Je passerai sur les avantages et inconvénients de ce type de gestion du code. Si vous n’êtes pas à l’aise avec le sujet, je vous laisserai vous faire votre propre opinion en parcourant cette liste de ressources.

Si le sujet n’a rien de nouveau, je ne l’ai vu que très rarement utilisé. Je connais très peu de sociétés françaises utilisant ce modèle (je peux les compter sur les doigts de la main). S’il ne s’agit aucunement d’une silver bullet, je suis convaincu que c’est une méthode efficace pour travailler sur certains projets. Par exemple, je travaille actuellement sur une plateforme orientée microservices (une dizaine), utilisée par 3 fronts et également composée de quelques bibliothèques de code indépendantes. Cette plateforme est gérée par une seule et même équipe, ce qui en fait un excellent candidat. Pourtant, nous gérons actuellement chaque brique au sein de son propre dépôt de code.

Mais nous ne sommes pas là pour débattre autour de ce point, mais plutôt pour évoquer comment gérer les dépendances Composer dans un dépôt de code monolithique. C’est un sujet que j’ai déjà abordé il y a quelques années dans un article de ce blog. Mais comment faire lorsque l’on souhaite partager une dépendance Composer sur Packagist.

Vous ne le savez peut-être pas, mais pour déclarer un composant PHP comme une bibliothèque de code pouvant être utilisée via Composer, il est nécessaire que votre code PHP soit présent dans un dépôt de code indépendant avec un fichier composer.json à la racine. Ce mode de fonctionnement n’est donc pas compatible avec un dépôt monolithique.

Pour obtenir ce dépôt de code indépendant, il est bien entendu hors de question de copier à la main les changements. Mais quelles solutions s’offrent à nous dans ce cas ?

La première solution (en partant du principe que vous gérez votre code avec Git) est d’utiliser les subtrees. Ces derniers vont permettre d’extraire une sous-arborescence de votre dépôt afin de le pousser code dans un autre dépôt.

Supposons que notre dossier contienne l’arborescence ci-dessous :

.git
/api
/backend
/ui
/packages
    /package-1
    /package-2

Nous souhaitons extraire le dossier /packages/package-2 dans son propre dépôt afin de publier ce dernier sur Packagist. Pour cela, nous allons commencer par créer le dépôt de code qui accueillera le projet:

$ cd <chemin-nouveau-depot>
$ git init --bare

Nous allons ensuite créer notre sous-arbre Git sur le dépôt original et indiquer un nom de branche :

$ git subtree split --prefix=packages/package-2 -b split

Il ne nous reste plus qu’à pousser les modifications dans le dépôt du composant :

$ git push <chemin-nouveau-depot> split:master

Vous pouvez ensuite pousser le dépôt de code indépendant là où vous le souhaitez et déclarer ce dernier dans Package comme n’importe quel autre dépôt.

Par la suite, vous n’aurez plus qu’à répéter les étapes 2 et 3 afin de mettre à jour le dépôt du composant avec les modifications du dépôt principal. Pour simplifier et automatiser ces mises à jour, je vous recommande vivement d’ajouter ces opérations dans votre intégration continue.

L’utilisation de git subtree split n’est en soi pas compliquée, mais elle est un peu verbeuse et nécessite de jongler entre différents dépôts de code. Il existe des outils pour simplifier cette opération.

Le premier outil auquel je pense (même si je ne l’ai jamais utilisé) est splitsh. Il s’agit de l’outil utilisé pour découper le projet monolithique de Symfony.

Le second outil est un composant PHP développé par Tomáš Votruba, membre reconnu de la communauté PHP. Tomáš a développé un composant qu’il a nommé MonorepoBuilder et qui contient tout un ensemble d’outils pour aider les développeurs à gérer un monorepo. Ce qui nous intéresse particulièrement est la commande de split. Pour l’utiliser, vous devrez récupérer la dépendance via Composer au travers de la commande composer require symplify/monorepo-builder --dev. Il faudra ensuite écrire un fichier de configuration monorepo-builder.yml qui permettra de configurer quel dossier doit être extrait vers quel dépôt.

# monorepo-builder.yml
parameters:
    directories_to_repositories:
        packages/package-1: 'git@github.com:Foo/Package1.git'
        packages/package-2: 'git@github.com:Foo/Package2.git'

Vous n’avez ensuite plus qu’à lancer l’opération via la commande vendor/bin/monorepo-builder split pour extraire le dossier dans son propre dépôt.

Tester une connexion SMTP avec SwiftMailer

Mon, 13 May 2019 00:00:00 +0200

J’ai pour habitude de créer une page de statut dans les applications que je développe afin de tester que l’ensemble des services nécessaires au bon fonctionnement de cette dernière (base de données, serveur mail, API…) sont lancés et correctement configurés. Nous allons voir dans cet article comment tester une connexion SMTP au sein d’une application utilisant le composant SwiftMailer.

Si l’on prend le cas d’usage simple proposé en introduction dans la documentation du composant :

// Create the Transport
$transport = (new Swift_SmtpTransport('smtp.example.org', 25))
  ->setUsername('your username')
  ->setPassword('your password')
;

// Create the Mailer using your created Transport
$mailer = new Swift_Mailer($transport);

// Create a message
$message = (new Swift_Message('Wonderful Subject'))
  ->setFrom(['john@doe.com' => 'John Doe'])
  ->setTo(['receiver@domain.org', 'other@domain.org' => 'A name'])
  ->setBody('Here is the message itself')
  ;

// Send the message
$result = $mailer->send($message);

Le principe pour une connexion est simple, il faut tester que la couche transport puisse se connecter au service. Pour cela, il faut démarrer la connexion vers le serveur SMTP et vérifier si une erreur s’est produite :

try {
    $transport->start();
    $isSmtpOk = true;
} catch (Swift_TransportException $e) {
    $isSmtpOk = false;
}

L’exemple ci-dessus marche bien, mais dans la plupart des cas, nous envoyons rarement directement un mail. Dans une grande majorité des cas, nous allons utiliser un spool de mail qui va stocker les mails que l’on souhaite envoyer pour par la suite effectuer un traitement en lot. C’est par exemple, le fonctionnement par défaut de SwiftMailer dans Symfony.

$spool = new FileSpool(__DIR__.'/var/spool');
$transport = new Swift_SpoolTransport($spool);
$mailer = new Swift_Mailer($transport);

Or dans ce cas, on ne peut pas réellement tester la couche de transport directement car notre instance de la classe Swift_SpoolTransport ne gère pas réellement l’envoi des mails, mais gère la logique permettant de traiter le mail plus tard. De ce fait l’ implémentation de la méthode $transport->start() est vide et ne fait donc aucune action.

Il faudra donc dans ce cas, tester la méthode start directement sur l’instance du spool, à savoir sur notre objet $spool. Et si vous utilisez Symfony, le framework configure un service swiftmailer.transport.real permettant d’accéder à l’instance de l’objet qui gérera réellement l’envoi des mails.

Open source, gratuité et utilisation professionnelle

Mon, 18 Mar 2019 00:00:00 +0100

J’aimerais aujourd’hui, au travers de ce billet, partager une réflexion concernant l’open source, que l’on utilise bien souvent gratuitement, dans un contexte professionnel. Ce billet découle de différentes discussions (aussi bien orales qu’au travers des réseaux sociaux) que j’ai pu avoir un certain nombre de personnes.

Pour bien comprendre le contexte, la semaine dernière, Gitlab a enlevé de son offre gratuite la possibilité de pouvoir approuver une merge request dans les dépôts privés. Il est donc maintenant nécessaire de posséder un compte payant pour accéder à cette fonctionnalité. Or il s’agissait là d’une fonctionnalité très utilisée en entreprise.

À la suite de cela, de nombreuses discussions et plaintes ont eu lieu de la part d’équipes de développement utilisant les offres gratuites de Gitlab. Ces plaintes se sont traduites par exemple par des tweets (trollesques et plus ou moins assassins) auprès de différents employés de Gitlab. De nombreux échanges tournaient également autour d’une migration vers Github.

On peut apprécier ou non Gitlab, le comparer à Github sur de nombreux points, l’objectif principal des deux outils étant de gérer des dépôts Git. Néanmoins les deux outils sont sensiblement différents et n’axent pas leurs développements de la même manière. Github se concentre sur son cœur de métier: la gestion des dépôts. Gitlab s’oriente (et c’est son principal argument marketing) sur l’aspect DevOps.

Mais le fond du problème dans ce que je viens de décrire ici, c’est que de nombreuses entreprises profitent gracieusement d’outils évolués sans jamais contribuer d’aucune sorte à ces derniers. Quand je parle de contributions, cela peut être aussi bien de manière financière qu’en reversant certains développements faisant évoluer des outils open source.

Par contre, ces mêmes sociétés vont se permettre de critiquer les outils, entreprises, voire même les employés de ces dernières sous prétexte qu’on leur “enlève” des fonctionnalités pour un outil pour lequel elles profitent sans aucune contrepartie.

Dans le cas de Gitlab, oui, il est fort probable que ce changement vise à inciter les entreprises à passer à des comptes premium. Je pense même que si certains migrent vers Github, au final ce n’est pas très grave, car ce sont des comptes qui n’auraient jamais basculé vers une offre payante.

Peut-on leur en vouloir pour ça ? Je ne pense pas. Travaillez-vous gratuitement ? Je ne pense pas. Alors pourquoi ces sociétés devraient-elles le faire ? Qui plus est quand les infrastructures pour supporter une qualité de service sont plus que non négligeables.

J’ai pris ici le cas précis de Gitlab, mais des exemples similaires, on en voit presque tous les jours. Cela peut aller de l’entreprise à but lucratif au mainteneur de projets open source travaillant bien souvent seul ou en très petites équipes.

Ce qui m’agace dans cette histoire, c’est que dans le lot des critiques, on retrouve parfois des sociétés faisant des millions d’euros de chiffres d’affaires, qui vendent des produits ou des services à des tarifs élevés, mais rechignent à prendre un outil à une dizaine de dollars par mois.

Derrière ce petit coup de gueule du lundi matin, j’aimerais que vous preniez quelques minutes avant de critiquer un outil, service ou projet que vous utilisez gracieusement, avec lequel vous gagnez de l’argent. Demandez-vous si vous reversez à ce dernier autant que ce qu’il vous apporte.

phpdaily le blog

Wed, 06 Mar 2019 00:00:00 +0100

Si vous suivez sur ce blog ou les réseaux sociaux, vous n’êtes pas sans savoir que depuis le mois de février, je travaille sur un projet qui met à disposition des images Docker pour tester les versions en cours de développement de PHP.

En plus de simplifier l’accès aux futures versions du langage, j’avais envie d’avoir un espace de publication pour communiquer les nouveautés de chaque version. C’est pour cela que j’ai démarré un blog (en anglais) rattaché au projet. Ce dernier servira à publier des articles pour décrire, expliquer et mettre en oeuvre au travers d’exemples les futures fonctionnalités du langage. Ce dernier est accessible à l’adresse https://phpdaily.github.io. Un flux RSS est disponible et un compte Twitter a été créé pour l’occasion.

Le blog est actuellement hébergé sur GitHub Pages et le code source est disponible. Aussi, je souhaite que ce blog soit communautaire. Donc si vous souhaitez écrire un billet (en anglais) à propos d’une prochaine évolution du langage, n’hésitez pas à faire une pull request sur le projet.

Envie de tester PHP 7.4 ? Il y a une image Docker pour ça !

Fri, 01 Feb 2019 00:00:00 +0100

La version 7.4 de PHP est prévue pour la fin de cette année 2019. Elle apportera un certain nombre de nouvelles fonctionnalités dont celle que j’attends avec la plus grande impatience: les propriétés typées. PHP est un langage dont le code source est librement disponible, il est alors possible de tester les nouveautés du langage au fil du développement de ce dernier.

Compiler PHP peut sembler être une tâche complexe et nécessitant d’installer un certain nombre d’outils avec lequel nous (développeurs PHP) ne sommes pas habitués. Pour éviter ce travail et faciliter l’utilisation de la version de développement de PHP, j’ai décidé d’utiliser Docker. En prenant comme base le dépôt des images officielles, j’ai adapté ces dernières afin de compiler la version en cours de développement de PHP.

J’ai rendu ce travail disponible sur Github et les images sont librement accessibles sur le registre officiel de Docker. Ces dernières sont construites (presque) quotidiennement.

Si vous souhaitez commencer à jouer simplement via le mode interactif de la CLI, rien de plus simple:

$ docker run --rm -it phpdaily/php:7.4.0-dev php -a

Si vous souhaitez tester un code existant, ce n’est guère plus compliqué:

$ docker run --rm -it -v "$PWD:/src" -w /src phpdaily/php:7.4.0-dev php script.php

Il se peut que vous souhaitiez tester des fonctionnalités qui ne soient pas actives de base dans les images. C’est par exemple le cas de l’extension FFI (Foreign Function Interface) qui nécessite des options de compilation spécifiques. Pour utiliser cette dernière, les images Docker mettent en place tout le nécessaire pour que vous puissiez facilement l’installer au sein d’une image personnalisée.

# phpdaily/php:7.4.0-dev est une image basée sur Linux Alpine
FROM phpdaily/php:7.4.0-dev

RUN apk add --no-cache --virtual .persistent-deps libffi-dev \
    && docker-php-ext-configure ffi --with-ffi \
    && docker-php-ext-install ffi

Construisez ensuite l’image Docker correspondante au travers de la commande:

$ docker build -t you/php-ffi .

L’extension sera alors utilisable dans les conteneurs qui seront basés sur votre image (vous pouvez vérifier cela en listant les extensions disponibles docker run --rm -it you/php-ffi php -m).

Toutes les images phpdaily/php étant basées sur les images officielles, vous avez accès aux mêmes possibilités d’utilisation et d’extension que sur ces dernières.

C’est maintenant à vous de jouer !

Rétrospective 2018

Sun, 13 Jan 2019 00:00:00 +0100

2018 s’est terminé et en ce début d’année 2019, je cède à l’écriture des traditionnelles “bonnes résolutions”. Après tout, il est toujours intéressant de faire une petite rétrospective de l’année passée pour voir le chemin parcouru et de se motiver à définir de nouveaux objectifs.

L’année dernière, je publiais un billet similaire sur mes objectifs 2018. Force est de constater que je n’ai pas réalisé tous les objectifs que je m’étais fixé.

Retour sur mon changement professionnel

J’ai donc démarré l’année en changeant, 2 fois d’entreprise. Comme souvent lorsque l’on quitte un poste, on sait ce que l’on perd, mais pas nécessairement ce que l’on gagne. Après, avoir intégré une première société dont le poste ne correspondait en réalité pas à mes attentes, je travaille aujourd’hui sur des applications de comparaisons d’offres en énergie au sein de la société Opéra Energie qui a récemment été labellisée “Pépites” par la métropole de Lyon (au-delà de l’aspect purement marketing, il s’agit d’une reconnaissance de la croissant de la société dans la métropole Lyonnaise).

La fin de Jobeet

Fin 2017, je démarrais l’adaptation du tutorial Jobeet pour la sortie de Symfony 4. Malheureusement, ce projet est plus chronophage que ce que j’avais prévu et je n’ai plus le temps nécessaire (ni la motivation peut-être) pour continuer ce dernier. Malgré le succès du tutorial et les nombreux retours positifs que j’ai pu avoir, je me suis résolu fin octobre à annoncer la fin du projet.

Le retour aux bases

Je souhaitais revenir aux fondamentaux techniques de mon métier (la programmation), ce qui fut chose faite avec plus ou moins de réussite. J’entends par là, de découvrir et redécouvrir les algorithmes et les structures de données de base de l’informatique. Cela aura a été l’occasion de jouer avec PHP-DS, de découvrir des bibliothèques PHP sympa comme Immutable et de tester Immutable.js de Facebook (pas de raison qu’il n’y en ait que pour PHP).

L’année de Rust, ou pas…

Cette année je devais m’intéresser à Rust le langage sécurisé conçu et développé par Mozilla. Malheureusement, faute de temps je n’aurais pas du tout eu l’occasion de m’y mettre.

Automatisation, automatisation, automatisation…

Il y a un peu plus d’un an, je migrais mes serveurs OVH vers Scaleway. Je voulais en profiter pour tout passer sous Docker et automatiser un maximum de choses. Effectuer cette migration manuellement a été long, laborieux et source d’erreurs. Je voulais également en profiter pour m’intéresser à l’utilisation de Docker en production.

Mais finalement, je serais allé beaucoup moins loin que ce que j’avais initialement prévu. L’ensemble tourne bien, je passe l’essentiel de mon temps à mettre à jour les paquets systèmes. J’ai donc peu de chose croustillante à raconter à ce sujet.

Le reste de l’année en bref

Au final cette année aura été relativement calme du technique. J’ai participé à peu d’événements techniques (meetups et conférences), très peu contribué à l’Open Source. La naissance de ma fille y est certainement pour quelque chose et j’ai mis du temps à trouver une organisation qui me permette de tout concilier (vie pro, vie perso et activités tierces).

Faits marquant de cette année, la fréquentation du blog qui a plus que doublé, notamment via le tutorial sur Symfony 4, qui est maintenant la raison principale de visite de ce site.

Et pour en finir avec les chiffres, voici les 3 articles écrits cette année, les plus consultés :

Le rôle de lead developer

Mon, 10 Dec 2018 00:00:00 +0100

J’ai l’impression que le poste de lead developer (ou encore tech lead) n’a pas réellement d’équivalence en français puisque, comme pour de nombreux termes dans notre industrie en fait, nous utilisons exclusivement une version anglo-saxonne du terme pour nous exprimer. Avec l’émergence de notre domaine ces dernières années, ce poste est semble-t-il l’un des plus prisés par les développeurs. Pourtant, lorsque je suis amené à discuter avec des développeurs, des recruteurs, des chefs d’entreprise voir même des lead dev, je constate que chacun à sa propre définition du rôle associé à ce titre.

Derrière ce libellé, parfois un titre honorifique (dans le sens où rien ne distingue les missions de ce dernier d’un autre développeur) donné à un ancien développeur présent sur un projet (ou dans l’entreprise) de longue date. On peut également retrouver derrière ce poste des développeurs expérimentés ou ayant une expertise dans une technologie ou un domaine spécifique. Il est alors intéressant de noter que l’on peut alors être lead dev à plusieurs niveaux. Une personne ayant des compétences avancées en PHP peut très bien être tech lead PHP par exemple. Mais si cette même personne connaît très bien un projet particulier, elle peut alors être lead au niveau du projet.

Partant de ce constat, le tech lead est avant tout un développeur ayant une expérience et une expertise significative. Son rôle au sein d’un projet et d’une entreprise doit aller au-delà du code qu’il produit. Il a un rôle de coaching vis-à-vis de l’équipe dans laquelle il travaille ou intervient. Il doit pouvoir la faire évoluer, monter en compétence et tirer le projet (ou le domaine d’expertise qu’il exerce) vers le haut. Il est l’un des garants de la qualité (et pas l’unique ! Cela ne dispense pas le reste de l’équipe d’y faire attention, bien au contraire).

Dans les missions qui seraient à réaliser par le lead dev, la principale est d’assurer la cohérence des développements réalisés au sein de l’équipe dans laquelle il travaille. Pour cela, il doit avoir une vision globale du travail à réaliser et il doit être capable d’évaluer les impacts sur l’existant. Même si ce n’est pas lui qui effectue l’implémentation, il doit veiller à industrialiser les processus de développement, s’assurer de la qualité du code en mettant en place des procédures pour garantir cette dernière. Il est également important qu’il se tienne à jour de l’état de l’art de son métier afin de pouvoir conserver un esprit critique en étant capable de prendre du recul sur les décisions qui sont prises.

Je qualifierai le lead dev d’assistant du CTO. Personnellement, j’aime bien utiliser l’image du chef de l’état (le CTO) et de ces ministres (les lead developers). Donc en plus de ces compétences techniques, il doit être capable de communiquer de manière claire, défendre et expliquer des choix réalisés. Il doit avoir une vision critique de ce qui est fait sur son domaine d’expertise pour faire évoluer les choses dans le bon sens, tout en sachant prendre du recul sur le travail réalisé.

On lui prête parfois des missions managériales. Mais à mon sens, ces missions ne font pas partie du poste. C’est au CTO, voir à des managers selon la taille de la société de faire ce travail. Le lead dev doit se concentrer sur la partie technique. Il est par contre à mon avis indispensable qu’il participe aux entretiens de recrutement des personnes qui intégreront l’équipe dans laquelle il travaille. D’ailleurs, dans l’idéal, toute l’équipe de développement devrait pouvoir discuter avec un candidat qui va intégrer l’équipe.

Voila en ce qui me concerne le rôle d’un lead dev.

Déploiement avec Deployer et Gitlab CI

Mon, 03 Sep 2018 00:00:00 +0200

Chez Opéra Energie, la société dans laquelle je travaille, nous développons nos outils en PHP et utilisons Deployer pour le déploiement de nos différents projets. Notre code est hébergé sur une instance Gitlab et c’est tout naturellement que nous utilisons Gitlab CI pour notre intégration continue et le déploiement de nos applications.

Si déployer du code depuis les instances de nos runners Gitlab CI ne posent pas de problème particulier (il est facile d’y déposer une clé SSH autorisant la connexion à nos serveurs de productions et de tests), nous utilisons également les instances des runners Gitlab. Avec ces derniers, il est alors impossible d’y déposer une clé SSH permettant de se connecter à nos serveurs.

Les runners Gitlab que nous utilisons fonctionnent exclusivement sur Docker. Pour le déploiement, nous installons Deployer dans une image php:7-alpine des plus classiques (à laquelle nous avons néanmoins ajouté le nécessaire pour démarrer une connexion SSH, à savoir le paquet openssh-client dans le cas d’une distribution Alpine). Afin de pouvoir s’assurer que nos conteneurs Docker puissent se connecter sur les serveurs qui hébergeront nos applications, nous avons commencé par créer des clés SSH par serveurs (afin de pouvoir avoir une gestion fine d’une éventuelle révocation de ces dernières). Nos clés SSH seront ensuite injectées dans le conteneur qui effectuera le déploiement lors de son démarrage.

Il convient tout d’abord d’ajouter les clés publiques sur chacun des serveurs concernés. Ensuite, dans Gitlab, nous créons des variables Gitlab CI qui contiendront les clés privées que nous avons précédemment générées. Ces dernières sont automatiquement transmises aux runners lors de leurs exécutions.

Une fois Gitlab correctement configuré, il est maintenant possible d’éditer le fichier .gitlab-ci.yml décrivant les actions qui seront réalisées par notre intégration continue. C’est dans ce dernier, que nous allons récupérer le contenu de nos variables d’environnement et ajouter dynamiquement nos clés SSH à l’agent pour ensuite effectuer le déploiement de notre projet :

image: php:7-cli-alpine

stages:
  - deploy

before_script:
    - apk add --update git openssh-client
    - mkdir -p ~/.ssh && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - eval $(ssh-agent -s)
    - echo "$SERVER_TEST1_KEY" | ssh-add -
    - echo "$SERVER_TEST2_KEY" | ssh-add -
    - echo "$SERVER_PROD1_KEY" | ssh-add -

deploy:app:
    stage: deploy
    script:
        - curl --show-error --silent https://getcomposer.org/installer | php
        - php composer.phar install
        - vendor/bin/dep deploy
    when: manual
    only:
        - master
    environment:
        name: prod
        url: https://my-app.domain.com

Vous remarquerez que le déploiement s’effectuant dans un conteneur Docker et ne pouvant prévoir le serveur sur lequel la tâche sera lancée, nous désactivons un contrôle de la clé SSH via l’option StrictHostKeyChecking no. Cette action n’est à effectuer qu’au sein d’un conteneur Docker et peut-être potentiellement dangereux, car elle permet à des attaques de type man-in-the-middle de pouvoir être effectué.

Et c’est ainsi, en injectant dynamiquement des clés SSH au sein d’un conteneur Docker, qu’il est possible de déployer une application PHP avec Deployer (au n’importe quel autre outil de déploiement en réalité) via des runners Gitlab.

Docker, déploiement et PHP

Sat, 01 Sep 2018 00:00:00 +0200

Si l’écosystème des conteneurs s’est autant démocratisé ces dernières années, c’est notamment grâce à l’apparition de Docker dont les ambitions sont clairement affichées sur le site: “Build, Ship, and Run Any App, Anywhere”, que l’on pourrait traduire par “construisez, déployez, et exécutez n’importe quelle application, n’importe où”. Si la promesse est intéressante, la mise en place d’une infrastructure autour de Docker peut ne pas être chose facile.

À l’heure actuelle, énormément d’environnement de développement et de système d’intégration continue fonctionne autour de Docker. Mais ce n’est pas nécessairement le cas des applications en production, car derrière cette promesse de portabilité se cache un certain nombre de contraintes et construire une application tournant au sein d’un conteneur n’est pas nécessairement une chose aisée, surtout en PHP.

Pour mettre en place avec succès une infrastructure autour de conteneur, de nombreuses entreprises ont établi un ensemble de bonnes pratiques. Parmis ces dernières, l’un des plus importante est qu’un conteneur doit correspondre à une application. Si cela est quelque chose de pertinent et facile dans le cas d’une application Go (qui une fois compilé correspond à un binaire embarquant toutes ses dépendances) ou d’une application Java (il est possible pour une archive Java d’embarquer son propre serveur HTTP pour fonctionner de manière autonome), tout n’est pas aussi facile dans le cas d’une application PHP.

Effectivement, une application Web PHP ne peut fonctionner de manière autonome. Cette dernière tourne généralement au travers de deux dépendances: un serveur HTTP (type Apache, Nginx, …) et un module PHP (qui, couplé au serveur HTTP permet d’exécuter la machine virtuelle du langage). Si nous souhaitons donc avoir un conteneur autonome et capable de faire tourner notre application PHP, nous devrions donc avoir un conteneur embarquant PHP et un serveur HTTP. Mais cette manière de procéder est-elle en adéquation avec les bonnes pratiques citées précédemment ?

Si nous considérons notre application comme un service à part entière, oui. Par contre si nous considérons le serveur HTTP (le point d’entrée d’une requête auprès de notre application) et le code PHP (notre application à proprement parler) comme deux services distincts, alors on peut considérer que nous sommes en train d’enfreindre les bonnes pratiques des conteneurs (à plus forte raison, si l’on voit un conteneur comme un processus isolé).

Il y a bien entendu la théorie et la pratique, et même si j’ai ma propre idée sur la mise en place d’un environnement de conteneur pour les applications PHP sur lesquelles je travaille, j’ai trouvé intéressant de poser la question sur Twitter pour avoir des retours d’expérience.

Les retours que j’ai pu avoir sont très intéressant et révèlent de nombreux avis différents ainsi que divers infrastructures. Je pense d’ailleurs publier prochainement une synthèse des échanges que j’ai pu avoir.

Et si vous souhaitez participer, il n’est pas encore trop tard !

Dites les gens qui utilisent #Docker pour déployer des projets #PHP en prod, est-ce que votre conteneur "applicatif" embarque PHP et le serveur Web (nginx, apache, ...) traitant les requêtes, ou est-ce que vous séparer les deux concepts dans des conteneurs séparés ? RT appréciés
— Jérémy DECOOL (@jdecool) 29 août 2018

Soumettre un formulaire HTML en AJAX avec Javascript

Mon, 20 Aug 2018 00:00:00 +0200

Nous travaillons aujourd’hui avec tellement de frameworks aussi bien pour concevoir les parties backend que frontend, que nous oublions parfois à quel point il peut être facile d’effectuer certaines actions pouvant paraître complexes sans utiliser aucun outil supplémentaire. C’est notamment le cas pour la soumission de formulaire en AJAX.

Posez la question autour de vous, qui sait comment soumettre un formulaire en AJAX sans utiliser un framework particulier côté client (tel que React ou encore VueJS ou même encore jQuery) et sans utiliser des composants qui sont parfois fournis avec des frameworks backend, vous pourriez être surpris des réponses.

Pourtant les navigateurs et le langage Javascript ont énormément évolué ces dernières années et soumettre un formulaire AJAX n’a plus rien de bien sorcier. À vous d’en juger avec le snippet ci-dessous:

<html>
  <body>
    <form method="post" action="/submit" enctype="multipart/form-data">
      <input type="text" name="filename">
      <input type="file" name="file">
      <input type="submit">
    </form>

    <script>
      document.addEventListener('DOMContentLoaded', function() {
        document.getElementsByTagName('form')[0].addEventListener('submit', (e) => {
          e.preventDefault();

          let form = e.target;

          fetch(form.action, { method: form.method, body: new FormData(form) })
            .then(response => response.json())
            .then(json => console.log(json));

          return false;
        });
      });
    </script>
  </body>
</html>

Pourquoi vous devriez utiliser la librairie HTTPlug dans vos projets

Tue, 31 Jul 2018 00:00:00 +0200

HTTPlug est une librairie d’abstraction de client HTTP. HTTPlug vous permet de découpler le code de votre application d’une implémentation spécifique d’un client HTTP. Lorsque tous les composants de votre application dépendent uniquement de la librairie, vous avez alors la possibilité de choisir le client HTTP qui correspond le mieux à votre projet ou d’utiliser le même client que vos dépendances.

La bibliothèque est compatible avec la PSR-7 et définit un contrat pour l’envoi de requête HTTP. Elle permet également l’utilisation d’un client HTTP asynchrone. L’intérêt majeur du composant et que HTTPlug est complètement indépendant de toute implémentation cliente. C’est-à-dire, que lorsque vous utilisez HTTPlug, vous allez avoir la possibilité, sans changer quoi que ce soit à votre code, d’effectuer les requêtes HTTP via CURL, Guzzle, ReactPHP ou n’importe quel client de votre choix.

Mais en quoi est-ce intéressant pour votre projet ?

Si vous développez une librairie, comme par exemple un client d’API, vous ne savez pas à l’avance les dépendances qui seront utilisées dans les projets où votre composant va être intégré. Il peut s’agir d’un projet écrit en pur PHP, comme un projet Symfony, Laravel, Zend ou n’importe quel autre framework. Mais au-delà du framework, le projet utilisateur peut très bien utiliser un client CURL pour effectuer les appels réseaux afin d’éviter une contrainte technique pouvant être liée à Guzzle. Comment vous assurez que votre bibliothèque puisse s’adapter sans contrainte particulière au plus grand nombre de projets ? HTTPlug permet justement de répondre à cette problématique. Ne forcez pas vos utilisateurs à mettre en place une implémentation d’un outil qu’ils ne souhaitent pas !

À ce stade, vous voyez peut-être l’intérêt de mettre en place HTTPlug pour le développement de composant indépendant. Mais qu’en est-il de son utilisation au sein d’un code applicatif ?

Il est vrai que dans une application, nous changeons rarement l’implémentation de la couche effectuant les appels réseau. Pourtant HTTPlug peut une fois encore se révéler utile. En effet, la bibliothèque vous permettra de normaliser et découpler la manière dont vous effectuer vos requêtes HTTP. Tout comme pour l’écriture d’une librairie, vous serez alors libre de choisir l’implémentation de votre choix. Vous souhaitez démarrer avec CURL, pas de problème, vous pourrez passer du Guzzle en remplaçant tout simplement le package php-http/curl-client par php-http/guzzle6-adapter.

Vous n’êtes pas convaincu par ce dernier argument ? Il est vrai que l’on ne change pas d’implémentation tous les jours. Mais vous souvenez-vous du passage de la version 4 de Guzzle à la version 5 ? Ou de la 5 vers la 6, quand l’API du client avait totalement changée ? Car qu’on le veuille ou non, il est parfois indispensable de faire cette mise à jour pour profiter des dernières fonctionnalités des composants ou tout simplement pour continuer à utiliser une version maintenant du composant tier. Si vous aviez utilisé HTTPlug, cette mise à jour aurait été complètement transparente.

En utilisant une abstraction d’un client HTTP, vous êtes donc libre. Libre de choisir l’implémentation que vous souhaitez utiliser, libre de changer le client HTTP pour prendre celui qui correspond réellement à votre besoin. HTTPlug est un composant dans l’air du temps, lorsque l’on parle DDD ou architecture hexagonale, lorsque l’on souhaite avoir un code proche du métier et découpler des frameworks que l’on utilise, c’est exactement la philosophie que suis ce composant.

Qu’attendez-vous pour le mettre en place dans vos projets ? L’essayer, c’est l’adopter !

Optimiser le stockage des adresses IP dans MySQL

Wed, 25 Jul 2018 00:00:00 +0200

C’est l’été, le mois d’août arrive, de manière générale les cadences et les volumes de travaillent ralentissent un peu pour la période estivale. C’est le moment parfait pour démarrer des travaux de refactoring où pour travailler sur des tâches pour lesquels vous n’arrivez jamais à dégager du temps ! Si au début de la semaine j’évoquais comment optimiser le stockage de vos UUID, évoquons comme optimiser et simplifier la gestion des adresses IP dans MySQL.

Pour la plupart d’entre nous, nous allons stocker les adresses IP sous la forme d’une chaîne de 15 caractères maximums dans le cas d’une adresse IPv4 et de 39 caractères pour une adresse de type IPv6. Pour la majorité de nos besoins cela est pleinement suffisant, nous effectuons en réalité assez peu de traitements sur ces dernières hormis de la consultation de données. Mais comme toujours une donnée stockée sous une forme textuelle est quelque chose de coûteux aussi bien en termes de stockage mais également en termes de performance. De plus cela peut rendre vos requêtes de sélection assez complexes (voire impossibles) à écrire.

Bien heureusement pour nous, les moteurs de base de données fournissent généralement des outils pour optimiser. Mais si PostgresSQL fournit un type inet permettant de gérer une donnée de type IPv4 ou IPv6, MySQL ne possède pas d’une gestion de type aussi évoluée. Néanmoins, MySQL met à disposition de ces utilisateurs 4 fonctions permettant de travailler avec des adresses IP: INET_ATON(), INET_NTOA(), INET6_ATON() et INET6_ATON().

Les méthodes INET_ATON() et INET6_ATON() vont permettre de transformer respectivement une adresse IPv4 et IPv6 d’une forme textuelle en un entier ou sous la forme d’une chaîne binaire qui représentera cette dernière sous forme numérique. Vous l’aurez donc deviné, les méthodes INET_NTOA() et INET6_ATON() vont procéder à l’opération inverse, c’est-à-dire prendre la forme numérique d’une adresse IP pour la convertir en forme textuelle. C’est ainsi qu’il est possible d’optimiser le stockage et améliorer la performance de vos requêtes, car effectuer une recherche numérique est plus rapide que de faire une recherche full text.

Un autre avantage de cette solution est que bien que les adresses IP soient transformées, la transformation conserve l’ordre de grandeur des données. Par exemple, si je veux trouver toutes les lignes de ma base qui sont comprises entre l’adresse 8.8.8.4 et 8.8.8.8, je pourrais très bien écrire la requête suivante : SELECT * FROM table WHERE ip BETWEEN INET_ATON('8.8.8.4') AND INET_ATON('8.8.8.8').

Et parce que nous sommes nombreux à utiliser Doctrine pour gérer nos interactions avec la base de données, il existe de nombreuses bibliothèques permettant d’ajouter le support de ces fonctions. Pour ma part j’utilise le plus régulièrement beberlei/DoctrineExtensions.

Et si vous préférez gérer cette logique côté PHP, le langage possède ses propres fonctions permettant d’effectuer ces conversions de type de données. Il met à disposition des développeurs les fonctions ip2long et long2ip pour les adresses IPv4, ainsi que inet_pton et inet_ntop pour les IPv6.

La gestion des UUID dans MySQL

Mon, 23 Jul 2018 00:00:00 +0200

Il est maintenant acquis que l’utilisation de valeurs auto-incrémentées en tant que clé primaire présente plusieurs inconvénients lorsque cette technique est mal utilisée. C’est pour cela que l’utilisation des UUID se démocratise aujourd’hui. Néanmoins toutes les bases de données ne traitent pas ce type de la même manière et cela peut avoir des répercussions sur la performance de nos requêtes. C’est notamment le cas si vous utilisez MySQL.

Titouan GALOPIN a récemment rédigé un billet sur l’utilisation des UUIDs dans Symfony avec Doctrine. Il recommande dans ce billet d’utiliser conjointement un identifiant auto-généré qui aura vocation à être utilisé par la base de données et un UUID qui servira de point d’entrée pour les données de notre application.

MySQL commence pourtant à mettre des solutions en place afin de pouvoir gérer les problèmes de performances liés à l’utilisation des UUID. Par exemple, la version 8 de MySQL introduit trois nouvelles fonctions en ce sens : IS_UUID, UUID_TO_BIN et BIN_TO_UUID.

MySQL ne sait pas gérer les UUID et nous stockons généralement ce dernier sous sa forme textuelle, correspondant à une chaîne de 36 caractères. C’est essentiellement pour cela que cela induit des problèmes de stockage et de performance car la donnée est plus complexe et plus lourde à gérer qu’un simple entier. Les fonctions UUID_TO_BIN et BIN_TO_UUID permettent ainsi de convertir un UUID textuel sous sa forme binaire (correspondant au type VARBINARY(16)). La données est ainsi deux fois plus petite que sous le format textuel et les données binaires sont mieux appréhendées par le système de base de données.

L’inconvénient de cette solution et que pour pouvoir visualiser l’UUID en base, il sera nécessaire d’appliquer la fonction BIN_TO_UUID pour rendre ce dernier lisible. Dans un article sur le stockage des UUID, MySQL duplique la donnée avec une version textuelle pour rendre la donnée visible, mais cela revient au final à une solution similaire à celle évoquée par Titouan. La question étant de savoir si vous avez réellement besoin d’avoir cette version textuelle ?

Si vous travaillez avec PHP, vous utiliserez certainement la librairie ramsey/uuid pour gérer vos UUID. Cette dernière fournit également un composant ramsey/uuid-doctrine pour s’interfacer avec Doctrine. Il est intéressant de noter que ce dernier propose un type uuid_binary utilisant les techniques citées dans ce billet.

Et pour aller plus loin, voici quelques ressources supplémentaires (disponible uniquement en anglais):

Pourquoi ? Donner un sens à notre travail

Tue, 17 Jul 2018 00:00:00 +0200

Depuis quelques jours, j’ai démarré la lecture de livre Commencer par pourquoi, la traduction française de Start with why de Simon SINEK. Dans la préface du livre, l’auteur y écrit la chose suivante :

Je n’avais pas un poste désagréable, ce n’était pas un mauvais job en soi. Je n’éprouvais tout simplement plus de plaisir à le faire. Pourtant et d’après toutes les statistiques, j’aurais dû être heureux. Je gagnais bien ma vie, je travaillais avec des clients et des collégues intéressants. Le problème était que je n’y trouvais plus de sens. Je ne m’épanouissais plus dans mon travail.

En lisant ces mots, je réalise pourquoi j’ai changé 2 fois de société durant la première moitié de cette année. Donner un sens aux choses, à nos actions, à notre vie, voila ce qui nous motive, nous fait avancer et nous dépasser.

Cloner des projets privés dans un runner Gitlab CI

Fri, 13 Jul 2018 00:00:00 +0200

Gitlab n’est aujourd’hui plus un simple outil permettant d’héberger son code sur Git au travers d’une interface agréable. Non, Gitlab est aujourd’hui un environnement extrêmement complet et orienté vers une culture DevOps tout en un. La plateforme permet aujourd’hui de stocker son code, gérer des projets, faire de l’intégration et du déploiement continu (incluant un outil de monitoring) au sein d’un outil unique.

C’est pour toutes ces raisons que nous utilisons Gitlab au quotidien chez Opéra Energie. Pour éviter d’avoir à gérer notre infrastructure, nous utilisons Gitlab et les outils associés en mode SaaS. Nous travaillons sur une plateforme ayant une architecture orientée services et où chacun de ces derniers est isolés au sein de son propre dépôt de code et est testé via un pipeline Gitlab CI.

Il arrive que certains projets requièrent des dépendances externes pouvant être gérés dans des dépôts privés. Dans ce cas-là, il est nécessaire que le runner Gitlab CI ait accès à ce dernier pour pouvoir cloner le projet en question. Comme je l’ai signalé précédemment, nous utilisons Gitlab (et Gitlab CI) en mode SaaS et il nous ait donc impossible d’accéder aux serveurs des runners pour y déposer la clé SSH permettant de récupérer les projets privés (sans compter que nous exécutons toutes les actions des runners au sein de conteneurs Docker).

Afin de contourner ce problème, nous injectons dynamiquement la configuration nécessaire durant l’exécution de notre pipeline Gitlab CI. Pour cela, nous avons commencé à créer une clé SSH uniquement dédiée à une utilisation des dépôts au sein des runners de Gitlab. La clé privée est alors utilisée en tant que Deploy Key des projets privés dont nous avons besoin.

Une fois configuré, nous allons ajouter la clé privée comme une variable d’environnement des runners et qui sera dynamiquement injectée dans le runner par Gitlab au moment de l’exécution de notre pipeline. Il ne reste ensuite plus qu’à utiliser notre clé SSH lors de l’exécution de nos différentes tâches :

image: alpine:3.6

before_script:
    - apk add --update git openssh-client
    - mkdir -p ~/.ssh
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - eval $(ssh-agent -s)
    - echo "$SECRET_KEY" | ssh-add -

test:unit:
    script:
        - ./run-unit-test.sh

test:functional:
    script:
        - ./run-functional-test.sh

Réalisez vos benchmarks de code PHP avec PHPBench

Mon, 14 May 2018 00:00:00 +0200

Pour mes besoins personnels, je souhaitais tester du code PHP et obtenir certaines données sur l’exécution de ce dernier (temps d’exécution, mémoire consommée, …) sans pour autant sortir l’artillerie lourde. En effectuant quelques recherches, j’ai alors découvert PHPBench qui comme son nom l’indique est un framework de benchmark PHP.

PHPBench permet de réaliser simplement des benchmarks sur du code PHP. Il permet de standardiser l’écriture du code et génère des rapports permettant de comparer différents cas d’utilisation.

Le framework vous propose d’écrire vos benchmarks un peu comme vous écririez un test PHPUnit. Vous allez ainsi commencer par écrire une classe contenant le code que vous souhaitez mesurer.

<?php

namespace Acme;

class TimeConsumer
{
    public function consume()
    {
        usleep(100);
    }
}

Puis le code permettant d’effectuer la mesure:

<?php

use Acme\TimeConsumer;

class TimeConsumerBench
{
    public function benchConsume()
    {
       $consumer = new TimeConsumer();
       $consumer->consume();
    }
}

Il ne restera plus qu’à exécuter le benchmark au travers de la commande : vendor/bin/phpbench run benchmarks --report=default.

Pour plus d’informations et pour découvrir les nombreuses fonctionnalités offertes par l’outil, consultez la documentation officielle.

Améliorez vos applications avec l'analyse statique de code

Fri, 11 May 2018 00:00:00 +0200

Pour corriger des problèmes sur un projet, il est primordial de détecter ces derniers le plus rapidement possible. Effectivement, au plus tôt un problème est détecté et au moins il sera coûteux de résoudre ce dernier. Il est pour cela possible d’avoir recours à de l’analyse statique. Il s’agit d’une opération permettant de détecter automatiquement des erreurs de programmation sans avoir à exécuter de code. Les outils utilisés vont analyser le code source afin de trouver d’éventuelles erreurs et rechercher des modèles de code reconnu comme étant à risque.

Ce billet a été originalement publié sur le blog de la société Novaway dans le cadre de mon travail.

Dans sa forme la plus simple, le mode CLI de PHP propose une option permettant d’analyser un fichier PHP. Il ne s’agit en réalité pas d’une analyse statique, mais plutôt d’une analyse syntaxique (l’opération qui va vérifier que le programme ne contient pas d’erreur de syntaxe). Néanmoins, cela permet d’avoir un premier retour sur le code écrit. Pour effectuer cette opération, il faut utiliser l’argument “-l” de l’interpréteur.

Evaluer l’envergure d’un projet

Obtenir des informations quantifiées sur la taille d’un projet est une opération qui peut s’avérer particulièrement intéressante lors de la prise en main d’un nouveau projet. Un suivi des données recueilli peut également être utile pour mesurer la façon dont le code grossi.

Dans ce cas, PHPLoc est l’outil idéal pour effectuer cette analyse. Ce dernier permet de mesurer rapidement la taille d’un projet PHP et d’en analyser la structure pour ensuite visualiser les résultats sous la forme de statistiques. Cet outil est particulièrement intéressant lors de la prise en main d’un nouveau projet car il permet de se rendre compte de l’envergure de ce dernier.

Les informations fournies par PHPLoc sont exhaustives. Il est possible de connaître le nombre de fichiers composant le projet, le nombre de lignes de code et de commentaires ainsi que le nombre de classes et de méthodes existantes (découpés en fonction de leurs visibilités).

En plus de ces données, PHPLoc fournit des indicateurs sur les dépendances décrites dans le code (utilisation de variables globales, accès direct à des attributs de classes ou l’utilisation de méthodes statiques). Il fournira également quelques informations sur la complexité cyclomatique du projet.

Analyser la complexité du code d’un projet

Il est primordial pour la pérennité d’un projet de pouvoir mesurer la complexité de sa base de code. Cette mesure permet d’avoir des informations sur la facilité de maintenabilité du projet. Des outils d’analyse permettent ainsi de détecter des éventuels problèmes au travers d’un ensemble de règles prédéfinies.

Dans ce sens, PHP Mess Detector (communément appelé PHPMD) vous aidera à identifier les fonctions, méthodes, paramètres ou variables inutilisés. Mais aussi de mettre en évidence des séquences de codes complexes ou des bugs potentiels. Au travers de ces différentes analyses PHPMD sera également capable de proposer des optimisations pour certaines portions de votre projet.

Dans le même esprit, PHP Depend (qui est le portage PHP de JDepend) est une application d’analyse de code et de mesure de la qualité. Les instructions de l’application sont examinées afin de déterminer l’extensibilité, la facilité de réutilisation et de maintenance de la base de code.

Avec l’arrivée de PHP 7, de nouveaux outils ont également fait leur apparition. C’est le cas de Phan. Développé par Etsy, Phan est un analyseur de code statique qui tente de minimiser au maximum les faux positifs. L’outil va se focaliser sur les problèmes les plus fréquents en détectant par exemple les types des paramètres passés aux fonctions et vérifier que ces derniers sont correctement définis.

Respecter les standards de code

Les standards de code sont très importants pour le travail en équipe car ils permettent d’uniformiser la manière dont les développeurs écrivent du code et facilite ainsi la lecture, la compréhension et la prise en main du projet.

Dans ce sens, plusieurs outils sont à la disposition du développeur. Le plus connu et plus ancien est certainement PHP_CodeSniffer. Il s’agit d’un ensemble de scripts qui vont analyser votre code PHP (mais aussi Javascript et CSS) afin de relever les violations de vos standards. En plus de la détection des erreurs, il sera possible de corriger automatiquement les erreurs détectées.

Dans le même esprit, il existe également PHP CS Fixer, un outil plus récent que le précédent et bénéficiant d’une gestion de la configuration plus « actuelle » afin d’éviter d’écrire de la configuration au format XML.

Tester la compatibilité avec une version de PHP

Proposé peu avant l’arrivée de PHP 7, php7cc est l’analyseur de code statique qui vous permettra de faciliter la migration de vos projets PHP 5 vers PHP 7. Une analyse de php7cc vous permettra de détecter les portions de votre code qui ne sont pas compatibles avec les dernières versions du langage et facilitera ainsi la transition vers la dernière branche majeure du langage.

Il existe également une solution nommée PHP CompatInfo qui est une librairie PHP qui va rechercher la version minimum du langage avec laquelle votre code est compatible.

Les solutions complètes

Il existe également des solutions plus complètes et qui permettent de regrouper l’ensemble des analyses citées précédemment. Ma solution préférée est certainement PhpMetrics, une des solution les plus récentes de ce billet.

PhpMetric, tout comme les outils précédents, permet d’analyser un projet pour obtenir des métriques sur la complexité et la maintenabilité du code. Le principal élément différenciateur de ce projet est qu’il se focalise sur les critères de qualité et fait un grand travail sur la présentation des résultats afin que ces derniers puissent être compris et interprétés par des développeurs de tout niveau au travers d’une interface agréable.

Un rapport de démo est disponible sur le site de l’outil afin de se faire une idée des capacités de ce dernier.

Notons également la présence de nombreuses autres solutions telles que SonarQube qui contrairement à l’ensemble des outils présentés jusqu’à maintenant, est un outil multilangage. Ce dernier est entre autres compatibles avec les langages tels que Java, C, C++, Objective-C, JavaScript, Python… Disponible dans une version open source, SonarSource l’éditeur de la solution propose également une version commerciale disponible en SaaS avec un support technique et proposant des analyses pour des langages tel que COBOL, Objective-C, Swift.

Parmi les autres outils existants, on peut également citer :

Scrutinizer, une solution propriétaire massivement utilisée pour analyser la qualité des projets open source
Sensiolabs Insight, le produit de la société Sensiolabs créatrice du framework Symfony
Exakat

Voilà qui conclut notre tour d’horizon des outils d’analyse de code statique. Notons que la plupart des outils évoqués s’intègrent très facilement dans les principaux IDE (PHPStorm, Eclipse, …) et éditeur de textes spécialisés (tels que SublimeText, Atom ou VSCode) de base ou au travers de leurs systèmes d’extensions.

Les solutions d’analyse statique sont nombreuses et il est souvent simple de les mettre en place pour obtenir les premiers rapports et indicateurs qui permettront d’améliorer la qualité d’un projet. Il est important de signaler que les résultats obtenus ne sont intéressants et pertinents que dans le contexte où ils sont mis en place.

Il est également intéressant de signaler, qu’il ne faut pas prendre les recommandations émises par ces outils comme étant une vérité absolue. Les analyses effectuées doivent être mises en place pour indiquer le chemin à suivre et fournir des indicateurs, elles ne remplacent en aucun cas l’expérience d’un développeur.

Les outils de profiling PHP open source

Wed, 09 May 2018 00:00:00 +0200

L’activité de profiling consiste à collecter un certain nombre d’informations sur l’exécution d’un code PHP. Une telle opération est effectuée lorsque l’on souhaite par exemple analyser le code d’un projet pour améliorer sa scalabilité ou encore optimiser ce dernier pour corriger un problème de performance applicative.

Ce billet a été originalement publié sur le blog de la société Novaway dans le cadre de mon travail.

Lorsque Facebook a rendu public XHProf, son outil de profiling dédié à PHP en mars 2009, cela a été une petite révolution pour la communauté. Effectivement avant cet outil, il était nécessaire d’utiliser XDebug, mais ce dernier n’est pas recommandé pour un usage en production car l’activation du mode de profiling entraîne de gros ralentissement de l’application.

Contrairement à XDebug, XHProf a été conçu pour pouvoir être utilisé en production et l’impact sur les performances de l’application est minimal. Un autre avantage et qu’il est possible de profiler uniquement une portion de code. Il sera donc possible de récupérer des données telles que la consommation CPU, la consommation mémoire, le nombre d’appels et le temps passé dans chaque fonction. L’analyse de ces données est facilité par le fait que XHProf fournit l’ensemble des scripts nécessaires à cette opération.

Malheureusement, Facebook se concentre désormais sur le développement de sa machine virtuelle HHVM qui intègre nativement XHProf. De ce fait l’extension PHP n’est actuellement plus maintenue. Si l’extension reste compatible avec les versions 5.x de PHP, il n’est pas possible de l’utiliser avec les versions 7 du fait de changement interne dans la structure du moteur. On a alors vu ces dernières années se développer des solutions de profiling commerciales. La plus en vogue est certainement Blackfire.

Pour remédier à ce problème, les développeurs de la société Tideways ont décidé de forker le projet XHProf et de créer leur propre extension PHP. Cette dernière propose des fonctionnalités équivalentes à XHProf, mais est compatible avec toutes les versions de PHP depuis la version 5.3. Elle est également proposée en open source et disponible sur un dépôt Github.

<?php

include __DIR__ . '/common.php';
include __DIR__ . '/tideways_symfony.php';

tideways_enable();

$kernel = new \Symfony\Component\HttpKernel\Kernel();
$kernel->boot();

$httpKernel = new \Symfony\Component\HttpKernel\HttpKernel();
$httpKernel->handle('indexAction');
$httpKernel->handle('helloAction');

print_spans(tideways_get_spans());

tideways_disable();

Mais le profiling avec l’extension Tideways ne s’arrête pas à un simple fork iso-fonctionnel de XHProf, puisque les développeurs ont également ajouté des fonctionnalités supplémentaires telles que notamment la détection du framework exécutant le code “profilé” afin d’ajouter des informations essentielles et de diminuer “le bruit généré” par le code du framework. À l’heure de l’écriture de ce billet, l’extension supporte 13 frameworks.

L’extension fait maintenant partie du cœur de la solution “Tideways Profiler Platform” une solution commerciale SaaS proposée par la société. Cette partie commerciale n’est en rien obligatoire, mais apporte notamment une interface de visualisation des informations remontées par l’application ainsi qu’un stockage de ces dernières directement sur les serveurs de la société.

Au final, les solutions de profiling open source sont rares, mais existantes. Bien que XHProf ne soit aujourd’hui plus maintenu par Facebook pour PHP, l’extension fournie par Tideways est une excellente alternative aux diverses solutions commerciales existantes. Il sera cependant nécessaire de passer par une phase de configuration et de trouver l’outil nécessaire pour traiter les données de profiling. Cela reste certainement la meilleure solution pour des besoins ponctuels. Si par contre vous souhaitez avoir une solution fonctionnelle rapidement et avec un minimum d’effort, vous pourrez vous tourner vers les nombreuses solutions SaaS existantes.

D’ailleurs si vous souhaitez tester le profiling avec Tideways, n’hésitez pas à télécharger les stubs de l’extension afin d’avoir une auto-complétion dans votre IDE préféré.

Tutorial Jobeet pour Symfony 4 - Partie 6: Aller plus loin avec le modèle

Sat, 24 Feb 2018 00:00:00 +0100

Notre application Jobeet commence à devenir utilisable. Nous savons maintenant créer des pages, les afficher et naviguer entre elles en utilisant le framework Symfony via les différents composants qui sont à notre disposition. Attardons-nous un peu sur la couche modèle de notre projet.

Cette dernière est actuellement composée de nos entités (les classes qui représentent les données stockées en base). Nous allons dans ce chapitre, travailler sur l’optimisation de notre code, ce qui vous permettra d’en apprendre un peu plus sur le sujet.

Revenons sur nos différents scénarios et plus précisément sur le scénario F1: En tant qu'utilisateur, je vois les dernières offres actives sur la page d'accueil. Car si vous avez bien suivi ce que nous avons réalisé, la page d’accueil liste actuellement toutes les offres d’emploi aussi bien celles qui sont actives que celles qui ne le sont pas.

Un emploi est considéré actif s’il a été posté il y a moins de 30 jours. Commençons par modifier la requête effectuée dans la méthode JobController::index :

<?php // src/Controller/JobController.php

namespace App\Controller;

// ...
use DateTime;

class JobController extends AbstractController
{
    public function index(EntityManagerInterface $em): Response
    {
        $queryBuilder = $em->getRepository(Job::class)->createQueryBuilder('j');
        $queryBuilder->andWhere('j.createdAt > :date');
        $queryBuilder->setParameter('date', new DateTime('-30 day'));
        $jobs = $queryBuilder->getQuery()->getResult();

        return $this->render('job/index.html.twig', [
            'jobs' => $jobs,
        ]);
    }
}

Pour écrire une requête “complexe”, nous utilisons l’objet QueryBuilder fourni par Doctrine et qui permet comme son nom l’indique de créer une requête compréhensible par l’ORM sans devoir écrire de code SQL. L’avantage est que Doctrine adaptera la requête au type de base de données avec lequel il communique (SQLite, MySQL, PostgresSQL, …). L’inconvénient est que cela masque complètement la requête qui est générée.

Notre requête commence à devenir plus complexe et il devient intéressant de l’extraire de notre contrôleur pour que cette dernière puisse être réutilisée sans devoir dupliquer le code. Jusqu’à maintenant, la méthode EntityManager::getRepository nous permettait d’obtenir un objet générique que Doctrine utilise pour fournir des méthodes de base permettant de faire des requêtes en base de données.

Nous allons maintenant définir une classe de type Repository. Les objets de types Repository contiennent des méthodes permettant de récupérer des données en base. Définissons donc une classe JobRepository, qui comme son nom l’indique, nous permettra de récupérer des données liées aux offres d’emploi.

<?php // src/Repository/JobRepository.php

namespace App\Repository;

use DateTime;
use Doctrine\ORM\EntityRepository;

class JobRepository extends EntityRepository
{
    public function findActive(DateTime $date)
    {
        return $this->createQueryBuilder('j')
            ->andWhere('j.createdAt > :date')
            ->setParameter('date', $date)
            ->getQuery()
            ->getResult();
    }
}

Une fois notre classe créée, nous allons devoir modifier la configuration du mapping de l’entité Job pour indiquer à Doctrine la classe que l’ORM devra utiliser pour accéder aux données. Cela se passe dans le fichier config/doctrine/mapping/Job.orm.yml.

# config/doctrine/mapping/Job.orm.yml
App\Entity\Job:
    type: entity
    repositoryClass: App\Repository\JobRepository

    # ...

Pour finir, supprimons le code du contrôleur pour utiliser notre nouvelle classe :

<?php // src/Controller/JobController.php

namespace App\Controller;

// ...

class JobController extends AbstractController
{
    public function index(EntityManagerInterface $em): Response
    {
        $jobs = $em->getRepository(Job::class)->findActive(new DateTime('-30 day'));

        return $this->render('job/index.html.twig', [
            'jobs' => $jobs,
        ]);
    }
}

Et voilà, nous utilisons maintenant une classe pour la récupération des données de notre offre d’emploi, ce qui permet d’isoler le code dédié à la récupération des données et permet ainsi d’améliorer la maintenabilité de notre projet.

Il est possible de consulter la requête générée par Doctrine en consultant les logs générés par l’application. Par défaut, Symfony crée les logs sur la sortie standard et son donc consultable directement sur le terminal.

2018-02-10T19:32:20+01:00 [debug] SELECT j0_.id AS id_0, j0_.type AS type_1, j0_.company AS company_2, j0_.logo AS logo_3, j0_.url AS url_4, j0_.position AS position_5, j0_.location AS location_6, j0_.description AS description_7, j0_.how_to_apply AS how_to_apply_8, j0_.token AS token_9, j0_.is_public AS is_public_10, j0_.is_activated AS is_activated_11, j0_.email AS email_12, j0_.expires_at AS expires_at_13, j0_.created_at AS created_at_14, j0_.updated_at AS updated_at_15, j0_.category_id AS category_id_16 FROM job j0_ WHERE j0_.created_at > ?

Un moyen plus simple d’accéder à ces informations est d’installer le composant symfony/profiler-pack.

$ composer require symfony/profiler-pack --dev

Ce dernier permet la mise en place d’une interface graphique qui affiche un certain nombre d’informations sur votre application. Chaque bundle peut ainsi y afficher des données. Cette interface ajoute une barre permettant d’avoir un résumé des informations disponibles :

Il est également possible d’accéder à un détail des informations récupérées en cliquant sur l’icône du composant concerné :

Pour l’heure, notre code est encore loin d’être parfait. Pour récupérer toutes les offres actives, nous sommes systématiquement obligés de passer en paramètre la date à partir de laquelle les offres sont visibles. Cela revient à dupliquer le calcul de la date et serait source d’erreurs. Pour corriger ce problème, nous allons créer une constante qui nous permettra de masquer ce calcul. Et pour optimiser notre requête, nous allons utiliser le champ expiresAt afin de stocker la date d’expiration d’une offre plutôt que de devoir la calculer.

Tout comme pour les dates de création et de modification de nos offres d’emploi, nous allons utilisons le gestionnaire d’événement de Doctrine pour mettre à jour la valeur du champ automatiquement. Commençons par ajouter le code nécessaire à notre entité :

<?php // src/Entity/Job.php

namespace App\Entity;

// use ...

class Job
{
    public const OFFER_LIFETIME = 30; // durée de vie d'une offre en jours

    // ...

    public function setExpiresAtValue(LifecycleEventArgs $event): self
    {
        // nous remplissons automatiquement la date d'expiration si cette dernière n'a pas été saisie
        // manuellement
        if (!$this->expiresAt) {
            $this->expiresAt = new DateTime('+'.self::OFFER_LIFETIME.' day');
        }

        return $this;
    }
}

N’oublions pas d’ajouter la configuration liée à cette gestion d’événement.

# config/doctrine/mapping/Job.orm.yml
App\Entity\Job:
    # ...
    lifecycleCallbacks:
        prePersist: [ setCreatedAtValue, setExpiresAtValue ]

Nous pouvons maintenant mettre à jour notre requête :

<?php // src/Repository/JobRepository.php

namespace App\Repository;

use DateTime;
use Doctrine\ORM\EntityRepository;

class JobRepository extends EntityRepository
{
    public function findActive()
    {
        return $this->createQueryBuilder('j')
            ->andWhere('j.expiresAt >= :date')
            ->setParameter('date', new DateTime())
            ->getQuery()
            ->getResult();
    }
}

N’oubliez pas d’enlever le paramètre dans l’appel de la méthode dans la classe JobController::index

Le code de notre application est maintenant plus simple et plus maintenable, mais si nous voulons pouvoir tester que tout fonctionne correctement, encore faut-il mettre à jour nos données de test. Car dans les données actuelles, nous avons défini une date d’expiration des offres au 10/10/2012 et nous ne voyons donc maintenant plus aucune offre. Supprimons les dates d’expiration de notre jeu actuel et ajoutons une offre expirée (consultez directement ce fichier pour avoir le code correspondant).

En rechargeant les fixtures au travers de la commande bin/console doctrine:fixtures:load, l’affichage ne devrait pas avoir changé, mais si vous regardez les données en base, vous constaterez qu’il y a pourtant bien 3 offres d’emploi enregistrées.

Si nous revenons à nos scénarios utilisateurs, nous avons spécifié que les offres devaient être classées par catégories, ce qui n’est actuellement pas le cas. Pour répondre à ce besoin, nous allons créer une classe de type Repository pour notre entité Category. Cette dernière nous permettra de lister les catégories existantes avec les offres d’emploi correspondantes.

Commençons par modifier le mapping Doctrine :

# config/doctrine/mapping/Job.orm.yml
App\Entity\Category:
    type: entity
    repositoryClass: App\Repository\CategoryRepository

    # ...

Créons maintenant la classe correspondante avec la nouvelle méthode de récupération des offres par catégorie :

<?php // src/Entity/CategoryRepository.php

declare(strict_types=1);

namespace App\Repository;

use DateTime;
use Doctrine\ORM\EntityRepository;

class CategoryRepository extends EntityRepository
{
    public function findCategoriesWithJobs()
    {
        return $this->createQueryBuilder('c')
            ->join('c.jobs', 'j')
            ->where('j.expiresAt >= :date')
            ->setParameter('date', new DateTime())
            ->getQuery()
            ->getResult();
    }
}

La requête Doctrine a été construite via le QueryBuilder. Doctrine implémente également son propre langage de requête appelé DQL (dérivé du SQL). Le QueryBuilder tout comme le DQL se base sur nos entités pour construire les requêtes effectuées en base de données, cela permet ensuite à Doctrine de créer les objets correspondants.

Utilisons maintenant cette dernière dans l’affichage de notre homepage :

<?php // src/Controller/JobController.php

namespace App\Controller;

// ...

class JobController extends AbstractController
{
    public function index(EntityManagerInterface $em): Response
    {
        $categories = $em->getRepository(Category::class)->findCategoriesWithJobs();

        $jobsCategories = [];
        foreach ($categories as $category) {
            $jobsCategories[$category->getName()] = $em->getRepository(Job::class)->findActiveByCategory($category);
        }

        return $this->render('job/index.html.twig', [
            'categories' => $jobsCategories,
        ]);
    }
}

Ajoutons la méthode permettant de récupérer les offres actives d’une catégorie :

<?php // src/Entity/JobRepository.php

declare(strict_types=1);

namespace App\Repository;

use DateTime;
use Doctrine\ORM\EntityRepository;

class JobRepository extends EntityRepository
{
    public function findActiveByCategory(Category $category)
    {
        return $this->createQueryBuilder('j')
            ->where('j.category = :category')
            ->andWhere('j.expiresAt >= :date')
            ->setParameter('category', $category)
            ->setParameter('date', new DateTime())
            ->getQuery()
            ->getResult();
    }
}

Modifions ensuite le template en conséquence :

{# templates/job/index.html #}
{% extends "base.html.twig" %}

{% block body %}
    <h1 class="my-4">Liste des offres</h1>

    {% for category, jobs in categories %}
        <div class="row">
            <h2 style="font-weight: bold; margin: 2rem 0;">{{ category }}</h2>

            {% for job in jobs %}
                <div class="row">
                    <div class="col-md-7">
                        <a href="#">
                            <img class="img-fluid rounded mb-3 mb-md-0" src="{{ asset('images/' ~ job.logo) }}" alt="{{ job.company }}">
                        </a>
                    </div>
                    <div class="col-md-5">
                        <h3>{{ job.position }}</h3>
                        <p>{{ job.description }}</p>
                        <p>Posted on {{ job.createdAt|date("m/d/Y") }}</p>
                        <a class="btn btn-primary" href="{{ path('job_show', { 'id': job.id, 'company': job.companySlug, 'location': job.locationSlug, 'position': job.positionSlug }) }}">See more</a>
                    </div>
                </div>

                <hr>
            {% endfor %}
        </div>
    {% endfor %}

    <ul class="pagination justify-content-center">
        <li class="page-item disabled">
            <a class="page-link" href="#" aria-label="Previous">
                <span aria-hidden="true">&laquo;</span>
                <span class="sr-only">Previous</span>
            </a>
        </li>
        <li class="page-item">
            <a class="page-link" href="#">1</a>
        </li>
        <li class="page-item disabled">
            <a class="page-link" href="#" aria-label="Next">
                <span aria-hidden="true">&raquo;</span>
                <span class="sr-only">Next</span>
            </a>
        </li>
    </ul>
{% endblock %}

Pour finir, nous allons sécuriser la page de consultation des offres. Effectivement, si vous connaissez l’URL d’une offre, il est possible d’accéder à cette dernière, et ce, même si la date d’expiration est dépassée. Pour cela, rajouter un contrôle dans notre action d’affichage :

<?php // src/Controller/JobController.php

namespace App\Controller;

// ...
use DateTime;

class JobController extends AbstractController
{
    public function show(EntityManagerInterface $em, int $id, string $company, string $location, string $position) : Response
    {
        // dans un projet réel, il sera nécessaire de faire une requête permettant de vérifier que tous les éléments
        // correspondent à une offre d'emploi valide
        $job = $em->getRepository(Job::class)->find($id);
        if (null === $job) {
            throw new NotFoundHttpException();
        }

        $currentDate = new DateTime();
        if ($job->getExpiresAt() < $currentDate) {
            throw new NotFoundHttpException();
        }

        return $this->render('job/show.html.twig', [
            'job' => $job,
        ])
}

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Que 2018 commence !

Fri, 26 Jan 2018 00:00:00 +0100

Oui l’année a commencé depuis presque un mois, mais il n’est jamais trop tard (ni même trop tôt) pour faire un point sur sa vie aussi bien personnelle que professionnelle, car il est important de se fixer des objectifs pour évoluer et progresser. D’ailleurs, je n’avais même pas prévu initialement de faire ce point publiquement, mais Cédric m’a inspiré ce billet.

Changement professionnel

Du point de vue professionnel, nouvelle année et nouvelle entreprise. Après 4 ans passés au sein d’une agence Web, je démarre lundi un nouvel emploi au sein ~~d'un éditeur (chez Wizaplace pour ne pas les citer)~~ du service informatique d’Opéra Energie, un courtier en énergie. Je réalise que ce type de société me convient plus, le rapport au produit étant sensiblement différent que lorsque l’on est prestataire. Travailler dans une agence Web aura été formateur, mais ne correspondait pas à ce que je recherchais pour m’épanouir et évoluer professionnellement comme je le souhaite.

Jobeet

En fin d’année dernière, je démarrais l’adaptation du tutorial Jobeet de Symfony à l’occasion la sortie de la version 4 du framework. J’ai eu beaucoup de retours positifs sur ce dernier et le projet attire de nombreuses personnes. Bien que de nouvelles mises à jour tardent à arriver, je n’ai pas abandonné ce projet. J’espère parvenir à publier les prochains chapitres sous peu. Il est vrai que les dernières semaines étaient chargées !

Une année, un langage

D’un point de vue technique, si 2017 a été pour moi l’année de l’apprentissage de Go, j’aimerai cette année me pencher un peu plus sur Rust. Comme toujours l’idée est de découvrir un nouveau langage qui si possible coupe avec PHP, le langage que j’utilise au quotidien. De plus ce dernier étant un langage interprété (pardonnez-moi cet abus de langage), j’ai plutôt l’envie de découvrir des langages compilés.

2018, le retour aux bases

Cette année, je voudrais également en profiter pour revenir aux bases de la programmation: l’algorithmie et les structures de données. PHP est un langage puissant qui s’est nettement amélioré ces dernières années, mais la principale structure de données que l’on utilise (à l’exception des classes) sont les tableaux.

Mais un tableau PHP n’est pas un simple tableau au sens structure de données comme on peut l’entendre. C’est en réalité une structure de données beaucoup plus complexe qui mélange : une liste doublement chaînée, une map et qui peut être utilisé comme une pile ou un tas.

J’ai envie de me replonger dans les structures de données telles que les listes chaînées, les piles, les tas, les graphs et revoir les différents algorithmes qui en découlent ainsi que leurs applications. Cela devrait me permettre d’utiliser des structures pertinentes et optimisées dans les applications que je pourrais être amené à développer. Ce sera peut-être également l’occasion d’approfondir PHP DS, une extension PHP permettant de travailler avec des structures de données de base et optimisées comme alternative aux tableaux.

En bonus

Ces derniers temps, je m’intéresse de plus en plus aux systèmes distribués, la montée en charge des applications et aux microservices. Plus je m’y intéresse et outre les problématiques de code, je me rends compte qu’il y a de nombreux challenges de l’ordre de l’opérationnel. J’espère ainsi avoir l’occasion de creuser ces concepts et tomber un peu plus dans la culture devops.

Des points pour lesquels j’ai commencé à mettre “les mains dans le cambouis” en démarrant une migration de “mon infrastructure personnelle” (un billet explicatif est prévu sur le sujet #teasing).

-> Voilà qui devrait m’occuper pour l’année à venir ! Je ne vais pas avoir le temps de m’ennuyer, mais c’est l’une des choses que j’apprécie le plus dans notre métier: évoluer et être en perpétuel apprentissage !

Symfony 4 et les tests avec le logger par défaut

Wed, 06 Dec 2017 00:00:00 +0100

Symfony 4 est sortie il y a quelques jours. Ce dernier est dorénavant fourni avec un minimum de dépendances. Monolog n’étant plus fourni par défaut, un logger proposant le strict nécessaire est inclus par défaut. Ce dernier, compatible PSR-3, va logger les informations par défaut sur la sortie standard. Ce fonctionnement peut ne pas être sans impact sur vos tests.

Effectivement, certains frameworks de tests interpréteront les sorties sur la sortie standard comme un défaut de fonctionnement et considérons de ce fait votre test comme échoué.

Pour cela, il sera peut-être nécessaire dans vos tests de remplacer le logger par défaut par le Psr\Log\NullLogger.

Choisir ses dépendances applicatives

Mon, 04 Dec 2017 00:00:00 +0100

Il est rare lorsque l’on développe une application d’écrire soi-même (ou une équipe) 100% du code qui fera fonctionner le projet. Nous utilisons et réutilisation de nombreux outils et composants que nous intégrons à notre code pour gagner du temps et éviter de réinventer la roue. Le choix de ces composants ne doit pas être pris à la légère car ils vont faire partie intégrante de notre code. Nous allons réfléchir dans ce billet aux différents aspects à prendre en compte.

Le premier élément à prendre en compte est le risque lié à la mise en place de la dépendance. Cette dernière a-t-elle une place critique dans le projet ? On ne s’attardera pas, par exemple, sur une librairie de génération d’un UUID, alors que sans aucun doute, une analyse poussée sera réalisée pour choisir le système de gestion de base de données. Effectivement ce dernier, qui servira au stockage des informations traitées par notre application est une pièce maîtresse. Utiliseriez-vous un moteur de base de données totalement inconnu pour un point aussi critique ?

Déterminer le risque d’utiliser tel ou tel module, vous poussera certainement à faire une analyse plus ou moins approfondie de la qualité du composant que vous allez mettre en place. Dans un domaine où nous utilisons de plus en plus d’outils et modules open source, n’importe quel développeur peut explorer le code pour en vérifier sa robustesse. Ce dernier respecte-t-il les “bonnes pratiques” de développement ? Est-il maintenable ? Possède-t-il des tests unitaires et/ou fonctionnels ? Autant de questions qui permettent de dresser un bilan de la qualité du projet. Une dépendance de qualité permettra de garantir son bon fonctionnement sur le long terme et facilitera d’éventuelles interventions au sein de cette dernière.

Un autre point à prendre en compte est l’activité autour du composant auquel on s’intéresse. Peut-être s’agit-il d’un projet de qualité, mais dont le développement n’est plus maintenu. Dans ce cas-là que se passe-t-il si vous rencontrez un problème lors de son utilisation ? Est-ce que l’équipe de développement pourra corriger ce dernier ? Si la réponse à cette question est “non”, il sera peut-être nécessaire de travailler sur votre propre version du module ou éventuellement d’en choisir un autre.

Le dernier point qu’il est intéressant d’analyser est la communauté qui gravite autour de la dépendance étudiée. Plus la communauté sera grande et plus vous pourrez profiter de retours d’expérience, d’aide et de conseils autour des questions et des différentes problématiques que vous pourrez rencontrer. Il faudra sur ce point, faire attention à la notion d’effet de mode. Il peut être préférable dans certains cas d’utiliser des outils éprouvés et pertinents pour l’utilisation que vous souhaitez en avoir. Focalisez-vous sur votre cas d’utilisation et ne choisissez pas spécialement des solutions “passe-partout”.

Le choix d’un module dépend de nombreux critères qui ne seront pas évalués de la même manière en fonction de l’impact dans le projet. Dans tous les cas, ce n’est pas une décision à prendre à la légère car cette dernière vous suivra durant toute la durée de vie du code de l’application. Pour limiter l’impact d’une dépendance et faciliter son remplacement, il est intéressant d’abstraire le côté technique de son utilisation au sein de classes orientées métier.

PHP Meminfo, l'extension qui vous fait voyager dans la mémoire PHP

Thu, 23 Nov 2017 00:00:00 +0100

Savez-vous vraiment comment est consommé la mémoire de votre application PHP ? Si la réponse est non, alors devriez considérer l’utilisation de PHP Meminfo.

PHP Meminfo est une extension PHP vous permettant d’avoir un aperçu de l’utilisation de la mémoire de vos scripts PHP. Cette dernière a été créé dans le but de comprendre l’origine des fuites mémoires de vos applications et de mieux comprendre le comportement de cette dernière.

L’extension vient tout récemment de sortir sa version 1.0.0 apportant notamment un support de PHP 7 et fournit une documentation plus complète.

En bonus, si vous êtes sous macOS et que vous utilisez Homebrew en tant que gestionnaire de paquet, vous aurez la possibilité d’installer très facilement l’extension sur votre système, un paquet étant disponible pour chaque version de PHP.

Tutorial Jobeet pour Symfony 4 - Partie 5: Les routes

Mon, 16 Oct 2017 00:00:00 +0200

Vous connaissez maintenant le principe d’une architecture MVC et comment cette dernière se met en place au sein d’un projet Symfony. Nous avons également rapidement évoqué le principe du routage (ou routing en anglais). Ce chapitre sera entièrement consacré à ce dernier point.

Dans un contexte web, une URL (Uniform Resource Locator) désigne un contenu accessible. Lorsque vous accédez à une page au travers de son URL, vous demandez au navigateur d’aller cherche un contenu identifié. C’est cette information que nous allons devoir décrire dans notre projet.

Dans la section consacrée au contrôleur et à la vue, nous avons commencé à modifier le fichier config/routes.yaml qui permet de faire le lien entre l’URL courante du navigateur et l’action de notre contrôleur devant être exécutée. Nous ne sommes pas rentré dans les détails, mais une route est définie par un nom, un schéma d’URL ainsi que le contrôleur avec la méthode associée.

C’est le composant Routing de Symfony qui s’occupe d’établir la correspondance entre notre configuration et le code de notre projet. Signalons que si deux routes possèdent le même nom, la seconde route écrase la première. De ce fait la première configuration ne sera jamais prise en compte.

Dans l’état actuel de notre projet, notre fichier config/routes.yaml contient la configuration suivante :

# config/routes.yaml
index:
    path: /
    defaults: { _controller: 'App\Controller\JobController::index' }

# Depends on sensio/framework-extra-bundle, doctrine/annotations, and doctrine/cache
#   install with composer req sensio/framework-extra-bundle annot
#controllers:
#    resource: ../src/Controller/
#    type: annotation

Une seule route y est déclarée. Cette dernière correspond à la page d’accueil de notre application qui liste les offres d’emploi disponible. Ajoutons maintenant une route qui permettra d’afficher le détail d’une offre.

Les offres d’emploi sont créées dynamiquement par un utilisateur. Pour accéder au détail d’une offre, nous allons faire référence à son identifiant unique de base de données (autrement dit, la propriété $id de notre classe Job). Nous allons créer une route qui contiendra un paramètre dynamique permettant de récupérer cette information et de la transmettre à notre action.

Modifions le fichier de configuration en conséquence :

# config/routes.yaml
index:
    path: /
    defaults: { _controller: 'App\Controller\JobController::index' }

job_show:
    path: /job/{id}
    defaults: { _controller: 'App\Controller\JobController::show' }

# Depends on sensio/framework-extra-bundle, doctrine/annotations, and doctrine/cache
#   install with composer req sensio/framework-extra-bundle annot
#controllers:
#    resource: ../src/Controller/
#    type: annotation

Nous venons donc de rajouter une nouvelle route nommée job_show qui correspond à l’appel de la méthode show de notre classe JobController. Le paramètre de la route est indiqué entre crochet ({id}), ce dernier correspond au nom de la variable qui sera automatiquement passé à la méthode du contrôleur.

Sur notre environnement de développement local, il sera possible d’accéder à une offre d’emploi au travers de l’URL http://localhost:8000/job/1 ou http://localhost:8000/job/2

Ajoutons maintenant l’action correspondante dans notre contrôleur :

<?php // src/Controller/JobController.php

namespace App\Controller;

use App\Entity\Job;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

class JobController extends AbstractController
{
    // ...

    public function show(EntityManagerInterface $em, int $id): Response
    {
        $job = $em->getRepository(Job::class)->find($id);
        if (null === $job) {
            throw new NotFoundHttpException();
        }

        return $this->render('job/show.html.twig', [
            'job' => $job,
        ]);
    }
}

La vue affichée par cette action ne sera pas détaillée car elle ne présente pas d’intérêt pour le routing. Je vous invite à récupérer le contenu du fichier directement sur le dépôt du projet.

Nous découvrons dans ce contrôleur comment décrire une route contenant un paramètre dynamique. Dans l’exemple précédent, le paramètre $id est automatiquement extrait de l’URL et transmis à l’action de notre contrôleur. Symfony faisant correspondre le nom du paramètre de notre configuration avec le nom de la variable de présent dans la définition de notre action.

Notons au passage l’utilisation de la méthode find de Doctrine permettant de récupérer l’objet via sa clé primaire de base de données.

Après avoir effectué notre requête en base de données avec Doctrine, il convient de contrôler que l’identifiant transmis correspond bien à une offre d’emploi. Si ce n’est pas le cas, nous générons une exception afin d’indiquer que l’utilisateur tente d’accéder à une ressource qui n’existe pas.

La classe Symfony\Component\HttpKernel\Exception\NotFoundHttpException est une exception fournie par le composant HttpFundation de Symfony. Elle permet de lancer d’indiquer au framework que l’erreur rencontrée est de type “ressource introuvable”. Le framework générera ainsi automatiquement une réponse renvoyant le code HTTP 404 au navigateur.

Nous avons créé une route qui permet de capter un paramètre correspondant à l’identifiant d’une offre d’emploi. Mais à ce stade, nous n’avons défini aucune restriction sur ce paramètre. Une donnée de type numérique est attendue, mais actuellement rien n’empêche un utilisateur d’entrer une URL du type /job/mon-offre. Cette adresse est valide mais va provoquer une erreur car nous avons indiqué dans notre action que la paramètre $id était de type int.

Pour éviter ce problème, il est possible de définir des règles de validations des adresses pouvant être captées par nos routes. Ajoutons donc un prérequis sur le paramètre {id} afin d’indiquer que ce dernier ne doit prendre en compte que les valeurs numériques entières.

# config/routes.yaml

# ...
job_show:
    path: /job/{id}
    defaults: { _controller: 'App\Controller\JobController::show' }
    requirements:
        id: '\d+'

# ...

Pour définir une contrainte sur un paramètre de notre URL, nous utilisons le mot-clé requirements qui permet de définir une liste de prérequis. Dans l’exemple précédent, nous spécifions que le paramètre id doit être de valeur numérique.

Le format des validateurs est en réalité une expression régulière. Le format raccourci \d+ correspond en réalité à l’expression [0-9]+.

Si nous réfléchissons d’un point de vue SEO, nos URL de type /job/1 ne sont pas très explicites et pourraient pénaliser notre référencement dans les moteurs de recherche. Une URL du type /job/sensio-labs/1/web-developer serait plus pertinente car elle décrit mieux la ressource à laquelle elle fait référence. Effectuons cette modification :

# config/routes.yaml

# ...
job_show:
    path: /job/{company}/{location}/{id}/{position}
    defaults: { _controller: 'App\Controller\JobController::show' }
    requirements:
        id: '\d+'
        company: '[A-Za-z0-9\-]+'
        location: '[A-Za-z0-9\-]+'
        position: '[A-Za-z0-9\-]+'

# ...

Et adaptons notre classe JobController en conséquence :

<?php // src/Controller/JobController.php

namespace App\Controller;

use App\Entity\Job;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

class JobController extends AbstractController
{
    // ...

    public function show(EntityManagerInterface $em, int $id, string $company, string $position, string $location): Response
    {
        // Faire les contrôles sur les variables $company et $position
        // ou les inclures dans la requête SQL
        $job = $em->getRepository(Job::class)->find($id);
        if (null === $job) {
            throw new NotFoundHttpException();
        }

        return $this->render('job/show.html.twig', [
            'job' => $job,
        ]);
    }
}

Nous n’implémenterons pas les requêtes ni les vérifications, ce n’est pas l’objectif de ce tutorial. Qui se concentre sur l’écriture d’une application avec Symfony.

Maintenant que nous avons ajouté notre page permettant de visualiser le détail d’une offre d’emploi, nous allons devoir mettre à jour les liens permettant à un utilisateur de naviguer au sein de notre application. Pour faciliter la navigation entre les pages dans nos templates Twig, le module TwigBridge met en place des fonctions permettant de faire référence à une page au travers du nom de la route associée. C’est notamment le cas de la fonction path. Cette dernière prend en paramètre le nom de la route à laquelle nous allons faire référence ainsi que les différentes variables nécessaires à la génération de l’URL.

<!-- templates/job/index.html.twig -->
{% extends "base.html.twig" %}

{% block body %}
    <h1 class="my-4">Liste des offres</h1>

    {% for job in jobs %}
        <div class="row">
            <div class="col-md-7">
                <a href="#">
                    <img class="img-fluid rounded mb-3 mb-md-0" src="{{ asset('images/' ~ job.logo) }}" alt="{{ job.company }}">
                </a>
            </div>
            <div class="col-md-5">
                <h3>{{ job.position }}</h3>
                <p>{{ job.description }}</p>
                <p>Posted on {{ job.createdAt|date("m/d/Y") }}</p>
                <a class="btn btn-primary" href="{{ path('job_show', { 'id': job.id, 'company': job.companySlug, 'location': job.locationSlug, 'position': job.positionSlug }) }}">See more</a>
            </div>
        </div>

        <hr>
    {% endfor %}

    <!-- ... -->
{% endblock %}

Pour générer le lien vers une offre d’emploi, nous avons utilisé les propriétés job.companySlug, job.locationSlug et job.positionSlug de notre classe Job. Ces dernières correspondent en réalité à des appels de méthode (au besoin, je vous invite à relire le chapitre concernant Twig pour plus d’informations). L’implémentation des méthodes ne sera pas détaillée, consultez le code source de la classe pour plus de détails.

Au fur et à mesure que nous allons ajouter des fonctionnalités à notre application, cette dernière va grossir et contenir de plus en plus de code et de configuration. Il peut être parfois utile de lister l’ensemble des routes disponibles sans pour autant devoir parcourir les différents fichiers de configuration. Pour cela, Symfony met à disposition des développeurs une commande permettant d’afficher ces dernières :

Cette commande permet également d’obtenir des informations détaillées sur une route. Il suffit pour cela d’indiquer le nom de la route en question :

Ce chapitre a introduit la notion de route et explique comment créer des liens entre les pages de votre application. Vous avez ainsi appris à utiliser le composant Routing de Symfony. Le prochain sera consacré à l’approfondissement du concept de modèle. Nous y expliquerons plus en détail comment structurer l’information et faire des requêtes complexes.

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Proxifier des requêtes HTTP en PHP

Wed, 11 Oct 2017 00:00:00 +0200

Ce soir, je me suis demandé comment il était possible de “proxifier” une requête HTTP effectuée depuis un script PHP. Pour être plus précis, je souhaitais faire une requête sur le réseau TOR (ou via n’importe quel proxy de manière générale) via une commande PHP.

En fait cela est beaucoup plus simple que je ne le pensais car l’extension CURL de PHP contient tout le nécessaire pour réaliser cette tâche. Il suffit pour cela de passer les bonnes options à notre ressource :

<?php

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'https://check.torproject.org');
curl_setopt($ch, CURLOPT_PROXY, 'localhost:9150'); // l'URL de notre proxy
curl_setopt($ch, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5); // le type du proxy
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 0);
curl_setopt($ch, CURLOPT_HEADER, 1);
$curl_scraped_page = curl_exec($ch);
curl_close($ch);

echo $curl_scraped_page;

Si vous utilisez une bibliothèque type Guzzle, ces dernières fournissent généralement tout le nécessaire pour proxifier vos requêtes HTTP.

D’ailleurs concernant cette dernière, j’ai trouvé un middleware megahertz/guzzle-tor dédié à la mise en place d’une connexion via TOR.

Ma semaine 40 de veille (02/10/2017 -> 08/10/2017)

Mon, 09 Oct 2017 00:00:00 +0200

Retrouvez chaque semaine la sélection de mes 5 tweets les plus populaires concernant la veille que je partage sur Twitter. Abonnez-vous au flux RSS, du site ou plus précisément à celui de cette catégorie pour être notifié des mises à jour.

Mon actu préférée

One Million Tables in MySQL 8.0 : https://t.co/edGYq1Jqed
— Jérémy DECOOL (@jdecool) 2 octobre 2017

La prochaine version majeure de MySQL arrive très prochainement. Cette semaine, Percona (société d'experts reconnue en performances de bases de données) a réalisé un benchmark l'efficacité de cette nouvelle monture sur un jeu de données d'un million de tables.

Le top de la semaine

How to Docker Compose a developer environment: an open source example : https://t.co/tI7Yt7pIxO
— Jérémy DECOOL (@jdecool) 3 octobre 2017

Docker a ouvert de nouvelles perspectives dans la gestion et le déploiement d'applications informatiques. Ce dernier a également su faire sa place auprès des développeurs pour la mise en place de leurs environnements de développement. Cet article en fait la démonstration au travers d'un projet open source.

3 Reasons Why You Should Quit Your Job : https://t.co/dWH3QmMjJo
— Jérémy DECOOL (@jdecool) 6 octobre 2017

En tant que professionnel de l'informatique, nous évoluons dans un domaine dynamique. Patrick God est développeur depuis une quinzaine d'années. Il évoque les 3 principales raisons qui selon lui pousse quelqu'un à rechercher un nouvel emploi.

Comment utiliser Docker multi-stage build avec Golang : https://t.co/aErQr25sUz
— Jérémy DECOOL (@jdecool) 2 octobre 2017

La version 17.05 de Docker a introduit la notion de "multistage build". Cette fonctionnalité offre la possibilité d'avoir plusieurs phases de construction de votre image. Parfois mal compris des utilisateurs, découvrez au travers de cet exemple une mise en pratique de ce nouveau concept.

Générer de la cryptomonaie en respectant les visiteurs : https://t.co/HPDYq960Xu
— Jérémy DECOOL (@jdecool) 5 octobre 2017

Récemment le site ThePirateBay à mis en place un script permettant de miner de la cryptomonnaie dans les pages web visitaient par les internautes. Si l'utilisateur est prévenu est favorable à ce système, cela peut représenter une alternative à de la publicité. Encore faut-il que cela se fasse en respectant nos utilisateurs.

Event-Driven Architecture : https://t.co/CgIwzevnDT
— Jérémy DECOOL (@jdecool) 6 octobre 2017

Les architectures orientées événements ont le vent en poupe actuellement car elles permettent de mettre en place une stratégie de découplage de notre code. Apprenez en davantage au travers de ce billet sur quand, comment et pourquoi mettre en place une telle architecture.

Ma semaine 39 de veille (25/09/2017 -> 01/10/2017)

Mon, 02 Oct 2017 00:00:00 +0200

Mon actu préférée

Google partage gratuitement ses outils pour managers : https://t.co/94eKhVpoy5
— Jérémy DECOOL (@jdecool) 29 septembre 2017

Google vient de rendre public certains des outils mis à disposition de ses managers pour les aider dans la gestion d'équipe. Des ressources très intéressantes à découvrir que l'on soit manager ou travaillant dans une équipe !

Le top de la semaine

Practical Clean Architecture in PHP [Part 1]: Domain layer https://t.co/iIEC88CdJp pic.twitter.com/4A7fTpkjzU
— Jérémy DECOOL (@jdecool) 25 septembre 2017

Lorsque l'on conçoit une application, nous cherchons toujours à ce que cette dernière soit évolutive et maintenable. Pour cela nous mettons en place des pratiques de "Clean Code", nous cherchons à coder proprement. Cette introduction vous fera découvrir les concepts pour séparer la logique de votre application en une couche indépendante (le domaine).

Goodbye controllers, hello request handlers : https://t.co/krnLLj4P7W
— Jérémy DECOOL (@jdecool) 26 septembre 2017

Si vous avez travaillé avec de grandes bases de code, peut-être avez-vous déjà vu des contrôleurs interminables et inmaintenable car ils ne respectaient pas les principes DRY et SOLID. En effet, ces concepts ne sont pas souvent utilisés pour des contrôleurs. Pourtant PHP a tout ce qu'il faut pour respecter ce principe.

Le documentaire Nothing To Hide est maintenant disponible gratuitement en français : https://t.co/osYFeqFEdp
— Jérémy DECOOL (@jdecool) 30 septembre 2017

Lorsque l'on parle du problème de la surveillance de masse et du pouvoir des GAFAM ont avec les données utilisateurs, l'argument qui revient le plus fréquemment est: "je n'ai rien à cacher". Ce documentaire, disponible sous licence Creative Commons, a pour vocation de vous démontrer pourquoi vous devriez quand même y faire attention.

Les députés adoptent l’obligation de déclarer tous ses identifiants électroniques : https://t.co/46hDK6b3tl
— Jérémy DECOOL (@jdecool) 27 septembre 2017

Les députés viennent de voter des mesures de contrôle et de surveillance individuelles. Parmi ces dernières, l'obligation pour une personne au comportement suspect de fournir l'intégralité de ses identifiants aux autorités administratives. Nextimpact nous résume cela dans cet article.

MySQL 8.0 RC1 – Highlights https://t.co/jAYdJsxT0Z
— Jérémy DECOOL (@jdecool) 26 septembre 2017

La sortie de la prochaine version de MySQL (la version 8.0) arrive à grands pas et propose de nombreuses évolutions. L'occasion de faire un tour d'horizon des nouveautés à venir.

Tutorial Jobeet pour Symfony 4 - Partie 4B: La gestion des assets avec Twig

Sat, 30 Sep 2017 00:00:00 +0200

Dans la section précédente, nous avons commencé à afficher nos premières pages et avons défini une charte graphique. Nous avons donc inclus un certain nombre de fichiers CSS, Javascript et utilisé des images. Voyons avant de continuer quelques bonnes pratiques sur la gestion des assets.

Les assets sont des fichiers statiques qui sont utilisés par l’interface de notre site. Il peut s’agir de fichiers CSS (pour la mise en page et la charte graphique du site), Javascripts (pour gérer l’interactivité de notre interface avec l’utilisateur), d’images ou par exemple des fichiers pouvant être téléchargées par l’utilisateur.

Tout d’abord, revoyons notre template base.html.twig qui inclut nos différentes feuilles de style :

# templates/base.html.twig
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
        <title>{% block title %}Jobeet{% endblock %}</title>
        <link rel="stylesheet" href="/vendor/bootstrap/css/bootstrap.min.css">
        <link rel="stylesheet" href="/vendor/1-col-portfolio.css">
        {% block stylesheets %}{% endblock %}
    </head>
    <body>
        <nav class="navbar navbar-expand-lg navbar-dark bg-dark fixed-top">
            <div class="container">
                <a class="navbar-brand" href="#">Jobeet</a>
                <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarResponsive" aria-controls="navbarResponsive" aria-expanded="false" aria-label="Toggle navigation">
                    <span class="navbar-toggler-icon"></span>
                </button>
            </div>
        </nav>

        <div class="container">
            {% block body %}{% endblock %}
        </div>

        <script src="/vendor/jquery/jquery-3.2.1.slim.min.js"></script>
        <script src="/vendor/popper/popper.min.js"></script>
        <script src="/vendor/bootstrap/js/bootstrap.min.js"></script>
        {% block javascripts %}{% endblock %}
    </body>
</html>

Pour inclure nos différents fichiers, nous avons spécifié le chemin complet pour accéder à nos ressources. Cette pratique n’est pas recommandée car elle possède de nombreux désavantages :

Elle rend nos templates verbeux en nous obligeant à écrire pour chaque fichier le chemin complet pour y accéder.
Le versionnement des fichiers est compliqué car il nécessite d’être géré manuellement pour chaque ressource.
Le déplacement des assets peut être source d’erreurs.
L’utilisation d’un CDN est impossible avec cette gestion manuelle.

Afin de résoudre toutes ces problématiques, il existe de nombreux composants PHP permettant de mettre en place une gestion d’asset simple, efficace et maintenable. Symfony propose également un composant pour ça, installons-le :

$ composer require symfony/asset

Using version ^3.3 for symfony/asset
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing symfony/asset (v3.3.9): Downloading (100%)
Writing lock file
Generating autoload files
Executing script make cache-warmup [OK]
Executing script assets:install --symlink --relative public [OK]

Une fois téléchargé, le composant est tout de suite prêt à être utilisé dans notre projet. Lors de notre découverte de Twig, nous avons rapidement évoqué le composant TwigBridge comme étant un module permettant d’étendre le fonctionnement de Twig en ajoutant des fonctionnalités spécifiques aux différents modules de de Symfony. Le composant Asset en fait partie. TwigBridge fournit ainsi une fonction asset permettant d’accéder à une ressource.

Modifions notre template d’origine :

# templates/base.html.twig
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
        <title>{% block title %}Jobeet{% endblock %}</title>
        <link rel="stylesheet" href="{{ asset('vendor/bootstrap/css/bootstrap.min.css') }}">
        <link rel="stylesheet" href="{{ asset('vendor/1-col-portfolio.css') }}">
        {% block stylesheets %}{% endblock %}
    </head>
    <body>
        <nav class="navbar navbar-expand-lg navbar-dark bg-dark fixed-top">
            <div class="container">
                <a class="navbar-brand" href="#">Jobeet</a>
                <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarResponsive" aria-controls="navbarResponsive" aria-expanded="false" aria-label="Toggle navigation">
                    <span class="navbar-toggler-icon"></span>
                </button>
            </div>
        </nav>

        <div class="container">
            {% block body %}{% endblock %}
        </div>

        <script src="{{ asset('vendor/jquery/jquery-3.2.1.slim.min.js') }}"></script>
        <script src="{{ asset('vendor/popper/popper.min.js') }}"></script>
        <script src="{{ asset('vendor/bootstrap/js/bootstrap.min.js') }}"></script>
        {% block javascripts %}{% endblock %}
    </body>
</html>

Nous pouvons également modifier l’affichage de l’image d’une offre d’emploi dans le fichier templates/job/index.html.twig. Notons au passage l’utilisation de l’opérateur de concaténation de chaine de caractère Twig ~.

Peut-être que vous ne remarquez que très peu de différences. Pour le moment, nous avons juste utilisé notre fonction asset mais le code reste le même et le chemin vers le fichier est toujours présent.

S’il y a peu de différences, c’est tout d’abord parce que nous avons placé nos fichiers dans le répertoire public (qui est le point d’entrée du serveur HTTP pour rechercher nos fichiers accessibles publiquement). C’est donc le répertoire où le composant Asset va rechercher nos fichiers par défaut.

Imaginons que nous souhaitons changer le répertoire contenant nos ressources, pour par exemple le déplacer dans un sous-répertoire public/assets. Il ne sera maintenant plus nécessaire de modifier tous les chemins des fichiers que nous avons utilisés. Il suffira de modification la configuration du framework afin de spécifier le répertoire racine qui contient nos assets comme dans l’exemple ci-dessous :

# config/packages/framework.yml
framework:
    # ...
    assets:
        base_path: '/assets'

Au travers de cet exemple, il est possible de commencer à voir les avantages d’utiliser un composant pour gérer nos ressources. Une autre des fonctionnalités majeures du module Asset est la gestion du versionnement des fichiers. Pour plus d’informations sur le versionnement des assets, je vous propose de consulter la documentation officielle qui fournira tous les informations utiles.

Si vous souhaitez spécifier une version d’asset dans notre projet, voici la configuration que vous allez devoir renseigner :

# config/packages/framework.yml
# app/config/config.yml
framework:
    # ...
    assets:
        version: 'v2' # asset('/images/logo.png') ==> /images/logo.png?v2

Le versionnement des assets est très utile pour gérer la mise en cache de nos ressources. C’est une pratique courante pour optimiser les données devant être renvoyées par les serveurs HTTP et économiser des appels réseaux.

Avant de terminer sur la gestion des ressources, évoquons une dernière fonctionnalité essentielle : la gestion des CDN.

Un Content Delivery Network (CDN ou réseau de diffusion de contenu en français) est une plate-forme de serveurs hautement distribuée optimisée pour diffuser du contenu. Les CDN ont l’avantage d’accélérer le chargement des pages.

Pour mettre en place la gestion d’un CDN, il suffit comme pour le versionnement des ressources, de spécifier les domaines qui vont être utilisés dans le fichier de configuration. Symfony sélectionnera un domaine (si vous n’en spécifiez pas un lors de l’utilisaton de la fonction asset) à chaque génération d’un page.

# config/packages/framework.yml
framework:
    # ...
    assets:
        base_urls:
            - 'http://cdn.example.com/' # asset('/images/logo.png') ==> http://cdn.example.com/images/logo.png

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Tutorial Jobeet pour Symfony 4 - Partie 4A: Le contrôleur et la vue

Fri, 29 Sep 2017 00:00:00 +0200

Nous avons jusqu’à présent entrevu le fonctionnement de Doctrine en créant une base de données et en y insérant un jeu de données afin d’avoir des données initiales, nous évitant ainsi d’avoir une application vide. Nous allons maintenant pouvoir commencer à afficher nos premières pages web.

Un projet Symfony repose sur le pattern MVC (Model View Controller ou Model Vue Contrôleur en français). Ce type d’architecture permet d’organiser le code en le séparant en trois couches :

La couche modèle contenant le traitement logique de vos données (on y retrouve les traitements métier, les accès à la base de données, …).
La vue est la modélisation de l’IHM (Interface Homme Machine). Elle représente ce qui est rendu à l’utilisateur (sous la forme d’une page Web, d’une commande d’un terminal, de données JSON/XML, …).
Le contrôleur correspond au code faisant le lien entre le modèle et la vue. Il récupère les données utilisateurs pour y appliquer les traitements et donner les résultats à la vue. Démarrons par ce dernier. Comme nous venons brièvement de le dire, le contrôleur est la couche qui va exécuter les traitements liés à notre application et transmettre les résultats à la vue pour que ces derniers puissent être affichés à l’utilisateur. Dans notre projet Web, cela va se matérialiser par des classes qui vont contenir des fonctions qui seront appelées en fonction d’une URL. Ces dernières renverront un objet de type Symfony\Component\HttpFoundation\Response qui est l’abstraction d’une réponse HTTP dans Symfony.

Ecrivons un premier contrôleur que nous allons nommer DefaultController et que nous allons placer dans le répertoire src/Controller. Ce dernier, contiendra une fonction qui permettra d’afficher un message dans le navigateur.

<?php // src/Controller/DefaultController.php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;

class DefaultController
{
    public function index(): Response
    {
        return new Response('Accueil Jobeet - Hello');
    }
}

Pour tester ce code, nous allons devoir indiquer au framework comment accéder à ce contrôleur. Pour cela nous allons éditer le fichier config/routes.yaml. Sans rentrer dans les détails (car c’est le sujet du prochain chapitre), ce fichier permet d’indiquer à Symfony l’URL qui déclenchera l’appel de la méthode index de notre contrôleur.

Pour le moment, décommentons simplement les 3 premières lignes :

# config/routes.yaml

index:
    path: /
    defaults: { _controller: 'App\Controller\DefaultController::index' }

# Depends on sensio/framework-extra-bundle, doctrine/annotations, and doctrine/cache
#   install with composer req sensio/framework-extra-bundle annot
#controllers:
#    resource: ../src/Controller/
#    type: annotation

Nous pouvons maintenant démarrer notre serveur Web via l’exécution de la commande make serve bin/console server:run dans un terminal et se rendre à l’adresse http://localhost:8000 avec son navigateur pour visualiser le résultat.

Pour pouvoir exécuter les différents traitements de notre application, le contrôleur doit pouvoir récupérer les données saisies par les utilisateurs. Dans un environnement Web, ces informations sont transmises par le navigateur au sein d’une requête HTTP.

Symfony utilise un composant HttpFoundation, dont l’objectif est de fournir une couche objet permettant de travailler avec le protocole HTTP. Nous avons, dans les exemples précédents, déjà utilisé un objet Response issue de ce composant. Nous allons maintenant utiliser un objet Symfony\Component\HttpFoundation\Request nous permettant d’accéder à toutes les informations d’une requête HTTP.

Pour ce faire, Symfony passe automatiquement en paramètre une instance d’un objet Request aux actions de nos contrôleurs si le paramètre est présent (Symfony détecte automatiquement la variable grâce à son typage).

Complétons notre code précédent pour récupérer un paramètre name et afficher le nom de la personne à saluer.

<?php // src/Controller/DefaultController.php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

class DefaultController
{
    public function index(Request $request): Response
    {
        return new Response('Accueil Jobeet - Hello '.$request->get('name', 'World'));
    }
}

Dans cet exemple, nous utilisons la méthode Request::get pour récupérer un paramètre de la requête. Ce paramètre peut être transmis via l’URL ou au travers d’une requête de type POST. S’il n’est présent dans aucun des cas, nous avons choisi ici de retourner la valeur par défaut “World”. La valeur par défaut est facultative, si rien n’est spécifié et que le paramètre n’est pas présent NULL sera renvoyé.

Intéressons-nous maintenant à la couche vue. C’est cette dernière qui renvoie et met en forme les informations qui seront affichées à l’utilisateur. Le format de retour des données dépend de plusieurs paramètres dont le contexte d’utilisation. Dans le cas d’une navigation Web classique, l’application va retourner des données au format HTML, alors que dans le cas d’une API, les données pourraient être renvoyées au format JSON, XML ou n’importe quel autre format. Dans ce cas chapitre nous allons travailler exclusivement avec des pages HTML.

Comme nous l’avons déjà évoqué auparavant, Symfony 4 laisse libre le développeur de choisir les outils qu’il souhaite utiliser. Le framework ne prend aucun parti pris. De ce fait et contrairement aux versions précédentes, Symfony n’est plus fourni avec un moteur de templating par défaut.

Les moteurs de templating simplifient le travail d’écriture HTML en améliorant la lisibilité du code, son organisation et sa maintenance. Ces derniers sont généralement fournis avec un ensemble de fonctions de haut niveau permettant entre autres d’afficher des variables PHP, de créer des macros, d’utiliser des structures de boucles et de contrôles, etc.

Dans ce tutorial, nous avons fait le choix d’utiliser Twig. Twig a été créé par l’agence SensioLabs, les créateurs du framework Symfony. Ce moteur de templating était jusqu’à maintenant celui qui était fourni par défaut avec le framework. Sa simplicité et sa puissance en font le moteur le plus populaire PHP.

Avant de pouvoir commencer à nous servir de Twig dans notre projet, nous allons devoir installer les dépendances nécessaires. Pour fonctionner dans notre projet Symfony, plusieurs composants sont requis :

Twig: le moteur de template en lui-même. Ce dernier n’est pas couplé à Symfony et peut ainsi être réutilisé dans n’importe quel projet (avec ou sans framework).
TwigBridge: permet d’intégrer des nouvelles fonctionnalités au moteur de template qui sont liées aux différents composants du framework (formulaires, internationalisation, …).
TwigBundle: l’intégration du moteur Twig dans Symfony.

Comme pour toute dépendance PHP, nous allons utiliser Composer (et Symfony Flex) pour installer Twig. Nous allons ainsi demander l’installation de symfony/twig-bundle. Ce dernier ayant besoin des deux autres composants pour fonctionner, toutes les dépendances requises au fonctionnement de Twig dans notre projet seront mises en place.

$ composer require symfony/twig-bundle

Using version ^3.3 for symfony/twig-bundle
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 3 installs, 0 updates, 0 removals
  - Installing twig/twig (v2.4.3): Loading from cache
  - Installing symfony/twig-bridge (v3.3.9): Downloading (100%)
  - Installing symfony/twig-bundle (v3.3.9): Downloading (100%)
Writing lock file
Generating autoload files
Symfony operations: 1 recipe
  - Configuring symfony/twig-bundle (3.3): From github.com/symfony/recipes:master
Executing script make cache-warmup [OK]
Executing script assets:install --symlink --relative public [OK]

Il est également possible d’utiliser une notation raccourcie pour installer Twig au travers de la commande composer require twig. Cela est possible grace à Symfony Flex qui permet de définir des noms alternatifs à des dépendances Composer. Dans le chapitre précédent, nous aurions pu utiliser la commande composer require orm pour installer Doctrine, cette dernière commande étant un alias de la commande composer require orm/pack.

Maintenant que Twig est installé, nous allons pouvoir créer et afficher notre premier template. Pour cela, nous allons commencer par injecter le moteur de templating dans notre contrôleur. Nous pourrons ensuite, utiliser ce dernier depuis nos actions pour récupérer le rendu de nos templates.

<?php // src/Controller/DefaultController.php

namespace App\Controller;

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Twig\Environment;

class DefaultController
{
    private $twig;

    public function __construct(Environment $twig)
    {
        $this->twig = $twig;
    }

    public function index(Request $request): Response
    {
        return new Response($this->twig->render('home.html.twig', [
            'name' => $request->get('name', 'World')
        ]));
    }
}

Notez qu’il n’est pas nécessaire de faire quoi que ce soit pour injecter notre objet Twig\Environment dans le constructeur de notre contrôleur. Le composant d’injection de dépendance de Symfony utilise l’autowiring pour injecter notre dépendance automatiquement.

Au moment de l’installation de Twig, Flex a préparé un dossier template à la racine de notre projet et a automatiquement configuré Twig pour que ce dernier aille chercher nos vues dans ce répertoire. Nous allons donc y créer un fichier home.html.twig.

# templates/home.html.twig
Hello {{ name }}

Pour afficher les variables que nous avons passé à notre template Twig, il faut utiliser la syntaxe {{ variable }}. Pour afficher le contenu de notre template, nous appelons la méthode render de Twig et passons le résultat à notre objet Response pour que le résultat puisse être retourné à l’utilisateur. Pour afficher le résultat de notre vue, cette syntaxe est un peu longue. Effectivement, nous allons devoir injecter dans chacun de nos contrôleurs une instance de Twig, récupérer le contenu d’un template et créer la réponse associée. Heureusement, Symfony met à notre disposition des outils pour simplifier notre travail et surtout mutualiser ce code au travers de la classe AbstractController. Cette dernière met à disposition une méthode render qui récupérera automatiquement une instance de Twig et créera notre objet Response en un appel de méthode.

Notre contrôleur peut ainsi être réécrit de la manière suivante :

<?php  // src/Controller/DefaultController.php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

class DefaultController extends AbstractController
{
    public function index(Request $request): Response
    {
        return $this->render('home.html.twig', [
            'name' => $request->get('name', 'World')
        ]);
    }
}

Nous connaissons à présent le fonctionnement des contrôleurs et comment ces derniers communiquent avec la vue pour afficher nos données à l’utilisateur. Nous allons maintenant pouvoir afficher les premières pages de notre projet Jobeet. Commençons par la page de listing des offres d’emploi.

Créons pour cela un contrôleur dédié à la gestion des offres et ajouter une méthode pour récupérer les offres disponibles.

<?php // src/Controller/JobController.php

namespace App\Controller;

use App\Entity\Job;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;

class JobController extends AbstractController
{
    public function index(EntityManagerInterface $em)
    {
        $jobs = $em->getRepository(Job::class)->findAll();

        return $this->render('job/index.html.twig', [
            'jobs' => $jobs,
        ]);
    }
}

Nous injectons ici un objet de type EntityManagerInterface directement dans notre méthode grace à l’autowiring (Symfony va détecter et injecter l’instance de l’objet qui implémente l’interface).

L’autowiring fonctionne avec une interface uniquement s’il n’existe qu’une seule classe qui implémente l’interface en question. Si deux classes implémentent la même interface, Symfony ne sera pas capable de savoir quelle instance injecter.

L’EntityManager est l’objet Doctrine qui permet de manipuler nos entités. Dans notre code, nous demandons une instance du repository (c’est-à-dire la classe qui permet de faire les requêtes en base de données) de notre entité Job pour ensuite récupérer la liste des emplois disponibles.

Doctrine fournit un ensemble de méthodes par défaut permettant de récupérer nos objets persistés. Signalons entre autres les fonctions find, findBy, findOneBy et findAll.

Ajoutons la vue qui va afficher nos résultats :

<!-- templates/job/index.html.twig -->

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <title>Jobeet - Liste des jobs</title>
        <link rel="icon" type="image/x-icon" href="{{ asset('favicon.ico') }}" />
    </head>
    <body>
        <ul>
            {% for job in jobs %}
                <li>{{ job.position }}</li>
            {% endfor %}
        </ul>
    </body>
</html>

Pour afficher la page, il sera nécessaire de modifier le fichier de configuration config/routes.yaml en modifiant le contrôleur devant être appelé.

L’exemple ci-dessus nous permet de découvrir de nouveaux éléments du langage de Twig. Tout d’abord, les instructions d’itérations qui nous permettent de parcourir des données de type array ou plus généralement des données iterable de PHP. Il s’agit d’une boucle for permettant de parcourir une liste d’éléments.

Nous constatons également qu’il est possible de passer à notre template Twig des instances d’objets et d’accéder aux propriétés de ces derniers avec l’opérateur . (cela fonctionnement également pour accéder à des tableaux).

Bien que la propriété position de notre objet Job soit privée, Twig parvient à afficher cette dernière. Twig possède un mécanisme qui va automatiquement trouver la méthode get associé à la propriété si cette dernière n’est pas accessible directement (si elle n’est pas public). Il est toutefois possible d’appeler directement la méthode getPosition() ou n’importe quelle autre méthode depuis notre template.

Pour le moment nous avons copié la totalité de la structure HTML dans notre fichier. Pour éviter d’avoir à dupliquer de nombreuses lignes de code dans tous nos templates, nous allons mutualiser le code qui va être commun à toutes les pages.

Si vous jetez un oeil aux fichiers qui ont été ajoutés dans le dossier templates par Flex lors de l’installation de Twig, vous noterez la présence d’un fichier base.html.twig.

<!-- templates/base.html.twig -->

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <title>{% block title %}Jobeet{% endblock %}</title>
        {% block stylesheets %}{% endblock %}
    </head>
    <body>
        {% block body %}{% endblock %}
        {% block javascripts %}{% endblock %}
    </body>
</html>

Ce fichier correspond à un template qui a vocation de définir la mise en page globale de notre application. Twig fonctionne sur le principe d’héritage. Cela signifie que vous allez pouvoir définir des templates qui contiendront des éléments qui pourront ensuite être surchargés dans d’autres templates. Pour cela, Twig utilise un système de blocs (block).

Utilisons le fichier templates/base.html.twig pour définir la mise en page de Jobeet. Pour commencer, nous allons étendre ce dernier dans notre template templates/job/index.html.twig et surcharger le bloc body pour y faire apparaître notre contenu :

<!-- templates/job/index.html.twig -->
{% extends "base.html" %}

{% block body %}
    <ul>
        {% for job in jobs %}
            <li>{{ job.position }}</li>
        {% endfor %}
    </ul>
{% endblock %}

Si vous rechargez la page, le résultat devrait être identique, mais nous avons beaucoup moins de code dans notre template, qui se concentre maintenant uniquement sur une tâche bien précise : afficher notre liste d’offres d’emploi.

Pour que nous interfaces soient un plus agréables à utiliser, nous allons y ajouter un peu de style avec du CSS. Pour gagner du temps, nous allons utiliser le framework boostrap au travers de ce thème https://startbootstrap.com/template-overviews/1-col-portfolio/ .

Une fois les fichiers téléchargés, nous allons placer les différents fichiers CSS et Javascript dans le dossier public (car ces derniers doivent être desservis par le serveur HTTP). Nous les organiserons dans un dossier vendor comme vous pouvez le voir dans le dépôt Github.

Commençons ensuite par modifier notre mise en page globale :

<!-- templates/base.html.twig -->

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
        <title>{% block title %}Jobeet{% endblock %}</title>
        <link rel="stylesheet" href="/vendor/bootstrap/css/bootstrap.min.css">
        <link rel="stylesheet" href="/vendor/1-col-portfolio.css">
        {% block stylesheets %}{% endblock %}
    </head>
    <body>
        <nav class="navbar navbar-expand-lg navbar-dark bg-dark fixed-top">
            <div class="container">
                <a class="navbar-brand" href="#">Jobeet</a>
                <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarResponsive" aria-controls="navbarResponsive" aria-expanded="false" aria-label="Toggle navigation">
                    <span class="navbar-toggler-icon"></span>
                </button>
            </div>
        </nav>

        <div class="container">
            {% block body %}{% endblock %}
        </div>

        <script src="/vendor/jquery/jquery-3.2.1.slim.min.js"></script>
        <script src="/vendor/popper/popper.min.js"></script>
        <script src="/vendor/bootstrap/js/bootstrap.min.js"></script>
        {% block javascripts %}{% endblock %}
    </body>
</html>

Nous conservons les blocs Twig stylesheets et javascripts même si nous ne les utiliserons pas pour le moment. C’est dernier seront utiles à l’avenir pour inclure des fichiers CSS ou Javascript spécifiques à certaines vues.

Pour finir, mettons en forme la présentation de nos offres d’emploi :

<!-- templates/job/index.html.twig -->
{% extends "base.html.twig" %}

{% block body %}
    <h1 class="my-4">Liste des offres</h1>

    {% for job in jobs %}
        <div class="row">
            <div class="col-md-7">
                <a href="#">
                    <img class="img-fluid rounded mb-3 mb-md-0" src="/images/{{ job.logo }}" alt="{{ job.company }}">
                </a>
            </div>
            <div class="col-md-5">
                <h3>{{ job.position }}</h3>
                <p>{{ job.description }}</p>
                <p>Posted on {{ job.createdAt|date("m/d/Y") }}</p>
                <a class="btn btn-primary" href="#">See more</a>
            </div>
        </div>

        <hr>
    {% endfor %}

    <ul class="pagination justify-content-center">
        <li class="page-item disabled">
            <a class="page-link" href="#" aria-label="Previous">
                <span aria-hidden="true">&laquo;</span>
                <span class="sr-only">Previous</span>
            </a>
        </li>
        <li class="page-item">
            <a class="page-link" href="#">1</a>
        </li>
        <li class="page-item disabled">
            <a class="page-link" href="#" aria-label="Next">
                <span aria-hidden="true">&raquo;</span>
                <span class="sr-only">Next</span>
            </a>
        </li>
    </ul>
{% endblock %}

Les images liées à notre jeu de données sont disponibles directement dans les sources de ce billet.

Et voilà le rendu final de notre application Jobeet :

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Ma semaine 38 de veille (18/09/2017 -> 24/09/2017)

Sun, 24 Sep 2017 00:00:00 +0200

Mon actu préférée

Relicensing React, Jest, Flow, and Immutable.js : https://t.co/uXpiZOHW3c
— Jérémy DECOOL (@jdecool) 23 septembre 2017

Ces dernières semaines, il y a eu beaucoup de polémiques concernant la licence des outils open source fournie par Facebook notamment à cause de la présence de clauses de types PATENTS (brevets). Après avoir annoncé malgré cela qu'il ne changerait pas la licence, la société vient de décider de faire machine arrière.

Le top de la semaine

Stack Overflow lance un calculateur de salaire pour les développeurs : https://t.co/7nBwZrRTL3
— Jérémy DECOOL (@jdecool) 22 septembre 2017

Stack Overflow l'un des sites les plus consultés par les développeurs, propose dorénavant un calculateur de salaire. Les chiffres sont basés sur l'enquête annuelle diffusée auprès des utilisateurs. Les résultats sont classés selon cinq critères : le lieu de travail, la formation, les années d'expérience, le type de développement et les technnologies utilisées.

What Motivates Me as a Programmer : https://t.co/VQk2dGybvQ
— Jérémy DECOOL (@jdecool) 20 septembre 2017

Un article de Yegor Bugayenko, un développeur russe qui décrit dans cet article, les différents éléments qui le motive dans son travail. Je pense que parmi les nombreux points évoqués, un bon nombre de développeurs y trouveront une similitude avec eux-mêmes.

🚨 iTerm2 leaks everything you hover in your terminal via DNS requests 🚨 https://t.co/Ad7jzDCLJM
— Jérémy DECOOL (@jdecool) 21 septembre 2017

Si vous développez sur Mac, il y a de très fortes chances pour que vous utilisiez iTerm, une alternative au terminal MacOS fourni par défaut. Une faille de sécurité a été découverte dans ce dernier. Vous trouverez les explications la concernant dans ce billet.

Edit : Le lien du tweet ne semble plus fonctionnel. Voici un lien valide de l'article.

Promise-Based Cache With ReactPHP : @zhukserega https://t.co/6Y8kOrZVHJ
— Jérémy DECOOL (@jdecool) 21 septembre 2017

Comment mettre en place une stratégie de cache en PHP basée sur des promesses avec ReactPHP ? Si vous souhaitez voir à quoi cela ressemble et si vous vous posez la question, c'est par ici.

Handling 1 Million Requests per Minute with Golang : https://t.co/FhExHDjapH
— Jérémy DECOOL (@jdecool) 19 septembre 2017

Go est un langage souvent utilisé dans le cas de site à haut traffic du fait de ses performances. Dans ce billet Marcio Castilho, CEO d'une solution antispam de SMS pour téléphone, explique comment en utilisant Go, ce dernier a réussi à supporter une charge de 1 million de requête par seconde. Un article très intéressant si vous êtes fan de webperf.

Tutorial Jobeet pour Symfony 4 - Partie 3B: Les données initiales

Thu, 21 Sep 2017 00:00:00 +0200

Nous avons donc créé notre base et données avec les tables qui permettront de stocker les informations que notre application va manipuler. Avant de commencer l’implémentation des fonctionnalités évoquées dans les billets précédents, nous allons commencer par insérer un jeu de données initiales (également appelées fixtures) afin de ne pas démarrer avec un projet vide.

Pour créer nos données, nous allons utiliser un bundle fourni par les équipes de Doctrine et qui propose un moyen de charger des données en base. Nous avions jusqu’à maintenant utilisé uniquement des modules officiels de Symfony. Le bundle que nous allons utiliser (DoctrineFixturesBundle) est un module non officiel de Symfony. Or, par défaut, Symfony Flex ne permet de ne travailler qu’avec les bundles officiels de Symfony.

Il est néanmoins possible d’utiliser Flex avec ces bundles, mais il sera nécessaire de le spécifier explicitement dans la configuration. Pour cela, nous allons modifier la valeur du paramètre allow-contrib présent dans notre fichier composer.json au travers de la commande suivante :

$ composer config extra.symfony.allow-contrib true

Une fois effectué, il sera possible de télécharger la dépendance. Cette dernière n’étant utilisée qu’en développement, nous allons utiliser l’option --dev de Composer afin de l’installer comme tel :

$ composer require doctrine/doctrine-fixtures-bundle --dev

Using version ^2.4 for doctrine/doctrine-fixtures-bundle
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Installing doctrine/data-fixtures (v1.2.2): Loading from cache
  - Installing doctrine/doctrine-fixtures-bundle (v2.4.0): Loading from cache
Writing lock file
Generating autoload files
Symfony operations: 1 recipe
  - Configuring doctrine/doctrine-fixtures-bundle (2.4): From github.com/symfony/recipes-contrib:master
Executing script make cache-warmup [OK]
Executing script assets:install --symlink --relative public [OK]

L’installation de cette dépendance va créer un dossier src/DataFixtures/ORM qui contiendra nos déclarations de fixtures. Mais avant d’écrire ces dernières, vous avez peut-être remarqué, que lorsque nous avons écrit nos entités, nous avons déclaré les propriétés de nos objets comment étant private. Nous allons donc devoir commencer par écrire les méthodes get qui permettront d’accéder à nos propriétés ainsi que les méthodes set qui permettront de modifier la valeur de nos propriétés.

L’activation du paramètre allow-contrib notamment permis la création du répertoire qui accueillera nos fixtures. Même si nous n’avions pas changé cette configuration, il aurait été possible d’installer le bundle, mais nous n’aurions pas profité des mécanismes de Flex qui permettent de créer une configuration du bundle par défaut.

Si vous avez eu la curiosité de regarder la liste des commandes proposées par le bundle Doctrine, vous aurez peut-être remarqué qu’il existe une commande doctrine:generate:entities dont le rôle est justement de remplir cette tâche.

Notre projet suit la convention PSR-4 décrivant la norme sur le chargement des fichiers PHP en fonction de leur arborescence (appelée autoloading). Malheureusement, le générateur de Doctrine n’est actuellement pas compatible avec cette norme (et ce n’est pas prévu à court ou moyen terme).

Mais cela n’est pas un problème étant donné que la plupart des outils de développement (tel que PHPStorm, Netbeans, Eclipse, Sublime Text, Atom, VSCode, …) ont une fonctionnalité (ou des plugins) permettant de générer du code automatiquement et notamment nos getters et setters.

Nous allons donc générer des méthodes get pour l’ensemble des propriétés de nos entités ainsi que les méthodes set associées, à l’exception des propriétés $id (car une clé primaire ne doit pouvoir être modifié), createdAt et updateAt (car nous avons déjà ajouté les méthodes permettant de modifier ces données).

Si vous souhaitez gagner du temps, vous pouvez accéder au code source correspondant à ce billet sur Github pour copier/coller les méthodes décrites ci-dessus.

Nous pouvons maintenant commencer à écrire nos fixtures, c’est-à-dire les classes qui vont s’occuper de la création notre jeu de données initiales. Nous allons commencer par créer des catégories d’offre d’emploi en créant une classe LoadCategoryData dans le dossier src/DataFixtures/ORM :

<?php //src/DataFixtures/ORM/LoadCategoryData.php

namespace App\DataFixtures\ORM;

use App\Entity\Category;
use Doctrine\Common\DataFixtures\AbstractFixture;
use Doctrine\Common\DataFixtures\OrderedFixtureInterface;
use Doctrine\Common\Persistence\ObjectManager;

class LoadCategoryData extends AbstractFixture implements OrderedFixtureInterface
{
    public function load(ObjectManager $manager)
    {
        $design = new Category();
        $design->setName('Design');
        $manager->persist($design);

        $programming = new Category();
        $programming->setName('Programming');
        $manager->persist($programming);

        $managing = new Category();
        $managing->setName('Manager');
        $manager->persist($managing);

        $administrator = new Category();
        $administrator->setName('Administrator');
        $manager->persist($administrator);

        $manager->flush();

        $this->addReference('category-design', $design);
        $this->addReference('category-programming', $programming);
        $this->addReference('category-managing', $managing);
        $this->addReference('category-administrator', $administrator);
    }

    public function getOrder()
    {
        return 1;
    }
}

Pour charger des données, notre classe doit étendre de AbstractFixture qui contient des fonctions de base de gestion de fixtures. Nous implémentons ensuite une interface OrderedFixtureInterface permettant de spécifier un ordre d’ insertion des nos fixtures (dans le cas présent, nous ne pouvons enregistrer une offre d’emploi si nous n’avons pas auparavant créé des catégories) au travers de la méthode getOrder().

Mise à jour du 04/03/2018 : Ce chapitre a été initialement rédigé sur la version 3.4 de Symfony. Depuis, la version installée de Doctrine a évolué. La classe Doctrine\Common\DataFixtures\AbstractFixture est maintenant remplacée par Doctrine\Bundle\FixturesBundle\Fixture et l’interface Doctrine\Common\DataFixtures\OrderedFixtureInterface par Doctrine\Common\DataFixtures\DependentFixtureInterface. Le fonctionnement pour charger des fixtures dépendantes les unes des autres a évolué, et il n’est plus nécessaire de définir l’ordre de chargement de ces dernières. L’interface DependentFixtureInterface définit une méthode retournant un tableau contenant les classes dont dépend le jeu de données courant. Vous n’avez donc plus à déterminer l’ordre de chargement des fixtures, Doctrine s’en charge dorénavant pour vous.

Le chargement des données se fait au sein d’une méthode load(ObjectManager $manager). Il s’agit de la méthode appelée lorsque les données doivent être insérées. Cette méthode prend en paramètre un objet de type ObjectManager qui est l’objet Doctrine qui permet de travailler avec la base de données.

Ce dernier permet d’appeler la méthode persist pour indiquer à Doctrine que nous souhaitons persister un objet en base. Pour que la donnée soit réellement écrite en base, on utilise un appel à la méthode flush. Dans le cas où l’on fait plusieurs appels à la méthode persist (comme c’est le cas ici) et qu’ensuite on flush, les insertions en bases sont réalisés au sein d’une transaction.

Une fois les données enregistrées, nous souhaitons les rendre accessibles depuis nos autres fixtures pour par exemple pouvoir affecter une catégorie à une offre d’emploi. Pour cela, nous allons définir explicitement les objets auxquels nous souhaitons accéder en appelant la méthode addReference et en associant une clé à notre donnée.

Nous pouvons ensuite passer à la fixture suivante :

<?php  //src/DataFixtures/ORM/LoadJobData.php

namespace App\DataFixtures\ORM;

use App\Entity\Job;
use Doctrine\Common\DataFixtures\AbstractFixture;
use Doctrine\Common\DataFixtures\OrderedFixtureInterface;
use Doctrine\Common\Persistence\ObjectManager;

class LoadJobData extends AbstractFixture implements OrderedFixtureInterface
{
    public function load(ObjectManager $manager)
    {
        $categoryProgramming = $this->getReference('category-programming');
        $categoryDesign = $this->getReference('category-design');

        $jobSensioLabs = new Job();
        $jobSensioLabs->setCategory($categoryProgramming);
        $jobSensioLabs->setType('full-time');
        $jobSensioLabs->setCompany('Sensio Labs');
        $jobSensioLabs->setLogo('sensio-labs.gif');
        $jobSensioLabs->setUrl('http://www.sensiolabs.com/');
        $jobSensioLabs->setPosition('Web Developer');
        $jobSensioLabs->setLocation('Paris, France');
        $jobSensioLabs->setDescription("You've already developed websites with symfony and you want to work with Open-Source technologies. You have a minimum of 3 years experience in web development with PHP or Java and you wish to participate to development of Web 2.0 sites using the best frameworks available.");
        $jobSensioLabs->setHowToApply('Send your resume to fabien.potencier [at] sensio.com');
        $jobSensioLabs->setIsPublic(true);
        $jobSensioLabs->setIsActivated(true);
        $jobSensioLabs->setToken('job_sensio_labs');
        $jobSensioLabs->setEmail('job@example.com');
        $jobSensioLabs->setExpiresAt(new \DateTime('2012-10-10'));
        $manager->persist($jobSensioLabs);

        $jobExtremeSensio = new Job();
        $jobExtremeSensio->setCategory($categoryDesign);
        $jobExtremeSensio->setType('part-time');
        $jobExtremeSensio->setCompany('Extreme Sensio');
        $jobExtremeSensio->setLogo('extreme-sensio.gif');
        $jobExtremeSensio->setUrl('http://www.extreme-sensio.com/');
        $jobExtremeSensio->setPosition('Web Designer');
        $jobExtremeSensio->setLocation('Paris, France');
        $jobExtremeSensio->setDescription('Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in.');
        $jobExtremeSensio->setHowToApply('Send your resume to fabien.potencier [at] sensio.com');
        $jobExtremeSensio->setIsPublic(true);
        $jobExtremeSensio->setIsActivated(true);
        $jobExtremeSensio->setToken('job_extreme_sensio');
        $jobExtremeSensio->setEmail('job@example.com');
        $jobExtremeSensio->setExpiresAt(new \DateTime('2012-10-10'));
        $manager->persist($jobExtremeSensio);

        $manager->flush();
    }

    public function getOrder()
    {
        return 2;
    }
}

Notez dans le code ci-dessus l’utilisation de la méthode getReference nous permettant de récupérer une donnée qui a été créée dans la fixture précédente.

Il ne reste maintenant plus qu’à charger nos données au travers de la commande :

$ bin/console doctrine:fixtures:load
Careful, database will be purged. Do you want to continue y/N ?y
  > purging database
  > loading [1] App\DataFixtures\ORM\LoadCategoryData
  > loading [2] App\DataFixtures\ORM\LoadJobData

Et voilà !

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Tutorial Jobeet pour Symfony 4 - Partie 3A: Le modèle de données

Wed, 20 Sep 2017 00:00:00 +0200

Maintenant que l’aspect fonctionnel de notre projet a été défini, nous allons pouvoir créer le modèle de données associé à notre application, c’est-à-dire les classes qui permettront d’interagir avec la base de données. Nous allons pour cela avoir recours à un ORM. Ce sera également l’occasion de voir comment ajouter et configurer un module tier dans notre projet.

D’après les scénarios que nous avons précédemment écrits, voici le schéma correspondant aux relations entre entités que l’on peut en déduire :

En plus des informations, nous avons également ajouté un champ created_at et updated_at à certaines tables afin de conserver une trace des dernières modifications des données que nous allons traiter.

Pour stocker les informations de l’application, nous allons utiliser une base de données relationnelle. Symfony étant un framework orienté-objet, nous allons donc manipuler les informations sous la forme d’objet. Les informations de notre base de données doivent ainsi être mappées avec notre modèle objet et pour cela nous allons utiliser un ORM.

Symfony 4 laisse le choix au développeur sur les outils qu’il souhaite utiliser. Contrairement aux versions précédentes, Symfony est livré “vide” et n’impose aucun choix par défaut. Pour ce tutorial, nous allons faire le choix d’utiliser l’ORM Doctrine qui est l’ORM le plus répandu dans l’écosystème PHP. Mais il serait tout à fait possible d’utiliser une simple connexion PDO ou Doctrine DBAL, ou un autre ORM tel que Propel, Eloquent, Pomm ou n’importe quel autre outil.

Avant de créer et configurer les classes de notre modèle de données, nous allons commencer par télécharger Doctrine. Pour intégrer ce dernier dans notre projet Symfony, nous devrons récupérer deux dépendances. La première, doctrine/orm est l’ORM en tant que tel. La seconde dépendance consiste à intégrer l’ORM dans notre architecture Symfony. Symfony facilite le développement et la réutilisation de module que l’on peut partager entre plusieurs projets. Ces modules (des plugins en quelque sorte) sont appelés bundles dans l’écosystème du framework. Il convient donc de télécharger la dépendance doctrine/doctrine-bundle qui va intégrer l’ORM dans notre environnement Symfony.

Afin d’éviter au développeur d’avoir à installer deux dépendances distinctes, les équipes de développement fournissent un méta-paquet Composer permettant d’installer les deux éléments d’un coup. Pour intégrer Doctrine à notre projet, il nous suffit donc de récupérer la dépendance symfony/orm-pack.

$ composer require symfony/orm-pack

Using version ^1.0 for symfony/orm-pack
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 20 installs, 0 updates, 0 removals
  - Installing ocramius/package-versions (1.1.3): Loading from cache
  - Installing zendframework/zend-eventmanager (3.2.0): Loading from cache
  - Installing zendframework/zend-code (3.3.0): Loading from cache
  - Installing ocramius/proxy-manager (2.1.1): Loading from cache
  - Installing doctrine/lexer (v1.0.1): Loading from cache
  - Installing doctrine/inflector (v1.2.0): Loading from cache
  - Installing doctrine/collections (v1.5.0): Loading from cache
  - Installing doctrine/cache (v1.7.1): Loading from cache
  - Installing doctrine/annotations (v1.5.0): Loading from cache
  - Installing doctrine/common (v2.8.1): Loading from cache
  - Installing doctrine/dbal (v2.6.3): Loading from cache
  - Installing doctrine/migrations (v1.6.1): Loading from cache
  - Installing symfony/doctrine-bridge (v4.0.0-RC1): Loading from cache
  - Installing doctrine/doctrine-cache-bundle (1.3.2): Loading from cache
  - Installing jdorn/sql-formatter (v1.2.17): Loading from cache
  - Installing doctrine/doctrine-bundle (1.8.0): Loading from cache
  - Installing doctrine/doctrine-migrations-bundle (v1.3.1): Loading from cache
  - Installing doctrine/instantiator (1.1.0): Loading from cache
  - Installing doctrine/orm (v2.5.12): Loading from cache
Writing lock file
Generating autoload files
Symfony operations: 4 recipes (9eb5d7e36646d167c1d8407c068032b9)
  - Configuring doctrine/annotations (1.0): From github.com/symfony/recipes:master
  - Configuring doctrine/doctrine-cache-bundle (1.3.2): From auto-generated recipe
  - Configuring doctrine/doctrine-bundle (1.6): From github.com/symfony/recipes:master
  - Configuring doctrine/doctrine-migrations-bundle (1.2): From github.com/symfony/recipes:master
ocramius/package-versions:  Generating version class...
ocramius/package-versions: ...done generating version class
Executing script cache:clear [OK]
Executing script assets:install --symlink --relative public [OK]


 Next: Configuration


  * Modify your DATABASE_URL config in .env

  * Configure the driver (mysql) and
    server_version</fg> (5.7) in config/packages/doctrine.yaml

Pour utiliser un bundle dans un projet, il est nécessaire d’activer ce dernier afin qu’il soit reconnu par le framework. Cette configuration s’effectue dans le fichier config/bundles.php. Ce fichier retourne un tableau associatif où la clé des éléments correspond au namespace complet du bundle à activer et dont la valeur est également un tableau associatif indiquant les environnements pour lesquels le bundle est actif (ou non).

<?php // config/bundles.php

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    Symfony\Bundle\WebServerBundle\WebServerBundle::class => ['dev' => true],
    Doctrine\Bundle\DoctrineCacheBundle\DoctrineCacheBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
    Doctrine\Bundle\MigrationsBundle\DoctrineMigrationsBundle::class => ['all' => true],
];

En réalité, l’activation d’un bundle se fait rarement manuellement. Effectivement, Symfony Flex, que nous avons évoqué brièvement lors de la mise en place du projet se chargera de cette action. Il sera néanmoins parfois nécessaire de corriger la configuration par défaut en activant ou désactivant le bundle pour certains environnements.

Maintenant que Doctrine est installé et activé dans notre projet, nous allons pouvoir commencer à paramétrer notre application pour qu’elle puisse accéder à une base de données. Pour cela nous allons renseigner les paramètres nécessaires à l’établissement de la connexion. Cette dernière étant propre à l’environnement d’exécution de notre code, nous allons définir les paramètres dans le fichier .env. Ce dernier a d’ailleurs été prérempli avec une configuration de base par Flex :

# .env
# ...

###> doctrine/doctrine-bundle ###
# Format described at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url
# For an SQLite database, use: "sqlite:///%kernel.project_dir%/var/data.db"
# Configure your db driver and server_version in config/packages/doctrine.yaml
DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/db_name
###< doctrine/doctrine-bundle ###

Vous avez certainement noté la présence des fichiers .env et .env.dist. Le fichier .env est le fichier qui contient réellement la configuration de notre application. Contenant des informations pouvant être très sensibles (comme par exemple des mots de passe), il n’est pas versionné.

C’est pour cela qu’un fichier .env.dist est présent. Ce dernier qui lui est versionné sert de modèle pour que les développeurs qui vont être ammenés à travailler sur le projet puisse connaître les informations à renseigner.

L’exemple de configuration qui a été inséré par Symfony Flex permet de se connecter à une base de données MySQL. Pour les besoins de ce tutorial, ainsi que pour éviter l’installation d’un serveur, nous allons utiliser SQLite qui est un système de base de données ne nécessitant pas une architecture client-serveur. Il sera nécessaire de vérifier que le driver SQLite de PHP (php-sqlite3) soit installé et activé. Nous allons ensuite modifier la variable d’environnement DATABASE_URL comme suit :

DATABASE_URL=sqlite:///%kernel.project_dir%/var/jobeet.db

Dans cette configuration, nous faisons référence à un paramètre kernel.project_dir définit par le framework (facilement reconnaissable car il est entouré du caractère %). Ce dernier fait référence à la racine du dossier du projet et permet ainsi de définir facilement l’endroit où l’on souhaite enregistrer nos données.

Mise à jour du 23/09/2017 : En parcourant le projet sur Github, j’ai trouvé l’issue concernant ce problème ainsi que sa résolution. Tout devrait rentrer dans l’ordre lors de la publication de la branche 3.4 du projet.

Le dossier var qui a été créé lors de la mise en place de Doctrine est, par convention, un dossier qui va contenir les fichiers écrits par notre application durant son fonctionnement (tel que des logs, des fichiers de cache, …). C’est donc tout naturellement dans ce dernier que nous allons stocker le fichier qui contiendra nos données SQLite.

Nous allons maintenant pouvoir démarrer l’écriture des classes qui vont modéliser nos données. Par défaut Doctrine est configuré pour travailler avec des annotations. Personnellement, je préfère séparer le code de sa configuration, c’est pour cela quand dans ce tutorial, nous utiliserons une configuration en YAML (il est également possible d’avoir une configuration en XML). Pour cela, nous allons éditer le fichier de configuration config/packages/doctrine.yaml pour y mettre le contenu ci-dessous :

# config/packages/doctrine.yaml
parameters:
    env(DATABASE_URL): 'sqlite:///%kernel.project_dir%/var/jobeet.db'

doctrine:
    dbal:
        driver: 'pdo_sqlite'
        url: '%env(resolve:DATABASE_URL)%'
    orm:
        auto_generate_proxy_classes: '%kernel.debug%'
        naming_strategy: doctrine.orm.naming_strategy.underscore
        auto_mapping: true
        mappings:
            App:
                is_bundle: false
                type: yml # annotation ou xml
                dir: '%kernel.project_dir%/config/doctrine/mapping' # configuration du mapping
                prefix: 'App\Entity'
                alias: App

On retrouve dans cette configuration la variable %kernel.project_dir% faisant référence au dossier racine de notre projet. Lorsqu’un paramètre de configuration est définit dans le framework. De la même façon, il est possible d’accéder à une variable d’environnement via la syntaxe %env(MA_VARIABLE)% (comme dans le fichier Doctrine pour accéder à la chaine de connexion à la base de données).

Notons également la présence du paramètre env(DATABASE_URL) permettant de définir le paramètre contenant la chaîne de connexion à notre base de données dans le cas où la variable d’environnement n’existerait pas.

Si vous analysez l’arborescence des fichiers, vous constaterez qu’il existe deux fichiers de configuration Doctrine : config/packages/doctrine.yaml et config/packages/prod/doctrine.yaml.

Le premier est un fichier de configuration commun à tous les environnements. Il est ensuite possible de définir une configuration spécifique pour un environnement (défini par la variable APP_ENV du fichier .env). Pour cela, il suffit de déposer le fichier de configuration dans un sous-dossier portant le nom de l’environnement pour lequel on souhaite surcharger la configuration et le framework le prendra automatiquement en compte.

Nous n’irons pas plus loin dans la configuration de Doctrine. Si vous après ce tutorial, vous souhaitez en savoir plus, je vous conseille de consulter la documentation officielle.

Créons maintenant les classes associées à notre modèle de données. Elles vont représenter les informations de la base de données sous la forme d’objets PHP (ces derniers sont appelés des entités) que l’on va pouvoir manipuler dans notre code. Lors de l’installation de Doctrine, Flex a ajouté un dossier src/Entity dans lequel nous allons créer nos classes.

Les entités sont de simples objets PHP dont les propriétés vont correspondre aux champs de notre base de données. Commençons par la table la plus simple, la table category :

<?php // src/Entity/Category.php

namespace App\Entity;

class Category
{
    private $id;
    private $name;
}

Maintenant passons à la table job. Un emploi étant lié à une catégorie, notre table contient une clé étrangère vers la catégorie associée. Dans notre entité, cette information va se modéliser sous la forme d’une propriété dont la valeur sera une instance de l’entité associée à la table catégorie (donc un objet Category).

<?php // src/Entity/Job.php

namespace App\Entity;

class Job
{
    private $id;
    private $category; // instance de Category
    private $type;
    private $company;
    private $logo;
    private $url;
    private $position;
    private $location;
    private $description;
    private $howToApply;
    private $token;
    private $isPublic;
    private $isActivated;
    private $email;
    private $expiresAt;
    private $createdAt;
    private $updatedAt;
}

La table qui va gérer les informations d’affiliation est un peu plus complexe. Dans notre modèle, une société peut-être être affiliée à plusieurs catégories et une catégorie peut avoir des affiliations de plusieurs sociétés. Avec une base de données relationnelle, cela se traduit par la création d’une table d’association pour gérer cette information (il s’agit de la table CategoryAffiliate).

Puisque nous avons dit qu’une table de notre base de données correspondait à un objet PHP, il devrait donc être nécessaire de créer deux nouveaux objets pour gérer cette relation. Mais en réalité cette table ne sert qu’à modéliser le fait qu’un objet Affialite est rattaché à plusieurs objets Category et vice-versa. Donc d’un point de vue programmation, un objet Affiliate devrait avoir une propriété $categories qui correspond à un tableau d’objet Affiliate et l’entité Category une propriété $affiliates correspondant un tableau d’objet Affiliate. Notre ORM est tout à fait capable de gérer cette problématique. Nous allons donc créer notre objet Affiliate avec une propriété $categories que nous ferons correspondre à un tableau d’objet Category. Doctrine gérera de manière automatique et transparente notre table d’association.

S’il avait été nécessaire de gérer des informations additionnelles, telles que par exemple la date de création de l’affiliation ou l’utilisateur ayant créé l’affiliation, il aurait été nécessaire de créer une entité supplémentaire et de gérer la relation manuellement.

<?php // src/Entity/Affiliate.php

namespace App\Entity;

use Doctrine\Common\Collections\ArrayCollection;

class Affiliate
{
    private $id;
    private $categories; // tableau d'objet Category
    private $url;
    private $email;
    private $token;
    private $isActive;
    private $createdAt;

    public function __construct()
    {
        $this->categories = new ArrayCollection();
    }
}

Lors de la mise en place d’une relation où l’on va gérer un tableau d’objet, il est nécessaire d’initialiser la propriété en question avec une collection vide. Pour Doctrine, cela passe par la création d’un objet ArrayCollection comme dans l’exemple précédent.

N’oublions pas de modifier notre objet Category pour y ajouter la propriété correspondant à nos objets Affialite. Une catégorie étant également associée à plusieurs emplois, nous allons en profiter pour y ajouter la propriété correspondante.

<?php // src/Entity/Category.php

namespace App\Entity;

use Doctrine\Common\Collections\ArrayCollection;

class Category
{
    private $id;
    private $name;
    private $jobs; // tableau d'objet Job
    private $affiliates; // tableau d'objet Affiliate

    public function __construct()
    {
        $this->jobs = new ArrayCollection();
        $this->affiliates = new ArrayCollection();
    }
}

Il est maintenant temps d’indiquer à Doctrine comment l’ORM va pouvoir faire le lien entre nos entités et les tables de la base de données. Pour cela, et comme nous l’avons spécifié précédemment, nous allons placer des fichiers de configuration dans le dossier config/doctrine/mapping. Tout comme pour l’écriture des classes, nous allons créer un fichier de configuration par entité en suivant la convention NomDeLaClasse.orm.yml.

Les fichiers de configuration vont permettre d’indiquer à quelle table correspondent une entité et les différentes caractéristiques de nos propriétés (colonne de rattachement, type de données, contraintes d’intégrité, ….).

Commençons par la configuration de notre entité Category :

# config/doctrine/mapping/Category.orm.yml
App\Entity\Category:
    type: entity

    # clé(s) primaire(s)
    id:
        id:
            type: integer
            generator:
                strategy: AUTO

    # colonne(s) de la table
    fields:
        name:
            type: string
            length: 63

    # relation de type un vers plusieurs
    oneToMany:
        jobs:
            targetEntity: Job
            mappedBy: category

    # relation de type plusieurs vers plusieurs
    manyToMany:
        affiliates:
            targetEntity: Affiliate
            inversedBy: categories

Comme vous pouvez le constater, les propriétés de correspondant à des relations sont dissociés du reste des propriétés. On distingue quatre types de relation, One-To-Many (relation de type un vers plusieurs), Many-To-One (plusieurs vers un), Many-To-Many (relation de plusieurs à plusieurs) et One-To-One.

Voici la configuration de l’entité Job :

# config/doctrine/mapping/Job.orm.yml
App\Entity\Job:
    type: entity

    id:
        id:
            type: integer
            generator:
                strategy: AUTO

    fields:
        type:
            type: string
            length: 255
            nullable: true

        company:
            type: string
            length: 255

        logo:
            type: string
            length: 255
            nullable: true

        url:
            type: string
            length: 255
            nullable: true

        position:
            type: string
            length: 255

        location:
            type: string
            length: 255

        description:
            type: text

        howToApply:
            type: text

        token:
            type: string
            length: 255
            unique: true

        isPublic:
            type: boolean
            default: false

        isActivated:
            type: boolean
            default: true

        email:
            type: string
            length: 255

        expiresAt:
            type: datetime

        createdAt:
            type: datetime

        updatedAt:
            type: datetime
            nullable: true

    manyToOne:
        category:
            targetEntity: Category
            inversedBy: jobs
            joinColumn:
                name: category_id
                referencedColumnName: id

Et pour finir le mapping correspondant à l’entité Affiliate :

# config/doctrine/mapping/Affiliate.orm.yml
App\Entity\Affiliate:
    type: entity

    id:
        id:
            type: integer
            generator:
                strategy: AUTO

    fields:
        url:
            type: string
            length: 255

        email:
            type: string
            length: 255
            unique: true

        token:
            type: string
            length: 255
            unique: true

        createdAt:
            type: datetime

    manyToMany:
        categories:
            targetEntity: Category
            mappedBy: affiliates

Lorsque nous allons enregistrer un emploi ou une affiliation, nous souhaiterions connaître la date de création et/ou de modification de la donnée écrite. Les entités correspondantes possèdent une propriété createdAt et/ou updatedAt. Plutôt que de devoir gérer manuellement cette information, nous allons déléguer ce travail à Doctrine.

En effet l’ORM possède un gestionnaire d’événement sur lequel nous allons nous brancher afin d’être notifié lors de l’enregistrement et la modification d’une entité. Nous allons donc ajouter cette configuration au mapping de nos entités afin d’indiquer la méthode de l’objet qui sera appelée lors de la propagation de l’événement.

Pour l’entité Job :

# config/doctrine/mapping/Job.orm.yml
App\Entity\Job:
    # ...

    lifecycleCallbacks:
        prePersist: [ setCreatedAtValue ] # appelé lors de la création de l'entité
        preUpdate:  [ setUpdatedAtValue ] # appelé lors de la modification de l'entité

Pour l’entité Affiliate :

# config/doctrine/mapping/Affiliate.orm.yml
App\Entity\Affiliate:
    # ...

    lifecycleCallbacks:
        prePersist: [ setCreatedAtValue ]

Il ne faudra pas oublier d’ajouter les méthodes correspondantes dans les classes associées. Ces dernières sont appelées avec un paramètre de type LifecycleEventArgs contenant un certain nombre d’informations sur le contexte d’exécution de l’ORM.

// src/Entity/Job.php
// ...

use Doctrine\Common\Persistence\Event\LifecycleEventArgs;

class Job
{
    // ...

    public function setCreatedAtValue(LifecycleEventArgs $event)
    {
        $this->createdAt = new DateTime();
    }

    public function setUpdatedAtValue(LifecycleEventArgs $event)
    {
        $this->updatedAt = new DateTime();
    }
}

Pour l’entité Affiliate, nous souhaitons connaître uniquement la date de création de la donnée.

// src/Entity/Affiliate.php
// ...

use Doctrine\Common\Persistence\Event\LifecycleEventArgs;

class Affiliate
{
    // ...

    public function setCreatedAtValue(LifecycleEventArgs $event)
    {
        $this->createdAt = new DateTime();
    }
}

Signalons l’existence d’un bundle StofDoctrineExtensionBundle contenant un ensemble d’extensions Doctrine pouvant être ajoutées à nos entités et possédant entre autres, une extension Timestampable. Cette dernière permet de gérer de manière automatique les dates de création et de modification d’une entité sans avoir à ajouter manuellement les propriétés correspondantes.

Maintenant que nous avons indiqué à notre projet comment se connecter à notre base de données, créé nos entités et indiqué la configuration nécessaire à la liaison entre nos objets et le contenu de notre base, nous allons pouvoir initialiser cette dernière. Doctrine va encore nous faciliter le travail dans cette tâche car l’ORM est distribué avec des commandes qui vont nous assister dans ce travail.

Dans un terminal, nous allons exécuter les commandes suivantes :

$ bin/console doctrine:database:create # pour créer la base de données
Created database var/jobeet.db for connection named default


$ bin/console doctrine:schema:create # pour créer la structure des tables
ATTENTION: This operation should not be executed in a production environment.

Creating database schema...
Database schema created successfully!

Vous pouvez constater que la base de données a été correctement initialisée en ouvrant le fichier contenant les données SQLite qui a été créé (var/jobeet.db) avec un outil tel que DB Browser for SQLite.

Voilà qui conclut notre section d’introduction au modèle de données. Nous avons maintenant une base de données (presque) prête à être utilisée et qui n’attend plus que nos données.

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Tutorial Jobeet pour Symfony 4 - Partie 2: Le projet

Tue, 19 Sep 2017 00:00:00 +0200

Nous avons précédemment créé la structure de notre projet Symfony et préparé notre environnement de développement. Nous allons très prochainement pouvoir commencer à écrire nos premières lignes de code. Mais avant cela, attardons-nous un peu sur les exigences de notre projet.

Ce billet est principalement d’une recopie des exigences fonctionnelles du tutorial initial. Je vous recommande vivement de lire ce dernier car des explications sur les nouvelles pratiques liées à Symfony 4 y sont décrites.

Jobeet est un logiciel open-source de recherche d’emploi qui ne fait qu’une seule chose, mais le fait bien. Il est facile d’utilisation, à adapter, à faire évoluer, et à intégrer à votre site internet. Il est multi langues dès le départ, et bien sûr il utilise les dernières technologies du web 2.0 pour améliorer l’expérience utilisateur. Il fournit également des feeds et une API pour interagir avec lui en programmant.

Le site web Jobeet a quatre types d’utilisateurs :

L’administrateur : il est propriétaire du site et il a le pouvoir magique
L’utilisateur : il visite le site pour chercher un emploi
L’annonceur : il soumet une offre d’emploi
L’affilié : il re-édite certains emplois sur son site

Nous allons maintenant découper le projet en scénarios d’utilisation. L’application est séparée en deux interfaces : le frontend (où les utilisateurs interagissent avec le site), et le backend (où les administrateurs gèrent le site).

Symfony recommande maintenant et générera dorénavant des applications orientées bundle-less. Si vous débutez avec Symfony, un bundle peut être considéré comme un “plugin”. Ils permettent de regrouper du code qui est regroupé par fonctionnalité et redistribuable dans n’importe quel projet Symfony.

Nous allons maintenant lister les exigences fonctionnelles de notre application. Ces dernières seront numérotés et débuteront par un F pour les aspects frontend et par un B pour les aspects backend.

F1: En tant qu’utilisateur, je vois les dernières offres actives sur la page d’accueil

Quand un utilisateur vient sur le site Jobeet, il voit une liste des emplois actifs. Les emplois sont classés par catégorie, puis par date de publication (emplois plus récents en premier). Pour chaque emploi, seul le lieu, la position, et la société sont affichés.

Pour chaque catégorie, la liste ne montre que les 10 premiers emplois et un lien permet de lister tous les emplois pour une catégorie donnée (scénario F2).

Sur la page d’accueil , l’utilisateur peut affiner la liste des travaux (scénario F3), ou par la soumission d’un nouvel emploi (scénario F5).

F2: En tant qu’utilisateur, je peux lister les emplois d’une catégorie

Quand un utilisateur clique sur un nom de catégorie ou sur le lien “more jobs” sur la page d’accueil, il voit tous les emplois pour cette catégorie triée par date.

La liste est paginée avec 20 emplois par page.

F3: En tant qu’utilisateur, je peux affiner les offres d’une catégorie

L’utilisateur peut saisir quelques mots-clés pour affiner sa recherche. Les mots-clés peuvent être des mots trouvés dans l’emplacement, la position, la catégorie, ou les champs de l’entreprise.

F4: En tant qu’utilisateur, je peux visualiser le détail d’une offre

L’utilisateur peut sélectionner un emploi dans la liste pour afficher des informations plus détaillées.

F5: En tant qu’utilisateur, je peux soumettre une offre d’emploi

Un utilisateur peut soumettre un emploi (il n’est pas nécessaire de devoir créer un compte). Un emploi est composé de plusieurs informations.

Le processus est simple, avec seulement deux étapes : d’abord, l’utilisateur remplit dans le formulaire toutes les informations nécessaires pour décrire l’emploi, puis il valide les informations en visualisant la page finale de l’emploi.

Même si l’utilisateur n’a pas de compte, un emploi peut être modifié ultérieurement, grâce à une URL spécifique (protégé par un jeton donné à l’utilisateur lorsque l’emploi est créé).

Chaque poste de travail est en ligne pendant 30 jours (ce qui est configurable par l’administrateur - voir Histoire B2). Un utilisateur peut revenir réactiver ou prolonger la validité de l’annonce pour un supplément de 30 jours, mais seulement lorsque le travail expire dans moins de 5 jours.

F6: En tant qu’utilisateur, je peux affilier ma société

Un utilisateur doit demander à devenir un affilié et être autorisés à utiliser l’API Jobeet. Pour postuler, il doit donner des informations.

Le compte d’ un affilié doit être activé par l’administrateur (scénario B3). Une fois activé, l’affilié reçoit un jeton pour une utilisation avec l’API par email.

Lors de l’application, l’affilié peut également choisir d’obtenir des emplois auprès d’un sous-ensemble des catégories disponibles.

F7: En tant qu’utilisateur, je peux exporter la liste des emplois actifs

Un affilié peut récupérer la liste des emplois en cours en appelant l’API avec le jeton de sa filiale. La liste peut être retournée en XML, JSON ou YAML.

La liste contient les informations publiques disponibles pour un emploi.

L’affilié peut également limiter le nombre d’emplois qui seront retournés, et affiner sa requête en spécifiant une catégorie.

B1: En tant qu’administrateur, je peux configurer le site

L’administrateur peut modifier les catégories disponibles sur le site.

B2: En tant qu’administrateur, je peux administrer les offres d’emploi

Un administrateur peut modifier et supprimer tous les emplois affichés.

B3: En tant qu’administrateur, je peux gérer les affiliés

L’administrateur peut créer ou modifier des affiliés. Il est responsable de l’activation d’un affilié et peut également les désactiver.

Lorsque l’administrateur active une nouvelle filiale, le système crée un jeton unique à utiliser par la filiale.

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Ma semaine 37 de veille (11/09/2017 -> 17/09/2017)

Mon, 18 Sep 2017 00:00:00 +0200

Mon actu préférée

[Blog] Tutorial Jobeet pour Symfony 4 - Introduction : https://t.co/CXGbthKSk0
— Jérémy DECOOL (@jdecool) 12 septembre 2017

Lors de la sortie de la première version du framework Symfony, un excellent tutorial était disponible pour apprendre à utiliser ce dernier. Avec la sortie prochaine de la version 4, j'ai souhaité remise à jour ce dernier dans une série de billets.

Le top de la semaine

Plongeon dans les profondeurs de l’internet : entre Darknets et Cybercriminalité - https://t.co/6Cy3exbHMa
— Jérémy DECOOL (@jdecool) 13 septembre 2017

Deepweb, Darknets et Darkweb. On entend de plus en plus souvent ces termes revenir dans l'actualité, parfois sans vraiment savoir réellement de quoi il s'agit. Nous sommes remplis de préjugé concernant ces termes. Ce billet vous permettra d'en savoir un plus sur le sujet ainsi que sur l'écosystème qui gravite autour.

PHP 7.2 is due in November. What's new ? https://t.co/XN580PkJoS
— Jérémy DECOOL (@jdecool) 11 septembre 2017

La prochaine version de PHP (la 7.2) vient de sortir sa deuxième Release Candidate pour une sortie prévue au mois de novembre. L'occasion de faire un récapitulatif des nouveautés de cette nouvelle version.

Comment je suis devenu heureux: retour sur 4 années d’entrepreneuriat https://t.co/UQkwfwwzKP
— Jérémy DECOOL (@jdecool) 12 septembre 2017

Il m'arrive de partager des articles qui ne sont pas techniques, c'est le cas pour ce tweet. Dans un monde où l'on coure majoritairement vers l'agent qui est dans notre société le principal indicateur de réussite. L'auteur nous explique comment, en ayant revu ses priorités, il est arrivé à devenir un homme plus heureux.

Ports & Adapters Architecture : https://t.co/Y4v1kNjgvX
— Jérémy DECOOL (@jdecool) 15 septembre 2017

Si vous êtes développeur, vous avez forcément entendu parler des architectures hexagonales. Ce type d'architecture est constitué d'un ensemble de bonnes pratiques utilisant de nombreux design patterns, parmi lesquels les Ports et les Adapters seront expliqués dans cet article.

How does Docker Compose help in continuous integration ? https://t.co/0E0U0t08XF
— Jérémy DECOOL (@jdecool) 14 septembre 2017

L'intégration continue est sans conteste une des meilleurs pratiques pour assurer la qualité de nos développements. Il existe de nombreux patterns pour monter un environnement de qualité et pérenne. Comment docker-compose peut participer à mettre en oeuvre un environnement d'intégration continue au travers de la conteneurisation ?

Tutorial Jobeet pour Symfony 4 - Partie 1: Démarrage du projet

Wed, 13 Sep 2017 00:00:00 +0200

Est-il encore nécessaire de présenter Symfony qui est l’un des frameworks PHP les plus populaires ? Dans cette première partie, nous allons créer la structure de notre application et voir comment s’organise un projet Symfony.

Démarrons tout d’abord avec les prérequis nécessaires à la mise en place de notre projet. Concernant la version de PHP que vous allez devoir utiliser, un PHP 7.1.3 sera au minimum nécessaire. Dans cette série de billets, nous partirons du principe que vous avez installé les extensions permettant d’accéder à une base de données telle que MySQL ou PostgreSQL (via l’extension PDO et les drivers associés). Le module XML de PHP (alias php-xml) est également requis. Pour finir, nous supposerons également, que Composer, l’outil de gestion des dépendances PHP est installé sur votre machine.

Jusqu’à la version 4 de Symfony, la création d’un nouveau projet se faisait au travers d’un outil d’installation spécifique nommé Symfony installer. Ce dernier outil est maintenant remplacé par Composer qui possède une commande create-project permettant de créer un nouveau projet PHP. Cette commande est ainsi indépendante du framework. Les équipes de Symfony ont souhaité standardiser la manière de démarrer un projet PHP sans devoir y ajouter des outils spécifiques. La création de notre projet Jobeet se fera ainsi au travers de la commande : composer create-project symfony/skeleton jobeet 4.0.0-RC1.

Composer va alors créer un dossier pour notre projet en se basant sur le modèle de projet Symfony et télécharger les dépendances associées. Dans sa nouvelle version, le framework fournit dorénavant un composant nommé Flex, une surcouche à Composer et qui permet entre autres de configurer automatiquement les dépendances que vous installez dans votre application.

Analysons la structure de notre projet vide :

jobeet
├── .env
├── .env.dist
├── composer.json
├── composer.lock
├── config
│   ├── bundles.php
│   ├── packages
│   │   ├── dev
│   │   │   └── routing.yaml
│   │   ├── framework.yaml
│   │   ├── routing.yaml
│   │   └── test
│   │       └── framework.yaml
│   ├── routes.yaml
│   └── services.yaml
├── public
│   └── index.php
├── src
│   ├── Controller
│   └── Kernel.php
└── vendor

Contrairement aux versions précédentes, le framework a changé l’arborescence de ces fichiers afin de se rapprocher d’une arborescence de fichiers que l’on pourrait retrouver sur des systèmes Unix. On retrouve ainsi les éléments ci-dessous :

config

Dossier contenant les fichiers de configuration de notre projet

public

Le répertoire contenant les fichiers désservis par les serveurs HTTP

src

Accueillera les fichiers sources PHP contenant toute la logique de notre projet

vendor

Le dossier utilisé par Composer et contenant les dépendances (décrites dans le fichier composer.json) nécessaires au fonctionnement de notre projet

.env

Fichier contenant la configuration de l'environnement d'exécution de notre code

Makefile

Décrit les tâches pouvant être exécutées par le framework

Même si nous n'avons encore aucune ligne de code ni même de configuration (en réalité Flex s'en est chargé pour nous), nous pouvons démarrer notre application Symfony. Il est possible de démarrer un serveur HTTP au travers de la commande `make serve` (si vous ne connaissez pas l'outil Make, je vous recommande vivement de vous renseigner sur ce dernier).

Même sans configuration particulière, nous pouvons démarrer notre application grâce au serveur Web embarqué dans PHP au travers de la commande php -S localhost:8000 -t public/.

Par défaut, le framework utilise le serveur Web embarqué avec PHP (ce qui peut être suffisant pour des besoins de développement). Symfony fournit également un bundle symfony/web-server-bundle (nous reviendrons plus tard sur la notion de bundle) permettant d’apporter une meilleure expérience développeur pour manipuler ce dernier.

Une fois le serveur démarré, nous pouvons nous connecter sur notre projet en ouvrant un navigateur et en tapant l’URL http://localhost:8000. Bien entendu, comme nous n’avons encore rien fait, une page d’erreur sera affichée.

Attardons-nous maintenant le contenu du fichier .env. Si vous regardez le contenu de ce dernier, vous constaterez qu’il contient un certain nombre de paramètres :

# This file is a "template" of which env vars needs to be defined in your configuration or in a .env file
# Set variables here that may be different on each deployment target of the app, e.g. development, staging, production.
# https://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration

###> symfony/framework-bundle ###
APP_ENV=dev
APP_DEBUG=1
APP_SECRET=f78d2a48cbd00d92acf418a47a0a5c3e
###< symfony/framework-bundle ###

Notons tout d’abord les commentaires ###> symfony/framework-bundle ### et ###< symfony/framework-bundle ### présent dans le fichier. Ces derniers servent de balise de début et de fin à Flex pour ajouter et supprimer automatiquement la configuration de nos dépendances lors de leurs ajouts ou suppressions dans notre projet.

Viennent ensuite les différentes variables d’environnement d’exécution de notre application :

La variable APP_ENV permet de définir l’environnement courant d’exécution du projet. Généralement 3 environnements sont utilisés : prod (l’environnement où interagissent les utilisateurs finaux), dev (l’environnement utilisé pendant les développements) et test (l’environnement utilisé pour tester automatiquement notre projet).
La variable APP_DEBUG de Symfony fournit un ensemble d’outils permettant de faciliter la résolution des bugs pouvant survenir lors du développement. Par exemple, c’est cette dernière qui génère l’affichage de la pile d’appel des fonctions du framework lorsqu’une erreur se produit (comme lorsque nous avons tenté d’accéder à l’application via le navigateur).
Un des principaux avantages d’avoir recours à un framework est d’utiliser un ensemble de composants réutilisables, régulièrement mis à jour et utilisant des bonnes pratiques de développement. Cela permet au framework de guider le développeur et de minimiser les erreurs pouvant faire apparaître des failles de sécurité. La variable APP_SECRET est ainsi utilisée par certains composants en tant que clé secrète pour générer des jetons de sécurité (comme par exemple lors de la mise en place de formulaire avec les jetons CSRF).

C’est sur ce point que nous allons conclure ce premier chapitre. À ce stade, nous avons créé notre projet Symfony et rapidement fait le tour de l’organisation des fichiers de notre application. Notre environnement est maintenant prêt et nous allons prochainement pouvoir commencer à développer.

La section suivante dévoilera les fonctionnalités de notre application et détaillera les besoins fonctionnels et techniques à satisfaire.

Retrouvez tous les tutorials Jobeet disponibles depuis le billet d’introduction de la série. Le code source de cette application est également disponible sur Github. Vous trouverez une branche associée à l’état du projet après chaque chapitre.

Tutorial Jobeet pour Symfony 4 - Introduction

Tue, 12 Sep 2017 00:00:00 +0200

J’ai récemment eu l’occasion de relire des articles concernant Jobeet, un tutorial pour concevoir une application de type “job board” écrit par l’équipe du framework Symfony (la première version à l’époque) afin de se familiariser avec l’outil. Ce dernier avait par la suite été adapté pour Symfony 2.8 par Dragos HOLBAN et traduit tout récemment en français par Jonathan THUAU.

Lors de l’écriture de ce billet, la version 4 du framework est en cours de finalisation et devrait sortir dans les prochains mois (courant novembre). Cette nouvelle version apporte de nombreuses améliorations et va modifier la manière dont nous travaillons avec l’outil, notamment grâce à un nouveau composant nommé Flex.

Quand j’ai relu le tutorial, j’ai été déçu que ce dernier ne soit pas disponible pour les dernières versions disponibles du framework. J’ai donc décidé de démarrer une série de billets consacrés à l’adaption du tutorial pour Symfony 4.

Vous trouverez donc ici, au fur et à mesure de l’écriture des différents billets, les liens vers les nouveaux articles dont le sommaire se trouve ci-dessous :

Par manque de temps, et du fait de nombreux changements personnels et professionnels je n'ai pas eu l'occasion de terminer la série d'articles que j'avais initialement prévus.

Tutorial Jobeet pour Symfony 4 - Partie 7: Jouons avec la page catégorie
Tutorial Jobeet pour Symfony 4 - Partie 8: Les tests unitaires
Tutorial Jobeet pour Symfony 4 - Partie 9: Les tests fonctionnels
Tutorial Jobeet pour Symfony 4 - Partie 10: Les formulaires
Tutorial Jobeet pour Symfony 4 - Partie 11: Tester les formulaires
Tutorial Jobeet pour Symfony 4 - Partie 12: L’interface d’administration
Tutorial Jobeet pour Symfony 4 - Partie 13: La sécurité
Tutorial Jobeet pour Symfony 4 - Partie 14: Le flux de données
Tutorial Jobeet pour Symfony 4 - Partie 15: Fournir une API
Tutorial Jobeet pour Symfony 4 - Partie 16: Envoyer des emails
Tutorial Jobeet pour Symfony 4 - Partie 17: La recherche
Tutorial Jobeet pour Symfony 4 - Partie 18: L’AJAX
Tutorial Jobeet pour Symfony 4 - Partie 19: L’internationalization
Tutorial Jobeet pour Symfony 4 - Partie 20: Les bundles
Tutorial Jobeet pour Symfony 4 - Partie 21: Le cache
Tutorial Jobeet pour Symfony 4 - Partie 22: Le déploiement
Tutorial Jobeet pour Symfony 4 - Partie 23: Un autre regard sur Symfony

Depuis la création de ce tutorial, le framework n’a cessé d’évoluer et de nouveaux composants ont fait leurs apparitions. Je tenterai d’ajouter de nouveaux articles afin d’y introduire ces derniers :

Tutorial Jobeet pour Symfony 4 - Partie 24: Les assets avec Webpack Encore
Tutorial Jobeet pour Symfony 4 - Partie 25: Gerer un workflow
Tutorial Jobeet pour Symfony 4 - Partie 26: Plus loin avec l’injection de dépendance
Tutorial Jobeet pour Symfony 4 - Annexe 1: Environnement Vagrant
Tutorial Jobeet pour Symfony 4 - Annexe 2: Environnement Docker
Tutorial Jobeet pour Symfony 4 - Annexe 3: Symfony Flex

N’hésitez pas à me contacter via Twitter ou par mail pour me faire part de vos observations et remarques.

Ma semaine 36 de veille (04/09/2017 -> 10/09/2017)

Mon, 11 Sep 2017 00:00:00 +0200

Retrouvez chaque semaine la sélection de mes 5 tweets les plus populaires concernant la veille que je partage sur Twitter. La semaine qui vient de s’écouler marque la fin des vacances scolaires ainsi que des congés d’été, cette dernière fut donc riche en actualités partagées.

Vous souhaitez suivre ma veille sans être “pollué” par les articles du blog ? Je viens pour cela d’ajouter un flux RSS dédié au suivi de la rubrique.

Mon actu préférée

How Does a Database Work ? https://t.co/FbxCW2VXaB
— Jérémy DECOOL (@jdecool) 4 septembre 2017

Savez-vous comment fonctionne une base de données ? Si la réponse et non, ou si vous souhaitez approfondir le sujet en créant un système de base de données similaire à SQLite, foncez sur ce billet !

Le top de la semaine

A curated list of amazingly awesome #PHPStorm plugins, resources and other shiny things : https://t.co/0HwPGNEV5Y
— Jérémy DECOOL (@jdecool) 5 septembre 2017

PHPStorm est certainement l'un des IDE les plus en vogue actuellement pour développer avec le langage PHP. Voici une liste de ressources concernant ce dernier (blogs, comptes Twitter, plugins, ...).

Little UI Details : https://t.co/Pk52KNuvz3
— Jérémy DECOOL (@jdecool) 6 septembre 2017

Vous êtes amené à concevoir des interfaces utilisateur ? Jetez donc un oeil à ce regroupement de tweet qui est une collection de petits conseils de @steveschoger pour améliorer vos compétences en conception visuelle au travers de petits détails qui font toute la différence.

"Go PHP 7.1" because they will ... https://t.co/Iwy9IxF58X
— Jérémy DECOOL (@jdecool) 4 septembre 2017

PHP 5.6 n'est plus activement maintenu et arrive en fin de vie... Vous n'êtes pas encore passé en version 7 ? Vous devriez, parce que eux l'on fait !

Votre CI de qualité : https://t.co/mTHjqjCl2X
— Jérémy DECOOL (@jdecool) 7 septembre 2017

Lorsque nous travaillons sur un projet, nous souhaitons tous mettre en place des bonnes pratiques de tests et d'intégration continue. Pourtant mettre en place un tel environnement peut s'avérer compliqué. Découvrez le retour d'expérience de la société Eleven Labs sur la mise en place d'une stratégie d'intégration continue.

How I failed to replicate an $86 million project in 1 line of code : https://t.co/owY6eznu9g
— Jérémy DECOOL (@jdecool) 4 septembre 2017

Il y a quelques semaines, un article est devenu populaire en expliquant comment son auteur avait réalisé l'équivalent d'un projet évalué à 86 millions de l'art en 57 lignes de code et quelques outils open source. Cet article est une réponse à ce dernier où l'auteur explique comment en prenant quelques résultats d'une expérience avec des technologies open source essaye de se donner "bonne figure".

La formation continue du développeur

Wed, 06 Sep 2017 00:00:00 +0200

Il est primordial lorsqu’on est développeur de rester “à jour”, de garder un oeil sur ce qui se fait et les évolutions de notre métier (aussi bien concernant les produits, processus ou technologies que nous sommes amenés à utiliser au quotidien). Pour cela, faire de la veille est essentiel.

Mais quels sont les moyens pour faire de la veille ? C’est la question que s’est posée cet été Camille Roux et à laquelle il a consacré quelques articles. Je vais pour ma part répondre à cette question dans ce billet.

Pour moi, le minimum qu’un développeur devrait faire, c’est de suivre l’actualité de son domaine. Je parle de domaine au sens large, il ne faut pas rester cantonné à ses acquis, mais sortir de sa zone de confort. Bien que je sois un développeur utilisant essentiellement PHP, je surveille ce qui se fait du côté des autres langages tels que Java, Scala, Kotlin, Javascript, Go, Rust et bien d’autres encore.

L’objectif est de surveiller et de s’organiser dans une collecte d’informations sur les sujets concernés. Je fais donc énormément de veille afin de suivre l’actualité :

liée aux sociétés informatiques (éditeur logiciel, cloud, agence de développement, …)
concernant les outils que je suis amené à utiliser (IDE, framework, langages, …)
à propos des techniques pouvant être utiles (méthodes, architectures, …)

Pour accomplir cette tâche, l’essentiel de ma veille se fait via la consultation de flux RSS en utilisant l’outil Tiny Tiny RSS. Ce dernier me permet d’organiser mes flux en différentes catégories. Généralement, j’ajoute un nouveau flux au fur et à mesure que je découvre de nouvelles sources d’information.

À mes débuts d’utilisation de Tiny Tiny RSS, j’ai commencé par ajouter et suivre de sites d’agrégation de contenu tel que Hacker News ou Human Coders. Lorsque je lis un contenu intéressant, j’ajoute ce dernier à mes flux à suivre. C’est ainsi que j’ai constitué la base des flux que je lis aujourd’hui.

C’est toujours aujourd’hui ce qui constitue l’essentiel de mes sources d’information. En parallèle, j’utilise Twitter. Ma timeline est essentiellement construite avec des personnes tweetant de manière régulière sur des sujets liés à l’informatique. J’utilise également les listes Twitter afin de catégoriser les personnes qui je suis. Pour m’aider dans cette tâche, je me sers de TweetDeck.

Trouvez du temps pour faire de la veille n’est pas forcément quelque chose d’aisé. Je suis persuadé que cela fait partie intégrante de notre travail de développeur et que de ce fait, il est tout à fait normal de consacrer une partie de son temps à cette tâche.

Pour me rendre au travail, je suis amené à prendre le train. Le trajet dure environ 30 minutes. Cela fait donc 1h aller-retour. C’est l’occasion de mettre ce temps à profit. Dans les transports je consulte donc mes flux et Twitter. Mais il m’arrive également fréquemment de lire des livres. C’est également une façon de se former et d’avoir des axes réflexions sur certains sujets. Sur les deux dernières années, j’ai pu lire ou relire des livres tels que : High Performance MySQL, The Clean Coder, Surveillance:// - Les libertés au défi du numériques, La Méthode Google, ou Free! Comment marche l’économie du gratuit.

Se tenir informé de ce qui se fait, des principes qui en découle et savoir quand utiliser ces principes, c’est déjà très bien. Mais avoir l’occasion de mettre en pratique ce que l’on a pu découvrir, c’est encore mieux ! Personnellement, j’adore écrire des petits bouts de code (pas nécessairement des projets complets ou fonctionnels) pour découvrir et utiliser une bibliothèque ou un framework.

Pour passer le cap de la théorie à la pratique, il y a bien tendu la documentation associée aux outils qui vous sera d’une aide précieuse. Mais on voit également de plus en plus de tutorials vidéo ou cours en ligne pour se former. De nombreuses plateformes hébergent ce type de contenu, parmi lesquelles: Youtube, Coursera, Udemy, Elephorm ou encore Tuto.com.

Il existe également des plateformes moins généralistes et donc plus spécialisées sur un domaine. Par exemple, l’année dernière j’ai pu approfondir mes connaissances sur le DDD, le CQRS et l’Event Sourcing au travers de Event Sourcery. Cette année, j’ai décidé de rattraper mon retard sur les technologies orientés frontend que j’ai pas mal délaissées en souscrivant à Egghead qui est une excellente plateforme pour se former sur l’écosystème Javascript (on y retrouve des cours complets sur React, Angular et Vue, mais aussi des vidéos d’introduction sur React Native, Electron, Elm, …).

Après à chacun de trouver la méthode qui lui convient et la plus adaptée pour permettre d’acquérir les connaissances et les compétences voulues.

Ma semaine 35 de veille (28/08/2017 -> 03/09/2017)

Mon, 04 Sep 2017 00:00:00 +0200

Cette semaine je vais essayer de démarrer une série de billets un peu particulière. Je fais beaucoup de veille que je partage abondamment sur Twitter. Je vais donc tenter de vous partager chaque semaine les 5 tweets ayant eu le meilleur taux d’engagements selon la plateforme.

Mon actu préférée

"Clean code" isn't actually clean : https://t.co/4AIzEjIND6
— Jérémy DECOOL (@jdecool) 30 août 2017

Comme Rober C. Martin (alias Uncle Bob) peut nous l'expliquer, un mauvais code peut fonctionner. La notion de "Clean Code" est un ensemble de bonnes pratiques pour concevoir un logiciel qui restera maintenable et évolutif dans le temps. Maintenant cela ne veut pas pour autant dire que le code sera parfait...

Le top de la semaine

Event Sourcing: What it is and why it's awesome https://t.co/d1SmYy2qsk
— Jérémy DECOOL (@jdecool) 30 août 2017

On parle de plus en plus de l'Event Sourcing en tant qu'architecture applicative. Des ingénieurs de Netflix ont d'ailleurs présenté comment ils avaient conçu le système de téléchargement des vidéos de la plateforme sur ce principe. Découvrez dans cet article les principes de base de cette architecture avec les différents avantages et inconvénients.

Egghead.io (https://t.co/pBtakV0qYX) is the best place to keep learning #javascript ecosystem !
— Jérémy DECOOL (@jdecool) 2 septembre 2017

J'ai prévu de faire un billet très prochainement sur la continuité de se former lorsqu'on est développeur, comment je tente au quotidien de garder un oeil sur l'état de l'art de notre métier et continue de me former autant que possible. Egghead.io est une excellente plateforme pour se former et garder un oeil sur les technologies orientés Javascript.

Développer une culture de la sécurité psychologique : https://t.co/7fXBmeo0MY
— Jérémy DECOOL (@jdecool) 31 août 2017

Dans un (trop) grand nombre d'entreprises, l'indicateur principal d'une équipe performante est le profil, l'ancienneté ou les niveaux de salaire. John Looney, un ancien ingénieur de Google qui au travers de son expérience autour la performance d'une équipe projet et des différents éléments qui peuvent l'impacter. Un article très instructif, riche en enseignement et qui fait réfléchir.

Instagram is listening to you : https://t.co/sSYxlpHFOz
— Jérémy DECOOL (@jdecool) 28 août 2017

Dans un monde où l'on est de plus en plus "traqué" sur Internet, nous attachons une importance au respect de notre vie privée à un point que cela commence à toucher le grand public. Cet article explique comment l'application mobile Instagram espionne ses utilisateurs pour obtenir un certain nombre d'informations vous concernant et ainsi pouvoir vous proposer une publicité toujours plus ciblée.

Why some people don't do Open Source : https://t.co/GYbrry7hnc
— Jérémy DECOOL (@jdecool) 29 août 2017

Je suis fortement attaché à l'Open Source. J'utilise un grand nombre d'outils Open Source et j'y contribue lorsque j'en ai l'occasion. Mais pourquoi tant de personnes ne prennent-elles pas part à ce mouvement ? Cet article tentera de répondre à cette question.

Les modèles économiques sur Internet

Wed, 02 Aug 2017 00:00:00 +0200

Je suis actuellement en train de lire “La méthode Google”, un livre qui décrypte les “lois de Google” pour en extraire des principes de management et de comportements qui ont fait le succès de l’entreprise.

Le livre aborde les choix de modèle économique de la société pour s’imposer. Un passage m’a particulièrement interpelé : “les entreprises les plus florissantes du Web ne font pas payer les clients le plus possible, […] tirez le moins de gains possible du réseau [de client] pour le laisser s’étendre au maximum en taille et en valeur”.

Ce passage résonne dans ma tête tant il est criant de vérité. Jusqu’à maintenant, les entreprises facturaient ce que le marché était prêt à payer. Mais aujourd’hui, de nouvelles sociétés s’imposent car elle facture à leurs clients le minimum de marges pour être viable. De cette façon, elle attire un plus grand nombre de clients et les fidélise. Je pense immédiatement à Canal+ qui se plaint de la concurrence d’acteurs comme Netflix. Mais les exemples sont légion ces dernières années.

L’auteur, Jeff Jarvis, un journaliste américain explique aussi que ce sont les communautés de client qui font la valeur de l’entreprise. Les sociétés du Web doivent ouvrir leurs plateformes aux différentes communautés pour que ces dernières s’approprient les marques. C’est ce que l’on voit de plus en plus avec par exemple, les sites d’e-commerce qui s’ouvrent de plus en plus au travers de Marketplace. La plupart des acteurs en sont doté Amazon, Fnac, CDiscount, RueDuCommerce et j’en passe.

Donc retenez bien ces points si vous souhaitez lancer un business dans un futur proche. Ne facturez pas ce que les gens sont prêts à payer, facturez le minimum dont vous avez besoin. Et surtout ne soyez pas fermé, ouvrez-vous à vos communautés d’utilisateurs.

Connexion master/slave avec Doctrine

Wed, 19 Jul 2017 00:00:00 +0200

Pour optimiser les performances d’une application, il arrive que l’on mette en place une architecture type master/slave. Ce type de fonctionnement consiste à mettre en place un serveur maître, répliqué sur un serveur esclave. Les accès à la base de données sont ensuite séparées: les opérations de lecture s’effectuent sur l’instance répliquée alors que les écritures se font sur le serveur maître.

Mettre en place ce type de fonctionnement en PHP lorsque l’on utilise Doctrine est très simple puisque la bibliothèque a prévu ce mode de fonctionnement. Pour cela, il est nécessaire de spécifier le type de connexion à utiliser au travers du paramètre wrapperClass et de décrire comment se connecter aux différents serveurs.

$connection = Doctrine\DBAL\DriverManager::getConnection([
    'wrapperClass' => 'Doctrine\DBAL\Connections\MasterSlaveConnection',
    'driver' => 'pdo_mysql',
    'master' => ['user' => '', 'password' => '', 'host' => '', 'dbname' => ''],
    'slaves' => [
        ['user' => 'slave1', 'password', 'host' => '', 'dbname' => ''],
        ['user' => 'slave2', 'password', 'host' => '', 'dbname' => ''],
    ]
]);

La configuration de la connexion s’effectue au sein de DBAL (la couche d’abstraction d’accès à la base de données du projet). Cette configuration est donc également possible au niveau de Doctrine ORM ainsi que son implémentation dans les frameworks Zend et Symfony.

Par exemple, pour utiliser ce mode de connexion à la base de données dans un projet Symfony, il suffira d’ajouter la configuration suivante :

# app/config/config.yml
doctrine:
    dbal:
        driver:   %database_driver%
        host:     %database_host%
        port:     %database_port%
        dbname:   %database_name%
        user:     %database_user%
        password: %database_password%
        slaves:
            slave1:
                host:     %database_host_slave1%
                port:     %database_port_slave1%
                dbname:   %database_name_slave1%
                user:     %database_user_slave1%
                password: %database_password_slave1%


            slave2:
                host:     %database_host_slave2%
                port:     %database_port_slave2%
                dbname:   %database_name_slave2%
                user:     %database_user_slave2%
                password: %database_password_slave2%

Lors de l’utilisation de la connexion MasterSlaveConnection, il est important de noter les opérations qui seront effectuées sur la base maître et sur la base esclave. Par exemple, l’appel aux méthodes exec, executeUpdate, insert, delete, update, createSavepoint, releaseSavepoint, beginTransaction, rollback, commit, query et prepare s’exécuteront sur la base maître.

Pour lire des données depuis les connexions secondaires, il sera nécessaire d’utiliser la méthode executeQuery. Lors de cette action, un serveur “esclave” sera choisi aléatoirement.

Il est également important de noter qu’il est possible de faire une opération d’écriture sur les serveurs esclaves si la requête effectuée n’ouvre pas de transaction. Il est tout à fait possible d’écrire le code suivant : $connection->executeQuery("DELETE FROM table");.

Les dépendances locales récursives dans un projet Composer

Thu, 13 Jul 2017 00:00:00 +0200

Dans un précédent billet, j’ai parlé de comment il était possible de gérer les dépendances PHP dans un projet monorepo avec Composer. Si vous avez testé la méthode décrite, vous avez peut-être rencontré des difficultés lorsqu’une dépendance de votre projet a elle-même une dépendance dans le même dépôt.

Par exemple, si je développe un site e-commerce avec un composant Cart pour la gestion du panier et que je souhaite implémenter ce dernier dans une application Symfony. Je peux alors être tenté de créer un CartBundle qui sera intégré dans l’application principale.

On aurait l’arborescence ci-dessous :

applications/
    frontend/
        composer.json # Dépendance vers CartBundle
components/
    Cart/
        composer.json # Autonome
    CartBundle/
        composer.json # Dépendance vers Cart

Le fonctionnement de Composer dans ce cas est clairement expliqué dans la documentation: les repositories ne sont pas chargés récursivement. En effet, Composer estime que ce paramètre de configuration est exceptionnel et doit être utilisé de manière temporaire.

Pour pallier ce problème, vous devrez spécifier explicitement les sous dépendances dans la configuration votre application principale.

applications/
    frontend/
        composer.json # Dépendance vers CartBundle et explicite vers Cart
components/
    Cart/
        composer.json # Autonome
    CartBundle/
        composer.json # Dépendance vers Cart

Heureusement, pour éviter d’avoir à spécifier tous les répertoires contenant nos dépendances, Composer autorise l’utlisation de “wildcard” tel que * et ?. Ainsi le fichier composer.json de notre application pourrait ressembler à :

{
  "repositories": [
    {
      "type": "path",
      "url": "../../components/*"
    }
  ],
  "require": {
      "myapp/Cart": "*",
      "myapp/CartBundle": "*"
  }
}

Gérer les dépendances Composer dans un projet monorepo

Mon, 26 Jun 2017 00:00:00 +0200

Mettre en place un monorepo (aka. un dépôt monolithique), c’est mettre en place un dépôt global regroupant toutes les applications et divers composants de votre projet. Dans ce billet, nous n’allons pas voir les avantages ou inconvénients de ce type d’organisation, certains ont fait des billets sur les avantages, les inconvénients ou des conférences à ce sujet. Nous allons plutôt voir comment mettre en place une gestion de dépendances avec Composer.

Prenons par exemple, un projet ayant l’arborescence suivante :

applications/
    api/
        composer.json
    backend/
        composer.json
    frontend/
        composer.json
    worker/
        composer.json
component/
    package1/
        composer.json
    package2/
        composer.json

La problématique va être de pouvoir gérer simplement dans les différentes applications, les dépendances présentes dans le répertoire component. La première idée qui peut venir à l’esprit pourrait être de configurer l’autoloading de composer afin de faire référence aux différents composants déclarer dans le dépôt.

{
  "autoload": {
    "psr-4": {
      "Vendor\\Package1\\": "../../component/package1/src",
      "Vendor\\Package2\\": "../../component/package2/src"
    }
  }
}

Bien que cette méthode fonctionne, elle n’est cependant pas optimale car avec cette dernière, le fichier composer.json du composant n’est pas utilisé. Or, ce dernier contient diverses informations sur la bibliothèque. Dans le cas présent, nous avons dû redéfinir la configuration de l’autoloading de la bibliothèque.

Composer définit le concept de “repositories”. Globalement, un repository correspond à une source de composant. Par défaut et sans que le développeur n’ait besoin de faire quoi que ce soit, Composer définit Packagist comme source principale.

Il est bien évidemment possible d’ajouter de nouvelles sources de repository et Composer supporte différentes sources de données telle que github, gitlab, vcs et bien d’autres encore. Mais celle qui va nous intéresser est path. Cette dernière va permettre de définir une source de composants correspondant à un chemin de notre machine.

Il est donc possible d’utiliser un composant en modifiant le composer.json d’une application de la manière suivante :

{
  "repositories": [
    {
      "type": "path",
      "url": "../../component/package1"
    },
    {
      "type": "path",
      "url": "../../component/package2"
    }
  ],
  "require": {
      "vendor/package1": "*",
      "vendor/package2": "*"
  }
}

Au travers de cette modification, il n’est plus nécessaire de redéfinir la configuration spécifiée dans le composant, puisque Composer va charger ce dernier comme n’importe quelle autre dépendance de votre projet.

En faisant des recherches sur la meilleure manière de gérer les dépendances au sein d’un monorepo, j’ai également découvert un projet expérimental se présentant sous la forme d’un plugin Composer dédié à la gestion de ce type d’organisation. Je n’ai pas expérimenté ce dernier et bien qu’il ne semble plus maintenu, il peut être intéressant d’y jeter un oeil. Son auteur a publié un article expliquant l’objectif et le fonctionnement du projet.

Des "metapackages" Composer prochainement dans Symfony

Fri, 23 Jun 2017 00:00:00 +0200

C’est en faisant un tour sur les dépôts Github de Symfony que j’ai découvert la création récente (à partir de la fin du mois de mai) de “metapackage” Composer. Pour rappel, un métapaquet est une dépendance vide dont l’objectif est de déclencher l’installation d’autres dépendances.

Après une recherche rapide sur le blog ainsi que sur la documentation, je n’ai pas trouvé la trace d’une communication officielle concernant ces nouvelles dépendances. On peut donc lister à ce jour 4 métapaquets :

annotations-pack pour la gestion des annotations
profiler-pack permettant d’avoir le Web profiler Symfony
orm-pack pour l’installation des modules Doctrine ORM
debug-pack pour obtenir les composants nécessaires au debug, à la mise en place de tests et à la gestion de logs

La création de ces dépendances sera néanmoins pratique pour installer rapidement des packs de fonctionnalités avec le nouveau mode de distribution de Symfony 4.

Edit: Suite à mon article, Kevin Dunglas a fait un tweet pour expliquer rapidement comment ces métapaquets étaient utilisés.

C'est utilisé par Flex en fait. C'est grâce à ces paquets que tu peux faire composer req api orm templating par exemple.
— Kévin Dunglas (@dunglas) 23 juin 2017

Novaway lance son blog

Thu, 01 Jun 2017 00:00:00 +0200

C’est désormais officiel, le blog de Novaway (la société pour laquelle je travaille :)) est en ligne ! Sur ce dernier, vous retrouverez des astuces, méthodes, technos et retours d’expérience tournant autour de nos 3 pôles d’expertises que sont la technique, le conseil et le marketing.

Je publierai donc conjointement à ce blog, quelques articles sur le blog d’entreprise. Là où ici, je m’attache à partager des articles courts et concis, les articles que je publierai sur le site de Novaway seront plus exhaustifs et complets.

À ce jour, j’ai publié 3 articles que je vous invite à découvrir (ainsi que ceux de mes collègues) :

Et pour ne louper aucun billet, n’hésitez pas à vous abonner au flux RSS.

RSS est mort, longue vie à JSONFeed

Mon, 29 May 2017 00:00:00 +0200

Peut-être que vous en avez jamais entendu parler, il a pourtant l’ambition de remplacer le format RSS. JSONFeed, dont la première version a été publiée le 17 mai 2017 est un nouveau format de syndication entièrement basé comme son nom l’indique sur JSON.

Le format RSS qui est massivement utilisé (à défaut d’alternative), a été créé en 1999 et permet de suivre facilement un flux d’informations. Le format a évolué en 2003, pour donner naissance à Atom.

JSONFeed tente d’apporter un nouveau souffle aux formats de syndication. Ce dernier a été conçu par deux développeurs qui ont souhaité proposer une alternative moderne en remarquant que le format JSON est devenu un standard incontournable du Web et que la plupart des développeurs souhaiter éviter XML.

Un format que l’on se doit de suivre dans les mois à venir.

PS: Le format étant récent, il n’existe pas d’outil permettant de générer un flux JSONFeed en PHP. J’ai donc commencé à écrire un composant PHP pour cela. N’hésitez pas à contribuer.

Les fluxs JSONFeed sont disponibles pour suivre la mise à jour de ce blog

Assurer le redémarrage d'une application Go en cas de plantage

Mon, 15 May 2017 00:00:00 +0200

Lorsque l’on développe une application Go et que l’on souhaite déployer cette dernière, on se pose souvent la question: “Comment assurer son redémarrage en cas de plantage ?”. Car contrairement à un script PHP ou tout autre script qui est exécuté par un serveur Web, en cas d’erreur fatale de notre application, le processus faisant fonctionner cette dernière va s’arrêter.

Pour cela, nous avons besoin d’utiliser un programme dont le but est de gérer les processus. Pour cela j’utilise Supervisor. Ce dernier va donc s’assurer qu’il y a toujours une instance de l’application en fonctionnement et en cas d’arrêt de cette dernière, relancera un nouveau processus automatiquement.

Dans sa version la plus simple, un service Supervisor se paramètre au travers d’un fichier de configuration :

[program:my_app]
command=/path/to/app

Si vous souhaitez en savoir plus, je vous invite à parcourir la documentation de l’outil. Elle vous permettra notamment de comprendre comment ce dernier fonctionne ainsi que la paramètre sur lesquels vous pouvez agir et qui vous permettront par exemple de définir l’utilisateur qui exécutera le processus, le nombre d’instance que vous souhaitez démarrer, comment doivent être gérer les sorties standard et bien d’autres encore…

Choisissez bien les dépendances de vos projets

Thu, 11 May 2017 00:00:00 +0200

La semaine dernière, une équipe à côté de laquelle je me trouvais faisait le point sur un projet. Il y avait alors un échange concernant l’utilisation d’une dépendance qui n’était pas compatible PHP 7, la version de PHP choisie pour démarrer ce dernier. Il en a résulté que l’équipe a été obligé de développer le projet en 5.6, ce qui m’a fortement fait réagir. Bien qu’il puisse y avoir des raisons qui peuvent conduire à prendre une telle décision, mais dans le cas présent, je trouve cela aberrant.

Pourquoi ? Tout d’abord parce que la dépendance en question devait être mise en place pour intégrer Elasticsearch dans le projet. Il existe une multitude de composants permettant cela et le client officiel est très bien fait. Je peux comprendre que dans le cas présent, l’équipe souhaitait un bundle Symfony qui ait quelques fonctionnalités supplémentaires, mais vu l’envergure du projet, n’était-il possible de simplement utiliser la librairie de base ? Mais si le bundle était si important pour l’équipe, n’était-il pas possible de faire une PR pour apporter la compatibilité sur la branche 7 de PHP et d’en faire profiter la communauté ?

Mais au-delà de tout ça, essayons de se poser les bonnes questions. En effet, PHP 5.6 est en fin de vie. Cette version n’a plus de support actif et reçoit donc maintenant que des correctifs de sécurité. PHP 7.0 est sortie il y a maintenant plus de deux ans et PHP 7.1 il y a un an. Si un composant PHP n’est pas compatible PHP 7, nous sommes alors en droit de se demander si ce dernier est encore actif et/ou maintenu ? Est-ce vraiment judicieux de démarrer un nouveau projet dans ces conditions ? Est-ce un pari gagnant dans le long terme ?

Pour ma part, la réponse est clairement non, surtout pour un projet qui est amené à être créé maintenant. Il est primordial de bien choisir les dépendances que l’on ajoute à un projet et d’avoir également une vision à long terme dans les phases de conceptions et réflexions autour du projet.

Si l’on devait conclure ce billet, et si vous n’aviez qu’une seule phrase à retenir, ça serait :

Ne démarrez pas vos projets sur des versions de PHP déjà obsolètes et utilisez des dépendances connues et maintenues !

Votre équipe vous en remerciera, car comme je le tweetais cette semaine :

N'oubliez pas que lorsque vous prenez des raccourcis dans vos devs, vous finissez irrémédiablement par en payer les conséquences tôt ou tard
— Jérémy DECOOL (@jdecool) 4 mai 2017

Utiliser Chrome Headless avec Behat

Tue, 09 May 2017 00:00:00 +0200

Il sera désormais possible à partir de la version 59 de Chrome (la version bêta au moment où j’écris ces lignes) en mode “headless”, c’est-à-dire sans interface graphique. Ce mode de fonctionnement est intéressant pour les tests par exemple, car il ne sera plus obligatoire de “piloter” Chrome via son interface graphique.

Cette nouvelle fonctionnalité a provoqué un large engouement de la part de la communauté Web. À tel point que le mainteneur de PhantomJS, un navigateur headless, également basé sur Webkit a annoncé la fin du projet. Donc si comme moi, vous utilisiez ce dernier dans vos scénarios Behat, il va être nécessaire de changer de solution.

Pour cela, rien de plus simple. Voici par exemple la configuration Behat pour Selenium que j’utilisais avec PhantomJS.

# behat.yml
default:
    extensions:
        # ...
        Behat\MinkExtension:
            base_url: http://project.dev
            sessions:
                default:
                    selenium2:
                        wd_host: http://localhost:4444/wd/hub

Pour que Selenium puisse interagir avec Chrome, nous allons devoir utiliser un driver additionnel ChromeDriver. Une fois ce dernier installé, nous devrons ajouter quelques lignes de configuration supplémentaires.

# behat.yml
default:
    extensions:
        # ...
        Behat\MinkExtension:
            base_url: http://project.dev
            sessions:
                default:
                    selenium2:
                        browser: chrome
                        wd_host: http://localhost:4444/wd/hub
                        capabilities:
                            chrome:
                                switches:
                                    - "--headless"
                                    - "--disable-gpu"

Parmi les changements, nous spécifions à Selenium d’utiliser Chrome en tant que navigateur au travers de l’argument browser. Puis nous spécifions des capabilities, c’est-à-dire des options permettant de personnaliser et de configurer la session Chrome qui sera ouverte. Nous indiquons ainsi vouloir une navigateur headless. Le paramètre --disable-gpu est pour le moment obligatoire.

Et voilà, en ayant tout juste rajouté 5 lignes de configuration, vous avez remplacé l’utilisation de PhantomJS par Google Chrome en mode “headless”.

Le fichier de configuration est disponible sur Gist

Jekyll sous Docker avec des dépendances tierces

Mon, 08 May 2017 00:00:00 +0200

Ce blog est généré avec Jekyll et j’utilisais jusqu’à maintenant Docker avec un conteneur personnalisé, basé sur l’image officielle mais qui avait quelques dépendances supplémentaires. Néanmoins, je viens de découvrir que l’image officielle était amplement suffisante, même si vous avez besoin d’installer des gems supplémentaires.

Jekyll est un outil écrit en Ruby, c’est donc tout naturellement que j’utilise Bundler pour simplifier la gestion et l’installation des dépendances que j’utilise pour faire tourner ce blog (génération d’un sitemap, highlight, compression des assets, …).

J’utilisais donc une image personnalisée qui pré-installé toutes les dépendances nécessaires. Pourtant, je viens de découvrir qu’il était possible de spécifier à bundle où installer les dépendances. De ce fait, j’installe ces dernières au même niveau que le blog et non plus de manière globale comme précédemment.

Si vous êtes dans le même cas que moi, vous pouvez utiliser cette commande :

docker run --rm -v $PWD:/src -w /src -p 4000:4000 jekyll/jekyll sh -c "bundle install --path vendor/bundle && exec jekyll [command]"

Utiliser l'extension PHP Tideways dans Travis CI

Sun, 23 Apr 2017 00:00:00 +0200

Tideways est une extension PHP permettant d’ajouter le support du profiling. Le profiling est une activité qui consiste à collecter un certain nombre d’informations sur l’exécution d’un code (PHP dans notre cas). Tideways est en réalité la continuité de l’extension XHProf précédemment développé par Facebook, mais aujourd’hui abandonné au profit de HHVM. Le principal avantage de cette dernière est que l’extension est compatible avec les versions 7 de PHP.

L’extension PHP n’étant pas “standard”, il n’est pas possible de l’activer directement dans Travis CI. Il sera donc nécessaire de télécharger, compiler et activer l’extension en amont de la phase de build. Pour cela, nous allons rajouter les commandes suivantes dans notre fichier .travis.yml :

# ...
before_scripts:
  # ...
  - wget -Otideways-php.tar.gz https://github.com/tideways/php-profiler-extension/archive/v4.1.1.tar.gz
  - tar xvfz tideways-php.tar.gz -C /tmp
  - cd /tmp/php-profiler-extension-4.1.1
  - phpize
  - ./configure
  - make
  # ...

Les commandes ci-dessus téléchargent les sources de l’extension, les décompressent dans le répertoire /tmp et les compilent. Une fois ces étapes, il ne reste plus qu’à activer l’extension auprès de PHP. Cela peut être fait en ajoutant une ligne dans le fichier de configuration PHP :

echo "extension=/tmp/php-profiler-extension-4.1.1/modules/tideways.so" >> ~/.phpenv/versions/$(phpenv version-name)/etc/php.ini

Sinon il est possible si vous utilisez PHP via la ligne de commande d’activer l’extension à la volée via l’option -d :

php -dextension=/tmp/php-profiler-extension-4.1.1/modules/tideways.so vendor/bin/phpunit

Ce que je retiens du SymfonyLive 2017

Sun, 02 Apr 2017 00:00:00 +0200

J’ai eu l’occasion cette année de participer au SymfonyLive organisé par SensioLabs à Paris. Tout comme ma dernière participation en 2015, cette année encore, j’ai pu assister à des conférences de qualité autour de PHP et du framework Symfony.

Présent au #Symfony_Live pour la team @novaway avec @FloChntrl pic.twitter.com/9DUFBCQ3R3
— Jérémy DECOOL (@jdecool) 30 mars 2017

Mais plus important que les différentes conférences et présentations qui sont données tout au long de ces 2 jours, c’est l’occasion de rencontrer et de discuter avec la communauté. Cela permet de voir les tendances émergentes ainsi que celles qui sont considérées comme acquis auprès de tous. Cela va même au-delà de l’écosystème Symfony.

Ce que je retiens donc de cet événement :

Parmi les “buzzwords” actuels, difficile d’éviter de parler des microservices. Les acteurs majeurs du Web ont largement migré vers ce type d’architecture. Mais les microservices ont du mal à se frayer un chemin dans l’écosystème PHP. Bien sur ce n’est pas une réponse universelle, mais des discussions que je peux avoir avec de nombreux développeurs, l’idée qui en ressort c’est que le concept est intéressant mais qu’il ne s’adapte jamais réellement au projet sur lequel on travaille. Il faut également que ce type d’architecture à un impact organisationnel sur les équipes qui la mette en place.
S’il y a bien un autre concept dont on entend de plus en plus parler dans l’écosystème PHP, c’est le Domain Driven Design (DDD). Cette technique de conception n’a rien de nouveau puisqu’elle existe depuis de nombreuses années. Mais PHP s’étant grandement professionnalisé, les projets que nous sommes amenés à développer sont de plus en plus complexes. Dans ce contexte, le DDD nous permet de développer des applications proches du métier, avec une forte expressivité de ce dernier. Sur ce point, j’ai un peu l’impression de voir ce qui s’est passé avec la notion de tests logiciels il y a quelques années. J’ai nettement l’impression que les développeurs, même s’ils ne vont pas migrer complètement vers ce type de conception, ces derniers vont tenter d’appliquer les concepts les plus importants dans leurs projets.
Le dernier point que je retiens est la démocratisation des Platform as a service (PaaS). Les problèmes de déploiement et de gestion des ressources serveurs (aka. la “scalabilité”) est une des préoccupations principale de nos applications. Les services de PaaS permettent de se concentrer sur le développement de notre projet en proposant de gérer la partie hébergement. De ce fait, les PaaS sont de plus en plus utilisés et les offres disponibles pour ce type de service sont de plus en plus nombreuses.

Si vous êtes intéressé par l’événement, sachez qu’il existe un dépôt Github contenant la description des présentations avec les slides associées. Les présentations ayant été filmé, les vidéos arriveront prochainement.

L'extension PHP qui permet de modifier des constantes

Mon, 06 Mar 2017 00:00:00 +0100

Comme quoi après des années de pratique d’un langage, ce dernier peut toujours nous surprendre. Une constante est par définition constante, sa valeur ne change pas. Lorsque l’on en définit une en PHP via la fonction define, il est donc impossible de la changer ou de la modifier.

Je viens de découvrir une extension PECL qui change tout ça ! Elle s’appelle runkit. Cette dernière fournit un ensemble de fonction qui vous permettra entre autres, d’ajouter, modifier et supprimer des constantes de votre code (le genre de chose qu’on ne devrait jamais avoir à faire).

Sachez en tout cas que si vous avez besoin de faire une telle chose, c’est que vous avez un problème de conception. Et si malgré tout vous souhaitez quand même tester l’extension, cette dernière ne semble plus maintenue et ne sera certainement pas compatible PHP7.

Partager des clés SSH avec un conteneur Docker

Sun, 05 Mar 2017 00:00:00 +0100

Lorsque l’on est amené à utiliser Docker, il arrive que l’on ait parfois besoin d’accéder aux clés SSH de l’hôte. C’est notamment le cas si l’on utilise un conteneur pour déployer une application. Il existe pour cela plusieurs solutions plus ou moins bonnes.

La première solution qui vous viendra peut-être à l’esprit et d’ajouter les clés SSH directement dans l’image du conteneur. Cette solution est de loin la pire ! Même si vous êtes la seule personne à l’utiliser. Et si ce n’est pas le cas, c’est une solution à proscrire, car de ce fait, vous allez partager des clés à tout un panel d’utilisateurs. C’est une catastrophe d’un point de vue sécurité.

La solution qui devrait vous venir naturellement, est de créer un volume afin de partager les clés SSH de l’hôte avec le conteneur via une commande du style : docker run -it -v $HOME/.ssh:/root/.ssh my-container (oui, j’utilise root et c’est mal). La contrainte avec cette méthode, c’est que vous allez obtenir avec un message d’erreur expliquant que l’utilisateur n’est soit pas le propriétaire des fichiers, soit que les droits de ces dernières sont trop ouverts.

Pour résoudre ce problème, j’ai vu des développeurs modifier directement les UID des clés de leur machine pour le faire correspondre avec celui du conteneur. Cette méthode n’étant pas universelle, relativement contraignante et vous obligeant à modifier les droits et/ou le propriétaire des fichiers, est loin d’être la méthode idéale.

La meilleure solution a mon sens, est de partager les clés SSH de l’hôte dans un répertoire temporaire du conteneur et de vérifier leurs présences au démarrage de ce dernier. Si elle existe, elles seront alors copiées dans les répertoires de configuration adéquate et on affectera les droits requis. Ce système est donc universel et fonctionne peu importe l’utilisateur du conteneur et du système hôte.

De manière concrète, j’ai tendance à utiliser un script de démarrage de mes conteneurs que je définis en tant qu’ENTRYPOINT dans lequel j’effectue les opérations suivantes :

if [ -f /var/tmp/sshconf ]; then
    cp /var/tmp/sshconf /root/.ssh/config
    chmod 600 /root/.ssh/config
fi

if [ -f /var/tmp/sshid ]; then
    cp /var/tmp/sshid /root/.ssh/id_rsa
    chmod 600 /root/.ssh/id_rsa
if [ -f /var/tmp/sshconf ]; then

Il ne vous restera plus qu’à démarrer votre conteneur Docker en définissant les fichiers à partager : docker run -it -v $HOME/.ssh/id_rsa:/var/tmp/sshid -v $HOME/.ssh/config:/var/tmp/sshconf my-container

Les déploiements automatisés

Mon, 27 Feb 2017 00:00:00 +0100

Il est maintenant assez rare de trouver un développeur qui vous dira qu’il ne déploie pas son projet en production de manière automatique. Cela fait aujourd’hui partie intégrante des bonnes pratiques de l’ingénierie logicielle et les outils pour nous aider dans cette tâche sont nombreux.

Pourtant sur un grand nombre de projets que je peux voir passer ou en discutant avec de nombreux développeurs, si le code source est effectivement poussé de manière automatisé, le déploiement complet d’un projet informatique n’est rarement entièrement réalisé sans intervention humaine.

Par exemple, la configuration initiale du projet est très souvent réalisée manuellement. Cette configuration permet généralement de définir les variables d’environnements et projet nécessaire entre autres, à la connexion à la base de données. Et si même on peut justifier que ce paramétrage n’est réalisé qu’une seule fois lors du premier déploiement, qu’en est-il lorsqu’un paramètre doit changer ou qu’un nouveau est ajouté ?

De même, si votre application nécessite la mise en place d’un système de tâches planifiées (CRON), est-il nécessaire que quelqu’un intervienne sur le serveur ou être vous capable de gérer cette configuration lors du déploiement ?

À ces deux exemples, on pourra me répondre qu’il s’agit d’opérations ponctuelles et qui ne sont pas réalisées de manière fréquente. En admettant que cela ne prenne qu’un temps négligeable pour être faites, il vous sera néanmoins nécessaire d’avoir une personne (disponible) ayant les accès requis pour effectuer le travail. Avec une telle contrainte, on peut oublier la mise en place d’une politique de déploiement continu. Sans parler des problèmes de sécurité potentiels liés à l’humain qui effectuera cette tâche.

Sans un processus de déploiement logiciel entièrement automatisé, on oubliera également la possibilité pour notre infrastructure de pouvoir “scaler” si notre produit rencontre un grand succès et est amené à croître rapidement.

N’oubliez pas que déployer son application automatiquement, ce n’est pas simplement pousser du code en production. Il y a un certain nombre de choses à prendre en compte tel que : la mise en place et installation d’un serveur, la gestion de la configuration du projet, une gestion autonome des secrets (notamment pour les accès base de données).

Assurer la compatibilité des tests PHPUnit 6 avec les versions antérieures

Mon, 20 Feb 2017 00:00:00 +0100

PHPUnit version 6 a été tagguée le 3 février 2017. Cette nouvelle version n’est dorénavant compatible qu’avec PHP 7+. Un changement majeur introduit par cette nouvelle branche est le renommage de la classe PHPUnit_Framework_TestCase en PHPUnit\Framework\TestCase. Si comme moi, il vous arrive de tester une même branche de code avec plusieurs versions de PHP, cela pourra être un problème.

J’ai eu le cas cette semaine, où, sur une base de code toujours maintenu (mais plus pour très longtemps) sur les versions PHP 5.3+. Sans rentrer dans les détails techniques, pour simplifier l’exécution des tests, nous récupérons une version de PHPUnit avec la définition Composer suivante : phpunit/phpunit:@stable. Ce n’est certes pas l’idéal ni une excellente pratique, mais cela fonctionne bien.

Lors du passage des tests avec PHP 7, nous récupérons ainsi la version 6 de PHPUnit qui provoque alors une erreur puisque la classe PHPUnit_Framework_TestCase qui était utilisée jusque-là n’est plus disponible.

En attendant la fin du support des versions de PHP 5.x pour le code concerné, la solution de contournement utilisé a été de définir un alias de classe dans le “bootstrap” de PHPUnit de la manière suivante :

// Keep PHPUnit < 6.0 BC
if (!class_exists('PHPUnit_Framework_TestCase') && class_exists('PHPUnit\Framework\TestCase')) {
    class_alias('PHPUnit\Framework\TestCase', 'PHPUnit_Framework_TestCase');
}

De ce fait, si la classe PHPUnit_Framework_TestCase n’existe pas, c’est que nous sommes certainement en train d’éxecuter la nouvelle version de PHPUnit. Et nous définissons donc un alias vers la classe PHPUnit\Framework\TestCase si cette dernière existe.

Formatter des valeurs monétaires en Javascript

Fri, 30 Sep 2016 00:00:00 +0200

Avec l’avènement des applications de type “Single Page Application” (SPA), nous développeurs, sommes amenés à concevoir des applications qui tendent à réaliser de plus en plus d’opérations côté client. Lorsque l’on travaille sur les problématiques d’internationalisation, il est régulièrement nécessaire de mettre en forme des valeurs monétaires en fonction d’une devise et d’une langue qui peut varier d’un utilisateur à un autre.

Pour cela la norme ECMAScript a introduit la fonction Number.prototype.toLocaleString() qui permet de renvoyer chaîne de caractères représentant un nombre en tenant compte de la locale. Cette dernière gère également la mise en forme des valeurs monétaires.

var balance = 4200.5;

console.log(balance.toLocaleString('fr-FR', {
  style: "currency",
  currency: "EUR"
})); // => 4 200,50 €

console.log(balance.toLocaleString('en-US', {
  style: "currency",
  currency: "EUR"
})); // => $4,200.50

Malheureusement, cette API n’est pas encore disponible dans tous les navigateurs. Et malgré de nombreuses recherches, je ne suis pas parvenu à trouver un composant ou un “polyfill” qui me convienne.

Cela jusqu’à aujourd’hui ! En effet l’OSREC Financial de Londres, vient de publier un composant permettant de gérer le formatage des valeurs monétaires compatible sur tous les navigateurs.

Bien que cette dernière ne soit pas parfaite, c’est celle qui aujourd’hui correspond le mieux à mon besoin.

Accèdez facilement à vos constantes Twig avec TwigConstantAccessorBundle

Wed, 28 Sep 2016 00:00:00 +0200

C’est sans surprise que la plupart des développeurs Symfony utilisent Twig comme moteur de templating, il s’agit en effet du moteur fourni par défaut avec le framework. Il arrive souvent que l’on soit amené à accéder à des constantes dans nos vues. Pour cela, Twig nous propose différentes solutions.

La solution la plus évidente est certainement l’utilisation de la fonction constant ainsi que du test correspondant.

{{ constant('Namespace\\Classname::CONSTANT_NAME') }}
{{ constant('RSS', date) }}

{% if post.status is constant('Post::PUBLISHED') %} ... {% endif %}
{% if post.status is constant('PUBLISHED', post) %} ... {% endif %}

La configuration de Symfony permet également de définir un certain nombre de variables, services et constantes pouvant être accessible directement depuis vos templates Twig.

# app/config/config.yml
twig:
    # ...
    globals:
        my_service:      "@my_service"
        my_constant_foo: foo
        my_constant_bar: bar

Une méthode moins répandue est de passer par une extension Twig. Mais attention, cette possibilité est maintenant dépréciée et sera supprimée dans la version 2 de Twig.

class Project_Twig_Extension extends Twig_Extension implements Twig_Extension_GlobalsInterface
{
    public function getGlobals()
    {
        return array(
            'text' => new Text(),
        );
    }

    // ...
}

Pour réduire tout ce travail de configuration, j’ai créé un bundle visant à simplifier l’accès aux constantes de classe dans les templates Twig. Une fois installé, il suffit de définir les classes dont vous souhaitez exposer les constantes et le bundle s’occupe entièrement de la gestion de la configuration.

# app/config/config.yml
twig_constant_accessor:
    classes:
        - AppBundle\Model\Foo
        - { class: 'AppBundle\Model\Bar' }
        - { class: 'AppBundle\Model\FooBar', alias: 'FooBarAlias' }

Avec cette configuration, vous aurez directement accès aux constantes dans vos vues Twig :

{{ Foo.MY_CONSTANT }} {# access AppBundle\Model\Foo::MY_CONSTANT #}
{{ Bar.KEY }}  {# access AppBundle\Model\Bar::KEY #}

{% if 'value' == FooBarAlias.MY_CONSTANT %}Test is OK{% endif %}
{# FooBarAlias is an alias for AppBundle\Model\FooBar #}

Le code, sa complexité et ses performances

Sun, 26 Jun 2016 00:00:00 +0200

Une des choses les plus importantes de la revue de code, c’est de détecter les rapidement les problèmes de conception et d’architecture d’un code qui va être envoyé en production. Cette tâche est délicate, car elle fait appel à la subjectivité du ou des relecteurs. Il faut trouver le “juste milieu” afin d’éviter d’en faire trop ou pas assez. Souvent, le principal argument utilisé pour éviter de découpler du code est que le fait de rajouter une classe va complexifier le code, en plus de dégrader les performances de l’application.

Dans le choix de mise en place d’une architecture, il est important de prendre en compte un certain nombre d’aspects techniques, organisationnels et métier. Il y a néanmoins des principes de base qui devraient (à mon sens) être systématiquement appliqués et cela, peu importe le type de l’application développée. En respectant certaines règles élémentaires, on facilitera l’écriture d’un code simple, évolutif, maintenable et scalable.

Le premier principe fondamental est d’avoir une séparation entre l’aspect technique d’un code et son aspect business. Très schématiquement, il s’agit de séparer l’objectif métier du code des détails de son implémentation technique. Par exemple, dans le cadre d’un site d’e-commerce, un des besoins métier est de gérer le panier afin de pouvoir y ajouter, modifier, enlever des produits que l’on souhaite acheter ou non. L’aspect technique est de gérer la manière dont ces informations vont être “enregistrées” (en session, en base de données…). Il est donc important que le code sépare ces deux notions pour limiter les impacts d’une éventuelle modification.

C’est un bon début, mais cela ne suffit pas. Il faut également découper l’aspect technique en plusieurs responsabilités. Ici, il convient d’avoir des briques logicielles qui ne font qu’une seule chose, qui ne remplissent qu’un objectif (récupérer de la donnée, générer des affichages, produire des logs, faire des traitements métiers, etc.). Se retrouver avec du code qui mixe ces concepts est une erreur. En plus de lier des notions sans rapport entre elles, cela risque de rendre votre code difficilement testable.

Les règles qui ont été présentées jusqu’ici sont d’autant plus vraies, qu’elles peuvent s’appliquer à n’importe quel langage et pour n’importe quel type d’application. Si vous avez du code qui ne les respecte pas, vous avez certainement une forte dette technique.

J’entends souvent (même venant de développeurs expérimentés) que découper son code en plusieurs responsabilités n’apporte pas de valeur, complexifie le code et dégrade les performances de l’application.

Ajouter du code peut effectivement complexifier la compréhension d’un programme. Mais, ajouter du code structuré en classe et découpé en différentes méthodes (correctement nommées), vise bien au contraire à améliorer la compréhension de ce dernier. De plus, cela n’a que peu d’impact sur les performances d’exécution. En réalité, ce n’est pas le découpage du code qui nuit aux performances d’une application, mais la manière dont ce dernier est écrit.

Il faut bien se rendre compte qu’à code équivalent, même avec un découpage en plusieurs classes, les performances seront équivalentes (les langages modernes sont pour la plupart dotés de mécanismes d’optimisation et de mise en cache).

Pourquoi les développeurs n'aiment pas Behat ?

Mon, 11 Apr 2016 00:00:00 +0200

Depuis sa mise à disposition, Behat est un outil plutôt controversé de la part des développeurs. Il y a ceux qui l’aiment et ne peuvent s’en passer (c’est mon cas) et ceux qui bien au contraire le détestent. Pourtant Behat est un outil formidable qui permet de faire le lien entre les tests d’acceptations et l’application que l’on est en train de concevoir. Tout cela de manière automatisée. Dit autrement, il va permettre de valider qu’une demande exprimée en langage métier donne le résultat attendu. Pourtant, je rencontre très souvent des développeurs qui ne supportent pas cet outil. J’ai tenté de comprendre pourquoi.

Avant de tenter de répondre à cette question, je pense qu’il est nécessaire de comprendre comment fonctionne l’outil. Comme évoqué précédemment, un des plus grands intérêts de Behat est que l’on va exprimer le test en langue naturelle (peu importe la langue utilisée). Le format d’écriture ressemble beaucoup à l’expression d’une user-story utilisé dans la méthode SCRUM.

Voici par exemple un exemple de scénario :

# language: fr
Fonctionnalité: Avoir un compte bancaire
    Afin d'offrir aux utilisateurs la possibilité d'avoir un compte bancaire
    Etant donné que je suis inscrit
    Je dois être capable d'ajouter ou de retirer de l'argent sur mon compte

    Scénario:
        Etant donné que je suis un utilisateur connecté
        Et que j'ai un compte bancaire
        Et que le solde de mon compte est de "10" euros
        Quand j'ajoute "5" euros sur mon compte
        Alors mon solde doit être de "15" euros

Lorsque l’on écrit nos tests Behat, nous commençons par décrire la fonctionnalité de manière générale puis on décrit un ensemble de cas d’utilisation. Ces derniers vont alors définir un contexte d’exécution, une série d’événements et terminer par le résultat attendu.

Les scénarios Behat peuvent ensuite être exécutés dans un ou plusieurs environnements. Par exemple, dans le cas d’un site Web, il est tout à fait envisageable d’exécuter le scénario dans différents navigateurs pour valider que le fonctionnement de l’application est correct aussi bien sur Firefox que Chrome ou Internet Explorer.

Une fois les scénarios écrits, il faudra alors que le développeur fasse le lien entre les étapes des différents scénarios et les actions qui en résultent dans l’application. Heureusement, Behat nous aide dans cette tâche en prégénérant le squelette du code correspondant.

Avec ce que nous venons dire, ne trouvez-vous pas que Behat est un outil extrêmement intéressant ? Il nous permet :

De valider notre compréhension du besoin client
De valider que notre application réponde correctement à ce dernier
De documenter notre application et fournit un esemble de spécifications

Alors pourquoi un développeur peut ne pas aimer Behat ?

Comme l’explique son auteur. Avec Behat, un développeur ne teste pas son application, mais il s’assure que son application réponde aux besoins métiers de son client. Beaucoup d’applications répondent aux attentes des développeurs, mais peuvent ne pas couvrir les besoins métiers.

Toujours d’après son auteur, Behat permet en réalité d’apprendre au développeur comment fonctionne le métier du client.

Je pense que si beaucoup de développeurs n’aiment pas Behat c’est à cause de ce dernier point. Ecrire des bons scénarios Behat est un travail délicat. Il faut exprimer le métier du client et non pas le fonctionnement de l’application.

Un développeur aura facilement tendance à écrire ce genre de scénario :

# language: en
Scenario: Showing delivery cost for a product on the basket page
  Given there is a product:
    | name  | White Marker |
    | price | £5           |
  And I am on the "/catalogue" page
  When I click "Buy" in the "White Marker" product block
  And I go to the "/basket" page
  Then I should see a list with 1 product
  And the overall price should be shown as £9

Alors que le scénario exprimé du point de vue du client devrait ressembler à :

# language: en
Scenario: Getting the delivery cost for a single product under £10
  Given a product named "White Marker" and priced £5 was added to the catalogue
  When I add the "White Marker" product from the catalogue to the picked up basket
  Then the overall basket price should be £9

Mais adopter ce point de vue n’est pas évident pour un développeur, qui a souvent plus une vision technique que fonctionnelle de l’application. Cela demande donc un véritable effort de réflexion, en plus de devoir écrire le code correspondant aux différents scénarios.

Je reste donc persuader que si de nombreux développeurs n’aiment pas Behat, c’est essentiellement à cause de leur culture technique et qu’il est difficile pour eux de faire un volte-face pour se mettre à la place du client.

Il se peut aussi que comme j’avais tenté de l’expliquer dans un précédent billet, que les développeurs vont tenter de se lancer directement dans l’écrire de leurs scénarios Behat, sans prendre le temps de comprendre les outils qu’ils utilisent et la manière de le configurer correctement.

Ressources :

Mon environnement PhpStorm

Wed, 17 Feb 2016 00:00:00 +0100

Comme de nombreux développeurs PHP, j’utilise au quotidien l’excellent IDE développé par Jetbrains, j’ai nommé PhpStorm. Au-delà des nombreuses fonctionnalités fournies nativement par l’IDE, il est possible d’ajouter des modules complémentaires au travers des nombreux plugins disponibles.

Dans ce billet, je vais présenter les principaux modules que j’utilise.

##PHP Annotation

PHP Annotation est un module qui comme son nom l’indique très bien permet de gérer les annotations dans l’IDE. C’est notamment grâce à cette extension qu’il sera possible de naviguer dans les annotations, d’obtenir de l’autocomplétion lors de l’implémentation de ces dernières, etc.

##Symfony

Je développe essentiellement en utilisant le framework Symfony. Cette extension permet ainsi d’obtenir un support complet du framework dans l’IDE.

##Atoum

Il m’est impossible de développer sans écrire de tests (et j’espère que vous aussi). Pour écrire mes tests unitaires, j’utilise Atoum aussi personnellement que professionnellement. Ce plugin créé tout récemment permet de faciliter la navigation dans mes tests, mais également de lancer simplement ces derniers directement dans l’IDE.

##PHP composer.json

Il est aujourd’hui devenu impossible de travailler en PHP sans utiliser Composer, le gestionnaire de dépendance pour le langage. Cette extension, permet d’avoir l’autocomplétion lors de l’édition du fichier de définition des dépendances, mais permet également de consulter les versions des dépendances installées.

##PHP Inspection EA

PHP Inspection EA est l’un des derniers modules que j’ai découvert, mais il commence à devenir indispensable. Effectivement, ce dernier permet d’effectuer des analyses de codes statiques en complément de celles effectuées nativement par l’IDE. Extrêmement pratique pour améliorer son code !

Mon retour du DDD Day 2016 à Lyon

Mon, 08 Feb 2016 00:00:00 +0100

Le DDD-Day est une journée de conférence visant à sensibiliser les développeurs PHP au DDD (le Domain-Driven Design), démystifier son utilisation et les patterns qui y sont rattachés. J’ai ainsi eu l’occasion d’assister à la première édition de cette journée qui s’est déroulée le 30 janvier 2016 à Lyon.

Le #dddday c'est maintenant ! pic.twitter.com/VJOesVWTFi
— Jérémy DECOOL (@jdecool) 30 Janvier 2016

Avant de faire un retour rapide sur la journée, je tenais à remercier une nouvelle fois tous ceux grâce à qui cette journée n’aurait pu avoir lieu : l’AFUP, KnpLabs, l’atelier des médias, Amabla et Vanoix.

La journée de conférence a été filmée et sera prochainement disponible sur la chaîne Youtube de OpenTalk.

Pourquoi le DDD ne devrait rien changer à votre vie ?

Alexandre Balmes - Slides - Vidéo

Cette journée commence par une présentation du Domain-Driven Design, pourquoi et quand l’utiliser. Derrière cette présentation Alexandre nous explique les bases du DDD et tente de nous montrer que malgré quelques termes “barbares”, il n’y a rien de sorcier derrière cet acronyme. Ce n’est au fond que du bon sens et peut s’intégrer dans tout environnement projet, surtout avec les outils qui sont à notre disposition en PHP aujourd’hui.

Get Off My Domain !

Matthieu NAPOLI - Slides - Vidéo

Après l’introduction faite par Alexandre, Matthieu rentre un peu plus dans les détails techniques d’une application DDD. Il va alors nous présenter les design-patterns essentiels qui doivent être utilisés dans nos applications. C’était l’occasion de revoir les notions de : Entity, Value Object, Domain Service, Repository (au sens premier du pattern), Aggregate et de Domain Event.

Ne laissez pas les formulaires Symfony influencer votre modèle

Jérémy BARTHE - Slides - Vidéo

En France, nous sommes très nombreux à utiliser le framework PHP Symfony. D’ailleurs l’ensemble des personnes présentes développaient leurs applications en utilisant ce dernier. Partant de ce constat, Jérémy nous a fait une présentation technique sur l’utilisation des formulaires en Symfony. L’objectif de sa présentation était de nous permettre de garder nos formulaires les plus simples possible tout en gardant en tête les fondamentaux du DDD : l’utilisation des Value Object et de l’Ubiquitous Language.

Soyez spécifiques

Kévin GOMEZ - Slides - Vidéo

Kévin nous a fait une présentation sur l’expression des règles métiers dans nos applications et la manière de les rendre réutilisables. Pour réussir cette tâche, il nous présente le pattern Specification et une implémentation de ce pattern qu’il a écrit dans sa librairie RulerZ. Avec RulerZ, il est alors possible via un DSL (Domain Specific Language), une règle métier qui peut ensuite être passée de manière complètement transparente à un QueryBuilder de Doctrine ou une Query ElasticSearch.

CQRS : Quand les Représentations ne sont pas symétriques

Guillaume ROSSIGNOL - Vidéo

CQRS (Command Query Responsibility Segregation) est un pattern applicatif qui repose sur un principe simple : la séparation, au sein d’une application, des composants de traitement de lecture et d’écriture. Cette présentation nous a fait un retour d’expérience sur la “migration” d’une application legacy vers une architecture orientée DDD et CQRS.

J’ai trouvé ce retour d’expérience intéressant vis-à-vis du choix que l’équipe a effectué. Effectivement, l’essentiel des problèmes rencontrés se trouvant côté “front”, l’équipe a fait le choix de garder l’application legacy en fonctionnement (correspondant à la logique d’écriture) et de démarrer une nouvelle application qui ne sert qu’à présenter les informations enregistrées par le back-office (la partie legacy).

Tour de table

Pascal MARTIN

Pour terminer cette journée, nous avons eu le droit à une table ronde animée par Pascal qui a permis à chaque membre de répondre aux questions restées en suspens lors des présentations.

Ce fut également un moment d’échange pour permettre aux organisateurs d’avoir le ressenti de chacun sur cette première édition du DDD Day.

Encore une fois merci à toutes les personnes qui ont rendu cette journée possible : les membres de l’organisation, les conférenciers ainsi qu’à tous les participants à cette journée. Ce fut une journée riche en information, mais cela fait également plaisir de revoir les personnes qui font bouger l’écosystème PHP à Lyon.

Merci à tous !

Très bonne journée au #dddday ! Merci à tous @pockystar @vanoix @AFUP_lyon pour l'orga et à tous les speakers.
— Jérémy DECOOL (@jdecool) 30 Janvier 2016

Définition d'un Value Object (objet-valeur)

Mon, 01 Feb 2016 00:00:00 +0100

J’ai déjà parlé plusieurs fois des Value-Object (ou Objet-Valeur en français), que ce soit pour tenter de les définir ou pour donner un cas d’utilisation, mais sans jamais en donner une définition simple.

J’ai eu l’occasion d’assister au DDD Day à Lyon qui a eu lieu le 30 janvier dernier. Il s’agissait d’une série de conférences avec pour objectif de démystifier l’utilisation du DDD en PHP.

Lors de cette journée, Matthieu NAPOLI a donné une définition des Value-Object que j’ai beaucoup appréciée car elle est à la fois simple et permet de bien comprendre ce que représente ce concept :

On peut définir un Value-Object comme étant un “wrapper” d’un type primitif ou complexe, auquel on va pouvoir ajouter des règles métiers.

Comment extraire un répertoire Git dans un autre dépôt ?

Mon, 11 Jan 2016 00:00:00 +0100

Lorsque l’on développe, nous sommes amenés à créer divers composants techniques et/ou fonctionnels afin de découper notre architecture applicative. Parfois, ces composants peuvent être utiles dans d’autres bases de code et il est alors intéressant de les extraire afin de pouvoir les réutiliser plus facilement.

Il est alors possible de créer un nouveau dépôt et de copier le ou les dossiers contenant le code du composant en question. Néanmoins, cette méthode simple présente un énorme inconvénient : le journal de commit. Effectivement, en effectuant une simple copie des fichiers, nous perdons l’historique des commits Git et donc l’historique du composant.

Heureusement Git possède tous les outils nous permettant de réaliser cette opération d’extraction tout en conservant notre historique de travail avec la commande filter-branch.

Note: pour les utilisateurs faisant ces opérations sous Windows, il est important de noter qu'il faut utiliser le séparateur *nix ('/') pour les dossiers. Sans quoi les commandes ne seront pas exécutées avec succès.

La commande filter-branch permet de réécrire l’historique Git en appliquant des filtres personnalisés. Les filtres peuvent permettre la réécrire des commits, des branches (en incluant les informations de merge), …

Pour extraire notre composant, nous allons commencer par cloner le dépôt dans le répertoire qui contiendra notre composant :

git clone –no-hardlinks /path/to/project /path/to/component

Puis nous allons extraire les fichiers du dossier qui nous intéresse :

cd /path/to/component
git filter-branch --prune-empty --subdirectory-filter src/path/component

Et voilà, notre nouveau dépôt ne contient que les fichiers que nous souhaitions extraire. Il ne reste plus qu’à supprimer définir le nouveau remote de notre composant :

git remote remove origin
git remote add origin url/to/new/remote

Le problème n+1

Thu, 17 Dec 2015 00:00:00 +0100

Si vous êtes développeur et que vous travaillez régulièrement avec une base de données, vous avez très certainement déjà été confronté à des problèmes de performance liés à des relations de type parent/enfant. L’anti-pattern que l’on retrouve le plus fréquemment consiste à exécuter une requête pour obtenir la relation parente puis à récupérer les enfants un à un. C’est un cas qui se produit souvent lorsque l’on travaille avec des ORM. On parle alors du problème N+1 (“N+1 problem” en anglais).

Prenons un exemple concret : une base de données permettant de répertorier des auteurs de livres ainsi que les livres écrits par ces derniers. Nous souhaitons récupérer la liste des auteurs avec les livres qu’ils ont écrits. Le code permettant d’afficher ce résultat pourrait ressembler à cela :

// ...
$authors = $pdo->query('SELECT * FROM author')->fetch();
foreach ($author as $authors) {
    $books = $pdo->query('SELECT * FROM book WHERE author_id = '.$author['id']);
    // ...
}

Avec le code ci-dessous, on constate que les performances de l’application vont se dégrader de manière exponentielle au fur et à mesure que l’on va renseigner des auteurs et ajouter des livres. Dans le cas présent, l’on récupère 10 auteurs, 11 requêtes vont être exécutées pour récupérer l’ensemble des informations voulues (1 pour récupérer les 10 auteurs, puis 10 pour récupérer les livres de chacun des auteurs).

Cela vous paraît aberrant ? Vous ne pensez ne jamais écrire un code comme cela ? Prenons le même exemple en utilisant un ORM (Doctrine par exemple).

class Author
{
    /**
     * @Id
     * @Column(name="id", type="int")
     */
    private $id;

    /**
     * @OneToMany(targetEntity="Book", mappedBy="author")
     */
    private $books;

    // ...
}

class Book
{
    /**
     * @Id
     * @Column(name="id", type="int")
     */
    private $id;

    /**
     * @ManyToOne(targetEntity="Author")
     */
    private $author;

    // ...
}


$authors = $entityManager->getRepository('Author')->findAll();
foreach ($author as $authors) {
    $books = $author->getBooks();
    // ...
}

Vous pensez peut-être que cette solution est plus performante. Pourtant le code ci-dessus se comporte exactement de la même façon que le précédent. Par défaut Doctrine (comme de nombreux ORM) génère des classes Proxy afin de ne récupérer les relations enfant que lorsqu’elles sont demandées. Dans ce cas, Doctrine va exécuter une requête à chaque appel de la méthode getBooks pour récupérer les informations correspondantes.

La solution pour éviter cela est bien évidemment d’utiliser des jointures SQL afin de récupérer les informations des auteurs avec les livres qu’ils ont écrit dans la même requête. La modification du premier exemple conduirait à ce code :

// ...
$authors = $pdo->query('SELECT * FROM author JOIN book ON author.id = book.author_id')->fetch();

Les ORM permettent également d’écrire des requêtes en utilisant les jointures afin de récupérer l’ensemble des données voulu. On peut également configurer le mapping des relations pour effectuer une récupération agressive des données (mais cela n’est pas forcément recommandé car il se peut que la récupération des données de la relation ne soit pas toujours utile) :

// utilisation du QueryBuilder de Doctrine pour récupérer l'ensemble des données en une requête
$authors = $entityManager->createQueryBuilder()
    ->select(['a', 'b'])
    ->from('Author', 'a')
    ->join('Book', 'b')
    ->getQuery()
    ->getResult()
;

Qu'est-ce que l'Event Sourcing ?

Tue, 01 Dec 2015 00:00:00 +0100

L’Event Sourcing, voilà un terme que l’on entend de plus en plus souvent. Décrit, il y a maintenant une dizaine d’années, ce concept commence maintenant à arriver dans nos architectures PHP. Mais, de quoi s’agit-il ? Derrière l’Event Sourcing se cache un mécanisme simple qui consiste à sauvegarder chaque événement déclenché dans une application.

Lorsque l’on accède et navigue au sein d’une application, en réalité nous accédons à un état donné de cette dernière. En effectuant certaines actions, nous pouvons par exemple modifier l’état du programme (en modifier les données qui sont gérées par ce dernier). La plupart du temps, les actions effectuées par l’utilisateur vont directement altérer les informations contenues dans la base de données. De ce fait, la base de données est une copie du dernier état de notre application.

Avec l’Event Sourcing, nous allons stocker chacun des événements qui vont déclencher la modification des données contenues en bases. L’objectif d’un tel mécanisme est de s’assurer que tous les changements d’états sont stockés comme une séquence d’événements. Il devient alors possible d’interroger n’importe quel événement qui s’est produit et d’en déduit l’état de l’application à n’importe quel moment de sa vie. Cela peut être considéré comme un journal d’événements. C’est d’ailleurs en parcourant ce dernier, que l’on reconstruit l’état actuel de l’application (pour nos utilisateurs).

Avec ce type de méthodologie, il est donc primordial que les événements soient des éléments immuables et qui ne peuvent donc être ni modifiés, ni supprimés.

Maintenant, vous devez vous demander qui peut bien utiliser une telle architecture ? La réponse la plus évidente est sans doute les systèmes de gestion de sources et du versionnement. Mais cette méthode de développement ne s’arrête pas à ces seuls outils. Des applications Web sont également conçues selon cette méthodologie. C’est notamment le cas de certaines applications internes développées chez ERDF ou encore chez BlaBlaCar.

Si vous souhaitez en savoir plus, je ne peux que vous conseillez de lire l’excellent billet de Martin Fowler très complet sur le sujet.

Trait ou héritage, il faut choisir

Sat, 28 Nov 2015 00:00:00 +0100

C’est avec la version 5.4.0 que les Traits sont apparus en PHP. Il s’agit d’un mécanisme de réutilisation de code, introduit dans le but de réduire certaines limites de l’héritage simple. Je constate que de plus en plus de développeurs se mettent à utiliser les Traits à tel point que ces certains n’utilise même plus l’héritage et préfère avoir recours à ce mécanisme. Que se soit avant de faire un héritage ou avant d’utiliser un trait, il convient de se poser la question de quand utiliser l’un ou l’autre ?

Revenons rapidement sur ce qu’est un héritage. L’héritage permet d’établir une relation (de type parent/enfant) entre des classes. Lorsque l’on étend une classe, la classe fille hérite alors de toutes les méthodes publiques et protégées de la classe parente. Il est également possible que la classe fille redéfinisse certaines de ces méthodes pour les adapter à ces spécificités.

Les traits quand à eux ont comme seul objectif de partager du code entre classes sans structuration hiérarchique. Il n’y a donc ici pas de relation entre les classes qui utilisent les traits. Il partage seulement un comportement.

Il faut bien avoir cette distinction lorsque vous écrivez du code. Voici par exemple, du code que j’ai pu voir récemment sur un projet :

trait RepositoryTrait
{
    public function find($id)
    { /* ... */ }

    // ...
}

class UserRepository
{
    use RepositoryTrait;

    // ...
}

class GroupRepository
{
    use RepositoryTrait;

    // ...
}

Il faut faire attention à l’utilisation des traits car ces derniers peuvent facilement casser les aspects classiques de la programmation objet. Dans ce bout de code, les classes UserRepository et GroupRepository n’implémente pas d’interface commune, elle utilise un trait. De ce fait, le principe de programmation SOLID peut facilement être rompu.

Dans ce cas-là, un héritage semble plus adapté :

abstract class Repository
{
    public function find($id)
    { /* ... */ }

    // ...
}

class UserRepository extends Repository
{
    use RepositoryTrait;

    // ...
}

class GroupRepository extends Repository
{
    use RepositoryTrait;

    // ...
}

De plus en utilisant un héritage, il est plus facile de faire du typage explicite. Il est alors possible de vérifier que la classe fournit en paramètre est bien de type Repository, ce qui n’est pas possible avec un trait. De plus il sera plus facile de respecter le principe de substitution de Liskov.

Il est préférable d’utiliser les traits pour partager du code avec des classes qui n’ont pas de lien entre elles. Prenons comme exemple :

trait TextFormater
{
    public function sanitize($text)
    {
        return strip_tags($text);
    }
}

class Mailer
{
    use TextFormater;

    public function send($subject, $text)
    {
        mail('user@mail.com', $this->sanitize($subject), $this->sanitize($text));
    }
}

class ConsoleWriter
{
    use TextFormater;

    public function write($text)
    {
        echo $this->sanitize($text), PHP_EOL;
    }
}

Dans l’exemple précédent, la classe Mailer a pour but d’envoyer un mail à un utilisateur et la classe Writer de générer un affichage à l’écran. Ces deux classes n’ont aucun rapport et pourtant elles ont toutes les deux besoins de traiter du texte fourni en paramètre. L’héritage n’a ici pas sa place et il convient donc de partager le code via l’utilisation d’un trait.

Un autre exemple concret de l’utilisation des traits est l’implémentation du pattern Singleton. Lorsque l’on souhaite utiliser ce dernier, le premier réflexe pourrait être de créer une classe Singleton et de faire hériter nos objets de cette dernière. Mais ce n’est pas toujours possible à cause de l’impossibilité de faire de l’héritage multiple. Partant du principe qu’il est préférable de favoriser un héritage “fonctionnel”, il convient dans ce cas-là, d’avoir recours aux traits pour résoudre le problème :

trait Singleton
{
    protected static $instance = null;

    public static function getInstance()
    {
        if (null === $this->instance) {
            $this->instance = new self;
        }

        return $this->instance;
    }
}

class Example extends Article
{
    use Singleton;
}

$expl = Example::getInstance();

Héritage et Trait, les deux concepts ont leur place dans nos projets, utilisons-les à bon escient et au bon moment.

Support complet de Gitlab dans Composer

Wed, 25 Nov 2015 00:00:00 +0100

Inutile de vous présenter Composer l’outil de gestion des dépendances massivement utilisé par les développeurs PHP. Voici un court billet pour vous annoncer que ce dernier intègre désormais le support complet de Gitlab.

L’issue Github datée du 26 août 2014 et demandée le support de l’API Gitlab pour la gestion des dépendances (avec notamment la gestion des droits).

C’est désormais chose faite, un an et demi après, Composer fournit maintenant un driver Gitlab.

Pour l’utiliser dans votre projet, il vous suffira de configurer votre fichier composer.json avec les éléments suivants :

{
    "repositories": [
        { "type": "gitlab", "url": "http://gitlab.mysrv.com/path/to/my_project" }
    ],
    "config": {
        "gitlab-domains": ["gitlab.mysrv.com"]
    },
    "require": {
        "vendor/my-project": "~1.0"
    }
}

Les patterns "Builder" et "Factory": même combat

Mon, 16 Nov 2015 00:00:00 +0100

Aujourd’hui, j’ai envie de vous parler des patterns “Builder” et “Factory”. S’il y en a un qui est bien connu des développeurs, on ne fait pas toujours la distinction entre ces deux patterns qui ont un objectif similaire: la création de nouveaux objets.

La factory (ou fabrique en français) est un patron de conception qui permet de créer un objet sans avoir à connaître la classe exacte de l’objet retourné. Ce dernier est alors construit en une seule étape. Exemple :

class DatabaseConnectionFactory
{
    private $dbParams;

    public function __construct(array $params)
    {
        $this->dbParams = $params;
    }

    public function create($type)
    {
        switch ($type) {
            case 'mysql':
                return new MysqlDatabaseConnection($this->dbParams);

            case 'pgsql':
                $conn = new PgsqlDatabaseConnection();
                $conn->setParams($this->dbParams);

                return $conn;

            default:
                throw new \InvalidArgumentException();
        }
    }
}

Le pattern builder quand à lui se focalise sur la construction d’objets plus complexes qui ne peuvent être créés en une seule étape. Il est parfois nécessaire que la création d’un objet nécessite plusieurs étapes. C’est alors que les objets de type builder sont utilisés. Exemple :

class WebserviceClientBuilder
{
    private $serviceUrl;

    public function __construct($url)
    {
        $this->serviceUrl = $url;
    }

    public function build()
    {
        $clientStrategyFactory = new clientStrategyFactory();
        $client = $clientStrategyFactory->create($this->serviceUrl);

        return new WebserviceClient($client);
    }
}

L’exemple ci-dessus est très simple, mais on voit bien que la création d’un client pour utiliser le web service nécessite la création de deux objets : le premier permettant de définir la stratégie à adopter pour accéder à ce dernier et le second est le client à proprement parlé.

Il existe également d’autres patrons de conception permettant de créer des objets, mais ces derniers étant moins utilisé (donc certains que je n’ai jamais pratiqués), je n’en parlerai pas. Je vous invite notamment à découvrir les patterns Object pool et Prototype.

Les commandes Git (trop) souvent ignorées

Mon, 26 Oct 2015 00:00:00 +0100

S’il y a bien un outil de gestion de sources qui a gagné la bataille, on ne peut citer que Git. Cet outil pratique et extrêmement puissant a été largement adopté par les développeurs. À tel point que c’est devenu l’outil de référence pour la gestion des versions décentralisées. Nous allons voir dans cet article quelques fonctionnalités bien pratiques mais qui sont bien trop souvent ignorées par les développeurs.

git cherry-pick

La commande cherry-pick permet d’appliquer des changements effectués au sein d’un autre commit. Lorsque l’on travaille, il est fréquent d’utiliser des branches pour le développement des différentes fonctionnalités à implémenter. Il peut parfois être utile de récupérer une partie du travail d’un autre développeur sans devoir récupérer l’ensemble de sa branche.

git cherry-pick d42c389f

git bisect

Le git bisect est certainement l’une des commandes que j’affectionne le plus. Pourtant je ne l’ai presque jamais vu utilisé dans mes différentes expériences professionnelles.

Cette commande permet pourtant de faciliter grandement la correction d’un bug de votre application en se chargeant de trouver le commit ayant introduit ce dernier. Il s’agit d’une commande redoutable surtout lorsqu’elle est couplée avec un outil de tests automatisés (c’est pratique mais pas obligatoire).

Son utilisation peut sembler complexe au premier abord, c’est peut-être ce qui freine son utilisation, mais pourtant une fois familiarisé avec cette dernière, vous ne pourrez plus vous en passer.

git rebase

Je pense que tout le monde connaît la commande rebase, mais on ne sait jamais réellement ce qu’il y a derrière. Nous utilisons en général le merge beaucoup plus que nous ne devrions. Certainement parce que ces deux commandes permettent d’intégrer les modifications d’une branche dans une autre. J’ai moi-même mis beaucoup de temps pour bien comprendre la différence.

De manière générale, je vois le rebasage utilisé pour fusionner des commits au sein d’une même branche. Le développeur a utilisé le commit pour sauvegarder son travail à un instant T et souhaite une fois terminé, fusionner et regrouper tous les commits correspondant à la même tâche.

Le fonctionnement du rebase est simple. Cette commande permet de rejouer une série de commits à partir d’une nouvelle base de travail.

Des collègues ont rencontré le problème très récemment. Une fonctionnalité avait été développée sur une branche qui a ensuite été laissée de côté pendant un certain laps de temps. La branche principale ayant elle évolué pendant ce temps, lorsqu’ils ont ensuite tenté de fusionner cette branche dans le master, ils ont constaté que certaines portions de code avaient été écrasées.

Ce fonctionnement peut sembler déroutant pourtant il est tout à fait logique. La branche où avait été développée la fonctionnalité avait pour point de départ une version obsolète de la branche principale. Lorsque Git a effectué sa fusion, il a réintégré les modifications en tenant compte des changements les plus récents.

Ce problème aurait pu être évité, si un rebase avait été fait avant le merge. Cette opération ayant pour effet de remettre le point de départ de la branche à une version récente et à jour du master.

git checkout ma-branche-ancienne
git rebase master

Faire de la veille techno

Wed, 21 Oct 2015 00:00:00 +0200

La veille technologique est très importante dans notre métier qui est en constante évolution. Thibault JOUANNIC a d’ailleurs eu l’occasion de donner une conférence à ce sujet. Conférence dont il a fait une retranscription dans un article de blog.

Le billet en résultant est très intéressant, et si vous ne l’avez pas encore fait, je vous recommande de le lire.

Néanmoins dans son article, il y a un passage qui m’a interpelé :

“Je pense que la manière la plus efficace de se maintenir à jour, ce n’est pas de tester une techno directement, par exemple sur un projet perso, c’est d’aller chercher des retours d’expérience.”

Bien que l’article ne s’attache pas à cette unique pratique, je pense que même si l’on a peu de temps, il est important de ne pas uniquement se limiter à cela. Ne serait-ce parce que si tout le monde fonctionne de la sorte, il n’y aurait alors plus personne pour tester ou mettre en place de nouvelles techniques au sein des projets actuels.

De plus, il faut bien faire attention à ces retours d’expérience, les nouvelles technos sont souvent portées par de grosses sociétés. Mais tout le monde n’est pas Google ou Facebook, et 90% des sociétés ne font pas face aux mêmes contraintes ou problématiques.

Lorsque l’on fait de la veille techno, il faut tester ce qui nous intéresse, regarder les retours d’expérience et mettre tout cela en parallèle avec notre environnement et les contraintes auxquelles nous sommes liés tous les jours. Il est aussi important de se faire sa propre idée et ne pas forcément tout le temps suivre les autres.

Gérer du multithread en PHP avec pthreads

Mon, 12 Oct 2015 00:00:00 +0200

PHP est par “défaut” un langage mono-thread et ne permet donc, par définition, de ne gérer qu’un seul processus à la fois. Or il peut s’avérer extrêmement avantageux de gérer plusieurs processus afin d’effectuer un certain nombre de tâches en parallèle. Il existe heureusement une extension PECL pour faire cela : pthreads.

« pthreads est une API orientée objet qui permet le multi-threading en PHP. Il inclut tous les outils nécessaires pour créer des applications multi-threadées pour le Web ou pour la console. Les applications PHP peuvent créer, lire, écrire, exécuter et synchroniser des Threads, des Workers, et des objets Threaded. »

Tout cela de manière très simple. La seule contrainte est que l’extension se base sur les threads POSIX et nécessitera donc l’installation du projet pthreads-win32 pour pouvoir fonctionner sous Windows.

Voici un exemple très simple de l’utilisation de l’extension :

<?php
$thread = new class extends Thread {
    public function run() {
        echo "Hello World\n";
    }
};

$thread->start() && $thread->join();
?>

J’ai par ailleurs publié une image Docker permettant d’exécuter PHP 7.0 préconfiguré avec l’extension pthreads. Tout cela est disponible sur le Docker Hub .

Exporter un fichier CSV avec Symfony2

Fri, 09 Oct 2015 00:00:00 +0200

Lorsque l’on travaille sur des applications de gestion, il est fréquent de devoir exporter des fichiers de données dans divers formats. Le plus simple des formats étant le CSV.

La plupart du temps, l’export passe par la génération d’un fichier temporaire qui est ensuite envoyé à l’utilisateur au travers d’un téléchargement de fichier via le navigateur. Pourtant Symfony2 fournit des outils permettant d’éviter de manipuler directement les fichiers temporaires via les StreamedResponse et les flux PHP.

La classe StreamedResponse permet de retourner un flux de réponse au client. Le contenu de la réponse est représenté par une fonction PHP au lieu d’une chaine de caractère :

public function generateCsvAction() {
    $repository = $this->get('app.repository.user');

    $response = new StreamedResponse();
    $response->setCallback(function() use ($repository) {
        $handle = fopen('php://output', 'w+');

        fputcsv($handle, ['Firstname', 'Lastname', 'Birthday'], ';');

        $results = $repository->findActiveUsers();
        foreach ($results as $user) {
            fputcsv(
                $handle,
                [$user->getFirstname(), $user->getLastname(), $user->getBirthday()],
                ';'
             );
        }

        fclose($handle);
    });

    $response->setStatusCode(200);
    $response->headers->set('Content-Type', 'text/csv; charset=utf-8');
    $response->headers->set('Content-Disposition','attachment; filename="export-users.csv"');

    return $response;
}

Objets-Valeurs et immutabilité

Tue, 21 Jul 2015 00:00:00 +0200

J’ai déjà parlé plusieurs fois des Objets-Valeurs (Value Objects) et quand les utiliser, mais je n’ai encore jamais évoqué le concept d’immutabilité qui en est indissociable.

Un objet immutable possède un état qui ne peut pas changer au cours du temps. Pourquoi est-il aussi important qu’un objet-valeurs ne puisse changer ? Les objets-valeurs ont pour objectif de représenter une donnée à un instant T. Ce qui a de la valeur pour un tel objet est son état. De ce fait, si l’état de notre objet change, il ne peut être représenté par une même instance (contrairement à un objet de type Entité) puisque c’est l’état de notre objet qui détermine son identité.

Prenons un exemple concret. Si dans un modèle objet, nous souhaitons représenter une couleur par un Objet-Valeurs, il est logique que ce dernier soit immutable. L’état caractèristique de l’objet et la couleur qui lui est associé, si cette dernière change, elle ne peut être associé à la même instance et il devra s’agir d’un nouvel objet.

Cela veut également dire que s’il est possible d’effectuer des opérations sur notre Objet-Valeurs, le résultat provoquera la création d’un nouvel Objet-Valeurs. Reprenons l’exemple de notre objet Money :

class Money
{
  /** @var int */
  private $amount;

  /** @var string */
  private $currency;

  /**
   * @param int    $amount
   * @param string $currency
   */
  public function __construct($amount, $currency)
  {
    $this->amount   = $amount;
    $this->currency = $currency;
  }

  /**
   * @return int
   */
  public function getAmount()
  {
    return $this->amount;
  }

  /**
   * @return float
   */
  public function getFormatedAmount()
  {
    return round($this->amount / 100, 2);
  }
}

Nous souhaitons ajouter la possibilité d’additionner deux objets de types Money. Pour cela nous ajoutons le code suivant :

class Money
{
  // ...

  /**
   * @param Money $money
   * @return static
   */
  public function add(Money $money)
  {
    // check same currency

    $value = $this->amount + $money->getAmoun();

    return new static($value, $this->currency);
  }
}

Le code ci-dessus permet d’ajouter deux objets Money et l’objet qui en résulte est un nouvel objet-valeurs. Il est ainsi possible d’ajouter des comportements à ces derniers tout en conservant le principe d’immutabilité.

Ecrire des logs manipulables

Wed, 15 Jul 2015 00:00:00 +0200

La notion de logs (ou journaux en français) est primordiale en développement. Ce sont eux qui permettent de faire remonter les informations générées par l’application une application. Ces derniers peuvent se présenter sous différentes formes : fichiers, base de données, sortie écran… Mais comment est-il possible de traiter ces différents retours facilement ?

Les données recueillies par les fichiers de logs informent des diverses situations rencontrées lors de l’exécution du code. Cela peut être des cas inattendus (exceptions), des erreurs, des informations sur les actions effectuées par les utilisateurs. Ils permettent aux développeurs de retracer l’exécution d’un bout de code. Les fichiers alors générés peuvent contenir un grand nombre d’informations et les analyser peut s’avérer être une tâche longue et complexe.

Bien entendu les informations écrites dans les fichiers de logs sont dépendantes de la phase de vie du projet. Il est ainsi fort probable que pendant la phase de développement, une grande quantité d’informations soient enregistrées afin d’avoir un maximum de détails. Par contre, une fois en production, le niveau de log sera réduit à son minimum afin d’avoir les informations essentielles.

De ce fait, une analyse automatique des logs s’avère très intéressante et peut révéler de nombreuses informations. Mais comment écrire des logs qui puissent être facilement traités et analysés par une machine ?

Pour cela, je vais m’appuyer sur les PSR (Propose a Standards Recommendation) de PHP et plus particulièrement la PSR-3 qui concerne les bibliothèques de journalisation. Si vous ne connaissez pas les PSR, il s’agit de recommandations validées par le PHP FIG (PHP Framework Interoperability Group) ayant pour objectif d’améliorer l’interopérabilité entre les frameworks PHP.

Pour résumer rapidement, dans PSR-3, on retrouve 8 niveaux de log avec autant de méthodes associées. Par exemple, le niveau DEBUG est associé à la méthode public function debug($message, array $context = array()). On retrouve également une fonction générique public function log($level, $message, array $context = array());

Ce que l’on peut remarquer avec les signatures de ces fonctions, c’est qu’elle ne se limite pas à écrire un message dans un fichier. Elles permettent également de renseigner un contexte d’exécution. Il est donc intéressant lorsque l’on écrit une ligne de log, de fournir des données sur l’état de l’application au moment donné. Par exemple :

$logger->info('User deletion', [
  'userLogged'  => $userLogged->getId(),
  'userDeleted' => $userDeleted->getId(),
]);

Le code ci-dessus génère la ligne suivante :

[2015-06-28 16:11:12] myapp.INFO: User deletion {"userLogged":1234,"userDeleted":7412} []

Cet exemple n’est pas très intéressant, je me limite à fournir les identifiants des utilisateurs concernés par l’action de suppression d’un utilisateur. De plus, si l’utilisateur est physiquement supprimé de la base de données, le fait d’avoir son identifiant est inutile. Il aurait été plus logique de donner les objets à la fonction de log qui les aurait sérialisés pour l’écrire du fichier.

Il est intéressant de noter que la ligne de log générée automatiquement analysée car elle est créée selon un schéma bien défini. Elle peut ainsi être découpée en 5 :

La date d’enregistrement : 2015-06-28 16:11:12
Le niveau de log : myapp.INFO
Le message de log : User deletion
Le contexte d’exécution : {"userLogged":1234,"userDeleted":7412}
Des données additionnels (dont je ne parle pas dans ce billet) : []

Il est donc très facile d’analyser les fichiers de manière automatique. L’analyse peut permettre d’obtenir des informations sur les erreurs rencontrées le plus souvent par l’application, mais également de faire des statistiques sur certaines utilisations de l’application. Ce travail d’analyse peut être réduit à son minimum car ce genre de logs peut être envoyé et analysé par des plateformes de type ELK (Elasticsearch Logstash Kibana).

Notons au passage que cette ligne de log aurait pu être plus difficilement analysable si elle avait été écrite de la manière suivante :

$logger->info(sprintf('User "%d" delete user "%d"',
  $userLogged->getId(),
  $userDeleted->getId()
);
// => [2015-06-28 16:11:12] myapp.INFO: User "1234" delete user "7412" []

Le problème avec cette méthode est que le message de log n’est pas “unique” pour une action donnée. Effectivement, l’action ayant déclenché l’écriture de la ligne est mélangée avec son contexte d’exécution.

Si vous souhaitez en savoir plus sur l’utilisation des fichiers de logs, Grégoire PINEAU, développeur chez SensioLabs a fait une excellente présentation lors du SFLive 2015 sur le sujet.

Lancer des applications desktop avec Docker

Mon, 13 Jul 2015 00:00:00 +0200

C’est un fait, l’utilisation de Docker s’est démocratisée dans notre milieu. Et même si nous n’en sommes qu’au début, il est possible de faire tellement de choses avec les conteneurs. Bien que dans un premier temps, ils étaient principalement utilisés pour faciliter la gestion de la diversité des environnements de développement, nombreux sont ceux qui commencent à l’utiliser pour gérer des déploiements d’applications en production.

On commence également à voir de plus en plus de personnes utiliser Docker pour lancer des applications desktop. Je ne vais pas ici vous expliquer comment le faire, on trouve sur le net de nombreux articles qui vous expliquent cela (notamment celui de Jessie FRAZELLE).

Le principe est simple car il suffit de partager l’environnement X11 de l’hôte avec son conteneur. Cela se réalise en 2 étapes : le partage du dossier de travail de X11 et l’utilisation d’une variable d’environnement indiquant comment accéder au gestionnaire.

docker run [...] -e DISPLAY=unix$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix

Par contre ce que l’on ne dit pas dans les articles, c’est que certains systèmes sont configurés pour empêcher des connexions externes sur votre environnement graphique. Il n’est pas rare alors de se retrouver avec une erreur Unable to initialize GTK+.

Il sera alors nécessaire d’autoriser la connexion d’un système externe via la commande :

xhost +  # pour autoriser toutes les connexions externes
xhost +local:`docker inspect --format='{{ .Config.Hostname }}' $containerId` # pour restreindre à l'utilisation d'un conteneur

Une fois cette configuration effectuée, vous pourrez lancer sans problème votre application graphique dans un conteneur.

Quand utiliser le pattern Value Object ?

Tue, 23 Jun 2015 00:00:00 +0200

Il y a quelques mois, je parlais du pattern Objets-Valeur (ou Value Object en anglais). Dans le billet présentant brièvement ce patron de conception, j’évoquais le fait qu’il est souvent méconnu des développeurs PHP. De ce fait les exemples sont assez rares et il est alors difficile de savoir quand et/ou comment l’utiliser.

Lorsque l’on évoque ce pattern, le principal exemple qui est cité est celui de l’objet Money permettant de gérer la notion d’argent (valeur + devise). Mais il existe une multitude de projet ne faisait pas appel à cette notion et de ce fait le concept reste abstrait.

Il peut être pourtant relativement simple de détecter à quel moment nous pouvons et/ou devons utiliser un Objet-Valeurs. La principale structure de données utilisées par les développeurs PHP est le tableau associatif. Dans bien de cas, ce dernier peut être remplacé par un objet de type Objet-Valeurs.

Par exemple, prenons le code suivant qui parse un fichier XML :

public function parseLine($data)
{
    // ... code permettant de traiter les données

    return [
        'name'        => trim($columns[0]->textContent),
        'frequency'   => trim($columns[1]->textContent),
        'location'    => trim($columns[2]->textContent),
        'transmitter' => trim($columns[3]->textContent),
    ];
}

Dans cet exemple, la fonction renvoie un tableau associatif contenant les informations d’une donnée lue dans un fichier XML. On pourrait dans ce cas utiliser un Value-Objet. Cela aurait de multiples avantages :

Avoir un objet où il serait possible d’avoir les données caractéristiques de l’élément (les propriétés) ainsi qu’un ensemble de comportement que nous pouvons y appliquer (les méthodes).
Cela permet de rendre le code plus lisible et compréhensible par les autres développeurs. Pas besoin d’analyser le contenu de la variable puisque cette dernière est décrite au travers d’un objet.

On pourrait ainsi réécrire le code sous la forme suivante :

public function parseLine($data)
{
    // ... code permettant de traiter les données

    return new RadioFrequency(
        trim($columns[0]->textContent),
        trim($columns[1]->textContent),
        trim($columns[2]->textContent),
        trim($columns[3]->textContent)
    );
}

Notons que si nous souhaitons faire les choses correctement, il serait nécessaire de déléguer la création de notre objet RadioFrequency à une fabrique (Factory). Bien que cela peut sembler compléxifier notre code en rajoutant une classe supplémentaire, c’est en réalité tout le contraire. Au travers de cette modification, nous respectons le principe de responsabilité unique.

Ainsi, le code final serait :

public function __construct($radioFrequencyFactory)
{
    $this->radioFrequencyFactory = $radioFrequencyFactory;
}

public function parseLine($data)
{
    // ... code permettant de traiter les données

    return $this->radioFrequencyFactory->createFromDOMNode($columns);
}

Au final, n’est-il pas plus agréable de manipuler un objet clairement identifié et ayant un comportement défini plutôt qu’un tableau où il est difficile de connaître son contenu et les actions qui peuvent y être appliquées sans effectuer une inspection xDebug ou sans dumper ce dernier ?

La conception émergente

Fri, 05 Jun 2015 00:00:00 +0200

Ceux qui me connaissent le savent bien, je suis un fervent défenseur des principes et des méthodes agiles. Même si aujourd’hui ces dernières se sont énormément démocratisées, les mettre en oeuvre au sein de projets n’est pas toujours une chose aisée (les habitudes ont la vie dure).

Ce billet, j’aurais mis un an pour l’écrire. Avec du recul ce n’est pas forcément une mauvaise chose car je vais vous raconter l’histoire d’un projet. Un projet qui, bien que développé en utilisant la méthode SCRUM, n’a pas fait l’objet d’une conception agile (que je qualifie également de conception émergente).

Utiliser une méthode agile est un bon début, mais ce n’est pas suffisant. Pour que cela fonctionne, il est nécessaire (d’après moi) que le processus de développement soit également fait de manière agile. Pour maximiser les chances de réussite, il est important de considérer les principes KISS (Keep It Simple and Stupid: ne compliquez pas les choses inutilement) et YAGNI (You ain’t gonna need it: vous n’en aurez pas besoin). C’est en respectant ces deux règles et en utilisant de manière efficace un certain nombre de Design Pattern qu’une conception émergente apparaît.

Contrairement à une “conception classique” où l’essentiel de l’architecture est réalisée en début de projet, la conception émergente a pour objectif de décrire la conception au fur et à mesure de l’avancement du projet. C’est-à-dire que l’architecture du produit est conçue au fil du développement des évolutions demandées par le métier. Ce mode de fonctionnement colle très bien à des projets agiles où les spécifications sont réalisées et priorisées tout au long de la vie du produit.

La notion de conception n’est pas remise en cause, le travail s’effectue différemment. Cela a alors un impact direct sur l’équipe. Il est important que chaque membre doit être capable d’identifier les éléments de conception redondants et de proposer des simplifications du code existant. L’équipe doit également être capable de différer une décision de conception liée à une exigence future et d’identifier le moment pertinent pour introduire une décision structurante.

Pour le projet dont je parlais au début de ce billet, l’équipe (composée d’un product owner, un scrum master et de 3 développeurs) a décidé (à mon grand regret) de partir sur une approche “traditionnelle”. De ce fait, une conception entière du système a été réalisée (le travail de développement était estimé à environ 6 mois/homme). Les sprints ont ainsi démarré par la réalisation d’un MCD complet répondant à l’ensemble des fonctionnalités qui devaient être fournies par l’outil. De cette conception a découlé la création de toutes les entités du modèle. Par la suite, les différents éléments du cahier des charges ont été découpés en users stories qui étaient réalisées de manière itérative lors de chaque sprint selon les priorités définies par le product owner.

Il est important pour la suite, de préciser que le projet en question n’est pas un projet “prioritaire” pour l’entreprise. Il est possible de le qualifier de “side-project” car il n’a pas d’impact business direct. Les membres de l’équipe sont donc affectés prioritairement sur d’autres projets (en respectant un ratio de 80/20). C’est pour cette raison, que le product owner a décidé de s’attacher à la réalisation de fonctionnalités techniques avancées afin de s’assurer de la faisabilité de ces dernières. Cela a eu pour conséquence de s’attarder sur des éléments techniques au détriment de la réalisation d’une application fonctionnelle.

Comme on pouvait s’y attendre, les délais de réalisation de l’application ont commencé à être rallongés. Le projet prenait du retard et a dû être mis en pause. Cela jusqu’à aujourd’hui, environ 6 mois après son arrêt temporaire.

Seulement les choix de conception qui ont été fait, rendent la reprise du travail difficile. La base de données a été entièrement modélisée pour les fonctionnalités annoncées il y plus d’un an maintenant. 80% des propriétés des entités ne sont pas utilisées (et correspondent donc à des colonnes de base de données à null). De plus, le fait de s’être concentré sur des éléments principalement techniques, a pour conséquence que de multiples fonctionnalités ont été commencées, mais qu’aucune n’est terminée. Il n’est donc pas possible de saisir une information dans l’interface d’administration et de la retranscrire correctement côté interface utilisateur. Et après 6 mois de pause, aucun membre de l’équipe n’est capable de dire ce qui fonctionne ou non, ni même où le travail s’était arrêté.

Lorsque l’on démarre un projet, il est important d’être pragmatique et d’avancer petit à petit. Il est également primordial de commencer un projet par un MVP (Minimum Viable Product: un produit minimum viable). Ne vous concentrez pas sur des aspects techniques qui n’ont que peu de valeur ajoutée. Développez votre produit rapidement (sans bafouer la qualité), mais avec un minimum de fonctionnalités. Ces dernières s’étofferont par la suite. Le plus important c’est que l’on utilise votre projet, cela vous rassurera en vous confrontant à votre marché, et pour l’équipe qui est derrière ce n’est pas un long tunnel sans fin.

Manipuler un champ Select2 avec Behat

Wed, 03 Jun 2015 00:00:00 +0200

Si vous développez en PHP, vous devez très certainement connaître Behat, le framework permettant de faire du développement piloté par le comportement (BDD, Behaviour Driven Development en anglais). Personnellement, je suis toujours embêté lorsque je me retrouve à écrire des scénarios devant manipuler une interface qui utilise le composant Select2 car il n’est pas possible de manipuler ce champ au travers de l’extension Mink.

Pour cela, il est nécessaire de créer des contextes personnalisés qui ajouteront des actions permettant de manipuler la liste déroulante. Etant donnée que je n’ai rien trouvé sur le Web, je vous partage le code qui permet d’interagir avec un champ Select2 dans un scénarii Behat.

/**
 * @When /^(?:|I )fill in select2 input "(?P<field>(?:[^"]|\\")*)" with "(?P<value>(?:[^"]|\\")*)" and select "(?P<entry>(?:[^"]|\\")*)"$/
 */
public function fillInSelectInputWithAndSelect($field, $value, $entry)
{
    $page = $this->getSession()->getPage();

    $inputField = $page->find('css', $field);
    if (!$inputField) {
        throw new \Exception('No field found');
    }

    $choice = $inputField->getParent()->find('css', '.select2-selection');
    if (!$choice) {
        throw new \Exception('No select2 choice found');
    }
    $choice->press();

    $select2Input = $page->find('css', '.select2-search__field');
    if (!$select2Input) {
        throw new \Exception('No input found');
    }
    $select2Input->setValue($value);

    $this->getSession()->wait(1000);

    $chosenResults = $page->findAll('css', '.select2-results li');
    foreach ($chosenResults as $result) {
        if ($result->getText() == $entry) {
            $result->click();
            break;
        }
    }
}

Avec ma société, nous avons également décidé de publier une extension Behat installable via Composer contenant un contexte permettant la manipulation complète d’un champ Select2. Cette dernière est disponible sur Github.

Le pattern "conteneur" (Container)

Wed, 22 Apr 2015 00:00:00 +0200

Lorsque l’on développe une application, le principal défi est de donner du sens à son code afin qu’il soit facilement compréhensible et maintenable. Une des nombreuses bonnes pratiques est alors d’utiliser des objets-valeurs plutôt que de simples variables. Pour stocker et manipuler ces derniers, il est possible d’utiliser un conteneur, un patron de conception souvent utilisé en parallèle.

En programmation objet, un conteneur n’est ni plus ni moins qu’un objet ayant pour but de gérer une collection d’élément. C’est un pattern assez peu utilisé dans le monde PHP car de nombreux développeurs ont pris l’habitude d’utiliser les tableaux associatifs fournis par le langage.

Il y a pourtant de multiples avantages à utiliser un conteneur dans vos applications. On peut citer :

Éviter la duplication de code dans les classes
Respecter le principe de responsabilité unique (vos objets métiers n’ont pas à se soucier de comment parcourir ou rechercher un élément dans un tableau, une liste ou une collection)

Pour vous aider à manipuler des conteneurs dans votre code, PHP fournit quelques interfaces qui peuvent être utiles lors de la mise en place de ces derniers :

Je suis toujours étonné que ce pattern ne soit pas plus connu et utilisé des développeurs PHP. Je rencontre souvent des développeurs qui me disent que la mise en place d’un tel objet est inutile et n’apporte pas de valeur (si ce n’est de complexifier inutilement le code). Sachez que vous manipulez ce genre de classe très souvent sans vous en rendre compte. Lorsque vous utilisez l’ORM Doctrine par exemple, qui utilise un conteneur ArrayCollection pour la gestion des associations multiples des entités.

Reconnaître une violation du principe de responsabilité unique

Mon, 20 Apr 2015 00:00:00 +0200

Dans un article précédent, j’ai parlé de programmation événementielle et comment il était possible d’utiliser les événements Symfony afin d’écrire du code qui respecte le principe de responsabilité unique. L’exemple était extrêmement simple et il est souvent plus difficile d’identifier les différentes responsabilités d’une classe lorsque celle-ci fait plusieurs centaines de lignes.

Le nombre de lignes de code présent (et le nombre de variables d’instances présentes) dans une classe peut être un signal d’alarme. Un autre indicateur est la présence de méthodes privées qui ont pour but de déléguer des tâches précises. Bien souvent ces méthodes peuvent être extraites dans une ou plusieurs classes indépendantes.

Si vous souhaitez approfondir les principes d’un code SOLID et comment écrire des classes qui soient facilement extensibles, réutilisables et maintenables, je ne peux que vous conseiller l’excellent livre de Matthias NOBACK : Principles of Package Design. Certainement l’une des meilleures ressources sur le sujet et que tout développeur devrait avoir lu.

Pas de logique dans les vues de vos applications MVC

Tue, 07 Apr 2015 00:00:00 +0200

La semaine dernière je suis tombé sur un article de blog écrit par Xavier NAYRAC, intitulé “Pas de logique dans les vues Rails”. Bien que l’article donne des exemples en Ruby, les propos du billet sont valables pour tous les langages et toutes les applications de type MVC. L’article étant pertinent, je relaie l’information.

Source

Utiliser les événements Symfony2 pour un code SOLID

Mon, 06 Apr 2015 00:00:00 +0200

En tant que développeur, nous essayons d’écrire du code simple, maintenable et facilement extensible. Pour cela, nous tentons de mettre en oeuvre les principes évoqués dans l’acronyme SOLID. Le “S” correspond à la notion de “Single Responsibility” (responsabilité unique). Cela signifie que vos classes doivent avoir une et une seule responsabilité, une seule raison d’exister.

Prenons pour exemple, un service Symfony dont l’objectif est d’enregistrer les données d’un utilisateur issu d’un formulaire. Le code pourrait alors ressembler à quelque chose comme cela :

// Controller/UserController.php
public function newAction(Request $request)
{
  $user = new User();

  $form = $this->createForm('user_form', $user, [
    'action' => $this->generateUrl('app_new_user'),
    'method' => 'POST'
  ]);
  $form->add('submit', 'submit', ['label' => 'Create']);

  $form->handleRequest($request);
  if ($form->isValid()) {
    $manager = $this->get('app.user_manager');
    $manager->save($user);

    return $this->redirectToRoute('user_show', ['id' => $user->getId()]);
  }

  return [ 'form' => $form->createView() ];
}

// Manager/UserManager.php
public function save(User $user)
{
  $this->entityManager->persist($user);
  $this->entityManager->flush();
}

Ce code respecte bien le principe de responsabilité unique, chacune de nos classes n’a qu’un seul objectif. Mais imaginons maintenant que nous souhaitons envoyer un email à l’utilisateur que nous venons de créer (pour le notifier de la création de son compte et lui envoyer ses informations de connexion par exemple).

Rien de difficile, il suffit alors de modifier notre manager pour envoyer le mail lors de la création du compte :

// Manager/UserManager.php
public function save(User $user)
{
  $this->entityManager->persist($user);
  $this->entityManager->flush();

  $this->emailManager->sendNewAccountNotification($user);
}

Sauf qu’en ajoutant cette ligne, nous venons de casser le principe de responsabilité unique de notre service gérant les utilisateurs. Réfléchissez bien, si vous souhaitez réutiliser la classe UserManager dans une autre application, mais que cette dernière ne souhaite pas envoyer de notification, comment allez-vous faire ?

Il vous faudra alors supprimer tous les appels à notre EmailManager ou mettre en place des conditions permettant de ne pas exécuter cette fonction. Dans le cas présent, l’exemple est très simple et cela peut être fait facilement. Mais imaginez une application de plusieurs milliers de lignes. Cela est tout de suite plus compliqué.

Heureusement, Symfony2 nous permet d’éviter ce couplage très simplement, au travers de la gestion des événements. L’idée est très simple, une fois l’enregistrement du nouvel utilisateur effectué, nous allons émettre un signal afin d’indiquer le succès de la création. Ce signal pourra alors être capter par différentes classes afin de déclencher différentes actions (un envoi de notification dans notre exemple).

Commençons par modifier notre classe UserManager :

// Manager/UserManager.php
public function __construct(EventDispatcherInterface $dispatcher, ...)
{
  $this->dispatcher = $dispatcher;
  // ...
}

public function save(User $user)
{
  $this->entityManager->persist($user);
  $this->entityManager->flush();

  $this->dispatcher->dispatch('user.create', new UserEvent($user));
}

La classe UserEvent est tout simple un conteneur pour les informations traitées par le formulaire (ici notre utilisateur créé).

use Symfony\Component\EventDispatcher\Event;

class UserEvent extends Event
{
  private $user;

  public function __construct(User $user)
  {
    $this->user = $user;
  }

  public function getUser()
  {
      return $this->user;
  }
}

Il ne reste plus qu’à intercepter le signal et à envoyer notre email :

<?php

use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class UserNotificationListener implements EventSubscriberInterface
{
  private $emailManager;

  public function __construct(EmailManagerInterface $emailManager)
  {
    $this->emailManager = $emailManager;
  }

  public function onUserCreate(UserEvent $event)
  {
    $this->emailManager->sendNewAccountNotification($event->getUser());
  }

  public static function getSubscribedEvents()
  {
    return [
      'user.create' => 'onUserCreate',
    ];
  }
}

Sans oublier de déclarer le service qui va bien :

// Resources/config/services.yml
services:
  listener.user_mailer_notification:
    class: Listener\UserNotificationListener
    arguments:
      - @app.manager.email
    tags:
      - { name: kernel.event_subscriber }

Nous avons donc maintenant des classes qui ont bien une responsabilité unique. De ce fait, le risque d’erreur est réduit. De plus cela, les rend plus facilement testables. Il sera également plus facile de les réutiliser dans d’autres projets.

Si vous souhaitez obtenir plus d’information concernant la gestion des événements dans Symonfy2, je vous invite à lire la documentation très bien rédigé à son sujet.

Intégration continue sur RaspberryPI avec PHPCI

Wed, 01 Apr 2015 00:00:00 +0200

Je possède un RaspberryPi que j’utilise essentiellement en tant que serveur personnel. J’y entrepose entre autres quelques petits dépôts Git que je souhaite garder privée. J’y ai également quelques scripts qui me permettent d’automatiser le déploiement de quelques applications (comme ce blog par exemple).

Pour automatiser un certain nombre de tâches et pour éviter de le faire manuellement, je souhaitais utiliser un outil de type intégration continue. Mon premier choix c’est alors porté sur le bien connu Jenkins. Bien évidemment, vu la puissance de la machine (que ce soit un RPi 1 ou 2), Jenkins est lent et ne permet pas d’être utilisé de manière fluide.

En recherchant sur le Web des solutions alternatives, je suis retombé sur PHPCI, une plateforme d’intégration continue spécialement conçue pour PHP et développé en PHP.

PHPCI ne se limite pas aux projets PHP. Je l’utilise pour une variété de tâches, notamment grâce à un plugin “Shell” qui me permet d’exécuter des commandes bash sur mes projets.

La solution est simple, légère et extrêmement fluide sur mon Raspberry2. Un vrai bonheur ! Comme je le racontais sur Twitter, je regrette vraiment de ne pas m’y être penché plus tôt.

pic.twitter.com/0HiuvDcMWl
— Jérémy DECOOL (@jdecool) 15 Mars 2015

En plus, le code de l’outil est plutôt simple et pouvoir mettre les mains dans le code est un vrai bonheur. De plus, l’équipe du produit (développé par une société anglaise pour ces besoins) est très sympathique et réactive sur Github.

Bien que cela ne fasse que quelques semaines que je l’utilise, l’outil me semble efficace et me semble une réelle alternative à Jenkins. Le seul véritable inconvénient, c’est le manque de plugin qui se fera sans doute sentir pour des projets complexes.

La conception pilotée par le domaine

Mon, 30 Mar 2015 00:00:00 +0200

Le DDD (Domain-Driven Design ou conception pilotée par le domaine en français), voila maintenant quelques années que j’en entends parler. Le plus souvent en ventant les mérites de cette approche. Pourtant je ne l’ai jamais pratiqué, ni même vu appliqué ou utilisé dans les différents projets sur lesquels j’ai travaillé. J’ai donc décidé à m’y intéresser de plus près.

J’ai donc commencé par effectuer des recherches pour trouver des ressources et en apprendre plus sur le sujet. Les nombreuses recherches que j’ai pu mener, m’ont systématiquement redirigé vers un ebook : Domain-Driven Design Vite Fait. “Ce livre est une introduction rapide sur les fondamentaux de DDD. Il n’introduit pas de nouveaux concepts. Il essaye de résumer l’essentiel de DDD en se basant principalement sur le livre d’Eric Evans” (l’auteur de DDD).

Je dois dire que je suis plutôt séduit par l’approche proposée. DDD est une méthodologie, une façon de concevoir une application, il n’y a absolument rien de technique dedans. La méthode se base sur la création d’un langage commun (utilisé entre les différents membres du projet, qu’ils soient techniques ou non). Ce langage commun permet ainsi de lever toutes ambiguïtés dans les conversations. Il est aussi impératif que ce langage se retrouve dans la modélisation du code du projet. Le gros avantage de cette façon de travailler est que les développeurs, chefs de projet et les personnes concernées utilisent les mêmes mots pour s’exprimer et désigner un concept précis. La communication est alors améliorée puisque tout le monde discute de la même manière et avec les mêmes mots.

Bien entendu, ce langage (dit omniprésent) peut être amené à évoluer, soit parce que le besoin métier évolue lui-même, soit parce qu’un nouveau concept qui n’avait pas été détecté apparaît. De ce fait, la modélisation de l’application doit évoluer en conséquence et une étape de refactoring sera nécessaire.

Un projet utilisant la conception pilotée par le domaine est donc voué constamment à évoluer et à subir une refactorisation continue. Afin de garantir l’évolutivité et la maintenance de l’application, il sera nécessaire d’implémenter de nombreux “design pattern” afin d’être le plus flexible possible. Il aura également la création de nombreuses classes afin de représenter les différents objets et éléments du domaine de la manière la plus explicite possible.

Cela entrainera une certaine complexité technique qui freine certains développeurs à utiliser cette méthode. Cette même complexité, fait que DDD n’est pas adapté pour de jeunes développeurs. Par contre cela peut être très constructif pour ce dernier s’il est accompagné dans son travail et que ce dernier est validé (par la mise en place de revues de code par exemple).

Pour ma part, je suis convaincu de l’aspect bénéfique de cette approche de conception pilotée par le domaine. Bien sûr elle ne s’appliquera pas à tout type de projet, mais peut-être très efficace dans des applications métiers complexes. En plus de l’aspect projet, cela peut être un très bon moyen de faire progresser de jeunes développeurs.

Les objets-valeurs (Value Object)

Wed, 25 Mar 2015 00:00:00 +0100

Tout récemment, nous avons eu un gros débat sur la conception d’un projet sur lequel je travaille. Le débat portait sur l’utilisation ou non d’un objet de type Objets-Valeur (ou Value Object en anglais). Il est vrai que dans l’environnement PHP l’utilisation de ce type d’objet est plutôt rare et méconnu (il est plus courant de voir utiliser des tableaux associatifs).

Les objets de type Objets-Valeurs sont généralement des petits objets dont leur objectif est d’apporter une notion sémantique au code. Contrairement à un autre objet, on s’intéresse à son contenu (la valeur de ses attributs) plutôt qu’à sa référence. Ces derniers sont généralement immuables.

L’exemple par excellence est certainement le cas de la monnaie. Si vous souhaitez gérer une notion d’argent, la monnaie peut alors être géré au moyen d’un Objet-Valeur, qui pourrait être défini comme ci-dessous :

class Money
{
  /** @var int */
  private $amount;

  /** @var string */
  private $currency;

  /**
   * @param int    $amount
   * @param string $currency
   */
  public function __construct($amount, $currency)
  {
    $this->amount   = $amount;
    $this->currency = $currency;
  }

  /**
   * @return int
   */
  public function getAmount()
  {
    return $this->amount;
  }

  /**
   * @return float
   */
  public function getFormatedAmount()
  {
    return round($this->amount / 100, 2);
  }
}

Cette exemple correspond à une implémentation du pattern monnaie décrit par Martin Fowler.

Il est alors plus agréable et compréhensible de manipuler un objet représentant une donnée précise qu’une variable de type entier ou flottante ayant une faible sémantique.

Ce type d’objet est très utilisé dans une conception pilotée par le domaine (Domain Driven Design) où le code est fortement basé sur le domaine métier et la logique associée. Ils permettent alors d’avoir un code compréhensible et avec un minimum d’ambiguïté.

PS: si vous êtes intéressé par une implémentation d’un Objet-Valeur permettant de gérer les devises. Sebastian BERGMANN a écrit une implémentation complète en PHP.

Les sous-modules Git

Tue, 17 Mar 2015 00:00:00 +0100

Comment ça vous ne connaissez pas les sous-modules (submodules) de Git ? Bien que pouvant être très pratique, ils sont souvent assez méconnus. Pourtant nous avons tous rencontré au moins une fois un cas où ils nous auraient bien rendu services.

N’avez-vous jamais eu envie d’inclure un projet tier au sein du projet sur lequel vous étiez en train de travailler ? Je ne parle pas d’une simple dépendance tierce, mais d’un module ou une bibliothèque que vous développez simultanément. Comment gérez-vous le développement des deux projets distinct qui pourtant doivent se retrouver au sein d’une même application ?

C’est un cas typique d’utilisation des sous-modules Git, car ils vont vous permettre d’inclure un autre dépôt Git au sein de votre projet actuel. Il vous sera alors possible de gérer vos commits sépérement pour chacun des dépôts.

Si vous souhaitez travailler sur une bibliothèque au sein de votre projet courant, vous pouvez initialiser un sous-module Git avec un dépôt externe au travers de la commande :

git submodule add http://url/depot.git dossier/destination

De ce fait, un nouveau dossier (dossier/destination) sera créé dans votre arborescence. Ce dernier fonctionnant comme un dépôt Git à part entière.

Vous noterez également qu’au travers de cette opération, Git a ajouté un nouveau fichier de configuration nommé .gitmodules contenant la description des sous-modules utilisés par le projet.

PHP-CLI cet outil méconnu

Fri, 06 Mar 2015 00:00:00 +0100

De nombreux développeurs travaillent avec PHP pour concevoir des sites ou des applications dans des environnements Web. On commence même à voir apparaître de nombreux outils utilisant PHP en ligne de commande. Pourtant ils sont peu nombreux à connaitre les possibilités offertes par PHP-CLI.

Prenons par exemple le cas d’un développeur PHP souhaitant tester une fonction PHP afin de l’utiliser. Je ne compte plus le nombre de développeurs ayant créé un fichier test.php afin de tester du code (fichier exécuté aussi bien via un serveur Web qu’en ligne de commande).

Effectivement, il est fréquent que les développeurs ignorent que PHP-CLI fournit un shell interactif permettant d’exécuter du code PHP (et donc de tester une fonction par exemple). Pour démarrer ce dernier, il suffit d’utiliser la commande php -a.

Prenons maintenant le cas du développeur qui souhaite afficher les informations de configuration PHP. Là encore, de nombreuses personnes créeront un fichier contenant un appel à la fonction phpinfo(). PHP-CLI fournit pourtant une option permettant d’afficher ces informations au travers de l’option -i.

De même si phpinfo() est également utilisé pour connaitre les modules PHP activées sur la machine, l’option -m permet d’obtenir la liste des modules actuellement actifs.

Il est de plus en plus fréquent d’utiliser des applications PHP en ligne de commande. L’exemple le plus courant est très certainement Composer. N’avez-vous jamais lancé un composer update et obtenu en réponse un message du genre Fatal Error: Allowed Memory Size of 134217728 Bytes Exhausted ?

Dans ce cas-là, il n’est pas toujours possible de modifier temporairement la configuration décrite dans le fichier php.ini. Vous me direz qu’il est toujours possible d’utiliser un appel à la fonction ini_set. Mais cela vous obligera à modifier votre code. Pour éviter cela (car en plus de ne pas être propre, c’est parfois impossible à mettre en oeuvre), PHP-CLI vous donne la possibilité de modifier une valeur de configuration au travers de l’argument -d.

Par exemple pour exécuter Composer avec une limite mémoire à 1 Go, il est possible d’utiliser la commande suivante :

php -d memory_limit=1024M /usr/local/bin/composer update

Il est bien évidemment possible de cumuler les variables de configuration à modifier. Vous pouvez donc appelez Composer en activer dynamiquement une extension PHP :

php -d memory_limit=1024M -d extension=blackfire.so composer.php

N’hésitez donc pas à découvrir ou redécouvrir les nombreuses possibilités de PHP-CLI, cela pourra vous servir et vous faciliter la vie au quotidien.

Le databinding en Javascript natif

Sat, 21 Feb 2015 00:00:00 +0100

Les navigateurs Web ont énormément évolué ces dernières années. Bien que jQuery soit encore largement utilisé par les développeurs Web, les possibilités offertes de base par Javascript tendent à le rendre obsolète.

Je m’intéresse énormément aux nouvelles possibilités du langage. Cela permet de réduire les dépendances utilisées par nos applications, d’alléger ces dernières et ainsi de les rendre plus rapide et fluide.

Je suis aussi un grand fan du framework de Google : AngularJS. Tout comme de nombreux développeurs, j’ai été attiré par sa simplicité d’utilisation et les avantages qu’il offre pour la réalisation d’application Web. Un de ces principaux atouts est certainement sa gestion du data-binding.

Lorsque j’ai entendu pour la première fois qu’il existait un équivalent natif en Javascript et avec l’emballement du Web, je me disais qu’il fallait que je regarde ça rapidement.

Avec un peu de retard, c’est chose faite ! Et c’est également une déception, car cette fonctionnalité est en réalité une proposition d’implémentation pour ECMAScript 7. De ce fait, très peu de navigateurs sont capables d’interpréter cette instruction (uniquement les versions de Chrome >= 33 et NodeJS lors de l’écriture de ce billet).

Bien que cela reste néanmoins prometteur, il va falloir attendre quelques années avant de pouvoir réellement en profiter !

Tests fonctionnels et gestion des dates

Wed, 11 Feb 2015 00:00:00 +0100

Je travaille actuellement sur une application de gestion de prise de rendez-vous à destination des professionnels. Afin de s’assurer du fonctionnement correct de la plateforme, cette dernière est testée au travers de nombreux scénarios Behat.

L’exécution des tests Behat est relativement classique. Avant chaque scénario, un jeu de données est chargée en base de données afin de dérouler les différentes étapes. Néanmoins cette méthode présente un inconvénient majeur puisque le jeu de données est statique.

Or lorsque l’on travaille avec des gestions de date, cela peut poser quelques problèmes. Effectivement, si on prend par exemple un scénario de prise de rendez-vous en tenant compte qu’un rendez-vous ne peut pas être pris pour une date antérieure à la date du jour, il sera nécessaire de mettre régulièrement le jeu de données à jour afin d’éviter que les données de ce dernier ne soient obsolètes. La date de la machine exécutant les tests étant la date de référence.

Pour résoudre ce problème, on peut penser à plusieurs solutions. La première est certainement de générer un jeu de données dynamique afin d’avoir des données relatives à la date du jour. Je n’aime pas trop cette solution pour diverses raisons. La première car elle nécessite du développement (et que j’ai peu de temps :)). La seconde, car on “perd” un certain contrôle sur le jeu de données et les tests vont nécessiter plus de codes. Or je souhaite garder ces tests aussi simple que possible.

La seconde solution, m’ayant traversé l’idée était de modifier la date système lors de l’exécution des tests. Il ne m’a pas fallu longtemps pour me dire que c’était une très mauvaise idée !

Dans le cas présent, afin de faire le minimum de modification sur l’existant, en introduisant le minimum de développement, j’ai eu recours à une application nommée faketime.

Cette application permet d’intercepter les appels systèmes de récupération de la date et l’heure. Faketime permet ainsi de démarrer un processus en altérant de manière virtuelle la date de la machine uniquement pour le processus désigné.

Lancer l’exécution des scénarios Behat en utilisant faketime se fait au travers d’une simple ligne de commande :

faketime '2014-10-05 12:30:00' bin/behat  # Utilisation d'une date précise
faketime 'last Friday' bin/behat          # Utilisation d'une date relative

Ne faites pas de "composer update"

Thu, 05 Feb 2015 00:00:00 +0100

Un titre provoquant certes, je devrais plutôt dire : “ne faites pas de composer update” d’un seul coup sur la totalité des dépendances de votre projet (et en plus c’est une mauvaise pratique) ! Et à plus forte raison si votre application n’est pas bien couverte par des tests automatisés.

Personnellement, j’ai eu le cas pas plus tard qu’aujourd’hui. Un développeur devait réaliser une évolution mineure sur le projet sur lequel je travaille. Ni une, ni deux, il ajoute une nouvelle dépendance à la main dans le composer.json et exécute un composer update pour l’installer.

Je passe le fait de ne pas avoir utilisé la ligne de commande adaptée pour cette opération (un composer require vendor/package), mais en plus il n’a pas pris la peine de lancer les tests (unitaires et fonctionnels) présent sur le projet.

Le résultat ? De nombreuses dépendances du projet ont été mise à jour. Certaines introduisaient des “breaking changes” (dans un changement de version mineur) et 50% du projet est devenu non opérationnel en 30 secondes !

Mocker un service Symfony2 dans un test Behat

Tue, 03 Feb 2015 00:00:00 +0100

Il arrive fréquemment que l’on soit amené à utiliser des services Web tiers dans les applications que nous concevons. Lors de l’écriture de nos tests, nous utilisons des mocks (bouchons) afin de simuler le comportement de ces derniers.

Dans le cas d’un test Behat le premier réflexe est certainement d’accéder au containeur de dépendances depuis un contexte afin de modifier ce dernier à la volée.

Malheureusement cette solution ne fonctionne pas. Effectivement le conteneur de dépendance n’est pas partagé entre notre application et les contextes utilisées par Behat. Toute modification de nos dépendances est alors sans effet.

Une solution consiste alors à utiliser une configuration du conteneur de dépendances en fonction de l’environnement Symfony utilisé et d’exécuter nos scénarios sur l’environnement correspondant.

Commençons donc par modifier la configuration du service que nous souhaitons mocker (un composant Facebook dans notre exemple) :

# src/AppBundle/Resources/config/services.yml
services:
    app.component.facebook:
        class: %app.component.facebook.class%

Définissons maintenant la classe à utiliser dans le cas “normal” :

# app/config/config.yml
parameters:
    app.component.facebook.class: Component\Facebook\Facebook

Il ne nous reste plus qu’à surcharger ce paramètre lorsque l’on utilise l’application dans son environnement de test :

# app/config/config_test.yml
parameters:
    app.component.facebook.class: AppBundle\Tests\Mock\Component\Facebook\FacebookMock

Maintenant cette configuration terminée, en configurant Behat pour qu’il utilise l’environnement de test de Symfony, les différents scénarios seront exécutés avec la version de l’application utilisant les bouchons.

La technique utilisée ici est simple, mais peut être contraignante si vous avez un certain nombre de classes à “mocker”. Sur son blog, Grégoire Pineau (consultant chez SensioLabs) donne une autre alternative pour réaliser cette tâche et surtout plus pertinente si vous travaillez sur de grosses applications.

Faire un héritage propre en Javascript

Mon, 26 Jan 2015 00:00:00 +0100

Plus je m’intéresse au langage Javascript et plus je me rends compte des erreurs que je fais depuis maintenant des années. En fait bien peu de développeurs connaissent réellement ce langage. À tel point que très peu de personnes (moi inclus) savent écrire un héritage sans passer par un composant tiers.

Car en attendant de pouvoir utiliser ECMAScript 6 et ainsi de bénéficier des mots-clés class et extend, écrire un héritage en Javascript n’est pas trivial. Pour comprendre comment réaliser cette opération, il vous faudra tout d’abord connaître la notion de prototype Javascript.

En ECMAScript 5 (version actuellement supportée par la majorité des navigateurs), le moyen le plus simple de réaliser un héritage est d’utiliser la fonction Object.create. Ainsi si j’ai une classe Cat qui doit hériter d’une classe Animal, on peut écrire cet héritage ainsi :

function Animal(p1, p2) {
  // ...
}

function Cat(p1, p2, p3) {
  Animal.call(this, p1, p2); // super() => appel du constructeur parent
  this.myProp = p3;

  // ...
}

Cat.prototype = Object.create(Animal.prototype, {
  constructor: { value: Cat }
});

De cette manière la classe Cat va hériter du comportement de la classe Animal.

Mais il se peut pour une raison quelconque vous utilisiez un navigateur ne supportant pas la version 5 de Javascript. Dans ce cas-là, il vous faudra écrire manuellement l’héritage.

On pourrait alors être tenté d’écrire quelque chose comme Child.prototype = new Parent() ce qui reviendrait à mettre dans le prototype de Child toutes les méthodes de Parent.

Tout d’abord écrire cette ligne de code n’est pas anodin, car cela signifie pour écrire un héritage, vous devez instancier un objet (ce qui n’est pas logique). Ensuite comment gérer le cas d’un objet parent dont le constructeur contiendrait des paramètres ? En utilisant cette méthode, il est impossible de résoudre ce cas.

La manière correcte d’écrire la fonction Object.create est :

function create(Child, Parent) {
  var Obj = function() { };
  Obj.prototype = Parent.prototype;

  Child.prototype = new Obj();
  Child.prototype.constructor = Child;
}

De cette façon on écrit un héritage tout en conservant nos constructeurs intacts. Cela passe par la création d’un objet intermédiaire n’ayant pas de constructeur, auquel nous connectons le prototype de notre objet parent. Nous utilisons cet objet intermédiaire dans le prototype de notre objet parent auquel nous n’oublions pas rattaché le constructeur de l’objet initial.

Comprenez les outils que vous utilisez

Fri, 23 Jan 2015 00:00:00 +0100

Le développement informatique évolue rapidement. Là où il y encore quelques années nous programmions tout à la main from scratch, nous réutilisons de plus en plus de composants externes. C’est d’autant plus vrai avec l’émergence et la démocratisation de l’Open Source. Seulement utilisez ces composants externes ne vous dispensent pas de comprendre comment ils fonctionnent.

Je vois trop souvent de nombreux développeurs faisant du copier/coller de code provenant d’internet ou d’un autre projet sans chercher à comprendre ce qu’ils font ni même à prendre le temps de lire un minimum la documentation de l’outil, du composant ou de l’application qu’ils utilisent.

Du coup au premier problème, ils ne savent plus vraiment comment faire :

“Pourtant ça fonctionnait sur le projet d’avant, je ne comprends pas.”

J’ai pour habitude de dire, que pour bien utiliser un outil, il faut comprendre sa philosophie et dans quel but il a été créé. Quand vous utilisez n’importe quel outil, prenez quelques instants pour le comprendre, comment il fonctionne, sa philosophie.

Lorsque ce dernier ne se comportera pas de la manière attendue, vous serez alors efficacement armé pour comprendre ce qui se passe et savoir où chercher.

Un avenir pour CoffeeScript avec ECMAScript 6 ?

Tue, 20 Jan 2015 00:00:00 +0100

Il y a quelques années, j’ai découvert CoffeeScript (un langage qui se compile en Javascript) et j’ai tout de suite été séduit. Ecrire du code Javascript est devenu plus rapide et surtout CoffeeScript a ajouté certaines fonctionnalités très plaisantes telles que les classes, les proxies, les générateurs et d’autres encores.

Apparu en 2009, CoffeeScript répondait à un réel besoin de simplification et d’évolution de Javascript. Seulement aujourd’hui Javascript évolue et la nouvelle spécification du langage (ECMAScript 6) comporte de nombreux ajouts qui ont fait le succès de Coffee. Cela à tel point que l’on peut être amené à se demander si CoffeeScript a encore un avenir.

J’ai beau réellement accrocher à CoffeeScript, pour moi la réponse est clairement “non”. Je pense réellement que la nouvelle spécification de Javascript rend obsolète CoffeeScript car les apports majeurs du langage seront maintenant natifs. La chose qui le différenciera sera sa syntaxe, mais ce n’est pour ma part pas un argument suffisant.

Seulement voilà, à l’heure actuelle, ECMAScript 6 n’est pas encore finalisé. Et bien que les principaux navigateurs commencent à implémenter certaines fonctionnalités, la couverture des spécifications est encore faible.

Il existe néanmoins des outils (transpileurs) qui vous permettent d’écrire du code ECMAScript 6 pour le traduire dans la version 5 du langage (qui est la version) actuellement supportée par les navigateurs. Parmi les outils les plus connus, on peut citer traceur et 6to5.

Donc à la question que faire maintenant, doit-on utiliser CoffeeScript ou commencer à utiliser ECMAScript 6 via un transpileur ? Personnellement, pour un projet qui devra durer dans le temps et pour lequel je parie sur l’avenir, j’utiliserais sans hésiter un transpileur car pour moi CoffeeScript est réellement sur sa fin de vie.

Ne mettez pas toute votre vie dans les fichiers .gitignore

Wed, 07 Jan 2015 00:00:00 +0100

Lorsque l’on travaille avec un gestionnaire de version, il est souvent utile d’ignorer et de ne pas versionner certains fichiers et/ou dossiers. C’est extrêmement pratique pour ne pas pourrir votre dépôt avec des fichiers inutiles tel que des logs par exemple ou pour éviter de commiter de mauvais fichier par inadvertance. Dans Git cela se traduit par la création d’un fichier .gitignore (mais des mécanismes similaires existent pour les autres outils).

Une bonne pratique est de n’ajouter que des fichiers directement liés au projet concerné. Mais nous rencontrons tous, régulièrement, des projets avec des fichiers .gitignore “fourre tout” où l’on retrouve de nombreux fichiers divers et variés. Avoir un fichier .gitignore propre, c’est faciliter la compréhension de ce dernier, mais aussi de comprendre certains mécanismes de l’application et identifier des fichiers de logs générés par des traitements (et utile pour le debug).

Il est pourtant possible avec Git de définir un fichier .gitignore global qui sera appliqué par défaut sur tous les projets en plus du fichier local du dépôt de travail. Personnellement, ce dernier contient l’ensemble des fichiers automatiquement créés par les différents IDE que je suis ammené à utiliser.

On trouve également des modèles sur Github : https://github.com/github/gitignore

Pour le mettre en place, il suffit de créer un fichier ayant un format identique à n’importe quel fichier .gitignore et d’indiquer à Git de le prendre en compte via la commande :

git config --global core.excludesfile /path/to/.gitignore_global

Et voilà, le tour est joué et vous ne pourrirez plus les fichiers .gitignore de vos projets et vos collègues vous en remercieront.

Résoudre le conflit entre Capifony et Capistrano 3

Tue, 16 Dec 2014 00:00:00 +0100

Si vous avez installé la version 3 de Capistrano (un outil largement utilisé pour le déploiement d’application web), vous avez peut-être remarqué qu’il y avait un conflit avec Capifony (son adaptation pour les applications Symfony2). Effectivement, ce dernier n’est pas (encore) compatible avec la dernière version de Capistrano.

Si vous rencontrez ce problème, il existe une solution simple permettant de résoudre le conflit. Pour cela il vous faudra installer bundler via cette ligne de commande : gem install bundler.

Bundler est l’outil utilisé pour gérer les dépendances des applications Ruby. Nous allons donc nous servir de cet outil pour installer et utiliser la version de Capistrano correspondant à nos besoins. La configuration de bundler se passe au travers d’un fichier Gemfile qui décrit les dépendances requises :

source 'https://rubygems.org'
gem 'capifony', '~> 2.8.1'

Il suffit ensuite de démarrer l’installation des dépendances via la commande bundle install.

Tout comme avec Composer, Bundler a installé les différents modules “localement”. Pour exécuter Capifony la version décrit dans le Gemfile, il faudra préfixer les commandes par bundle exec.

Par exemple, la commande de déploiement s’execute via la commande : bundle exec cap deploy

Une authentification Git permanente en HTTP

Tue, 18 Nov 2014 00:00:00 +0100

Je travaille régulièrement avec Git au travers du protocole HTTP quand il m’est impossible d’utiliser une connexion SSH. Le plus embêtant et qu’il est toujours nécessaire de saisir ses identifiants pour pouvoir accéder au dépôt distant.

Git utilisant cURL pour effectuer ses requêtes HTTP, si vous avez la chance d’être sous Linux, vous pouvez stocker vos informations de connexion dans un fichier .netrc à mettre dans votre “home”.

Par exemple :

machine serveur.git.com
login monUtilisateurGit
password s3cret

Attention, les vos identifiants et mots de passe étant stockés en clair, pensez à changer les droits du fichier avec un chmod 0600 afin d’empêcher les autres utilisateurs d’y avoir accès.

À noter également qu’à partir de la version 1.8.3 de Git, il est tout à fait possible d’utiliser des fichiers .netrc cryptés.

Protégez l'accès à vos ressources

Sun, 16 Nov 2014 00:00:00 +0100

Ce weekend, je baladais sur le site d’une agence musicale qui offre à ses clients des prestations audiovisuelles. La société offre notamment un accès à un large catalogue de musique à condition d’être un professionel du domaine de l’audiovisuel. Sauf qu’en réalité, avec un peu de débrouille, l’ensemble du catalogue est librement accessible.

Effectivement, lorsque l’on navigue sur le site en question, un lecteur audio permet d’écouter les titres disponibles. En analysant les trames réseaux, il est facile d’accéder à l’adresse du fichier qui est écouté :

Rien que via cette URL on peut récupérer le morceau complet au format MP3 encodé en 128 kbps. En analysant l’adresse du fichier, il est aisé de reconnaitre le schéma adopté http://site.com/musicfiles/[format]/[id-musique].[format].

En recherchant les différents morceaux, les identifiants des musiques sont facilement récupérables car ils apparaissent dans la barre d’adresse du navigateur.

Cela aurait pu s’arrêter ici, mais en lisant les mentions légales du site, on apprend qu’il est possible de télécharger les différents morceaux en format “MP3 (320 kbps)”, “AIFF” ou “WAV” (non compressé). Et oui c’est l’ensemble du catalogue dans tous les formats disponibles (et même haute définition) qui sont librement accessibles.

Il aurait pourtant été facile de protéger l’accès aux ressources en utilisant un petit script PHP comme celui ci-dessous :

ob_clean();

header('Content-Type: audio/mp3');
header('Content-Disposition: filename="fichier.mp3"');
flush();

readfile('chemin/vers/le/fichier.mp3');

Lorsque vous concevez un site, pensez bien à la sécurité des données de ce dernier et pas seulement celles qui sont présentes en base de données.

PS: un autre élément également inquiétant, les en-têtes renvoyées par le serveur Apache et qui indique que la version de PHP utilisée est la 5.2.17. Soit une version qui n’est plus maintenue depuis le 6 janvier 2011 !

Des propriétés non énumérables dans un objet Javascript

Wed, 05 Nov 2014 00:00:00 +0100

Dans un article précédent, je parlais de comment créer des objets en Javascript en utilisant les prototypes. Mais le fonctionnement par défaut du langage implique que les propriétés de votre objet sont énumérables. De ce fait, elles seront listées au sein d’une boucle for...in par exemple.

En reprenant l’exemple précédent :

function MyObject() {
    this.myProperty1 = null;
    this.myProperty2 = null;
}

MyObject.prototype.myMethod1 = function() {
    return 'method1';
}

MyObject.prototype.myMethod2 = function(param1, param2) {
    return 'method2';
}

var myInstance = new MyObject();

var properties = [];
for (var prop in myInstance) {
	properties.push(prop);
}

console.log(properties); // => [ 'myProperty1', 'myProperty2', 'myMethod1', 'myMethod2' ]

Il peut être dérangeant dans certains cas que les éléments constituants de notre objet soient énumérables. Pour éviter cela, la solution est d’utiliser la méthode Object.defineProperty(). Cette dernière permet de définir une nouvelle propriété ou d’en modifier une existante. Elle permet également de définir le comportement de la propriété ajoutée.

Il est donc possible de définir une contrainte enumerable à false afin d’éviter que les propriétés n’apparaissent dans les boucles.

Notre objet peut donc être défini ainsi :

function MyObject() {
    this.myProperty1 = null;
    this.myProperty2 = null;
}

Object.defineProperty(MyObject.prototype, "myMethod1", {
    enumerable: false,
    value: function() {
        return 'method1';
    }
});

Object.defineProperty(MyObject.prototype, "myMethod2", {
    enumerable: false,
    value: function() {
        return 'method2';
    }
});

var myInstance = new MyObject();

var properties = [];
for (var prop in myInstance) {
	properties.push(prop);
}

console.log(properties); // => [ 'myProperty1', 'myProperty2' ]

Object.defineProperty() propose également une option writable qui permet d’empêcher la modification d’une propriété de l’objet.

Si vous souhaitez obtenir plus d’information sur le fonctionnement de Object.defineProperty(), je vous invite à consulter la documentation développeur de Mozilla.

Les prototypes Javascript

Tue, 28 Oct 2014 00:00:00 +0100

Je travaille depuis quelques semaines sur une application temps réel réalisé avec NodeJS. J’ai longtemps critiqué ce langage qui au fond est plein de qualités, c’est juste qu’en réalité peu de gens le connaissent réellement. C’est donc l’occasion de revoir les basiques de ce langage.

Contrairement à une croyance répandue, Javascript est un langage orienté objet. Certes la syntaxe et la façon d’écrire un objet sont différentes de la plupart des langages, mais cela reste de la programmation objet.

Souvent, lorsque l’on regarde un tutorial sur le Web, un objet est écrit comme cela :

function MyObject() {
    this.myProperty1 = null;
    this.myProperty2 = null;

    this.myMethod1 = function()  {
        return 'method1';
    };

    this.myMethod2 = function(param1, param2) {
        return 'method2';
    };
}

var myInstance = new MyObject();
myInstance.myMethod1(); // => method1

C’est une des méthodes pour déclarer un objet en Javascript, mais ce n’est pas la solution idéale.

Pourquoi ? Parce que en déclarant votre objet ainsi, à chaque création d’une instance de votre objet, la machine virtuelle Javascript va redéfinir l’ensemble des propriétés et méthodes et donc les dupliquer en mémoire.

La bonne solution est donc d’utiliser les prototypes. Un prototype permet d’attacher une propriété à un objet. Il s’agit d’un mécanisme de “fallback”. Lorsqu’un appel sur une instance de notre objet est évalué par la machine virtuelle, cette dernière va commencer par vérifier s’il existe une propriété attachée dans le constructeur de l’objet (la définition de la fonction). Si rien n’est trouvé, alors une recherche sera effectuée dans son prototype.

À ce moment-là, si la propriété n’est toujours pas trouvée dans l’objet, une recherche va être effectuée dans l’objet parent (s’il en existe un). Dans le cas contraire, l’évalutation retournera la valeur undefined.

Le gros avantage des prototypes est qu’un prototype est en réalité un pointeur vers une fonction. Cela implique donc que la fonction n’est pas redéfinie et/ou dupliquer par toutes les instances de notre objet.

La bonne façon d’écrire notre code est la suivante :

function MyObject() {
    this.myProperty1 = null;
    this.myProperty2 = null;
}

MyObject.prototype.myMethod1 = function() {
    return 'method1';
}

MyObject.prototype.myMethod2 = function(param1, param2) {
    return 'method2';
}

var myInstance = new MyObject();
myInstance.myMethod1(); // => method1

Accéder aux commandes Doctrine dans Symfony2

Fri, 24 Oct 2014 00:00:00 +0200

Vous ne le saviez peut-être pas, mais lorsque vous démarrez un projet Symfony2, Doctrine est fourni avec un certain nombre de commandes prédéfinit. Parmi ces dernières certaines peuvent être très utiles comme par exemple une commande permettant d’importer un fichier SQL en base de données.

Si vous ne le saviez pas, c’est normal, car ces commandes n’apparaissent pas par défaut dans la console de Symfony. Mais étant donné qu’elles utilisent le composant Console du framework, il est facile d’y avoir accès.

Pour cela, la solution la plus simple est de créer une commande dans son projet et de la faire hériter de la commande Doctrine à laquelle on souhaite accéder.

Par exemple, si je souhaite accéder à la commande de Doctrine DBAL permettant d’insérer un fichier SQL en base de données, je peux écrire la commande ci-dessous :

namespace JDecool\Bundle\DemoBundle\Command;

use Doctrine\DBAL\Tools\Console\Command;
use Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper;
use Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

class ImportCommand extends Command\ImportCommand
{
    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $container = $this->getApplication()->getKernel()->getContainer();

        $doctrine = $container->get('doctrine');

        $em = $doctrine->getEntityManager();
        $db = $em->getConnection();

        $helperSet = $this->getHelperSet();
        $helperSet->set(new ConnectionHelper( $db ), 'db');
        $helperSet->set(new EntityManagerHelper( $em ), 'em');

        parent::execute($input, $output);
    }
}

Si vous souhaitez connaitre l’ensemble des commandes proposées par Doctrine, la liste est disponible sur la documentation officielle du projet.

Un certificat SSL gratuit pour vos applications Web

Tue, 14 Oct 2014 00:00:00 +0200

La base de la sécurité d’une application Web commence par des échanges cryptés réalisés au travers d’un protocole de type HTTPS. Via un certificat SSL, il sera alors possible de chiffrer les connexions entre pairs. Il semble pourtant que de nombreux sites n’y ont pas recours.

Même s’il est aujourd’hui prouvé que ce système comporte des failles, cela permet d’accorder un minimum de confiance à l’outil que l’on est en train d’utiliser. Il s’agit d’ailleurs, d’un gage de confiance pour le grand public, à tel point que Google a décidé d’ améliorer le référencement des sites HTTPS.

Pour rappel, la mise en place d’une communication chiffrée au travers d’un certificat SSL a pour objectif :

d’assurer une confidentialité des données en rendant impossible d’espionner les informations échangées
de contrôler l’intégrité des données et de vérifier qu’elles n’ont pas été altérées (volontairement ou non) au cours de l’échange
de certifier de l’identité de l’hôte en authentifiant la personne ou l’ entreprise avec qui l’on communique

Pour créer un certificat SSL valide, il est nécessaire que le certificat que vous allez mettre en place soit signé par une autorité de certification ce qui a un coût.

J’ai découvert récemment au travers d’un tweet que certaines entreprises proposaient de signer gratuitement des certificats SSL “de base”. C’est notamment le cas de StartSSL.

J’ai testé le service pour un usage personnel et j’avoue que j’en suis pleinement satisfait pour le moment. Cela me permet d’avoir des services sécurisés en HTTPS reconnu par tous les navigateurs modernes.

Il s’agit bien sûr d’un certificat basique et il y a très peu de vérification pour l’obtenir. Mais si comme moi, il vous arrive de lancer quelques “side-project” et que vous souhaitez offrir un niveau de confiance minimal à vos utilisateurs, cela peut être une bonne façon de commencer.

À noter également, que si votre projet est Open Source, vous avez la possibilité d’obtenir un certificat GlobalSign gratuitement.

Sinon, pour un certificat de base, l’un des meilleurs rapports qualité/prix est certainement le certificat standard de Gandi proposé à 12€/an et gratuit la première année pour l’achat du nom de domaine.

Maintenant, plus d’excuses pour ne pas fournir un des éléments de base d’une application sécurisée !

Injecter la Request dans un service Symfony2

Thu, 09 Oct 2014 00:00:00 +0200

C’est une question qui revient souvent chez les développeurs, comment injecter la Request Symfony2 dans un service ? La réponse ne semble pas si simple à trouver car dans de très nombreux cas, je constate que pour pallier le problème, c’est tout le conteneur de dépendances qui est transmet au service en question. Une très mauvaise pratique !

C’était effectivement, à “une époque”, l’unique solution car Symfony gérant plusieurs Request, le problème de l’injection est très complexe. Depuis la version 2.4 du framework, un service “request_stack” est désormais disponible.

Si vous souhaitez avoir plus d’informations sur ce service et son utilisation, je vous renvoie vers la documentation du framework expliquant comment utiliser la RequestStack.

Comment obtenir l'opcode d'un script PHP ?

Tue, 07 Oct 2014 00:00:00 +0200

Si vous suivez un peu ce qui se passe dans la sphère PHP, vous avez peut-être vu passer une explication d’Igor WIEDLER concernant l’utilisation de l’instruction goto dans une librairie qu’il a écrit. Pour justifier son choix, Igor s’est appuyé sur l’opcode résultant de l’interprétation de son code. Je me suis alors demandé comment est-il possible de générer l’opcode résultant d’un script PHP.

Avant toute chose, je vais rappeler rapidement ce qu’est l’opcode. Lorsqu’un script PHP est exécuté, la machine virtuelle PHP va transformer le script lu en un langage intermédiaire qui représente des opérations de base. Ces instructions de bas niveau sont généralement appelé “opcode”.

Il y a plusieurs raisons qui peuvent pousser un développeur à visualiser l’opcode d’un fichier PHP. Tout d’abord par curiosité intellectuelle afin de comprendre comment fonctionne le langage. Il faut également savoir que par défaut, la machine virtuelle PHP n’optimise pas le code source qui est lu. Dans le cas, où il n’y a ni mécanisme d’optimisation, ni cache d’opcode, il peut être intéressant de connaitre l’opcode généré afin de faire quelques optimisations de son code.

Le moyen qui est certainement le plus simple pour visualiser l’opcode d’un code PHP est de se rendre sur le site 3v4l qui permet de tester du code sur plusieurs versions de PHP, mais il fournit également l’opcode résultant aussi bien pour le ZendEngine (la machine virtuelle PHP) que pour HHVM (la machine virtuelle de Facebook compatible PHP).

La solution précédente est simple, mais vous oblige à posséder une connexion Internet et à copier/coller vos différents scripts sur le site. Une autre solution consiste alors à installer une extension PHP qui nous permettra de visualiser la représentation interne des scripts exécutés.

L’extension en question s’appelle Vulcan Logic Disassembler. Cette dernière s’installe facilement au travers la commande pecl ou en récupérant son code source et en le compilant.

$ pecl install vld-beta

Une fois l’extension installée, vous pourrez visualiser l’opcode d’un script via la commande :

$ php -dextension=vld.so -dvld.active=1 mon-script.php

Finding entry points
Branch analysis from position: 0
Return found
filename:       /in/t0fJ6
function name:  (null)
number of ops:  2
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   3     0  >   ECHO                                                     'Hello+World'
         1    > RETURN                                                   1

Si vous vous intéressez au fonctionnement interne de PHP, je ne peux que vous conseillez de lire ce livre collaboratif expliquant et décrivant le fonctionne interne de PHP.

Vous pourrez également en apprendre un peu plus avec le livre développer une extension PHP de Pascal MARTIN, qui tient également un blog où chaque mois, il résume ce qui se passe sur @internals, la mailing-list des développeurs de PHP.

L’issue Github dont il est question dans l’article
Un article de Pascal MARTIN sur une utilisation avancée de Vulcan Logic Disassembler.

Un adapteur générique pour appeler les fonctions natives de PHP

Wed, 01 Oct 2014 00:00:00 +0200

L’adaptateur (adapter en anglais) est l’un des design patterns les plus connus et utilisés en programmation. “Il permet de convertir l’interface d’une classe en une autre interface que le client attend. L’adaptateur fait fonctionner ensemble des classes qui n’auraient pas pu fonctionner sans lui, à cause d’une incompatibilité d’interfaces” (définition Wikipedia).

Il ne s’agit ni plus ni moins que d’un proxy qui va se charger de faire des appels d’une classe à un autre en transformant les données dans le format attendu. Les adaptateurs sont très utiles pour l’écriture de tests unitaires car ils permettent au travers de l’injection de dépendances d’être remplacé par un mock. C’est un cas d’utilisation très pratique lorsque l’on souhaite tester des blocs de code faisant appel à des fonctions natives de PHP.

Par exemple, si l’on souhaite lire un fichier de configuration, nous pourrions écrire le code suivant :

public function getUserConfiguration($user, $key)
{
    $configurationFile = file_get_contents($user->getConfigurationFile());

    $configuration = $this->parse($configurationFile);
    return $configuration[$key];
}

Le code ci-dessus pose problème, car il est impossible de contrôler l’exécution de la méthode file_get_contents. Si le test échoue, cela ne sera pas forcément lié au code qui a été écrit, mais peut-être au système de fichiers qui est indisponible au moment du test.

On peut alors écrire le test en utilisant un adaptateur :

public function getUserConfiguration($user, $key)
{
    $configurationFile = $this->fileAdapter->getFileContent($user->getConfigurationFile());

    $configuration = $this->parse($configurationFile);
    return $configuration[$key];
}

De cette manière, le code devient facilement testable, puisqu’il suffira d’utiliser un mock de la classe fileAdapter implémentant la méthode getFileContent.

C’est d’ailleurs en jetant un oeil dans le code source d’Atoum, un framework de tests unitaires (que je recommande vivement) que j’ai découvert un adaptateur générique permettant de tester naturellement les fonctions natives de PHP (également présenté dans un très bon article de Julien BIANCHI).

Voici le code de l’adaptateur :

// disponible à l'URL suivante => https://github.com/atoum/atoum/blob/master/classes/adapter.php
class adapter
{
    public function __call($functionName, $arguments)
    {
        return $this->invoke($functionName, $arguments);
    }

    public function invoke($functionName, array $arguments = array())
    {
        return call_user_func_array($functionName, $arguments);
    }
}

Cette classe est très astucieuse et fait appel “aux méthodes magiques” de PHP afin de rediriger les appels de l’adaptateur vers les fonctions natives du langage. De cette manière, plus besoin de créer une multitude de classes adaptateurs pour garantir que l’ensemble de notre code soit testable unitairement.

Attention toutefois à ne pas en abuser, les adaptateurs comme tout principe de programmation doivent être utilisé de manière judicieuse.

Des problèmes avec PHPStorm sous Linux ? Vérifier votre JRE

Mon, 29 Sep 2014 00:00:00 +0200

J’utilise depuis peu un nouvel environnement de développement basé sur une distribution Linux (Ubuntu 14.04). Ce fut l’occasion de réinstaller un stack LAMP complète avec l’IDE par excellence, j’ai nommé PHPStorm.

A priori aucun problème et tout se déroule correctement. C’est lors de l’utilisation de PHPStorm que je me suis aperçu de nombreux petits soucis (essentiellement graphique) mais très dérangeant pour un usage au quotidien.

Par exemple, la fenêtre d’auto-complétion qui ne se positionne pas au niveau du curseur, mais dans le coin en haut à droite de l’écran :

J’ai pourtant suivi la procédure d’installation de Jetbrains en installant une version officiel du JDK d’Oracle :

$ java -version

java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

Et pourtant c’est en remettant une version OpenJDK installée de base sur l’OS que l’ensemble de mes problèmes ont disparus.

$ java -version

java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.2) (7u65-2.5.2-3~14.04)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

J’ai alors immédiatement tenté l’installation du JDK 7 d’Oracle. Et là, aucun problème non plus. C’est donc bien la version 8 de Java qui est en défaut.

Donc si vous utilisez PHPStorm sous une Ubuntu (mais peut-être que le problème est présent sur les autres OS), pensez bien à vérifier le JDK installé sur votre machine.

Monitorez vos applications Symfony2 !

Tue, 23 Sep 2014 00:00:00 +0200

Vous venez de terminer votre application Symfony2 et de la déployer en production. Tous vos tests (unitaires et fonctionnels) sont au vert. Pourtant qu’est-ce qui vous assure que tout fonctionne correctement sur votre serveur ? Afin d’obtenir des informations sur ce qui se passe, il est nécessaire de mettre en place une solution de monitoring au sein de votre projet Symfony2.

Pour cela, je ne peux que vous conseiller d’utiliser le bundle SoclozMonitoringBundle qui vous permettra de monitorer (simplement et rapidement) le code Symfony sur vos serveurs de production afin de :

vous envoyer des emails lors du lancement d’exception
profiler le code PHP et d’envoyer les informations à statsd (un système de statistique)
logguer les informations de profiling
ajouter des en-têtes HTTP en cas de bugs

La mise en place (ainsi que la configuration) de ce bundle est extrêmement simple et rapide. Il vous faudra bien sûr, commencer par déclarer la dépendance dans votre fichier composer.json :

{
    "require": {
        ...,
        "socloz/monitoring-bundle": "dev-master"
    }
}

Et activer le bundle dans le kernel de Symfony :

class AppKernel extends Kernel
{
    public function registerBundles()
    {
        // ...

        if ($this->getEnvironment() == 'prod') {
            $bundles[] = new Socloz\MonitoringBundle\SoclozMonitoringBundle();
        }

        // ...

        return $bundles;
    }
}

Une fois ces deux opérations effectués, il ne vous reste plus qu’à configurer le bundle. Par exemple, l’exemple ci-dessous enverra un mail à l’adresse monitoring@mon-serveur.com lorsqu’une exception sera levée par l’application sauf pour les exceptions NotFoundHttpException et AccessDeniedHttpException :

socloz_monitoring:
    exceptions:
        enable: true
        ignore:
            - 'Symfony\Component\HttpKernel\Exception\NotFoundHttpException'
            - 'Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException'
    profiler:
        enable: false
    mailer:
        enable: true
        from: system@mon-serveur.com
        to: monitoring@mon-serveur.com
    statsd:
        enable: false

Un bundle indispensable pour garder le contrôle et améliorer la qualité de vos projets.

Protéger un champ de formulaire Symfony2 avec un droit

Tue, 09 Sep 2014 00:00:00 +0200

Il arrive fréquemment que l’on souhaite restreindre l’accès à certains champs de nos formulaires avec un (ou plusieurs) droit(s) utilisateur. Pour cela, une majorité de développeurs passera un paramètre dans le tableau d’options reçu par la fonction buildForm obligeant alors à modifier le code du formulaire pour traiter l’information reçue. Nous allons voir une alternative beaucoup plus élégante.

Pour cela nous allons créer une extension de type de formulaire qui se chargera de la vérification des droits et affichera ou non auprès de l’ utilisateur de notre application.

Prenons pour exemple un formulaire permettant de créer un billet de blog :

<?php

namespace JDecool\Bundle\ForumBundle\Form;

use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\OptionsResolver\OptionsResolverInterface;

class ThreadType extends AbstractType
{
     /**
     * @param FormBuilderInterface $builder
     * @param array $options
     */
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('title')
            ->add('content', 'textarea')
            ->add('solved', 'checkbox', [
                'required'   => false,
            ])
        ;
    }

    /**
     * @param OptionsResolverInterface $resolver
     */
    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver->setDefaults(array(
            'data_class' => 'JDecool\Bundle\ForumBundle\Entity\Thread'
        ));
    }

    /**
     * @return string
     */
    public function getName()
    {
        return 'forum_thread';
    }
}

Maintenant que notre formulaire est défini, nous allons restreindre l’affichage du champ solved uniquement au utilisateurs ayant le rôle ROLE_ADMIN. Pour cela nous allons simplement ajouter une nouvelle propriété au champ correspondant.

public function buildForm(FormBuilderInterface $builder, array $options)
{
    $builder
        ->add('title')
        ->add('content', 'textarea')
        ->add('solved', 'checkbox', [
            'required'   => false,
            'is_granted' => 'ROLE_ADMIN',
        ])
    ;
}

Pour que ce paramètre soit interprété, nous allons créer notre extension de type formulaire en lui injectant le SecurityContext Symfony afin de vérifier les droits de l’utilisateur connecté.

<?php

namespace JDecool\Bundle\ForumBundle\Form\Extension;

use Symfony\Component\Form\AbstractTypeExtension;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\Form\FormEvent;
use Symfony\Component\Form\FormEvents;
use Symfony\Component\OptionsResolver\OptionsResolverInterface;
use Symfony\Component\Security\Core\SecurityContextInterface;

class SecurityTypeExtension extends AbstractTypeExtension
{
    /**
     * The security context
     * @var SecurityContextInterface
     */
    private $securityContext;

    /**
     * Object constructor
     */
    public function __construct(SecurityContextInterface $securityContext)
    {
        $this->securityContext = $securityContext;
    }

    /**
     * {@inheritdoc}
     */
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $grant = $options['is_granted'];
        if (null === $grant || $this->securityContext->isGranted($grant)) {
            return;
        }

        $builder->addEventListener(FormEvents::PRE_SET_DATA, function (FormEvent $event) {
            $form = $event->getForm();
            if ($form->isRoot()) {
                return;
            }

            $form->getParent()->remove($form->getName());
        });
    }

    /**
     * {@inheritdoc}
     */
    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver->setDefaults(array('is_granted' => null));
    }

    /**
     * {@inheritdoc}
     */
    public function getExtendedType()
    {
        return 'form';
    }

}

Il ne reste plus qu’à enregistrer notre extension en tant que service :

services:
    jdecool_forum_bundle.security_type_extension:
        class: JDecool\Bundle\ForumBundle\Form\Extension\SecurityTypeExtension
        arguments:
            - @security.context
        tags:
            - { name: form.type_extension, alias: form }

Et voilà, il est maintenant possible de restreindre n’importe quel champ de formulaire avec un droit utilisateur sans avoir besoin de donner en paramètre l’utilisateur connecté ou à manipuler ce dernier dans notre classe de formulaire.

Mise à jour du 10/09/2014: Suite à de nombreuses réactions sur Twitter, je tiens à rendre à Ceasar ce qui appartient à Ceasar. Je ne suis pas l’auteur de ce code. Ce code a été trouvé dans un projet sur lequel je travaillais et que j’ai souhaité partager. Après des discussions, l’auteur est Alexandre SALOME, consultant chez SensioLabs qui avait donné cette astuce lors d’une présentation à un sfPot à Paris.

Utiliser une branche Github avec Composer

Fri, 05 Sep 2014 00:00:00 +0200

Lorsque l’on travaille sur un projet avec de multiples dépendances, il arrive que l’on soit amené à faire évoluer l’une d’entre elles pour les besoins de notre développement. Nous devons alors spécifier à Composer sur qu’elle branche il doit travailler.

Pour cela, nous allons prendre pour exemple une dépendance récupérée depuis un dépôt Github (le fonctionnement est similaire pour tout autre dépôt, via un Satis par exemple).

Il faut donc tout d’abord spécifier à Composer sur quel dépôt il va devoir travailler. Cette configuration se fait au travers d’une section “repositories” à ajouter dans le fichier composer.json.

{
	// ...

    "repositories": [
        {
            "type": "git",
            "url": "https://github.com/jdecool/my-lib"
        }
    ],

    // ...
}

Une fois le dépôt spécifié, il ne reste plus qu’à indiquer la branche de travail de votre dépendance.

{
	// ...

	"require": {
        // ...
        "vendor/my-lib": "dev-my-branch"
    },

    // ...
}

Vous pouvez maintenant effectuer un composer update vendor/my-lib pour mettre à jour la dépendance avec la branche du dépôt que vous venez de configurer.

Protégez vos actions Symfony2

Tue, 02 Sep 2014 00:00:00 +0200

Il est parfois excessif de créer un formulaire pour effectuer certaines actions au sein d’une application. Il est alors d’usage d’utiliser un lien HTML permettant d’effectuer ces opérations (c’est par exemple souvent le cas pour supprimer un élément dans une liste). Il est alors important de sécuriser ses actions.

Pour cela, imaginons une liste d’élément s’affichant de la manière suivante :

<table>
  <tr>
    <td>Mon élement 1</td>
    <td><a href="/element/1/delete">Supprimer</a></td>
  </tr>

  <tr>
    <td>Mon élement 2</td>
    <td><a href="/element/2/delete">Supprimer</a></td>
  </tr>
</table>

Bien sûr il ne s’agit là que d’un exemple, et dans une application réelle, il faudrait que l’action de suppression soit effectuée au travers d’une méthode POST ou DELETE.

En supposant qu’il y ait déjà une restriction en fonction des droits de l’ utilisateur connecté, nous allons donc protéger cette action d’une attaque de type CSRF. Pour cela nous allons voir comment générer un jeton qui permettra d’identifier la requête qui sera effectuée.

Nous allons donc commencer par créer le jeton dans l’action qui affiche la liste et ajouter la vérification du token dans l’action de suppression :

// src/JDecool/MyBundle/Controller/DemoController.php

public function listAction(Request $request)
{
	// ...
	$token = $this->get('form.csrf_provider')->generateCsrfToken('element_list');

	return $this->render('MyBundle::list.html.twig', [
		// ...
		'token' => $token,
	]);
}

public function deleteAction(Request $request, $id)
{
	if (!$this->get('form.csrf_provider')->isCsrfTokenValid('element_list', $token)) {
		$this->redirect('message_list');
	}

	// ...
}

Une fois ce code ajouté, il ne restera plus qu’à passer le jeton lors de la génération du lien de l’action.

Notez également que le jeton généré ici restera valide pour l’ensemble de la durée de la session de l’utilisateur et qu’il pourra être réutilisé. Le jeton est également généré à l’aide du paramètre secretprésent dans le fichier app/config/parameters.yml d’où l’importance de modifier ce dernier.

C’est une méthode simple et rapide qui vise à protéger votre application, et pourtant peu de développeurs l’utilise.

Visualiser le code coverage des tests Atoum dans PHPStorm

Tue, 19 Aug 2014 00:00:00 +0200

Lorsque je parle d’Atoum auprès de personnes qui ne l’utilisent pas, un des éléments qui revient très souvent (pour les utilisateurs de PHPStorm tout du moins), est l’impossibilité de visualiser la couverture du code par les tests directement dans l’IDE. Or à partir de maintenant, cela sera un argument qui ne tient plus.

Effectivement, il est désormais possible de visualiser le code coverage des tests Atoum directement dans PHPStorm grâce au plugin PHPUnit code coverage qui est désormais compatible avec les fichiers de type “clover” générés par Atoum.

Pour installer le plugin dans l’IDE, il faut aller dans les préférences de l’outil, puis dans la section “Plugin”. Cliquez sur le bouton “Browse repositories…” pour parcourir l’ensemble des plugins disponibles, et recherchez “PHPUnit code coverage” pour l’installer (il sera nécessaire de redémarrer PHPStorm).

Pour pouvoir utiliser le plugin, nous allons maintenant devoir configurer Atoum pour que ce dernier nous génère un rapport de type “clover”. Ce rapport se présente sous la forme d’un fichier XML décrivant tous les fichiers qui ont été parcouru par nos tests et indique quelles lignes ont été executé ou non. Le plugin lit ce fichier pour retranscrire son contenu dans l’IDE.

Pour générer ce rapport, il faut ajouter les lignes ci-dessous dans votre fichier .atoum.php:

$cloverWriter = new atoum\writers\file(__DIR__.'/build/atoum.clover.xml');
$cloverReport = new atoum\reports\asynchronous\clover();
$cloverReport->addWriter($cloverWriter);
$runner->addReport($cloverReport);

Une fois cela effectué, il ne vous reste plus qu’à configurer le plugin en lui indiquant où trouver le fichier généré. Il faut alors retourner dans les préférences de PHPStorm et ouvrir la section “PHPUnit code coverage”:

La configuration terminée, vous pourrez alors visualiser les blocs de votre code couvert par les tests et ceux qui ne le sont pas.

Plugin PHPUnit code coverage

Des dépôts Composer privés avec Satis

Tue, 12 Aug 2014 00:00:00 +0200

Composer est certainement l’un des outils PHP les plus connus et utilisé à l’heure actuelle. Il permet en effet de gérer très facilement les dépendances d’un projet PHP. Cependant, (trop) peu de développeurs connaissent ou utilisent Satis, l’outil de création de dépôts Composer.

Pourtant Satis est un outil très pratique et permet de mettre en place une gestion de dépôts privés. On peut également l’utiliser afin de mirrorer nos dépendances Composer provenant de Github, ce qui pourrait permettre de continuer à travailler même si Github venait à ne plus être disponible.

Si peu de personnes utilisent Satis, c’est peut-être à cause de sa mise en place qui peut sembler (au premier abord du moins) complexe. Pourtant, nous allons voir qu’il n’y a rien de compliqué et que la configuration de Satis ressemble étrangement à celle de Composer.

Nous allons donc commencer par installer Satis. Bien entendu, nous allons utiliser Composer pour cela. L’installation de Satis se fait en une ligne de commande: php composer.phar create-project composer/satis --stability=dev --keep-vcs.

Une fois installé, il faut configurer Satis en lui indiquant comment accéder à nos dépôts. Voici un exemple de fichier de configuration:

{
    "name": "Satis",
    "homepage": "https://satis.local.dev",
    "archive": {
        "directory": "dist",
        "absolute-directory" : "/home/satis/dist",
        "format": "zip",
        "skip-dev": true
    },
    "repositories": [
        { "type": "composer", "url": "https://packagist.org" },
        { "type": "git", "url": "git://git.local.dev/my-bundle" },
    ],
    "require": {
        "symfony/symfony": "2.5.*",
        "doctrine/orm": "*",
        "private/my-bundle": "*"
    },
    "require-all": true
}

Je ne vais pas détailler ici l’ensemble des éléments de la configuration de Satis, je vous invite à lire la documentation de Composer pour cela. J’attire cependant votre attention sur la section require qui, comme dans un fichier composer.json, indique les dépendances que vous souhaitez mettre à disposition. Dans l’exemple ci-dessus, la configuration crée un miroir des dépôts symfony/symfony et doctrine/orm ainsi qu’un dépôt privé permettant d’exposer le composant private/my-bundle provenant d’un dépôt Git.

Pour démarrer la création du dépôt Satis, il suffit d’exécuter la commande:

php /path/to/satis/bin/satis build /path/to/satis.conf /path/to/packages-repository

Il ne reste plus qu’à donner un accès au dépôt que l’on vient de créer en configurant un serveur Web:
php -S 0.0.0.0:4680 -t /path/to/packages-repository

Votre dépôt Satis est maintenant configuré et vous pouvez l’utiliser dans l’ensemble de vos projets PHP via Composer. Il faudra, au préalable, préciser l’adresse de votre dépôt Satis dans le fichier composer.json en ajoutant une section repositories:

"repositories": [
    {
        "type": "composer",
        "url": "http://your-mirror-server:4680"
    }
],

Documentation de Satis

Dépôt Github

Tester rapidement un site mobile avec Behat

Wed, 06 Aug 2014 00:00:00 +0200

J’utilise Behat au quotidien pour écrire mes tests fonctionnels. J’ai récemment eu besoin de mettre en place des tests pour un site mobile conjointement aux tests existant sur le projet. N’ayant que peu de temps alloué sur le projet, j’ai dû mettre en place des derniers très rapidement.

Pour cela, la solution qui me semblait la plus évidente était de modifier le user-agent du navigateur utilisé en le remplaçant par celui d’un appareil mobile. Or j’utilise Behat avec le driver Selenium2 qui n’autorise pas cette modification.

Les navigateurs modernes sont capables de gérer différentes configurations au travers d’un gestionnaire de profils. Une autre solution consiste alors à utiliser ces derniers en créant un profil qui aurait le user-agent voulu. Mes tests étant exécutés par Firefox, il suffit de démarrer ce dernier avec l’option -p pour ouvrir le gestionnaire de profil.

Une fois le nouveau profil créé, nous allons accéder à l’interface de configuration de Firefox en saisissant about:config dans la barre d’adresse. Il ne reste plus qu’à ajouter une nouvelle clé de configuration (si elle n’existe pas) nommée general.useragent.override en lui donnant la valeur désirée (dans mon cas un iPhone 4S utilisant Safari Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7).

Il ne reste plus qu’à créer une archive ZIP contenant le profil que l’on vient d’ajouter. Ces derniers se trouvent dans les dossiers suivants :

Mac : /Users/<loginUtilisateur>/Library/Application\ Support/Firefox/Profiles/<identifiant.NomDuProfil>
Linux : ~/.mozilla/firefox/<identifiant.NomDuProfil>
Windows : C:\Users\<loginUtilisateur>\AppData\Roaming\Mozilla\Firefox\Profiles\<identifiant.NomDuProfil>

Maintenant il ne nous reste plus qu’à configurer un nouveau profil Behat pour l’exécution de nos tests avec ce nouvel environnement. Voici une configuration type que j’utilise dans mes projets Symfony2 :

mobile:
    paths:
        features: features/mobile
        bootstrap: %behat.paths.features%/bootstrap
    extensions:
        Behat\Symfony2Extension\Extension:
            mink_driver: true
            kernel:
                env: test
                debug: true
        Behat\MinkExtension\Extension:
            base_url: http://localhost:8000/app_test.php
            browser_name: firefox
            goutte: ~
            selenium2:
                capabilities:
                    firefox:
                        profile: '/chemin/vers/le/profil/firefox-mobile.zip'

Vous pouvez maintenant lancer vos tests avec un navigateur mobile en exécutant behat : bin/behat --profile mobile.

Cette installation rapide est surtout destinée à pouvoir écrire des tests fonctionnels rapidement et peut convenir pour des projets de faibles envergures. De plus elle ne fonctionne que pour des sites Web devant fonctionner sur mobile. Pour des tests plus pérennes ou pour des projets plus conséquents il conviendra d’utiliser des outils spécialisés dans les tests mobiles tels que SauceLabs, Appium, Selendroid, ios-driver.

Présentation "Introduction PHPUnit et Atoum"

Thu, 31 Jul 2014 00:00:00 +0200

Il y a quelques jours, j’ai eu l’occasion de parler des tests unitaires en PHP lors d’une présentation chez mon employeur actuel (Novaway). L’objectif était d’introduire les concepts fondamentaux liés aux tests unitaires et de présenter rapidement les 2 principaux frameworks de tests PHP : PHPUnit et Atoum.

J’ai réalisé les slides de la manière la plus objective possible en essayant de ne pas tenir compte de mon opinion concernant chacun des frameworks de manière à être le plus neutre possible.

Les slides sont disponibles sur Github et vous pouvez accéder à la présentation en ligne. Les slides ne sont plus disponibles sur Github, mais sont dorénavant consultable sur ce site.

Atoum et la gestion du error_reporting

Mon, 21 Jul 2014 00:00:00 +0200

J’utilise depuis quelques années maintenant Atoum pour écrire les tests unitaires sur mes différents projets (Open Source et professionnels). Pourtant cela ne m’empêche pas d’avoir encore quelques surprises lors de l’écriture de mes tests.

Ce weekend, en écrivant des tests sur une librairie PHP “legacy”, et en profitant pour y faire un peu de refactoring, mes tests Atoum me généraient une erreur PHP (E_STRICT) que je ne parvenais pas à reproduire via une application test.

La seule explication de ce phénomène est qu’Atoum surchage la configuration error_reporting de votre environnement PHP.

Après une rapide réflexion, cela n’est en soi pas une mauvaise idée, car cela vous permet de vous assurer que votre code ne contient réellement aucune erreur et cela indépendamment de la configuration qui sera utilisée sur la machine qui utilisera votre code (comme l’explique Frédéric HARDY lors d’un échange de tweet).