J’ai évoqué dans une publication précédente, l’usage de l’IA par les leaders pour construire leurs arguments, et la perte d’authenticité que cela entraîne. J’ai exactement le même sentiment côté technique.

De plus en plus, je vois des développeurs avancer des arguments qu’ils n’ont pas construits. Des réponses générées, structurées, bien tournées, mais qui ne sont pas les leurs. Et tout comme pour les leaders, cela désincarne les propos et leur fait perdre en crédibilité.

Je vais régulièrement courir. Pas pour la performance, juste pour m’aérer l’esprit et être un minimum mobile, plutôt que de camper devant mon écran. Paradoxalement, c’est à ce moment que j’ai les meilleures idées qui me viennent à l’esprit.

Il y a quelque temps, je faisais passer des entretiens pour un poste. J’ai pu rencontrer de nombreux profils: développeur, “lead dev” ou “architecte” et derrière ces titres des réalités bien différentes (même à titre équivalent).

Depuis quelques mois, je repère de plus en plus de documents et de présentations de leads et de directeurs rédigés à coups d’IA. Ce n’est pas forcément gênant, mais le problème, c’est quand ça se voit de trop.

Avec l’IA, on parle beaucoup de la rapidité et de la vitesse de génération de code. Mais, tout comme le code, générer de la documentation n’a jamais été aussi simple et rapide. En quelques secondes, l’IA produit des pages entières décrivant un projet. Mais attention à cette abondance.

Bien que cela commence à changer, Github reste aujourd’hui la forge de référence pour l’hébergement de projet autour de Git. Néanmoins, dans une démarche d’autonomie numérique, je ne souhaite pas dépendre uniquement de cette plateforme. Pour réduire cette dépendance, j’ai décidé de dupliquer et “mirrorer” l’ensemble de mes dépôts (publics et privés) sur Codeberg, une forge européenne et associative.

L’IA permet à de nombreux éditeurs logiciels de livrer de nouvelles fonctionnalités toujours plus rapidement. Elle a augmenté la vitesse de production logicielle. La tentation de toujours aller plus vite est alors grande. Les nouvelles fonctionnalités d’un logiciel étant souvent perçu comme un avantage concurrentiel. Plus il en propose, plus il semble riche et plus il paraît compétitif.

Pour beaucoup, la Clean Architecture se résume à un découpage du code en 3 couches: Domain, Application et Infrastructure (avec éventuellement une couche de présentation). Pourtant, si l’on regarde le livre de référence sur le sujet, “Clean Architecture” de Robert C. Martin, ce découpage ne représente qu’une dizaine de pages sur les 400 que compte le livre.

Pour beaucoup de développeurs, voir un dossier “Domain” dans le code source d’un projet, visant à isoler la partie métier, et avoir des objets riches avec un nommage cohérent, c’est faire du DDD (Domain Driven Design). C’est certes un bon début, mais réduire le Domain Driven Design à une structure de dossier, c’est passer à côté de l’essentiel.

Je commence à voir de plus en plus d’équipes où le lead tech est devenu plus rapide à implémenter une fonctionnalité via l’IA qu’à l’expliquer, la déléguer et attendre que quelqu’un la prenne en charge. Pourquoi cadrer un ticket, répondre aux questions et relire du code quand on peut obtenir le résultat directement en utilisant une IA ?

Nous sommes à l’ère de la génération de code. L’IA génère dorénavant du code à une vitesse impressionnante. Avec elle, apparaissent des revues de code parfois massives, à plusieurs centaines, voire plusieurs milliers de changements.

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.

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.

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.

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.

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.

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.

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.

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.

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 ?

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.

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.

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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 ?

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.

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 ?

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.

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.

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

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

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.

Pour de nombreux développeurs, une tâche s’arrête lorsqu’elle est fusionnée dans la branche principale de travail. Pourtant à ce stade-là, seule la moitié du travail a été effectuée.

Il existe un élément invisible dans une équipe, mais qui peut pourtant modifier radicalement sa performance et son bien-être : la sécurité psychologique.

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.

Lorsqu’une entreprise tech grandit, je vois souvent les équipes se structurer autour d’un découpage technique (front, back, infra, devops…). Ce découpage est assez naturel, puisqu’il rassemble des groupes possédant des compétences similaires. Mais cette organisation n’est pas sans problème.

Nombreux sont les développeurs qui cherchent à fuir les tests techniques.

Je lis régulièrement que ces derniers rebutent bon nombre de personnes et que ça ne permet pas d’évaluer correctement un candidat. Mais le vrai problème, c’est la décorrélation entre l’exercice réalisé et la réalité du métier une fois embauché.

À l’ère de l’IA, il n’a jamais été aussi important de s’intéresser aux fondements du développement logiciel et à la documentation des outils que l’on utilise.

La semaine dernière, je disais qu’il était pour moi hors de question de laisser l’IA en roue libre, qu’il est nécessaire de la guider.

Mais comment la guider correctement sans maîtriser les concepts de base ? Impossible de construire une architecture robuste, maintenable et évolutive sans connaître les design patterns qui sous-tendent ce travail.

Investir dans les compétences fondamentales aujourd’hui, c’est garantir la solidité des applications de demain.

L’IA pour le développeur, c’est la possibilité de se recentrer sur l’essentiel, la valeur ajoutée pour l’utilisateur et l’architecture logicielle.

Comme toute personne passionnée par le code, je me suis longtemps attaché à la technique et sa qualité. L’avènement de l’IA, rendant la tâche d’écrire du code (presque) secondaire, permet de se concentrer sur ce qui compte vraiment: la résolution des problèmes utilisateur et l’architecture logicielle.

Il n’est (pour moi) pas question de laisser l’IA en roue libre. Je la guide dans ce que je souhaite implémenter et de quelle manière. Je lui laisse la main pour écrire le détail des implémentations.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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 ?

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

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.

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?

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

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

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.

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.

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

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.

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 :

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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

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. 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 Responsibility” (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. À tel point que très peu de personnes (moi inclus) savent écrire un héritage sans passer par un composant tiers.

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

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.

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.