#tests #phpunit #infectionphp #mutation

    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).

    #architecture #cleanArchitecture #hexagonal #uncleBob

    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.

    #architecture #testing

    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.

    #architecture #design #screaming architecture

    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 de ce genre de déconvenues qu’est né le concept de Screaming Architecture.

    #retry #résilience #exponential backoff

    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 messageries ou de file 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 entrainant 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.

    #Q/A #tests

    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.

    #pattern #programmationOrientéeObjet #cohérence #validation

    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.

    #tests #contractTesting #design #behavioralContractTesting

    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.

    #designPattern #unitOfWork #ORM

    Le design pattern Unit of Work est au coeur 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.

    #designPattern #command #query

    Ces dernières années, on a entendu de plus en plus souvent parler du pattern CQRS (pour Command Query Responsability Segration) du fait 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.

    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 queUserService ou ProductManager, il est important de nommer un message en fonction de sa responsabilité.

    #jekyll #lunrjs #recherche

    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.

    #php

    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.

    #api #php #symfony #idempotence

    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 retournera toujours le même résultat. Les appels GET à une API REST sont alors considérés comme idempotent (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.

    #php #docker #local

    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.

    #docker #test

    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.

    #php #optional #pattern

    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.

    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.

    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.

    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.

    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 maitrisent 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.

    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.

    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.

    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 ?

    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.”.

    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.

    Hier soir (jeudi 15 février 2024), j’ai eu la chance de pouvoir participer à la soirée de lancement de 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 leurs fonctionnements afin de savoir comment “leur parler”. Tout cela avec un peu d’explication de sciences cognitives et de magie.

    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.

    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.

    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.

    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.

    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 !

    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.

    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.

    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.

    Depuis son rachat par Elon Musk, Twitter est un peu dans la tourmente: licenciement en masse, de nombreux départ volontaire 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’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

    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.

    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.

    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.

    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?

    A 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.

    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.

    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.

    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.

    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 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.

    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.

    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.

    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.

    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.

    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.

    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.

    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 !

    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 ?

    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é.

    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.

    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.

    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.

    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.

    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.

    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.

    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 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.

    Nous travaillons aujourd’hui avec tellement de framework 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 complexe sans utiliser aucun outil supplémentaire. C’est notamment le cas pour la soumission de formulaire en AJAX.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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ériences tournant autour de nos 3 pôles d’expertises que sont la technique, le conseil et le marketing.

    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.

    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.

    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.

    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.

    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.

    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 principale avantage de cette dernière est que l’extension est compatible avec les versions 7 de PHP.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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é le 30 janvier 2016 à Lyon.

    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.

    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).

    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.

    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 ?

    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.

    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.

    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. A tel point que c’est devenu l’outil de référence pour la gestion des versions décentralisé. Nous allons voir dans cet article quelques fonctionnalités bien pratiques mais qui sont bien trop souvent ignorées par les développeurs.

    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.

    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.

    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.

    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 ?

    C’est un fait, l’utilisation de Docker s’est démocratisé 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.

    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.

    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).

    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.

    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 plus facilement. 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.

    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.

    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.

    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 Responsability” (responsabilité unique). Cela signifie que vos classes doivent avoir une et une seule responsabilité, une seule raison d’exister.

    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).

    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.

    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).

    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.

    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.

    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 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.

    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.

    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.

    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. A tel point que très peu de personne (moi inclus) savent écrire un héritage sans passer par composant tier.

    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.

    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.

    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).

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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 !

    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.

    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).

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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’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.