The blog of Jean-François Lépine

Qu'est-ce qu'un beau code, pour un LLM ?

2026-04-22T00:00:00+00:00

Chaque développeur a sa propre idée de ce qu’est un beau code.

Il y a ceux qui veulent des méthodes courtes, quitte à les multiplier. Ceux qui préfèrent des méthodes longues mais cohérentes. Ceux pour qui un commentaire bien placé sauve une vie, et ceux qui considèrent qu’un bon code n’a pas besoin de commentaires. Il y a des écoles. Robert C. Martin a fait carrière sur l’une d’elles avec Clean Code. Kent Beck sur une autre. Et des équipes entières se déchirent depuis des années sur ces questions.

Une question qu’on s’est rarement posée avec précision : et les LLMs, ils ont quel style ?

On sait bien qu’ils ont des préférences. Quand on demande à GPT, Claude ou Gemini de générer du code, on voit assez vite des patterns. Mais c’est anecdotique. Personne, à ma connaissance, n’avait fait une étude vraiment systématique de la signature stylistique d’un LLM. Combien de méthodes en moyenne ? Combien de commentaires conservés ? Combien d’identifiants renommés ?

Trois chercheurs de l’université de la Sarre (Norman Peitek, Julia Hess et Sven Apel) viennent de publier sur arXiv un papier qui répond à cette question. Le titre est From Restructuring to Stabilization: A Large-Scale Experiment on Iterative Code Readability Refactoring with Large Language Models. L’idée est simple : prendre 230 snippets Java, demander cinq fois de suite à GPT-5.1 de les refactoriser pour améliorer la lisibilité, et regarder ce qui se passe.

Le résultat est, à mon avis, l’un des plus utiles de ces derniers mois pour qui utilise des LLMs en production. Et le point important n’est pas que GPT-5.1 refactorise. C’est qu’il refactorise toujours dans une direction reconnaissable - la sienne.

Le protocole

Source : Peitek, Hess & Apel, arXiv:2602.21833, 2026.

Les auteurs ont pris 230 fichiers Java du dépôt GitHub The Algorithms – Java, un repo éducatif d’implémentations d’algorithmes classiques. Le choix n’est pas anodin : code idiomatique, conventions homogènes, licence MIT donc reproductible. Ils ont filtré pour ne garder que des fichiers entre 50 et 200 lignes, avec au moins 50 % de code (pas que des commentaires).

À partir de chaque fichier, ils ont créé trois variantes :

Original : le code tel quel, propre, idiomatique.
Meaningless : tous les identifiants (classes, méthodes, variables) ont été remplacés par des noms sans signification. Tous les commentaires ont été rendus aléatoires. La structure du code est préservée mais sa lisibilité humaine est volontairement détruite.
NoComment : tous les commentaires sont retirés, sans rien d’autre toucher.

Ensuite, pour chaque variante, ils ont demandé à GPT-5.1 (temperature = 0, donc déterministe) de refactoriser le code cinq fois de suite, en utilisant trois formulations de prompt :

PromptGeneral : « Refactor this code for improved readability. »
PromptMeaning : « Refactor this code for improved readability, especially with respect to identifier naming. »
PromptComments : « Refactor this code for improved readability, especially with respect to comments. »

Total : 230 snippets × 3 variantes × 3 prompts × 5 itérations = 10 350 snippets produits par le modèle. Un outil de diff fin (DiffParser) catégorise ensuite chaque ligne changée : rename, syntaxe seule, changement de commentaire, modification de code, ou changement mixte.

Étude de bonne taille, et surtout très bien instrumentée.

Découverte 1 : Une dynamique en deux phases

Pourcentage de lignes inchangées à chaque itération

Variante Original, PromptGeneral. Source : Peitek et al., 2026.

Il y a deux phases distinctes dans le processus, et c’est reproductible.

À la première refactorisation (v0 → v1), GPT-5.1 touche beaucoup de code. Seulement 45 % des lignes restent inchangées. Il renomme, casse en plusieurs méthodes, supprime des commentaires, en ajoute d’autres, change le format. C’est une vraie restructuration.

À la deuxième itération (v1 → v2), c’est déjà différent. 76 % des lignes ne bougent plus. Les changements deviennent locaux, chirurgicaux.

À partir de la troisième, on entre dans une phase de stabilisation : 86 %, 89 %, puis 92 % de lignes inchangées entre versions successives. Le modèle a trouvé sa version « finale » et n’y touche plus qu’à la marge.

Le principe de la convergence : à chaque itération, le LLM modifie moins le code, jusqu'à se stabiliser.

Première information utile : un refactoring LLM n’est pas un processus convergent rapide. Il y a une vraie phase de restructuration qui mobilise une à deux itérations. Si on demande à GPT de refactoriser une fois et qu’on compare au résultat, on voit beaucoup de changements. Si on lui redemande, on voit encore beaucoup de changements - mais d’une autre nature. Ce n’est pas la même chose, et pour qui industrialise du refactoring assisté, la distinction change tout.

Découverte 2 : Le LLM converge, indépendamment du point de départ

Convergence du % de lignes inchangées : les trois variantes

Original - code propre, idiomatique

NoComment - commentaires retirés

Meaningless - identifiants obfusqués

Pourcentage de lignes inchangées par transition. Les trois courbes finissent dans la même zone (~89-92 %). Source : Peitek et al., 2026.

C’est ici qu’on entre dans le résultat le plus contre-intuitif du papier.

Pour vérifier si la convergence observée est vraie (et pas un artefact du code de départ), les auteurs ont mesuré ce qui se passe avec les variantes Meaningless et NoComment. Souvenez-vous : Meaningless est volontairement illisible, NoComment a perdu tous ses commentaires.

Si le modèle se contentait de polir le code qu’on lui donne, on s’attendrait à ce que les trois variantes restent différentes après cinq itérations. La Meaningless aurait des noms peu informatifs, la NoComment aurait peu de commentaires. Logique.

Ce n’est pas du tout ce qui se passe.

Les trois variantes convergent vers des représentations très proches après cinq itérations. Sur le nombre de méthodes : les trois partent à 3,1 méthodes en moyenne (même structure de base) et finissent toutes autour de 6 méthodes après cinq refactorings. Sur le nombre de lignes de code : les trois partent à 56 lignes et finissent autour de 73. Sur les commentaires inline : Original et Meaningless partent à 1,3, et toutes les variantes convergent vers 0,2 - quasi-élimination.

Le LLM a une représentation interne de ce qu’est du « code lisible ». Cette représentation existe - elle est démontrée empiriquement par la convergence. Et elle ne dépend que marginalement du code de départ.

Le LLM ne se contente pas de polir le code qu’on lui donne en respectant son style. Il le pousse vers son propre style. Et cette « cible » est suffisamment stable pour que, partant de trois codes très différents, on aboutisse à trois codes très proches.

Déléguer le refactoring à un LLM, ce n’est pas neutre stylistiquement. C’est adopter implicitement le style du modèle.

Découverte 3 : La signature stylistique de GPT-5.1

Signature stylistique GPT-5.1 : après 5 itérations

Méthodes par fichier

3,1 → 6,0 +93 %

Lignes de code

58 → 73 +26 %

Commentaires inline

1,3 → 0,2 −85 %

Lignes vides

tendance ↗ stable à partir de v3

Moyennes sur 230 snippets Java, variante Original, PromptGeneral. Source : Peitek et al., 2026.

Sur les 230 snippets refactorisés cinq fois, voici les tendances mesurées :

Le nombre de méthodes est passé en moyenne de 3,1 à 6 par fichier. Presque doublé. GPT-5.1 croit à la décomposition. Une longue méthode devient plusieurs petites.
Le nombre de lignes de code augmente régulièrement à chaque itération, de 58 à 73. Le découpage en plus de méthodes ne se fait pas à coût zéro : signatures supplémentaires, appels, parfois paramètres.
Les commentaires inline (du type int x = 0; // counter) sont quasiment éliminés. De 1,3 à 0,2 en moyenne.
Les lignes vides augmentent progressivement. Le code devient plus aéré, plus respirable visuellement.
Les identifiants sont normalisés vers des conventions Java standard (camelCase, noms longs et descriptifs, suffixes explicites comme Counter, Result, Helper).

Méthodes courtes et nombreuses, suppression des commentaires inline, aération à la PEP-8, noms longs et descriptifs : dit autrement, et en forçant un peu le trait, dans cette expérience, GPT-5.1 se comporte comme un disciple de Clean Code. On peut raisonnablement soupçonner que ce type de littérature a influencé les patterns appris, sans pouvoir le démontrer.

Ce qui compte ici, c’est la netteté du pattern - reproductible, mesurable, sur 230 codes différents. Et c’est précisément ce qui rend le sujet sensible : beaucoup d’équipes ne se reconnaissent pas dans Clean Code, et se retrouvent malgré tout à recevoir ce style en sortie de leur LLM.

Découverte 4 : Le LLM ne sait pas s’arrêter

Similarité entre versions successives : code déjà propre

Variante Original. Même sur du code propre, GPT-5.1 continue de modifier ~10 % des lignes à chaque passage. Source : Peitek et al., 2026.

Sur la variante Original (code déjà propre, déjà idiomatique), on s’attendrait à ce que le modèle laisse tranquille. Ce n’est pas ce qui se passe. La similarité entre versions successives s’approche de 0,90 à la fin, mais ne touche jamais le plafond. Le modèle ne s’arrête pas spontanément.

Les auteurs appellent ça une tendance au sur-refactoring : quand on demande de refactoriser, le modèle refactorise, même quand il n’y a rien à faire. Pour qui industrialise ce type de flux, c’est un problème concret. Modifier du code qui n’en avait pas besoin, c’est du risque de bug, du bruit dans le git blame, de la friction en revue.

La parade est connue mais peu utilisée : il faut des critères d’arrêt explicites. Ne pas dire « refactorise », mais « refactorise si nécessaire, sinon réponds inchangé ». Et même comme ça, le résultat n’est pas garanti.

Découverte 5 : L’effet « rename oscillation »

Oscillation d'un identifiant sous PromptMeaning

count

numberOfItems

itemCount

numberOfItems

itemCount

numberOfItems

Exemple représentatif. Le modèle alterne entre deux noms équivalents au fil des itérations, sans amélioration nette. Source : Peitek et al., 2026.

Avec le prompt PromptMeaning (qui cible explicitement les noms), un phénomène inattendu apparaît : les noms oscillent. Le modèle choisit un nom en v1, le change en v2, revient au premier en v3. Pas systématique - mais suffisamment fréquent pour être documenté comme un risque structurel.

L’explication probable : sans guide externe (convention d’équipe, dictionnaire de domaine), le modèle hésite entre plusieurs noms équivalents. Le contexte change légèrement à chaque itération (d’autres lignes ont bougé), et son arbitrage bascule. Un dev senior trancherait une fois et s’y tiendrait. Le LLM, lui, peut changer d’avis.

Pour qui industrialise ce flux, c’est un signal d’alerte : les diffs successifs sont bruités par des changements qui ne correspondent à aucune amélioration. Le type de bruit qui pollue les revues et érode la confiance dans l’outil.

Découverte 6 : Le prompt influence le détail, pas la trajectoire générale

Les auteurs ont testé trois prompts différents (PromptGeneral, PromptMeaning, PromptComments) pour voir si la formulation change quelque chose à la dynamique de refactoring.

Le résultat est nuancé. Les prompts ciblés influencent bien le type de changements introduits - PromptMeaning produit plus de renames, PromptComments produit plus de modifications de commentaires. Mais la dynamique globale (restructuration puis stabilisation, convergence vers le même idéal stylistique, sur-refactoring résiduel) est la même quelle que soit la formulation.

Rassurant, parce que le prompt garde un effet local : on peut bien orienter les renames ou les commentaires. Inquiétant, parce qu’il ne suffit pas à changer la trajectoire stylistique de fond : on peut demander gentiment, insister, préciser, le modèle reviendra toujours vers son idée du beau code.

Ce que ça éclaire pour moi

On mesure déjà la complexité. On mesure déjà le couplage. Mais on mesure encore mal la cohérence stylistique structurelle d'une codebase. Et c'est précisément là que les LLMs vont laisser leurs traces.

La maintenabilité d’un projet tient aussi à la cohérence stylistique interne de sa codebase. Une codebase où toutes les méthodes sont longues mais cohérentes est plus facile à maintenir qu’une codebase qui mélange des fichiers façon Clean Code et des fichiers façon « grosse fonction utilitaire de 200 lignes ». Le cerveau du développeur s’habitue à un style - c’est ce qui permet de naviguer rapidement, de prévoir où trouver quoi, de reconnaître l’inhabituel.

Introduire un LLM dans le flux de refactoring d’une codebase existante, c’est prendre le risque de fragmenter ce style interne. Les fichiers qu’il touche migrent vers sa cible à lui. Les autres restent dans l’idéal historique de l’équipe. La codebase devient un patchwork (méthodes de cinq lignes ici, de cinquante là) sans que les métriques classiques en montrent quoi que ce soit. La complexité cyclomatique moyenne peut être identique. Le couplage peut ne pas avoir bougé. Mais la cohérence s’érode, silencieusement.

C’est là le vrai trou dans nos outils. PhpMetrics, AstMetrics, les linters et les formateurs ont été construits pour quantifier la maintenabilité - mais via des métriques absolues (complexité, couplage) ou de surface (mise en forme). La dispersion stylistique structurelle (variance du nombre de méthodes par fichier, des longueurs de méthodes, des conventions de nommage, de la densité de commentaires) reste largement non mesurée. Et c’est précisément le terrain où les LLMs vont laisser leurs traces.

Ce que ça implique, concrètement

Quatre choses ressortent.

Un LLM a un style, et il faut le documenter. Si l’équipe utilise GPT-5.1 pour refactoriser, elle pousse vers Clean Code. Si elle utilise Claude, le style est différent. Si elle utilise Qwen ou Mistral, idem. Avant de déléguer du refactoring, il est utile d’avoir une idée de la signature stylistique du modèle utilisé - et de décider si elle est compatible avec celle de la codebase.

Des critères d’arrêt explicites. Le sur-refactoring n’est pas un bug - c’est le comportement par défaut du modèle. Pour qu’il s’arrête quand il n’y a plus rien à faire, il faut l’inscrire dans le prompt. Refactorise uniquement si le code en a besoin. Si tu juges qu’il est déjà acceptable, réponds avec le code inchangé. Et même comme ça, vérifier en aval que les diffs sont réellement améliorants.

Préserver explicitement les commentaires qui ont de la valeur. Le modèle élimine systématiquement les commentaires inline, et c’est parfois une vraie perte. Un commentaire qui dit pourquoi (« on prend cette branche d’abord parce qu’elle est la plus fréquente en production ») a une valeur que le code ne véhicule pas. Si le flux LLM les supprime, on appauvrit la codebase.

Faire attention au naming. L’oscillation sur les noms est réelle et bruyante. Refactoriser plusieurs fois la même portion de code avec un LLM sans demander de réutiliser les noms existants revient à voir le même fichier renommer ses variables à chaque passage, sans amélioration nette.

Au-delà de ces points techniques, il y a une question plus large : qui définit le style de notre codebase ? Pendant des décennies, c’étaient les équipes humaines, à travers leurs revues, leurs guides internes, leurs disputes. Maintenant, si on n’y prend pas garde, c’est implicitement le LLM qu’on utilise - et donc les biais hérités d’un corpus d’entraînement dont la composition n’est pas neutre.

Que cette référence soit bonne ou mauvaise est un autre débat. Le point ici, c’est que c’est une décision par défaut (prise pour nous, sans nous) qui mériterait d’être consciente.

Limites et précautions de lecture

Le papier a plusieurs limites que les auteurs mentionnent honnêtement.

Un seul modèle testé. C’est GPT-5.1, et c’est GPT-5.1 uniquement. La signature stylistique de Claude, de Qwen, de Mistral est probablement différente. Une comparaison cross-modèles serait un prolongement naturel - c’est très probablement ce qui suivra.

Une seule langue testée, Java. Sur du Python, du PHP ou du Go, les patterns stylistiques préférés du modèle peuvent ne pas être les mêmes. Les conventions sont différentes par langage, et le modèle s’y adapte. Les chiffres précis (multiplier les méthodes par 2, augmenter de 26 % les lignes de code) ne sont pas directement transposables.

Un corpus académique. Les snippets du repo The Algorithms sont pédagogiques, courts, isolés. Le comportement sur du code de production réel (multi-fichier, avec des dépendances, des side-effects) n’est pas testé ici. On peut raisonnablement supposer que les grandes tendances tiennent, mais les chiffres précis ne sont pas garantis.

Le point important n’est donc pas de savoir si le style de GPT-5.1 est bon ou mauvais. Le point important, c’est qu’il existe.

Quand une équipe introduit un LLM dans son flux de développement, elle introduit aussi une préférence stylistique externe. On peut l’accepter. On peut la mesurer. On peut la contraindre. Mais il vaut mieux éviter de la subir sans s’en rendre compte.

LLMs in Production: Why an 8-Word Prompt Beat All the Others

2026-03-24T00:00:00+00:00

I had a simple need: get the best possible score on a language assessment task. A human-annotated dataset, 700 texts, and a way to test multiple prompts under the same conditions.

I did what everyone does. I started with an elaborate, structured prompt, following best practices. Then I tested variations. And the result surprised me: an 8-word prompt beat a prompt designed by 21 researchers.

At first I thought it was an anomaly. Then I looked into the literature, and I discovered this result had a name: instruction dilution. A documented phenomenon that affects all language models. The idea is simple and somewhat counterintuitive: when you add information to a prompt, even correct, even relevant information, performance can degrade. Not because the information is wrong, but because it dilutes the useful signal into noise.

What follows is what recent research teaches us about this phenomenon, illustrated by my experiment on those 700 texts.

The experiment: 700 texts, 4 prompts

The context: automated assessment of learners’ English language proficiency, according to the CEFR framework (the six levels A1 to C2). The model tested: GPT-4.1. The corpus: 700 written compositions, each evaluated by three certified human examiners.

Setup

Corpus 700 examples under CC BY-NC-SA 4.0 license. Each text comes with a reference level and evaluations from three certified examiners.

Model GPT-4.1, via API, same parameters for all prompts tested.

Metric Exact match: did the model assign exactly the right level?

We built four prompts. From the most elaborate to the most minimalist.

P1: Few-shot, following the OpenAI guide 44%

Show full prompt

Classify the CEFR level of the following written text. ### Rules: - Output only the CEFR level: A1, A2, B1, B2, C1, or C2 - No explanation, no justification - If uncertain, output the closest level Examples: Text: "I have a dog. His name is Max. He is big and black." Level: A1 Text: "Last summer I visited my grandparents. We went to the market every morning." Level: A2 (...) ### Text: """""" Level:

Instructions up front, ### and """ separators, few-shot examples, format constraints. Follows official OpenAI guide recommendations.

P2: Prompt from an academic publication 51%

Show full prompt

You are an expert in language proficiency classification based on the Common European Framework of Reference for Languages (CEFR). Your task is to analyze the given text or narrative and determine the best CEFR level [A1, A2, B1, B2, C1, or C2] based on the CEFR descriptors of reading comprehension of learners below: A1 - Learners of this level can give information about matters of personal relevance (e.g. likes and dislikes, family, pets) using simple words/signs and basic expressions. Learners can also produce simple isolated phrases and sentences. A2 - Learners of this level can produce a series of simple phrases and sentences linked with simple connectors like "and", "but" and "because". Learners have sufficient vocabulary for the expression of basic communicative needs and for coping with simple survival needs. B1 - Learners of this level can produce straightforward connected texts on a range of familiar subjects within their field of interest, by linking a series of shorter discrete elements into a linear sequence. Learners have a good range of vocabulary related to familiar topics and everyday situations. B2 - Learners of this level can produce clear, detailed texts on a variety of subjects related to their field of interest, synthesising and evaluating information and arguments from a number of sources. Learners have a good range of vocabulary for matters connected to their field and most general topics. C1 - Learners of this level can produce clear, well-structured texts of complex subjects, underlining the relevant salient issues, expanding and supporting points of view at some length with subsidiary points, reasons and relevant examples, and rounding off with an appropriate conclusion. Learners can also employ the structure and conventions of a variety of genres, varying the tone, style and register according to addressee, text type and theme. C2 - Learners of this level can produce clear, smoothly flowing, complex texts in an appropriate and effective style and a logical structure which helps the reader identify significant points. Learners have a good command of a very broad lexical repertoire including idiomatic expressions and colloquialisms; shows awareness of connotative levels of meaning. Provide only the CEFR level as output directly, without explanation or justification. Text: «TEXT» Answer:

From Universal CEFR: Enabling Open Multilingual Research on Language Proficiency Assessment (arXiv:2506.01419). Written by researchers specializing in automated assessment.

P3: One sentence (best result 🏆) 59%

Assess the CEFR level of this written production.

No role. No criteria. No list of levels. The model infers everything (and does it better than when you explain it).

P4: P3 slightly enriched 47%

Assess the CEFR level of this written production by an English learner. Give a score between A1, A2, B1, B2, C1, C2.

We add context and the list of levels. Two seemingly useful pieces of information. Result: -12 points compared to P3.

The results

Accuracy (Exact Match) (GPT-4.1, n=700)

44%

P1
Few-shot

51%

P2
Academic

59%

P3
One sentence

47%

P4
Enriched

P1Few-shot following the OpenAI guide: 44%

P2Academic research prompt (Universal CEFR): 51%

P3"Assess the CEFR level of this written production": 59%

P4P3 with context and level list: 47%

Exact match on the A1-C2 scale. GPT-4.1 via API. Academic corpus CC BY-NC-SA 4.0, evaluated by three certified human examiners.

P3 wins, and by a wide margin. It beats the academic prompt by 8 points, the few-shot prompt by 15 points, and its own enriched version by 12 points.

That last gap is the one that intrigued me most. Between P3 and P4, we only added two pieces of information that GPT-4.1 already knows: that the learner is studying English, and the list of CEFR levels. By repeating them, we didn’t help the model. We got in its way.

Why adding information degrades results

This 12-point gap between P3 and P4 is explained by what the literature calls information dilution: when you rephrase what the model already knows, you dilute the useful signal into noise.

The mechanism isn’t mysterious. Transformer attention allocates finite capacity on each pass. When part of that capacity is consumed by redundant information, even correct information, less remains for the task itself. Attention doesn’t disappear: it scatters across non-informative tokens. Jiang et al. (2024) describe “reduced perceptual ability due to the limited context window”: the context window is a finite resource, and every token consumed by noise is one less token for signal.

GPT-4.1 knows the CEFR. It was trained on massive amounts of language assessment data. When you ask it in one sentence to evaluate according to the CEFR, it activates exactly what it needs. When you provide detailed examples and instructions, however well-crafted, you’re offering a reformulation of what it already knows. And that reformulation creates friction. That’s why P1, the most elaborate prompt, finishes last.

A longer prompt is not a more precise prompt. On a domain the model has mastered, it's often a noisier prompt.

The question that follows: how systematic is this phenomenon? And what happens when you push models beyond just a few instructions?

Three degradation profiles

The IFScale benchmark (Jaroslawicz et al., 2025) tested 20 models on tasks with 10 to 500 simultaneous instructions. The results reveal three distinct degradation profiles.

Three degradation profiles by instruction density

Threshold: near-perfect, then sharp drop (o3, gemini-2.5-pro)

Linear: steady, predictable degradation (gpt-4.1, claude-3.7-sonnet)

Exponential: rapid collapse, low plateau (claude-3.5-haiku, llama-4-scout)

Source: IFScale (Jaroslawicz et al., arXiv:2507.11538), 2025.

Reasoning models like o3 or gemini-2.5-pro follow a threshold profile: performance stays near-perfect up to 150 or 250 instructions, then drops sharply. Gemini-2.5-pro goes from 98.4% at 100 instructions to 68.9% at 500. The model absorbs and absorbs, then gives way all at once.

Large general-purpose models like gpt-4.1 or claude-3.7-sonnet degrade steadily and predictably. GPT-4.1 goes from 95.4% to 48.9%, claude-3.7-sonnet from 94.8% to 52.7%. Each added instruction costs a bit of performance. This is the most actionable profile, because you can estimate the loss before incurring it.

Smaller models like claude-3.5-haiku or llama-4-scout collapse quickly then stabilize at a low plateau, between 7 and 15%. Beyond about a hundred instructions, adding or removing anything barely changes the result: the model has already disengaged.

It's not "shorter = better." It's that there's a threshold beyond which performance collapses; and that threshold depends on the model.

The nuance matters. Reasoning models resist remarkably well up to a critical point. General-purpose models degrade gradually but manageably. Smaller models simply aren’t designed for dense prompts. Knowing the degradation profile of the model you’re using means knowing how many instructions you can afford.

Omission vs modification: how models fail

IFScale also reveals something more subtle: models don’t fail the same way depending on instruction density.

At low density, when a model gets it wrong, it gets it wrong by a little. It approximates, it misinterprets a constraint. The researchers call this a modification error: the model tried, and fell short.

At high density, the failure mode changes radically. The model doesn’t get it wrong, it forgets. Instructions aren’t misinterpreted, they’re simply ignored. This is an omission error. And the numbers are striking: at 500 instructions, llama-4-scout shows an omission/modification ratio of 34.88x. For every approximation error, 35 instructions are simply forgotten. The model isn’t doing its best with an imperfect result. It’s giving up.

This shift has a direct consequence for how we design prompts. At moderate density, rephrasing or clarifying an instruction can help. At high density, it’s pointless, because the problem isn’t that the model misunderstands. It’s that it’s no longer reading.

There’s also a cognitive competition effect worth mentioning. The attention spent on instruction-following degrades the quality of the main task itself. IFScale shows that o3, at 500 instructions, produces about 1,500 output tokens where every third word must be an imposed keyword. The model devotes so much capacity to respecting formal constraints that not enough remains for the task.

The connection to my experiment is direct. P1 and P2 add instructions that compete with the main evaluation task. Even though those instructions are correct, they consume attention. P3 leaves all the attention to the model for what actually matters.

Positional bias: Lost in the Middle and beyond

Instruction dilution is amplified by another well-documented problem: positional bias.

Liu et al. (Stanford, 2023) showed that LLMs exhibit a U-shaped attention bias. They process information at the beginning and end of the prompt better, and significantly degrade information placed in the middle. This is the Lost in the Middle phenomenon, and it affects even models explicitly trained for long contexts.

IFScale adds an unexpected nuance about primacy bias, the model’s tendency to favor earlier instructions. This bias follows a non-linear curve. At low density, below 100 instructions, it’s weak: the model processes instructions relatively uniformly. At moderate density, between 150 and 200 instructions, it peaks. The model becomes selective and favors the first instructions at the expense of later ones. Beyond 300 instructions, the bias converges to a low level, not because the model has become fair again, but because it’s switched to “uniform failure” mode: it ignores instructions evenly, regardless of position.

In practice, on moderate-length prompts (the most common case in production), position matters enormously. What’s at the beginning frames the task. What’s at the end acts as the last instruction before generation. What’s in the middle is the most vulnerable to being forgotten. And that’s one more reason to keep prompts short: the longer the prompt, the larger the “middle,” and the more pronounced the U-shaped bias.

It’s not always the shortest that wins

The message of this article is not “make shorter prompts.” It’s that beyond a certain threshold, adding information becomes counterproductive, and that threshold is lower than you think.

This threshold depends on several things. First, the model: reasoning models like o3 or gemini-2.5-pro resist instruction density far better than smaller models. A prompt that works on gpt-4.1 may collapse on claude-3.5-haiku.

Then, the task. My P3 wins because GPT-4.1 already knows the CEFR. It was trained on massive volumes of language assessment data. On a domain unknown to the model, a proprietary business framework, unpublished specialized jargon, a detailed prompt remains necessary. It’s precisely because the model doesn’t know that you need to tell it.

And finally, the nature of the added information. The entire difference lies between redundant and new information. Rephrasing what the model knows (the CEFR descriptors, the list of levels) creates noise. Providing what the model doesn’t know (a proprietary grading scale, specific business criteria) creates signal.

The rule isn't "be short." The rule is: don't rephrase what the model knows. Only add what it doesn't know.

In practice, this requires knowing the model’s boundaries, what’s part of its training and what isn’t. That boundary is rarely documented. It’s discovered by testing.

Prompt compression: compress rather than remove

In many production use cases (RAG, document analysis, long contexts), you simply can’t shorten the prompt. The context is long because the problem demands it.

Research on prompt compression offers an interesting alternative: rather than removing information, you compress it. You eliminate noise while preserving signal.

The first family of approaches, called text-to-text, transforms text into shorter text by pruning non-informative tokens or by summarization. LLMLingua-2 from Microsoft achieves compression ratios of 3 to 6x with performance comparable to uncompressed text. On NaturalQuestions, F1 stays at 71.90 with 3.9x compression. On GSM8K, exact match reaches 79.08 at 5x. You divide context size by 4 or 5, and performance stays nearly identical.

The second family, text-to-vector, encodes text into compact vector representations that the literature calls gist tokens. The gisting technique achieves up to 26x compression with minimal loss. The idea: instead of having the model read 10,000 tokens, you encode them into a few hundred vectors that capture the essential information.

LLM-DCP (Jiang et al., 2024) goes further by modeling compression as a Markov Decision Process. Each token is evaluated sequentially, keep or remove, based on its contribution to the task. The result: 12.9x compression ratio.

Compression is an alternative to truncation. It preserves signal while eliminating noise (exactly what instruction dilution prevents us from doing manually).

When context is long, the question isn’t “how to shorten?” but “how to compress without losing signal?” It’s an engineering problem, not a writing problem.

Practical implications

From all of this, I take away a few principles that I now apply daily.

The first is atomicity. One instruction per prompt, stated in a single sentence if possible. When a task is complex, I break it into steps rather than making the prompt longer.

The second is position. Main instruction at the beginning, critical constraints at the end, context and examples in the middle, knowing they’ll be less well retained.

The third is testing at scale. A prompt that works on 10 examples may collapse on 700. IFScale results show that degradation profiles are predictable: it’s worth testing at different densities to find your model’s threshold.

And finally, when a prompt contains multiple constraints, a reminder at the end (“make sure you respect all constraints above”) can reduce the omission rate. It’s a palliative, not a solution, but it works on linear degradation profiles.

I drew concrete rules for production prompting from these observations, what changes when you move from conversation to API, how to separate the what from the how, and how to stabilize and evaluate prompts at scale.

Conclusion

Instruction dilution isn’t an intuition. It’s a measurable, reproducible phenomenon, and research is starting to understand it well. Beyond a certain threshold, adding information to a prompt degrades the model’s performance. That threshold depends on the model, the task, and the nature of the added information.

Prompting guides provide techniques. Research explains why some work and others don’t. Not because the guides are wrong, but because they’re written for a context, conversation, that doesn’t transfer directly to another, production at scale.

To write prompts that work at scale, you need to understand what’s happening in the model’s attention. Know what it already knows, what it doesn’t, and where the tipping point lies. And that can only be learned through experimentation. By getting it wrong on 700 examples and understanding why.

Sources and further reading

IFScale: Benchmarking Instruction Following Across Scales
Jaroslawicz et al., 2025. Benchmark of 20 models on 10 to 500 simultaneous instructions.

Lost in the Middle: How Language Models Use Long Contexts
Liu et al. (Stanford), 2023. U-shaped positional bias in LLMs.

LLM-DCP: Prompt Compression as a Markov Decision Process
Jiang et al., 2024. Prompt compression via sequential decision process.

LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression
Microsoft, 2024. Text-to-text compression 3-6x with preserved performance.

A Survey on Prompt Compression
Taxonomy of text-to-text and text-to-vector approaches.

LLMs en prod : pourquoi un prompt de 8 mots a battu tous les autres

2026-03-24T00:00:00+00:00

J’avais un besoin simple : obtenir le meilleur score possible sur une tâche d’évaluation linguistique. Un jeu de données annoté par des humains, 700 textes, et de quoi tester plusieurs prompts dans les mêmes conditions.

J’ai fait ce qu’on fait tous. J’ai commencé par un prompt élaboré, structuré, conforme aux bonnes pratiques. Puis j’ai testé des variantes. Et le résultat m’a surpris : un prompt de huit mots a battu un prompt conçu par 21 chercheurs.

J’ai d’abord pensé à une anomalie. Puis j’ai cherché dans la littérature, et j’ai découvert que ce résultat avait un nom : l’instruction dilution. Un phénomène documenté, qui touche tous les modèles de langage. L’idée est simple et un peu contre-intuitive : quand on ajoute des informations à un prompt, même correctes, même pertinentes, les performances peuvent se dégrader. Non pas parce que les informations sont fausses, mais parce qu’elles diluent le signal utile dans du bruit.

Ce qui suit, c’est ce que la recherche récente nous apprend sur ce phénomène, illustré par mon expérience sur ces 700 textes.

L’expérience : 700 textes, 4 prompts

Le contexte : évaluation automatique du niveau de langue d’apprenants en anglais, selon le référentiel CECRL (les six niveaux A1 à C2). Le modèle testé : GPT-4.1. Le corpus : 700 expressions écrites, chacune évaluée par trois examinateurs humains certifiés.

Dispositif

Corpus 700 exemples sous licence CC BY-NC-SA 4.0. Chaque texte est accompagné d'un niveau de référence et des évaluations de trois examinateurs certifiés.

Modèle GPT-4.1, via API, mêmes paramètres pour tous les prompts testés.

Métrique Exact match : le modèle a-t-il attribué exactement le bon niveau ?

On a construit quatre prompts. Du plus élaboré au plus minimaliste.

P1: Few-shot, conforme au guide OpenAI 44%

Voir le prompt complet

Instructions en tête, séparateurs ### et """, exemples few-shot, contraintes sur le format. Conforme aux recommandations du guide officiel OpenAI.

P2: Prompt issu d'une publication académique 51%

Voir le prompt complet

Extrait de Universal CEFR: Enabling Open Multilingual Research on Language Proficiency Assessment (arXiv:2506.01419). Rédigé par des chercheurs spécialisés en évaluation automatique.

P3: Une phrase (le meilleur résultat 🏆) 59%

Évalue le niveau CECRL de cette production écrite.

Pas de rôle. Pas de critères. Pas de liste des niveaux. Le modèle infère tout (et le fait mieux que quand on lui explique).

P4: P3 légèrement enrichi 47%

Évalue le niveau CECRL de cette production écrite d'un apprenant d'anglais. Donne un score entre A1, A2, B1, B2, C1, C2.

On ajoute le contexte et la liste des niveaux. Deux informations utiles, en apparence. Résultat : −12 points par rapport à P3.

Les résultats

Accuracy (Exact Match) (GPT-4.1, n=700)

44%

P1
Few-shot

51%

P2
Académique

59%

P3
Une phrase

47%

P4
Enrichie

P1Few-shot conforme au guide OpenAI : 44%

P2Prompt de recherche académique (Universal CEFR) : 51%

P3« Évalue le niveau CECRL de cette expression écrite » : 59%

P4P3 avec contexte et liste des niveaux : 47%

Exact match sur l'échelle A1–C2. GPT-4.1 via API. Corpus académique CC BY-NC-SA 4.0, évalué par trois examinateurs humains certifiés.

P3 gagne, et d’assez loin. Il bat le prompt académique de 8 points, le prompt few-shot de 15 points, et sa propre version enrichie de 12 points.

Ce dernier écart est celui qui m’a le plus intrigué. Entre P3 et P4, on a seulement ajouté deux informations que GPT-4.1 possède déjà : le fait que l’apprenant étudie l’anglais, et la liste des niveaux CECRL. En les répétant, on ne l’a pas aidé. On l’a gêné.

Pourquoi ajouter de l’information dégrade les résultats

Cet écart de 12 points entre P3 et P4 s’explique par ce que la littérature appelle l’information dilution : quand on reformule ce que le modèle sait déjà, on dilue le signal utile dans du bruit.

Le mécanisme n’est pas mystérieux. L’attention des transformers alloue une capacité finie à chaque passe. Quand une partie de cette capacité est consommée par des informations redondantes, même correctes, il en reste moins pour la tâche elle-même. L’attention ne disparaît pas : elle se disperse sur des tokens non informatifs. Jiang et al. (2024) parlent de “reduced perceptual ability due to the limited context window” : la fenêtre de contexte est une ressource finie, et chaque token consommé par du bruit est un token en moins pour le signal.

GPT-4.1 connaît le CECRL. Il a été entraîné sur des données massives d’évaluation linguistique. Quand on lui demande en une phrase d’évaluer selon le CECRL, il active exactement ce qu’il faut. Quand on lui fournit des exemples et des instructions détaillées, aussi bien formulés soient-ils, on lui propose une reformulation de ce qu’il sait déjà. Et cette reformulation crée une friction. C’est pour ça que P1, le prompt le plus élaboré, termine dernier.

Un prompt plus long n'est pas un prompt plus précis. Sur un domaine que le modèle maîtrise, c'est souvent un prompt plus bruyant.

La question qui se pose alors : à quel point ce phénomène est-il systématique ? Et que se passe-t-il quand on pousse les modèles au-delà de quelques instructions ?

Trois profils de dégradation

Le benchmark IFScale (Jaroslawicz et al., 2025) a testé 20 modèles sur des tâches comportant de 10 à 500 instructions simultanées. Les résultats révèlent trois profils de dégradation distincts.

Trois profils de dégradation selon la densité d'instructions

Seuil : quasi parfait, puis chute brutale (o3, gemini-2.5-pro)

Linéaire : dégradation régulière et prévisible (gpt-4.1, claude-3.7-sonnet)

Exponentiel : effondrement rapide, plateau bas (claude-3.5-haiku, llama-4-scout)

Source : IFScale (Jaroslawicz et al., arXiv:2507.11538), 2025.

Les modèles de raisonnement comme o3 ou gemini-2.5-pro suivent un profil à seuil : les performances restent quasi parfaites jusqu’à 150 ou 250 instructions, puis chutent brutalement. Gemini-2.5-pro passe de 98,4 % à 100 instructions à 68,9 % à 500. Le modèle encaisse, encaisse, puis cède d’un coup.

Les grands modèles généralistes comme gpt-4.1 ou claude-3.7-sonnet se dégradent de façon régulière et prévisible. GPT-4.1 passe de 95,4 % à 48,9 %, claude-3.7-sonnet de 94,8 % à 52,7 %. Chaque instruction ajoutée coûte un peu de performance. C’est le profil le plus actionnable, parce qu’on peut estimer la perte avant de la subir.

Les petits modèles comme claude-3.5-haiku ou llama-4-scout s’effondrent rapidement puis se stabilisent sur un plateau bas, entre 7 et 15 %. Au-delà d’une centaine d’instructions, ajouter ou retirer quoi que ce soit ne change presque plus rien : le modèle a déjà décroché.

Ce n'est pas « plus court = mieux ». C'est qu'il existe un seuil au-delà duquel la performance s'effondre ; et ce seuil dépend du modèle.

La nuance est importante. Les modèles de raisonnement résistent remarquablement bien jusqu’à un point critique. Les généralistes se dégradent graduellement mais de façon gérable. Les petits modèles ne sont tout simplement pas conçus pour les prompts denses. Connaître le profil de dégradation du modèle qu’on utilise, c’est savoir combien d’instructions on peut se permettre.

Omission vs modification : comment les modèles échouent

IFScale révèle aussi quelque chose de plus subtil : les modèles n’échouent pas de la même façon selon la densité d’instructions.

À faible densité, quand un modèle se trompe, il se trompe de peu. Il approxime, il interprète mal une contrainte. C’est ce que les chercheurs appellent une erreur de modification : le modèle a essayé, et il s’est trompé.

À haute densité, le mode d’échec change radicalement. Le modèle ne se trompe plus, il oublie. Les instructions ne sont pas mal interprétées, elles sont purement et simplement ignorées. C’est une erreur d’omission. Et les chiffres sont frappants : à 500 instructions, llama-4-scout présente un ratio omission/modification de 34,88x. Pour chaque erreur d’approximation, 35 instructions sont simplement oubliées. Le modèle ne fait pas de son mieux avec un résultat imparfait. Il abandonne.

Ce basculement a une conséquence directe sur la façon dont on conçoit les prompts. À densité modérée, reformuler ou clarifier une instruction peut aider. À haute densité, ça ne sert à rien, parce que le problème n’est pas que le modèle comprend mal. C’est qu’il ne lit même plus.

Il y a aussi un effet de compétition cognitive qui mérite d’être mentionné. L’attention dépensée sur le suivi des instructions dégrade la qualité de la tâche principale elle-même. IFScale montre que o3, à 500 instructions, produit environ 1 500 tokens de sortie où chaque troisième mot doit être un mot-clé imposé. Le modèle consacre tellement de capacité au respect des contraintes formelles qu’il n’en reste plus assez pour la tâche.

Le lien avec mon expérience est direct. P1 et P2 ajoutent des instructions qui entrent en compétition avec la tâche principale d’évaluation. Même si ces instructions sont correctes, elles consomment de l’attention. P3 laisse toute l’attention au modèle pour ce qui compte vraiment.

Le biais positionnel : Lost in the Middle et au-delà

L’instruction dilution est amplifiée par un autre problème bien documenté : le biais positionnel.

Liu et al. (Stanford, 2023) ont montré que les LLMs présentent un biais d’attention en forme de U. Ils traitent mieux ce qui est au début et à la fin du prompt, et dégradent significativement les informations placées au milieu. C’est le phénomène Lost in the Middle, et il touche même les modèles explicitement entraînés pour les longs contextes.

IFScale apporte une nuance inattendue sur la tendance du modèle à favoriser les premières instructions, ce qu’on appelle le biais de primauté. Ce biais suit une courbe non linéaire. À faible densité, en dessous de 100 instructions, il est faible : le modèle traite les instructions de façon relativement uniforme. À densité modérée, entre 150 et 200 instructions, il atteint un pic. Le modèle devient sélectif et favorise les premières instructions aux dépens des suivantes. Au-delà de 300 instructions, le biais converge vers un niveau bas, non pas parce que le modèle est redevenu équitable, mais parce qu’il passe en mode « échec uniforme » : il ignore les instructions de façon homogène, quelle que soit leur position.

En pratique, sur des prompts de longueur modérée (le cas le plus courant en production), la position compte énormément. Ce qui est au début cadre la tâche. Ce qui est à la fin agit comme dernière instruction avant la génération. Ce qui est au milieu est le plus vulnérable à l’oubli. Et c’est une raison de plus de garder les prompts courts : plus le prompt est long, plus le « milieu » est grand, et plus le biais en U est prononcé.

Ce n’est pas toujours le plus court qui gagne

Le message de cet article n’est pas « faites des prompts courts ». C’est qu’au-delà d’un certain seuil, l’ajout d’information devient contre-productif, et ce seuil est plus bas qu’on ne le pense.

Ce seuil dépend de plusieurs choses. D’abord du modèle : les modèles de raisonnement comme o3 ou gemini-2.5-pro résistent beaucoup mieux à la densité d’instructions que les modèles plus petits. Un prompt qui fonctionne sur gpt-4.1 peut s’effondrer sur claude-3.5-haiku.

Ensuite de la tâche. Mon P3 gagne parce que GPT-4.1 connaît déjà le CECRL. Il a été entraîné sur des volumes massifs de données d’évaluation linguistique. Sur un domaine inconnu du modèle, un framework métier propriétaire, un jargon spécialisé non publié, un prompt détaillé reste nécessaire. C’est justement parce que le modèle ne sait pas qu’il faut lui dire.

Et enfin de la nature de l’information ajoutée. Toute la différence est entre information redondante et information nouvelle. Reformuler ce que le modèle sait (les descripteurs CECRL, la liste des niveaux) crée du bruit. Fournir ce que le modèle ne sait pas (un barème propriétaire, des critères métier spécifiques) crée du signal.

La règle n'est pas « soyez court ». La règle est : ne reformulez pas ce que le modèle sait. Ajoutez seulement ce qu'il ne sait pas.

En pratique, ça demande de connaître les frontières du modèle, ce qui fait partie de son entraînement et ce qui n’en fait pas partie. Cette frontière est rarement documentée. Elle se découvre en testant.

Prompt compression : compresser plutôt que supprimer

Dans beaucoup de cas d’usage en production (RAG, analyse de documents, contextes longs), on ne peut pas simplement raccourcir le prompt. Le contexte est long parce que le problème l’exige.

La recherche sur la prompt compression offre une alternative intéressante : plutôt que de supprimer de l’information, on la compresse. On élimine le bruit tout en préservant le signal.

La première famille d’approches, dite text-to-text, transforme le texte en un texte plus court, par élagage des tokens non informatifs ou par résumé. LLMLingua-2 de Microsoft atteint des taux de compression de 3 à 6x avec des performances comparables au texte non compressé. Sur NaturalQuestions, le F1 reste à 71,90 avec 3,9x de compression. Sur GSM8K, l’exact match atteint 79,08 à 5x. On divise la taille du contexte par 4 ou 5, et la performance reste quasi identique.

La seconde famille, text-to-vector, encode le texte en représentations vectorielles compactes, ce que la littérature appelle des gist tokens. La technique du gisting atteint jusqu’à 26x de compression avec une perte minimale. L’idée : au lieu de faire lire 10 000 tokens au modèle, on les encode en quelques centaines de vecteurs qui capturent l’essentiel de l’information.

LLM-DCP (Jiang et al., 2024) va plus loin en modélisant la compression comme un processus de décision de Markov. Chaque token est évalué séquentiellement, garder ou supprimer, en fonction de sa contribution à la tâche. Le résultat : 12,9x de compression.

La compression est une alternative à la troncature. Elle préserve le signal en éliminant le bruit (exactement ce que l'instruction dilution nous empêche de faire manuellement).

Quand le contexte est long, la question n’est pas « comment raccourcir ? » mais « comment compresser sans perdre le signal ? ». C’est un problème d’ingénierie, pas de rédaction.

Implications pratiques

De tout ça, je retiens quelques principes que j’applique maintenant au quotidien.

Le premier, c’est l’atomicité. Une instruction par prompt, formulée en une phrase si possible. Quand une tâche est complexe, je la découpe en étapes plutôt que d’allonger le prompt.

Le second, c’est la position. L’instruction principale va au début, les contraintes critiques à la fin, le contexte et les exemples au milieu, en sachant qu’ils seront moins bien retenus.

Le troisième, c’est le test sur volume. Un prompt qui fonctionne sur 10 exemples peut s’effondrer sur 700. Les résultats d’IFScale montrent que les profils de dégradation sont prévisibles : il vaut la peine de tester à différentes densités pour trouver le seuil de son modèle.

Et enfin, quand un prompt contient plusieurs contraintes, un rappel en fin de prompt (« assure-toi de respecter toutes les contraintes ci-dessus ») peut réduire le taux d’omission. C’est un palliatif, pas une solution, mais il fonctionne sur les profils de dégradation linéaire.

Mise à jour : la piste de la répétition du prompt

Suite à la publication de cet article, Xiaoou Wang (Ingénieur en humanités numériques, Université Côte d’Azur) m’a suggéré une approche complémentaire que je n’avais pas couverte : la répétition du prompt.

L’idée vient d’un paper de Google Research : Prompt Repetition Improves Non-Reasoning LLMs (Leviathan, Kalman, Matias, 2025). Le principe est simple : au lieu d’envoyer <QUERY>, on envoie <QUERY><QUERY>. On répète le prompt tel quel.

Le mécanisme exploite une propriété des transformers causaux. Dans un modèle classique, les tokens passés ne peuvent pas « voir » les tokens futurs. Le début du prompt est traité sans le contexte de la fin. En répétant le prompt, chaque token de la seconde copie peut attendre à tous les tokens de la première. On corrige le biais directionnel sans modifier le contenu.

Les résultats sont nets : sur 7 modèles (Gemini, GPT, Claude, Deepseek) et 7 benchmarks, la répétition gagne dans 47 cas sur 70, avec zéro défaite (test de McNemar). Et contrairement à d’autres techniques comme le Chain of Thought, la répétition n’augmente ni la latence ni le nombre de tokens générés. Le surcoût se limite au prefill, qui est parallélisable.

C’est une approche qui s’inscrit bien dans ce que nous avons vu. Là où l’instruction dilution nous dit de ne pas ajouter de bruit, la répétition ne modifie pas le contenu : elle renforce le signal existant en donnant au modèle une seconde passe d’attention sur les mêmes informations. Les chercheurs notent d’ailleurs que les modèles de raisonnement entraînés par RL apprennent souvent à répéter eux-mêmes des parties du prompt dans leur chaîne de pensée. La répétition externalise ce comportement dans le prefill.

Je ne l’ai pas encore testée personnellement sur mes données, mais les benchmarks sont solides et la technique est triviale à déployer. C’est une piste que je compte explorer, et qui mérite d’être connue.

Conclusion

L’instruction dilution n’est pas une intuition. C’est un phénomène mesurable, reproductible, et la recherche commence à bien le comprendre. Au-delà d’un certain seuil, ajouter de l’information à un prompt dégrade les performances du modèle. Ce seuil dépend du modèle, de la tâche, et de la nature de l’information ajoutée.

Les guides de prompting donnent des techniques. La recherche explique pourquoi certaines marchent et d’autres non. Non pas parce que les guides sont faux, mais parce qu’ils sont écrits pour un contexte, la conversation, qui ne se transfère pas directement à un autre, la production à l’échelle.

Pour écrire des prompts qui fonctionnent à l’échelle, il faut comprendre ce qui se passe dans l’attention du modèle. Savoir ce qu’il sait déjà, ce qu’il ne sait pas, et où se situe le point de basculement. Et ça, ça ne s’apprend que par l’expérimentation. En se trompant sur 700 exemples et en comprenant pourquoi.

Si vous voulez systématiser cette expérimentation, des outils comme promptfoo ou le Playground d’OpenAI permettent de comparer des variantes de prompts sur un jeu de données, de mesurer les régressions entre versions, et de trouver ce fameux seuil de basculement pour chaque modèle.

LLMs can code. But can they maintain?

2026-03-10T00:00:00+00:00

I’ve been coding for nearly thirty years. Twenty of them professionally. And I’m going to say something that would have seemed absurd just four years ago: artificial intelligences vastly outperform me in terms of code production. In speed, in volume, often in edge case coverage.

This isn’t a surrender. It’s an honest observation, and I’m at peace with it. These tools have made me more effective than I’ve ever been. Copilot, Claude, GPT — depending on the context, they regularly impress me. For implementing a known algorithm, wiring up an API, writing unit tests, or refactoring a function, their power is real and now undeniable.

But for a while, something had been nagging at me. An intuition I couldn’t quite articulate. This paper articulated it for me.

It’s titled SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration, published in early March 2026 on arXiv by researchers from Sun Yat-sen University and Alibaba Group. It asks a simple and unsettling question: we know LLMs write code — but do they write code that holds up over time?

The problem nobody measures

To understand what this work contributes, you need to understand how LLMs are evaluated on code today. Classic benchmarks (HumanEval, SWE-bench, LiveCodeBench) all ask the same fundamental question: the agent receives a problem, produces a solution — does it pass the tests?

This is what researchers call “snapshot” evaluation: a photo at a single point in time. The model fixes a bug, generates a function, proposes a patch. We check. It works or it doesn’t.

Classic evaluation (snapshot)

One problem → one solution → tests pass. The agent is evaluated on a single act of production. What came before and what comes after does not exist.

→

What SWE-CI measures

Start from a real codebase, evolve the project across dozens of successive iterations, and measure whether the code remains maintainable over time.

The problem? In real life, software isn’t born in a single night and doesn’t die after its first deployment. It lives, mutates, ages. Features get added, interfaces change, colleagues (or agents) pick up what we’ve written. What matters then isn’t just that a working patch was produced — it’s that this patch didn’t mortgage the next fifty.

An agent that hard-codes a fragile workaround and an agent that writes clean, extensible code can both pass the same tests. Their difference only becomes visible at the third or fourth change.

This is precisely what Lehman’s laws of software evolution theorized back in the 1970s: software quality degrades naturally as it evolves. And classic literature estimates that maintenance accounts for 60 to 80% of the total lifecycle cost of software. Maintenance, not initial development.

How SWE-CI works

The benchmark is carefully constructed. The researchers combed GitHub for serious Python projects: at least three years of active maintenance, at least 500 stars, a real test suite, a permissive license. From 4,923 filtered projects, they ultimately retained 100 cases from 68 distinct repositories.

For each case, they select two commits on the main branch: a starting commit (the “base”) and a target commit (the “oracle”), separated on average by 233 days and 71 commits of real development history. Between the two, at least 500 lines of source code have changed.

The agent must evolve the base toward the oracle, but not all at once. It proceeds through successive iterations, as a team would in continuous integration. At each turn:

An “architect” agent analyzes the failing tests, identifies root causes in the code, and produces a requirements document in natural language — no more than five priority requirements, framed in terms of expected behavior, without prescribing the implementation.

A “developer” agent reads this document, understands the behavioral contracts, plans its modifications, and writes the code. Without running the tests itself — the external system does that.

This dual protocol reproduces what happens in a real team. The architect doesn’t code. The developer doesn’t over-engineer. And it’s the cumulative result across the entire sequence that is measured.

How to measure maintainability

The researchers introduce two original metrics. The first, the normalized change, measures at each iteration how many additional tests pass relative to the base — with a symmetric penalty if tests that were passing get broken (what we call a regression).

The second, the EvoScore, aggregates these measurements across the entire sequence with increasing weight toward the later iterations. The idea is simple and sound: truly maintainable code is code that remains easy to modify as evolution progresses. An agent that succeeds in the early iterations by accumulating technical debt, then collapses afterward, will be penalized. An agent that progresses steadily, even slowly, will be rewarded.

What the results show

The researchers evaluated 18 models from 8 different providers, spending over 10 billion tokens in total. Three major observations emerge.

1. LLMs are improving — fast

Across all model families, recent versions systematically outperform their predecessors. And models released after early 2026 show particularly marked gains. This isn’t linear progression: it’s acceleration. What was difficult a year ago is beginning to be solved.

Over the entire observation period, the Claude Opus series stands out clearly at the top, with GLM-5 as another remarkable performer.

EvoScore by model family — general trend

Schematic representation of EvoScore (γ=1) progression by model release date. Post-2026 models show markedly stronger gains. Source: SWE-CI, Figure 4.

2. Providers have different priorities

The γ parameter of the EvoScore allows varying the weight given to early versus late iterations. When you raise γ, you favor models that maintain quality over the long term. When you lower it, you reward immediate gains.

What the researchers observe is revealing: rankings change depending on γ. MiniMax, DeepSeek, and GPT favor long-term gains. Kimi and GLM prioritize quick returns. Qwen, Doubao, and Claude remain relatively stable regardless of weighting. The authors interpret this as a reflection of training choices — each provider orients its models differently, and it shows.

3. Regression remains the great unsolved problem

This is the most striking observation, and the most directly useful for anyone using AI in their projects.

A regression, in development, is when a change breaks something that was working before. It’s every experienced developer’s nightmare. And this is precisely where current LLMs struggle the most.

"Zero regression" rate — proportion of trials with no regression introduced

Claude Opus 4.6

0.76

Claude Opus 4.5

0.51

Kimi-K2.5

0.37

GLM-5

0.36

GPT-5.2

0.23

Qwen3.5-plus

0.20

DeepSeek-V3.2

0.20

MiniMax-M2.5

0.20

MiniMax-M2.1

0.15

Kimi-K2-Thinking

0.15

GLM-4.7 / GLM-4.6

0.14

Kimi-K2-instruct

0.12

Qwen3-coder-plus

0.10

Doubao / Qwen3-Max

0.08–0.09

Proportion of trials in which no regression was introduced throughout maintenance. Most models stay below 0.25. Only two models exceed 0.5. Source: SWE-CI, Figure 6.

In concrete terms: if you ask most current LLMs to maintain a project over time, in more than 75% of cases, they will break something that was working. Not intentionally. Not through negligence. Through lack of a view of the whole — exactly like a junior developer who fixes a bug without reading the rest of the code.

Reading note. These figures evaluate agents in autonomous mode, without human review between iterations. In practice, an experienced developer supervising AI suggestions will catch these regressions before they accumulate. The paper measures the intrinsic capability of models — not their usefulness in pair programming, which remains very real.

What this clarifies for me

When I started building phpmetrics, the central question was: how do you know, objectively, whether a PHP project is healthy? Not whether it compiles. Not whether it passes tests. But whether the internal structure of the code will allow working with it six months from now without suffering.

Cyclomatic complexity. Coupling between modules. Class cohesion. Component instability. These metrics aren’t glamorous. They don’t answer the question “does it work?” — they answer the question “will it hold?”

ast-metrics extends this logic by going deeper into the syntactic structure of code, independent of language. The idea remains the same: give a picture of maintainability, not just functionality.

What SWE-CI has just formalized for AI agents is exactly this distinction. And it struck me reading the paper: the researchers built, to evaluate LLMs, the same type of reasoning that has guided these tools from the beginning.

Making it work is necessary. Making it last is different. The two are not measured the same way.

LLMs excel today at making things work. They are progressing, fast, on the question of making things last. But they’re not there yet — with one exception. And this exception is not trivial: Claude Opus 4.6 reaches a zero-regression rate of 0.76. That’s remarkable. It’s also proof that it’s possible, and that the rest of the market will follow.

What this means in practice

For me, the practical lesson is twofold.

First, maintainability metrics are not a luxury. They may have been when code was entirely human and teams naturally had a memory of the project. They become essential when code is generated at industrial speed, with tools that have no memory between sessions and no vision of the global architecture. Without external measurement, you’re flying blind.

Second, AI doesn’t replace architecture — it needs it all the more. An LLM generating a function does so in a local context, without seeing adjacent modules, without understanding the constraints that guided past decisions. The more we delegate code production to these tools, the more important it becomes for someone (a human) to maintain the overall vision, set the invariants, define the contracts.

This isn’t a criticism of AI. It’s a description of what it is today: an extraordinarily powerful production tool that needs a framework so its power doesn’t turn against itself.

Thirty years of code have taught me that the truly costly problems are almost never bugs. They’re architectural errors discovered too late, poorly thought-out dependencies, abstractions that don’t hold up over time. LLMs haven’t solved that yet. And that’s precisely why tools like phpmetrics or ast-metrics remain useful — not as a bulwark against AI, but as a necessary complement.

The SWE-CI paper is available on arXiv: arxiv.org/abs/2603.03823. It’s accessible, well-written, and its data is public on Hugging Face. If you work with AI agents on real projects, it’s worth a read.

Les LLMs savent coder. Mais savent-ils maintenir ?

2026-03-10T00:00:00+00:00

Je code depuis près de trente ans. Vingt ans à titre professionnel. Et je vais dire quelque chose qui aurait semblé absurde il y a encore quatre ans : les intelligences artificielles me surpassent largement en termes de production de code. En vitesse, en volume, souvent en couverture de cas limites.

Ce n’est pas une capitulation. C’est un constat honnête, et je le vis bien. Ces outils m’ont rendu plus efficace que je ne l’ai jamais été. Copilot, Claude, GPT - selon les contextes, ils m’épatent régulièrement. Pour implémenter un algorithme connu, câbler une API, écrire des tests unitaires ou refactoriser une fonction, leur puissance est réelle et désormais indiscutable.

Mais depuis un moment, quelque chose me tracassait. Une intuition que je n’arrivais pas tout à fait à formuler. Ce papier l’a formulée pour moi.

Il s’intitule SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration, publié début mars 2026 sur arXiv par des chercheurs de Sun Yat-sen University et Alibaba Group. Il pose une question simple et dérangeante : on sait que les LLMs écrivent du code - mais est-ce qu’ils écrivent du code qui tient dans le temps ?

Le problème qu’on ne mesure pas

Pour comprendre l’apport de ce travail, il faut comprendre comment on évalue aujourd’hui les LLMs sur le code. Les benchmarks classiques (HumanEval, SWE-bench, LiveCodeBench) posent tous la même question fondamentale : l’agent reçoit un problème, produit une solution, est-ce que ça passe les tests ?

C’est ce que les chercheurs appellent l’évaluation « snapshot » : une photo à un instant T. Le modèle corrige un bug, génère une fonction, propose un patch. On vérifie. Ça marche ou pas.

Évaluation classique (snapshot)

Un problème → une solution → les tests passent. L'agent est évalué sur un seul acte de production. Ce qui précède et ce qui suit n'existe pas.

→

Ce que SWE-CI mesure

Partir d'une base de code réelle, faire évoluer le projet sur des dizaines d'itérations successives, et mesurer si le code reste maintenable au fil du temps.

Le problème ? Dans la vraie vie, un logiciel ne naît pas en une nuit et ne meurt pas après son premier déploiement. Il vit, mute, vieillit. Des fonctionnalités s’ajoutent, des interfaces changent, des collègues (ou des agents) reprennent ce qu’on a écrit. Ce qui compte alors, ce n’est pas seulement qu’un patch fonctionnel ait été produit - c’est que ce patch n’ait pas hypothéqué les cinquante suivants.

Un agent qui hard-code une rustine fragile et un agent qui écrit du code propre et extensible peuvent tous les deux passer les mêmes tests. Leur différence n'est visible qu'au troisième ou quatrième changement.

C’est précisément ce que les lois de Lehman sur l’évolution logicielle théorisaient dès les années 1970 : la qualité d’un logiciel se dégrade naturellement à mesure qu’il évolue. Et la littérature classique estime que la maintenance représente entre 60 et 80 % du coût total du cycle de vie d’un logiciel. La maintenance, pas le développement initial.

Comment SWE-CI fonctionne

Le benchmark est construit avec soin. Les chercheurs ont parcouru GitHub à la recherche de projets Python sérieux : au moins trois ans de maintenance active, au moins 500 étoiles, une vraie suite de tests, une licence permissive. Sur 4 923 projets filtrés, ils ont finalement retenu 100 cas issus de 68 dépôts distincts.

Pour chaque cas, ils choisissent deux commits sur la branche principale : un commit de départ (la « base ») et un commit cible (l’« oracle »), séparés en moyenne par 233 jours et 71 commits de vrai historique de développement. Entre les deux, au moins 500 lignes de code source ont changé.

L’agent doit faire évoluer la base vers l’oracle, mais pas en une seule fois. Il procède par itérations successives, comme une équipe le ferait en intégration continue. À chaque tour :

Un agent « architecte » analyse les tests qui échouent, identifie les causes racines dans le code, et produit un document de requirements en langage naturel - pas plus de cinq exigences prioritaires, formulées en termes de comportement attendu, sans prescrire l’implémentation.

Un agent « développeur » lit ce document, comprend les contrats comportementaux, planifie ses modifications, et écrit le code. Sans exécuter les tests lui-même - c’est le système externe qui le fait.

Ce double protocole reproduit ce qui se passe dans une vraie équipe. L’architecte ne code pas. Le développeur ne sur-conçoit pas. Et c’est le résultat cumulé sur toute la séquence qui est mesuré.

Comment mesurer la maintenabilité

Les chercheurs introduisent deux métriques originales. La première, le normalized change, mesure à chaque itération combien de tests supplémentaires passent par rapport à la base - avec une pénalité symétrique si des tests qui passaient sont cassés (ce qu’on appelle une régression).

La seconde, l’EvoScore, agrège ces mesures sur toute la séquence avec un poids croissant vers les dernières itérations. L’idée est simple et juste : un code vraiment maintenable est un code qui reste facile à modifier quand l’évolution avance. Un agent qui réussit les premières itérations en accumulant de la dette technique, puis s’effondre ensuite, sera pénalisé. Un agent qui progresse régulièrement, même lentement, sera récompensé.

Ce que les résultats montrent

Les chercheurs ont évalué 18 modèles de 8 fournisseurs différents, en dépensant plus de 10 milliards de tokens au total. Trois observations majeures ressortent.

1. Les LLMs progressent - vite

Dans toutes les familles de modèles, les versions récentes surpassent systématiquement les précédentes. Et les modèles sortis après début 2026 affichent des gains particulièrement marqués. Ce n’est pas une progression linéaire : c’est une accélération. Ce qui était difficile il y a un an commence à être résolu.

Sur toute la période d’observation, la série Claude Opus se distingue nettement en tête, avec GLM-5 comme autre performeur remarquable.

EvoScore par famille de modèles — tendance générale

Représentation schématique de la progression de l'EvoScore (γ=1) selon la date de sortie des modèles. Les modèles post-2026 montrent des gains nettement plus marqués. Source : SWE-CI, Figure 4.

2. Les fournisseurs ont des priorités différentes

Le paramètre γ de l’EvoScore permet de faire varier le poids donné aux premières versus aux dernières itérations. Quand on fait monter γ, on favorise les modèles qui maintiennent la qualité sur le long terme. Quand on le fait baisser, on récompense les gains immédiats.

Ce que les chercheurs observent est révélateur : les classements changent selon γ. MiniMax, DeepSeek et GPT favorisent les gains à long terme. Kimi et GLM privilégient les retours rapides. Qwen, Doubao et Claude restent relativement stables quelle que soit la pondération. Les auteurs interprètent ça comme un reflet des choix de formation - chaque fournisseur oriente ses modèles différemment, et ça se voit.

3. La régression reste le grand problème non résolu

C’est l’observation la plus parlante, et la plus directement utile pour quiconque utilise l’IA dans ses projets.

Une régression, en développement, c’est quand une modification casse quelque chose qui fonctionnait avant. C’est le cauchemar de tout développeur expérimenté. Et c’est précisément là que les LLMs actuels peinent le plus.

Taux "zéro régression" — proportion d'essais sans aucune régression introduite

Claude Opus 4.6

0.76

Claude Opus 4.5

0.51

Kimi-K2.5

0.37

GLM-5

0.36

GPT-5.2

0.23

Qwen3.5-plus

0.20

DeepSeek-V3.2

0.20

MiniMax-M2.5

0.20

MiniMax-M2.1

0.15

Kimi-K2-Thinking

0.15

GLM-4.7 / GLM-4.6

0.14

Kimi-K2-instruct

0.12

Qwen3-coder-plus

0.10

Doubao / Qwen3-Max

0.08–0.09

Proportion des essais dans lesquels aucune régression n'a été introduite tout au long de la maintenance. La plupart des modèles restent sous 0.25. Seuls deux modèles dépassent 0.5. Source : SWE-CI, Figure 6.

Traduction concrète : si vous demandez à la plupart des LLMs actuels d’entretenir un projet sur la durée, dans plus de 75% des cas, ils vont casser quelque chose qui marchait. Pas intentionnellement. Pas par négligence. Par manque de vision de l’ensemble - exactement comme un développeur junior qui règle un bug sans lire le reste du code.

Note de lecture. Ces chiffres évaluent des agents en mode autonome, sans revue humaine entre les itérations. Dans la pratique, un développeur expérimenté qui supervise les suggestions de l'IA attrapera ces régressions avant qu'elles s'accumulent. Le paper mesure la capacité intrinsèque des modèles - pas leur utilité en pair programming, qui reste très réelle.

Ce que ça éclaire pour moi

Quand j’ai commencé à construire phpmetrics, la question centrale était : comment savoir, objectivement, si un projet PHP est en bonne santé ? Pas si ça compile. Pas si ça passe les tests. Mais si la structure interne du code va permettre qu’on y travaille encore dans six mois sans souffrir.

La complexité cyclomatique. Le couplage entre modules. La cohésion des classes. L’instabilité des composants. Ces métriques n’ont rien de glamour. Elles ne répondent pas à la question « ça marche ? » - elles répondent à la question « ça va tenir ? »

ast-metrics prolonge cette logique en allant plus profond dans la structure syntaxique du code, indépendamment du langage. L’idée reste la même : donner une image de la maintenabilité, pas seulement de la fonctionnalité.

Ce que SWE-CI vient de formaliser pour les agents IA, c’est exactement cette distinction. Et ça m’a frappé en lisant le paper : les chercheurs ont construit, pour évaluer les LLMs, le même type de raisonnement que celui qui a guidé ces outils depuis le début.

Faire fonctionner, c'est nécessaire. Faire durer, c'est différent. Les deux ne se mesurent pas de la même façon.

Les LLMs excellent aujourd’hui à faire fonctionner. Ils progressent, vite, sur la question de faire durer. Mais ils n’y sont pas encore - sauf exception. Et cette exception n’est pas anodine : Claude Opus 4.6 atteint un taux sans régression de 0.76. C’est remarquable. C’est aussi la preuve que c’est possible, et que le reste du marché va suivre.

Ce que ça implique, concrètement

Pour moi, la leçon pratique est double.

D’abord, les métriques de maintenabilité ne sont pas un luxe. Elles l’étaient peut-être quand le code était entièrement humain et que les équipes avaient naturellement une mémoire du projet. Elles deviennent essentielles quand on génère du code à vitesse industrielle, avec des outils qui n’ont pas de mémoire entre les sessions et aucune vision de l’architecture globale. Sans mesure externe, on avance à l’aveugle.

Ensuite, l’IA ne remplace pas l’architecture - elle en a d’autant plus besoin. Un LLM qui génère une fonction le fait dans un contexte local, sans voir les modules adjacents, sans comprendre les contraintes qui ont guidé les décisions passées. Plus on délègue la production de code à ces outils, plus il devient important que quelqu’un (un humain) maintienne la vision d’ensemble, fixe les invariants, définit les contrats.

Ce n’est pas une critique de l’IA. C’est une description de ce qu’elle est aujourd’hui : un outil de production extraordinairement puissant, qui a besoin d’un cadre pour que sa puissance ne se retourne pas contre elle-même.

Trente ans de code m’ont appris que les problèmes vraiment coûteux ne sont presque jamais des bugs. Ce sont des erreurs d’architecture découvertes trop tard, des dépendances mal pensées, des abstractions qui ne tiennent pas à l’épreuve du temps. Les LLMs n’ont pas encore résolu ça. Et c’est précisément pour ça que des outils comme phpmetrics ou ast-metrics restent utiles - pas comme rempart contre l’IA, mais comme complément nécessaire.

Le paper SWE-CI est disponible sur arXiv : arxiv.org/abs/2603.03823. Il est accessible, bien écrit, et ses données sont publiques sur Hugging Face. Si vous travaillez avec des agents IA sur des projets réels, ça vaut le détour.

How We Unblocked Our PR Flow in 4 Months

2025-11-16T00:00:00+00:00

Six months ago, I joined a talented, technically strong engineering team filled with developers who genuinely cared about quality. It wasn’t a team in trouble. Far from it. And yet, something was seriously blocking our ability to deliver: Pull Requests were taking far too long to review and merge.

Not a few hours. Not two or three days.
Sometimes close to three weeks between opening and merging a PR.

That’s what pushed me to write this article. Not to present a magic method or a heroic fix, but simply to share a gradual cultural shift applied to a problem many teams face without naming it.

When a skilled team gets slowed down by its own PRs

The first thing I noticed was simple: our PRs were too big. They often represented an entire sprint’s worth of work (sometimes more). No one can review that “between meetings”. You need the right moment. And that right moment never comes.

On top of that, an implicit habit had formed over the years: leads review PRs. It wasn’t written anywhere, but it had become the rule. This created an automatic bottleneck.

We also lacked visibility into the flow. Nobody really knew which PR was waiting on whom, or for how long. There was no lack of goodwill, just a structural invisibility.

When I started looking at the data, one number stood out above all others: 19 days on average between opening a PR and merging it.

The initial cultural shock

When I started talking about changing some habits, I could feel a quiet apprehension. Nothing confrontational. Just that silent, universal developer question:

Is this going to make our work harder?

Touching the way a team creates, reviews and merges PRs is always a small cultural shock. These are deeply anchored gestures. They shape the daily routine. Changing them feels like poking at the team’s internal gravity.

But the pushback I expected never came.
No resistance.
No tension.

Just a cautious curiosity, and above all, a willingness to try.

The psychological mechanisms slowing everything down

Oversized PRs aren’t only a technical issue. They’re a cognitive issue.

A big PR is intimidating. It triggers fear of missing something, fear of not understanding fully, fear of making a wrong call. It activates a defensive procrastination mechanism: “I’ll review it when I have a real chunk of time.” That time does not exist in a normal workday.

Coming back to a PR that has been open for five days requires considerable mental effort. Reloading the context, reinterpreting the intent, rebuilding the mental stack. It’s tiring. And that cognitive cost makes you hesitate even more.

This wasn’t a matter of motivation. It was a matter of cognitive load.

What we changed and how it happened

Our first step was to introduce a simple goal: small PRs. Not as a rule. Not as a mandate. Just a shared intention: open PRs more frequently so they become smaller and easier to review.

Very quickly, PRs became easier to write, easier to review, and easier to maintain. A 150 line PR doesn’t trigger any mental resistance. You review it almost without thinking.

The second step was to share the reviewing work. Not to help the leads, but simply because small PRs invite participation. Reviewing becomes lighter. Everyone starts contributing. This change also happened naturally.

The third step was to make the flow visible. We used OctoFirst, the tool I’ve been building for the past two years. At first, it was just a personal dashboard to understand how my teams worked. Then it became an analysis tool. Then a cultural support. Then a way to help teams steadily change their habits.

And that’s when things accelerated.

When the team could see which PRs were stuck, see the interactions, see the progress, the shift no longer depended on explanations. It became intuitive.

The results after 4 months

Four months later, the metrics looked nothing like before.

The average time went from 19 days to 3 calendar days.
The first review arrived in about ten hours.
The review ping pong took roughly twenty hours.
The merge followed soon after.

We moved from a stalled flow to a fluid one.
It wasn’t magic.
It wasn’t overwork.
It wasn’t even a new process.

It was a cultural shift.

PRs naturally became smaller. Reviews became a reflex. Collaboration increased dramatically.
The interaction graph had nothing to do with what it looked like before.

The team’s interaction graph in OctoFirst, after 4 months of new practices.

The team collaborates better, and leads are no longer the central bottleneck.

Today: a fully embedded culture

Six months after this shift, the flow is simpler, lighter and clearer.
What strikes me the most is not the reduction of merge times, nor the charts, nor the metrics.

It’s that everything has become normal.

And that’s what defines a culture: the moment when no one thinks about “the old way” anymore, because the new way makes so much sense that it takes over without effort.

Which brings me to OctoFirst.

For more than fifteen years, I’ve been building open source tools (a lot of them). I’ve created tools to measure, analyze, understand. For a long time, this work lived in the shadows: useful for me, useful for a few teams around me, but nothing more. I never thought of “building a product”. I just wanted to understand what teams really experience, beyond impressions.

Then, slowly, OctoFirst took a shape I didn’t fully expect: a tool that doesn’t just show statistics, but helps teams see what they usually can’t see. To understand their internal dynamics. To change habits gently. To regain fluidity.

And honestly, it’s the first time I’ve thought: “Maybe what I’m building could really help more people.”

Not because it’s revolutionary, or “AI powered”. But because I see the concrete, measurable, human effect it can have on a team.

Today, OctoFirst is still in beta. It’s moving quickly, mostly thanks to the feedback I receive. And I need that feedback.
If your team struggles with PR latency, if you want to understand your internal interactions, or if you’re simply curious, I’d love for you to try it and tell me what works, what doesn’t, and what should be improved.

There’s no hidden strategy. I’m just trying to improve a tool I’ve been building for a long time, and which is finally taking the shape of a real product.

If you want to take a look or help me improve it: ➡️ app.octofirst.com

And if you’d like to discuss, compare practices, or share your experience, reach out.
These conversations are precisely what helps this tool grow.

Thank you.

Comment nous avons débloqué notre flux de PRs en 4 mois

2025-11-15T00:00:00+00:00

Il y a six mois, je suis arrivé dans une équipe talentueuse, solide techniquement, avec des développeurs investis et attentifs à la qualité. Ce n’était pas une équipe en difficulté, loin de là. Pourtant, quelque chose bloquait fortement notre capacité à livrer : les Pull Requests mettaient beaucoup trop de temps à être relues et mergées.

Pas quelques heures, ou deux ou trois jours. Parfois près de trois semaines entre l’ouverture et le merge.

Et c’est ce qui m’a poussé à documenter ce qui suit. Pas une méthode magique ou un geste héroïque, juste un changement culturel progressif, appliqué à un problème que beaucoup d’équipes rencontrent sans jamais vraiment le nommer.

Quand une équipe compétente se retrouve ralentie par ses propres PRs

Le premier constat que j’ai fait est simple : les PRs étaient trop grosses. Elles représentaient souvent un livrable complet de sprint (voire parfois plusieurs), ce qui les rendait naturellement difficiles à relire. Le reviewer devait tout recharger en tête : le contexte, les intentions, les impacts. On n’aborde pas ce genre de PR « entre deux réunions » ; on attend d’avoir le bon moment. Et ce moment n’arrive jamais.

D’autant qu’un mécanisme implicite s’était installé avec les années : les leads relisent. Ce n’était écrit nulle part, c’était juste « comme ça ». Résultat : une concentration involontaire des relectures, et donc un goulot d’étranglement mécanique.

Enfin, nous manquions de visibilité sur le flux. Personne ne savait exactement quelles PRs attendaient quoi, ni depuis combien de temps. Il n’y avait pas d’intention, pas de mauvaise volonté, juste une invisibilité structurelle.

Quand j’ai commencé à regarder les chiffres, le plus froid de tous était celui-ci : 19 jours en moyenne entre l’ouverture d’une PR et son merge.

Le choc culturel du début

Quand j’ai commencé à évoquer l’idée de changer certaines habitudes, j’ai senti une appréhension silencieuse. Rien de frontal. Juste cette question que tout développeur se pose, même inconsciemment :

Est ce que ça va compliquer notre travail ?

Toucher à la façon de créer, relire et merger des PRs est toujours un petit choc culturel. Ce sont des gestes ancrés, routiniers, presque invisibles. Quand on y touche, on touche à la structure même du quotidien.

Mais ce que je redoutais ne s’est pas produit. Il n’y a pas eu de forte résistance, ni de crispation.

Juste une curiosité prudente, et surtout une volonté d’essayer.

Les mécanismes psychologiques qui ralentissaient tout

Les grosses PRs ne posent pas seulement un problème technique. Elles posent un problème cognitif.

Une PR massive intimide. Elle crée de la peur de mal faire, de passer à côté, de ne pas comprendre. Elle déclenche une forme de procrastination défensive : « Je la lirai quand j’aurai un vrai moment ». Mais ce moment n’existe pas dans une journée normale.

Revenir sur une PR vieille de cinq jours demande un effort mental considérable. On doit tout recharger, tout réinterpréter, retrouver le fil. C’est épuisant. Et ce coût mental nourrit encore plus l’hésitation à se lancer.

Ce n’était pas une question de volonté. C’était une question de charge cognitive.

Ce que nous avons changé, et comment

La première étape a été d’introduire un objectif simple : des PRs petites. Pas par injonction. Pas avec une règle stricte. Juste une intention commune : ouvrir des PR plus souvent, pour réduire la taille, donc pour réduire l’effort.

Très vite, les PRs ont commencé à devenir plus faciles à écrire, plus faciles à relire, plus faciles à maintenir. Une PR de 150 lignes ne déclenche plus aucun mécanisme de défense. On la lit presque naturellement.

La deuxième étape a été de distribuer la relecture. Pas pour faire plaisir aux leads. Pour que chacun contribue à la fluidité du flux. Et là aussi, le changement s’est fait naturellement : une PR petite n’intimide personne, donc tout le monde ose relire.

Enfin, la troisième étape a été de rendre le flux visible. Nous avons utilisé OctoFirst, l’outil que je construis depuis deux ans, déjà. Au départ, c’était juste un tableau de métriques pour comprendre le fonctionnement de mes équipes. Puis c’est devenu un outil d’analyse. Puis un support de changement culturel. Puis un moyen d’accompagner les équipes dans leurs habitudes.

Et c’est là que tout s’est accéléré.

Lorsque l’équipe a pu voir les PRs bloquées, voir les interactions, voir les progrès, la transformation ne dépendait plus d’explications. Elle devenait naturelle.

Le résultat après 4 mois

4 mois plus tard, les métriques étaient méconnaissables.

Le temps moyen était passé de 19 jours à 3 jours calendaires.
La première review arrivait en une dizaine d’heures.
Le ping pong de commentaires prenait une vingtaine d’heures.
Le merge se faisait dans la foulée.

Nous étions passés d’un flux immobile à un flux fluide.
Ce n’était pas de la magie, ni même du sur effort. Ce n’était même pas un nouveau process. C’était juste une culture différente.

Les PRs étaient devenues naturellement petites. Les relectures étaient devenues un réflexe. La collaboration avait explosé.
Le graphe des interactions ne ressemblait plus du tout à ce qu’il était.

Le graphe des interactions de l'équipe sur Octofirst, après 4 mois de changement de pratiques.

Les équipes collaborent bien, et les lead ne centralisent plus tout

Aujourd’hui : une culture installée

Six mois après cette transformation, notre flux est devenu plus simple, plus léger, plus lisible. Et ce qui me frappe le plus, ce n’est pas la baisse du temps de merge, ni les graphiques, ni les chiffres. C’est que tout cela est devenu normal.

Je crois que c’est ce qui définit vraiment une culture : le moment où plus personne ne réfléchit “à l’ancienne manière”, parce que la nouvelle façon de faire a tellement de sens qu’elle s’impose d’elle-même.

Ce qui m’amène à OctoFirst. Depuis plus de quinze ans, je fais de l’open source (beaucoup !). J’ai construit des outils pour mesurer, analyser, comprendre. Pendant longtemps, ce travail est resté dans l’ombre : utile pour moi, utile pour quelques équipes autour de moi, mais rien de plus. Je n’ai jamais pensé “faire un produit”. Je voulais juste comprendre ce que les équipes vivent réellement, au-delà des impressions.

Et puis, petit à petit, OctoFirst a pris une forme qui me dépasse un peu : un outil qui n’est pas seulement là pour afficher des statistiques, mais pour aider les équipes à voir ce qu’elles ne voient pas d’habitude. À comprendre leurs dynamiques internes. À changer leurs habitudes en douceur. À retrouver de la fluidité.

Pour être honnête, c’est la première fois que je me dis : « Peut-être que ce que je construis peut aider vraiment davantage de monde. »

Pas parce que c’est “révolutionnaire”, ou que c’est “IA-powered”. Juste parce que je vois l’effet concret, mesurable, humain que ça peut avoir sur une équipe.

Aujourd’hui, OctoFirst est encore en bêta. Il avance vite, mais surtout grâce aux retours que je reçois. Et j’ai besoin de ce feedback. Si votre équipe rencontre des latences dans les PRs, si vous voulez mieux comprendre vos interactions internes, si vous êtes simplement curieux, alors j’aimerais beaucoup que vous l’essayiez et que vous me disiez ce qui fonctionne, ce qui manque, ce qui pourrait être mieux.

Il n’y a pas de stratégie cachée. Je cherche juste à améliorer un outil que je construis depuis longtemps, et qui commence enfin à prendre la forme d’un produit réel.

Si vous voulez jeter un œil ou m’aider à l’améliorer : ➡️ app.octofirst.com

Et si vous avez envie d’en discuter, de comparer vos pratiques, ou de partager votre expérience, écrivez-moi. C’est exactement grâce à ces échanges que cet outil progresse.

Merci !

How to Audit Go Code with Static Analysis: A Deep Dive into ast-metrics

2025-09-18T00:00:00+00:00

Static code analysis is one of the most powerful techniques for maintaining code quality at scale. When it comes to Go, there are several excellent tools available, each with their own strengths and trade-offs. In this post, I’ll walk you through the landscape of Go static analysis tools, explain why I built ast-metrics, and show you how to use it effectively in your projects.

Understanding Static Analysis and AST

Before diving into tools, let’s understand what static analysis actually means and how it works.

Static analysis examines source code without executing it, looking for patterns that might indicate bugs, security vulnerabilities, or code quality issues. It’s like having a very thorough code reviewer that never gets tired and can process thousands of lines in seconds.

The foundation of static analysis is the Abstract Syntax Tree (AST). When you write Go code like this:

func calculateTotal(items []Item) float64 {
    total := 0.0
    for _, item := range items {
        total += item.Price
    }
    return total
}

The Go compiler first parses this into an AST - a tree structure where each node represents a construct in your code. The func becomes a function node, the for loop becomes a loop node, and so on. Static analyzers traverse this tree, looking for specific patterns and relationships.

This is powerful because it means we can detect not just syntax errors, but semantic issues like:

Functions that are too complex
Dependencies that violate architectural rules
Code that might panic at runtime
Security vulnerabilities

Analyzing the AST is also a way to get insights into the architecture of the code.

The Go Static Analysis Landscape

Go has a rich ecosystem of static analysis tools, each serving different needs:

golangci-lint

The most popular choice, golangci-lint is actually a meta-linter that runs multiple linters in parallel. It’s fast, configurable, and catches a wide range of issues.

To start using it, you just need to install it and run it:

curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/HEAD/install.sh | sh -s -- -b $(go env GOPATH)/bin v2.4.0
golangci-lint run

Then you get a report like this:

This tool is really useful for catching bugs and security vulnerabilities. But it doesn’t provide any architectural insights.

Strengths:

Comprehensive coverage with 50+ linters
Excellent performance through parallel execution
Great CI integration
Active community and regular updates

Limitations:

Some linters produce overlapping warnings
Configuration can be complex for large teams
Focuses mainly on code style and basic quality issues

go vet

Built into the Go toolchain, go vet catches common mistakes that the compiler doesn’t catch.

You have nothing to do to use it, it’s built into the Go toolchain. Just run it:

go vet ./...

Gives something like this:

Having a tool built into the language is a big plus. It’s really something super in Golang. But it’s still very basic (useful!), and very focused on instructions, not on architecture.

Strengths:

Always up-to-date with Go releases
Zero configuration required
Very fast execution
Catches subtle bugs

Limitations:

Limited scope compared to third-party tools
No architectural analysis
No complexity metrics

staticcheck

A sophisticated linter that goes beyond basic checks to find bugs and performance issues.

It detects dead code, uninitialized variables, and more.

staticcheck ./...

After running it, you get a report like this:

This tool is really useful for finding bugs and performance issues. But it doesn’t provide any architectural insights. But, just like the others, it also doesn’t help you understand the architecture of your codebase.

Strengths:

Excellent at finding real bugs
Good performance
Clear, actionable error messages
Catches issues other tools miss

Limitations:

Focuses on correctness rather than architecture
No complexity or maintainability metrics
Limited architectural analysis

SonarQube

SonarQube is more a debt detection tool than a static analysis tool, even if it can be used for static analysis.

It’s very useful for detecting debt and code smells, and give insights into the codebase.

But it’s very heavy and resource-intensive, and requires a significant infrastructure.

I’m not the best person to talk about it, as I haven’t used it in years.

Strengths:

Very comprehensive analysis
Great reporting and dashboards
Supports many languages
Good for enterprise environments

Limitations:

Heavy and resource-intensive
Complex setup and maintenance
Can be overkill for smaller projects
Requires significant infrastructure

Why I Built ast-metrics

I code since more than 20 years, and I noticed that static analysis tools were often limited. In general, I notice that:

Architectural analysis was limited: most tools focus on individual files or functions, but don’t help you understand how your code is structured at a higher level.
Complexity metrics were scattered: you could get cyclomatic complexity from one tool, coupling from another, but there was no unified view.
CI integration was cumbersome: setting up comprehensive analysis in CI often meant running multiple tools and combining their outputs.
Reports were not actionable: many tools produce lists of issues, but don’t help you understand the bigger picture or prioritize fixes.

I have a good experience with static analysis tools. In 2013, I created PhpMetrics, a static analysis tool for PHP. I immediately imagined something very different, not focused on syntax or language sugar, but rather on architecture and code quality in general. A tool to give feedback, and not to decide for the developer.

It’s a tool that is quite unique in its approach, and I haven’t found anything like it in static analysis tools for other languages.

Since then, I have had the opportunity to work on more and more complex projects, with more and more teams. I noticed that static analysis tools were often limited, and that teams didn’t know how to use them. It’s necessary to configure them for each language, integrate them into the CI, etc.

I have therefore decided to create ast-metrics, a static analysis tool agnostic of the programming language, and above all which gives a view of the code and its architecture. Not necessarily a tool to check such or such instruction, but rather something that tells you if your packages are too coupled, if your methods are too complex, if your data structures are too large, etc.

ast-metrics was born from the need for a tool that provides architectural insights, complexity metrics, and activity analysis in a single, fast binary that’s easy to integrate into any workflow, for any language.

Key Features of ast-metrics

Multi-language Support

While built in Go, ast-metrics supports multiple languages (Go, Python, Rust, PHP) with more coming. This makes it valuable for polyglot projects.

Architectural Analysis

The tool’s most distinctive feature is its ability to detect “communities” - clusters of tightly coupled components in your codebase. This helps you understand your architecture and identify refactoring opportunities.

Comprehensive Metrics

ast-metrics calculates over 20 different metrics including:

Cyclomatic complexity
Maintainability index, Bugs probability
Coupling (afferent and efferent)
Lines of code (physical and logical)
Activity metrics (commits, bus factor)
Lack of cohesion of methods (LCOM)

and more.

Fast and Dependency-free

A single binary with no external dependencies, making it perfect for CI/CD pipelines.

I think we can make it much more performant, but it’s a project that is in constant development, and is constantly evolving.

A CLI app, with HTML reports

It’s not just a tool that throws a bunch of numbers at you. You can actually navigate through your code metrics right in your terminal (thanks to lipgloss and bubbletea!)

Getting Started with ast-metrics

Installation

The easiest way to install ast-metrics is using the provided script:

curl -s https://raw.githubusercontent.com/Halleck45/ast-metrics/main/scripts/download.sh | bash

This downloads the appropriate binary for your platform. For manual installation, check the official documentation.

Basic Analysis

To analyze your Go project:

ast-metrics analyze --report-html=./report /path/to/your/code

This generates an HTML report in the ./report directory. The report includes multiple views:

Overview: High-level metrics and trends
Risks: Potential issues and code smells
Explorer: Detailed file-by-file analysis
Architecture: Architectural insights
Compare: Branch comparison (if using Git, and if you used the --compare-with option)

## Exploring the report

I invite you to explore the Architecture page, which gives you an overview of the architecture of your code.

For example, here is the architecture report for the ast-metrics project:

In the top of the chart, you have the entrypoint of your code (the “highest layers”). And at the bottom, you have the “lowest layers” of the project (the package and components used by the entrypoints).

You can also explore the “purity” of your packages. A package is pure if it does not depend on any other package.

I’m currently refining the algorithms, but I already find the results quite promising. The next step for me is to keep making things as clear as possible. But it’s a good start!

Configuration with Rulesets

Even if it’s not the main objective of ast-metrics, you can use it as a linter for yours projects.

ast-metrics uses a ruleset-based configuration system. Start by initializing a configuration file:

ast-metrics init

This creates a .ast-metrics.yaml file. Then add rulesets based on your needs:

# List available rulesets
ast-metrics ruleset list

# Add specific rulesets
ast-metrics ruleset add architecture
ast-metrics ruleset add volume
ast-metrics ruleset add complexity
ast-metrics ruleset add golang

Each ruleset contains related rules. For example, the architecture ruleset includes:

Coupling constraints
Circular dependency detection
Maintainability thresholds
God class detection

Understanding Rulesets

Let’s look at what each ruleset provides:

Architecture Ruleset

requirements:
  rules:
    architecture:
      coupling:
        forbidden:
          - from: Controller
            to: Repository
          - from: Repository
            to: Service
      max_afferent_coupling: 10
      max_efferent_coupling: 10
      min_maintainability: 70

This enforces architectural constraints like preventing controllers from directly accessing repositories.

Volume Ruleset

    volume:
      max_loc: 1000
      max_logical_loc: 600
      max_loc_by_method: 30
      max_logical_loc_by_method: 20

Controls file and method size limits.

Golang Ruleset

    golang:
      no_package_name_in_method: true
      max_nesting: 4
      max_file_size: 1000
      max_files_per_package: 50
      slice_prealloc: true
      context_missing: true
      context_ignored: true

Enforces Go-specific best practices.

Future Rulesets

I try to add new ruleset, based on my experience and my ideas.

Feel free to contribute if you have ideas ❤️!

Linting Your Code

Once you have rules configured, you can lint your code:

ast-metrics lint

This will check your code against all enabled rules and report violations. The output is designed to be actionable, with clear explanations of what’s wrong and how to fix it.

CI Integration

ast-metrics provides a dedicated CI command that runs linting and generates all reports:

ast-metrics ci

This command:

Runs the linter first
Generates HTML, Markdown, JSON, OpenMetrics, and SARIF reports
Exits with non-zero status if violations are found
Still produces reports even if violations exist

GitHub Actions Integration

**For GitHub Actions, there’s a dedicated action:

name: "AST Metrics"
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
        - uses: halleck45/action-ast-metrics@v1

This automatically analyzes your code on every push and can be configured to fail the build on violations.

Exploring Architecture with Communities

One of ast-metrics’ most powerful features is its community detection algorithm. This analyzes your code’s dependency graph to identify clusters of tightly coupled components.

How Community Detection Works

The algorithm uses label propagation to group related components. It starts by assigning each component to its own community, then iteratively moves components to the community that most of their neighbors belong to.

This reveals the natural boundaries in your codebase - areas that are tightly coupled internally but loosely coupled to the rest of the system.

Reading the Communities Report

The communities page in the HTML report shows:

Community graph: The relations between your packages.
Community Details: Size, coupling ratios, and key components for each community
Architectural Suggestions: Recommendations for refactoring based on the analysis

For example, if you see a community with high outbound coupling (>0.7), the tool might suggest introducing a facade pattern. If a community is very large (>50 components) with low purity (<0.6), it might suggest splitting the module.

Using Communities for Refactoring

Communities help you answer questions like:

Which parts of my code are too tightly coupled?
Where should I introduce interfaces to reduce coupling?
What are the natural boundaries for microservices?
Which components are architectural bottlenecks?

Advanced Usage

Branch Comparison

Compare your current branch with another branch or commit:

ast-metrics analyze --compare-with=main .

This shows how metrics have changed between branches, helping you understand the impact of recent changes.

Custom Exclusions

Exclude files or directories from analysis:

ast-metrics analyze --exclude=".*_test.go" --exclude="vendor/" .

Multiple Report Formats

Generate reports in different formats:

ast-metrics analyze \
  --report-html=./html-report \
  --report-json=./metrics.json \
  --report-sarif=./results.sarif \
  --report-openmetrics=./metrics.txt \
  .

This is particularly useful for CI pipelines where different tools consume different formats. If you don’t know what is the correct format for you, use the --ci option: it will generate all the reports once.

Current Limitations and Future Directions

ast-metrics is actively developed, but there are some current limitations:

Language Support

While supporting Go, Python, Rust, and PHP, some languages have more complete support than others. TypeScript, Java, and C++ support is planned, and I hope to support more languages in the future.

Rule Customization

While the ruleset system is flexible, some advanced customization scenarios might require code changes rather than configuration.

IDE Integration

Currently, ast-metrics is primarily a command-line tool. IDE integration would make it more accessible for day-to-day development. I think that a VsCode extension would be a good idea.

Performance on Very Large Codebases

While fast, very large codebases (millions of lines) might require optimization for memory usage. For example, analyzing 2 millions of lines of code takes a around 30 seconds on my computer. It can be improved.

Best Practices for Go Static Analysis

Based on my experience with ast-metrics and other tools, here are some recommendations:

Start Simple

Begin with basic rules and gradually add more sophisticated ones as your team gets comfortable.

Focus on Architecture

Don’t just look at individual files - understand how your components interact. This is where ast-metrics really shines.

Use Multiple Tools

ast-metrics complements rather than replaces other tools. Use golangci-lint for style issues and ast-metrics for architectural analysis.

Integrate Early

Set up static analysis in your CI pipeline from day one. It’s much easier than retrofitting it later.

Review Regularly

Static analysis is not a silver bullet. Regular code reviews and architectural discussions are still essential.

My final thoughts

Static analysis is a crucial part of maintaining code quality, especially as your codebase grows. While there are many excellent tools available, ast-metrics fills an important gap by providing architectural insights and comprehensive metrics in a single, easy-to-use tool.

The key is to start with basic analysis and gradually incorporate more sophisticated rules as your team’s needs evolve. The communities feature alone can provide valuable insights into your code’s structure and help guide refactoring efforts.

Whether you’re working on a small Go service or a large polyglot system, static analysis tools like ast-metrics can help you write better, more maintainable code. The investment in setting up these tools pays dividends in reduced bugs, easier refactoring, and better architectural decisions.

Give ast-metrics a try on your next project, and let me know what you think. The project is open source and welcomes contributions - after all, the best tools are built by the community that uses them.

ast-metrics is available on GitHub and documented. For questions or contributions, feel free to open an issue or start a discussion.

Speech Vectorization Explained: Building a Local AI for Pronunciation Detection

2025-09-11T00:00:00+00:00

Reading or writing has never been much of a problem for me, but as soon as it comes to speaking, I realize my pronunciation is not always clear.

ChatGPT is great for text, but current generative models are not designed to evaluate pronunciation.
So I asked myself: what if I built my own pronunciation coach?

A tool that:

listens to me,
compares what I say to a reference,
and gives me clear and visual feedback.

That’s the project I’ll detail here, while also breaking down the AI building blocks: embeddings, distances, DTW, phonemes, visemes.

Why is comparing two sounds so hard?

A spoken word is not a sequence of letters, but a sound wave that varies over time:

the air vibrates,
the voice rises and falls,
some parts are long, others very short.

Even two people pronouncing exactly the same word will never have identical curves.

The central question becomes: how do you compare two audios that do not align perfectly?

The chosen approach

Here’s an overview of the architecture I set up:

Don’t worry(we’ll break down all these concepts step by step.

Turning sound into numbers: embeddings

A computer does not understand sound. It only manipulates vectors of numbers.

A vector = a list of numbers, e.g. [0.2, -0.7, 1.1].
An audio embedding = a condensed representation of a short audio segment.

With Wav2Vec2, every few milliseconds of audio are encoded into 768 numbers describing timbre, energy, articulation, etc.

processor = Wav2Vec2Processor.from_pretrained("facebook/wav2vec2-large-960h")

def extract_embeddings(audio_waveform, sampling_rate=16000):
    inputs = processor(audio_waveform, sampling_rate=sampling_rate,
                       return_tensors="pt", padding=True)
    input_values = inputs.input_values.squeeze(0)
    with torch.no_grad():
        features = model(input_values).last_hidden_state
    return features.squeeze(0).numpy()

In short:

similar sounds → close vectors,
different sounds → distant vectors.

Measuring similarity: distances

Once two vectors are extracted, you need to measure their proximity.

The basic tool: Euclidean distance.
Simple example between [1,2] and [4,6]:

√((4-1)² + (6-2)²) = 5

With audio embeddings, it’s the same principle, but in a 768-dimensional space.

from fastdtw import fastdtw
from scipy.spatial.distance import euclidean

def compare_pronunciation(expected, actual):
    expected_seq = get_phoneme_embeddings(expected)
    actual_seq = get_phoneme_embeddings(actual)
    distance, _ = fastdtw(expected_seq, actual_seq, dist=euclidean)
    return distance

DTW: when speech is not at the same speed

Problem: a word can last 0.5 seconds for me and 0.8 seconds in the reference.
If you compare naively, it fails.

The solution: Dynamic Time Warping (DTW).
This algorithm aligns two sequences of different speeds by “stretching” or “compressing” time to match similar parts.

import numpy as np

def align_sequences_dtw(seq1, seq2):
    distance, path = fastdtw(seq1, seq2, dist=euclidean)
    aligned1, aligned2 = [], []
    for i, j in path:
        aligned1.append(seq1[i][0])
        aligned2.append(seq2[j][0])
    return np.array(aligned1), np.array(aligned2)

Result: a robust comparison, even when pacing differs.

Phonemes and visemes: hear AND see

Some sounds are hard to distinguish by ear.
Example: “think” vs “sink” (subtle difference between /θ/ and /s/).

A phoneme = the smallest distinctive sound (e.g. /p/, /a/, /t/).
A viseme = the visual mouth shape that produces that sound.

In my prototype, when a word is mispronounced, I can click on it and see a mouth animation showing the correct articulation.

👉 Learning becomes more concrete: I both hear and see what to correct.
(Microsoft documentation on visemes)

The complete pipeline

I write a text: “Hello, how are you?”.
The system generates a reference voice (e.g. gTTS).
I record my voice.
Extract Wav2Vec2 embeddings for both audios.
Align them with DTW.
Compare phoneme by phoneme.
Feedback returned:
- a global score (out of 100),
- a list of mispronounced words,
- clear feedback: “❌ You should pronounce better: Hello, you”,
- and the corresponding visemes.

Limitations of the approach

Let’s be honest:

Wav2Vec2 was not trained to score pronunciation → approximation.
Synthetic voices are imperfect → sometimes artificial accent.
Simplified visemes → animations too discrete compared to a real mouth.
Subjectivity remains → a native listener is still the ultimate reference.

What it still brings

I can listen to myself objectively.
I can spot my mistakes without a teacher.
I get visual feedback.
And most importantly: I stay motivated to practice.

Ways forward

Integrate specialized pronunciation scoring models (commercial APIs).
Improve visemes with smooth 3D animation.
Add prosody (intonation, stress, rhythm).
Extend to other languages.
Evaluate longer sentences (reading, dialogue).

Conclusion

I haven’t reinvented Duolingo. But I have built a home-made coach that helps me improve my speaking.

The strength comes from the combination of:

AI (Wav2Vec2) to turn voice into vectors,
classic algorithms (DTW) to compare,
pedagogical visuals (visemes) to correct.

A mix of machine learning, math, and pedagogy, all serving a very concrete goal: speaking English better.

👉 Source code is available on GitHub.
Feedback or contributions are welcome.

Speech Embeddings et Pronunciation Detection : construire un pipeline IA local avec Wav2Vec2

2025-09-11T00:00:00+00:00

Lire ou écrire ne me pose pas trop de problèmes, mais dès qu’il s’agit de parler, je me rends compte que ma prononciation n’est pas toujours claire.

ChatGPT est super pour le texte, mais les modèles génératifs actuels ne savent pas évaluer la prononciation.
Alors je me suis demandé : et si je construisais moi-même un petit coach ?

Un outil qui :

m’écoute,
compare ce que je dis à une référence,
et me renvoie un retour clair et visuel.

C’est ce que je vais détailler ici, tout en expliquant simplement les briques IA derrière : embeddings, distances, DTW, phonèmes, visèmes.

Pourquoi comparer deux sons est si difficile ?

Un mot parlé n’est pas une suite de lettres, mais une onde sonore qui varie dans le temps :

l’air vibre,
la voix monte et descend,
certaines parties sont longues, d’autres très courtes.

Même deux personnes qui prononcent exactement le même mot n’auront jamais deux courbes identiques.
La question centrale devient donc : comment comparer deux audios qui ne s’alignent pas parfaitement ?

L’approche choisie

Voici un aperçu de l’architecture que j’ai mise en place :

N’ayez pas peur, on va expliquer tous ces concepts pas à pas.

Transformer le son en nombres : les embeddings

Un ordinateur ne comprend pas les sons. Il ne manipule que des vecteurs de nombres.

Un vecteur = une liste de nombres, par ex. [0.2, -0.7, 1.1].
Un embedding audio = une représentation condensée d’un petit morceau de son.

Avec Wav2Vec2, chaque tranche d’audio de quelques millisecondes est encodée en 768 nombres décrivant le timbre, l’énergie, l’articulation, etc.

processor = Wav2Vec2Processor.from_pretrained("facebook/wav2vec2-large-960h")

def extract_embeddings(audio_waveform, sampling_rate=16000):
    inputs = processor(audio_waveform, sampling_rate=sampling_rate,
                       return_tensors="pt", padding=True)
    input_values = inputs.input_values.squeeze(0)
    with torch.no_grad():
        features = model(input_values).last_hidden_state
    return features.squeeze(0).numpy()

En résumé :

sons proches → vecteurs proches,
sons différents → vecteurs éloignés.

Mesurer la ressemblance : les distances

Une fois deux vecteurs extraits, il faut mesurer leur proximité.

L’outil de base : la distance euclidienne.
Exemple simple entre [1,2] et [4,6] :

√((4-1)² + (6-2)²) = 5

Avec les embeddings audio, c’est le même principe mais dans un espace à 768 dimensions.

from fastdtw import fastdtw
from scipy.spatial.distance import euclidean

def compare_pronunciation(expected, actual):
    expected_seq = get_phoneme_embeddings(expected)
    actual_seq = get_phoneme_embeddings(actual)
    distance, _ = fastdtw(expected_seq, actual_seq, dist=euclidean)
    return distance

DTW : quand on ne parle pas à la même vitesse

Problème : un mot peut durer 0,5 seconde chez moi et 0,8 seconde dans la référence.
Si on compare naïvement, ça échoue.

La solution : Dynamic Time Warping (DTW).
Cet algorithme aligne deux séquences de vitesses différentes en “étirant” ou “compressant” le temps pour faire correspondre les parties similaires.

import numpy as np

def align_sequences_dtw(seq1, seq2):
    distance, path = fastdtw(seq1, seq2, dist=euclidean)
    aligned1, aligned2 = [], []
    for i, j in path:
        aligned1.append(seq1[i][0])
        aligned2.append(seq2[j][0])
    return np.array(aligned1), np.array(aligned2)

Résultat : une comparaison robuste, même si le rythme diffère.

Phonèmes et visèmes : entendre ET voir

Certains sons sont difficiles à distinguer à l’oreille.
Exemple : “think” vs “sink” (différence subtile entre /θ/ et /s/).

Un phonème = le plus petit son distinctif (ex. /p/, /a/, /t/).
Un visème = l’image de la bouche qui produit ce son.

Dans mon prototype, quand un mot est mal prononcé, je peux cliquer dessus et voir une animation de bouche qui montre la bonne articulation.

👉 Apprentissage plus concret : j’entends et je vois ce qu’il faut corriger.
(Documentation Microsoft sur les visèmes)

Le pipeline complet

J’écris un texte : “Hello, how are you?”.
Le système génère une voix de référence (ex. gTTS).
J’enregistre ma voix.
Extraction des embeddings Wav2Vec2 pour les deux audios.
Alignement avec DTW.
Comparaison phonème par phonème.
Feedback renvoyé :
- un score global (sur 100),
- une liste de mots mal prononcés,
- un feedback clair : “❌ Tu dois mieux prononcer : Hello, you”,
- et les visèmes correspondants.

Limites de l’approche

Soyons honnêtes :

Wav2Vec2 n’est pas entraîné pour noter la prononciation → approximation.
Voix de synthèse imparfaite → accent parfois artificiel.
Visèmes simplifiés → animations trop discrètes comparées à une bouche réelle.
Subjectivité persistante → la compréhension d’un natif reste la référence ultime.

Ce que ça apporte malgré tout

Je peux m’écouter objectivement.
J’identifie mes erreurs sans prof.
Je dispose d’un feedback visuel.
Et surtout : je garde la motivation à pratiquer.

Pistes pour aller plus loin

Intégrer des modèles spécialisés de pronunciation scoring (API commerciales).
Améliorer les visèmes avec de la 3D fluide.
Ajouter la prosodie (intonation, accentuation, rythme).
Étendre à d’autres langues.
Évaluer des phrases longues (lecture, dialogue).

Conclusion

Je n’ai pas réinventé Duolingo. Mais j’ai construit un coach maison qui m’aide à progresser à l’oral.

La force vient de la combinaison :

IA (Wav2Vec2) pour transformer la voix en vecteurs,
algorithmes classiques (DTW) pour comparer,
visuels pédagogiques (visèmes) pour corriger.

Un mélange de machine learning, de maths et de pédagogie, au service d’un objectif très concret : mieux parler anglais.

👉 Le code source est disponible sur GitHub.
Vos retours ou contributions sont bienvenus.

Parsing PHP code, without depending on PHP

2025-08-26T00:00:00+00:00

For the past few months, I’ve been working on AstMetrics, a tool for analyzing source code of software projects at scale, regardless of the programming language.

The idea is simple: instead of limiting analysis to line counts or superficial static rules, AstMetrics relies directly on the AST (Abstract Syntax Tree), i.e. the structured representation of code as understood by the compiler.

With an AST, you can measure much more than surface-level metrics: complexity, nesting depth, number of branches, dependencies between logical units, and so on. You can also compare metrics between project versions and detect trends.

From the beginning, AstMetrics was designed as language-agnostic. Nothing prevents analyzing PHP, JavaScript, Python, or Go: as long as I can obtain an AST in a stable format (JSON, for instance), I can build metrics on top of it. This is one of the reasons I started AstMetrics compared to PhpMetrics, which is PHP-only.

It’s in this context that Go-PHP-Parser was born.

The problem: parsing PHP

To extract the AST of a language, there are two main approaches:

Write your own parser: starting from the grammar of the language, rebuild a lexical and syntax analyzer.
Reuse the official parser: embed it or call it directly to get the AST it produces.

At first, I explored the first option, which seemed more interesting.

Attempt 1: Lex and Yacc

What are Lex/Yacc?

Lex is a lexical analyzer generator. You describe the tokens of a language (keywords, operators, strings, etc.) using regular expressions. Lex generates C code that can split a source file into a stream of tokens.
Yacc (Yet Another Compiler Compiler) is a parser generator. You describe the grammar of a language in terms of production rules (e.g., an expression is either a number or the addition of two expressions). Yacc generates a parser that builds a syntax tree from the tokens produced by Lex.

The Lex+Yacc combo is classic: it was used to build parsers for many languages in the 80s–90s. There are modern equivalents in Go, like goyacc.

These are fundamental tools, used as compilation engines for many programming languages.

Trying to parse PHP with Lex/Yacc

So I started writing a PHP grammar for Yacc in Go. Very quickly, I hit the limits:

The PHP grammar is huge, full of edge cases and historical quirks.
Each version of the language adds new constructs (e.g., match expressions in PHP 8).
Keeping this grammar up to date would have required enormous and constant effort.

I tried to automate part of the process with AI to generate the rules. It turned out too complex for the AI. Maybe in a few months it’ll be worth trying again… I spent hours on it, but for now I’m dropping that path.

By the way, a project like z7zmey/php-parser followed that approach. It’s a native PHP parser in Go based on a hand-written grammar. But it’s not fully up to date (PHP 8.2), and you can see why: maintaining a manual PHP grammar in another language is a never-ending job.

Result: I learned a lot, but abandoned the idea.

If you’re interested in the subject, I recommend reading Lex & Yacc, by John Levine, Doug Brown, Tony Mason. It’s dense but really useful, especially if you like regular expressions!

Attempt 2: reusing the official parser

The second option is to avoid reinventing the wheel.

PHP already has its official parser, maintained by the language team. There’s even an extension, ext-ast, which exposes PHP’s AST internally in a stable and versioned form (thanks to Nikita Popov 🙏).

The problem: to use it, you must have PHP installed in the correct version, and you also need the ext-ast extension enabled.

This works locally, but not for a generic tool like AstMetrics, which must run on any machine without dependencies.

I tried building a standalone PHP to parse code. It worked, but the performance was awful, and CPU usage was huge.

The most logical solution (not necessarily the simplest, I admit): switch to C and use the SAPI Embed to call the official parser.

Go-PHP-Parser: embedding PHP in Go

The chosen solution was to embed the PHP engine directly as a C library thanks to the SAPI Embed.

SAPI Embed

PHP offers several SAPIs (Server APIs). The most well-known is SAPI FPM for running PHP behind a web server.
The Embed SAPI is an interface that allows you to use the PHP engine as a library inside another C program.

You can initialize the engine, feed it some code, and get the result back.

This SAPI is available in the PHP GitHub repository.

ext-ast

By enabling ext-ast, I can ask PHP not for the execution result, but directly for the AST of the code.

This AST is identical to the one PHP uses internally, so it is always up to date with the language.

An AST is simply a tree representation of your source code. For example, the code:

while b ≠ 0:
if a > b:
a := a - b
else:
b := b - a
return a

is represented by this tree (Wikipedia illustration):

C ↔ Go Bridge

I wrote a small bridge in C that:

Initializes the embedded PHP engine.
Passes the PHP source code to ext-ast.
Serializes the AST to JSON.

This bridge is exposed to Go via cgo. In practice, from Go I can simply call:

ast, err := parser.Parse("<?php echo 1 + 2;")

and I get a JSON structure describing the AST.

Simplified distribution

To avoid forcing the user to compile PHP embed themselves, the project relies on static-php-cli:

Precompiled binaries of PHP + ext-ast are provided.
On first use, the binary for the current platform is automatically downloaded.

Result: the Go user has nothing to install. Just run:

go get github.com/Halleck45/go-php-parser

In the future, I might drop static-php-cli if I see the project isn’t maintained anymore. It’s possible, even though static-php-cli saves a lot of time when compiling PHP.

Architecture

Here’s an overview of the overall architecture of Go-PHP-Parser:

Why Go?

Two main reasons:

Performance: Go compiles to native binaries without a heavy runtime. It’s fast for handling C calls via cgo and efficient at processing large volumes of files in parallel thanks to goroutines. Perfect for scanning entire repositories.
Interoperability: Go is a good language for writing easy-to-use libraries. By providing a Go API, I make integration into AstMetrics trivial.

Approach comparison

Approach	Advantage	Drawback
Custom parser (Lex/Yacc)	Independent, full control	Huge maintenance, slow to keep up to date
Project like z7zmey	Native Go, fast	Not up to date, costly to maintain
Calling a PHP binary	Simple to implement	External process, I/O overhead, requires installation
Embed + ext-ast (current)	Fast, always up to date, reduced maintenance	Requires a C bridge and embedded binaries. More complex

Performance

Preliminary benchmarks show that:

Parsing a PHP file is in the same ballpark as using php-ast natively (4,000 to 8,000 files per second on my 16-core 32 GB RAM PC).
Embedding avoids the cost of launching a php process for each file.
For large-scale scans, the real bottleneck is disk I/O, not parsing itself.

Potential and use cases

Go-PHP-Parser was born to serve AstMetrics, but it can be useful for much more:

Running PHP code from Go (I think there’s real potential there).
Automated refactoring tools.
Static analysis integrated into CI/CD.
Code indexing for search engines or big-code tools.
Assisting migration between PHP versions.
Documentation generation from code.

Basically, anything that needs fast and reliable access to the PHP AST.

Conclusion

Go-PHP-Parser is not a parser written from scratch, and that’s intentional.

Instead of maintaining a parallel PHP grammar, I chose to rely on the official parser of the language, via the Embed SAPI and ext-ast. This ensures staying up to date while benefiting from native performance and the simplicity of Go.

Next steps for me: using it in AstMetrics! It’s a lot of work, but little by little it’s moving forward, among my many other projects…

I hope the project will be useful to others! If you’d like to test or contribute, the project is available here: https://github.com/Halleck45/go-php-parser

Parser du code PHP, sans dépendre de PHP

2025-08-25T00:00:00+00:00

Depuis quelques mois, je travaille sur AstMetrics, un outil pour analyser le code source de projets logiciels à grande échelle, quel que soit le langage de programmation.

L’idée est simple : au lieu de se limiter à du comptage de lignes ou à des règles statiques superficielles, AstMetrics s’appuie directement sur l’AST (Abstract Syntax Tree), c’est-à-dire la représentation structurée du code telle que le compilateur l’entend.

Avec un AST, on peut mesurer bien plus que des métriques superficielles : complexité, profondeur de nesting, nombre de branches, dépendances entre unités logiques, etc. On peut également comparer des métriques entre versions d’un projet et détecter des tendances.

Dès le départ, AstMetrics a été pensé comme agnostique du langage. Rien n’empêche d’analyser du PHP, du JavaScript, du Python ou du Go : tant que je peux obtenir un AST dans un format stable (JSON par exemple), je peux construire des métriques dessus. C’est une des raisons qui m’ont poussées à démarrer AstMetrics par rapport à PhpMetrics, uniquement orienté PHP.

C’est dans ce contexte qu’est né Go-PHP-Parser.

Le problème : parser du PHP

Pour récupérer l’AST d’un langage, deux approches principales existent :

Écrire son propre parser : à partir de la grammaire du langage, reconstruire un analyseur lexical et syntaxique.
Réutiliser le parser officiel : l’embarquer ou l’appeler pour récupérer directement l’AST produit.

Au départ, j’ai exploré la première voie, qui m’a parue plus intéressante.

Tentative 1 : Lex et Yacc

Qu’est-ce que Lex/Yacc ?

Lex est un générateur d’analyseur lexical. On décrit les tokens d’un langage (mots-clés, opérateurs, chaînes de caractères, etc.) sous forme d’expressions régulières. Lex génère du code C qui sait découper un fichier source en une suite de tokens.
Yacc (Yet Another Compiler Compiler) est un générateur d’analyseur syntaxique. On décrit la grammaire d’un langage en termes de règles de production (par ex. une expression est soit un nombre, soit une addition de deux expressions). Yacc génère ensuite un parser qui construit un arbre syntaxique à partir des tokens produits par Lex.

La combinaison Lex+Yacc est classique : c’est ce qui a servi à écrire des parseurs pour de nombreux langages dans les années 80-90. Il existe des équivalents modernes en Go, comme goyacc.

Ce sont des outils fondamentaux, utilisés comme moteur de compilation pour de nombreux langages de programmation.

Essayer de parser PHP avec Lex/Yacc

J’ai donc commencé à écrire une grammaire PHP pour Yacc en Go. Très vite, j’ai vu les limites :

La grammaire PHP est énorme, pleine de cas particuliers et d’ambiguïtés historiques.
Chaque version du langage ajoute de nouvelles constructions (par exemple, les match expressions en PHP 8).
Maintenir cette grammaire à jour aurait demandé un travail colossal et constant.

J’ai essayé d’automatiser une partie via des IA pour générer les règles. C’était visiblement trop complexe pour l’IA. Peut-être que d’ici quelques mois, avec les progrès actuels, ça vaudra plus le coup… J’y ai passé des heures, pour le moment j’abandonne ce chemin.

D’ailleurs, un projet comme z7zmey/php-parser a pris cette voie. C’est un parseur PHP natif en Go basé sur une grammaire écrite à la main. Mais il n’est pas complètement à jour (PHP 8.2), et on comprend pourquoi : maintenir une grammaire manuelle de PHP dans un langage tiers est une tâche sans fin.

Résultat : j’ai beaucoup appris, mais j’ai abandonné l’idée.

Si le sujet vous intéresse, je vous recommande de lire Lex & Yacc, de John Levine, Doug Brown, Tony Mason. C’est dense mais vraiment utile, surtout si vous aimez les expressions régulières !

Tentative 2 : réutiliser le parser officiel

La deuxième voie consiste à ne pas réinventer la roue.

PHP possède déjà son parser officiel, maintenu par l’équipe du langage. Il existe même une extension, ext-ast, qui expose l’AST PHP en interne, sous une forme stable et versionnée (merci Nikita popov 🙏)

Le problème : pour l’utiliser, il faut avoir PHP installé dans la bonne version, et en plus avoir activé l’extension ext-ast.

C’est faisable en local, mais pas dans le cadre d’un outil générique comme AstMetrics qui doit tourner sur n’importe quelle machine, sans dépendance.

J’ai tout de même essayé de builder un standalone PHP pour parser du code. Ca marchait bien, mais les performances étaient catastrophiques, ainsi que le CPU utilisé.

Le plus logique (pas forcément le plus simple, je le reconnais) : passer sur sur C, et utiliser la SAPI Embed pour appeler le parser officiel.

Go-PHP-Parser : embarquer PHP dans Go

La solution retenue a été d’embarquer le moteur PHP directement comme une librairie C grâce à la SAPI Embed.

SAPI Embed

PHP propose plusieurs SAPIs (Server API). La plus connue est le SAPI FPM pour exécuter PHP derrière un serveur web.
La SAPI Embed est une interface qui permet d’utiliser le moteur PHP comme une bibliothèque au sein d’un autre programme C.

On peut ainsi initialiser le moteur, lui donner un bout de code, et récupérer le résultat.

Cette SAPI est disponible sur le repository Github de PHP.

ext-ast

En activant ext-ast, je peux demander à PHP de me renvoyer non pas le résultat d’exécution, mais directement l’AST du code.

Cet AST est identique à celui que PHP utilise en interne, donc toujours à jour avec les évolutions du langage.

Un AST est simplement une représentation en arbre de votre code source. Par exemple, le code:

while b ≠ 0:
    if a > b:
        a := a - b
    else:
        b := b - a
return a

Est représenté par cet arbre (illustration wikipedia):

Bridge C ↔ Go

J’ai écrit un petit bridge en C qui :

Initialise le moteur PHP embed.
Passe le code source PHP à ext-ast.
Sérialise l’AST en JSON.

Ce bridge est exposé côté Go via cgo. En pratique, dans Go j’appelle une fonction simple :

ast, err := parser.Parse("<?php echo 1 + 2;")

et je reçois une structure JSON décrivant l’AST.

Distribution simplifiée

Pour éviter à l’utilisateur de devoir compiler PHP embed lui-même, le projet s’appuie sur static-php-cli :

Des binaires précompilés de PHP + ext-ast sont fournis.
Lors de la première utilisation, le binaire adapté à la plateforme est téléchargé automatiquement.

Résultat : l’utilisateur Go n’a rien à installer. Un simple :

go get github.com/Halleck45/go-php-parser

et tout fonctionne.

A l’avenir, je me passerai peut-être de static-php-cli, si je m’aperçois que le projet n’est plus maintenu. C’est possible, même si static-php-cli fait gagner beaucoup de temps pour la phase de compilation de PHP.

Architecture

Voici un aperçu de l’architecture générale de Go-PHP-Parser :

Pourquoi Go ?

Deux raisons principales :

Performance : Go compile en binaire natif, sans runtime lourd. Il est rapide pour gérer des appels C via cgo, et efficace pour traiter des gros volumes de fichiers en parallèle grâce aux goroutines. C’est parfait pour scanner des dépôts entiers.
Interopérabilité : Go est un bon langage pour écrire des bibliothèques simples à utiliser. En fournissant une API Go, je rends l’intégration dans AstMetrics triviale.

Comparaison des approches

Approche	Avantage	Inconvénient
Parser maison (Lex/Yacc)	Indépendant, contrôle total	Maintenance énorme, lent à mettre à jour
Projet type z7zmey	Natif Go, rapide	Pas à jour, coûteux à maintenir
Appel à un binaire PHP	Simple à écrire	Process externe, coût d’I/O, dépendance à l’installation
Embed + ext-ast (choix actuel)	Rapide, toujours à jour, maintenance réduite	Nécessite un bridge C et des binaires embarqués. Complexe

Performance

Les benchmarks préliminaires montrent que :

Le parsing d’un fichier PHP est du même ordre de grandeur que via php-ast en natif (4 000 à 8 000 fichiers par seconde sur mon PC de 16 coeurs et 32 Go de RAM).
L’embed évite le coût de lancer un process php à chaque fichier.
Pour un scan massif, le vrai goulot reste les I/O disques, pas le parsing lui-même.

Potentiel et usages

Go-PHP-Parser est né pour servir AstMetrics, mais il peut servir bien plus :

Exécution de code PHP depuis Go (je pense qu’il y a là un vrai potentiel)
Outils de refactoring automatique.
Analyse statique intégrée à la CI/CD.
Indexation de code pour moteurs de recherche ou big-code.
Aide à la migration entre versions de PHP.
Génération de documentation à partir du code.

Tout ce qui nécessite un accès fiable et rapide à l’AST PHP.

Conclusion

Go-PHP-Parser n’est pas un parseur écrit from scratch, et c’est volontaire.

Plutôt que de maintenir une grammaire PHP parallèle, j’ai préféré m’appuyer sur le parser officiel du langage, via la SAPI embed et ext-ast.
Cela permet de rester toujours à jour, tout en bénéficiant des performances du natif et de la simplicité de Go.

Prochaines étapes pour moi : l’utiliser dans AstMetrics ! C’est du boulot, mais petit à petit ça avance, parmi mes nombreux autres projets…

J’espère que le projet servira à d’autres ! Si vous voulez tester ou contribuer, le projet est disponible ici : https://github.com/Halleck45/go-php-parser

Monorepo : pourquoi (et comment) rapatrier vos dépôts existants avec git subtree

2025-08-08T00:00:00+00:00

Vous entendez parler de monorepo partout, ça a l’air ésotérique, mais en vrai c’est pas si compliqué.
Dans ce billet, on va voir à quoi ça sert, pourquoi c’est souvent mystifié, ce qu’est Git subtree (et en quoi c’est différent de submodules), puis comment rapatrier proprement des dépôts existants dans un monorepo.

TL;DR

Un monorepo = un seul dépôt Git pour plusieurs projets, packages, librairies…
C’est utile pour synchroniser les versions, factoriser les libs, simplifier les PR transverses et industrialiser la CI/CD.
Pas besoin de Bazel ou d’outillage complexe : git subtree et git filter-repo suffisent dans la majorité des cas.
subtree garde une arborescence propre (un dossier par projet) et l’historique de chaque dépôt importé. Pas de dépendance comme avec les submodules.
Voici un script ci-dessous pour rapatrier un dépôt existant dans un sous-dossier de votre monorepo, en conservant son historique.

Pourquoi adopter un monorepo ?

Il y a vraiment de nombreux avantages à fusionner vos projets dans un seul dépôt Git :

Visibilité globale : un seul endroit pour tout voir (services, libs, front, infra-as-code…).
Refactorings atomiques : une PR peut toucher plusieurs packages d’un coup.
Outillage unifié : lints/formatters/tests/CI standardisés.
Gestion des versions : stratégies de release cohérentes (versionning de libs internes, changelogs, etc.).
Onboarding : un clone, et les devs ont tout ce qu’il faut.

La simplicité de ne faire qu’une seule Pull Request à un seul endroit est vraiment un plaisir au quotidien.

Par exemple : si vous travaillez sur un projet avec un dépôt pour le front et un autre pour le back. Si jusqu’ici vous deviez faire deux Pull Requests, attendre que la première soit mergée pour accepter la seconde… désormais vous pouvez faire une seule PR pour les deux.

`subtree` n’a rien de mystique

On confonds les deux, mais les subtree et les submodule n’ont pas grand chose en commun.

Submodules : pointent vers d’autres dépôts (pointeurs Git). Souvent pénibles à synchroniser, cassent le dev workflow si tout le monde n’est pas à l’aise.
Subtree : intègre le contenu d’un dépôt dans un sous-dossier de votre monorepo, en conservant l’historique. Vous pouvez ensuite pull/push des mises à jour entre le monorepo et le dépôt d’origine si vous le gardez vivant.

Si vous avez déjà essayé de faire un monorepo avec les submodules, vous savez que c’est vraiment galère.

Utiliser des submodules revient à ajouter une dépendance externe dans un repo interne. On se tire rarement une balle dans le pied en 2025 avec des submodules si on peut l’éviter.

Est-ce que je vais perdre mon historique ?

Non (sauf si vous choisissez délibérement de le faire avec l’option --squash)

Deux stratégies pour rapatrier des dépôts

1) `git subtree add`

C’est rapide et rapide et natif :

git remote add my-origin git@github.com:acme/my-repository.git
git subtree add --prefix=packages/my-repository my-origin main --squash

Ici:

--prefix : le dossier cible dans votre monorepo.
--squash : optionnel, compresse l’historique si vous ne voulez pas tout garder (perso je préfère conserver l’historique).

2) `git filter-repo` + merge (plus flexible)

Vous clonez le dépôt source, réécrivez son historique pour le placer sous un sous-dossier, puis merge dans le monorepo.

Vous avez plus de contrôle sur le résultat final, vous pouvez renommer, nettoyer…

C’est cette 2ᵉ approche que j’automatise ci-dessous.

Le script pour importer un dépôt existant dans un monorepo (avec historique)

En général, on place les repositories importés dans un dossier packages. Dumoins, c’est ce que j’ai toujours rencontré, j’en déduis que c’est un standard.

Pré-requis :

Git 2.30+
git-filter-repo installé (successeur moderne de git filter-branch)

Usage :

./import-into-monorepo.sh <adresse-du-repository> [branche] <dossier-destination>

# exemple:
./import-into-monorepo.sh git@github.com:acme/my-repository.git main packages/my-repository

Et le code de import-into-monorepo.sh

#!/usr/bin/env bash
set -euo pipefail

MONOREPO_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"

REPOSITORY="${1:-}"
BRANCH="${2:-main}"
FOLDER="${3:-}"

if [[ -z $REPOSITORY ]]; then
    echo "Usage: $0 <repository> [branch] [folder]"
    echo "Example: $0 git@github.com:acme/my-repository.git main packages/my-repository"
    exit 1
fi

if [[ -z ${FOLDER} ]]; then
    echo "Error: <folder> (destination in monorepo) is required"
    exit 1
fi

if ! command -v git-filter-repo >/dev/null 2>&1; then
    echo "Error: git-filter-repo not found. Install it: https://github.com/newren/git-filter-repo"
    exit 1
fi

if [[ -d $FOLDER ]]; then
    echo "Folder $FOLDER already exists in the monorepo"
    exit 1
fi

# Clean temp workdir
if [[ -d /tmp/workdir ]]; then
    rm -Rf /tmp/workdir
fi

# Clone source repo (single branch)
cd /tmp
git clone --branch "$BRANCH" --single-branch "$REPOSITORY" /tmp/workdir

# Rewrite history to move repo into $FOLDER
cd /tmp/workdir
git filter-repo --to-subdirectory-filter "$FOLDER"

# Merge rewritten history into monorepo
cd "$MONOREPO_DIR"
git remote -v | grep -q "repo-to-import" && git remote remove repo-to-import || true
git remote add repo-to-import /tmp/workdir
git fetch repo-to-import

# If you want to allow unrelated histories (typical case)
git merge --allow-unrelated-histories "repo-to-import/$BRANCH" -m "Import $REPOSITORY into $FOLDER"

# Optional: cleanup remote
git remote remove repo-to-import || true

echo "✅ Imported $REPOSITORY into monorepo at $FOLDER (branch: $BRANCH)."

Bonus : workflow GitHub Actions (optionnel) pour pousser le code vers l’ancien repository

Maintenant, vous pourriez avoir envie de garder l’ancien dépôt actif. Par exemple, si vous avez des Github actions qui tournent dessus, ou si vous souhaitez garder des PR ouvertes…

Vous pouvez automatiser ce processus avec GitHub Actions.

Créer un fichier .github/workflows/push-subtree.yml avec le contenu suivant :

name: Push subtrees
on:
  push:
    branches: [ main ]
    paths:
      - 'packages/my-repository/**'

jobs:
  push-subtree:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Push subtree to legacy repo
        run: |
          git remote add legacy git@github.com:acme/my-repository.git
          git subtree push --prefix=packages/my-repository legacy main

Cette action va se déclencher à chaque push sur le branch main, s’il y a eu des modificationsdans le dossier packages/my-repository, et va renvoyer les dernières modifications sur le dépôt d’origine.

Comment améliorer votre CV (du point de vue d'un CTO) ?

2025-05-08T00:00:00+00:00

Je ne suis pas recruteur, et je n’ai pas la prétention d’être expert en recrutement.

Par contre, en tant que CTO, et leader technique depuis quelques années déjà, j’ai été amené à lire un bon paquet de CV. J’estime avoir mené environ 350 entretiens techniques. Je n’aurai pas la prétention de parler d’erreurs, mais je vois des choses qui dévalorisent parfois les CV que je lis, et je voudrais partager quelques conseils pour vous aider à mieux valoriser votre profil.

C’est un billet que j’aurais aimé lire il y a quelques années, côté candidat, et qui j’espère pourra vous aider.

Il existe des tonnes de sites sur le sujet, mais curieusement peu me paraissent concrets, c’est souvent des sites qui semblent plus vouloir faire du trafic que de réellement partager des retours d’expérience réels ; J’espère combler un peu ce manque.

Comment ça se passe quand un recruteur reçoit un CV ?

L’habitude consiste à utiliser un ATS (Applicant Tracking System) pour trier les CV. C’est exactement comme l’outil de ticketing que vous avez l’habitude d’utiliser (comme Jira, Trello, Asana…), mais avec des CV.

Ca veut dire que, comme pour ces outils, c’est parfois un peu le bazar et fastidieux à utiliser.

Voici par exemple une vue de l’ATS de WelcomeToTheJungle:

Même si la capture est anonymisée, vous pouvez remarquer une chose : il y a beaucoup de candidats. Et, d’aussi loin que je recrute, c’est toujours le cas. L’exemple ci-dessus est une annonce pour un poste de développeur front-end, et il y a déjà 150 candidats.

Vu le nombre de candidats, et même si c’est super important, il est difficile de passer plus de quelques secondes, ou dizaines de secondes, sur un CV.

C’est la partie la plus difficile pour un candidat : il faut se démarquer, et faire en sorte que le·la recruteur·se ait envie de passer plus de temps sur votre CV.

D’un point de vue recruteur, c’est pas évident : l’enjeu est énorme, et refouler un CV est un geste humainement difficile, car on sait qu’un·e candidat·e a passé du temps à postuler, et attend beaucoup de cette candidature. Recruter a un un impact monumental sur la vie des gens, et c’est pas un geste anodin. Mais il faut bien faire le tri et rester pragmatique.

Plus vous aiderez le·la recruteur·se à comprendre votre parcours rapidement, plus il sera enclin à passer du temps sur votre CV.

Comment faire pour se démarquer ?

TL;DR : les essentiels

Parce qu’on n’a pas toujours le temps de lire un article entier, voici un résumé des conseils que je vais vous donner dans cet article :

Regardez cette vidéo de Google Careers.
Résumez votre parcours dès le début, et indiquez ce que vous recherchez.
Donnez des chiffres, des impacts, pas juste des mots.
Mettez le contexte de vos missions.
Ne mettez pas de lettre de motivation, sauf si elle est personnalisée.
Lisez L'Art de l'enchantement.
Privilégiez la clarté à l’exhaustivité.
Faites les calculs de date vous-mêmes
Soyez aligné… visuellement aussi.
Précisez l’usage des outils plutôt qu’un inventaire
Ayez un CV clair et beau
N'hésitez pas à relancer
Ne mettez pas d’étoiles ou de barres de progression

Vous pouvez vous arrêter là, ou continuer à lire pour avoir plus de détails sur chacun de ces conseils.

Parlez de votre impact

La première chose de mon point de vue consiste à afficher vos accomplissements.

Par exemple, dans votre expérience précédente, plutôt que de mettre quelque chose comme:

Version améliorable

Développeur front-end chez MonEntreprise (2020 - 2023)

Développement de l'application web (React)
Développement de l'API (PHP)

Trouvez un moyen de mettre en avant l’impact de votre travail. Par exemple :

Version améliorée

Développeur front-end chez MonEntreprise (2020 - 2023)

Développement de l'application web (React) : 20 composants créés, accessibilité améliorée de 30% (audit Lighthouse)
Développement de l'API (PHP) : Temps de réponse moyen réduit de 20%

Je vous invite FORTEMENT à lire la section Carrière de Google, et à visionner cette vidéo.

On me dit parfois que “oui mais moi ma boîte elle mesure rien, donc je peux pas mettre de chiffres”. Je vous réponds que c’est faux.

Vous pouvez toujours trouver un moyen de quantifier votre impact. Posez-vous ces questions :

est-ce que vous avez amélioré la productivité de l’équipe ?
Est-ce que vous avez réduit le temps de développement d’une fonctionnalité ?
Est-ce que vous avez amélioré la satisfaction des utilisateurs ?
Est-ce que vous avez réduit le nombre de bugs ?
Est-ce que vous avez amélioré la qualité du code ?
Est-ce que vous avez réduit le temps de réponse d’une API ?
Est-ce que vous avez amélioré l’accessibilité d’une application ?
Est-ce que vous avez amélioré la sécurité d’une application ?
Est-ce que vous avez amélioré la performance d’une application ?
Est-ce que vous avez amélioré l’expérience utilisateur ?
etc.

Faites un résumé de votre expérience et de ce que vous recherchez

De ce que j’ai pu glaner comme informations, un recruteur se fait une idée de votre profil en lisant la première moitié de la première page de votre CV.

C’est un peu comme la ligne de flottaison d’un site web : il faut que ça soit clair et concis.

Je vous conseille d’ajouter une phrase ou deux en haut de votre CV, qui résume votre expérience et ce que vous recherchez. Par exemple :

Version suggérée

Développeuse front-end avec 5 ans d'expérience spécialisée en Vue.js, je suis passionnée par l'accessibilité et l'optimisation des performances. Je recherche un poste dans une entreprise SaaS qui met l'accent sur la qualité du code et l'expérience utilisateur.

C’est un gain de temps pour le·la recruteur·se, et ça lui permet de savoir si vous correspondez à ce qu’il recherche. Et un bon moyen de vous démarquer.

Donnez du contexte

Un autre point important est de donner du contexte à vos missions. Par exemple, précisez combien vous étiez dans l’équipe, quel était le produit, quel était le contexte de votre mission, etc.

Par exemple, au lieu de mettre :

Version améliorable

Développeuse front-end chez MonEntreprise (3 ans)

Développement de l'application web (React)
Développement de l'API (PHP)

Essayez de mettre :

Version améliorée

Développeuse front-end chez MonEntreprise (3 ans)

Équipe de 5 personnes, produit SaaS B2C utilisé par 1000 utilisateurs actifs.

Contexte : refonte de l'application pour améliorer l'expérience utilisateur et la performance

Développement de l'application web (React) : 20 composants créés, accessibilité améliorée de 30% (audit Lighthouse)
Développement de l'API (PHP) : Temps de réponse moyen réduit de 20%

Dans le contexte, parlez de l’équipe, du produit, de la taille de l’entreprise, du nombre d’utilisateurs, etc. Le but est de donner de la perspective :

Type de boîte : ESN ? Produit SaaS ? Agence ?
Taille de l’équipe : 2 devs ? 20 ?
Mission principale : refonte ? support ? évolution ?

Précisez l’usage des outils plutôt qu’un inventaire

Pas la peine de coller une liste de 30 technos. Dites plutôt :

Docker : optimisation des images et des temps de build
PostgreSQL : optimisation de requêtes lentes

Mentionnez aussi les “évidences” comme Git, bash, etc. quand vous avez un profil junior ; ça peut rassurer.

Par exemple, au lieu de mettre :

Version améliorable

Développeuse front-end chez MonEntreprise (3 ans)

(...)

Technos : Docker, PostgreSQL, React, PHP, Git, bash

Essayez de mettre :

Version améliorée

Développeuse front-end chez MonEntreprise (3 ans)

(...)

Technos : Docker (optimisation des images et des temps de build), PostgreSQL (optimisation de requêtes lentes), React (20 composants créés, accessibilité améliorée de 30% (audit Lighthouse), PHP (développement de l'API Laravel), Git, Bash

Surtout, ne mettez pas de technologies qui seraient simplement présentes dans l’entreprise, mais que vous n’avez pas utilisées.

L’exemple typique est “Tests unitaires” : si vous n’avez pas écrit de tests unitaires, ne le mettez pas, même si votre collègue José a bien écrit des tests unitaires, lui. Ce serait le meilleur moyen de créer de la frustration lors de l’entretien (et c’est vraiment hyper fréquent, je vous assure).

Ayez un CV clair et beau

Si si, je vous le promet : le style ça compte. Inconsciemment ou pas, un CV bien présenté, avec une belle mise en page, donne envie de le lire.

Je vous conseille de lire ce merveilleux livre L’Art de l’enchantement - Comment influencer les coeurs, les esprits et les actes, ce sera sans doute l’un des meilleurs investissements de votre carrière.

Je vous invite également à arrêter d’utiliser LaTeX pour faire votre CV. Oui oui c’est cool vous être trop fort·e en LaTeX, mais un CV c’est pas un article scientifique. On en voit tellement, et ils sont tous tellement similaires, que ça n’offre aucun point de différenciation ou d’ancrage mémoriel pour le·la recruteur·se.

Prenez le temps de faire un CV beau, clair, et qui vous ressemble. Vous pouvez utiliser des outils comme Canva, Figma ou Google Docs pour faire un CV qui vous ressemble.

Attention à bien garder une version “texte” de votre CV, car certains ATS font un premier tri sur le texte brut, et peuvent ne pas lire les images ou les mises en page trop complexes.

Si vous êtes, comme moi, nul·le en design, vous pouvez utiliser des modèles de CV sur Canva ou Figma, et les adapter à votre goût, et même lire Refactoring UI qui vous donnera de superbes astuces pour améliorer vos designs de manière générale.

N’hésitez pas à relancer

Si vous n’avez pas de nouvelles après une semaine, n’hésitez pas à relancer le·la recruteur·se.

Il est possible qu’il ait oublié de vous répondre, ou qu’il ait eu un contretemps, ou que votre CV soit passé à la trappe.

Ce sera sans doute un bon moyen de vous démarquer, et de montrer que vous êtes motivé·e. C’est en général un excellent signal pour le·la recruteur·se.

N’hésitez pas non plus (sans trop en faire) à échanger avec des personnes de l’entreprise sur LinkedIn. C’est un bon moyen de vous forger une opinion sur l’entreprise, et de vous faire connaître.

Expérience en remote ? Dites-le

Si vous cherchez un poste en remote, n’hésitez pas à le préciser dans votre CV, et à bien mettre en avant vos expériences en remote.

Ce sera un énorme levier plus éviter de perdre du temps à postuler pour des postes qui ne sont pas en remote, et surtout permettra au recruteur que vous êtes déjà à l’aise avec le travail à distance.

Par exemple, vous pouvez mettre :

Version suggérée

Développeuse front-end chez MonEntreprise (3 ans - 🏠 Full remote)

Ne mettez pas d’étoiles ou de barres de progression

Vous avez mis 4/5 étoiles en PHP ? Super !

Ca veut donc dire que vous avez le même niveau que ce candidat qui, lui aussi, a mis 4/5 étoiles en PHP, mais fait du PHP depuis 20 ans dans des boîtes de la Silicon Valley ? Non ? Dans ce cas évitez de mettre des étoiles ou des barres de progression.

C’est un peu comme si vous mettiez une note sur 20 à votre CV, mais sans connaître le barème de notation.

Je vous conseille de mettre plutôt un petit paragraphe qui explique votre niveau, et ce que vous savez faire avec la techno.

Par exemple, plutôt que de mettre :

Version améliorable

PHP : ⭐⭐⭐⭐

Essayez de mettre :

Version suggérée

PHP : 4 ans d'expérience, développement d'API RESTful avec Symfony et Laravel, optimisation de requêtes SQL, tests unitaires et fonctionnels.

Si vous pouvez, mentionnez votre compte GitHub

Alors non, je ne dis pas que vous devez avoir un compte GitHub et avoir fait des tonnes de contribution Open Source pour postuler.

On a tous une vie, et j’espère que la majorité des recruteurs en sont conscients. Chacun contribue à son rythme, selon ses envies.

Mais si vous avez un compte Github étoffé, c’est un vrai plus à mentionner sur votre CV. Vous pouvez tout à fait mettre une section complémentaire “Open Source” ou “Contributions” dans votre CV, et mettre le lien vers votre compte GitHub.

Une grosse réserve toutefois : si votre compte ne contient que des exercices imposés lors de votre formation, ce n’est pas très intéressant pour le·la recruteur·se. Essayez de mettre en avant des projets personnels, ou des contributions à des projets Open Source.

vous venez d’un bootcamp ? Ajoutez un portfolio.

Les formations bootcamp (type OpenClassroom) sont légion. Pour ne pas dire hyper saturées.

Si vous êtes junior·e, avec peu d’expérience, le seul moyen efficace de vous démarquer est de montrer vos projets. Je sais que c’est pénible, mais c’est un passage obligé dans votre cas, car le marché est saturé de candidats avec des formations similaires.

N’hésitez pas à ajouter une ou deux pages à votre CV, avec un titre clair “Portfolio”, et à mettre en avant vos projets annexes. Même si ces projets ne sont pas en ligne, ou n’ont pas d’utilisateurs, c’est pas grave. Le but est de montrer que vous êtes capable de mener un projet à terme, et que vous avez une certaine autonomie.

Je fais un aparté un instant : le marché est, de mon point de vue, sursaturé de candidat·e·s issu·e·s de reconversions courtes. Des écoles vous font croire qu’avec une formation de trois mois, vous trouverez un CDI payé 50 K€. C’est faux, et ça le sera toujours. Je ne dis pas que ces formations sont inutiles, mais elles ne sont pas suffisantes pour vous faire décrocher un CDI.

Faites les calculs vous-mêmes

Un truc un peu idiot mais impactant, c’est de faire les calculs vous-mêmes. Par exemple, indiquez le nombre d’années passées dans une entreprise plutôt que simplement mettre les dates de début et de fin.

Par exemple, au lieu de mettre :

Version améliorable

Développeur front-end chez MonEntreprise (2020 - 2023)

Essayez de mettre :

Version améliorée

Développeur front-end chez MonEntreprise (3 ans)

Excepté si les dates sont importantes, évitez d’ajouter trop de charge mentale au recruteur, qui, je le rappelle, ne passera pas plus de quelques secondes sur votre CV.

Ne mettez pas de lettre de motivation, sauf si

Que pensez-vous de cette lettre de motivation ?

Version améliorable

Lettre de motivation

Bonjour,

Je suis très intéressé·e par le poste de développeur·se front-end chez MonEntreprise. Je serai ravie de mettre mes compétences au service de votre entreprise.

Forte de mes 5 ans d'expérience en développement front-end, je suis convaincue que je pourrai apporter une réelle valeur ajoutée à votre équipe.

Je vous remercie de l'attention que vous porterez à ma candidature.

Cordialement,

Jeanne Dupont

C’est une perte de temps.

A force de lire des lettres de motivation, on finit par se rendre compte que c’est un simple copier-coller de la même lettre. Je pense que la très large majorité des candidats·es copie-colle le premier exemple de lettre trouvé sur Google, et le personnalise un peu. Autant vous dire que ça ne sert à rien.

Par contre, j’ai souvent bien accroché avec des lettres de motivation qui étaient bien écrites, et qui montraient que la personne avait pris le temps de se renseigner sur l’entreprise, et sur le poste.

A l’heure de ChatGPT, je pense que ça vaut le coup de prendre 5 minutes pour coller l’annonce dans chatGPT, coller votre CV, et lui demander de vous faire une lettre de motivation “personnalisée” pour le poste.

Si votre lettre de motivation n’est pas personnalisée, ne mettez pas de lettre de motivation, et mettez plutôt un lien vers votre profil LinkedIn, ou vers votre portfolio.

Personnalisez votre CV

C’est la partie pénible, mais c’est un passage obligé. Ne postulez pas avec le même CV pour toutes les annonces.

C’est hyper long, hyper fastidieux, et je sais que c’est pas évident. Mais c’est un passage obligé si vous voulez vous démarquer.

Parfois, il suffit de changer le résumé en haut de votre CV, ou de mettre en avant certaines expériences plutôt que d’autres.

Par exemple, pour une annonce “Développeur·se front-end React”, mettez en avant la compétence React, et mettez le en avant dans votre résumé de haut de page.

Version suggérée

Développeuse front-end avec 5 ans d'expérience, ayant une forte appétence en React, je suis passionnée par l'accessibilité et l'optimisation des performances. Je recherche un poste dans une entreprise SaaS qui met l'accent sur la qualité du code et l'expérience utilisateur.

Ne mentez pas bien sûr, mais essayez de mettre en avant les compétences qui sont demandées dans l’annonce.

Ensuite ?

Je pourrai probablement continuer, mais je crois qu’en respectant déjà ces quelques conseils, vous aurez un CV qui se démarquera plus facilement.

Je n’ai pas tellement l’habitude d’aborder ce genre de problématiques sur mon blog, alors dites moi si ce genre de sujets vous intéresse. Je pourrai également, par exemple, faire un retour sur les entretiens, si jamais ça peut intéresser du monde.

N’hésitez pas également à partager vos propres conseils ici, je suis sûr que ça peut aider du monde.

PHP Ecosystem Deep Dive: The Code Quality Landscape

2025-03-05T00:00:00+00:00

A quick word about the approach

Hi! I'm Jean-François Lépine, and I've been interested in software quality for quite a few years now. I created PhpMetrics, then Ast-Metrics, and have helped many companies in industrializing their development processes.

I wanted to see the big picture of PHP code in the wild, so I went all in. I downloaded the entire PHP ecosystem—a whopping 236 GB of Git repositories containing a total of 2.3 billion lines of code.

The analysis script ran for three full days, processing every single file. I built it in Go for raw performance and precise CPU control - PHP analysis at this scale needs serious optimization.

TL;DR - Too Long? Didn’t Read? Here’s the Short Version!

PHP open-source is modern, modular, and maintainable. But beware of over-reliance on a few core packages and under-maintained projects.

Modern PHP is modular and concise

36% of files have fewer than 100 lines of code
Heavy use of interfaces makes the ecosystem highly modular.

Complexity is mostly under control, but…

76.5% of files have low cyclomatic complexity (0-10).
However, 23.5% of the code is complex, posing maintainability challenge

Extreme dependency on a small set of packages

Just 136 packages (0.05%) account for 50% of all downloads.
These core libraries are well-maintained, but they create strong dependency risks.

The "shadow infrastructure" problem

Some highly used packages receive very little recognition (few GitHub stars).
Critical dependencies may be maintained by very small teams.

The PHP ecosystem is healthy but aging

70% of packages show minimal activity.
23% appear abandoned, making dependency audits essential.

X-Ray of the PHP OpenSource Ecosystem

Open Source vs Enterprise Context:

It's important to note that these metrics come from open-source projects, which differ significantly from typical enterprise codebases. Open-source libraries often prioritize extensibility and abstraction (explaining the high interface-to-class ratio), while enterprise projects may focus more on business logic implementation and specific use cases. When benchmarking your own codebase, consider whether your context aligns more with library design patterns or application-specific implementations.

I analyzed 11.1 million PHP files, totaling over 707.6 million lines of PHP code—part of a staggering 2.3 billion lines of code across all languages in the Packagist ecosystem. These metrics offer a real-world snapshot of how PHP is structured in the wild, beyond theoretical best practices."

File Size Distribution

An overwhelming 36% of files contain fewer than 100 logical lines of code, with a median of just 4.0 lines.

This reveals a strong ecosystem-wide preference for small, focused implementations - much smaller than most style guides would suggest as maximums. It also reflects the massive use of interfaces in the ecosystem, with 3.7M interfaces compared to 7.4M classes - many of these interfaces containing no logical code, only method signatures.

Cyclomatic Complexity

76.5% of files maintain low complexity (0-10), while 23.5% venture into higher complexity territory.

Even with a focus on small files, nearly a quarter of the codebase still shows significant complexity – highlighting areas where maintainability might be challenging.

Analyzed Packages

411.6K

PHP packages from PHP ecosystem

Files

11.1M

Detected PHP files

Methods

53.4M

Analyzed PHP methods

Lines of Code

707.6M

Total lines of code

Including 362.9M logical lines of code

Logical lines of code distribution

Cyclomatic complexity distribution

Download Concentration: The Foundation of PHP

One of the most revealing aspects of the PHP ecosystem is the extreme concentration of downloads.

The data shows that just 136 packages (0.05 % of all packages) account for more than half of all monthly downloads in the entire ecosystem.

This concentration reflects several important dynamics in the PHP world:

Consolidated Foundation

The PHP ecosystem has matured to rely on a relatively small set of core libraries that provide essential functionality. This stable foundation means developers don't need to constantly evaluate competing implementations for basic needs.

Dependency Chain Effects

Many top packages are fundamental building blocks that get pulled in as transitive dependencies across thousands of projects. This cascading effect magnifies download counts for these foundational packages.

🎉 The Good News

The encouraging finding is that these high-impact packages are overwhelmingly well-maintained and healthy:

✓ Nearly all top packages have active contributor communities
✓ Most have robust test suites and CI/CD pipelines in place
✓ Many are backed by companies or foundations ensuring long-term stability

Download Dominance

Packages that collectively represent 50% or more of monthly downloads

Number of dominant packages

136

% of total downloads

0.05

Monthly total downloads

2808.6M

Package	Monthly downloads	%	Stars
symfony/deprecation-contracts	15.7M	0.55	2053.0
symfony/polyfill-mbstring	15.5M	0.55	7847.0
psr/log	15.2M	0.55	10421.0
psr/container	15.0M	0.55	9981.0
symfony/console	14.9M	0.55	9785.0
symfony/service-contracts	14.7M	0.5	2595.0
symfony/polyfill-intl-normalizer	14.6M	0.5	2026.0
psr/http-message	14.5M	0.5	6998.0
guzzlehttp/psr7	14.2M	0.5	7905.0
guzzlehttp/promises	14.1M	0.5	7645.0
symfony/process	14.1M	0.5	7453.0
symfony/polyfill-ctype	14.1M	0.5	4056.0
symfony/finder	14.0M	0.5	8436.0
guzzlehttp/guzzle	14.0M	0.5	23313.0
symfony/string	13.9M	0.5	1741.0
ralouphie/getallheaders	13.9M	0.5	3778.0
psr/http-factory	13.6M	0.5	1827.0
nikic/php-parser	13.6M	0.5	17179.0
symfony/polyfill-php80	13.6M	0.5	1731.0
symfony/polyfill-intl-grapheme	13.6M	0.5	1689.0
psr/http-client	13.3M	0.45	1685.0
symfony/event-dispatcher	13.3M	0.45	8534.0
monolog/monolog	13.1M	0.45	21132.0
symfony/event-dispatcher-contracts	13.1M	0.45	3394.0
symfony/var-dumper	13.0M	0.45	7426.0
myclabs/deep-copy	12.8M	0.45	8807.0
phpunit/phpunit	12.7M	0.45	19791.0
symfony/http-foundation	12.7M	0.45	8652.0
sebastian/diff	12.6M	0.45	7600.0
doctrine/lexer	12.6M	0.45	11102.0
symfony/translation-contracts	12.4M	0.45	2576.0
phpunit/php-code-coverage	12.3M	0.45	8863.0
symfony/polyfill-intl-idn	12.3M	0.45	3339.0
sebastian/comparator	12.3M	0.45	7024.0
sebastian/exporter	12.3M	0.45	6801.0
psr/event-dispatcher	12.2M	0.45	2209.0
phpunit/php-file-iterator	12.2M	0.45	7444.0
sebastian/recursion-context	12.2M	0.45	6556.0
sebastian/global-state	12.1M	0.45	6584.0
sebastian/version	12.1M	0.45	6557.0
phpunit/php-timer	12.1M	0.45	7684.0
sebastian/environment	12.1M	0.45	6752.0
webmozart/assert	12.1M	0.45	7588.0
phpunit/php-text-template	12.1M	0.45	7389.0
symfony/http-kernel	12.0M	0.45	8126.0
sebastian/object-enumerator	12.0M	0.45	6507.0
sebastian/code-unit-reverse-lookup	11.9M	0.4	6690.0
symfony/yaml	11.9M	0.4	3826.0
symfony/error-handler	11.9M	0.4	2623.0
theseer/tokenizer	11.9M	0.4	5177.0
phar-io/manifest	11.9M	0.4	7431.0
symfony/translation	11.9M	0.4	6620.0
sebastian/object-reflector	11.8M	0.4	6257.0
symfony/mime	11.8M	0.4	2794.0
phar-io/version	11.8M	0.4	7429.0
symfony/routing	11.8M	0.4	7623.0
psr/simple-cache	11.5M	0.4	8104.0
sebastian/type	11.5M	0.4	1434.0
doctrine/inflector	11.5M	0.4	11290.0
psr/cache	11.2M	0.4	5138.0
egulias/email-validator	11.2M	0.4	11517.0
sebastian/cli-parser	11.1M	0.4	1132.0
symfony/css-selector	11.1M	0.4	7440.0
sebastian/complexity	11.1M	0.4	1183.0
sebastian/lines-of-code	11.0M	0.4	1101.0
phpunit/php-invoker	11.0M	0.4	1256.0
ramsey/uuid	11.0M	0.4	12515.0
sebastian/code-unit	11.0M	0.4	1131.0
psr/clock	10.9M	0.4	526.0
doctrine/deprecations	10.7M	0.4	1707.0
brick/math	10.6M	0.4	1907.0
ramsey/collection	10.4M	0.35	1153.0
nesbot/carbon	10.1M	0.35	48.0
symfony/polyfill-php83	9.8M	0.35	357.0
league/flysystem	9.7M	0.35	13410.0
league/mime-type-detection	9.6M	0.35	1300.0
symfony/mailer	9.6M	0.35	1527.0
doctrine/instantiator	9.4M	0.35	10975.0
symfony/filesystem	9.2M	0.35	4621.0
vlucas/phpdotenv	9.0M	0.3	13265.0
phpoption/phpoption	8.9M	0.3	2644.0
psy/psysh	8.7M	0.3	9767.0
dragonmantank/cron-expression	8.6M	0.3	4594.0
nette/utils	8.5M	0.3	2034.0
carbonphp/carbon-doctrine-types	8.4M	0.3	156.0
tijsverkoyen/css-to-inline-styles	8.4M	0.3	5826.0
voku/portable-ascii	8.4M	0.3	555.0
composer/semver	8.4M	0.3	3195.0
fakerphp/faker	8.3M	0.3	3696.0
graham-campbell/result-type	8.3M	0.3	504.0
paragonie/random_compat	8.2M	0.3	8178.0
laravel/serializable-closure	8.2M	0.3	550.0
dflydev/dot-access-data	8.2M	0.3	666.0
symfony/options-resolver	8.1M	0.3	3222.0
phpdocumentor/type-resolver	8.1M	0.3	9161.0
phpstan/phpdoc-parser	8.0M	0.3	1398.0
symfony/polyfill-php81	8.0M	0.3	877.0
symfony/polyfill-uuid	8.0M	0.3	657.0
doctrine/dbal	8.0M	0.3	9554.0
phpdocumentor/reflection-common	7.9M	0.3	9045.0
league/commonmark	7.9M	0.3	2807.0
symfony/uid	7.9M	0.3	568.0
laravel/framework	7.9M	0.3	33237.0
nette/schema	7.8M	0.3	939.0
composer/pcre	7.8M	0.3	597.0
mockery/mockery	7.8M	0.3	10661.0
doctrine/event-manager	7.8M	0.3	5964.0
firebase/php-jwt	7.7M	0.3	9526.0
hamcrest/hamcrest-php	7.7M	0.3	6970.0
aws/aws-sdk-php	7.7M	0.3	6082.0
symfony/var-exporter	7.7M	0.25	2065.0
mtdowling/jmespath.php	7.7M	0.25	1954.0
sebastian/resource-operations	7.5M	0.25	6281.0
league/flysystem-local	7.5M	0.25	180.0
laravel/tinker	7.4M	0.25	7363.0
phpdocumentor/reflection-docblock	7.4M	0.25	9360.0
league/config	7.4M	0.25	519.0
doctrine/cache	7.4M	0.25	7868.0
paragonie/constant_time_encoding	7.1M	0.25	836.0
phpseclib/phpseclib	7.1M	0.25	5434.0
aws/aws-crt-php	7.1M	0.25	367.0
filp/whoops	7.0M	0.25	13218.0
phpstan/phpstan	7.0M	0.25	13240.0
guzzlehttp/uri-template	6.9M	0.25	154.0
nunomaduro/termwind	6.9M	0.25	2377.0
symfony/config	6.7M	0.25	4248.0
laravel/prompts	6.7M	0.25	562.0
fruitcake/php-cors	6.7M	0.25	261.0
symfony/dependency-injection	6.7M	0.25	4130.0
symfony/http-client-contracts	6.6M	0.25	1952.0
symfony/polyfill-php73	6.6M	0.25	2399.0
symfony/clock	6.5M	0.25	353.0
league/uri-interfaces	6.5M	0.25	482.0
symfony/cache	6.5M	0.25	4125.0
league/uri	6.5M	0.25	1060.0
doctrine/annotations	6.4M	0.25	6742.0

The Invisible Infrastructure: High-Impact, Low-Recognition Packages

While analyzing the relationship between GitHub stars and download counts, we discovered a fascinating subset of PHP packages: those with massive download numbers but surprisingly few stars. These packages form what might be called the "invisible infrastructure" of PHP—critically important components that operate silently beneath the surface of countless applications.

This "recognition gap" has several important implications:

⚠ Packages with high impact but low visibility might struggle to attract contributors
⚠ Critical dependencies may be maintained by small teams despite their outsized ecosystem importance
✓ However, many represent opportunities for developers looking to make meaningful contributions to the PHP ecosystem

Package	Monthly download	Stars
staabm/side-effects-detector	3.6M	76.0
spatie/error-solutions	2.5M	42.0
google/longrunning	2.3M	43.0
illuminate/macroable	1.8M	73.0
pestphp/pest-plugin	1.6M	37.0
php-http/guzzle7-adapter	1.6M	79.0
ta-tikoma/phpunit-architecture-test	1.5M	91.0
pestphp/pest-plugin-arch	1.4M	33.0
symfony/polyfill-php82	1.4M	55.0
illuminate/conditionable	1.4M	81.0
kelunik/certificate	1.4M	92.0
amphp/pipeline	1.4M	54.0
open-telemetry/api	1.3M	14.0
pear/pear_exception	1.3M	97.0
open-telemetry/context	1.2M	11.0
pear/pear-core-minimal	1.2M	77.0
pear/console_getopt	1.1M	84.0
phpcsstandards/phpcsutils	1.1M	55.0
mpdf/psr-log-aware-trait	1.0M	46.0
codeception/module-asserts	1.0M	80.0
pear/archive_tar	1.0M	74.0
mpdf/psr-http-message-shim	998.5K	33.0
consolidation/self-update	960.2K	98.0
async-aws/core	957.8K	85.0
consolidation/site-alias	917.2K	59.0
symfony/polyfill-php84	892.0K	20.0
consolidation/filter-via-dot-access-data	880.8K	45.0
codeception/lib-innerbrowser	874.9K	83.0
consolidation/site-process	866.7K	50.0
drupal/core-composer-scaffold	858.8K	49.0

Popular packages

In contrast, these packages are both very popular and widely used. They are the cornerstone of PHP.

bubble size proportional to GitHub forks

Packagist Ecosystem Health Status

Analysis of PHP packages reveals significant health concerns in the Packagist ecosystem: 70% show minimal activity with few downloads and GitHub interactions, while 23% appear abandoned with no recent updates. With an average of just 60 stars per package (heavily skewed by popular outliers), these metrics highlight the typical "long tail" distribution in open source ecosystems. This data emphasizes the importance of carefully evaluating dependency health through metrics like bus factor, update frequency, and community engagement when integrating packages into production projects.

Empty Packages

94.9K

Abandonned packages

Shadow packages

288.5K

Packages with few downloads, few GitHub stars or forks

Average Popularity

Average stars per package

Excluding non-starred packages

Top required packages for development

Package	Number of packages using it
phpunit/phpunit	201.5K
orchestra/testbench	33.9K
squizlabs/php_codesniffer	33.8K
phpstan/phpstan	32.3K
mockery/mockery	31.8K
friendsofphp/php-cs-fixer	24.4K
pestphp/pest	11.5K
vimeo/psalm	10.5K
phpstan/phpstan-phpunit	9.7K
laravel/pint	9.6K
phpstan/extension-installer	9.0K
symfony/var-dumper	8.9K
nunomaduro/collision	8.4K
roave/security-advisories	8.2K
phpmd/phpmd	6.7K
symfony/phpunit-bridge	6.5K
phpstan/phpstan-deprecation-rules	6.4K
pestphp/pest-plugin-laravel	6.2K
satooshi/php-coveralls	6.0K
php-coveralls/php-coveralls	5.8K

Top required packages for production

Package	Number of packages using it
illuminate/support	46.4K
guzzlehttp/guzzle	39.7K
laravel/framework	18.9K
illuminate/contracts	16.2K
yiisoft/yii2	16.2K
symfony/console	13.0K
psr/log	11.7K
symfony/framework-bundle	11.2K
illuminate/database	10.2K
composer/installers	9.0K
symfony/yaml	8.8K
psr/http-message	8.6K
monolog/monolog	8.0K
symfony/dependency-injection	7.7K
symfony/http-kernel	7.6K
symfony/http-foundation	7.1K
symfony/config	7.1K
twig/twig	6.6K
spatie/laravel-package-tools	6.5K
doctrine/orm	6.4K

But What About Quality?

Despite PHP's occasionally maligned reputation, the data tells a different story. PHP packages show surprisingly clean code that's easy to maintain and understand. Functions are refreshingly short, different parts of the code play well together, and packages stay reasonably sized. Turns out PHP developers aren't writing spaghetti code after all - they're crafting well-structured dishes that would make even the pickiest code chefs nod in approval.

Complexity Distribution

Average Cyclomatic

8.8

Median Cyclomatic

4.0

Code Quality

Maintainability Index

108

Lines per Method

3.0

Packages with Most Lines of Code

If you are curious about the packages with the most lines of code, you can find the top 100 packages below. Note that the biggest packages concerns geographical data, and embed a lot of data in their code.

Package	Lines of Code	Files
xnrcms/alipaysdk	2.8M	11.4K
zerossb/laravel-world	2.2M	48.0
tencentcloud/tencentcloud-sdk-php-intl-en	1.9M	19.2K
vccmas/tencentcloud-sdk-php-intl-en	1.6M	15.5K
zohocrm/php-sdk-6.0	1.5M	15.7K
udemy/googleads-php-lib	1.5M	1.1K
volcengine/volcengine-php-sdk	1.3M	3.1K
vavajke/bxcore	1.3M	4.4K
sos-solution/other-framework	1.2M	8.7K
tombeachell/forza-magento	1.2M	4.2K

What Else Is Hiding in PHP Repositories?

Analyzing PHP on Packagist is one thing, but what about everything around PHP? The reality is, modern PHP projects rely on a diverse tech stack.

🔍 Here’s what I found inside the repositories:

PHP dominates (707M+ lines of code), but it’s far from alone.
JavaScript is the most common companion (216M+ lines), proving that front-end and back-end integration is key.
JSON & YAML are everywhere (200M+ lines combined), highlighting the rise of configuration-driven architectures.
CSS & HTML (167M+ lines total) showcase the full-stack nature of many PHP applications.
SQL, XML, and Markdown reflect the importance of structured data and documentation in modern PHP projects.

💡 Surprising finds:

TypeScript is growing (2.7M lines) – are PHP projects becoming more structured in the front end?
C, Go, and Rust appear in small amounts – a sign of performance-critical extensions?
Even Lua, Perl, and Scheme pop up – legacy integrations or scripting tools within PHP projects?

👉 Modern PHP is more than just PHP. It’s an ecosystem that blends with various technologies, making cross-language skills increasingly valuable for PHP developers.

Repartition of lines of code by language (top 10)

What's Next?

Now that most of the process is scripted, I still have some code cleanup to tackle, but I think it would be valuable to run this analysis at least twice a year to keep an up-to-date view of the PHP ecosystem. So far, I've focused exclusively on Packagist, but it's not the only package manager out there - adding new code sources would provide a more comprehensive picture.

I'm also considering implementing more advanced code metrics to deepen the analysis. The current metrics give us a good foundation, but there's always more we could learn about code quality and ecosystem health.

If you have ideas for additional metrics or features that would enhance this dashboard, please reach out - your insights could help shape the future direction of this project!

Plongée dans l'écosystème PHP : État des lieux de la qualité du code

2025-03-05T00:00:00+00:00

Un mot rapide sur l'approche

Bonjour ! Je suis Jean-François Lépine, et je m'intéresse à la qualité logicielle depuis plusieurs années. J'ai créé PhpMetrics, puis Ast-Metrics, et j'ai aidé de nombreuses entreprises à industrialiser leurs processus de développement.

Je voulais avoir une vue d'ensemble du code PHP existant, alors j'ai tout analysé. J'ai téléchargé l'intégralité de l'écosystème PHP - pas moins de 236 Go de dépôts Git contenant au total 2,3 milliards de lignes de code.

Le script d'analyse a tourné pendant trois jours complets, traitant chaque fichier. Je l'ai développé en Go pour des performances optimales et un contrôle précis du CPU - l'analyse PHP à cette échelle nécessite une optimisation sérieuse.

TL;DR - Trop long ? Pas lu ? Voici la version courte !

Le PHP open-source est moderne, modulaire et maintenable. Mais attention à la dépendance excessive à quelques packages centraux et aux projets sous-maintenus.

Le PHP moderne est modulaire et concis

36% des fichiers ont moins de 100 lignes de code
L'utilisation intensive des interfaces rend l'écosystème hautement modulaire.

La complexité est globalement maîtrisée, mais...

76,5% des fichiers ont une faible complexité cyclomatique (0-10).
Cependant, 23,5% du code est complexe, posant un défi de maintenabilité

Dépendance extrême à un petit ensemble de packages

Seulement 136 packages (0,05%) représentent 50% de tous les téléchargements.
Ces bibliothèques centrales sont bien maintenues, mais créent des risques de dépendance importants.

Le problème de "l'infrastructure fantôme"

Certains packages très utilisés reçoivent très peu de reconnaissance (peu d'étoiles GitHub).
Des dépendances critiques peuvent être maintenues par de très petites équipes.

L'écosystème PHP est sain mais vieillissant

70% des packages montrent une activité minimale.
23% semblent abandonnés, rendant l'audit des dépendances essentiel.

Radiographie de l'écosystème Open Source PHP

Open Source vs Contexte Entreprise :

Il est important de noter que ces métriques proviennent de projets open-source, qui diffèrent significativement des bases de code typiques d'entreprise. Les bibliothèques open-source privilégient souvent l'extensibilité et l'abstraction (ce qui explique le ratio élevé interfaces/classes), tandis que les projets d'entreprise se concentrent davantage sur l'implémentation de la logique métier et des cas d'utilisation spécifiques. Lors de l'évaluation de votre propre base de code, considérez si votre contexte s'aligne davantage avec les modèles de conception de bibliothèques ou les implémentations spécifiques aux applications.

J'ai analysé 11,1 millions de fichiers PHP, totalisant plus de 707,6 millions de lignes de code PHP — faisant partie d'un impressionnant total de 2,3 milliards de lignes de code toutes langues confondues dans l'écosystème Packagist. Ces métriques offrent un aperçu réel de la structure du PHP dans la nature, au-delà des bonnes pratiques théoriques.

Distribution de la taille des fichiers

Une écrasante majorité de 36% des fichiers contiennent moins de 100 lignes de code logique, avec une médiane de seulement 4,0 lignes.

Cela révèle une forte préférence à l'échelle de l'écosystème pour des implémentations petites et ciblées - bien plus petites que ce que la plupart des guides de style suggèrent comme maximum. Cela reflète également l'utilisation massive des interfaces dans l'écosystème, avec 3,7M d'interfaces comparé à 7,4M de classes - beaucoup de ces interfaces ne contenant aucun code logique, uniquement des signatures de méthodes.

Complexité Cyclomatique

76,5% des fichiers maintiennent une faible complexité (0-10), tandis que 23,5% s'aventurent dans un territoire de plus haute complexité.

Même avec un accent mis sur les petits fichiers, près d'un quart de la base de code montre encore une complexité significative – mettant en évidence des zones où la maintenabilité pourrait être problématique.

Packages Analysés

411,6K

Packages PHP de l'écosystème PHP

Fichiers

11,1M

Fichiers PHP détectés

Méthodes

53,4M

Méthodes PHP analysées

Lignes de Code

707,6M

Total des lignes de code

Dont 362,9M lignes de code logique

Distribution des lignes de code logique

Distribution de la complexité cyclomatique

Concentration des téléchargements : Le fondement de PHP

L'un des aspects les plus révélateurs de l'écosystème PHP est l'extrême concentration des téléchargements.

Les données montrent que seulement 136 packages (0,05 % de tous les packages) représentent plus de la moitié de tous les téléchargements mensuels dans l'ensemble de l'écosystème.

Cette concentration reflète plusieurs dynamiques importantes dans le monde PHP :

Une base consolidée

L'écosystème PHP a mûri pour s'appuyer sur un ensemble relativement restreint de bibliothèques centrales qui fournissent des fonctionnalités essentielles. Cette base stable signifie que les développeurs n'ont pas besoin d'évaluer constamment des implémentations concurrentes pour les besoins fondamentaux.

Effets de chaîne des dépendances

De nombreux packages populaires sont des éléments fondamentaux qui sont inclus comme dépendances transitives dans des milliers de projets. Cet effet en cascade amplifie le nombre de téléchargements pour ces packages fondamentaux.

🎉 Les bonnes nouvelles

La découverte encourageante est que ces packages à fort impact sont très majoritairement bien maintenus et sains :

✓ Presque tous les packages populaires ont des communautés de contributeurs actives
✓ La plupart disposent de suites de tests robustes et de pipelines CI/CD
✓ Beaucoup sont soutenus par des entreprises ou des fondations assurant leur stabilité à long terme

Dominance des téléchargements

Packages qui représentent collectivement 50% ou plus des téléchargements mensuels

Nombre de packages dominants

136

% du total des téléchargements

0,05

Total des téléchargements mensuels

2808,6M

2808.6M

Package	Monthly downloads	%	Stars
symfony/deprecation-contracts	15.7M	0.55	2053.0
symfony/polyfill-mbstring	15.5M	0.55	7847.0
psr/log	15.2M	0.55	10421.0
psr/container	15.0M	0.55	9981.0
symfony/console	14.9M	0.55	9785.0
symfony/service-contracts	14.7M	0.5	2595.0
symfony/polyfill-intl-normalizer	14.6M	0.5	2026.0
psr/http-message	14.5M	0.5	6998.0
guzzlehttp/psr7	14.2M	0.5	7905.0
guzzlehttp/promises	14.1M	0.5	7645.0
symfony/process	14.1M	0.5	7453.0
symfony/polyfill-ctype	14.1M	0.5	4056.0
symfony/finder	14.0M	0.5	8436.0
guzzlehttp/guzzle	14.0M	0.5	23313.0
symfony/string	13.9M	0.5	1741.0
ralouphie/getallheaders	13.9M	0.5	3778.0
psr/http-factory	13.6M	0.5	1827.0
nikic/php-parser	13.6M	0.5	17179.0
symfony/polyfill-php80	13.6M	0.5	1731.0
symfony/polyfill-intl-grapheme	13.6M	0.5	1689.0
psr/http-client	13.3M	0.45	1685.0
symfony/event-dispatcher	13.3M	0.45	8534.0
monolog/monolog	13.1M	0.45	21132.0
symfony/event-dispatcher-contracts	13.1M	0.45	3394.0
symfony/var-dumper	13.0M	0.45	7426.0
myclabs/deep-copy	12.8M	0.45	8807.0
phpunit/phpunit	12.7M	0.45	19791.0
symfony/http-foundation	12.7M	0.45	8652.0
sebastian/diff	12.6M	0.45	7600.0
doctrine/lexer	12.6M	0.45	11102.0
symfony/translation-contracts	12.4M	0.45	2576.0
phpunit/php-code-coverage	12.3M	0.45	8863.0
symfony/polyfill-intl-idn	12.3M	0.45	3339.0
sebastian/comparator	12.3M	0.45	7024.0
sebastian/exporter	12.3M	0.45	6801.0
psr/event-dispatcher	12.2M	0.45	2209.0
phpunit/php-file-iterator	12.2M	0.45	7444.0
sebastian/recursion-context	12.2M	0.45	6556.0
sebastian/global-state	12.1M	0.45	6584.0
sebastian/version	12.1M	0.45	6557.0
phpunit/php-timer	12.1M	0.45	7684.0
sebastian/environment	12.1M	0.45	6752.0
webmozart/assert	12.1M	0.45	7588.0
phpunit/php-text-template	12.1M	0.45	7389.0
symfony/http-kernel	12.0M	0.45	8126.0
sebastian/object-enumerator	12.0M	0.45	6507.0
sebastian/code-unit-reverse-lookup	11.9M	0.4	6690.0
symfony/yaml	11.9M	0.4	3826.0
symfony/error-handler	11.9M	0.4	2623.0
theseer/tokenizer	11.9M	0.4	5177.0
phar-io/manifest	11.9M	0.4	7431.0
symfony/translation	11.9M	0.4	6620.0
sebastian/object-reflector	11.8M	0.4	6257.0
symfony/mime	11.8M	0.4	2794.0
phar-io/version	11.8M	0.4	7429.0
symfony/routing	11.8M	0.4	7623.0
psr/simple-cache	11.5M	0.4	8104.0
sebastian/type	11.5M	0.4	1434.0
doctrine/inflector	11.5M	0.4	11290.0
psr/cache	11.2M	0.4	5138.0
egulias/email-validator	11.2M	0.4	11517.0
sebastian/cli-parser	11.1M	0.4	1132.0
symfony/css-selector	11.1M	0.4	7440.0
sebastian/complexity	11.1M	0.4	1183.0
sebastian/lines-of-code	11.0M	0.4	1101.0
phpunit/php-invoker	11.0M	0.4	1256.0
ramsey/uuid	11.0M	0.4	12515.0
sebastian/code-unit	11.0M	0.4	1131.0
psr/clock	10.9M	0.4	526.0
doctrine/deprecations	10.7M	0.4	1707.0
brick/math	10.6M	0.4	1907.0
ramsey/collection	10.4M	0.35	1153.0
nesbot/carbon	10.1M	0.35	48.0
symfony/polyfill-php83	9.8M	0.35	357.0
league/flysystem	9.7M	0.35	13410.0
league/mime-type-detection	9.6M	0.35	1300.0
symfony/mailer	9.6M	0.35	1527.0
doctrine/instantiator	9.4M	0.35	10975.0
symfony/filesystem	9.2M	0.35	4621.0
vlucas/phpdotenv	9.0M	0.3	13265.0
phpoption/phpoption	8.9M	0.3	2644.0
psy/psysh	8.7M	0.3	9767.0
dragonmantank/cron-expression	8.6M	0.3	4594.0
nette/utils	8.5M	0.3	2034.0
carbonphp/carbon-doctrine-types	8.4M	0.3	156.0
tijsverkoyen/css-to-inline-styles	8.4M	0.3	5826.0
voku/portable-ascii	8.4M	0.3	555.0
composer/semver	8.4M	0.3	3195.0
fakerphp/faker	8.3M	0.3	3696.0
graham-campbell/result-type	8.3M	0.3	504.0
paragonie/random_compat	8.2M	0.3	8178.0
laravel/serializable-closure	8.2M	0.3	550.0
dflydev/dot-access-data	8.2M	0.3	666.0
symfony/options-resolver	8.1M	0.3	3222.0
phpdocumentor/type-resolver	8.1M	0.3	9161.0
phpstan/phpdoc-parser	8.0M	0.3	1398.0
symfony/polyfill-php81	8.0M	0.3	877.0
symfony/polyfill-uuid	8.0M	0.3	657.0
doctrine/dbal	8.0M	0.3	9554.0
phpdocumentor/reflection-common	7.9M	0.3	9045.0
league/commonmark	7.9M	0.3	2807.0
symfony/uid	7.9M	0.3	568.0
laravel/framework	7.9M	0.3	33237.0
nette/schema	7.8M	0.3	939.0
composer/pcre	7.8M	0.3	597.0
mockery/mockery	7.8M	0.3	10661.0
doctrine/event-manager	7.8M	0.3	5964.0
firebase/php-jwt	7.7M	0.3	9526.0
hamcrest/hamcrest-php	7.7M	0.3	6970.0
aws/aws-sdk-php	7.7M	0.3	6082.0
symfony/var-exporter	7.7M	0.25	2065.0
mtdowling/jmespath.php	7.7M	0.25	1954.0
sebastian/resource-operations	7.5M	0.25	6281.0
league/flysystem-local	7.5M	0.25	180.0
laravel/tinker	7.4M	0.25	7363.0
phpdocumentor/reflection-docblock	7.4M	0.25	9360.0
league/config	7.4M	0.25	519.0
doctrine/cache	7.4M	0.25	7868.0
paragonie/constant_time_encoding	7.1M	0.25	836.0
phpseclib/phpseclib	7.1M	0.25	5434.0
aws/aws-crt-php	7.1M	0.25	367.0
filp/whoops	7.0M	0.25	13218.0
phpstan/phpstan	7.0M	0.25	13240.0
guzzlehttp/uri-template	6.9M	0.25	154.0
nunomaduro/termwind	6.9M	0.25	2377.0
symfony/config	6.7M	0.25	4248.0
laravel/prompts	6.7M	0.25	562.0
fruitcake/php-cors	6.7M	0.25	261.0
symfony/dependency-injection	6.7M	0.25	4130.0
symfony/http-client-contracts	6.6M	0.25	1952.0
symfony/polyfill-php73	6.6M	0.25	2399.0
symfony/clock	6.5M	0.25	353.0
league/uri-interfaces	6.5M	0.25	482.0
symfony/cache	6.5M	0.25	4125.0
league/uri	6.5M	0.25	1060.0
doctrine/annotations	6.4M	0.25	6742.0

L'Infrastructure Invisible : Les Packages à Fort Impact mais Peu Reconnus

En analysant la relation entre les étoiles GitHub et le nombre de téléchargements, j'ai découvert un sous-ensemble fascinant de packages PHP : ceux qui ont des nombres de téléchargements massifs mais étonnamment peu d'étoiles. Ces packages forment ce qu'on pourrait appeler "l'infrastructure invisible" de PHP — des composants d'une importance cruciale qui opèrent silencieusement sous la surface d'innombrables applications.

Ce "déficit de reconnaissance" a plusieurs implications importantes :

⚠ Les packages à fort impact mais à faible visibilité peuvent avoir du mal à attirer des contributeurs
⚠ Des dépendances critiques peuvent être maintenues par de petites équipes malgré leur importance démesurée dans l'écosystème
✓ Cependant, beaucoup représentent des opportunités pour les développeurs cherchant à apporter des contributions significatives à l'écosystème PHP

Package	Monthly download	Stars
staabm/side-effects-detector	3.6M	76.0
spatie/error-solutions	2.5M	42.0
google/longrunning	2.3M	43.0
illuminate/macroable	1.8M	73.0
pestphp/pest-plugin	1.6M	37.0
php-http/guzzle7-adapter	1.6M	79.0
ta-tikoma/phpunit-architecture-test	1.5M	91.0
pestphp/pest-plugin-arch	1.4M	33.0
symfony/polyfill-php82	1.4M	55.0
illuminate/conditionable	1.4M	81.0
kelunik/certificate	1.4M	92.0
amphp/pipeline	1.4M	54.0
open-telemetry/api	1.3M	14.0
pear/pear_exception	1.3M	97.0
open-telemetry/context	1.2M	11.0
pear/pear-core-minimal	1.2M	77.0
pear/console_getopt	1.1M	84.0
phpcsstandards/phpcsutils	1.1M	55.0
mpdf/psr-log-aware-trait	1.0M	46.0
codeception/module-asserts	1.0M	80.0
pear/archive_tar	1.0M	74.0
mpdf/psr-http-message-shim	998.5K	33.0
consolidation/self-update	960.2K	98.0
async-aws/core	957.8K	85.0
consolidation/site-alias	917.2K	59.0
symfony/polyfill-php84	892.0K	20.0
consolidation/filter-via-dot-access-data	880.8K	45.0
codeception/lib-innerbrowser	874.9K	83.0
consolidation/site-process	866.7K	50.0
drupal/core-composer-scaffold	858.8K	49.0

Packages populaires

En contraste, ces packages sont à la fois très populaires et largement utilisés. Ils constituent la pierre angulaire de PHP.

taille des bulles proportionnelle aux forks GitHub

État de santé de l'écosystème Packagist

L'analyse des packages PHP révèle des préoccupations importantes concernant la santé de l'écosystème Packagist : 70% montrent une activité minimale avec peu de téléchargements et d'interactions GitHub, tandis que 23% semblent abandonnés sans mises à jour récentes. Avec une moyenne de seulement 60 étoiles par package (fortement influencée par les cas exceptionnels populaires), ces métriques mettent en évidence la distribution typique en "longue traîne" des écosystèmes open source. Ces données soulignent l'importance d'évaluer soigneusement la santé des dépendances à travers des métriques comme le facteur bus, la fréquence des mises à jour et l'engagement de la communauté lors de l'intégration de packages dans des projets de production.

Packages vides

94,9K

Packages abandonnés

Packages fantômes

288,5K

Packages avec peu de téléchargements, peu d'étoiles ou de forks GitHub

Popularité moyenne

Moyenne d'étoiles par package

Excluant les packages sans étoiles

Packages les plus requis pour le développement

Package	Nombre de packages l'utilisant
phpunit/phpunit	201.5K
orchestra/testbench	33.9K
squizlabs/php_codesniffer	33.8K
phpstan/phpstan	32.3K
mockery/mockery	31.8K
friendsofphp/php-cs-fixer	24.4K
pestphp/pest	11.5K
vimeo/psalm	10.5K
phpstan/phpstan-phpunit	9.7K
laravel/pint	9.6K
phpstan/extension-installer	9.0K
symfony/var-dumper	8.9K
nunomaduro/collision	8.4K
roave/security-advisories	8.2K
phpmd/phpmd	6.7K
symfony/phpunit-bridge	6.5K
phpstan/phpstan-deprecation-rules	6.4K
pestphp/pest-plugin-laravel	6.2K
satooshi/php-coveralls	6.0K
php-coveralls/php-coveralls	5.8K

Top required packages for production

Package	Number of packages using it
illuminate/support	46.4K
guzzlehttp/guzzle	39.7K
laravel/framework	18.9K
illuminate/contracts	16.2K
yiisoft/yii2	16.2K
symfony/console	13.0K
psr/log	11.7K
symfony/framework-bundle	11.2K
illuminate/database	10.2K
composer/installers	9.0K
symfony/yaml	8.8K
psr/http-message	8.6K
monolog/monolog	8.0K
symfony/dependency-injection	7.7K
symfony/http-kernel	7.6K
symfony/http-foundation	7.1K
symfony/config	7.1K
twig/twig	6.6K
spatie/laravel-package-tools	6.5K
doctrine/orm	6.4K

Et qu'en est-il de la qualité ?

Malgré la réputation parfois critiquée de PHP, les données racontent une histoire différente. Les packages PHP montrent un code étonnamment propre, facile à maintenir et à comprendre. Les fonctions sont remarquablement courtes, les différentes parties du code s'harmonisent bien et les packages gardent une taille raisonnable. Il s'avère que les développeurs PHP n'écrivent pas du code spaghetti après tout - ils élaborent des plats bien structurés qui feraient hocher la tête d'approbation même aux chefs de code les plus exigeants.

Distribution de la complexité

Complexité cyclomatique moyenne

8,8

Complexité cyclomatique médiane

4,0

Qualité du code

Indice de maintenabilité

108

Lignes par méthode

3,0

Packages avec le plus de lignes de code

Si vous êtes curieux des packages ayant le plus de lignes de code, vous trouverez les 100 premiers packages ci-dessous. Notez que les plus gros packages concernent les données géographiques et intègrent beaucoup de données dans leur code.

Package	Lignes de code	Fichiers
xnrcms/alipaysdk	2.8M	11.4K
zerossb/laravel-world	2.2M	48.0
tencentcloud/tencentcloud-sdk-php-intl-en	1.9M	19.2K
vccmas/tencentcloud-sdk-php-intl-en	1.6M	15.5K
zohocrm/php-sdk-6.0	1.5M	15.7K
udemy/googleads-php-lib	1.5M	1.1K
volcengine/volcengine-php-sdk	1.3M	3.1K
vavajke/bxcore	1.3M	4.4K
sos-solution/other-framework	1.2M	8.7K
tombeachell/forza-magento	1.2M	4.2K

Que cache-t-on d'autre dans les dépôts PHP ?

Analyser PHP sur Packagist est une chose, mais qu'en est-il de tout ce qui entoure PHP ? En réalité, les projets PHP modernes s'appuient sur une pile technologique diverse.

🔍 Voici ce que j'ai trouvé dans les dépôts :

PHP domine (plus de 707M lignes de code), mais il est loin d'être seul.
JavaScript est le compagnon le plus courant (plus de 216M lignes), prouvant que l'intégration front-end et back-end est essentielle.
JSON & YAML sont omniprésents (plus de 200M lignes combinées), soulignant l'essor des architectures pilotées par la configuration.
CSS & HTML (plus de 167M lignes au total) démontrent la nature full-stack de nombreuses applications PHP.
SQL, XML et Markdown reflètent l'importance des données structurées et de la documentation dans les projets PHP modernes.

💡 Découvertes surprenantes :

TypeScript est en croissance (2,7M lignes) – les projets PHP deviennent-ils plus structurés côté front-end ?
C, Go et Rust apparaissent en petites quantités – un signe d'extensions critiques en performance ?
Même Lua, Perl et Scheme font leur apparition – des intégrations héritées ou des outils de script au sein des projets PHP ?

👉 Le PHP moderne est plus que du PHP. C'est un écosystème qui se mélange avec diverses technologies, rendant les compétences multi-langages de plus en plus précieuses pour les développeurs PHP.

Répartition des lignes de code par langage (top 10)

Et après ?

Maintenant que la majorité du processus est automatisée, il me reste encore quelques nettoyages de code à effectuer, mais je pense qu'il serait utile de réaliser cette analyse au moins deux fois par an pour maintenir une vue actualisée de l'écosystème PHP. Jusqu'à présent, je me suis concentré exclusivement sur Packagist, mais ce n'est pas le seul gestionnaire de packages - l'ajout de nouvelles sources de code fournirait une image plus complète.

J'envisage également d'implémenter des métriques de code plus avancées pour approfondir l'analyse. Les métriques actuelles nous donnent une bonne base, mais il y a toujours plus à apprendre sur la qualité du code et la santé de l'écosystème.

Si vous avez des idées de métriques ou de fonctionnalités supplémentaires qui pourraient améliorer ce tableau de bord, n'hésitez pas à me contacter - vos suggestions pourraient aider à façonner l'orientation future de ce projet !

Yet another static analysis tool. Yes, but better!

2024-04-18T00:00:00+00:00

10 years after starting the development of PHP Metrics, I think it’s time to start something new, more modern… and more ambitious.

AST Metrics

AST Metrics is a tool, written in Go, for static code analysis. It is a performant, simple, language-agnostic tool.

Why Go? First and foremost for performance. Where most code analyzers take several minutes, AST Metrics only takes a few seconds to parse several million lines of code and tens of thousands of commits.

And then for fun: I’ve wanted to learn Go for a long time, and I thought this was a good opportunity.

Why a new tool?

Code analysis involves traversing the source code, transforming it into an abstract syntax tree (AST), and analyzing this tree to extract metrics.

Among the most common metrics are:

code complexity (the number of decision points);
maintainability index;
coupling between classes;
etc.

My vision is to make these metrics readable and understandable to as many people as possible, and to make them accessible to all developers.

I want to produce something that is easy to use and attractive, performant, and easy to install.

Think of AST Metrics as a linter on the architecture of your code, which allows you to detect quality problems before they become problems.

How does it work?

Installation is quite simple. You just need to fetch a binary from Github. No dependencies, no complicated installation, no configuration file to edit.

In the command line, run the following command:

curl -s https://raw.githubusercontent.com/Halleck45/ast-metrics/main/scripts/download.sh|bash

Be careful, as with any command found on the Internet, read the script before running it.

If you prefer a manual installation, everything is explained here.

Then run the following command to analyze, for example, your project /www/myproject:

ast-metrics analyze /www/myproject --non-interactive --report-html=/tmp/report

An HTML report will be generated in the file /tmp/report/index.html, which you can open in your browser.

Note that I used the --non-interactive option for simplicity in this blog post. If you don’t add it, a CLI application will allow you to navigate among the different metrics.

Lint your code

Of course, AST Metrics goes further. You can, for example, ensure that your code does not exceed certain thresholds.

Generate a .ast-metrics.yaml configuration file in your project by running the following command:

ast-metrics init

And edit it to add your thresholds:

sources:
  - /www/myproject

exclude:
  - /vendor/
  - /node_modules/

reports:
  html: ./build/report
  markdown: ./build/report.md

requirements:
  rules:
    fail_on_error: true

    maintainability:
      min: 85

From now on, the analysis will fail if the maintainability of your code is less than 85.

ast-metrics analyze --non-interactive

You can also control cyclomatic complexity, coupling between classes, etc.

For example, to forbid too complex code:

requirements:
  rules:
    fail_on_error: true
    cyclomatic_complexity:
      max: 10

Or to check the coupling between classes:

requirements:
  rules:
    fail_on_error: true
    coupling:
      forbidden:
        - from: "Controller"
          to: "Repository"

Now, if a controller depends on a repository, the analysis will fail (note that these are regular expressions that are used here).

This is very useful, for example, if you want to ensure that your code respects the architecture principles you have defined with your colleagues.

And continuous integration?

AST Metrics is designed to be used in a CI/CD pipeline.

For example, for Github, you just need to add the Github action that is already ready to use for you:

In the file .github/workflows/ast-metrics.yml:

name: AST Metrics
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
        - name: AST Metrics
          uses: halleck45/action-ast-metrics@v1.0.2

And that’s it, with each push, your code will be analyzed, and you will receive a complete report. If you have defined thresholds, the CI will fail if these thresholds are not met.

For example, here is a report generated by the CI in Github:

To go further, do not hesitate to consult the documentation.

And what’s next?

The project is still in its infancy, and experimental. But promising, I think!

The next step is to better support other programming languages, and, in an ideal world, to add trends. There is also a lot of work to be done on error handling, improving the tool…

In the long run, I would like to add two AIs: a generative AI, to give refactoring advice, and a predictive AI, to predict bugs and risky commits.

I would like this project to grow and offer the maximum number of features and services. And for that, I need help!

If you want to help, the best thing to do is to test the tool and talk about it around you. Thank you! And don’t hesitate to tell me what you think, if you find bugs, or even to encourage me by offering me a ☕ coffee. It’s always nice to have feedback, whatever it is.

Encore un outil d'analyse statique. Oui, mais en mieux !

2024-04-18T00:00:00+00:00

10 ans après avoir démarré le développement de PHP Metrics, je crois qu’il est temps de démarrer quelque chose de nouveau, de plus moderne… et de plus ambitieux.

AST Metrics

AST Metrics est un outil, écrit en Go, d’analyse statique de code source. C’est un outil performant, simple, et agnostique du langage de programmation.

Pourquoi en Go ? Avant tout pour la performance. Là où il faut plusieurs minutes pour la majorité des analyseurs de code, il ne faut que quelques secondes à AST Metrics pour parser plusieurs millions de ligne de code et des dizaines de milliers de commits.

Ensuite pour le plaisir : je voulais apprendre le Go depuis longtemps, et j’ai trouvé que c’était une bonne occasion.

Pourquoi un nouvel outil ?

L’analyse de code consiste à parcourir le code source, à le transformer en un arbre de syntaxe abstraite (AST) et à analyser cet arbre pour en extraire des métriques.

Parmi les métriques fréquentes, on trouve :

la complexité du code (le nombre de points de décision) ;
l’indice de maintenabilité ;
le couplage entre les classes ;
etc.

Ma vision consiste à rendre ces métriques lisibles et compréhensibles pour le plus grand nombre, et à les rendre accessibles à tous les développeurs et développeuses.

Je souhaite produire quelque chose de simple à utiliser et d’attrayant, de performant, et de simple à installer.

Voyez AST Metrics comme un linter sur l’architecture de votre code, qui vous permet de détecter les problèmes de qualité avant qu’ils ne deviennent des problèmes.

Comment ça marche ?

L’installation est assez simple. Il s’agit d’aller chercher un binaire sur Github. Aucune dépendance, pas d’installation compliquée, pas de fichier de configuration à éditer.

En ligne de commande, lancez la commande suivante:

curl -s https://raw.githubusercontent.com/Halleck45/ast-metrics/main/scripts/download.sh|bash

Attention comme toute commande trouvée sur Internet, soyez viligant(e) et lisez le script avant de l’exécuter.

Si vous préférez une installation manuelle, tout est expliqué ici.

Ensuite, lancez la commande suivante pour analyser, par exemple, votre projet /www/myproject:

ast-metrics analyze /www/myproject --non-interactive --report-html=/tmp/report

Un rapport HTML sera généré dans le fichier /tmp/report/index.html, que vous pouvez ouvrir dans votre navigateur.

Notez que j’ai utilisé l’option --non-interactive par simplicité dans ce billet de blog. Si vous ne l’ajoutez pas, une application en mode CLI vous permettra de naviguer parmi les différentes métriques.

Linter votre code

Bien sûr, AST Metrics va plus loin. Vous pouvez par exemple vous assurer que votre code ne dépasse pas certains seuils.

Générez un fichier de configuration .ast-metrics.yaml dans votre projet, en lançant la commande suivante:

ast-metrics init

Et éditez-le pour y ajouter vos seuils:

sources:
  - /www/myproject

exclude:
  - /vendor/
  - /node_modules/

reports:
  html: ./build/report
  markdown: ./build/report.md

requirements:
  rules:
    fail_on_error: true

    maintainability:
      min: 85

Désormais, l’analyse échouera si la maintenabilité de votre code est inférieure à 85.

ast-metrics analyze --non-interactive

Vous pouvez également contrôler la complexité cyclomatique, le couplage entre les classes, etc.

Par exemple pour interdire le code trop complexe:

requirements:
  rules:
    fail_on_error: true
    cyclomatic_complexity:
      max: 10

Ou encore pour vérifier le couplage entre les classes:

requirements:
  rules:
    fail_on_error: true
    coupling:
      forbidden:
        - from: "Controller"
          to: "Repository"

Désormais, si un contrôleur dépend d’un repository, l’analyse échouera (notez que ce sont ici des expression régulières qui sont utilisées).

C’est très pratique, par exemple si vous souhaitez vous assurer que votre code respecte les principes d’architecture que vous avez définis avec vos collègues.

Et l’intégration continue ?

AST Metrics est conçu pour être utilisé dans un pipeline CI/CD.

Par exemple, pour Github, il vous suffira d’ajouter la Github action qui est déjà prête à l’emploi pour vous:

Dans le fichier .github/workflows/ast-metrics.yml:

name: AST Metrics
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
        - name: AST Metrics
          uses: halleck45/action-ast-metrics@v1.0.2

Et voilà, à chaque push, votre code sera analysé et vous recevrez un rapport complet. Si vous avez défini des seuils, la CI échouera si ces seuils ne sont pas respectés.

Voici par exemple un rapport généré par la CI dans Github:

Pour aller plus loin, n’hésitez pas à consulter la documentation.

Et la suite ?

Le projet est encore balbutiant, et expérimental. Mais prometteur je trouve !

La suite consiste à mieux supporter d’autres langages de programmation, et, dans un monde idéal, à ajouter des tendances. Il reste également pas mal de boulot sur la gestion des erreurs, améliorer l’outil…

A terme, j’aimerai ajouter deux IA: une IA générative, pour donner des conseils au refactoring, et une IA prédictive, pour prédire les bugs et les commits à risque.

J’aimerai que ce projet grossisse, et puisse offrir le maximum de fonctionnalités et de service. Et pour ça j’ai besoin d’aide !

Si vous avez envie d’aider, le mieux reste de tester l’outil et d’en parler autour de vous. Merci ! Et n’hésitez pas à me dire ce que vous en pensez, si vous trouvez des bugs, ou même à m’encourager en m’offrant un ☕ café. Ca fait toujours plaisir d’avoir du feedback, quel qu’il soit.

Industrialization and Software Quality

2024-01-01T00:00:00+00:00

Un éditeur de texte pour les enfants dyslexiques

2023-02-15T00:00:00+00:00

La dyslexie est une chose complexe et multiple. On parle d’ailleurs en général de dyslexies, au pluriel.

C’est un monde que je ne connaissais pas. Mais, depuis deux ans, ma fille est pressentie dyslexique. Au-delà de la difficulté à faire les devoirs, il y a la difficulté à trouver les bons outils.

On a essayé les lunettes spéciale dyslexie, investi dans une lampe pour dyslexiques… Mais, pour les devoirs, nous sommes longtemps restés sur des choses peu confortables.

Les maîtresses de ma fille sont toutes géniales, et font l’effort d’utiliser LireCouleur, sans doute le seul logiciel pour dyslexique accessible en français. Cependant, elles ont du courage. L’interface est un peu lourde, et il manque quelques fonctionnalités essentielles, comme la reconnaissance d’image, ou le partage de liens. Cela leur prend beaucoup de temps.

C’est pour cela (également pour ma veille personnelle) qu’il y a quelques mois, j’ai commencé CaptainDys.com.

C’est un éditeur en ligne, le plus simple possible, pour rendre la lecture de texte la plus confortable possible. Parmi les fonctionnalités implémentées, on y retrouvera :

la lecture vocale ;
la mise en couleur des phonèmes ;
la reconnaissance vocale ;
la reconnaissance d’images (pour importer les devoirs).

J’aimerais aussi, rapidement, intégrer la possibilité de résumer des textes grâce à OpenAI, que je commence à plutôt bien utiliser au travail.

J’ai choisi d’Open Sourcer cet outil pour permettre à chacun d’en profiter, mais également de contribuer pour l’améliorer.

Il y a déjà eu un accueil très favorable, et des premières contributions très appréciables !

C’est un outil simple, en JavaScript. Si vous avez envie de contribuer, ou ne serait-ce que de le tester ou laisser un mot d’encouragement, 🏕 toute l’aventure se passe sur Github.

Je vous remercie pour votre aide et pour vos partages !

Boostez vos Échanges de Données entre Services : DataBus, RabbitMQ et Protobuf

2022-10-28T00:00:00+00:00

Je vous propose de parler un peu de Bus de données. Un bus de données permet de transférer des données entre plusieurs logiciels. Par exemple, entre une application web et un moteur de traitement en masse de données (Big Data). Ou encore entre deux micro-services.

Nous utilisons RabbitMQ et PHP pour nos bus. Ce n’est pas forcément les technologies les plus adaptées dans votre cas, mais ça reste très pratique à mettre en œuvre et couvre bien nos besoins.

Triplets, et un peu de grammaire

Au quotidien, dans notre architecture CQRS, tout événement métier sur nos sites web déclenche l’émission d’un message RabbitMQ.

Par exemple (en schématisant) voici le code lorsqu’on veut dépublier une offre d’emploi sur l’un de nos sites :

<?php
$event = new JobPostingHasBeenUnublished($jobPosting);
$eventDispatcher->dispatch($event);
// L'information part alors dans RabbitMQ

On a donc un événement métier JobPostingHasBeenUnublished (Une offre d’emploi a été dépubliée). Un événement (du latin evenio), indique que quelque chose s’est passé (il faut impérativement que la chose dont on parle soit déjà réalisée).

On souhaite alors que cet événement métier déclenche des actions, comme l’envoi d’un mail, ou la suppression de l’offre d’emploi dans un moteur de recherche, mais aussi dans notre moteur de recommendation, etc.

Chez nous, chaque événement, s’il veut être ingéré dans RabbitMQ, va implémenter une interface qui l’oblige à se décrire sous la forme d’un triplet Sujet + Verbe + Prédicat.

Par exemple :

# triplet qui représente un événement

Utilisateur 123         career.job_publishing.delete        JobPosting 456

Un triplet est une expression de la forme Sujet + Verbe + Prédicat, mais peut prendre des formes complexes :

<?php

// Un triplet simple
$event = new EventLog('Utilisateur 123', 'career.job_publishing.delete', 'JobPosting 456');

// Un triplet avec un prédicat complexe
class JobPosting implements Predicate 
{
    public function asPredicate(): array; // @implement me
    public function asPredicateidentifier(): string; // @implement me
}

$jobPosting = new JobPosting(456);
$event = new EventLog('Utilisateur 123', 'career.job_publishing.delete', $jobPosting);

En général chaque élément du triplet est un objet qui implémente la bonne interface.

Dès lors, notre moteur va envoyer ce triplet à RabbitMQ.

Un énorme avantage de cette approche, c’est que l’on peut facilement retrouver l’événement qui a déclenché une action, et on peut le documenter très facilement : lorsqu’on génère notre documentation, savoir si un événement part dans le bus de données est très facile.

Standardisation des données via ProtoBuff.

À partir de ce moment, ce triplet va être sérializé en JSON via ProtoBuf, et être émis vers RabbitMQ.

Nous avons fait le choix de fortement rationaliser les noms des messages. Tous se terminent par l’un des suffixes suivants :

*.*.post lorsque l’événement implique une création
*.*.put lorsque l’événement implique une mise à jour
*.*.delete lorsque l’événement implique une suppression
*.*.hit lorsque l’événement implique une visite (comme “voir une page”)

Pour plus de facilités, les schémas protobuf sont partagés entre les différents services et sont stockés dans un dépôt git séparé, récupérables via Composer.

L’émission

RabbitMQ est un passe-plat entre un outil qui émet des informations, et un ou plusieurs outils qui les consomment (consumers). Il existe plusieurs stratégies de consommation, mais ce n’est pas l’objet de ce billet.

En très bref, RabbitMQ permet d’émettre des messages :

vers une queue de messages (queue)
vers un échangeur (exchange)

Une queue est une sorte de base de données temporaire, dans les quelles les consumers vont chercher les messages à lire.

Un échangeur est comme un aiguilleur : à partir de règles de configuration, il va orienter chaque message vers une, ou plusieurs, queues. Il est ainsi en général préférable d’émettre via un échangeur plutôt qu’une queue, car ça offre beaucoup plus d’évolutivité. Un échangeur peut même dupliquer le message, pour l’envoyer dans plusieurs queues à la fois. C’est ce qu’on appelle le Multiplexing.

Tout se passe via du mapping très simple, à coup de détection de motifs dans le nom du message (routing key)

Ici, les messages qui matchent *.*.post sont dirigés vers une queue dédiée au traitement métier, tandis que les messages *.*.hit sont dirigés vers un autre échangeur dédié à l’analytics, qui lui-même se chargera de les diriger aux bonnes queues.

Exploiter le bus de données

Dans ce contexte il devient alors possible de spécialiser certaines briques de consommation pour les faire traiter des sujets bien précis. C’est ce qu’on appelle des micro-services (ici on ne parle pas d’API, mais bel et bien de services. Parfois ces services peuvent disposer d’une API, mais ce n’est pas une obligation).

On peut par exemple imaginer un service dédié à l’analytics, un autre à la synchronisation des données avec un service externe, un autre qui va faire de la consolidation, un autre qui va hydrater une DataPipeline en vue de l’exploiter en Big data, etc.

En multiplexant le message, d’échangeur en échangeur, on permet à chaque donnée d’être traitée autant de fois que nécessaire dans le système. Chaque service de consommation a une seule responsabilité simple, limitant sa complexité (la complexité ne porte plus alors sur le code, mais sur la compréhension des flux).

Choisir comment structurer la donnée

Dans un échange de données, il y a en gros 2 manières de voir la donnée (et donc de construire le message RabbitMQ) :

ou bien elle est très légère. Elle ne contient que les infos minimales (un type et identifiant).
ou bien elle est suffisante. Elle contient en elle-même les infos nécessaires à son traitement.

Chaque solution a ses inconvénients.

Si le message RabbitMQ est léger, il consomme moins de RAM. Mais chaque service de consommation doit avoir accès à une source de données complète (une base ou une API), ce qui renforce la dépendance entre les services et ralentit le traitement.

Si le message RabbitMQ est suffisant, il consomme beaucoup de RAM. Il faut être vigilant à ne pas le faire grossir inutilement, sous peine de saturer les serveurs. Par contre, le service de consommation n’a rien à faire de son côté, il lui suffit de déserialiser la donnée pour l’exploiter facilement.

J’avoue que je préfère avoir des données suffisantes. C’est, de mon expérience, de très loin plus simple et performant. C’est pour ça que j’aime beaucoup ProtoBuf, vu qu’il me permet de sérializer / déserializer des données complètes très facilement, sans me soucier de la technologie utilisée (PHP, NodeJS, Go…).

De mon point de vue, devoir aller chercher des informations complémentaires sur une donnée entraîne nécessairement des “micro-services spaghettis”, qui s’appellent tous les uns les autres et dans tous les sens. Mais il doit être toutefois possible d’y arriver de manière élégante.

Quelques exemples de ce qu’il est possible de faire

Les possibilités sont infinies.

En s’appuyant sur des événements métiers, on peut avoir une vue en temps réel de ce qui se passe dans une application. Chaque événement étant daté, il suffit de les lire dans l’ordre pour savoir ce qu’il se passe. Voici par exemple une capture d’un écran de suivi d’activité de production :

On s’en sert aussi pour hydrater un moteur de recommendations, en temps réel. Le consumer RabbitMQ devient alors la première brique de notre DataPipeline.

Encore un dernier exemple : on s’en sert pour synchroniser des données entre notre système d’information et celui de certains clients / fournisseurs, ce qui permet d’avoir en temps réel des informations à jour partout.

Limites

Ce paradigme a toutefois quelques limites.

D’abord, en termes de cohérence de données. S’appuyer sur RabbitMQ est facile, mais il existe d’autres types de bus plus “solides”. Par exemple, RabbitMQ ne garantie pas que les événements seront reçus dans l’ordre d’émission. Le message RabbitMQ d’une suppression d’utilisateur peut être reçu avant même de recevoir celui de création !

Le risque est minime dans un contexte à faible charge, mais sur de très gros volumes d’événements le risque est là.

Ensuite, en termes de code même : il nécessite de bien cibler ce qu’il est pertinent d’émettre dans le Bus. On est vite tentés de tout “bourrer” dans le bus de données, au cas où on en aurait besoin un jour. Il ne faut pas oublier que toute donnée utilise de la RAM et du CPU, qu’il convient d’utiliser avec parcimonie.

En bref

Une fois cela dit, c’est un pattern de conception extrêmement pratique et simple à mettre en oeuvre.

Il facilite la scalabilité, en rendant les traitements asynchrones simples et systématiques, et il rend possible l’isolation des responsabilités au sein des micro-services.

Ce n’est pas une solution miracle, mais pour l’avoir mis en place sur plusieurs gros projets, dans différents contextes pour lesquels il me semblait adapté, il rend bien service !

ProtoBuf in PHP for ultra-efficient and agnostic serialization

2022-07-13T00:00:00+00:00

Today I want to talk about a tool that I now use almost every day: Protocol Buffers (or ProtoBuf for short).

Contrary to popular belief, it is perfectly possible (and efficient!) to use ProtoBuf in PHP.

❔ What is ProtoBuf?

ProtoBuf is:

A standard for exchanging data (to structure and serialize it);
A code generator (Java, PHP, Go…) to process this data

My use case is quite basic: I need to transmit information between several microservices, via a RabbitMQ bus. So I use ProtoBuf for that.

We will exchange data between a PHP application and a Go application. Let’s see how it works! 🎉

📄 The standard

If you have looked at the official website, you see the word “Google” everywhere. Don’t panic, it’s still very interoperable. The coupling to Google is quite non-existent, and the technology is used by many different actors. Google is mainly at the initiative of the project.

The idea behind all this is to describe data via .proto files, which are standardized and agnostic. From these files, any data will be serialized and deserialized, in binary or JSON.

For a basic example, we will describe a simple message, of type blog post:

# file src/BlogPost.proto

syntax = "proto3";
message BlogPost {
  string uuid = 1;
  string title = 2;
  string content = 3;
}

This is a simple message, which contains a title and content. Each attribute is associated with a position (1, 2, 3, …), which should never change over time. It is on this that serialization and deserialization are based.

Let’s continue with our BlogPost, in order to add tags and an author (in a rather simplistic way, but the idea is there):

# file src/User.proto

syntax = "proto3";
message User {
    string uuid = 1;
    string name = 2;
    optional string avatar = 3;
}

# file src/Tag.proto

syntax = "proto3";
message Tag {
    string label = 1;
}

Let’s modify the BlogPost to connect everything. The file now looks like:

syntax = "proto3";

import "src/User.proto";
import "src/Tag.proto";

message BlogPost {
  string uuid = 1;
  string title = 2;
  string content = 3;
  User author = 4;
  repeated Tag tags = 5;
}

We can have as many tags as we want, via the repeated instruction.

We will finally add a publication date to our BlogPost. To do this, we will need to import the timestamp type, which is native, but must be imported if you want to use it. There are quite a few types, I let you discover them in the documentation

# ...
import "google/protobuf/timestamp.proto";

message BlogPost {
  # ...
  google.protobuf.Timestamp published = 6;
}

To go all the way and discover one last rather useful aspect, know that it is also possible to use enums:

# ...

message BlogPost {
  # ...
  enum PublicationStatus {
    DRAFT = 0;
    PUBLISHED = 1;
    ARCHIVED = 2;
  }
  PublicationStatus status = 7;
}

If you want to test, and don’t have the courage to copy-paste everything, here is the complete code for the BlogPost:

syntax = "proto3";

import "src/User.proto";
import "src/Tag.proto";
import "google/protobuf/timestamp.proto";

message BlogPost {
  string uuid = 1;
  string title = 2;
  string content = 3;
  User author = 4;
  repeated Tag tags = 5;
  google.protobuf.Timestamp published = 6;
  enum PublicationStatus {
    DRAFT = 0;
    PUBLISHED = 1;
    ARCHIVED = 2;
  }
  PublicationStatus status = 7;
}

It is possible to define Namespaces for classes generated by ProtoBuf. It is even required for some languages (like Go).

We will add metadata to each of our .proto files, by adding:

option go_package = "blog/demo";
option php_namespace = "Blog\\Demo";
option php_metadata_namespace = "Blog\\Demo\\Metadata";

💡 Tips

As your project progresses, you will need to evolve your messages. If you are concerned about breaking backward compatibility (e.g. by making an attribute obsolete), a good practice is to use a version attribute.
message ... {
 optional int32 version = 999;
}
Store the current version of your data there, you will then be able to manage it according to its version without breaking everything.

🧬 Using ProtoBuf and Generating Code

We’ve described a whole bunch of great things, but using them is even better! It’s time to install ProtoBuf.

Simply download the latest release on the official Github repository (look for the protoc-xxx file that corresponds to your distribution).

For example, in my case, I download version 21.2 for Ubuntu:

curl https://github.com/protocolbuffers/protobuf/releases/download/v21.2/protoc-21.2-linux-x86_64.zip \
  -o protoc-21.2-linux-x86_64.zip
unzip -qq protoc-21.2-linux-x86_64.zip -d protoc
chmod +x protoc/bin/protoc

I now have a protoc folder in my current directory, with the bin/protoc binary that we will use for everything else.

We will now do something quite magical: we will generate PHP code to serialize and deserialize BlogPost objects.

Still in bash, run:

mkdir -p generated # the "generated" folder will contain the generated code
protoc/bin/protoc --php_out=./generated  --proto_path=src $(find src -name '*.proto')

You will find a set of ready-to-use PHP classes in the generated folder.

Let’s create a small script to use them. The first step will be to install ProtoBuf for PHP:

composer require google/protobuf

Then let’s create a script that will generate the PHP code:

<?php

require_once __DIR__ . '/vendor/autoload.php';

$blogSpot = new \Blog\Demo\BlogPost();
$blogSpot
    ->setTitle('My great post')
    ->setContent('Lorem ipsum')
    ->setAuthor(
        (new \Blog\Demo\User())
        ->setName('Jean-François')
    )
    ->setPublished(new Google\Protobuf\Timestamp());

// the content serialized in JSON:
$json = $blogSpot->serializeToJsonString();

// the content serialized in binary
$binary = $blogSpot->serializeToString();

// We put the binary in a temporary file, which will be read by Go
file_put_contents('blogpost.bin', $json);

The JSON looks like:

{"title":"My great post","content":"Lorem ipsum","author":{"name":"Jean-François"},"published":"1970-01-01T00:00:00Z"}

And there you go! Now we will deserialize our post, but in Go this time.

🚀 Using ProtoBuf in Go

Let’s install the dependencies:

go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go mod init Version1
go get github.com/golang/protobuf
go get github.com/golang/protobuf/proto

Let’s use ProtoBuf to automatically generate the Go code:

protoc/bin/protoc --go_out=vendor $(find src -name '*.proto')

Here is a very simple code to read and parse the blogspot.bin file that we generated in PHP:

package main
import "io/ioutil"
import "github.com/golang/protobuf/proto"
import "blog/demo"
import "log"

func main() {

    in, err := ioutil.ReadFile("blogpost.bin")
    if err != nil {
        log.Fatalf("Read File Error: %s ", err.Error())
    }
    blogpost := &demo.BlogPost{}
    err2 := proto.Unmarshal(in, blogpost)
    if err2 != nil {
        log.Fatalf("DeSerialization error: %s", err.Error())
    }

    log.Printf("BlogPost: %s", blogpost.Title)
    log.Printf("Author is: %s", blogpost.Author.Name)
}

Let’s run it:

go run demo.go

# BlogPost: My great post
# Author is: Jean-François

Our Go program successfully read the file serialized by PHP, and was able to extract the information from it, without any problems.

🔥 Conclusion

In both cases we were able to use typed objects or structures. If the data is deserialized, it means it’s valid!

The advantages of ProtoBuf are truly numerous:

The data is standardized. You manipulate typed structures. There is no need to add validators. You can use complex types. Serialization/deserialization is efficient.

However, from my experience, there is one caveat: the documentation could be greatly simplified to make it more accessible for beginners.

I hope I’ve made you want to try this tool. Feel free to share your experience on the subject.

💡 Additional Resources

You can also discover a real production use case of ProtoBuf in a RabbitMQ data bus

ProtoBuf en PHP, pour une serialisation ultra-performante et agnostique

2022-07-13T00:00:00+00:00

Aujourd’hui j’ai envie de vous parler d’un outil que j’utilise désormais presque tous les jours : Protocol Buffers (ou ProtoBuf pour les intimes).

Contrairement à une idée reçue, il est tout à fait possible (et efficace !) d’utiliser ProtoBuf en PHP.

❔ Qu’est-ce que ProtoBuf ?

ProtoBuf, c’est :

un standard pour échanger des données (pour les structurer et les sérialiser) ;
un générateur de code (Java, PHP, Go…) pour traiter ces données.

Mon cas d’usage est assez basique : je dois faire transiter de l’information entre plusieurs microservices, via un bus RabbitMQ. Je me sert donc de ProtoBuf pour ça.

Nous allons échanger de la donnée entre une application PHP et une application Go 🎉 . Voyons comment ça marche !

📄 Le standard

Si vous avez regardé le site officiel, vous voyez le mot “Google” un peu partout. Pas de panique, ça reste très intéropérable. Le couplage à Google est assez inexistant, et la technologie est utilisée par beaucoup d’acteurs différents. Google est surtout à l’initiative du projet.

L’idée derrière tout ça est de décrire une donnée via des fichiers .proto, standardisés et agnostiques. À partir de ces fichiers, toute donnée sera sérialisée et désérialisée, en binaire ou en JSON.

Pour un exemple basique, nous allons décrire un message simple, de type billet de blog :

# fichier src/BlogPost.proto

syntax = "proto3";
message BlogPost {
  string uuid = 1;
  string title = 2;
  string content = 3;
}

C’est un message simple, qui contient un titre et un contenu. Chaque attribut est associé à une position (1, 2, 3, …), qui ne doit jamais changer dans le temps. C’est sur elle que s’appuie la sérialisation et déserialisation.

Continuons avec notre BlogPost, afin de lui ajouter des tags et un auteur (de manière assez simpliste, mais l’idée est là) :

# fichier src/User.proto

syntax = "proto3";
message User {
    string uuid = 1;
    string name = 2;
    optional string avatar = 3;
}

# fichier src/Tag.proto

syntax = "proto3";
message Tag {
    string label = 1;
}

Modifions le BlogPost pour relier le tout. Le fichier ressemble désormais à :

syntax = "proto3";

import "src/User.proto";
import "src/Tag.proto";

message BlogPost {
  string uuid = 1;
  string title = 2;
  string content = 3;
  User author = 4;
  repeated Tag tags = 5;
}

Nous pouvons avoir autant de tags que nous le souhaitons, via l’instruction repeated.

Nous allons enfin ajouter une date de publication à notre BlogPost. Pour cela, nous allons devoir importer le type timestamp, qui est natif, mais à importer si vous souhaitez l’utiliser. Il existe pas mal de types, je vous laisse les découvrir dans la documentation.

# ...
import "google/protobuf/timestamp.proto";

message BlogPost {
  # ...
  google.protobuf.Timestamp published = 6;
}

Pour aller jusqu’au bout et découvrir un dernier aspect assez utile, sachez qu’il est possible également d’utiliser des enums :

# ...

message BlogPost {
  # ...
  enum PublicationStatus {
    DRAFT = 0;
    PUBLISHED = 1;
    ARCHIVED = 2;
  }
  PublicationStatus status = 7;
}

Si vous avez envie de tester, et pas le courage de tout copier-coller, voici le code complet pour le BlogPost :

syntax = "proto3";

import "src/User.proto";
import "src/Tag.proto";
import "google/protobuf/timestamp.proto";

# Il reste une étape ici pour les namespaces

message BlogPost {
  string uuid = 1;
  string title = 2;
  string content = 3;
  User author = 4;
  repeated Tag tags = 5;
  google.protobuf.Timestamp published = 6;
  enum PublicationStatus {
    DRAFT = 0;
    PUBLISHED = 1;
    ARCHIVED = 2;
  }
  PublicationStatus status = 7;
}

Il est possible de définir des Namespaces pour les classes générées par ProtoBuf. C’est même requis pour certains langages (comme le Go).

Nous allons ajouter des metadonnées à chacun de nos fichiers .proto, en y ajoutant :

option go_package = "blog/demo";
option php_namespace = "Blog\\Demo";
option php_metadata_namespace = "Blog\\Demo\\Metadata";

💡 Astuce

Au-fur-et-à-mesure de la vie du projet, vous allez faire évoluer vos messages. Si vous craignez de briser la rétrocompatibilité (par exemple en rendant obsolète un attribut), une bonne pratique consiste à utiliser un attribut de version.
message ... {
 optional int32 version = 999;
}
Stockez-y la version actuelle de votre donnée, vous pourrez alors gérer cette dernière en fonction de sa version sans tout casser.

🧬 Utiliser ProtoBuf et générer du code

On a décrit tout plein de belles choses, c’est bien. Mais les utiliser c’est mieux ! Il est temps d’installer ProtoBuf.

Téléchargez simplement la dernière release sur le dépôt Github officiel (cherchez le fichier protoc-xxxqui correspond à votre distribution).

Par exemple dans mon cas, je télécharge la version 21.2 pour Ubuntu :

curl https://github.com/protocolbuffers/protobuf/releases/download/v21.2/protoc-21.2-linux-x86_64.zip \
  -o protoc-21.2-linux-x86_64.zip
unzip -qq protoc-21.2-linux-x86_64.zip -d protoc
chmod +x protoc/bin/protoc

J’ai désormais un dossier protoc dans mon dossier courant, avec le binaire bin/protoc qui nous servira pour tout le reste.

Nous allons maintenant faire quelque chose d’assez magique : nous allons générer du code PHP pour sérialiser et désérialiser des BlogPost.

Toujours en bash, lancez :

mkdir -p generated # le dossier "generated" va accueillir le code généré
protoc/bin/protoc --php_out=./generated  --proto_path=src $(find src -name '*.proto')

Vous trouverez dans le dossier generated un ensemble de classes PHP prêtes à l’emploi.

Créons un petit script pour les utiliser. La première étape sera d’installer ProtoBuf pour PHP:

composer require google/protobuf

Puis créons un script qui va générer le code PHP :

<?php

require_once __DIR__ . '/vendor/autoload.php';

$blogSpot = new \Blog\Demo\BlogPost();
$blogSpot
    ->setTitle('Mon super billet')
    ->setContent('Lorem ipsum')
    ->setAuthor(
        (new \Blog\Demo\User())
        ->setName('Jean-François')
    )
    ->setPublished(new Google\Protobuf\Timestamp());

// le contenu sérialisé en JSON:
$json = $blogSpot->serializeToJsonString();

// le contenu sérialisé en binaire
$binary = $blogSpot->serializeToString();

// Nous déposons le binaire dans un fichier temporaire, qui sera lu par Go
file_put_contents('blogpost.bin', $json);

le JSON ressemble à :

{"title":"Mon super billet","content":"Lorem ipsum","author":{"name":"Jean-François"},"published":"1970-01-01T00:00:00Z"}

Et voilà ! Nous allons maintenant désérialiser notre billet, mais en Go cette fois.

Installons les dépendances :

go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go mod init Version1
go get github.com/golang/protobuf
go get github.com/golang/protobuf/proto

Utilisons ProtoBuf pour générer le code Go automatiquement :

protoc/bin/protoc --go_out=vendor $(find src -name '*.proto')

Voici un code très simple pour lire et parser le fichier blogspot.bin que nous avons généré en PHP:

package main
import "io/ioutil"
import "github.com/golang/protobuf/proto"
import "blog/demo"
import "log"

func main() {

    in, err := ioutil.ReadFile("blogpost.bin")
    if err != nil {
        log.Fatalf("Read File Error: %s ", err.Error())
    }
    blogpost := &demo.BlogPost{}
    err2 := proto.Unmarshal(in, blogpost)
    if err2 != nil {
        log.Fatalf("DeSerialization error: %s", err.Error())
    }

    log.Printf("BlogPost: %s", blogpost.Title)
    log.Printf("Author is: %s", blogpost.Author.Name)
}

Lançons le :

go run demo.go

# BlogPost: Mon super billet
# Author is: Jean-François

Notre programme en Go a bien lu le fichier serialisé par PHP, et a pu en extraire les informations, sans aucun problème.

🔥 Conclusion

Et voilà, nous avons fait passer de la donnée, structurée, de PHP vers Go. Dans les deux cas nous avons pu utiliser des objets ou des structures typées. Si la donnée est déserialisée, c’est qu’elle est valide !

Les avantages de ProtoBuf sont vraiment nombreux :

les données sont standardisées
on manipule des structures typées
il devient inutile d’ajouter des validateurs
on peut utiliser des types complexes
la sérialisation / déserialisation est performante

Avec toutefois, de mon expérience, une réserve : la documentation mériterait d’être largement simplifiée, pour la rendre plus abordable pour les débutants.

En espérant vous avoir donné envie de tester cet outil, n’hésitez pas à faire part de votre expérience sur le sujet.

💡 Pour aller plus loin

vous pouvez également découvrir un cas d’usage réel de production de ProtoBuf, dans le cadre d’un bus de données RabbitMQ

Un environnement complet de tests avec Docker - jour 2 (tests d'IHM)

2015-10-19T00:00:00+00:00

Ce billet est le second d’une série sur la création d’un environnement de test pour des projets web. Aujourd’hui nous parlerons d’IHM, c’est-à-dire comment tester que l’interface (visuelle) de mon site n’est pas cassée sous tel ou tel navigateur.

Je rappelle que l’objectif ce ces billets / outils est de pouvoir dire “Vous n’avez pas de raison valable de ne pas tester” :)

Introduction

La question de tester une interface graphique est complexe pour plusieurs raisons :

manque de maturité des outils
complexité de comparer l’incomparable (un site avec des publicités change à chaque rafraîchissement, ce n’est pas pour autant qu’il est cassé)
complexité de gérer les changements de contenus (une page d’accueil avec des articles change tout le temps)
gérer les faux-positifs (liés, par exemple, au lissage des polices qui peuvent être différents pour un même navigateur)

Mon retour sur quelques outils de test de régression

Au fil du temps, j’ai testé pas mal d’outils de test de régression. Tous s’appuient sur des comparaisons de captures d’écrans (du site en entier, ou de blocs (divs, etc.) du site).

Navigateurs headless :

PhantomCss : performant, mais souvent insuffisant car basé sur un navigateur virtuel. Le rendu, même sur des sites moyennement complexes, est souvent insatisfaisant et génère de nombreux faux-positifs)
BackstopJs : idem

Vrais navigateurs (qui plus est ces outils ont des connecteurs vers des solutions de virtualisation externe, de type SauceLabs ou BrowserStack) :

Wraith : développé par le BBC, efficace mais à l’usage la sélection de blocs est assez aléatoire (voire buggée). Cet outil génère une gallerie des screenshots très très pratique. Je n’ai jamais réussi à faire fonctionner wraith-selenium correctement.
Huxley : développé (mais abandonné) par Facebook, complexe à utiliser (on passe son temps à patcher le code source)
Gemini : simple et efficace, c’est lui qui a ma préférence aujourd’hui. Permet, comme Wraith, de générer un rapport HTML

Sass :

ghostinspector.com/ : très joli, mais tout se fait au clickdrome avec une extension Chrome, je n’ai pas trouvé de moyen de le piloter automatiquement ou d’écrire ses propres scripts.
percy.io : j’aimerai bien tester, mais je n’ai pas d’invitation. Pour l’instant seul Firefox est supporté

Pour les curieux, ceux que je n’ai fait que survoler :

VisualReview
Gatling (non, pas LE gatling qu’on connaît tous)
ScreenBeacon
Shoov
WebDriverCss
BrowserShots
Bref, il existe pas mal d’outils différents, et ça bouge bien en ce moment.

Installation

Nous allons donc utiliser Gemini. Voici un exemple de rapport HTML que l’on souhaite obtenir :

Si le site a subi des régression, les écarts seront mis en surbrillance comme suit:

Là encore, j’ai préparé une image Docker pour vous:

docker pull qualiboo/testing-gemini

On va s’appuyer sur le fichier docker-compose.yml que l’on a créé la dernière fois.

gemini:
  image: roukmoute/testing-gemini
  links:
    - hub
    - firefox
    - chrome
  volumes:
    - ./gemini:/var/work
hub:
  image: qualiboo/testing-hub
  ports:
    - 4444:4444
firefox:
  image: qualiboo/testing-node-firefox
  ports:
    - 5900
  links:
    - hub
chrome:
  image: qualiboo/testing-node-chrome
  ports:
    - 5900
  links:
    - hub

Vous constatez que l’on utilise Selenium, avec des noeuds Chrome et Firefox.

Vérifions l’installation. La commande suivante doit afficher la version de gemini:

docker-compose run gemini version

Premiers tests

Nous allons procéder en deux temps :

faire les captures d’écrans qui serviront de référence pour les tests (gemini capture) ;
comparer de nouvelles capture à ce référentiel pour voir s’il y a des régression (gemini test).

Pour cela, créez un dossier ./gemini/suite et créez-y le fichier premier-test.js avec le contenu suivant :

var gemini = require('gemini');
gemini.suite('homepage', function(suite) {
    suite
        .setUrl('/')
        .setCaptureElements('#nav-menu');
        .capture('menu');
});

Le code (JavaScript) est assez simple : on capture la div dont l’id est #nav-menu depuis la racine du site.

Maintenant, créez le fichier ./gemini/.gemini.yml qui va permettre de configurer Gemini :

rootUrl: http://qualiboo.com
gridUrl: http://hub:4444/wd/hub
browsers:
  chrome:
    desiredCapabilities:
      browserName: chrome
  firefox:
    desiredCapabilities:
      browserName: firefox

Nous indiquons ici à Gemini l’URL de base du site, les navigateurs souhaités, et comment se connecter à Selenium Grid..

Lancez la capture du référentiel (ça prend quelques secondes):

docker-compose run gemini capture

Vérifiez bien à chaque fois que vous faites une capture que les images générées (dossier ./gemini/gemini/screens) correspondent à vos attentes. Elle serviront de référentiel pour les tests. Voilà, les tests peuvent être lancés :

docker-compose run gemini test

Après quelques secondes/minutes, vous voilà avec un “beau” rapport HTML dans ./gemini/gemini-report/index.html. Il ne reste plus qu’à l’ouvrir dans votre navigateur préferé…

Tester le responsive design

Avant toute chose, il faut savoir que le monde de tests d’IHM n’est pas parfait. La version du ChromeDriver actuelle pour Linux (2.20) ne permet pas de capturer un bloc qui est plus grand que le viewport du navigateur. Si vous voulez capturer toute la page (le body), il faudra passer par Firefox.

Il est simple avec Gemini de forcer certains tests à être exécutés uniquement dans Firefox ou Chrome. Dans le fichier ./gemini/.gemini.yml ajoutez le contenu suivant:

(...)
sets:
  firefox:
    files:
     - suite/firefox-only
    browsers:
     - firefox
  chrome:
    files:
     - suite/chrome-only
    browsers:
     - chrome

Tous les tests qui seront placés dans le dosser ./gemini/suite/firefox-only seront désormais lancés uniquement par firefox (et même chose pour ./gemini/suite/chrome-only).

Comme nous souhaitons capturer la page entière (le body), plaçons notre fichier de test (./gemini/suite/premier-test.yml) dans le dossier firefox-only

Nous allons tester notre site sous des résolutions différentes ; pour cela, modifiez le fichier premier-test.yml.

Nous allons changer la résolution de l’écran avant chaque test, et cette fois nous capturons donc le body :

var gemini = require('gemini');
gemini.suite('homepage', function(suite) {
  suite
    .setUrl('/')
    .setCaptureElements('body')
    .capture('homepage', function (actions) {
        actions.setWindowSize(1200, 1024).wait(1000);
    })
    .capture('homepage tablet', function (actions) {
        actions.setWindowSize(768, 1024).wait(1000);
    })
    .capture('homepage mobile', function (actions) {
        actions.setWindowSize(320, 568).wait(1000)
    });
});

N’oubliez pas de mettre à jour le référentiel de screenshots :

docker-compose run gemini capture

A vous désormais de lancer les tests à votre guise (par exemple à chaque Push sur votre dépôt, à l’aide de Jenkins).

Aller plus loin et faire abstraction du contenu dynamique

Je l’ai évoqué, un problème récurrent des tests de régression d’IHM concerne le contenu dynamique (publicités, actualités…). Il faut trouver un moyen de faire abstraction de ce type de contenu.

Le seul moyen simple que j’ai trouvé consiste à remplacer ce contenu par du “Lorem ipsum”. Il faut alors, avant chaque test, exécuter un script JavaScript pour ce faire:

suite
    .setUrl('/')
    .setCaptureElements('body')
    .before(function(actions, find) {
        actions.executeJS(function(window) {
            // replacing images
            $('img.my-class').attr('src', '');
            
            // replacing some texts
            $('p.another-class, .title, (etc.)').html('Lorem ipsum dolor sit amet');
    
            // advertising
            $('.pub').html('PUBLICITE');
            
            // etc.
        })
    .capture(...)

Dès lors, toutes les images et contenus dynamiques sont remplacés. Il est assez simple de factoriser ce code dans un fichier à part pour le réutiliser partout.

Le contenu du site a changé, donc, oui, nos tests sont alors incomplets et éloignés de la réalité. Mais si on ne le fait pas, le risque est que ces tests ne soient jamais pertinents car fondés uniquement sur de faux-positifs. La suppression des publicités est un compromis pour être pragmatique.

Conclusion

Vous l’avez vu, vous avez là un moyen simple de tester l’IHM de votre site sous différentes résolutions, à l’aide de Docker. Si vous avez un feedback, n’hésitez pas à laisser un commentaire ; et si ce billet vous plaît, n’hésitez pas à le partager :)

Un environnement complet de tests avec Docker - jour 1 (Behat)

2015-10-12T00:00:00+00:00

Ce billet est le premier d’une série sur la création d’un environnement de test pour des projets web. A la fin de cette série, vous disposerez d’un environnement Docker capable de lancer facilement :

des tests fonctionnels avec Behat, Selenium Grid, Chrome, Firefox et PhantomJs
des tests de non régression d’interface utilisateur
des tests de performance

Aujourd’hui nous allons démarrer avec les tests Behat, exécutés dans un navigateur grâce à Selenium Grid et Docker.

Docker

Je ne vais pas refaire un billet sur ce que d’autres ont fait avec bien plus de clarté que je ne saurais faire. Sachez juste que Docker va vous permettre de “virtualiser” une partie de votre système, permettant donc d’installer plein d’outils sans pourrir votre machine, et sans risque de conflits de versions.

Pour tous les billets, je suppose que Docker et Docker-Compose sont installés sur votre machine. Si ce n’est pas le cas, il est encore temps :

Et pour Docker-Compose :

Linux:

curl -L https://github.com/docker/compose/releases/download/1.4.2/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

OSX:

Déjà installé avec Docker (au passage, je ne comprendrais jamais pourquoi on n'a pas la même processus d'installation sur Max oO)

Windows:

curl -L https://github.com/docker/compose/releases/download/1.4.2/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

Behat

En deux mots, Behat est un outil de test. Il permet de convertir des phrases (langues naturelles) en code source. Il est du coup possible d’associer ces phrases à des actions utilisateurs dans un navigateur (Chrome, Firefox…) ou un émulateur de navigateur (on parle de “navigateur headless”).

Pour vous simplifier la vie, j’ai préparé des images “prêtes à l’emploi”. Commencez par télécharger l’image principale (c’est l’heure du premier café):

docker pull qualiboo/testing-behat

Voilà, vous voilà avec un Behat prêt à l’emploi. Créez un dossier local behat (et un sous-dossier build pour les logs) pour stocker les tests Behat, puis demandons à Behat d’y créer l’arborescence de base, en montant un volume :

mkdir -p behat/build
docker run -v $(pwd)/behat:/var/work qualiboo/testing-behat --init

Vous voilà presque prêt(e) à démarrer.

Behat interagit avec des Fonctionnalités, décrites dans des fichiers *.features. Il est temps d’écrire notre premier test ; créez le fichier ./behat/premier-pas.feature:

Feature: My first feature
  
  Scenario: Visitor can follow link to get information on blogpost
    Given I am on "http://blog.lepine.pro"
    When I follow "Un outil pour améliorer la qualité d'un projet web"
    Then I should see "qualiboo"
    And the url should match "/outil-mesure-qualite-projet-web/"

Si vous lancez Behat tel quel, Behat ne saura pas quoi faire de ces phrases. Nous avons besoin d’importer Mink, une extension bien pratique qui permet d’utiliser des expressions liées à la navigation web. Ouvrez le fichier ./behat/bootstrap/FeatureContext.php, et ajoutez-y le code suivant:

public function __construct(array $parameters)
{
    $this->useContext('mink', new \Behat\MinkExtension\Context\MinkContext($parameters));
}

Nous venons de dire à Behat que nous souhaitons utiliser l’extension Mink.

Lançons les tests:

docker run --rm -t -v $(pwd)/behat:/var/work qualiboo/testing-behat

Tout est vert ; les tests sont donc passés (si vous ne me faites pas confiance essayez de modifier le fichier feature ;) )

En quelques minutes, nous disposons donc d’un robot capable de vérifier rapidement et à l’infini que mon blog est en ligne, que je peux suivre un lien et que suivre ce lien me fait changer de page. Pas mal !

N’oubliez pas que vous pouvez connaître la liste des expressions prêtes à l’emploi grâce à la commande suivante :

docker run --rm -t -v $(pwd)/behat:/var/work qualiboo/testing-behat -dl

Pour aller plus loin sur la manière d’écrire des fonctionnalités ou sur les bonnes pratiques Behat, je vous invite à lire cet ebook Open Source que j’ai écrit il y a un moment sur le sujet.

Un “vrai” navigateur

Bon, on a nos tests, mais en réalité jusqu’ici nous utilisons un navigateur “virtuel”. Ce navigateur est incapable d’interpréter du javascript. Il faut aller plus loin.

Nous avons besoin maintenant de lancer nos tests dans un vrai navigateur. Nous pourrions utiliser le nôtre, mais n’oubliez pas que désormais on dispose de Docker, ce qui est un énorme avantage : grâce à Docker on peut fixer une version, avoir un navigateur qui n’est pas pollué par 20 extensions qui faussent les résultats des tests (AdBblock & Co)…

Nous allons utiliser Selenium, qui permet de piloter des navigateurs de manière très efficace, plus spécifiquement Selenium Grid, qui permet en plus de gérer une grille de navigateurs (dans des versions et résolutions différentes).

Pour simplifier les choses, là encore je vous ai préparé des images Docker. Nous allons utiliser Docker-Compose pour les télécharger et les relier entre-elles.

Il vous suffit de créer un fichier docker-compose.yml pour les utiliser :

behat:
  image: qualiboo/testing-behat
  volumes:
    - ./behat:/var/work
  links:
      - hub
  environment:
    website: http://blog.lepine.pro
hub:
  image: qualiboo/testing-hub
  ports:
    - 4444:4444
firefox:
  image: qualiboo/testing-node-firefox
  ports:
    - 5900
  links:
    - hub
  environment:
    REMOTE_HOST_PARAM: "-maxSession 3 -browser browserName=firefox,maxInstances=3"
chrome:
  image: qualiboo/testing-node-chrome
  ports:
    - 5900
  links:
    - hub

C’est ce fichier que nous allons enrichir au fil des billets, pour obtenir un environnement de test complet.

Grâce à ce fichier, Docker Compose va télécharger les images:

“qualiboo/testing-behat”, qui permet de lancer Behat
“qualiboo/testing-hub”, qui contient Selenium Grid
“qualiboo/testing-node-firefox”, qui contient Firefox
“qualiboo/testing-node-chrome”, qui contient Chrome

Lançons Docker Compose (c’est l’heure du second café) :

docker-compose up -d

Et là, la magie opère. Commencez par tagger la fonctionnalité avec @javascript pour indiquer à Behat que nous voulons utiliser un vrai navigateur :

@javascript
Feature: My first feature

Les images Docker que vous venez d’installer sont pré-configurées. Vous pouvez désormais choisir quel navigateur utiliser simplement en utilisant l’option --profile=<navigateur.

Par exemple:

docker-compose run behat --profile=firefox

Notez que vous avez quatre navigateur à votre disposition:

Goutte (aucun paramètre)
PhantomJs (--profile=phantomjs)
Chrome (--profile=chrome)
Firefox (--profile=firefox)

Notez également que désormais Behat a été lancé par Docker Compose (commande docker-compose) et non simplement Docker.

Dernière chose: vous pouvez superviser vos noeuds Selenium à l’adresse http://localhost:4444/grid/console.

Ah au fait : si vous voulez plus de noeuds Selenium (par exemple, disposer de plusieurs Firefox pour paralléliser les tests), n’hésitez pas à utiliser les capacités de scaling de docker. Par exemple, pour avoir 5 firefox:

docker-compose scale firefox=5

Voilà, c’est tout pour ce premier billet. la prochaine fois, on parlera de tests de non régression visuelle.

Si le sujet du test vous intéresse, ou si que vous voulez que j’ajoute d’autres types d’outils / tests à cette série de billets, n’hésitez pas à laisser un commentaire (ou même pour m’encourager ^^).

Un outil pour améliorer la qualité d'un projet web

2015-09-14T00:00:00+00:00

Le mot “qualité”, quand on parle d’un logiciel, est très ambigu : parle-t-on de faible complexité du code source ? D’évolutivité, de performance, d’accessibilité ? Que dire à propos des tests et de l’intégration continue ? La gestion des anomalies (Issue tracker) fait-elle partie de la qualité ? En bref, que siginifie “qualité logicielle” ? Et comment la mesurer ?

Les premières véritables tentatives de définitions datent des années 70, et de McCall et Boehm. Dès 1996, le standard ISO 9126, régulièrement amélioré, donne une liste de caractéristiques possibles, puis les standard ISO 9000:2000 viennent affiner les concepts. Une grille de facteurs de la qualité logicielle est établie et mature.

Grille de facteurs de qualité

Personnellement, la grille que j’utilise dans mes stratégies de test est celle proposée par le groupe ISTQB :

** Exactitude**: Degré de conformité par rapport aux spécifications
** Fiabilité**: Capacité d’un programme à accomplir sa fonction sans défaillance
** Efficacité**: Capacité du programme à exploiter efficacement (de manière optimale) les ressources (CPU, mémoire…) à disposition”
** Intégrité**: Capacité de protéger le système et les données qu’il manipule
** Ergonomie**: Capacité du programme à être utilisé avec peu d’efforts
** Maintenabilité**: Capacité à faciliter la localisation et la correction d’anomalies
** Testabilité**: Capacité du programme à se prêter à une vérification (tests) de bon fonctionnement
** Flexibilité**: Capacité d’évolution et d’adaption à de nouvelles fonctionnalités
** Portabilité**: Facilité de changement d’environnements (OS, matériel…)
** Réutilisabilité**: Possibilité de réutilisation de composants dans d’autres projets
** Interopérabilité**: Capacité du programme à être associé à un autre (échange de données, utilisation…)

Disposer d’une grille, c’est beau, c’est bien… Mais, et après ? On peut s’en servir pour élaborer une stratégie de test, mais ça reste très théorique. Comment mesurer tout ça ?

Si pour la performance (au sens premier, à savoir l’exploitation efficace des ressources mises à disposition), un consensus peut facilement émerger (mesure du temps de réponse, mesure de la complexité asymptotique), qu’en est-il des autres facteurs ? Pas facile…

Mesurer les facteurs de qualité prioritaires

C’est un sujet que j’ai vraiment beaucoup (beaucoup beaucoup) étudié, et à force de confrontations à la réalité des projets, je me suis rendu compte que pour les projets web, certains facteurs sortent du lot, car généralement considérés par les équipes techniques comme “plus importants” :

la maintenabilité
l’évolutivité
la fiabilité

Il existe des métriques logicielles, statiques ou dynamiques, qui tentent de mesurer ces aspects :

Indice de maintenabilité, l’absence de cohésion des méthodes ou le nombre de complexité cyclomatique … pour la maintenabilité et l’évolutivité ;
le CRAP, la couverture ou le taux de résistance aux mutations le taux de détection de bugs… pour la fiabilité ;
le couplage, l’abstraction… pour l’évolutivité et la réutilisabilité.

Malheureusement, les outils pour mesurer ces métriques sont rares ; c’est pour ça que j’ai développé PhpMetrics, ou encore MutaTesting, tous deux Open Source.

Une fois que l’on sait collecter ponctuellement ces métriques, reste encore à rendre la collecte systématique ; pour ça on utilise souvent Sonar ou Jenkins. Or Sonar se focalise plus sur la dette technique (SQALE), et Jenkins n’est clairement pas fait pour ça (mais pour de l’intégration continue). Il faut une énergie immense dans tous les sens pour obtenir un résultat acceptable, à défaut de convenable.

Autre problème : quand bien même on a mis en place ces outils, il reste à rendre les résultats lisibles et clairs, ce qui (croyez-moi) pour le coup n’est vraiment pas simple.

Encore un autre problème : on ne se focalise que sur un code source ; or je l’ai dit, un projet c’est bien plus : on a souvent plusieurs dépôts, un tracker de bugs… Si vraiment on veut mesurer la maintenabilité d’un projet, on doit par exemple regarder l’évolution du nombre de tickets ouverts, l’évolution du taux de détection des bugs (DDP), . A ma connaissance, il n’existe que peu d’outils de mesure qui prennent en compte un projet dans sa globalité (je pense à VisualStudio ou Cast software), et aucun pour PHP.

Qualiboo.com, un outil de mesure en ligne

C’est ce qui m’a amené à réflechir à la création d’un outil capable d’aider à mesurer un projet web dans son ensemble, en collectant un grand nombre de métriques variées. Bien sûr cet outil ne pourrait pas mesurer la “qualité” d’un projet web au sens propre, mais aiderait à fournir des indicateurs. Ce serait un assistant à la qualité, ou à défaut à la détection d’éléments susceptibles de mener à la “non-qualité”.

Il existe plusieurs très bons outils en ligne d’analyse de code pour PHP : Sensio Insight, Scrutinizer… Mais tous ont ces inconvénients que j’ai cités : ils ne se focalisent que sur le code source, et qui plus est sur un seul dépôt de code (pas très pratique quand on fait du microservice par exemple, avec plein de dépôts Git pour un seul projet).

C’est pour ces raisons que j’ai construit qualiboo.com. C’est une application de suivi de la qualité d’un projet web :

analyse du code JavaScript et PHP
aggrégation d’analyses sur plusieurs dépôts de code (Git, Gitlab et Github)
analyse du tracker de bugs (Redmine et Github)
suivi de l’intégration continue (Jenkins - bientôt Travis-ci)
suivi des dépendances (licenses, vulnérabilités connues…)
suivi de l’activité Git
rapports très graphiques en “mode TV”
et très vite bien plus :)

Voici un aperçu de l’application:

C’est un projet à la fois gratuit et payant : gratuit pour les projets Open Source, payant pour les entreprises. Payant ? Si vous me connaissez, vous savez que ça n’est pas fréquent chez moi ; 100% de mes projets sont Open source, libres et gratuits. Oui, mais cette fois j’ai des coûts d’exploitation (serveurs) élevés qu’il me faut rentabiliser, et surtout j’aimerai vraiment améliorer sans cesse la qualité du service rendu par ce site, et donc pouvoir m’y investir pleinement, en prenant le temps qu’il faut pour y travailler efficacement, et pas seulement “vite fait” le matin ou le soir.

Le projet est encore en jeune, mais j’apprécierai vraiment votre feedback : cet outil vous paraît-il utile ? Adapté ? Seriez-vous prêt à l’utiliser ? Que manque t-il à votre avis ?

Et si vous pensez que qualiboo.com peut avoir un intérêt, n’hésitez pas à en parler autour de vous :) . Merci !

OSS : The Swiss Army Knife to manage your free media files.

2015-02-25T00:00:00+00:00

Composer, NPM… so many tools to manage the technical dependencies of our projects. That’s good. But what about managing the licenses of the downloaded files? And what about the free or open source media (images, sounds, videos) that we use?

For example, take this illustration that you version in your project. In 6 months, you won’t remember where it comes from, or under what license it is distributed.

Take the problem of media. There are tools (OpenHub for example), but nothing really related to the daily life of the developer. Until now I had a tendency to note the images I use in a text file. But this approach is a bit messy, and in the long run I get lost between the images that are really used on my site and those that I have downloaded “to test”.

OSS, a tool to manage the free media of your project

OSS is a simple binary, without dependencies, and Open Source. It allows you to manage the free media of your project.

This is why I created a tool to help me manage the free media in a project: OSS. The objectives are:

to encourage developers to explicitly declare the free media they use;
to help developers to manage licenses;
to rationalize licenses using the SPDX repository.

OSS is a simple binary, written in Go, that you can download from the latest release. It does not require any external dependencies.

On first use, simply run the oss init command. This will look for the SPDX repository and create the .oss file at the root of your project.

Then it’s quite simple; the commands are similar to those of Git:

oss add <licence> <fichier> : reference a file
oss rm <fichier> : dereference a file
oss status : status of the repository, lists all referenced media
oss show : information about a file

A file appears in red when it is not found in the project.

One of the objectives is to help developers to manage licenses, the tool comes with the following commands:

oss licenses : lists the licenses of the SPDX repository
oss search <licence> : search for a license

If the license does not exist when adding a media, the tool will suggest a license phonetically close. It is impossible to add a media if its license is not part of the SPDX repository.

This will not be enough: we need the involvement of everyone

I would like a tool capable of listing all the licenses of the bricks of a project. I would love to add to OSS a “scan” function, which would discover the licenses of Bower, Composer, Npm, Gem dependencies…

Technically nothing complicated; the code is almost ready. No, the real problem comes from the developers. Indeed, rare are the dependency management tools that require / encourage to declare a valid license. Licenses are often empty or unusable.

And even if that were the case, a major problem comes from the dependency management tools themselves. Take Bower for example; it is possible to obtain information about a package through the API. For example the HTTP request http://bower.herokuapp.com/packages/jquery will give us:

{"name":"jquery","url":"git://github.com/jquery/jquery.git"}

But as you can see, there is no information about the license. It then takes patches of patches to successfully retrieve the correct license in the LICENSE file of the associated Git repository.

And this is just one example! In short, the real problem is that developers, although fervent users of Open Source, are not yet used to interacting with free software.

For example, a few days ago I intervened on a well-advanced project, which uses a specific NodeJs component. Curious, I opened the LICENSE file of the component in question; and there, surprise: the component was not necessarily so free of rights. When I informed the technical team of this information, I had the right to the following answer:

“But yet it’s Github, we can get the source code, so it’s free”

No! Everything on Github is not free. Moreover by default, any project deposited on Github is proprietary, unless otherwise stated in the sources. Putting your project on Github is good, but let’s not forget to associate a real license, exploitable and clear.

There are comprehensive repositories ready to use; it’s time to make our tools compatible with the world of free software.

Conclusion

OSS is a simple tool, but I hope it will help developers to better manage the free media of their projects.

Feel free to share it, improve it… All ideas are welcome.

💡 Tips

Conférence Licensing and Packaging FOSS with SPDX

SPDX

OSS : Le couteau suisse pour gérer vos fichiers externes libres de droit.

2015-02-25T00:00:00+00:00

Composer, NPM… autant d’outils pour gérer les dépendances techniques de nos projets. C’est bien. Mais quid de la gestion des licenses des fichiers téléchargés ? Et que faire des médias (images, sons, vidéos) libres ou open source que nous utilisons ?

Par exemple, prenez cette illustration que vous versionnez dans votre projet. Dans 6 mois, vous ne vous souviendrez plus d’où elle vient, ni sous quelle licence elle est distribuée.

Prenons le problème des médias. Il existe des outils (OpenHub par exemple), mais rien de vraiment lié au quotidien du développeur. Jusqu’ici j’avais tendance à noter les images que j’utilise dans un fichier texte. Mais cette démarche est un peu brouillonne, et à long terme je m’y perd entre les images qui sont vraiment utilisées sur mon site et celles que j’ai téléchargées “pour tester”.

OSS, un outil pour gérer les médias libres de votre projet

OSS, est un simple binaire, sans dépendance, et Open Source. Il vous permet de gérer les médias libres de droit de votre projet.

D’où mon idée de créer un outil pour me faciliter la gestion des médias libres dans un projet : OSS. Les objectifs sont :

d’inciter les développeurs à déclarer explicitement les médias libres de droit qu’ils utilisent ;
d’aider les développeurs à s’y retrouver dans leur gestion des licences ;
de rationnaliser les licenses en utilisant le référentiel SPDX.

OSS est un simple binaire, écrit en Go, qu’il suffit de télécharger depuis la dernière release. Il ne nécessite aucune dépendance externe.

Au premier usage, lancez simplement la commande oss init. Cette dernière va chercher le référentiel SPDX et va créer le fichier .oss à la racine de votre projet. C’est ce fichier qui va désormais servir d’annuaire de vos médias.

Ensuite c’est assez simple ; les commandes sont proches de celles de Git :

oss add <licence> <fichier> : référencer un fichier
oss rm <fichier> : déréférencer un fichier
oss status : état du référentiel, liste l’ensemble des médias référencés
oss show : informations sur un fichier

Un fichier apparaît en rouge quand il n’est pas trouvé dans le projet.

Un des objectifs étant d’aider les développeurs à s’y retrouver dans la gestion des licenses, l’outil vient avec les commandes suivantes :

oss licenses : liste les licenses du référentiel SPDX
oss search <licence> : recherche une licence

Si la licence n’existe pas lors de l’ajout d’un média, l’outil suggerera une license phonétiquement proche. Il est impossible d’ajouter un média si sa licence ne fait pas partie du référentiel SPDX.

Ca ne suffira pas : il faut l’implication de chacun

J’aimerai un outil capable de répertorier l’ensemble des licenses des briques d’un projet. J’aimerai beaucoup ajouter à OSS une fonction “scan”, qui découvrirait les licences des dépendances Bower, Composer, Npm, Gem…

Techniquement rien de bien compliqué ; le code est quasi prêt. Non, le vrai problème vient des développeurs. En effet, rares sont les outils de gestion de dépendances qui imposent / incitent à déclarer une licence valide. Les licenses sont souvent vides ou inexploitables.

Et même si c’était le cas, un problème majeur vient des outils de gestion de dépendances eux-mêmes. Prenez Bower par exemple ; il est possible d’obtenir des informations sur un paquet grâce à l’API. Par exemple la requête HTTP http://bower.herokuapp.com/packages/jquery nous donnera :

{"name":"jquery","url":"git://github.com/jquery/jquery.git"}

Mais comme vous le voyez, il n’y a aucune information sur la license. Il faut alors des rustines de rustines pour réussir à récupérer la bonne licence dans le fichier LICENSE du dépôt Git associé.

Et ce n’est qu’un exemple ! Bref, le vrai problème, c’est que les développeurs, pourtant fervents utilisateurs de l’Open Source, ne sont pas encore habitués à intéragir avec le logiciel libre.

A titre d’exemple, il y a quelques jours je suis intervenu sur un projet bien entamé, qui utilise un composant NodeJs spécifique. Curieux, j’ai ouvert le fichier LICENSE du composant en question ; et là, surprise : le composant n’était pas forcément si libre de droits que ça. Lorsque j’ai fait part de ces informations à l’équipe technique, j’ai eu le droit comme réponse à :

“Mais pourtant c’est Github, on peut récupérer le code source, donc c’est gratuit”

Non ! Tout ce qui est sur Github n’est pas gratuit. D’ailleurs par défaut, tout projet déposé sur Github est propriétaire, sauf avis contraire dans les sources. Mettre son projet sur Github c’est bien, mais n’oublions pas d’y associer une vraie licence, exploitable et claire.

Il existe des référentiels assez complets et prêts à l’emploi ; il est temps de rendre nous outils compatibles avec monde du libre.

Conclusion

OSS est un outil simple, mais qui je l’espère, pourra aider les développeurs à mieux gérer les médias libres de leurs projets.

N’hésitez pas à le partager, l’améliorer… Toutes les idées sont les bienvenues.

💡 Pour aller plus loin :

Conférence Licensing and Packaging FOSS with SPDX

SPDX

Semantic Versionning automatisé

2015-01-07T00:00:00+00:00

Pour résumer, le sémantique versionning est une logique de fabrication des numéros de version d’un produit où l’on identifie une version v1.2.3 telle que décrite sur le site officiel :

Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter :

le numéro de version MAJEUR quand il y a des changements rétro-incompatibles, le numéro de version MINEUR quand il y a des changements rétro-compatibles, le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétro-compatibles

La prise de décision d’incrémenter une version ne peut être que manuelle : il faut un humain pour savoir si ce qui a été modifié concerne un correctif ou une nouvelle fonctionnalité…

Par contre, il peut-être utile de répercuter cette prise de décision automatiquement. Par exemple pour tagger un dépôt Git, ou encore pour changer un fichier de code source qui contiendrait la version actuelle en dur. C’est ce que j’ai fait pour PhpMetrics.

À l’heure où j’écris ces lignes, la version actuelle de PhpMetrics est la v1.2.0, comme nous le montre la commande suivante :

php phpmetrics.phar --version

La version de l’application est stockée en dur dans le fichier de création du phar (build.php):

$app = new Hal\...\PhpMetricsApplication('...', '1.2.1');

À chaque montée de version, je dois donc penser à modifier ce fichier, puis à créer le tag Git ; ce que j’oublie tout le temps de faire… Il me faut donc l’automatiser.

Première étape : trouver un moyen simple de stocker mon numéro de version actuelle et de l’incrémenter. Ma première idée était de me tourner vers les tags Git en parsant le résultat d’un git describe --tags, mais j’ai trouvé plus simple : semver, un outil qui fait ça très bien. Pour incrémenter une version je n’ai plus qu’à lancer, au choix :

semver inc major
semver inc minor
semver inc patch

Et je récupère la version actuelle avec la commande semver tag. (les infos sont stockées dans un fichier .semver à la racine du projet).

Au lieu de mettre en dur la version dans mes sources, j’utilise donc un tag:

$app = new Hal\...\PhpMetricsApplication('...', '<VERSION>');

Il faut désormais remplacer ce tag par la vraie version récupérée avec semver tag. sed est mon meilleur allié :

sed -i "s/<VERSION>/`semver tag`/g" build.php

Reste enfin à créer un tag git pour cette release :

git tag -a $(semver tag) -m "tagging $(semver tag)"

Et voilà le travail ! Un petit Makefile et le tour est joué. Voici pour les plus curieux le Makefile de PhpMetrics:

REPLACE=`semver tag`
    
# Build phar
build: test
    @echo Copying sources
    @mkdir -p /tmp/phpmetrics-build
    @cp * -R /tmp/phpmetrics-build
    @rm -Rf /tmp/phpmetrics-build/vendor /tmp/phpmetrics-build/composer.lock
    
    @echo Releasing phar
    @sed -i "s/<VERSION>/`semver tag`/g" /tmp/phpmetrics-build/build.php
    
    @echo Installing dependencies
    @cd /tmp/phpmetrics-build && composer.phar install --no-dev --optimize-autoloader --prefer-dist

    @echo Building phar
    @cd /tmp/phpmetrics-build && php build.php
    @cp /tmp/phpmetrics-build/build/phpmetrics.phar build/phpmetrics.phar
    @rm -Rf /tmp/phpmetrics-build
    
    @echo Testing phar
    ./vendor/bin/phpunit -c phpunit.xml.dist --group=binary &&	echo "Done"


# Run unit tests
test:
    ./vendor/bin/phpunit -c phpunit.xml.dist


# Publish new release. Usage:
#   make tag VERSION=(major|minor|patch)
# You need to install https://github.com/flazz/semver/ before
tag:
    @semver inc $(VERSION)
    @echo "New release: `semver tag`"


# Tag git with last release
git_tag:
    git tag -a $(semver tag) -m "tagging $(semver tag)"

Lorsque je veux une nouvelle version, il ne me reste donc que deux lignes à taper pour construire mon phar avec la bonne version:

make tag VERSION=minor
make

La commande php phpmetrics.phar --version indique désormais la bonne version.

Je sais qu’il existe des plugins Jenkins pour ça, mais je souhaitais pouvoir exécuter le processus manuellement si besoin, directement dans mon terminal.

je me doute qu’il existe des solutions plus pertinentes que celle que je décris ici ; vos retours sont donc les bienvenus.

Intégration continue : utiliser le fichier .travis.yml dans Jenkins avec Docker

2014-05-29T00:00:00+00:00

J’utilise massivement travis-ci comme plate-forme d’intégration continue pour mes projets open source.

Pour cela, il suffit d’ajouter un simple fichier .travis.yml. Voici par exemple celui que j’utilise pour PhpMetrics:

language: php
php:
  - 5.3
  - 5.4
before_script:
  - wget http://getcomposer.org/composer.phar
  - php composer.phar install --dev --prefer-dist

script:
  - ./vendor/bin/phpunit -c phpunit.xml.dist

Ce qui est génial avec Travis-ci, c’est de pouvoir lancer son build sur plusieurs environnements (ici PHP 5.3 et PHP 5.4).

J’ai également une PIC locale , pour laquelle j’utilise Jenkins, et qui me permet de suivre l’ensemble de ses projets personnels. Et je dois avouer que ça m’agace de configuer deux fois mon build : et dans Jenkins, et dans Travis.

Voici donc un moyen minimaliste de builder un projet dans Jenkins, dans des environnements isolés (grâce à Docker), en utilisant le même fichier .travis.yml qu’avec Travis-ci.

Installation de Docker et configuration des containers

Je ne vais pas m’attarder sur Docker : de nombreux tutoriels existent sur le net, et la documentation est assez bien faite. Sachez juste que c’est ce qui va nous permettre de virtualiser nos environnements.

Tout ce dont on a besoin pour l’installation (debian) tient sur ces quelques lignes :

#!/bin/bash
# fichier install.sh

# Dépendances PIP (pour le Yaml)
apt-get update  -y -q
apt-get install python-pip -y
pip install shyaml

# Docker
apt-get install docker.io  -y
ln -sf /usr/bin/docker.io /usr/local/bin/docker

# Containers
docker build -t debian/5.3 - < Dockerfile53
docker build -t debian/5.4 - < Dockerfile54
docker build -t debian/5.5 - < Dockerfile55

Les trois dernières lignes sont intéressantes. Ce sont elles qui vont créer nos environnements de test. Docker permet en effet de provisionner et configurer un container à l’aide d’un fichier de configuration (le fameux Dockerfile, mais ici qui s’appelle Dockerfile53, Dockerfile54, etc). Voici ceux que j’ai utilisé pour cet exemple, libre à vous de les enrichir :

pour PHP 5.3 :

# fichier Dockerfile53
FROM debian:squeeze
RUN apt-get update -y -q
RUN apt-get install  php5-common php5-cli php5-curl php5-xdebug wget -y --force-yes
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/

pour PHP 5.4 :

# fichier Dockerfile54
FROM debian
RUN echo "deb http://packages.dotdeb.org wheezy all" |  tee -a /etc/apt/sources.list
RUN echo "deb-src http://packages.dotdeb.org wheezy all" |  tee -a /etc/apt/sources.list
RUN apt-get update -y -q
RUN apt-get install  php5-cli php5-curl php5-apc php5-xdebug wget -y --force-yes
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/

pour PHP 5.5 :

# fichier Dockerfile55
FROM debian
RUN echo "deb http://packages.dotdeb.org wheezy-php55 all" |  tee -a /etc/apt/sources.list
RUN echo "deb-src http://packages.dotdeb.org wheezy-php55 all" |  tee -a /etc/apt/sources.list
RUN apt-get update -y -q
RUN apt-get install  php5-cli php5-curl php5-apc php5-xdebug wget -y --force-yes
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/

Si vous lancez maintenant les commandes d’installation qui sont plus haut, vous vous retrouverez avec trois containers :

debian/5.3
debian/5.4
debian/5.5

Leurs noms sont très importants : ce sont eux qui vont nous permettre de faire le lien avec le fichier .travis.yml.

Lancement des tests

L’objectif est de ne plus avoir à configurer quoique ce soit dans Jenkins. Nous allons donc créer un script qui va lire le fichier .travis.yml, repérer les commandes à exécuter (noeuds before_script et script), puis lancer ces commandes pour chaque environnement souhaité.

Pour les plus pressés, voici ce script (et voici le gist si vous souhaitez l’améliorer).

#!/bin/bash
EXIT_STATUS=0

echo "#!/bin/bash" > ./docker-travis-test.sh
cat .travis.yml | shyaml get-values before_script >> ./docker-travis-test.sh
cat .travis.yml | shyaml get-values script >> ./docker-travis-test.sh


PHP_VERSIONS=`cat .travis.yml | shyaml get-values php`
for PHP_VERSION in $PHP_VERSIONS
do

    echo
    echo "Running tests for PHP $PHP_VERSION"
    echo "==================================="


    DOCKER_IMG=debian/$PHP_VERSION


    DOCKER_ID=$(docker run -d -t $DOCKER_IMG /bin/bash)
    docker run  -v `pwd`:/project -w "/project" -t $DOCKER_IMG /bin/bash ./docker-travis-test.sh

    CODE=$?
    case "$CODE" in
     0) RESULT="OK"
        OUTPUT="${OUTPUT}PHP ${PHP_VERSION}: OK \n"
        ;;
     *)
        RESULT="ERROR ($CODE)"
        OUTPUT="${OUTPUT}PHP ${PHP_VERSION}: Error (code ${CODE}) \n"
        EXIT_STATUS=1
        ;;
    esac

    DOCKER_IDS="${DOCKER_IDS} ${DOCKER_ID}"
done


docker restart $DOCKER_ID
$(docker wait ${DOCKER_IDS})

echo
echo "Results"
echo "==================================="
echo -e $OUTPUT;

exit $EXIT_STATUS

Passons aux explications :)

echo "#!/bin/bash" > ./docker-travis-test.sh
cat .travis.yml | shyaml get-values before_script >> ./docker-travis-test.sh
cat .travis.yml | shyaml get-values script >> ./docker-travis-test.sh

Ces quelques lignes permettent de concaténer les contenus des noeuds before_script et script dans un fichier nommé arbitrairement ./docker-travis-test.sh. Ce fichier sera donc executé pour lancer les tests. La lecture du fichier yaml s’effectue grâce à shyaml

PHP_VERSIONS=`cat .travis.yml | shyaml get-values php`
for PHP_VERSION in $PHP_VERSIONS
do
    ...
done

Ces lignes extraient du fichier .travis.yml la liste des versions de PHP sur lesquelles ont souhaite exécuter nos tests, puis itèrent sur chaque version ($PHP_VERSION vaut ici “5.3” puis “5.4”)

DOCKER_IMG=debian/$PHP_VERSION

Cette ligne est très importante : c’est elle qui fait le lien entre la version souhaitée et un container Docker. Rappelez-vous que l’on a nommé nos containers “debian/5.3”, “debian/5.4” et “debian/5.5”.

DOCKER_ID=$(docker run -d -t $DOCKER_IMG /bin/bash)
docker run  -v `pwd`:/project -w "/project" -t $DOCKER_IMG /bin/bash ./docker-travis-test.sh

C’est là que tout se passe : on récupère l’ID de notre container (pour pouvoir travailler avec), puis on lance le script ./docker-travis-test.sh que l’on a créé plus haut sur notre code.

À noter :

-w /project définit l’espace de travail du container
-v \~pwd\~:/project permet de partager le dossier courant avec le container

CODE=$?
case "$CODE" in
 0) RESULT="OK"
    OUTPUT="${OUTPUT}PHP ${PHP_VERSION}: OK \n"
    ;;
 *)
    RESULT="ERROR ($CODE)"
    OUTPUT="${OUTPUT}PHP ${PHP_VERSION}: Error (code ${CODE}) \n"
    EXIT_STATUS=1
    ;;
esac

...

echo
echo "Results"
echo "==================================="
echo -e $OUTPUT;

exit $EXIT_STATUS

Ces lignes permettent de gérer les codes de retour d’erreur, et concatènent le résultat de chaque jeu de tests dans la variable OUTPUT afin de l’afficher à la fin du build.

Exemple dans Jenkins

Voici donc à quoi ressemblent mes builds Jenkins désormais

La prochaine étape serait la parallélisation (le plus simple me paraît d’utiliser parallel), et bien sûr de rendre tout ça un peu plus propre (rollback des containers, nettoyage…). En attendant, à vous de jouer :)

Qualité logicielle : comment fixer les valeurs limites ?

2014-05-07T00:00:00+00:00

Plus j’avance dans la réalisation de PhpMetrics, plus une question se pose : je dispose de métriques sur le code source, mais à partir de quel moment alerter l’utilisateur ? Quelle est la valeur idéale ? Quelles sont les valeurs minimales et maximales ?

Je vous propose un petit retour d’expérience sur la manière dont j’ai tenté de fixer ces valeurs pour PhpMetrics. Ce qu’il faut savoir, c’est que j’ai procédé itérativement selon la manière suivante :

utilisation de valeurs théoriques
pondération de la théorie
analyse démographique
ajustement par l’expérience

Étape 1 : Utilisation de valeurs théoriques

La première méthode est la plus simple : la plupart des métriques logicielles que j’ai intégrées sont très bien théorisées, et de des suggestions de bornes maximales et minimales existent assez souvent.

Prenez LCOM4 par exemple. Cet indicateur (Lack of cohesion of methods) tend à révéler la cohésion d’une classe :

<?php
class Example {
    private $a;

    public function m1() {
        $this->m2();
    }

    public function m2() {
        $this->a = 1;
    }

    public function m3() {
        $this->a = 1;
    }

    public function m4() {
        $this->m5();
    }

    public function m5() {
        echo 'ok';
    }
}

Examinons les corrélations des méthodes de cette classe :

m1() appelle m2(). m2() partage avec m3 un attribut commun a
m4() appelle m5()

Il y a donc deux flux de code bien distincts dans cette classe. On dit alors que LCOM4(Example) = 2.

Cet indicateur est à mettre en relation avec le S des principes SOLID (Single reponsability). Les méthodes d’une classe qui servent une besoin commun s’articulent ensemble : elles s’appellent les unes les autres ou partagent des attributs communs. Il est donc probable ici que notre classe possède au moins deux reponsabilités.

D’un point de vue purement théorique, la valeur idéale de LCOM4 d’une classe est donc de 1.

Étape 2 : Pondération de la théorie

Mais il ne faut pas oublier que ces indicateurs, bien que volontairement agnostiques, ont tout de même été fortement orientés par les langages de programmation utilisés pour les théoriser / illustrer.

Revenons à LCOM4, et à l’idéal théorique de LCOM4(classe) = 1.

Cet idéal signifie que toutes les méthodes d’une classes fonctionnent ensemble (principe de cohésion). Or la plupart des classes PHP comportent un très grand nombre de getters/setters, souvent inutilisés à l’intérieur de la classe même. Vu par un robot, les getters/setters méthodes semblent des méthdoes orphelines, et augmentent donc artificiellement LCOM4.

Cet aspect est propre aux langages qui ne comportent pas de sucre syntaxique pour les getters et setters. En C#, on pourrait simplement écrire

public int X { get; set; }

En PHP ce n’est pas encore le cas. il faut donc pondérer cet indicateur.

Il en va de même pour la majorité des indicateurs : le code écrit en PHP est assez typique : typique par le langage même, mais aussi par l’orientation des projets qui l’utilisent, assez souvent plus orientés production (court terme) plutôt qu’évolution (long terme).

Petite parenthèse utile : je ne cherche pas à polémiquer, juste à faire un constat. Ce constat pourrait tout à fait être identique pour d’autres langages de programmation. Oui, je sais qu’il y a d’excellents projets PHP, orientés très long terme. Mais je pense ici faire un constat d’ordre général selon mon expérience. Bref, j’essaye d’être pragmatique.

Étape 3 : Analyse démographique

Il m’a donc fallu trouver un moyen de déterminer de nouvelles bornes, proches de la téhorie, mais plus adéquates à PHP.

Le plus simple m’a semblé de faire une analyse démographique de projets PHP. Idéalement de projets représentatifs. Coup de chance, packagist fournit la liste des paquets les plus utilisés. Je me suis donc mis à les analyser.

[Spoiler] La première chose à comprendre est que cette analyse est biaisée :

les projets sont open source. Ils sont fait par des volontaires, avec un processus souvent plus qualitatif (revue de code) que des projets d’entreprise
les projets recensés sur packagist sont ceux qui sont déclarés comme paquet Composer. Ils sont donc, pour la plupart, très récents.
les projets open source concernent généralement de l’outillage (composants, frameworks, librairies…). Ils ne sont pas représentatifs de projet fonctionnement complexes

[/Spoiler]

Je reviendrai sur ces aspects par la suite. En attendant, je pense que cette analyse, bien que biaisée, reste pertinente si on la prend pour ce qu’elle est, et rien de plus : une analyse de projets bien spécifiques, représentatifs d’une partie seulement des typologies de projets possibles.

Le processus d’analyse est le suivant :

Téléchargement des sources
Exécution de l’analyse sur un échantillon représentatif (environ 5 000 classes)
Aggrégat des résultats
Elimination des extrêmes (par écart interquartile)
Analyse des percentiles de chaque série

Je me suis alors retrouvé avec des résultats de ce type :

Par tâtonnements, il m’a paru judicieux de considérer comme :

borne inférieure => le trentième percentile
borne supérieure => le quatre vingtième percentile
borne supérieure maximale => le quatre vingt dixième percentile

Dans le cas du nombre de lignes de code, il en ressortirai qu’un fichier doit contenir idéalement entre 65 et 130 lignes de code, et au maximum 154. Ces chiffres ne semblent pas absurdes.

Voici quelques graphiques qui illustrent ces résultats:

Étape 4 : Ajustements par l’expérience

Je l’ai dit : l’analyse démographique, bien qu’intéressante, est faussée : elle ne considère que certains types de projets (généralement des outils).

Dans la vraie vie, la plupart des codes sources sont “en dehors de clous”. Facile d’avoir une complexité cyclomatique faible quand on n’a pas de délais, qu’on ne gère pas de changements fonctionnels fréquents ou qu’on ne gère pas de règles métiers…

J’ai donc confronté ces indicateurs à mon expérience. J’ai en effet la chance de réaliser des audits chez de nombreux clients, ce qui me permet d’être confronté à des projets très variés et nombreux . J’ai donc systématiquement analysé le code des projets auxquels j’ai été confronté, et ce depuis que je suis développeur (ou presque).

Attention, là encore l’analyse est biaisée : quand on fait appel à un consultant, c’est en général que le projet subit des avaries, souvent dûes à des problèmes techniques (code peu évolutif, architecture mal adaptée…). Le code de ces projets est donc généralement moins maintenable que sur des projets où tout se passe bien (même si ce n’est pas systématiquement le cas). On est donc dans la situation inverse des projets Open Source précédemment mentionnés.

J’ai donc réajusté les indicateurs en fonction de ces analyses, et continue de les réajuster au fur-et-à-mesure.

Conclusion

Enfin, un point important reste à soulever. C’est d’ailleurs cet aspect qui m’a fait hésiter à fournir des indicateurs visuels (rouge pour “critique”, jaune pour “à examiner” et vert pour “probablement correct”) : aucune borne, aucune limite n’est universelle.

Lorsqu’on analyse un Controlleur, il est évident qu’on ne s’attend pas à avoir le même Vocabulaire que dans un Service. Une Entité n’aura pas le même Indice de maintenabilité qu’un Validateur…

La conclusion de ces analyses est donc assez triviale : c’est à l’humain de pondérer les chiffres. Un outil d’analyse ne fournit que des indicateurs, pas des vérités.

Attention, il ne faut pas pour autant rejeter tout outil d’analyse statique (comme on le fait malheureusement trop souvent). Ces indicateurs sont pratiques et indispensables si on sait les interpréter et les prendre pour ce qu’ils sont : des indicateurs. Ce qui compte, ce n’est pas de savoir si telle classe ou telle fichier a une complexité trop élevée. Non, ce qui est important c’est de surveiller et de tenir compte de l’accumulation d’indicateurs et de leur orientation générale.

Si une classe a un peu trop de lignes de code ce n’est pas grave ; si les classes d’un paquet ont une Complexité cyclomatique élevée, une LCOM élevée, un Indice de maintenabilité faible… là il faudra écouter les tendances des indicateurs, et se pencher sur le code en question pour comprendre ce qui peut causer ces remontées.

**L'analyse statique n'est pas une diseuse de vérité, mais un un outil d'alerte**

Indice de maintenabilité d'un projet PHP et Jenkins

2014-02-06T00:00:00+00:00

Dans mon dernier billet je vous avais présenté un outil sur lequel je travaille : PhpMetrics. Cet outil permet de calculer différents indicateurs sur le code source, dont l'Indice de Maintenabilité, le Poids des commentaires, la Difficulté d'un code, etc.

Je pense qu'avoir une vision régulière de ce type d'indicateurs est important pour assurer la qualité d'un projet, ou au moins détecter les écarts de qualité assez rapidement. Bien que ce ne soit pas vraiment le rôle de Jenkins d'assurer un tel suivi (mais plutôt d'un outil comme Sonar, par exemple), mais vu que Jenkins reste un outils assez répandu aujourd'hui, je vous propose de voir comment intégrer ces indicateurs de code dans Jenkins.

Si vous n'avez jamais utilisé Jenkins, je vous invite à lire les excellents billets de Pascal Martin sur l'installation et la configuration d'un premier projet PHP. Et si vous êtes un peu fainéant, vous pouvez aussi directement utiliser la procédure d'installation expliquée sur sur jenkins-php.org.

Je pars du principe pour la suite que vous avez un job Jenkins fonctionnel.

Première étape: lancer l'analyse.

Différentes options s'offrent à vous. Si avoir Java sur votre machine d'intégration ne vous dérange pas, vous pouvez utiliser Ant. Voilà à quoi ressemblera votre fichier build.xml (par exemple):

<?xml version="1.0" encoding="UTF-8" ?>
<project name="demo" default="phpmetrics" basedir="./">

    <!-- source to analyze -->
    <property name="src" value="${basedir}/src"/>

    <target name="phpmetrics">
        <exec command="wget https://github.com/Halleck45/PhpMetrics/raw/master/build/metrics.phar"/>
        <exec command="php metrics.phar --summary-xml=phpmetrics.xml --summary-html=phpmetrics.html ${src}"/>
    </target>
</project>

Si vous pensez que, finalement, ce n'est peut être pas si pertinent d'avoir [troll]une énorme usine à gaz juste pour lancer deux commandes[/troll], vous pouvez simplement configurer le job pour qu'il exécute les commandes en question directement :

Deuxième étape: le graphique

Nous allons utiliser le plugin de Jenkins Plot, dont c'est justement la spécialité; Il suffit de configurer une étape Post-Build pour ajouter le résultat de la dernière analyse au graphique :

Bonus: le rapport HTML

PhpMetrics fournit un rapport Html qui offre, je l'espère, un peu de recul sur un code source. N'hésitez pas à installer le plugin Html Publisher, qui vous permettra d'ajouter un lien vers ce rapport HTML dans le menu de votre projet :

Le mot de la fin

Bien évidemment vous pouvez intégrer d'autres courbes: Volume du code, Difficulté... La démarche sera la même que celle présentée ci-dessus.

Je vous rappelle que PhpMetrics est Open Source, et a besoin d'être éprouvé, tant sur les indicateurs fournis que sur la stabilité de l'outils. N'hésitez pas à [lien github issue]remonter les anomalies que vous rencontrerez, ou simplement à me dire si vous l'utilisez : ça me motivera encore plus pour l'enrichir et l'améliorer ;)

La maintenabilité d'un projet PHP en images

2013-12-18T00:00:00+00:00

Ça faisait longtemps que je cherchais un outil capable de me fournir un aperçu, très général et visuel, de la maintenabilité d'un projet. Ne trouvant finalement que peu de chose sur le net, je me suis décidé à en coder un rapidement.

Pour illustrer le fonctionnement de cet outil, voici les rapport pour les sources de différents projets PHP :

Symfony2 Component :

Zend Framework 2 :

Drupal 7 :

CakePHP 2 :

WordPress 3 2 :

Chaque cercle représente un fichier. En schématisant, plus le cercle est gros, plus le code est complexe ; la couleur, elle, est représentative de l'indice de maintenabilité.

Pour les plus pressés, l'outil en question est disponible sur Github.

Pour les autres, voici quelques explications.

Avant de commencer, il faut être conscient que la notion de maintenabilité applicative est bien plus complexe que ne sait le résoudre un tel outil. Elle dépend de facteurs humains (équipe en charge du projet), environnementaux (contexte de l'entreprise, contraintes de délais), du code source (clarté, simplicité), du choix des outils (présence d'un support, possibilité d'obtenir des formations), etc.

Cet outil ne prétend en aucun cas fournir des chiffres précis sur l'ensemble de ces critères. Non, l'objet de cet outil est de fournir des indicateurs à partir d'une analyse statique du code source.

Je n'ai rien inventé : les algorithmes utilisés pour calculer ce type d'indicateurs existent depuis la fin des années 70, et de nombreux IDE (Visual Studio par exemple) intègrent nativement des modules de supervision du code basés sur ces mêmes algoritmes pour différents langages de programmation.

L'outil commence d'abord par convertir le code source en tokens, pour calculer le premier indicateur utilisé : les métriques d'Ahlstead. Cet indicateur fourni des informations à partir d'un ratio entre le volume du code, la variété et le type de structures manipulées dans un code source. Il fournit :

la taille du programme (N) ;
le vocabulaire (n) : en gros, plus le code emploie de fonctions, variables, opérateurs... différents, plus le vocabulaire est riche ;
le volume du programme (V) : ratio entre la taille et le vocabulaire ;
le niveau de difficulté (D) : propension d'erreurs du programme ;
l'effort d'implémentation fourni (E) ;
le temps d'implémentation estimé en secondes (T) ;
le nombre de bugs délivrés (B) : il s'agit d'une estimation du nombre de bugs dans le code source. Ce nombre est idéalement inférieur à 2.

La seconde étape consiste à calculer la complexité cyclomatique du code source. De ce côté, je n'ai pas cherché à réinventer la route : j'utilise l'excellent phploc.

À partir de ces informations, nous pouvons calculer l'Indice de maintenabilité. Cet indicateur fourni une note, de 0 à 171, où 0 représente un code très difficilement maintenable, et 171 un code maintenable.

Le code source est disponible sur Github: Halleck45/PhpMetrics. Cet outil reste à affiner ; n'hésitez donc surtout pas à proposer des améliorations ou à signaler des anomalies.

Le Développement piloté par le comportement : 2 ebooks gratuits et libres

2013-10-04T00:00:00+00:00

Ça faisait longtemps que je les avais rédigés (plus de 6 mois), je viens de les retrouver au fond de mon placard. Voici deux ebooks open source et gratuits sur le développement piloté par le comportement (Behavior Driven Development).

Ces deux livres courts (50 pages) sont, plutôt que des documentations complètes, des invitations : il ne s'agit en aucun cas d'expliquer techniquement ce qu'est le Développement piloté par le comportement, mais bien de comprendre la philosophie qui anime cette démarche. Ils s'adressent bien spécifiquement à deux cibles : les fonctionnels (clients, product owner...) et les techniques (développeurs, testeurs...).

Tome 1 : Communiquez avec vos développeurs

Tome 1 : Communiquez avec les développeurs

Ce tome, comme son titre l'indique, explique aux chefs de projets fonctionnels (et clients, product owners...) les avantages qu'ils auraient à utiliser la méthodologie du développement piloté par le comportement : économies de communication, gain de vélocité, efficacité et stabilité... Sans jamais aborder les aspects techniques de la démarche.

Tome 2 : Développeurs, faites-vous plaisir !

Tome 2 : Développeurs, faites-vous plaisir

Ce tome, lui, s'adresse aux développeurs soucieux de la qualité de leurs projets, ou fatigués de faire des va-et-vients entre les demandes toujours changeantes de leurs clients. Il ne s'adresse pas spécifiquement aux développeurs PHP, même si les exemples utilisés utilisent Behat comme outil de test.

Open Source ?

Ces deux livres, publiés avec l'application PHP easyBook, sont open source. Les fichiers MarkDown utilisés sont accessibles sur mon Github. N'hésitez pas, si le coeur vous en dit, à y contribuer :-)

Mon idée première était de ne faire qu'un seul livre, à double destination (fonctionnels et techniques), puis de contacter un éditeur pour une publication classique. Plusieurs éléments m'ont convaincus du contraire :

Au départ le projet a été lancé en collaboration avec une startup nantaise bien connue. Différents changements d'organisation là-bas ont ralenti la finalisation du livre. Il est temps pour moi de le publier, le plus simple reste d'en faire des ebooks accessibles à tous.
Plusieurs éditeurs m'ont pertinemment fait remarquer qu'un livre doit choisir une, et une seule seule, cible. Sinon les revendeurs ne sauront jamais comment communiquer pour vendre le livre.
Je me sers déjà depuis plusieurs mois du tome 1 auprès de mes clients pour leur expliquer les avantages du Développement piloté par le comportement et leur expliquer comment formaliser leur besoin efficacement. Ça l'air plutôt efficace, j'ai donc envie que le maximum de personnes puissent faire de même en introduisant cette pratique dans leur société.
Pourquoi pas ? :) . Je ne travaille qu'avec des produits open source, pourquoi un livre ne le serait-il pas ? Surtout qu'il a été rédigé en MarkDown language, ce qui facilite d'autant plus la contribution...

Je vous invite donc à visiter communiquez.lepine.pro pour télécharger ces ebooks (PDF ou ePub). Les sources sont, elles, hébergés sur Github.

Je suis preneur de tout retour, toute remarque ou suggestion. Les livres ne sont pas figés, ils sont faits pour évoluer. Merci à vous !

Mutation Testing en PHP : pour la qualité des tests unitaires

2013-06-03T00:00:00+00:00

Aujourd'hui, dans l'écosystème PHP, on ne se pose enfin plus la question de savoir ce qu'est un test unitaire. Les tests unitaires sont devenus une pratique courante, et il existe des frameworks de tests matures, comme PHPUnit ou atoum.

L'engouement pour la qualité logicielle a poussé la communauté à progresser et à proposer de nouvelles pratiques, de nouveaux outils... Cependant, il reste encore exceptionnel de contrôler la qualité des tests unitaires produits.

Attention, par contrôle de qualité des tests, je ne parle pas d'indicateurs de couverture de code. Non, car une couverture de code à 100 % est contre-productive, impossible et surtout totalement fausse. Et voici pourquoi.

Couverture de nœuds et couverture de chemins

Les outils de couverture actuelle ont un défaut majeur, inhérent à leur fonctionnement : ils indiquent uniquement si des portions de code ont été exécutées lors des tests unitaires.

Or, prenons un exemple simple :

<?php
class Foo {
    public function bar($x, $y) {
        if($x == 1) {
            echo 'A';
        } else {
            echo 'B';
        }
        
        if($y == 1) {
            echo 'C';
        } else {
            echo 'D';
        }
    }
}

et le test unitaire suivant :

<?php
<p>require_once __DIR__.'/Foo.php';</p>
class FooTest extends PHPUnit_Framework_TestCase
{
    public function testFoo1()
    {
        $foo = new Foo;
        $foo->bar(1, 2);
        $foo->bar(2, 1);
    }
}

Le premier appel de bar() affiche 'AD', le second affiche 'BC'. Je suis donc passé partout dans mon code source, la couverture de code de ma suite de test est de 100 % :

Super ! 100 % ! J'ai couvert tout mon code ! En plus c'est vert, c'est donc que tout va bien.

Et bien non… ou plutôt, je suis passé à chaque nœud de mon code source, mais je n'ai pas couvert tous les chemins possibles de code. Car avec ces deux if(), le code peut faire :

A, C
A, D
B, C
B, D

Quatre chemins possibles donc, alors que la couverture de code est de 100 % en à peine deux tests. La couverture de code est donc un indicateur assez peu fiable, puisqu'elle nous trompe allègrement : dans mon exemple, très simple, je n'ai en réalité couvert que 50 % des chemins possibles ; et encore, uniquement pour cette portion de code. Et le code est très simple : imaginez un switch() avec des if() imbriqués, vous verrez qu'en réalité la différence entre la réalité et la couverture de code indiquée est exponentielle.

Pire : les test unitaires qui ne testent rien

Attendez, j'ai donc ici une couverture de code de 100 %, mais, en réalité, mes tests unitaires ne font strictement rien. Il n'y a même pas d'assertion !

Il arrive en effet très fréquemment que les tests unitaires ne servent à rien. Oui, même dans la vraie vie, même sur de gros projets. C'est encore plus vrai lorsqu'on commence à " sur-mocker " tout et n'importe quoi : un mock par-ci, un mock par-là... Il m'arrive de voir des tests unitaires où les assertions portent sur des mocks ; autant ne pas écrire de test unitaire.

Quel indicateur de qualité alors pour les tests unitaires?

Vous l'avez compris, il est difficile d'obtenir des indicateurs fiables de qualité pour des tests unitaires. Et encore, on ne cherche que des indicateurs...

C'est ici qu'intervient le Mutation Testing. Dès les années 70 (oui, c'est vieux), s'est posée la question de savoir comment résoudre cette question de la qualité de tests.

L'idée du Mutation Testing consiste à introduire des bugs dans le code source, puis à vérifier si les tests unitaires ont bien détecté ces bugs. Autrement dit, nous introduisons des mutations dans le code source (on parle de " mutants "), les tests unitaires sont sensés les détecter (on dit alors que le mutant en question est " tué ").

Si tous les bugs ont bien été détectés, c'est sans doute que les tests unitaires sont fiables. Si aucun bug n'est détecté, les tests unitaires ne servent à rien. Dire que tous les mutants ont été tués est donc un indicateur de la bonne qualité de tests unitaires.

Les avantages du Mutation Testing sont nombreux :

c'est efficace
c'est très simple et ne requiert pas de développement spécifique en plus des tests unitaires
c'est assez précis.

Par contre, le Mutation Testing a un certain nombre d'inconvénients :

C'est très très long à s'exécuter (le volume de mutations possibles est exponentielle)
Il arrive qu'il y ait des mutants impossible à tuer

Maintenant que les bases sont posées, parlons outils. Il n'existait en PHP, à ma connaissance, qu'un seul outil pour le Mutation Testing : Mutagenesis. Malheureusement, cet outil, pourtant très intéressant, a, malgré ses avantages, trois inconvénients :

il est sorti trop tôt, à une époque où tester son code restait encore une pratique anecdotique en PHP
le dernier commit date de plus d'un an
il nécessite d'installer une extension PHP assez lourde : RunKit

Partant de ce constat, j'ai réfléchi à une solution pour proposer un outil plus moderne et moins lourd. J'ai donc démarré le développement de MutaTesting. A titre personnel, je dois avouer que ça m'intéressait beaucoup de voir comment résoudre les difficultés inhérentes à cet outil sans devoir passer par l'installation de RunKit ou de xDebug.

MutaTesting, un nouvel outil pour la qualité PHP

MutaTesting, c'est quoi ? C'est un outil PHP qui crée des mutants à partir votre code source puis lance vos tests unitaires pour voir s'il est possible de tuer ces mutants.

Mon idée première a été de faire un outil très simple : pas besoin d'extension PHP, pas besoin de configuration compliquée ; il suffit, en ligne de commande, d'indiquer trois choses :

le framework de test utilisé
le chemin du binaire à exécuter pour lancer les tests
le dossier des tests unitaires

Par exemple, pour une suite de tests PHPUnit :

./bin/mutatesting phpunit phpunit.phar myTestFolder

ou pour atoum :

./bin/mutatesting atoum mageekguy.atoum.phar myTestFolder

C'est tout. A partir de là, MutaTesting va procéder à un certain nombre de processus :

les tests vont être lancés une première fois
chaque suite de test va être isolée, puis relancée pour déterminer quelles sources PHP elle permet de tester
le code source est converti en tokens, puis chaque token transformable est transformé en mutant
chaque suite de test va être relancée sur chaque mutation de code

Bien entendu, votre code source n'est jamais modifié. En réalité, l'outil joue avec un StreamWrapper spécifique pour le flux de fichier standard (file://) pour substituer la mutation à votre code originel.

Voici quelques exemples de bugs qui peuvent être introduits :

remplacer un test d'égalité (" == ") par un test de non-égalite (" != ")
remplacer " true " par " false "
supprimer un bloc " else "

Voici le résultat de la mutation pour les tests de MutaTesting même :

L'analyse du code source a donc permis de créer 46 mutants, donc 26 ont survécu. Le score des tests est donc de 43 %.

Les tests unitaires ont donc des anomalies. Relançons le même outil pour obtenir un compte rendu au format HTML, plus complet (option –format=html). Voici un aperçu de ce qui est obtenu :

Cette fois-ci on a plus de détails : les mutants sont détaillés et regroupés par fichier de source.

Ce qui est intéressant, c'est que les sources qui ressortent comme les moins bien testées sont justement celles que je n'ai pas développées par TDD. L'analyse de ce rapport va donc me permettre de me focaliser sur les tests unitaires qui concernent les sources sur lesquelles le plus de mutations a survécu.

Conclusion

Le Mutation Testing est donc finalement assez simple : on introduit des bugs dans un code source, puis on vérifie qu'ils sont bien détectés par les tests unitaires.

Ce qui est surtout intéressant c'est que cette pratique ne nécessite aucun développement en plus, mais simplement l'utilisation d'un outil, automatisé

Concernant MutaTesting même, que j'ai développé et qui est disponible sur Github, je pense que c'est un outil que j'espère simple à utiliser et à étendre. Bien que fonctionnel, il peut largement être amélioré. Les Pull Requests sont les bienvenues :-) .

De la même façons, vos retours sur les bienvenus : sur vos pratiques, vos attentes en terme d'outils...si l'envie vous prend de l'essayer, voire d'y contribuer.

PS: j'ai eu pas mal de remarques sur la lisibilité du thème de ce blog. J'ai changé de thème ; c'est mieux ? :p

Mais... on peut faire "ça" en PHP ? Mais c'est horrible !

2013-03-26T00:00:00+00:00

Pour changer, je ne vais pas parler de ce qui est super avec PHP, mais plutôt de ce qui pue dans PHP. Et oui...

Attention, qu'on ne me fasse pas dire ce que je n'ai pas dit : j'adore PHP ! C'est la techno que j'utilise tous les jours, c'est un beau langage, riche et puissant, mais aussi très souple, et il est facile de faire n'importe quoi avec. Les codes suivants sont des exemples de ce qu'on peut faire grâce (ou à cause) de cette souplesse.

Ces techniques sont vraiment crades, mais peuvent parfois, en dernier recours, être utiles. Après, si vous voyez un code qui les utilise, posez-vous la question : est-ce PHP qui est crade, ou bien n'est-ce pas plutôt le développeur derrière qui ne s'est pas posé assez de questions ?

Redéfinir la portée d'un attribut

Commençons doucement. Un attribut privé est un attribut qui n'est accessible que par la classe qui le possède (par définition)... Ah bon ? Et si on essaye de changer sa portée ?

class Foo
{

    private $bar = 5;

    public function bar()
    {
        return $this->bar;
    }

}

$foo = new Foo;


$attribute = new ReflectionProperty($foo, 'bar');
$attribute->setAccessible(true);
$attribute->setValue($foo, 'nouvelle valeur');

var_dump($foo->bar());
// string(15) "nouvelle valeur"

Nom de zeus ! On vient de modifier la valeur d'un attribut privé !

Lire des attributs privés

On a pu changer la portée d'une variable, mais l'honneur est sauf : il n'est pas possible de lire un attribut privé, tant qu'il reste privé.

Bon, il doit bien y avoir une solution, non ? Essayons avec un petit coup de serialize().

class Foo {
    private $bar = 5;
}

$foo = new Foo;
$serialized = serialize($foo);

preg_match('!bar";(.):(.*);!', $serialized, $matches);
list(,$type,$value) = $matches;

var_dump("bar vaut $value");
// bar vaut 5

Facile ! Bien sûr, l'exemple est trivial, il existe des solutions plus complètes.

Hériter... directement de ses grand-parents

L'héritage c'est pratique ; un objet hérite de son parent, qui lui-même hérite d'un autre objet, le tout dans une harmonie parfaite.

Mais attendez, saviez-vous qu'il est possible d'hériter de sa classe grand-mère, sans passer par sa classe Mère ? (par pitié, n'essayez pas de vous représenter ce que ça ferait dans la vraie vie)

class GrandMother {
    public $bar;
    public function foo() {
        return $this->bar. ' in GrandMother';
    }
}

class Mother extends GrandMother {
    public function foo() {
        return $this->bar. ' in Mother';
    }
}

class Child extends Mother {
    public function foo() {
        return GrandMother::foo();
    }
}

$child = new Child;
$child->bar = 'abc';
var_dump($child->foo());
// string(18) "abc in GrandMother"

Il suffit donc de ne pas utiliser le mot-clef "parent", mais directement le nom de la classe Grand-mère. Le contexte ($this) est bel et bien préservé. C'est un reliquat de PHP 4...

Ne pas donner de nom à une variable

Toute variable possède un nom : $i, $foo, $bar... Que se passe t-il si vous tenez de déclarer une variable sans lui donner de nom ?

$ = 5;
// PHP Parse error:  syntax error, unexpected '=', expecting variable

Arf... Mais attendez, ne peut-on pas utiliser l'évaluation dynamique des noms de variables pour créer une variable dont le nom serait une chaîne vide ? Essayons :

$foo = '';
${$foo} = 5;

print_r(get_defined_vars());
//    ...
//    [foo] =>
//    [] => 5
//)

Et bien si, on peut. Constatez au passage que la variable est bien visible dans le get_defined_vars().

Du coup, on peut s'amuser à faire plein de trucs pas très utiles, comme nommer sa varaible $0 par exemple :

echo $0;
// syntax error, unexpected '0' ...

echo ${0};
// ok

Transtyper un objet

Un objet est d'une classe donnée. Chaque classe possède un contexte propre (des attributs) et son propre comportement.

Du coup il ne devrait pas être possible de réutiliser un objet A pour en faire un objet B. Et pourtant ...

class Foo
{

    public $a = 5;
    public $b = 6;

}

class Bar
{

    public $a = 'abc';
    public $b = 'def';

}

$foo = new Foo;
$bar = new Bar;


$object = convert($foo, 'Bar');
print_r($object);
//Bar Object
//(
//    [a] => 5
//    [b] => 6
//)

Comment a t-on fait ? C'est assez simple, il suffit une fois de plus de sérializer notre objet, de modifier une valeur dans la chaîne obtenue, puis de créer un nouvel objet.

function convert($object, $class)
{
    $serialized = serialize($object);

    $className = get_class($object);
    $len = strlen($className);
    $start = $len + strlen($len) + 6;


    $serializedInfos = 'O:' . strlen($class) . ':"' . $class . '":';
    $serializedInfos .= substr($serialized, $start);

    return unserialize($serializedInfos);
}

Vous trouverez de nombreux exemples sur le net.

"Ecouter" les changements d'une variable

Vous connaissez sûrement la fonction JavaScript watch(), très pratique, qui permet d'écouter les changements qui peuvent survenir sur une variable.

Vous me voyez venir : il est possible (à grands frais : lenteurs, charge mémoire, etc !) de faire la même chose en PHP. Je vous aurai prévenu : ne faites pas ça en prod !

L'idée consiste à utiliser une fonction qui va être exécutée à chaque tick, pour observer si la variable que l'on souhaite "écouter" à été modifiée ou non. Si c'est le cas, un simple appel à debug_baktrace() nous permettra de savoir comment cette variable a été modifiée.

$var = 'abc';

function tick()
{
    global $var, $expectedVar;
    if (isset($var)) {
        if (isset($expectedVar) && $var !== $expectedVar) {

            //
            // La variable a été modifiée
            $context = debug_backtrace();
            $where = (isset($context[1]['class']) ? $context[1]['class'] . '::' : '')
                    . $context[1]['function'] . '()';

            printf('la variable $var a été modifiée par %s (fichier %s, ligne %d), et vaut désormais "%s"'
                    , $where, $context[1]['file'], $context[1]['line'], $var);
        }
        $expectedVar = $var;
    }
}

//
// Enregistrons notre pseudo "écouteur"
register_tick_function("tick");
declare(ticks = 1);

Vérifions :

//
// L'heure du test
function foo()
{
    global $var;
    $var = 'def';
}

foo();
//
// Affiche :
//
// la variable $var a été modifiée par foo()
// (fichier /home/data/www/jeff/misc/php-berk/watch-var.php, ligne 39),
// et vaut désormais "def"

C'est tout ?

J'hésite à aller plus loin : on pourrait parler encore de ce qu'il est possible de faire avec les __PHP_Incomplete_Class, de la confusion possible à utiliser des fonctions comme class_alias() (quoique parfois utile), de ce qu'il est affreusement possible de faire avec runkit, dela possibilité de remplacer $_GET par une valeur de notre choix... Mais je crois que ça suffira là :) .

Bref, vous l'aurez compris, si je suis vraiment convaincu que PHP est un super langage, je vois passer beaucoup de mauvais code, de mauvais développeurs et de mauvaises pratiques, qui me font quotidiennement prendre conscience qu'il est possible de faire vraiment n'importe quoi en développement. Lorsque l'on sort des sentiers battus, on doit avoir une bonne raison et comprendre pourquoi on le fait.

PHP est un beau langage, ce n'est pas parce qu'il est "facile" de débuter en PHP qu'il faut en faire n'importe quoi. Heureusement, on peut aussi faire de très belles choses avec ! Et c'est justement ça le job d'un développeur.

Behat - créer des tests solides et efficaces

2013-02-25T00:00:00+00:00

Ca commence à faire déjà quelques temps que j'utilise Behat, et j'ai eu la chance de pouvoir l'utiliser sur différents projets, gros et petits. Je commence donc à avoir un peu plus de recul sur la chose, et à avoir accumulé pas mal de mauvaises pratiques.

Par manque de chance (ou pas ^^), il a fallu que je commence à utiliser Behat sur un projet assez important. C'est donc là que j'ai commencé à faire mes plus grosses erreurs. Je vous propose de voir quelles ont été ces erreurs, et comment éviter de les reproduire.

Utiliser Behat sans faire du Développement piloté par le comportement

C'est évident, mais il faut le dire : Behat n'est qu'un outil, ce qui compte vraiment c'est le Développement piloté par le comportement. Et oui ! Behat n'est ni un outil de test, ni un outil de spécification. Ce n'est "rien de plus" qu'un bonus par rapport à une démarche de travail.

Si on prend Behat, comme il m'est arrivé de le faire, comme simple outil de test, on fonce dans le mur : au bout de plusieurs mois on risque d'avoir substitué Behat à des outils de tests unitaires (PHPUnit, atoum). Behat permet (entre autres) de tester du besoin fonctionnel. Encore faut-il que ce besoin soit exprimé !

Faire du refractoring de code plutôt que du refractoring de phrases

Allez, créons une méthode privée réutilisable dans notre Contexte de définition. Ah, et puis passons la publique le jour où il nous faudra l'utiliser dans un autre Contexte...

Au final on se retrouve avec une application dans l'application. Quand c'est le cas, et ça m'est arrivé, c'est qu'on confond refractoring de code et refractoring de définitions.

Les Contextes de définition servent à traduire des expressions en code source. C'est donc sur ces expressions qu'il faut se focaliser. L'idéal est de réussi à parvenir à découper chaque expression en unités atomiques fondamentales.

Par exemple :

Quand que j'ajoute dans mon panier "Télévision Sony" depuis le catalogue produits

On peut découper cette expression en sous-expressions (étapes)

Etant donné que je suis sur la page du catalogue produit
Quand j'ajoute "Télévision Sony" au panier

Et au final on peut arriver à des expressions atomiques simples :

Etant donné que je suis sur "/catalogue/produits"
Quand je sélectionne "Télévision Sony"
Et je clique "Ajouter au panier"

Vous voyez que là on fait du refractoring de phrases. L'avantage est que c'est hyper simple avec Behat :

<?php
use Behat\Behat\Context\Step;

/**
* @Given /^que je consulte le catalogue produit$/
*/
public function queJeConsulteLeCatalogueProduit()
{
	return array(
	    new Step\Given('que je suis sur la page "/catalogue/produits"')
	);
}

// etc

Il suffit d'utiliser des sous-appels d'étapes dans la définitions.

C'est la seule manière que j'ai trouvé pour se retrouver avec des Contextes de définition simples et surtout stables dans le temps. Sinon on passe notre temps à les réécrire dans leur ensemble.

Par contre ça oblige à avoir plein de définitions, d'où le point suivant :

Utiliser Behat sans couche d'isolation

Au départ, quand on utilise Behat, on a tendance à se créer 2 ou 3 contextes de définition, et puis c'est tout. C'est à mon avis une erreur. Aujourd'hui, je démarre chaque projet qui utilise Behat avec au moins ce découpage :

Contextes de définition métiers
Contexte de définition de vue (web)
Couche d'isolation pour la persistance des données si besoin

Pourquoi ? Tout simplement parce que je me suis rendu compte d'une chose : il arrive souvent de devoir repasser sur des définitions ! Et oui. Et c'est long, laborieux et, disons-le, très très démotivant.

Il faut au moins regrouper les définitions qui concernent l'interface graphique dans un contexte spécifique. Par défaut, si vous utilisez Mink, c'est ce qui fait plus ou moins implicitement lorsque vous utilisez des définitions toute-prêtes de Mink.

Mais que se passera t-il quand le client vous annoncera qu'il sort une appli mobile ? Normalement, appli mobile ou web, aucune spécification ne devrait changer. Par contre, si vous avez mal organisés vos Contextes de définition, vous allez galérer.

Au contraire, si vous regroupez tout ce qui concerne l'UI dans un Contexte de vue, mettons par exemple "View\WebContext.php", il vous suffit simplement de gérer vos sous-contextes :

public function __construct(array $parameters)
{
    if ($parameters['view'] == 'mobile') {
        $this->useContext('view', new View\MobileContext($parameters));
    } else {
        $this->useContext('view', new View\WebContext($parameters));
    }
}

C'est aussi simple que ça : il vous suffit de regrouper tout ce qui concerne l'affichage dans un Contexte spécifique.

Bien entendu, pour les très grosses applications on peut aller plus loin, et d'ailleurs ça devient très vite intéressant : créer un Contexte par page. Par exemple:

$this->useContext('view.catalogue', new View\Web\CatalogueContext($parameters));
$this->useContext('view.panier', new View\Web\PanierContext($parameters));

Ca peut paraître extrémiste, mais dans le cas où votre application est conséquente, c'est très utile. Il faut bien se dire que tout ce travail consiste à solidifier votre architecture de test. De la même manière qu'il faut découper une application en blocs de code (modules), il faut découper les Contextes de définition selon leur... contexte.

Après, il faut prendre la juste mesure des choses, et trouver un découpage adapté :

aux besoins
à la taille du projet
au temps disponible
à la compétence de l'équipe

Exactement comme on le ferait pour un applicatif.

Voilà pour ces quelques retours que je souhaitais partager avec vous. Après, ils sont basés sur mon expérience personnelle, et je serai très curieux de savoir ce que vous en pensez, et surtout comment vous vous avez fait pour gérer la croissance de vos projets utilisant Behat / Cucumber / etc.. N'hésitez pas à partager votre expérience...

dependency.me, pour savoir si vos dépendances composer sont à jour

2013-01-30T00:00:00+00:00

Ça faisait pas mal de temps que l'idée me trottait en tête : un service pour savoir si l'on utilise des dépendances composer à jour ou non.

Tel que je le voyais, je trouvais optimal de pouvoir intégrer une image à notre readme github, exactement comme pour Travis-Ci. Bien entendu, j'ai cherché sur le net ce que je pouvais trouver, et j'ai été assez surpris de trouver pas mal d'outils pour Ruby, Python, NodeJs... mais rien pour les dépendances de PHP avec composer !

Prenant mon courage à deux mains, je me suis donc décidé à coder (très rapidement) http://dependency.me. Il vous suffit de vous connecter avec votre compte Github et de sélectionner les repositories pour lesquels vous souhaitez activer le service, vous aurez en temps (quasi) réel une idée de l'état de vos dépendances, branche par branche :

Bien entendu, il est tout à fait possible d'avoir le détail pour chaque branche :

Le site vous donne pour chaque dépôt le Markdown à copier-coller dans votre readme.md (par exemple) pour afficher une image mise automatiquement à jour selon l'état de vos dépendances :

Bien entendu, le site est Open Source, et est hébergé sur Github.

Toutes les bonnes âmes souhaitant m'aider sont les bienvenues : qu'il s'agisse de signaler les bugs, me faire retours, et pourquoi pas directement à faire évoluer le code concerné. Je pense qu'on peut faire mieux : actuellement le service ne gère pas les dépôts privés par exemple... Et un coup de pouce pour l'anglais serait le bienvenue !

Je suis également preneur de toute remarque, positive ou négative, sur ce service.

Merci à vous !

Doctrine n'est pas un ORM ?

2013-01-04T00:00:00+00:00

Pour bien commencer l'année, je vous propose de troller un peu sur les ORM. Ce qui suit est mon point de vue et n'engage que moi :)

Selon moi, Doctrine 2 représente un tournant majeur dans le monde de PHP, sans doute plus encore que Symfony2 ou Zend Framework 2. Mais j'ai le sentiment que Doctrine n'est pas utilisé à sa juste valeur...

Les ORM classiques

Prenons un peu de recul ; qu'est-ce qu'un ORM ? Traditionnellement, un ORM est une technique pour représenter des enregistrements (et leurs relations) sous forme d'objets. Généralement, on implémente pour cela principalement ces patterns :

Table Data Gateway:
Un objet est une passerelle vers une table: Active Record:
Un objet représente un enregistrement et dispose du comportement nécessaire pour implémenter la logique métier de cet enregistrement: Data Access Object:
Un objet est utilisé pour encapsuler tous les accès vers une source de donnée

C'est ce qui se passe depuis des années, par exemple avec Zend Framework 1 :

<?php
// Table Data Gateway
class TableUsers extends Zend_Db_Table_Abstract {
    // nom de la table et de la base
    protected $_name = 'tbl_users';
    protected $_schema = 'database_name';
}

$table = new TableUsers;
// Rowset : jeu de résultat Traversable
$users = $table->find(1);
?>

<?php
class User extends Zend_Db_Table_Row_Abstract {
    
    public function resetPassword() {
        $this->pwd = md5(uniqid());
    }
    
}

$user = $table->fetchRow(array('id' => 1));
$user->name = 'Jean-François';
$user->resetPassword();
$user->save();
?>

Et les principes SOLID ?

Bon, vous allez me dire que des milliers de projets ont été faits de cette manière, et que ça fonctionne.

Oui, ça fonctionne, mais ça tombe en marche : les coûts de maintenance sont nécessairement élevés, vu que le code ne respecte en rien les principes SOLID. Et oui, notre objet User a plusieurs responsabilités ! Il a la responsabilité de représenter une information, de gérer ses règles métiers, de s'enregistrer... Bref, c'est une God Class (un objet dieu), ce n'est pas de l'orienté objet... Et on fonce dans le mur.

En réalité, un ORM ne peut pas partir du postulat qu'on va représenter des enregistrements par des objets. Non, il doit faire l'inverse !

Je m'explique : le principe de la programmation orientée objet est de manipuler des objets. Il existe différents types d'objet : des agrégats, des objets valeurs... Pour conserver un code propre et maintenable, il ne faut se focaliser que sur le comportement des objets que l'on souhaite utiliser). La manière dont ils sont stockés n'a aucune importance. Vraiment aucune ! Si si; j'insiste : aucune ! Après tout, qu'ils soient stockés sous forme de fichiers, d'une base relationnelle, d'un document... tout cela n'impacte pas le comportement de votre application. Non, ça n'aura un impact que sur la couche basse d'infrastructure de votre application, exclusivement.

L'apport du Domain Driven Design

Le Domain Driven Design est une approche qui tente de focaliser la conduite d'un projet informatique sur le besoin métier exclusivement. Très grossièrement, l'idée est de maximiser la communication entre les équipes techniques et les équipes fonctionnelles pour faciliter l'expression du besoin, puis de calquer le code source sur cette expression de besoin. De cette manière, le code source est en permanence le reflet exact du besoin tel qu'il a été exprimé par les fonctionnels.

Identité et entité

Que nous dit le DDD (Domain Driven Design) ? Que chaque projet manipule des concepts, des noms communs, qui semblent plus importants que les autres. Ce pourra être par exemple les mots "acheteur", "panier" et "produit" dans le cas d'une boutique en ligne.

Quelle est la spécificité de ces mots ? C'est qu'ils représente des choses différentiables les unes des autres de manière certaine : chaque produit est unique, chaque acheteur se distingue des autres acheteurs ; bref, chacune des ces choses est unique. On dira dans ce cas que chaque acheteur, chaque produit, ont une identité propre.

Cette notion d'identité est fondamentale : une identité est unique, et est marquée par des informations d'état de l'objet à laquelle elle s'applique. Par exemple, mon identité pourrait être marquée par mon numéro de sécurité sociale.

En informatique, on a longtemps oublié cette notion d'identité, en utilisant un "identifiant unique" (id) à la place d'une vraie information. Souvent, par exemple, on stocke des informations sur des comptes bancaires dans une table qui a une colonne "id" et une autre "account_number".

C'est une erreur conceptuelle : la colonne "id" n'a aucune valeur fonctionnelle. Ce qui fait l'identité du compte, c'est son numéro de compte. C'est donc la colonne "account_number" qui doit être utilisée pour distinguer un compte d'un autre ! Je conçois qu'il est pratique d'ajouter une colonne "id" pour des raisons d'index et de performance dans une table, mais cet "id" ne doit pas être utilisé dans le code source, puisqu'il ne représente rien en terme de métier (fonctionnellement donc).

<?php
class Account  {
    private $accountNumber = 'xxxxxxxxxx';
}
?>

Ces choses, qui ont une identité, qui sont absolument uniques, sont désignées par le terme d'entités, ou "entity" en anglais dans le monde du Domain Driven Design.

Ah, comme dans Doctrine ? Oui, comme dans Doctrine... Les entités sont des objets qui ont une identité. Simplement, et uniquement.

Dans le DDD, il existe des collections d'entités, que l'on appelle des Agrégats (Aggregate). Oui, toujours comme dans Doctrine :)

Les services

On a vu qu'il existait des concepts importants dans tout projet informatique, concepts représentés par des noms communs.

Il existe d'autres concepts très importants, qui sont eux représentés par des verbes : "acheter", "vendre", "ajouter dans le panier"...

Comment représenter techniquement ces concepts ? En créant, nous dit le DDD, des objets "Services" :

<?php
class ServicePanier {
    
    public function ajouterProduit(ProduitInterface $produit, PanierInterface $panier) {
        // ...
    }
}
?>

Ces objets services sont justement les objets que votre application doit manipuler. Ils constituent le comportement global de votre application. C'est donc eux qui doivent être utilisés dans les Contrôleurs, et eux seuls.

Les dépôts / Repositories

Un projet informatique nécessite souvent de retrouver des informations. Ou plutôt, de retrouver ce qui est désigné fonctionnellement par des noms communs ("acheteur", "panier", "produit"...) et qui possède une identité.

C'est le rôle des dépôts (Repository). Un Repository ne sert qu'à retrouver des informations. Et uniquement selon des critères fonctionnels ; on ne doit pas appeler un repository en passant des tableaux de paramètres... Non, il faut continuer de penser SOLID :

<?php
class RepositoryProduit {
    
    public function listerProduitsDuPanier(PanierInterface $panier) {
        // ...
    }
    
    public function recupererProduit($identite) {
        // ...
    }
}
?>

Attendez, on a aussi le concept de Repository dans le DDD, comme dans Doctrine ?! Et oui ! Vous voyez pourquoi je fais tout ce détour par le DDD pour parler de Doctrine :-)

Et bien plus ...

Il y a encore plein de choses dans le DDD, et j'ai schématisé très grossièrement, mais vous voyez où je veux en venir : Doctrine n'est pas un ORM classique (et ne doit pas être utilisé comme tel), Doctrine est un super outil pour pratiquer l'approche du Domain Driven Design.

Surtout, la démarche de Doctrine n'est pas de mapper une base de données sur des objets. Non, c'est exactement l'inverse : on part des objets (et donc du besoin fonctionnel) pour ensuite les faire persister.

De nombreux concepts du DDD sont présents dans Doctrine. Du coup, pourquoi ne pas penser Domain Driven Design dans vos projets Doctrine ? Qu'il s'agisse de projets Symfony 2, Zend Framework 2 (avec le module Doctrine), ou autre... ?

Et dans ce cas, si les entités sont des concepts fonctionnels importants (un panier, un produit, un acheteur...) qui ont une identité... par pitié ne créez pas d'entités pour vos relations dans Doctrine. Une table intermédiaire n'est pas une entité. D'ailleurs ça n'existe même pas : il n'existe que des relations entre les objets, tout le reste n'a aucun sens en terme de Programmation Orientée Objet.

Et si vous voulez me répondre que créer des entités-relations dans Doctrine reste pratique vu que ça permet de gérer et contrôler plus facilement certaines relations, je vous répondrai que ce n'est pas à PHP de vérifier la cohérence d'une donnée, mais à un SGBD relationnel, et que le SGBD sera bien meilleur vu qu'il est conçu pour ça.

Je crois que ça devrait être la résolution pour ce début d'année 2013 de tous les développeurs PHP : arrêtez de voir les ORM comme des solutions pour manipuler des bases de données.

Voyez plutôt des objets, qui ont des responsabilités, des comportements, parfois même une identité ; et considérez qu'il s'agit plutôt d'un accident quand on doit les persister.

Après tout, si on faisait pas du web, le besoin fonctionnel resterait le même, mais on n'aurait pas besoin de persister nos "acheteurs", "produits" et "paniers". Il suffirait de "livrer", "commander"... Il n'y a que ça qui compte. Pas vrai ? :-)

Automatisation des tâches avec Phing

2012-11-16T00:00:00+00:00

Je ne vais pas vous convaincre qu'un bon développeur est un développeur faignant, c'est à dire qui sait employer suffisamment d'énergie à un moment donner pour en gagner plein par la suite... Non, par contre, pour ceux qui ne l'utilisent pas encore, je vais vous montrer qu'on n'a pas besoin de se compliquer la vie lorsqu'on veut automatiser. On peut même s'organiser !

Phing, c'est quoi ? Les mauvaises langues diront que c'est une version instable de Ant. C'est pas totalement faux, mais c'est loin d'être vrai. Phing, c'est un outil d'automatisation de tâches, mais spécialisé et conçu pour PHP, ce qui change vraiment tout, comme vous allez le voir.

Ce qu'il faut noter également avant de commencer c'est que la documentation est très riche, même si elle n'est pas toujours 100% pratique.

Premiers pas avec Phing

L'installation de phing est simple :

<p>pear channel-discover pear.phing.info</p>
<p>pear install phing/phingdocs</p>

Il suffit ensuite de créer un fichier build.xml, qui va décrire un certain nombre de tâches que l'on souhaite exécuter :

<?xml version="1.0" ?>
<project name="demo" basedir="." default="example">
    <target name="example">
        <echo message="yep, I will create a directory" />
        <mkdir dir="/my/path/" />
    </target>
</project>

Rien de bien compliqué : un projet est composé de n tâches (noeud target), identifiées par un nom (attribut name). Si j'ai besoin de créer le dossier "/my/path", il ne me reste plus qu'à exécuter :

phing

Pas besoin de paramètre : vous voyez l'attribut "default" du noeud "project" : c'est la tâche à lancer par défaut si rien n'est précisé, ce qui est le cas ici.

Un peu plus loin

Bon, ok, c'est rigolo... Mais on peut faire plein de choses : il n'y a aucune limite. Vous avez vu le noeud "mkdir". Il en existe des tas : "echo", mais aussi "phpunit", "ftpdeploy", "gitpull", "phpdepend"... Vous commencez à voir pourquoi utiliser Phing est intéressant : il gravite autour des utils PHP. Il existe enfin le noeud "exec", qui permet de lancer une commande classique.

Un truc bien pratique aussi c'est l'utilisation de variable. Un variable c'est :

un noeud "property" dans votre fichier xml
une déclaration dans un fichier de propriété
un paramètre que vous fournissez lorsque vous lancez phing, avec l'option -D

Chaque variable est réutilisable, il suffit de l'écrire sous la forme ${maVariable}. Soit :

<property name="out" value="/my/path/" />

<target name="prepare">
    <mkdir dir="${out}" />
</target>

Je vais pouvoir écraser la valeur de ${out} en lançant phing :

phing -Dout=/another/path

Je pourrai également importer un fichier de variables :

<!-- file phing.xml -->
<property file="./my.properties"/>
<!-- file my.properties -->
out=/another/path
var2=xxxx
var3=xxxx

Vous trouverez un exemple d'utilisation basique de phing pour générer un rapport minimal de vos sources : CodeSniffer pour vos conventions, PHPUnit pour vos tests, phpMessDetector pour le "smell code", rats pour la sécurité, CopyPasteDetector pour les copier-collers, CodeBrowser pour intégrer tout ça dans un navigateur...

Vous voyez qu'en quelques lignes de xml on se retrouve à ne plus jamais avoir besoin de lancer ces outils à la main. En un mot : on automatise !

Notez qu'il est possible de gérer la dépendance entre différentes tâches :

<target name="t1" depends="t2,t3">
    <!-- (...) -->
</target>

Toute exécution de la tâche t1 lancera les tâches t2 et t3.

Gérer le plan de tâches

Ce qui est chouette avec Phing, c'est qu'on peut faire plein de choses. Et même gérer le déroulement de nos tâches... Comment ? Et bien par exemple avec des si et des alors. C'est possible !

<if>
   <equals arg1="123456" arg2="${valueToCompare}" />
   <then>
       <echo message="${valueToCompare}" est égal à 123456" />
   </then>
   <else>
       <echo message="${valueToCompare}" est différent de 123456" />
   </else>
</if>

Pas mal non ? Bien sûr, on peut faire tout ce qui est classique : égal, différent, plus grand que, elseif...

Un autre moyen de gérer notre déroulement est de demander à phing d'interrompre le processus à moins que... à moins qu'une variable donnée soit vraie. Par exemple :

<fail unless="myVariable" message="On stoppe tout!" />

Structurer, découper et organiser les tâches Phing

Le risque de phing est de se retrouver à devoir copier-coller plein de tâches pour gérer les différents cas . Il existe un moyen simple d'éviter cela : chaque tâche est réutilisable par une autre (un peu à l'image d'une fonction), grâce au noeud "phingCall"

<target name="myTask1">
    <!-- (...) -->
</target>

<target name="myTask2">
    <!-- we call myTask1 -->
    <phingCall target="myTask1" />
</target>

Vous me direz : "Et les variables dans tout ça ? On peut les passer en paramètre ?". Bien sûr :

<target name="myTask1">
    <echo message="ma variable vaut ${myVar}." />
</target>

<target name="myTask2">
    <!-- we call myTask1 -->
    <phingCall target="myTask1">
        <property name="myVar" value="abcd" />
    </phingCall>
</target>

Pas mal non ?

Pour organiser un peu mieux vos tâches, il est également possible de découper votre fichier xml en plusieurs sous fichiers, et de les importer (à la manière d'un require en PHP) :

<import file="./another-file1.xml"/>
<import file="./another-file2.xml"/>

Les tâches ne sont pas exécutées, mais sont disponibles à l'utilisation lorsque l'on fait un phingCall. Comme un "require" donc...

Evaluer du PHP

Ce qui me plaît le plus avec Phing, c'est la possibilité d'évaluer du code PHP directement, sans se compliquer. Oui c'est possible, je vous ai dit que Phing était justement fait pour PHP.

En plus c'est simple : l'évaluation de l'expression est directement mise dans la variable déclarée dans l'attribut "returnProperty" :

<php expression="in_array('curl', get_loaded_extensions())" returnProperty="curlEnabled"/>
<fail unless="curlEnabled" message="You need cUrl to use it" />

Pour finir

Vous le voyez, Phing mérite d'être utilisé. Si vous voulez voir un projet plus complet (et pourquoi pas y contribuer, si si, j'insiste), je vous invite à regarder PHPStarter, qui est un simple automate d'installation de sites (téléchargement des sources du framework utilisé, création des virtual hosts...), et qui synthétise tout ce que je viens de présenter.

Enfin, une petite astuce que m'a donnée mon collègue @gaspaio, et à laquelle je n'avais pas pensé : il suffit de définir comme tâche par défaut une tâche qui affiche de l'aide, et vous voici avec un outil encore plus structuré et simple d'utilisation. C'est ce qui se passe par exemple ici.

Phing n'est pas parfait bien entendu, surtout que c'est finalement assez peu utilisé par rapport à son utilité, même si pas mal de monde l'utilise. D'ailleurs je suis curieux : qui l'utilise au quotidien ? De temps en temps ? Jamais ? Et parmi la dernière catégorie, qui compte l'utiliser maintenant ?

Industrialiser le Contrat dans un projet PHP - les Slides

2012-10-31T00:00:00+00:00

Suite à l'invitation de l'antenne nantaise de l'AFUP pour un rendez-vous PHP (très sympa au passage!), j'ai eu envie de parler de la notion de Contrat dans un projet PHP, et surtout des outils pour s'assurer qu'un contrat, quel qu'il soit, soit respecté.

En effet, mon opinion est que TOUT, absolument tout, est Comportement : une application est un comportement vis-à-vis d'une donnée entrante (requête HTTP) pour fournir une information (réponse HTTP) ; de la même façon une fonction est un comportement vis-à-vis d'une donnée entrante (paramètre) pour fournir une information (valeur de retour) ; etc.

Or, qui dit "comportement", dit "contrat" pour s'assurer que le comportement souhaité est bel et bien appliqué. Je vous propose donc dans ces slides de retrouver différents niveaux de contrat (code source, travail en équipe, besoin fonctionnel...), et à chaque fois différents outils pour s'assurer automatiquement qu'il sont respectés.

Je suis curieux de vos retours sur ces notions de Comportement/Contrat, et aussi curieux de savoir quels outils vous avez l'habitude d'utiliser parmi ceux cités. N'hésitez pas à nous dire ça par commentaire :-)

Industrialiser le contrat dans un projet PHP from halleck45

Design Pattern : pour des règles métiers complexes et/ou changeantes

2012-09-27T00:00:00+00:00

Désolé d'avance pour la longueur de ce billet ; comme ça fait longtemps que mon blog n'a pas été mis à jour, j'en profite pour faire un mini-tutoriel sur un sujet qui me tient à coeur : comment gérer les règles métier, autrement dit les Spécifications fonctionnelles, dans un projet php ?

Je pense qu'on a tous (enfin, on devrait :-) ) avoir en tête les principes SOLID. Ces principes sont étroitement liées à la notion de Complexité Cyclomatique, qui elle, est moins connue.

Derrière ce terme barbare, que vous connaissez bien si vous faites du test unitaire ou si vous utilisez des outils tels que PHPDepend, se cache en réalité quelque chose de simple : si chaque bloc conditionnel de votre projet est un noeud, la complexité cyclomatique est la somme de l'ensemble des chemins empruntable dans votre projet.

De cette manière, le code suivant :

<?php
<p>if c1</p>
    a()
<p>else</p>
    b()

<p>if c2</p>
    c()
<p>else</p>
    d()

a une complexité cyclomatique plus élevée que

<?php
<p>if c1</p>
    a()
<p>else</p>
    b()

Un programme maintenable est en général un programme dont la complexité cyclomatique est la plus faible possible. Et c'est justement l'enjeu de la POO de nous fournir un moyen de concevoir des applications de Complexité cyclomatique faible.

Bon, ça c'est pour comprendre le principe. Après on me dit souvent : "oui, mais moi comment je fais pour gérer mes différents cas possibles si je dois limiter mes if() ?"

Prenez cet exemple :

on a un panier de produits
on ne peut ajouter que des produits en stock
on ne peut ajouter que 20 produits maximum
la règle ci-dessus ne s'applique pas en période de fêtes
les règles ci-dessus sont susceptibles de changer souvent

Générallement on imbrique des if(), du coup on se retrouve avec un arbre applicatif assez large, c'est-à-dire de nombreux chemins possibles. A terme :

on a un risque de changement du code source très important (à chaque fois qu'on ajoute une règle métier)
on gère mal l'ajout de nouvelles règles
très vite l'algorithme devient imbuvable car trop complexe

C'est là qu'intervient la notion Specification (bon, je sais il est temps, l'intro était longue ;-) )

Ce pattern répond à : "Comment gérer mes règles métier dans mon projet". Il est généralement associé au DDD (Domain Driven Design), mais on peut l'appliquer dans n'importe quel contexte qui s'y prête.

L'idée est la suivante : chaque règle métier va être représentée par un objet (une Spécification), à qui l'on va demander si la règle est respectée :

$anyObject = new StdClass;
$specification = new MySpecification;
$isOk = $specification->isSatisfedBy($anyObject);

Là où ça devient puissant, c'est qu'on va pouvoir créer des Spécifications composites pour créer des règles métiers complexes à partir d'un ensemble de règles simples :

$anyObject = new StdClass;
$specification =
    new MySpecification1()
    ->and(new MySpecification2())
    ->and(
        new MySpecification3()
        ->or(new MySpecification4())
    );
;
$isOk = $specification->isSatisfedBy($anyObject);

Vous voyez les avantages : vous pouvez désormais appliquer n'importe quelle règle métier sans avoir à imbriquer plein de if() ; si vous souhaitez tester unitairement une règle, vous pouvez mocker les autres ; vos règles sont facilement évolutives...

Bon concrètement comment ça se passe ? Il faut commencer par créer notre contrat pour le fonctionnement de nos Spécifications :

interface SpecificationInterface {

    public function isSatisfiedBy($object);

    public function andSpec(SpecificationInterface $specification);

    public function orSpec(SpecificationInterface $specification);

    public function notSpec(SpecificationInterface $specification);
}

Ensuite, pour permettre la création de Spécification composite il faut créer une classe abstraite générique pour nos spécifications.

abstract class Specification implements SpecificationInterface {

    public function andSpec(SpecificationInterface $specification) {
        return new AndSpecification($this, $specification);
    }

    public function orSpec(SpecificationInterface $specification) {
        return new OrSpecification($this, $specification);
    }

    public function notSpec(SpecificationInterface $specification) {
        return new NotSpecification($this);
    }

}

Il ne nous reste plus qu'à déterminer le comportement de chacunes de nos structures de contrôle :

Pour le "et":

class AndSpecification extends Specification implements SpecificationInterface {

    private $specification1;
    private $specification2;

    function __construct(SpecificationInterface $specification1, SpecificationInterface $specification2) {
        $this->specification1 = $specification1;
        $this->specification2 = $specification2;
    }

    public function isSatisfiedBy($object) {
        return $this->specification1->isSatisfiedBy($object)
                && $this->specification2->isSatisfiedBy($object);
    }

}

Pour le "ou" :

class OrSpecification extends Specification implements SpecificationInterface {

    private $specification1;
    private $specification2;

    function __construct(SpecificationInterface $specification1, SpecificationInterface $specification2) {
        $this->specification1 = $specification1;
        $this->specification2 = $specification2;
    }

    public function isSatisfiedBy($object) {
        return $this->specification1->isSatisfiedBy($object)
                ||  $this->specification2->isSatisfiedBy($object);
    }
}

Et enfin pour le "non" :

class NotSpecification extends Specification implements SpecificationInterface {

    private $specification;

    public function __construct($specification) {
        $this->specification = $specification;
    }

    public function isSatisfiedBy($object) {
        return !$this->specification->isSatisfiedBy($object);
    }
}

Ca y est, on vient de se créer le minimum vital pour gérer nos règles métiers. Ca, c'est fait une bonne fois pour toute...

Maintenant dans notre projet il suffit de faire hériter nos règles de la classe Specification. Par exemple :

class SpecLePannierPeutEtreRempli extends Specification {
    public function isSatisfiedBy($customer) {
        return(boolean)  $x; // la condition de notre règle ici
    }
}

class SpecOnEstEnPeriodeDeFetes extends Specification {
    public function isSatisfiedBy($customer) {
        return (boolean) $x; // la condition de notre règle ici
    }
}

class SpecLeProduitEstEnStock extends Specification {
    public function isSatisfiedBy($customer) {
        return (boolean) $x; // la condition de notre règle ici
    }
}

Et après il suffit simplement d'utiliser nos règles. Depuis PHP 5.4 on peut utiliser une interface fluide sur nos constructeurs, nous voici donc avec :

$specification =
    new SpecLeProduitEstEnStock()
    ->and(SpecLePannierPeutEtreRempli())
    ->and(
        new SpecIlResteDeLaPlaceDansLePannier()
        ->or(new SpecOnEstEnPeriodeDeFetes())
    );

if($specification->isSatisfedBy(specification)) {
    $panier->ajouterProduit($produit);
} else {
    throw new ArticleNePeutPasEtreMisDansLePannierException('...');
}

Pour synthétiser :

la Spécification permet de gérer des règles métiers
elle permet de combiner n règles métiers dynamiquement
elle facilite la gestion du changement fonctionnel
elle facile la lisibilité des règles
elle vous permet de mocker certaines parties des règles métier
ce n'est pas un remède miracle, mais elle mérite d'être plus utilisé ^^

N'hésitez pas à laisser vos retours sur ce pattern Specification, je suis curieux de savoir s'il est utilisé massivement ou non ? Ou peut-être utilisez-vous déjà un framework de gestion de règles métier, comme ceux qu'il existe dans le monde du Java ?

Behat - Une interface graphique pour rédiger / lister ses fonctionnalités

2012-07-31T00:00:00+00:00

Encore du Behat, mais du neuf cette fois !

Ca fait maintenant pas mal de temps que je planche sur une interface graphique pour utiliser Behat. Pourquoi ? Tout simplement parce que je trouve qu'un client / product owner n'a pas à plonger dans des fichiers textes imbuvables pour rédiger ses spécifications. C'est à mon avis le grand problème de Behat : seuls les développeurs savent l'utiliser.

Pour rappel, Behat permet d'écrire des spécifications / tests de recette dans une syntaxe précise (Gherkin), puis de lancer une recette automatisée de ces spécifications, afin d'en ressortir la liste des fonctionnalités finies / en cours de développement / en échec.

Comme je le disais, j'ai donc travaillé sur une interface graphique pour simplifier la vie des clients et des Products Owners qui souhaitent fournir des spécifications à leurs développeurs. Ca a été un travail intéressant pour pas mal de raisons.

La première de ces raisons est technique : je suis originaire du monde Zend Framework, cet outil a été pour moi l'occassion d'approfondir un peu mes connaissances de Symfony 2.

Une autre raison, sans doute la plus importante, concerne l'ergonomie de ce logiciel. C'est sans doute ce qui m'a pris le plus de temps : réussir à me plonger dans la tête d'un utilisateur non technique pour offrir une expérience utilisateur agréable à n'importe qui, même non développeur. Pas si simple, et peut-être pas si réussi, mais je suis tout de même assez satisfait, même si je me doute que cette appli va pas mal évoluer au fil du temps (j'attends vos retours là-dessus hein :-) ! ).

Enfin, et c'est pas négligeable, c'est mon premier projet open-source ! Certes j'ai déjà contribué par-ci par là à des projets open source, mais je n'avais jamais comme ça jusqu'à maintenant. Ce qui me pousse (et m'a poussé à consacrer pas mal de temps à ce projet) c'est l'envie de voir plus utilisé cet outil (Behat) que je trouve pertinent et adapté à la vie en entreprise, mais malheureusement trop difficile d'accès pour les décideurs. J'espère que cet outil sera un pas de plus pour l'appropriation du BDD par les entreprises.

Quoi qu'il en soit, je rappelle je vous invite à regarder la démo de ce produit pour me dire ce que vous en pensez, et pourquoi pas à contribuer à son amélioration en forkant ce projet et en y ajoutant votre pierre. L'installation est, j'espère, on ne peut plus simple, vu que c'est un simple Bundle pour Symfony 2.

Ce n'est pas la seule tentative, et comme les autres ce n'est pas encore stable. Mais j'espère qu'on arrivera ensemble à faire quelque chose de bien pour proposer un outil digne de ce nom.

J'attends vos retours et idées d'amélioration avec impatience ! :-p

Exploiter PHP 5 - les slides

2012-07-09T00:00:00+00:00

Comme promis à ceux qui étaient présents, voici mes slides de notre rendez-vous du 5 juillet à Orléans, durant lequel on a parlé "outils" et "SPL".

Bien sûr, les slides ne sont pas exhaustifs, mais j'espère avoir réussi à convaincre que PHP était un outil riche, très riche même, et qui mérite largement qu'on aille explorer un peu plus loin la documentation pour éviter de réinventer la roue à chaque développement :-)

Par rapport aux questions qu'il y a pu avoir, voici un lien pour obtenir des informations sur la PSR-0.

Merci à tous ceux qui sont venus, j'ai pris plaisir à faire cette petite présentation ;-)

Exploiter php 5

View more presentations from halleck45.

BDD : produit mal pensé, développement raté

2012-07-05T00:00:00+00:00

Ce billet, non technique, peut surprendre, mais je pense qu'en tant que développeur il faut comprendre un minimum ce que doit être une spécification, surtout si on veut faire du Développement Piloté par le Comportement. Cela fait quelques temps que j'avais en tête de rédiger ce petit billet, alors allons-y :-)

Rédiger des tests d'acceptation / tests de recette n'est certes pas mon métier, mais à force de l'expliquer, de le décrire, bref, à force de tenter de former des gens, je crois que je commencer à comprendre ce qui est si difficile dans ce travail de clarification.

En un mot : la majorité des gens est déformée par son expérience professionnelle passée ; trop habitués aux SFG, aux SFD et autres specs bien verbeuses. Fournir une spécification claire et précise, alors que cela devrait être naturelle et facile, semble au contraire contre intuitif.

Au risque de dire des choses évidentes, lorsqu'on fournit des spécifications à un développeur, ce n'est pas pour lui dire comment il doit faire son travail, mais pour lui décrire ce qu'il souhaite possible pour l'utilisateur. Une application, sans utilisateur pour la manipuler, est une coquille vide.

Un produit, au contraire, place les utilisateurs (qui ont donc un rôle) au centre. Le produit est donc constitué par ce que l'utilisateur peur faire avec (son comportement).

J'insiste, l'application n'a en aucun cas un comportement ; non, c'est la manière dont l'utilisateur interagit avec l'application qui constitue un comportement. On ne dit pas "cette application peut" mais "cette application permet"...

Bref, tout ça pour dire quoi ? Et bien que si la personne qui rédige les spécifications n'a pas cette vision du produit, l'utilisation de tests automatisés (Behat) risque d'être contre productive.

Un peu de concret

Je vais prendre un exemple que j'ai pu voir récemment. Il s'agit de spécifier un import de données dans une application :

Fonctionnalité: pouvoir importer des événement
  Afin d'ajouter des événements dans l'application depuis un fichier d'import
  En tant que Batch
  Je dois pouvoir importer un événement

  Scénario :
    Etant donné que je reçois un fichier d'import valide
    Et que je reçois un événement valide
    En tant que Batch
    Je dois pouvoir importer un événement

Au premier coup d'oeil, le développeur voit que quelque chose cloche dans cette fonctionnalité. En tant que Batch ?! Hum, bizarre, mais oui c'est vrai, c'est bien un batch qui va s'en charger. Je reçois cette spéc, elle me paraît logique, je vais donc l'implémenter.

Oui, mais NON. Si on implémente cette fonctionnalité on fonce dans le mur ! Que se passera t-il ? Tout d'abord on est tributaire du moyen technique utilisé. On pourrait très bien envoyer l'info par pigeon voyageur pour une raison x ou y, et dans ce cas la fonctionnalité deviendrait invalide.

Autre souci : quel bénéfice l'utilisateur tire t-il ? Aucun. Non non, aucun. On se moque que l'application puisse importer de la donnée, ça c'est le moyen. Non, la vrai fonctionnalité c'est de pouvoir intégrer des nouvelles données dans l'application. Et là j'ai un bénéfice pour l'utilisateur. J'ai donc aussitôt proposé ceci :

Fonctionnalité: pouvoir intégrer mes nombreux événements dans l'application
  Afin d'ajouter rapidement plusieurs événements
  En tant qu'utilisateur qui a le droit d'ajouter par lots des événements
  Je dois pouvoir intégrer de nouveaux événements rapidement

  Scénario :
    Etant donné que je fournis une liste d'événements
    Et que ces événements sont valides
    Quand je demande à intégrer cette liste d'événements
    Alors je dois pouvoir constater que ces événements ont bien été ajoutés

Pas grand chose n'est changé, mais tout change. Certes, ce n'est toujours pas parfait, mais désormais, quelque soit le moyen technique utilisé (transfert par pigeons voyageurs, clef USB, FTP...), la spécification de la fonctionnalité restera valable.

Plus encore, le développeur comprend tout de suite le souhait du client. Après c'est son rôle à lui, développeur (ou un ergonome, un architecte, mais surtout pas au fonctionnel) de déterminer comment satisfaire la demande du client. Et là, utiliser Behat a un sens.

Un autre exemple : le taxi. On peut dire que ça consiste à demander de l'argent à un client afin de le transporter dans une voiture. Mais on peut aussi dire qu'il s'agit de transporter une ou plusieurs personnes d'un point A à un point B. Et là ça marche, car en tant que client, mon souhait c'est bel et bien de me rendre quelque part. Et là surtout, la spécification reste valable qu'on parle de taxi moto, de calèche...

Impact sur les dates de livraison du projet

Un autre avantage fondamental est le contrôle que cela offre au propriétaire sur la date de livraison. En découpant le produit en fonctionnalités fondamentales, claires et simples, il devient facile de mettre de côté certaines fonctionnalités pour gagner un peu de temps, quitte à les ajouter plus tard.

Dans l'exemple du taxi, si je monte ma compagnie, je vais pouvoir dire ceci : "On du retard. Nous allons donc laisser de côté la fonctionnalité de paiement. Certes je vais perdre de l'argent un temps, mais au moins je serai visible. Nous ajouterons la fonctionnalité de paiement, qui n'est pas fondamentale pour l'instant, dans 15 jours."

A mon avis, les développeurs doivent en être conscients, au risque sinon d'aboutir à un échec du projet. Pour faire de Développement Piloté par le Comportement, il FAUT un comportement, et donc un produit clair dont le coeur est l'utilisateur.

Après, c'est mon ressenti, je serai curieux de connaître le vôtre sur cette question :-)

Les principales causes d'échec du BDD

2012-05-24T00:00:00+00:00

Bonjour à tous ! Alors bien évidemment, il serait absurde de vouloir lister toute les erreurs possibles, et totalement illusoire de croire que j'en n'en fait plus ; mais je crois pouvoir donner quelques exemples de ce qu'il faut éviter à tout prix lorsque l'on fait du développement piloté par le comportement avec Behat.

Petit rappel : Behat, c'est quoi ? En un mot, c'est un outil qui va vous permettre de pratiquer du BDD (Behavior Driven Development) en PHP. En d'autres mots, il va vous permettre de tester automatiquement si le développement d'un produit correspond aux spécifications qu'en a donné le client. Vous trouverez une description beaucoup plus complète ici.

Bref, c'est génial, c'est simple à utiliser... mais c'est extrêmement difficile à utiliser correctement. Et c'est catastrophique si c'est mal mal utilisé ! Pourquoi ?

Behat a deux côtés : un côté fonctionnel (rédacteur), rédigé avec la syntaxe de Gherkin, un côté "développeur", en PHP.

De ce que je vois, le plus souvent le fonctionnel (au choix) :

ne dispose pas du temps nécessaire pour se consacrer à la rédaction des tests d'acceptation (fonctionnalité)
n'a pas une vision assez clair de son produit pour pouvoir le découper fonctionnellement
confond interface (ergonomie, disposition...) et comportement de l'application
confond contrôle sur les données et test sur le comportement (trèèès souvent!)
ou, plus rarement, confond socle technique et fonctionnalité

De ce que je constate, le développeur (au choix) :

est obligé de se substituer au client dans la rédaction des tests, ce qui n'est pas son métier (pas simple donc)
n'arrive pas à s'abstraire du technique
se focalise sur le cheminement (comment arriver là?) et l'emplacement dans l'application
a tendance à écrire du code PHP plutôt que de réutiliser des étapes existantes

Bon, le constant est sévère, mais je généralise bien sûr. Cependant il est très difficile d'échapper à ça.

Je passe aux exemples, tirés d'un code vu ce matin même.

Décrire une fonctionnalité : pas si simple

Prenons ce bout de fonctionnalité que j'ai reçu comme spécification :

Feature: access to the task's page from a list of tasks
In order to see a task
As a logged in user
I need to open a task

Background:
Given I am logged in user

Scenario Outline:
When I press "Find a task"
And I fill in "Task reference" with "<reference>"
And I press "Search"
Then I should be on "index/task/id/<id>"

Examples:
| reference   | id  |
| task1       | 1   |
| task2       | 2   |

Bon, ça marche. Mais quand on y regarde plus près :

on se consacre plus aux étapes permettant d'accéder aux conditions du scénario qu'au scénario lui-même
si la structure de la page change, le test est obsolète
on ne teste pas le comportement, mais la donnée. Si la donnée change, le test est obsolète
si l'url change (rewriting, etc), le test est obsolète

Bref, le test va rapidement devenir obsolète.

Il est difficile dans ce cas de voir comment s'abstraire des données (liaison id et task). Après réflexion, on peut suggérer d'évoluer vers ceci :

Feature: access to the task's page from a list of tasks
In order to see a task
As a logged in user
I need to open an task's page from a list

Background:
Given I am logged in user

Scenario Outline:
Given I see a list of tasks, including the task "<reference>"
When I follow "<reference>"
Then I should be on the Task's page
And I should see the task "<reference>"

Examples:
| reference  |
| task1      |
| task2      |

On a donc opéré des modifications afin de rendre le test indépendant du jeu de données ou de l'interface de l'application.

Ce que je dis souvent, c'est que, en théorie, un test de comportement est valide quelque soit le support : que l'on passe d'un site web à une application mobile, le changement de support ne change pas la fonctionnalité ou les scénarios ! Ca ne change que leur implémentation.

On pourra certainement trouver encore à redire, mais la fonctionnalité, telle qu'elle est décrite, est désormais valable quelque soit son implémentation technique. Seul son comportement est ici spécifié. Elle a donc une forte probabilité d'être viable et pertinente dans le temps.

Implémenter une définition de fonctionnalité : pas plus facile

On a vu un exemple de fonctionnalité à risque. Passons de l'autre côté et mettons-nous du point de vue du développeur. De la même façon, voici une implémentation possible :

Note : en l’occurrence, la liste des tâches n'est possible dans l'application qu'après avoir effectué une recherche.

/**
 * @Given /^I see a list of tasks, including the task "([^"]*)"$/
 */
public function iSeeAListOfTasksIncludingTheTask($reference)
{
    $session = $this->getMainContext()->getSubcontext('mink')->getSession();
    $page = $session->getPage();

    $session->visit('/task');

    // Find the task in the search engine
    $page->find('css', '.ipt-task-search')->setValue($reference);
    $page->find('css', '.button-search')->press();

    if ($session->getCurrentUrl() != "/task/{$reference}") {
        throw new AssertException("We cannot find the task {$reference} with the search engine");
    }
}

On constate différente choses :

Que de code ! C'est long à écrire
Que de code ! Et pas réutilisable en plus !
Que de code ! Et qu'est-ce qui se passe si l'interface HTML change ?
On ne comprend pas ce qui se passe au premier coup d'oeil

L'implémentation fonctionne, mais est peu viable dans le temps, et surtout on a perdu du temps pour l'écrire (c'est fastidieux de devoir manipuler le navigateur à la main).

Là où Behat est fort, c'est qu'il nous permet, en PHP, de faire comme si on écrivait des étapes de scénario "à la main". Ca fait gagner un temps monstre et permet de réutiliser les définitions existantes :

/**
* @Given /^I see a list of tasks, including the task "([^"]*)"$/
*/
public function iSeeAListOfTasksIncludingTheTask($reference) {
    return array(
        new Given('I am on "/"')
        , new When(sprintf('I fill "Task reference" with "%s"', $reference))
        , new When('I press "Search"')
    );
}

Pour s'aider, le développeur peut s'appuyer (si tout se passe bien) sur la personne qui a rédigé le scénario, qui l'aidera à découper sa définition en différentes étapes.

Attention, contrairement au scénario Gherkin, ce code peut être amené parfois à évoluer. Par exemple, si on ajoute un scénario pour la recherche de tâche, avec cette étape :

When I search the task ""

On pourra dès lors écrire :

/**
* @Given /^I search the task "([^"]*)"$/
*/
public function iSearchTheTask($reference) {
    return array(
        new Given('I am on "/"')
        , new When(sprintf('I fill "Task reference" with "%s"', $reference))
        , new When('I press "Search"')
    );
}

/**
* @Given /^I see a list of tasks, including the task "([^"]*)"$/
*/
public function iSeeAListOfTasksIncludingTheTask($reference) {
    return array(
        new When(sprintf('I search the task "%s"', $reference))
    );
}

Le développeur peut donc, sans architecture ou code complexe, mais simplement en utilisant les objets Etapes fournis par Behat, organiser ses définitions de façon à les rendre réutilisables.

Le mot de la fin

Bref, ça semble évident, mais quand on fait du BDD... et bien il faut se focaliser le le Comportement. Ce n'est pas facile, et contre intuitif pour beaucoup de monde. Toutefois, le rédacteur du test peut s'aider de la structure de la fonctionnalité (comment la décrire, qui y participe, quels en sont les bénéfices, puis quels cas d'utilisation je peux en donner).

En d'autres mots, le "rédacteur" ne doit pas s'appuyer sur ce qu'il connaît de son application (emplacement, design...), mais sur la vision du produit (comment ça se passe ? Avec quel gain pour l'utilisateur ?). En clair :

Le rédacteur ne doit pas s'appuyer sur ce qu'il connaît de son application mais sur la vision du produit

Le développeur, lui, doit prendre l'habitude de ne pas se lancer tête baissée dans le code, au risque de consacrer trop de temps et d'énergie à l'utilisation de Behat. Certes il doit écrire ce code, mais il ne code plus pour interagir avec un autre code (comme lorsqu'il le fait pour un test unitaire par exemple), mais pour interagir avec un produit. En clair :

Le développeur n'interagit plus avec du code mais avec un produit

Ceci dit, félicitations d'avoir lu ce billet jusqu'au bout :-) .

Je ne prétend pas avoir le recul suffisant, mais je crois que ces constats s'appliquent généralement. C'est le cas pour vous aussi ? Vous avez vu d'autres écueils courants ? Ou au contraire, pour vous tout a roulé tout de suite ?

Mémento Industrialisation PHP : Outils et bonnes pratiques

2012-05-22T00:00:00+00:00

Certains d'entre-vous sont déjà au courant, voire l'ont déjà entre les mains, mais je planche depuis déjà quelques temps sur un mémento dédié aux outils PHP et aux pratiques liées à l'industrialisation.

Mais comme l'a bien dit Raphaël Hertzog il y a peu quand il parlait de son mémento Git, écrire un mémento de quelques pages ce n'est pas si facile !

Au départ il y a une volonté : faire une petite synthèse des principaux outils utiles et pratiques quand on souhaite "industrialiser" certains aspects d'un développement afin d'en faciliter la qualité : tests unitaires, de comportement, outils d'audit de code, de versionning...

Ensuite... Ensuite, et bien je me suis rendu compte qu'il était extrêmement difficile de faire un travail de synthèse suffisant pour faire tenir toutes ces informations en quelques pages (13 pages exactement). Et même très difficile ! Il a fallu condenser, relire, supprimer, re-condenser l'information.

Au final, plus qu'un simple mémento "cheat-sheet", j'espère avoir réussi à présenter un tour d'horizon des outils et pratiques pour ceux et celles qui souhaiteraient aller plus loin dans leurs développements PHP, qu'il s'agisse de faciliter le travail en équipe, la maintenabilité ou la fiabilité.

L'idée n'était surtout pas de faire la liste des outils disponibles et de les comparer. Au contraire; j'ai essayé de créer une continuité entre les outils présentés, afin d'en avoir une vision d'ensemble, et surtout afin de tirer parti de chacune de leur spécificité. Et j'espère avoir réussi :-) !

Chaque outil est présenté avec sa description, sa procédure d'installation, ses usages, et généralement des petites astuces bonnes à avoir sous les yeux.

Ceux qui me connaissent savent que la qualité logicielle me tient beaucoup à cœur. J'espère que ce mémento saura vous aider à découvrir, ou redécouvrir, quelques uns des outils utiles à mettre en place et conserver cette qualité dans vos projets PHP.

Je vais faire mon commercial, mais le mémento est en pré-vente sur Amazon au prix de 9,90 €. Comme tous les mémentos Eyrolles, il est plastifié et théoriquement "indéchirable", vous pouvez l'amener partout. Attention, le mémento a la même couleur que le très bon mémento PHP et SQL. A ne pas confondre donc...

Pour finir, si vous avez l'occasion de l'avoir entre vos mains n'hésitez surtout pas à me faire un retour : ce qui va, ce qui manque, ce qui est en trop... J'attends avec impatience vos avis !

Au passage, encore merci à Xavier Lacot et à Armel Fauveau, qui m'ont laaaaargement aidé et relu ;-)

Streams - Flux personnalisés et filtres en PHP

2012-04-13T00:00:00+00:00

Lorsque vous faites un fopen(), ou toute autre fonction équivalente, PHP vous retourne une ressource, sous forme d'un flux. Il existe différent types de flux en PHP :

<p>fopen('file://...') // fichier</p>
<p>fopen('php://temp') // fichier temporaire</p>
<p>fopen('php://memory') // en mémoire</p>
<p>fopen('php://stdout') // sortie de la console</p>
<p>etc.</p>

Bref, il y en a pas mal...

Mais on oublie souvent qu'on peut aussi ajouter ses propres types de flux. Par exemple je vais créer un type de flux "twitter" pour lire mes tweets :

$fp = fopen("twitter://@halleck45", "r");
if ($fp) {
    while (!feof($fp)) {
        var_dump(fgets($fp, 140));
    }
}

Création d'un nouveau type de flux

C'est relativement facile : il suffit d'ajouter un nouveau gestionnaire de flux, c'est à dire une classe qui respecte le prototype StreamWrapper.

stream_wrapper_register("twitter", "TwitterStream");

Plutôt que d'implémenter toutes les méthodes de ce prototype, concentrons nous sur le principal, et créons 4 méthodes :

stream_open(), qui va ouvrir notre flux
stream_close(), pour le fermer
stream_read($size) qui va être appelée à chaque lecture dans le flux
stream_eof(), pour indiquer qu'on arrive à la fin

Pour simplifier l'exemple, le flux Twitter est en lecture seule. Pour la même raison, on va rapatrier tous les tweets d'un coup et les stocker dans notre objet dans un tableau.

Pour démarrer, créons une petite fonction qui va aller chercher les tweets d'un utilisateur donné :

ini_set('allow_url_fopen', 1);
define('TWITTER_PWD', 'votre-mot-de-passe');
define('TWITTER_LOGIN', 'votre-login');

function example_stream_twitter_fetch($username) {
    $ch = curl_init();
    $url = sprintf('http://api.twitter.com/1/statuses/user_timeline.json?screen_name=%s&include_entities=true&include_rts=true&count=20', $username);
    curl_setopt($ch, CURLOPT_URL,$url);
    curl_setopt($ch, CURLOPT_USERPWD, TWITTER_LOGIN . ':' . TWITTER_PWD);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $result = curl_exec($ch);
    curl_close($ch);
    return $result ? json_decode($result) : null;
}

Maintenant le gestionnaire de flux :

class TwitterStream {

    protected $_json;
    protected $_offset = 0;

    public function stream_open($path, $mode, $options, &$opened_path) {

        //
        // Read only !
        if ($mode != 'r') {
            trigger_error("Unsupported mode", E_USER_WARNING);
            return false;
        }

        //
        // Calling example_stream_twitter_fetch() in order to fetch data from twitter
        $result = false;
        if (preg_match('!@(\w*)!', $path, $match)) {
            $result = example_stream_twitter_fetch($match[1]);
        }

        if (!$result) {
            if (($options & STREAM_REPORT_ERRORS)) {
                trigger_error("Username not found", E_USER_WARNING);
            }
            return false;
        }

        $this->_json = $result;
        return (bool) $result;
    }

    public function stream_close() {
        $this->_json = null;
        return true;
    }

    public function stream_read($count) {
        return $this->_json[$this->_offset++]->text;
    }

    public function stream_eof() {
        return $this->_offset >= sizeof($this->_json);
    }

}

Rien de bien compliqué. Il faut juste bien penser à lancer un warning en cas de problème...

Et ça suffit :

stream_wrapper_register("twitter", "TwitterStream");

$fp = fopen("twitter://@halleck45", "r", STREAM_REPORT_ERRORS);
if ($fp) {
    while (!feof($fp)) {
        var_dump(fgets($fp, 140));
    }
}

Pratique non ?

Bon, bien sûr l'exemple est trivial, ne serait-ce parce que les tweets peuvent dépasser les 140 caractères à cause des liens ; mais je pense que vous aurez compris l'intérêt de la chose :-)

Appliquer des fitres sur des flux

Autre "truc pratique" assez peu utilisé mais vraiment utile : on peut appliquer des filtre sur des flux, même sur les flux "natifs".

Par exemple, je veux convertir le texte que j'écris dans un fichier en l33t, en utilisant cette fonction :

function l33t($string) {
    return str_replace(array('l', 'e', 't'), array('1', '3', '7'), $string);
}

Nous allons enregistrer le filtre "l33t" et l'associer à la classe "l33t_filter' :

stream_filter_register("l33t", "l33t_filter");

Cette classe l33t_filter doit hériter de la classe native php_user_filter :

class l33t_filter extends php_user_filter {

    function filter($in, $out, &$consumed, $closing) {
        
        while ($bucket = stream_bucket_make_writeable($in)) {
            //
            // leet -> l33t
            $bucket->data = l33t($bucket->data);
            $consumed += $bucket->datalen;
            stream_bucket_append($out, $bucket);
        }
        // on retournerait PSFS_ERR_FATAL en cas d'erreur bloquante
        return PSFS_PASS_ON;
    }
}

On peut par exemple imaginer appliquer des filtres de cryptage, de contrôle...

Alors, convaincu ? :-) Avez-vous déjà utilisé votre propres flux ou filtre de flux en PHP ?

Behat : liens et ressources utiles

2012-04-02T00:00:00+00:00

Ce billet fait suite à :

Pour ce dernier billet du tutoriel Behat, j'avais prévu de parler la mise en place de Behat au sein d'une plate-forme d'intégration continue (PIC). Je me suis rendu compte qu'il y avait déjà quelques bons tutos là dessus. Je vous propose donc plutôt une petite liste de liens que je vous invite à découvrir pour aller plus loin avec Behat.

Contextes prêts à l'usage

Le BehatCH, développé par PMSIpilot est ce que j'ai trouvé de plus complet pour apporter des bonnes bases à un projet. regardez surtout le BrowserContext et le TableContext, qui permettent d'écrire des choses comme :

<p>I wait "5" seconds until I see "element"</p>
<p>I should see "5" elements</p>
<p>The 1st column of the 1st row in the "table" table should contain "Lorem"</p>

Vous pouvez également utiliser les Extra Contexts mis à disposition par l'auteur de Behat, qui sont eux moins axés outils mais plus à mon sens comme des composants pour créer d'autres outils.

Blogs intéressants sur Behat

Pour les blogs francophones, je vous recommande les blog de PMSIpilot et de knpLabs (bon, ok c'est plus souvent en anglais qu'en français :-) ...).

Pour les anglohpones, vous pouvez jeter un oeil sur le blog de Shashikant Jagtap, de l'auteur même de Behat, ou aussi sur craftItOnline

Plate-forme d'intégration continue et Behat

Avant toute chose sachez que Behat permet très facilement de générer des rapports en XML, au format JUnit :

behat -f junit --out ./report

Voici un tutoriel pour installer Behat sur Jenkins, et en voici un autre pour Hudson

Bonne lecture ! :-) N'hésitez pas si vous avez des ressources à suggérer à les mettre en commentaire

Behat - jour 4 : API Mink, Sous-contextes et Hooks

2012-03-29T00:00:00+00:00

Voici l'avant dernier billet de la série sur la prise en main de Behat. Pour rappel, on a vu :

Allons un peu plus loin :-)

Sortir des sentiers battus : l'API de Mink

Assez rapidement on se retrouve à devoir gérer des cas particuliers, par exemple :

Quand je suis à découvert
<p>Alors le bouton "retirer de l'argent" doit être désactivé

On sort des cas classiques de Mink. Comment faire ?

La solution consiste à développer nous même ce comportement :

/**
 * @Then /^le bouton "([^"]*)" doit être désactivé$/
 */
public function leBoutonDoitEtreDesactive($button)
{
    throw new PendingException();
}

On commence par récupérer notre page à partir de l'objet de session:

$page = $this->getSession()->getPage();

Ensuite on va récupérer l'élément html concerné. Il existe différente manière de faire cela. Le plus simple dans notre cas consiste à passer par un des raccourcis de sélection de Mink : findButton(libellé | id | nom)...

$element = $page->findButton($button);

Si l'élément html n'est pas trouvé, on va lever une exception, sinon on va continuer en faisant une assertion simple : l'élément doit avoir l'attribut "disabled". Ce qui donne au final :

$page = $this->getSession()->getPage();
$element = $page->findButton($button);

if (null === $element) {
    throw new Behat\Mink\Exception\ElementNotFoundException(
        $this->getSession(), 'element', 'css', $button
    );
}

<p>assertEquals(true, $element->hasAttribute('disabled'));

Au passage, remarquez qu'il s'agit d'une assertion classique de PHPUnit, mais en mode fonction. Pour cela on aura bien entendu ajouté au début de notre fichier :

require_once 'PHPUnit/Autoload.php';
<p>require_once 'PHPUnit/Framework/Assert/Functions.php';

Je vous laisse regarder la documentation ou la feuille d'astuce pour Mink pour plus d'informations. Sachez juste qu'on peut faire pas mal de chose, comme exécuter du JavaScript par exemple (avec $session->evaluateScript() ) ;-) ...

Organiser son code

Jusqu'ici on a systématiquement mis notre code dans le fichier FeatureContext.php. C'est pas l'idéal : on va très vite se retrouver avec un fichier énorme et imbuvable. Il nous suffit de découper notre contexte en sous-contextes. Tout se fait dans le constructeur du contexte principal :

class FeatureContext extends BehatContext
{

    public function __construct(array $parameters) {
        $this->useContext('mink', new MinkContext($parameters));
        $this->useContext('example1', new MyExample1Context($parameters));
    }

On a donc isolé le contexte de Mink pour en faire un sous-contexte, et on a plus ajouté le nôtre ('example1').

L'utilisation des contextes est assez simple. Chaque sous-contexte a un nom (ici 'mink' et 'behat'), que l'on peut utiliser pour les récupérer :

getMainContext(): Récupérer le contexte principal
getSubContext('nom'): Récupérer un sous contexte
getSubcontexts(): Récupérer la liste des tous les sous-contextes

Par exemple :

$session = $this->getMainContext()->getSubContext('mink')->getSession();

On va donc créer le fichier MyExample1Context.php :

class MyExample1Context extends BehatContext
{

    /**
     * @Then /^le bouton "([^"]*)" doit être désactivé$/
     */
    public function leBoutonDoitEtreDesactive($button) {
        $session = $this->getMainContext()->getSubContext('mink')->getSession();
        $page = $session->getPage();
        $element = $page->findButton($button);

        if (null === $element) {
            throw new Behat\Mink\Exception\ElementNotFoundException(
                    $this->getSession(), 'element', 'css', $button
            );
        }

        assertEquals(true, $element->hasAttribute('disabled'));
    }

}

Et voilà, nous voici avec un code découpé et des fichiers plus spécialisés.

Les hooks de Behat

Comme pour les tests unitaires, il est possible d'exécuter du code à certaines phases du déroulement du tests. Il suffit d'utiliser des annotations :

/**
 * @BeforeSuite
 */
<p>public static function prepare(SuiteEvent $event)</p>
{
    // (...)
}

les déclencheurs disponibles sont :

BeforeSuite
AfterSuite
BeforeFeature
AfterFeature
BeforeScenario
AfterScenario
BeforeStep
AfterStep
AfterStep

Un dessin valant mieux qu'un long discours, le plus simple est de regarder ici.

Conclusion

On voit qu'on a quand même peu de limites avec Mink et Behat. Bien plus, on peut même l'intégrer à une PIC (Jenkins, Hudson...). C'est d'ailleurs ce qu'on verra dans le prochain billet, qui sera le dernier de la série ^^

=> Juste par curiosité : j'utilise exclusivement Sahi pour mes tests. Beaucoup de monde utilise Selenium ? C'est mieux ? Vous avez des avis ?

Behat – jour 3 : Tester une application web avec Mink

2012-03-19T00:00:00+00:00

On a vu précédemment ce qu'était Behat et comment tester une application simple en php avec Behat.

Maintenant allons plus loin et voyons comment tester une application web (à la quelle on accède par un navigateur). Et oui c'est possible ! :-)

Behat et ... Mink

On l'a dit : Behat permet de tester un produit. Ceci dit, il est rare qu'un client vous demande une application en ligne de commande ; le plus souvent le produit en question va être constitué de pages web. Qu'à cela ne tienne, Behat est très fortement lié à un autre outil : Mink.

Mink c'est quoi ? Et bien Mink va vous permettre :

ou bien de simuler un navigateur pour interagir avec votre application (produit)
ou bien de piloter un vrai navigateur (Firefox, Chrome...) pour interagir avec le produit

Voyons comment le lancer en mode "simulation" dans un premier temps.

Application de test

Pour vous éviter de perdre du temps, je vous propose de télécharger une petite page web toute simple qui va correspondre à notre produit de test :

une seule page pour consulter notre compte et ajouter/retirer des sous
un formulaire de connexion (pas de mot de passe)
les informations sont stockées en session

Ce qui donne ça :

Pour télécharger l'application exemple, ça se passe ici : behat-jour3-appli-web.zip (15 Ko).

Notre produit web

N'oublions pas que le client (product owner) reste le maître de son produit. Il nous fournit donc un fichier de fonctionnalités pour décrire son produit.

Remarque : la fonctionnalité est décrite en anglais ; bien que très actif, utiliser behat et mink en français reste aujourd'hui très aventureux à mon goût, ne serait-ce qu'à cause des nombreux apostrophes présents dans notre langue qui posent des difficultés.

Fichier bank.feature :

<p>Feature: Manage a bank account</p>
  In order to manage my account
  As a logged in user
  I need to be able to add or take mon ey on my account

  Background:
    And I am logged in as "jeanfrancois"
    And I have "50" euro
    And I am on "/"

  Scenario: Check my bank account
    Then I should see "You have 50 euro on your account"

  Scenario Outline: Add money
    Given I have "<initialAmount>" euro
    When I select "<operation>" from "Operation"
    And I fill in "Amount" with "<amount>"
    And I press "Go"
    Then I should see "You have <finalAmount> euro on your account"

    Examples:
    | operation   | initialAmount | amount    | finalAmount   |
    | Add money   | 50            | 10        | 60            |
    | Add money   | 50            | 20        | 70            |
    | Add money   | 50            | 5         | 55            |
    | Add money   | 50            | 0         | 50            |
    | Take money  | 50            | 10        | 40            |
    | Take money  | 50            | 20        | 30            |
    | Take money  | 50            | 30        | 20            |

  Scenario: Overdrafts are not allowed
    Given I have "50" euro
    When I select "Take money" from "Operation"
    And I fill in "Amount" with "60"
    And I press "Go"
    Then I should see "You have 50 euro on your account"
    And I should see "Overdrafts are not allowed"

Nous voilà prêts :-) Notez que les expressions utilisées (I fill in "xxx" with "xx", etc) ne sont pas anodines, bien au contraire. On va le voir par la suite.

Installer Mink

Rien de plus simple :

sudo pear install behat/mink-beta

Maintenant on va "dire" à Behat que l'on souhaite utiliser Mink pour nos tests. Ouvrez le fichier bootstrap/FeatureContext.php, et remplacez

class FeatureContext extends BehatContext {

par

require_once 'mink/autoload.php';
class FeatureContext extends Behat\Mink\Behat\Context\MinkContext

C'est là que la magie s'opère : Mink dispose déjà de nombreuses expressions disponibles pour tester notre produit web ! On va pouvoir le confirmer en faisant un :

behat -dl --lang=en

Il ne nous reste plus qu'à préparer un petit fichier de configuration, nommé feature/behat.yml, qui sera automatiquement lu par behat :

<p>default:</p>
  context:
    parameters:
      base_url: http://localhost/mettez/ici/l/adresse/a/tester

Ici nous indiquons simpelment à Mink la racine de base de notre application, pour éviter de la répéter dans chacun de nos tests.

Tester le produit : Mink crée du sens

Il est temps de se lancer et d'exécuter en ligne de commande :

behat

Miracle ^^ : la majorité des expressions utilisées par notre product owner possède déjà un sens. En tant que développeur, il n'y a que deux expressions pour lesquelles je dois donner du sens :

Quand le product owner spécifie 'I should see "content"', Mink va tout seul faire le lien avec l'assertion "le contenu de la page doit comporter le texte "content".

Mais bien mieux encore : les champs de mes formulaires ne sont pas reconnus par leur nom ou leur identifiant (name ou id). Non non, le product owner n'en n'a rien à faire de la structure interne d'une page web ; ce qu'il veut c'est un produit qui à l'écran correspond à ses attentes. Les éléments de formulaires sont reconnus par leur libellé (label).

le product owner n'en a rien à faire de la structure interne d'une page web ; ce qu'il veut c'est un produit qui, à l'écran, correspond à ses attentes

Bien sûr, Mink est permissif et on peut tout même cibler un lien, bouton, élément de formulaire... par son identifiant ou son nom... peu importe :-)

Vous trouverez la liste des expressions de base de Mink ici.

Donner son sens aux expressions non définies

Il nous reste donc deux expressions qui n'ont actuellement pas de signification : "Given I am logged in as ..." et "I have x euro". A nous, développeurs, de les définir dans features/bootstrap/FeatureContext.php.

Attention, il y a là un énorme piège. Je l'ai vu à chaque fois, le premier réflexe d'un développeur va être de créer un lien entre le code source de l'application et le code disponible dans le fichier FeatureContext.php. Par exemple en créer une instance d'une Zend_Application comme on le ferait pour des tests unitaires d'une application Zend... C'est la dernière chose à faire !

Non, si le product owner veut un produit web, si Mink nous permet de tester un produit web, continuons de tester un produit web uniquement, et laissons le code de côté :-p .

Le product owner nous dit qu'il est un utilisateur connecté ("I am logged in as..."). Connectons l'utilisateur au sein de l'application :

/**
 * @Given /^I am logged in as "([^"]*)"$/
 */
public function iAmLoggedInAs($username)
{
    return array(
        new Step\Given('I go to "login.php"')
        ,new Step\When("I fill in \"My name\" with \"$username\"")
        ,new Step\When('I press "Login"')
    );
}

Pensez à ajouter au début du fichier :

use Behat\Behat\Context\Step;

Comme vous le voyez, on réutilise les étapes utilisables directement dans nos scénarios. Dans 99% des cas cela suffit. Ce sont les mêmes étapes que le product owner pourrait utiliser dans un fichier de fonctionnalité classique.

Ce qui reviendrait à écrire :

Given I go to "login.php"
When I fill in "My name" with "jeanfrancois"
When I press "Login"

On fait la même chose pour donner du sens à 'I have "50" euro' :

/**
 * @Given /^I have "([^"]*)" euro$/
 */
public function iHaveEuro($balance) {
    return array(
        new Step\Given('I go to "/"')
        , new Step\When("I fill in \"New balance\" with \"$balance\"")
        , new Step\When('I press "Reset"')
    );
}

Ca y est, on est bons :

Le système de test est fiable car il n'est pas assujetti à des modifications de notre code, mais seulement aux modifications de notre produit. Si l'application venait à ne plus correspondre aux souhaits du product owner, celui-ci en serait immédiatement averti.

Un vrai navigateur, avec du vrai javascript

C'est beau, mais pas très réaliste : quid des applications riches ? Que faire si on a du Javascript et de l'ajax de tous les côtés ?

Et bien on va continuer d'utiliser Mink, mais cette fois-ci on va piloter un vrai navigateur. Mink permet de piloter n'importe quel navigateur en utilisant le driver de notre choix : Sahi ou Selenium (1 ou 2).

Ayant eu de nombreuses déconvenues avec Selenium par le passé, et n'ayant pas encore eu de souci majeur à ce jour avec Sahi, j'ai une nette préférence pour Sahi. Installons le ensemble :

L'instalaltion est simple. Téléchargez Sahi depuis http://sourceforge.net/projects/sahi/files/ et exécutez le :

wget http://sourceforge.net/projects/sahi/files/latest/download?source=files
<p>java -jar sahi_v35_20110719.jar</p>

Cliquez sur suivant, suivant... c'est pas moi qui vais vous apprendre un installer quelque chose :-D.

Lancez ensuite Sahi (placez vous bien dans le dossier spécifié pour éviter les ennuis) :

cd dossier/installation/bin/</p>
./sahi.sh &

Lier des fonctionnalités à un vrai navigateur

Pour utiliser un vrai navigateur à la place de l'émulateur, il suffit d'utiliser le tag @javascript devant le scénario qui le nécessite:

@javascript
  Scenario: ...

ou devant la fonctionnalité toute entière :

@javascript
<p>Feature: ...</p>

Ensuite on lance behat comme d'habitude :

behat

Vous devriez à ce stade voir se lancer votre navigateur et voir les pages changer toutes seules : les champs se remplissent, ça clique... Bref, ça marche !

Alors bien sûr vous allez me dire : c'est lent ! Et alors ? Ca reste toujours infiniment plus rapide que de tester tout ça à la main, et surtout c'est fiable : si une ligne est rouge, le produit n'est pas livrable ; mais si tout est vert, alors c'est que vous êtes dans les clous et que vous avez bien fait votre boulot. De plus le gain de temps de test manuel et d'aller et retours avec le product owner est considérable. Là c'est vraiment le client qui est le maître de son produit.

Configurer le navigateur

Il nous reste deux ou trois petites choses à voir. En effet, figurez vous que c'est firefox qui est lancé pour les tests, mais que moi je préfererai que ce soit chrome. Pas de problème, modifions le fichier behat.yml :

default:
  context:
    parameters:
      base_url: base_url: http://localhost/mettez/ici/l/adresse/a/tester
      browser: chrome

Il y a pas mal d'options, je vous laisse consulter la petite cheat sheet si besoin ;-)

La prochaine fois on verra comment allez plus loin dans le contrôle du navigateur, en exploitant l'API de Mink, et comment s'organiser pour travailler à plusieurs en créant des sous-contextes personnalisés plutôt que de ranger tout notre code dans un seul fichier.

Mais en attendant, n'hésitez pas à tester Behat et Mink et surtout à dire ce qu'il en est pour vous :-)

Behat – jour 2 : Installation et premiers tests

2012-03-11T00:00:00+00:00

Maintenant qu'on a vu à quoi sert Behat, il est temps de passer à la pratique...

Vous trouverez une archive contenant toutes les sources de ce billet en bas de cette page.

Installer Behat

Le plus simple à mon goût : passer par pear :

pear channel-discover pear.symfony.com
<p>pear channel-discover pear.behat.org</p>
<p>pear install behat/behat

Un petit test pour vérifier que tout s'est bien passé :

behat --version

Démarrer un projet

Voici la structure initiale de mon exemple :

mkdir -p  application/library tests/product

Placez-vous dans le dossier tests/product, puis tapez :

behat --init

Cela a pour effet de créer les dossiers nécessaires à votre projet :

features : les fichiers de fonctionnalité *.feature
features/bootstrap : les classes nécessaires au fonctionnement des fonctionnalités (contextes)
features/bootstrap/FeatureContext.php : le contexte principal

Première fonctionnalité

Il est temps de démarrer. Notre client (product owner) souhaite une application dans laquelle on puisse gérer un compte bancaire : on peut consulter son solde, ajouter des sous, en retirer... et on n'a pas le droit d'être découvert.

Le fichier de fonctionnalité livré par notre client ressemble à ceci >feature/banque.feature< :

# language: fr
<p>Fonctionnalité: posséder un compte bancaire</p>
  Afin de gérer les comptes bancaires des utilisateurs
  En tant que client
  Je dois être capable d'effectuer des opérations basique sur mon compte

  Scénario: Avoir un compte bancaire valide
    Etant donné que je suis un nouveau client
    Alors je dois avoir "0" euros sur mon compte

  Scénario: Retirer de l'argent sur mon compte
    Etant donné que je suis un client
    Et que je possède "50" euros sur mon compte
    Quand je retire "10" euros
    Alors je dois avoir "40" euros sur mon compte

  Plan du Scénario: Ajouter de l'argent sur mon compte
    Etant donné que je suis un client
    Et que je possède "<soldeInitial>" euros sur mon compte
    Quand je dépose "<montant>" euros
    Alors je dois avoir "<soldeFinal>" euros sur mon compte

    Exemples:
      | soldeInitial    | montant | soldeFinal |
      | 0               | 10      | 10         |
      | 15              | 5       | 20         |
      | 35              | 5       | 40         |

  Scénario: Interdire les découverts
    Etant donné que je suis un client
    Quand j'essaye de retirer plus d argent que je n en ai sur mon compte
    Alors j'ai un message d erreur "Vous ne pouvez pas être à découvert"

Le product owner sait ce qu'il veut, il nous a même donné des exemples pour mieux nous orienter dans notre développement.

Notez au passage le commentaire "# language: fr" au début du fichier. Il indique que notre fonctionnalité est décrite en français.

Lancer les tests

Il va être temps de lancer behat. Placez-vous dans le dossier tests/product/feature, puis tapez simplement :

behat --lang=fr

(N'oubliez pas de préciser la langue, vu qu'on travaille pour l'instant en français). On va dérouler ensemble le résultat de cette commande :

Rappel de la fonctionnalité

On commence par un rappel de la fonctionnalité et des scénarios testés.

S'il y avait eu des erreurs, le texte aurait été écrit en rouge, et si tout avait été ok, il serait vert. Là le texte est orange : il n'a pas encore de signification par rapport à notre produit.

Bilan du test

On a ensuite des informations sur les tests :

Donner du sens aux fonctionnalités

Toutes nos étapes sont en attente de définition. En effet, on n'a rien qui fait le lien entre les scénarios (les souhaits du product owner) et notre produit (le code source). C'est là que Behat va être à mon sens magique : il nous fournit le code PHP nécessaire pour créer ce lien, avec pour chaque phrase :

l'annotation qui permet de faire le lien (@Given /^que je suis un nouveau client$/)
la méthode a insérer pour donner du sens à cette phrase (public function queJeSuisUnNouveauClient())
les valeurs de cas du scénario (encadrés par des guillemets), qui sont fournis en paramètres de la méthode

Voici donc la dernière étape du traitement du résultat de la commande :

Behat nous fourni le code a copier-coller vers la classe qui gère notre contexte principal, à savoir la classe FeatureContext contenue dans /features/bootstrap/FeatureContext.php. Allons -y : copiez le code dans le fichier .

Vous pouvez constater que chaque méthode lance une exception de type PendingException. Cela signifie qu'il va falloir modifier ces méthodes pour les relier à notre application.

Pour vous simplifier la vie, je vous propose de télécharger directement le code nécessaire au bon fonctionnement de ces tests : Account.php, à placer dans application/library. Sinon libre à vous d'écrire le code qui correspondra à l'application ; en soit, peu importe le code, ce qui nous intéresse c'est le produit ;-)

Nous allons maintenant convertir le texte (langue naturelle) en code (source) :

<!--?php use Behat\Behat\Context\ClosuredContextInterface,     Behat\Behat\Context\TranslatedContextInterface,     Behat\Behat\Context\BehatContext,     Behat\Behat\Exception\PendingException; use Behat\Gherkin\Node\PyStringNode,     Behat\Gherkin\Node\TableNode; require_once 'PHPUnit/Autoload.php'; require_once 'PHPUnit/Framework/Assert/Functions.php'; require_once __DIR__ . '/../../../../application/library/Account.php'; use \MyApp\Account as Account; /**  * Features context.  */ class FeatureContext extends BehatContext {     /**      * Testes account      *      * @var \MyApp\Account      */     private $_account;     /**      * Contains the last exception      *      * @var \Exception      */     private $_lastException;     /**      * @Given /^que je suis un nouveau client$/      */     public function queJeSuisUnNouveauClient() {         $this--->_account = new Account;
    }

    /**
     * @Then /^je dois avoir "([^"]*)" euros sur mon compte$/
     */
    public function jeDoisAvoirEurosSurMonCompte($balance) {
        assertEquals($balance, $this->_account->getBalance());
    }

    /**
     * @Given /^que je suis un client$/
     */
    public function queJeSuisUnClient() {
        if(is_null($this->_account)) {
            $this->_account = new Account;
        }
    }

    /**
     * @Given /^que je possède "([^"]*)" euros sur mon compte$/
     */
    public function queJePossedeEurosSurMonCompte($balance) {
        $this->_account->setBalance($balance);
    }

    /**
     * @Given /^je retire "([^"]*)" euros$/
     */
    public function jeRetireEuros($amount) {
        $this->_account->takeMoney($amount);
    }

    /**
     * @Given /^je dépose "([^"]*)" euros$/
     */
    public function jeDeposeEuros($amount) {
        $this->_account->addMoney($amount);
    }

    /**
     * @Given /^j\'essaye de retirer plus d argent que je n en ai sur mon compte$/
     */
    public function jEssayeDeRetirerPlusDArgentQueJeNEnAiSurMonCompte() {
        try {
            $this->_account->setBalance(50);
        $this->_account->takeMoney(100);
        } catch (\Exception $e) {
            $this->_lastException = $e;
        }
    }

    /**
     * @Given /^j\'ai un message d erreur "([^"]*)"$/
     */
    public function jAiUnMessageDErreur($message) {
        assertEquals($message, $this->_lastException->getMessage());
    }

}

Vous constaterez que :

on utilise PHPUnit en mode "fonction" pour nos assertions
chaque méthode correspond à une phase d'un scénario
on fait ce qu'on veut à l'intérieur de notre contexte ^^
c'est simple : il ne faut même pas 3 minutes pour écrire ce code

L'heure de vérité

Le suspense est à son comble : notre code correspond t--il au souhait du client quant à son produit ?

behat --lang=fr

Conclusion

Si besoin voici une archive contenant l'ensemble de ce projet : Découverte de behat - jour 2.zip.

Notre client (product owner) peut désormais s'assurer à tout moment que son produit est valide.Bien plus, il va pouvoir ajuster son produit au fur et à mesure des sprints en vous décrivant clairement son besoin : fini les specs de 500 pages, c'est le product owner qui est maître de son produit ! Et cela grâce à Behat.

La prochaine fois on verra comment mieux organiser son code : sous-contextes, configuration... et surtout comment tester une application web, grâce à Mink. mais en attendant, toute remarque / commentaire est le bienvenu ;-)

Je vous rappelle qu'une cheat sheet pour behat est disponible.

Cheat Sheet Behat

2012-03-06T00:00:00+00:00

Je vous propose une petite feuille d'astuces (cheat sheet) pour Behat et Mink. N'hésitez pas pas à vous en servir et vous en resservir :-)

PDF : Cheat Sheet Behat and Mink

Edit : The English version : PDF (en) : English Behat Cheat Sheet

Image :

Page 1

Page 2

Au programme :

Page 1 :

Utilisation de la ligne de commande
Behat en 2 mots
Les fichiers de fonctionnalités et les scénarios
Insérer des exemples dans les scénarios
Naviguer avec Mink

Page 2 :

Infos sur la Session
Infos sur les éléments
Infos sur les noeuds HTML
Configuration par défaut (behat.yml)
Drivers disponibles pour Mink

Pour découvrir Behat, je vous invite à consulter le billet Jour 1 - Comprendre et utiliser Behat pour tester un produit Scrum ?

Tout commentaire est le bienvenu (ce qui manque, n'est pas clair, etc...). Merci de vos retours !

Behat - jour 1 : comment tester son produit SCRUM ?

2012-03-02T00:00:00+00:00

Ce billet démarre une série consacrée à cet outil que je trouve génial : Behat. Désolé pour la longueur, mais le sujet est suffisamment intéressant à mon goût pour être creusé comme il faut. :-) Pour ce premier jour avec Behat, on va se placer du côté du client uniquement. la partie développeur viendra dans le prochain billet. Nous allons donc découvrir Behat pas à pas.

Behat, c'est quoi ? Pour le comprendre, il faut d'abord faire un tour du côté des méthodes agiles, et particulièrement du côté de SCRUM

Scrum - la notion de produit et de test d'acceptation

J'abstrais volontairement une partie des aspects de Scrum pour me consacrer uniquement aux points déterminants pour comprendre les enjeux de Behat. Vous trouverez plus de détails sur Scrum ici).

Scrum, c'est avant tout un état d'esprit, mais c'est aussi un exemple d'organisation. Imaginez un peintre à qui l'on demande de peindre Mona Lisa. Si on fait l'analogie avec le développement, la manière classique consiste à peindre le tableau de haut en bas, comme le ferait une imprimante. Le tableau ne pourra être livré qu'une fois la peinture entièrement achevée, de bas en haut.

(les images proviennent de Jeff Patton)

Au contraire, en Scrum, on va commencer par esquisser les traits de Mona Lisa, puis on va demander au client si ça lui convient. Puis on va affiner le trait et le dessin. On redemande au client si ça lui convient. Enfin on va pouvoir ajouter des touches de couleurs, etc. C'est ce qu'on appelle un développement itératif. A chaque itération ("release"), le client valide le produit fourni et décide ou non de continuer. S'il s'arrête, le produit est simplement moins riche qu'escompté, mais il est livrable et utilisable par le client.

En Scrum, le client est donc le maître du produit qu'on lui fourni : il a la main dessus et doit participer activement a sa description fonctionnelle. On dit alors qu'il est le propriétaire du produit (Product Owner).

Pour décrire, justement, son produit, le client fourni généralement des spécifications fonctionnelles détaillées (SFD - qui, au passage, ne sont en général jamais lues car trop longues). Cette fois le client va au contraire décrire des cas d'utilisation de son produit. Pour savoir si le produit livré correspond à son besoin, il lui suffira de s'assurer que les cas d'utilisation sont respectés. Ces cas d'utilisation, garants du produit, sont regroupés dans tests d'acceptations du produit.

A chaque itération (release), le produit livré est donc comparé au produit souhaité au moyen de ces tests d'acceptation. C'est la garantie :

de satisfaire la demande initiale du client
d'éviter les quiproquos ("mais moi je voulais pas ça")
d'éviter les spécifications trop volumineuses
d'éviter l'ajout de nouvelles fonctionnalités par le client au fur et à mesure du développement (mais il pourra ajouter des fonctionnalités lors d'une prochaine release)

Behat dans tout ça ?

Behat, c'est l'outil PHP qui va permettre de faire le lien entre ces tests d'acceptation, écrits par le Product Owner, et le produit que moi, développeur, je lui livre. Bien plus, il permet de lancer ces tests d'acceptation de manière automatisée sur le produit et d'en fournir un rapport lisible par n'importe quel client. A chaque release, en un coup d'oeil, le client voit si ce qu'on lui a livré correspond à son besoin.

Attention ! Behat ne se substitue pas aux tests unitaires. Non, au contraire. Ce qu'il faut se dire c'est que le client n'en a rien à faire de savoir que le code est de bonne qualité ; ce qu'il veut c'est un produit fini, fonctionnel, conforme à ses souhaits initiaux. Le test unitaire, lui, va nous permettre de nous assurer de l'intégrité du code pour des fonctionnalités sensibles ou complexes. Il ne teste pas le comportement du produit (mais le test unitaire reste cependant indispensable)

Le développeur a en effet souvent tendance à détourner ses tests unitaires de leur fonction initiale (tester du code), pour tester des scénarios (par exemple qu'un Controlleur a le comportement attendu). Ce n'est pas aux outils de tests unitaires de faire cela. Heureusement, Behat est là pour ça ;-) !

Comment ça marche ?

Bon, c'est bien, mais plus concrètement ça marche comment ?

Et bien le Product Owner va rédiger ses tests d'acceptation en langue naturelle. Chaque fonctionnalité va être écrite dans un .

Il commencer par une description de sa fonctionnalité :

Fonctionnalité: Avoir un compte bancaire
  Afin d'offrir aux utilisateurs la possibilité d'avoir un compte bancaire
  Etant donné que je suis inscrit
  Je dois être capable d'ajouter ou de retirer de l'argent sur mon compte

Cette description permet de comprendre la fonctionnalité de manière générale. Ensuite il va fournir des cas d'utilisation qui vont décrire cette fonctionnalité. On parle alors de "Scénario". Chaque scénario est défini par :

un contexte (étant donné que)
des événements déclencheurs (quand)
un résultat attendu (alors)

Scénario:
  Etant donné que je suis un utilisateur connecté
  Et que j'ai un compte bancaire
  Et que le solde de mon compte est de "10" euros
  Quand j'ajoute "5" euros sur mon compte
  Alors mon solde doit être de "15" euros

Il va pouvoir combiner les scénarios :

Scénario:
  Etant donné que j'ai un compte bancaire
  Et que le solde de mon compte est de "10" euros
  Quand j'ajoute "5" euros sur mon compte
  Alors mon solde doit être de "15" euros

<p>Scénario:</p>
  Etant donné que j'ai un compte bancaire
  Et que le solde de mon compte est de "10" euros
  Quand je retire "50" euros sur mon compte
  Alors je dois avoir le message d'erreur "vous n'avez pas le droit d'être à découvert"
  Et mon solde doit être de "10" euros

Quand je lancerai Behat, si mon application fonctionne correctement, ce scénario va être valide et donc coloré en vert à l'écran.Sinon il sera rouge.

Mieux encore, le Product Owner va pouvoir insérer des exemples. Behat va automatiquement lancer ces tests pour chaque exemple fourni :

Scénario Outline:
  Etant donné que j'ai un compte bancaire
  Et que le solde de mon compte est de "" euros
  Quand j'ajoute "" euros sur mon compte
  Alors mon solde doit être de "" euros

  Examples:
    | soldeInitial | montant | soldeFinal |
    | 5            | 10      | 15         |
    | 20           | 20      | 40         |
    | 20           | 7       | 27         |
    | 0            | 10      | 10         |

Pas mal non ? Je vais avoir un rapport visuel (une page web par exemple) de l'état de mon produit par rapport à ces tests :

Maintenant vous avez compris le principe du test d'acceptation. Vous vous êtes mis dans la peau d'un Product Owner qui rédige ses tests d'acceptation. Si vous êtes Product Owner, vous n'avez pas besoin d'aller plus loin. Si vous êtes développeur ou Scrum Master, on verra ensemble le versant technique de Behat dans le prochain Billet ;-)

Edit: le jour 2 est prêt : Behat – jour 2 : Installation et premiers tests

Atelier PHP sur Orléans - Tester son code / produit

2012-02-29T00:00:00+00:00

Comme chaque premier jeudi du mois, demain se tiendra un atelier afup à Orléans.

Au programme :

le développement piloté par les tests (TDD)
tester son code avec phpUnit
tester son code avec Atoum
tester son produit avec Behat

Les infos nécessaires sont ici

Je n'ai pas prévu de slides : uniquement du code ;-) . Nous échangerons ensuite sur le thème du test en général et sur les outils présentés...

Tout le monde est le bienvenu : membres et non-membres de l'AFUP, développeur confirmé ou non.

A demain !

Utilisez un moteur javascript en PHP et faites exploser vos perfs

2012-02-25T00:00:00+00:00

Bon, je l'admets, ce titre est un brin accrocheur et trolleur :-) . Ceci dit, je viens de tomber sur Twitter sur un package PECL que je ne connaissais pas et qui à mon avis ouvre des perspectives très intéressantes, notamment pour améliorer les performances de certaines fonctionnalités chronophage de PHP.

Sur certains de mes tests (voir plus bas), le résultat est juste... 300 fois plus performant !

Ce package, V8JS, permet d'utiliser dans PHP le célèbre V8 JavaScript Engine. Ce moteur, développé par Google et très performant, est le moteur javaScript de Chrome.

Installation du V8 JavaScript Engine

On va commencer par installer le moteur en lui-même :

sudo apt-get install libv8-dev
<p>sudo apt-get install libv8-3.1.8.22

Installation du package pear

sudo pecl install v8js-beta php_ini=/chemin/vers/le/php.ini

Puis modifier le php.ini pour inclure le module v8js.so

[v8js]
<p>extension=/chemin/du/module/v8js.so

Vous pouvez déplacer le module v8js.so dans le dossier des modules de PHP, ce qui permet d'avoir plus simplement :

<p>extension=v8js.so

Un petit phpinfo() pour vérifier :

Utiliser V8JS

les choses sérieuses commencent ! Examinons la documentation. Plutôt simple : on a une classe V8Js, et une méthode executeString() pour appeler le moteur :

$v8 = new V8Js();
$JS = <<<EOT
function car(){
}
var myCar = new car();
<p>myCar.color = 'green';</p>
print(myCar.color);
<p>EOT;</p>

<p>try {</p>
  $v8->executeString($JS);
} catch (V8JsException $e) {
  var_dump($e);
}

On a donc utilisé le moteur javascript pour :

déclarer une classe
instancer un objet
ajouter un attribut à cette instance

Les performances

C'est là qu'on tombe dans des choses intéressantes.

Parenthèse :

Attention, comme tout bench, ces mesures sont à remettre dans leur cadre. ici je teste un type de comportement, dans un contexte donné, sur ma machine. De plus c'est orienté, j'ai délibérément choisi quelque chose pour lequel JavaScript excelle.

Bref, en voyant ça, je me suis dit : tiens, et si je testais un peu les performances ? J'ai alors cherché un comportement pour lequel JavaScript est particulièrement performant, et qui existe également en PHP. J'ai tout de suite pensé aux fonctions array_reduce / reduce. Voici deux codes qui me semblent comparables.

Voici le premier, en PHP pur :

<?php
// bench
$start = microtime(true);

//
// Test
$myArray = array();
for ($i = 0; $i < 100000; $i++) {
    array_push($myArray, $i);
}

function rsum($v, $w) {
    $v += $w;
    return $v;
}

$r = array_reduce($myArray, "rsum");

//
// Bench
$duration = microtime(true) - $start;
<p>var_dump($duration);

Dans l'autre, on reporte les calculs sur le moteur JavaScript :

//
// bench
$start = microtime(true);

$js = <<<EOT
<p>var i;</p>
<p>var myArray =  [];</p>
for (i = 0; i < 100000; i++) {
    myArray.push(i);
}

function rsum(v, w) {
    v += w;
    return v;
}

var r = myArray.reduce(rsum);
print(r);
<p>EOT;</p>


//
// Test
$v8 = new V8Js();
<p>try {</p>
  $v8->executeString($js);
} catch (V8JsException $e) {
  var_dump($e);
}

les résultats

Voici ce que j'obtiens :

en pur PHP : 2.5989
en reportant sur le moteur javascript : 0.0085

Bref, comme je le disais plus haut : un sacré écart !

Conclusion sur le moteur V8 en PHP

je n'ai aucun recul sur cette utilisation du moteur V8 au sein de PHP. Le package est d'ailleurs en bétâ. Cependant, je pense que c'est une piste sérieuse si on cherche à reporter certains traitements (particulièrement des calculs) vers JavaScript...

Le point sur les limites du typage de PHP

2012-02-20T00:00:00+00:00

Les limites

PHP a ceci de particulier qu'il est est un langage de typage faible (le type des variables peut changer en cours de route), mais qu'il autorise un typage fort partiel des paramètres de fonctions pour ce qui concerne les objets et les tableaux. On pourra ainsi écrire :

function test(array $argument) {
    (...)
}

function test(monObjet $argument) {
    (...)
}

mais par contre il n'est pas possible de typer les paramètres de méthodes pour les types scalaires (entier, chaînes de caractères...)

function test(string $argument) {
    // qui a dit que PHP ne savait pas être drôle ?
    // Argument 1 passed to test() must be an instance of string, string given
}

Pourtant, ça semble bien souvent manquer : combien de fois vois t-on des tests de type dans un code ?

function test($argument) {
    if(!is_string($argument)) {
        throw new InvalidArgumentException(&amp;quot;eh ! on voulait une chaîne !&amp;quot;);
    }
}

Bref, on se retrouve avec du code pas vraiment utile (qui n'est ni métier ni applicatif), qui, bien souvent, nuit à la lecture et à la bonne compréhension des sources.

Les solutions pistes

il existe cependant des solutions, ou au moins des tentatives de solutions, pour pallier à ces inconvénients.

Patch

La première provient d'un modification du langage lui-même, sous forme d'un patch ou d'une extension. Ilia Alshanetsky propose depuis longtemps un patch pour PHP 5.3. Ce patch, complet, modifie le comportement du parseur, mais complète également Reflection.

Malheureusement, l'utilisation de ce patch nécessite de devoir patcher systématiquement PHP, avec d'autant plus de risques que le patch n'est pas officiel. Mais surtout ce patch n'est pas mis à jour, et n'est plus compatible avec les versions récentes de PHP 5.3 (ne parlons même pas de PHP 5.4 :-) )

La Standard Php Libary

Bon, c'est un idée, mais il y en a eu d'autres. Marcus Börger et David Coallier ont développé l'extension PECL SPL_Types pour insérer ce comportement dans la SPL.

Ici, pas vraiment de typage fort scalaire, mais une surcouche à utiliser :

function test(SplInt $integer){
    // (...)
}

$value = new SplInt(5);
<p>test($value);

Ça semble marcher, mais personnellement je trouve ca peu élégant et pas vraiment optimal : quid de la compatibilité avec des librairies externes qui n'utiliseront pas les typages Spl ? Et bon, on ne type pas les scalaires ; dans notre exemple ce qui suit ne fonctionnera pas, ce qui montre en soi que cette solution n'est qu'une rustine :

assert(5 instanceof SplInt); // faux
<p>assert(is_int( new SplInt(5) )); // faux

La rustine de la mort qui tue

Très vite, de nombreux développeurs ont eu l'idée de passer par un gestionnaire d'erreur personnalisé pour résoudre ce problème. Personnellement, je l'avais mis en place sur un framework dans une ancienne boite. À l'époque j'avais trouvé ça tout seul et ça m'avait bien amusé. Après j'avais fait des benchs et je l'avais vite retiré ;-)

L'idée est d'intercepter les erreurs, d'analyser le message de l'erreur et de voir s'il correspond pas à un problème de type. Si c'est le cas on fait nous même le contrôle "a la main", sinon on renvoie vers le gestionnaire d'erreur par défaut.

Voici une version basique :

set_error_handler(function($errno, $errstr, $errfile, $errline) {
    if(preg_match('!must be an instance of (\w*), (\w*) given!', $errstr, $matches)) {
        $matches[2] = str_replace('double','float', $matches[2]);
        return strtolower($matches[1]) == strtolower($matches[2]);
    }
});

En 6 petites lignes de code, magique : on peut désormais écrire ceci :

function example1(integer $v) {
    echo 'Cool, integer was given !'.PHP_EOL;
}
function example2(string $v) {
    echo 'Cool, string was given !'. PHP_EOL;
}
function example3(float $v) {
    echo 'Cool, float was given !';
}
function example4(boolean $v) {
    echo 'Cool, boolean was given !';
}
function example5(object $v) {
    echo 'Cool, object was given !';
}
function example6(resource $v) {
    echo 'Cool, resource was given !';
}

N'oubliez pas que c'est catastrophique côté perf :-)

Conclusion

Bref, on se retrouve avec des rustines et pas vraiment des solutions exploitables en production. Pourtant, si je comprend que le typage fort puisse gêner, je trouve que le typage des paramètres et des retours de de fonction (comme en Java par exemple) manque beaucoup, et pourrait apporter du grain dans la professionnalisation du langage.

D'ailleurs, si on observe bien, on retrouve tout de même de nombreuses RFC à ce sujet, et le sujet à été débattu à de nombreuses reprises, et par de nombreuses "figures" de PHP (Derick Rethans, Sebastian Bergmann...), on a même un moment que c'était bon. Aux dernières nouvelles (mais je dois avouer que je ne sais pas trop ce qu'il en est ) il me semble que l'introduction du typage fort des arguments des fonctions reste très largement discutée, voire contestée, et qu'alors même on l'espérait pour php 5.4, elle n'est prévue dans aucune des futures versions sur les rails.

Quel est votre avis sur la question ? Le typage fort des paramètres et des retours de fonctions vous manque t-il au quotidien ? Ou bien au contraire trouvez-vous que c'est justement la force de PHP que d'offrir une grande souplesse aux développeurs et de s'en passer ? Etes-vous déçus de ne pas avoir cette nouveauté dans PHP 5.4 ?

Slides de l'atelier php sur les Traits pour l'AFUP

2012-02-03T00:00:00+00:00

Pour ceux qui étaient là hier pour notre atelier php à Orléans sur la programmation orientée objet, php 5.4 et les traits, voici les slides que j'ai utilisés :

Programmation Orientée Objet et les Traits en PHP 5.4

View more presentations from halleck45

Au passage, merci à tous d'êtres venus ! Prochain rendez-vous le 1er mars (premier jeudi du mois) :-)

PHP à Orléans : ça bouge !

2012-01-20T00:00:00+00:00

Et bien pour un premier apéro php sur Orléans, on peut dire que ça s'est bien passé ! Une bonne dizaine de personnes, motivées, sympas.... finalement à Orléans on semble bien décidés à montrer qu'on existe :-)

Pour synthétiser la soirée, qui s'est tenu sur la place du Martroi, au coeur d'Orléans, et bien des bonnes discussions de geeks, des projets... Ainsi a t-il été décidé de se retrouver une fois par mois pour des ateliers / formations sur PHP et sur des technologies tierces.

Parmi les présents, on retrouve en force SUPINFO, mais aussi la CCI, et différentes web agency orléanaises. On espère être plus nombreux pour le prochain rendez-vous ; aussi si vous êtes de la région, n'hésitez pas à surveiller le site d'apéro php ou à m'envoyer un petit message si vous êtes intéressés. Y'aurait un développeur photographe dans l'équipe ? :-p

En attendant le prochain rendez-vous, voici quelques photos de la soirée. Bon, désolé pour la qualité de l'image, on ne peut pas dire que mon téléphone soit le meilleur pour ce qui est de prendre des photos...

Comment tester un Trait avec phpUnit ?

2011-09-13T00:00:00+00:00

Il peut être intéressant de tester un code avec des Traits, PHP et phpUnit. Les Traits sont apparus en PHP 5.4, et permettent de définir des comportements qui peuvent être réutilisés dans plusieurs classes.

Lors de mes premiers tests, je me suis vite rendu compte d’un problème : pour pouvoir tester un trait, c’est à dire un comportement, il faut une classe qui implémente ce comportement :

trait MyBehavior {
    public function getAny()
    {
        return 'ok';
    }
}

class Example {
    use MyBehavior;
}

Et le test :

class BehaviorTest extends PHPUnit\Framework\TestCase {

    public function testMyBehavior()
    {
        $behavior = new Example;
        $this->assertEquals('ok', $behavior->getAny());
    }
}

Or ici on voit bien l’erreur : on ne test pas unitairement le comportement du Trait, mais son implémentation dans une classe qui est sujette à modifications.

C’est ici qu’intervient PHPUnit, qui a introduit la méthode getObjectForTrait() dans sa version 3.6. Grâce à cette méthode, il est possible de tester directement notre comportement.

trait MyBehavior {
    public function getAny()
    {
        return 'ok';
    }
}

et le test :

class BehaviorTest extends PHPUnit\Framework\TestCase {
    
    public function testMyBehavior() 
    {
        $behavior = $this->getObjectForTrait('MyBehavior');
        $this->assertEquals('ok', $behavior->getAny());
    }
}

Pratique non ?

💡 Pour aller plus loin :

PHPUnit, le framework de test unitaire pour PHP.

Les traits en PHP, la documentation officielle.

Les traits en PHP, conférence que j’ai donnée à l’AFUP.

Couverture de code de PHP : un avis sur la polémique de PHP 5.3.7 ?

2011-09-09T00:00:00+00:00

Si vous êtes intéressé par la couverture de code de PHP* (la manière dont les fonctions natives du langage sont testées par des Tests unitaires), il est très intéressant de consulter http://gcov.php.net/ .

Ce site contient en temps réel les compte-rendus de la couverture de la version en cours de PHP (PHP 5.3) et la la prochaine version (PHP 5.4)

Vous y trouverez :

la couverture de code
les compte-rendus de compilation
la liste des fonctions en erreur / warning
la liste des fonctions non testées

Ce site va peut être mettre fin aux polémiques sur le workflow des versions de PHP. En effet, on se souvient tous de l'affaire récente de PHP 5.3.7 qui a révélé de grosses lacunes dans le langage (à savoir que les versions stables de PHP contiennent en réalité de nombreuses fonctions dont les tests unitaires échouent).

J'ai bien envie de tirer alors un petit bilan, qui n'engage que moi, mais sur lequel j'aimerai avoir votre avis. Je pense que depuis PHP 5.3, PHP s'est largement professionnalisé, grâce à d'une part un nouveau modèle Orienté Objet plus riche, d'autre part l'appropriation par les développeurs des outils de PIC (Plate-forme d'intégration continue) et de phpUnit en particulier.

Cette professionnalisation a amené de nouveaux types de développeurs PHP, avec de nouvelles exigences, auxquelles PHP tente de répondre aujourd'hui.

Je pense alors que, oui on peut critiquer le processus actuel de mise en production de PHP, car avec PHP 5.3.7 PHP a été la "risée" du web (j'éxagère exprès, mais disons que ça ne l'aide pas à effacer l'image très négative des développeurs PHP, qui sont souvent considérés comme des "sous-développeurs", même encore aujourd'hui).

Mais c'est sur la bonne voie. PHP se professionnalise, se réorganise (processus de votes, passage de subversion à git...), se réoriente. Le langage répond de mieux en mieux à nos exigences de qualité (il suffit de voir le nombre de type d'exceptions dans la SPL par exemple, ou encore l'apparition des Traits dans PHP 5.4). Bref, je trouve dommage de jeter la pierre, comme certains l'ont fait, à un langage qui est dans une phase de transition, et, je l'espère, de transition positive.

Et vous ? Pensez-vous également que cette phase de transition soit positive ? Il serait aussi intéressant de savoir ce qu'en pensent des développeurs d'autres langages, pour connaître des avis extérieurs...

____________

* note pour ceux qui ne sont pas familiarisés avec les tests unitaires, il est peut-être temps de vous y mettre :-) . L'outil le plus utilisé est PhpUnit, mais un "nouveau" venu qui a l'air bien conçu mais que j'ai pas encore eu l'occasion de tester est Atoum, de Frédéric Hardy.

Pour générer un compte rendu de la couverture de code avec phpUnit, cette simple commande suffit :

phpunit  --coverage-html /chemin/du/rapport/ /chemin/des/tests/unitaires

PHP Solutions d'Aout est disponible

2011-08-02T00:00:00+00:00

Bon, et bien comme un peu de pub n'a jamais fait de mal, et surtout que j'ai écrit comme je vous le disais un petit article dans ce numéro, je vous invite à découvrir le dernier numéro de PHP Solution :

POO en PHP et nouveautés apportées par PHP 5.4.
Drupal et Magento deux géants pour une plateforme e-commerce / m-commerce complète.
Facebook : Créer vos applications au bout des doigts.
Générer des classeurs pour tableur avec PHPExcel.
Les solutions pour booster WordPress.
PC ASUS G73S.

Bref, si le coeur vous en dit ça se passe ici : PHP Solutions Aout 2011

L'article "Repenser l'approche orientée objet" est une introduction à une suite d'article sur la professionnalisation de PHP et sur l'arrivée prochaine de PHP 5.4. En quelques pages je n'ai pas la prétention de "repenser" l'objet, mais simplement démarrer en présentant mon point de vue sur : d'un côté qu'utiliser une classe ne veut pas dire qu'on pense Objet ; d'autre part que pour moi une application se définit comme un maillage de "Comportements", d'où l'intérêt de PHP 5.4 et des Traits selon moi.

Après, si vous avez des suggestions, des retours et des critiques, n'hésitez pas à laisser un petit commentaire, et surtout faites-nous partager votre vision de la Programmation Orientée Objet, et de la manière dont le modèle Objet de PHP oriente vos développements :-)

Redonner son sens à l'héritage grâce aux Traits

2011-08-01T00:00:00+00:00

Suite à la rédaction d'un petit article pour PHP Solutions sur l'approche Orientée Objet, je me suis mis à faire quelques tests pour voir jusqu'à quel point les Traits de PHP 5.4 pourront changer notre manière de programmer.

Et bien ça fait plus que changer, les Traits sont à mon avis une véritable révolution dans l'approche et la conceptualisation d'un code, quel qu'il soit.

En effet, un Trait permet de réutiliser un Comportement. Or sur un gros projet, même en organisant bien notre code, on est souvent amené à recoder plusieurs fois le même comportement. Par exemple, pour créer un Singleton on a deux choix :

ou bien on écrit tout le code nécessaire dans notre classe
ou bien on fait hériter notre classe d'une classe mère Singleton

Dans le premier cas, on a inévitablement du code redondant dans notre application.

Dans le second, on perd le principe de l'héritage : l'héritage ne sert pas ici à spécialiser un comportement métier, mais à disposer d'outils pour un fonctionnement interne. On perd alors totalement ce principe de l'Orienté Objet qui consiste réduire le couplage entre les modules métiers et les modules internes ; L'héritage en PHP n'étant pas multiple, on perd le seul héritage métier/fonctionnel que l'on aurait pu avoir pour notre classe.

Un solution consisterait à augmenter le niveau d'héritage et de créer une hiérarchie de classes (c'est ce qui est souvent fait, vu que l'héritage multiple n'existe pas en PHP). Mais dans ce cas :

on a perdu la logique objet : l'héritage n'a pas servi à spécialiser
le code n'est plus maintenable
l'architecture n'est plus maintenable (on est pris dans un cercle vicieux, celui de rajouter toujours un niveau au dessus jusqu'à créer une classe géante à la racine qui fait tout)

Bref, à mon avis sur ce genre de code on est souvent dans une impasse. C'est là qu'interviennent les Traits. Plutôt que de consacrer l'héritage à un comportement interne, laissons l'héritage pour le comportement métier et utilisons les traits pour ce qui est interne.

Attention, je ne dis pas que les Traits ne peuvent pas être utilisés pour du comportement métier (bien au contraire), ne me faites pas dire ce que je n'ai pas dit :-)

En voici un exemple simple. Cet exemple n'est pas idéal, dans la mesure où il s'agit plus d'un détournement des Traits que d'une utilisation plus intelligente, mais je pense qu'il est clair :

trait Singleton {
    /**
     * Constructor
     *
     */
    protected function __construct() {}
     /**
     * Get singleton instance
      *
     * @return static
     */
    public static function getInstance() {

        static $instance = null;
        if (is_null($instance)) {
            $instance = new static;
        }

        return $instance;
    }

    /**
     * Prevents cloning
     *
     * @throws Exception
     */
    public function __clone() {
        throw new \Exception('Cloning of this object isn\'t authorized');
    }

    /**
     * Prevents deserialization
     *
     * @throws Exception
     */
    public function __wakeup() {
        throw new \Exception("Cannot deserialize instance of Singleton pattern in" . get_called_class());
    }
}

Il ne reste plus qu'à l'utiliser :

class Example extends MaClasseMetier {
    use \Singleton;
}
$oExample = Example::getInstance();
var_dump($oExample === Example::getInstance());
// true
$oExample = new Example;
// Fatal error: Call to protected Example::__construct() from invalid context

Ce détournement nous permet d'utiliser le Comportement "Singleton" pour toutes les classes qui en ont besoin, avec un simple "use Singleton". Bon, il ne faut pas forcément le faire, et je sens les remarques qui vont arriver sur le Singleton et la testabilité, mais je pense que c'est un exemple clair des horizons que nous ouvrent les Traits :-p

Compiler et installer PHP

2011-07-04T00:00:00+00:00

Comme promis, voici le pas-à-pas d'une installation personnalisée de PHP (en l'occurrence PHP 5.4 alpha1).

Avant toute chose, notez qu'en production il ne faut PAS utiliser une version alpha. Pour installer une version stable, ce code suffira :

Note : toutes les commandes ci-dessous sont à utiliser pour Ubuntu

sudo apt-get install php5

Commencez par télécharger la release : http://qa.php.net/

Ensuite, il suffit d'extraire le contenu de l'archive dans un dossier temporaire à part :

wget http://downloads.php.net/stas/php-5.4.0alpha1.tar.gz
tar xvzf php-5.4.0alpha1.tar.gz

Uniquement en mode console ( cli )

Ouvrez un terminal, puis entrez :

./configure --enable-pcntl --enable-shmop --enable-cli --without-apache --disable-cgi --enable-posix

(c'est en l'occurrence ce dont moi j'avais besoin : ligne de commande uniquement + pcntl ; à vous de voir ce qu'il vous faut).

Si tout s'est bien passé, il ne reste plus qu'à préparer l'installation :

make

C'est sans doute le moment de lancer les tests de PHP. Ces tests unitaires vous permettront de vous assurer que tout s'est bien passé :

make test

par contre, ne vous inquiétez pas, c'est plutôt long.

Si tout est ok, il est temps de lancer l'installation de version de PHP :

sudo make install

Pour vérifier votre version de PHP (cli), c'est simple :

php -v
//
PHP 5.4.0alpha1 (cli) (built: Jun 29 2011 13:24:55)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies

Je ne connais pas la procédure sous Windows, et je ne suis même pas sûr que ce soit possible (peut-être avec Visual Studio ?), mais si quelqu'un veut bien l'expliquer ...

Edit: apparemment c'est possible sous Windows. Des retours ?

Mode web (Apache)

Bon, lancer un script php c'est souvent pas suffisant, c'est mieux quand un site web tourne avec :-p

Dans ce cas, on va légèrement changer la configuration, pour créer en même temps le module php pour apache (le with-apxs2):

Petite parenthèse:

Si vous n'avez pas apxs2, utilisez commande suivante :

sudo apt-get install apache2-threaded-dev
un which apxs2 devrait vous retourner le chemin complet

./configure --with-mysql=shared --with-pdo-mysql  --with-apxs2=/usr/bin/apxs2 --enable-xml --with-zlib
copier le libphp5.xo
make

Il faut copier le module qui a été généré par le make (dans libs/libphp5.so) dans le répertoire des modules apache :

sudo cp libs/libphp5.so /usr/lib/apache2/modules/libphp5.so

et bien sûr, redémarrer Apache

sudo /etc/init.d/apache2 restart

le phpinfo() vous affiche désormais :

PS : ce n'est pas forcément la meilleure configuration, l'intérêt de compiler est justement de prendre ce dont vous avez besoin; A vous de voir quels extensions vous sont utile ; n'hésitez pas à faire un tour dans votre phpinfo() avant pour le savoir :-)

PS : en même temps que j'ai publié ce billet, notre cher Rasmus Lerdorf a publié une config pour tester PHP 5.4.

Ca vous dit d'installer l'alpha de PHP 5.4 ?

2011-07-01T00:00:00+00:00

Ca y est, depuis le 28 juin une alpha de PHP 5.4 est officiellement disponible. Ca vous dit de la tester ?

Personnellement (et il n'est jamais trop tard pour changer d'idée :-) ), je pense qu'un développeur doit varier ses environnements de travail, ne serait-ce que pour être prêt pour n'importe quelle migration.

Bien sûr, il ne me viendrait pas à l'idée de travailler sur une alpha au boulot ou de l'installer sur mon serveur de production : je ne suis pas suicidaire. Par contre, avoir, par exemple, une machine avec PHP 5.4 dès aujourd'hui, me permettra d'être prêt le jour où le besoin s'en fera sentir professionnellement ; cela me permettra d'apprendre à utiliser les apports de cette version, mais aussi d'en connaître les pièges et les subtilités.

De même, varier les environnements peut être avantageux : si pour une raison x ou y vous devez changer de type serveur (Linux à Windows par exemple) pour une application, vous saurez anticiper un minimum les contraintes et limiter les dégâts (même si là j'ai pris un exemple extrême :-p )

Mais vous, comment fonctionnez-vous généralement quand une version majeure est annoncée ? Vous migrez rapidement (pour vos développements persos) pour pouvoir prendre en main les nouveautés rapidement ? Ou bien préférez-vous attendre que ce soit bien stable avant d'y toucher, de peur que certains comportements changent en cours de route ?

Je pense que ça peut être intéressant de voir les habitudes des développeurs PHP sur ce point, alors n'hésitez pas à décrire les vôtres ici. A vos votes et vos commentaires :-p !

[poll id="2"]

Apéro PHP à Blois : Joyeux anniversaire PHP !

2011-07-01T00:00:00+00:00

Pour l'anniversaire de PHP 5.3, Sophie a fort gentiment organisé une rencontre sur Blois.

Etaient principalement présents l'équipe de la société Flavea et celle de la Maison de Valérie.

Le petit éléphant bleu était bien là pour son anniversaire :-)

Très bonne soirée ! On remet ça pour la sortie de PHP 5.4 ?

Vous étiez-où vous ? Apparemment à Lille ça a été pas mal non plus non ?

[gallery]

Tour d'horizon des Callbacks en PHP

2011-06-17T00:00:00+00:00

Je suis toujours étonné de voir de nombreux développeurs PHP, pourtant habitués à travailler avec des callbacks en JavaScript, connaître si peu voire pas du tout les callbacks PHP.

C'est pourquoi je vous propose aujourd'hui un petit rappel des callbacks en PHP :

Un callback, c'est quoi ? En un mot, Un callback est une référence vers un code exécutable.

L'utilisation de callbacks est très fréquente dans certains langages. Un exemple simple en JavaScript :

<a onclick="doAnything()">example</a>

La fonction doAnything() est un callback, qui sera exécuté à chaque clic sur le lien.

Création d'un callback en PHP

En PHP, les callbacks peuvent être définis de nombreuses manières :

Fonction anonyme

$callback = function() {
    echo "un callback dans une fonction anonyme";
};

Fonction existante

Les callbacks peuvent référer une fonction existante. Dans ce cas, on utilise le nom de la fonction comme callback :

$callback = 'maFonction';

Méthode de classe existante

De la même façon, on peut référer une méthode de classe, avec cette fois quelques subtilités :

$callback = array('NomDeLaClass','maMethode');

Equivaut à :

$obj = new NomDeLaClass;
$callback = array($obj,'maMethode');

Ou encore (méthode statique) :

$callback = array('NomDeLaClass::maMethodeStatique');

Cas particuliers

Pour accéder au parent de la classe actuelle, utilisez le mot clef "parent" de cette façon :

$callback = array('parent::maMethode');

et cela de la même façon pour self et static :

$callback = array('self::maMethode');
$callback = array('static::maMethode');

Appeler/Exécuter un callback

le plus simple est sans doute d'utiliser la fonction call_user_func :

call_user_func($callback);

le moins élégant (c'est le moins qu'on puisse dire :-)) est d'utiliser la syntaxe suivante :

$callback();

Passage de paramètres et références

Nous allons nous attarder maintenant sur les paramètres à passer au callback. C'est simple :

$callback($param1, $param2);
// ou
call_user_func($callback, $param1, $param2);

la fonction call_user_func a une soeur, call_user_func_array, qui permet de passer les paramètres sous forme de tableau :

call_user_func_array($callback, array($param1, $param2));

Jusque là, c'est simple. Il faut juste faire attention au passages de paramètres par référence. En effet, la fonction call_user_func() ne passe pas les paramètres par référence :

function test(&$val) {
}
call_user_func('test', $value);
// Warning: Parameter 1 to test()
// expected to be a reference, value given

Il faut ruser et passer par call_user_func_array() en forçant la référence :

function test(&$a) {
}
call_user_func_array('test',array(&$value));
// Cette fois c'est bon

Performances

Les appels de fonctions de type callback sont plus lents que des appels de fonction directs. Voici un bench sur 1 million d'itérations :

Certes il y a une différence, mais dans application standard cette différence est généralement négligeable.

Le mot de la fin

Vous me direz que PHP n'est pas à la base un langage où l'utilisation massive des callbacks est pertinente. Mais bien utilisé, les callbacks peuvent significativement alléger le code, et en voici un exemple trivial :

$array=array('pomme','peche','poire','abricot');
array_walk($array, function(&$item) {
    $item = strtoupper($item);
});
print_r($array);
//Array
//(
//    [0] => POMME
//    [1] => PECHE
//    [2] => POIRE
//    [3] => ABRICOT
//)

Et vous, vous avez l'habitude d'utiliser des callbacks, ou bien vous réservez ça pour d'autres langages ?

Le Design Pattern Flyweight (Poids mouche)

2011-06-08T00:00:00+00:00

Aujourd'hui je vous propose de parler Design Pattern, et plus particulièrement d'un pattern intéressant à mettre en place quand on cherche à alléger (en mémoire) une application : le pattern Flyweight (poid mouche).

Problème à résoudre

l'application doit manipuler de très nombreuses Entités (des produits pour une boutique par exemple), et chaque Entité est représentée par un Objet. L'instanciation de tous ces objets est très gourmande en mémoire :

$oDataMapper = new DataMapper_Product();
$tRowset = $oDataMapper->fetchAll($where);

foreach($tRowset as $oProduct) {
    // one instance of Product $oProduct is created in each loop
    echo $oProduct->getName();
}

On voit le problème : pour chaque ligne récupérée, un objet est instancié, donc est créé, chargé en mémoire... c'est lent et coûteux.

La solution : Flyweight

Il suffit de n'instancier qu'une seule fois l'objet en question, et de l'hydrater au fur et à mesure du besoin :

$oDataMapper = new DataMapper_Product();
$tRowset = $oDataMapper->fetchAll($where);

// Only one instance of Product is used
$oProduct = new Product;

foreach($tRowset as $tInfosAboutProduct) {
    $oProduct->hydrate($tInfosAboutProduct);
    echo $oProduct->getName();
}

Ce qui dans notre cas pourrait donner par exemple cette classe :

class Product extends Dao {

    protected $_name;
    protected $_price;

    (... getter and setters ...)
    
    public function hydrate(array $tData) {
        $this
                ->setName($tData['name'])
                ->setPrice($tData['price']);
        return $this;
    }

}

Les performances sont dans ce cas meilleures, et l'utilisation mémoire est plus réduite.

Quand utiliser le pattern Flyweight ?

Ce type de pattern n'est pas forcément adapté dans toutes les situations, on l'utilise :

quand on doit manipuler de très nombreux petits objets
quand le coût (mémoire/vitesse) de cette manipulation est élevé

Et vous, avez-vous déjà utilisé ce pattern ? Quel est votre retour d'expérience ?

Objet : accéder au grand parent en PHP

2011-06-06T00:00:00+00:00

S'il est courant de surcharger une méthode parente en PHP, il est plus rare d'accéder directement à la classe "grand -mère" sans passer par la mère. Pourtant... c'est possible, et voici comment :-)

En effet, un héritage de PHP 4 permet préserver le contexte d'exécution de la classe fille quand on appelle une classe parente en utilisant son nom plutôt que l'opérateur "parent" (qui n'existait pas avant). Un exemple tout simple :

class GrandMother {
    protected $_myVar = '5';

    public function doSomething() {
        echo "GrandMother, value is " . $this->_myVar;
    }
}

class Mother extends GrandMother {

    public function doSomething() {
        echo 'Mother, value is '; // Never called
    }
}

La classe fille n'utilise pas "parent", mais directement le nom de la classe grand-mère :

class Child extends Mother {

    public function doSomething() {
        $this->_myVar = '20';
        return GrandMother::doSomething();
    }
}

Il ne reste plus qu'à tester :

$oObject = new Child;
$oObject->doSomething();
// affiche "GrandMother, value is 20"

A utiliser avec précaution et modération ;-)

PHP 5.4 : les Traits (Horizontal Reuses)

2011-06-04T00:00:00+00:00

PHP 5.4 offre son lot de nouveautés, dont les Traits. Un trait permet d'injecter dans une classe des méthodes d'une ou plusieurs autres "classes" (des traits):

trait Color {
	public function getColor() {
		return 'blue';
	}
}

class Vehicle {}

class Car extends Vehicle {
	use Color;
}

$myCar = new Car;
echo $myCar->getColor(); // blue

On voit ici l'intérêt du trait : reporter sur une entité un aspect "fonctionnel" d'une classe. On peut imaginer une classe Car presque vide mais fonctionnelle :

trait Color {
	public function getColor() {
		(...)
	}

	public function changeColor() {
		(...)
	}
}

trait Selling {
	use Price; // un trait peut utiliser un autre trait
	public function buy() {
		(...)
	}
}

class Car {
	use Color, Selling;
}

Attention toutefois : les Traits rompent avec les aspects classique de la programmation par Interface (de l'orienté objet donc) ou de la programmation par Contrat :

la classe Car n'implémente PAS une Interface Color ou Selling, elles ne fait que reporter, utiliser, horizontalement.

Ce point est très important et dangereux, car en PHP un principe de base est la verticalité des classes et le respect du principe de substitution de Liskov : un objet qui travaille avec un autre objet Y doit pouvoir continuer à fonctionner de la même façon lorsqu'on substitue à cet objet Y un autre objet Z de même Interface.

Un Trait peut s'assurer de la présence d'une méthode dans la classe

Il est possible de s'assurer dans un Trait de la présence de certaines méthodes dans la classe qui l'utilise :

trait Selling {
	(...)
	abstract public function getCarBrand();
}
class Car {
	use Color, Selling;
	protected $_brand;

	public function getCarBrand() {
		return 'Ma marque est '.$this->_brand;
	}
}

Portée des méthodes

Il est possible de préciser certaines informations lors de la déclaration du trait dans une classe :

trait Selling {
	(...)
	public function getConstructorPrice() {};
}

class Car {
	use Selling {
		getConstructorPrice as private // la méthode getCarBrand est rendue privée
	}
}

$myCar = new Car;
$myCar->getConstructorPrice(); // Error

Priorité des Traits

Que faire si une classe utilisent des traits qui contiennent les mêmes méthodes ? Tout est prévu :

trait Selling {
	public function exampleDuplicateMethod() {}
}
trait Color {
	public function exampleDuplicateMethod() {}
}
class Car {
	use Selling, Color {
		Color::exampleDuplicateMethod insteadof Selling;
	}
}

Cas pratique : le singleton

Il est temps de voir un cas pratique :-) Il est pratique en PHP de créer une classe abstraite Singleton, que l'on serait tentée d'hériter à chaque fois que l'on a besoin d'un singleton. Malheureusement, PHP ne permet pas l'héritage multiple, et on se prive alors peut-être d'un héritage fonctionnel plus intéressant pour notre classe. L'utilisation des Traits résouts partiellement ce problème :

trait Singleton {
	public static function getInstance() {
		(...)
	}
}

class Example extends MotherExample {
	use Singleton;
}
$obj = Example::getInstance();

Pratique non ? (n'oubliez pas qu'un singleton c'est plus que ça, là il ne s'agit que d'un exemple)

Et PHP 5.3 dans tout ça ?

Les Traits n'existent pas en PHP 5.3, pourtant cette version du language risque d'être longtemps utilisée. Il existe une astuce simple pour simuler ces traits en PHP 5.x : la relation de Composition et l'utilisation massive des méthodes magiques :

Nous allons commencer par créer notre classe Child1, en lui donnant un tableau (nommé $_tTraits) qui contiendra la liste des classes dont on souhaite qu'elle puisse les utiliser comme des Traits.

class Trait1{
    public function method1() {
        echo 'Cette fonction est dans le Trait 1';
    }
}
class Trait2 {
    public $attribute2 = 'demo';
    public function method2() {
        echo 'Cette fonction est dans le Trait 2';
    }
}

class Child extends Parent1 {
    private $_tTraits  = array('Trait1', 'Trait2');
}

Maintenant, nous allons automatiquement instancier ces classes lors de la construction de l'objet. Ces instances seront stockées, nous nous en serviront pour reporter les actions effectuées sur la classe vers les classes Traits.

class Child extends Parent1 {
    private $_tTraits = array('Trait1', 'Trait2');
    private $_tTraitsInstances   = array();  // ce tableau contient toutes les instances créées par le constructeur

    /**
     * Constructeur
     * création des instances de chaque classe Trait
     */
    public function __construct() {
        // ::::: build instance for each Trait class :::::
        foreach($this->_tTraits as $className) {
		$this->_tTraitsInstances[] = new $className;
	}
    }
}

Ensuite, nous allons reporter chaque appel de méthode, si elle n'existe pas dans Child1, vers l'un de ses Traits, si cette méthode existe.

/**
 * Méthode magique __call()
 * On va reporter chaque appel sur une des instances des classes mères
 * @param string $funcName
 * @param array $tArgs
 * @return mixed
 */
public function __call($funcName, $tArgs) {
    foreach($this->_tTraitsInstances as &$object) {
        if(method_exists($object, $funcName)) {
		return call_user_func_array(array($object, $funcName), $tArgs);
	}
    }
    throw new Exception("The $funcName method doesn't exist");
}

Désormais, tout appel de méthode de Child1 est reporté, si elle n'existe pas dans Child1 même, vers une de ses classes Traits. Il est donc possible de surcharger une méthode de ces classes Traits simplement en la déclarant dans Child1.

Enfin, nous allons reporter toutes les lectures d'attributes (accesseurs) vers les attributs des instances des classes Traits:

/**
 * Méthode magique __get()
 * On va reporter chaque lecture d'attribut (accesseur) sur une des instances des classes mères
 * @param string $varName
 * @return mixed
 */
public function __get($varName) {
    foreach($this->_tTraitsInstances as &$object) {
        $tDefinedVars   = get_defined_vars($object);
        if(property_exists($object, $funcName)) return $object->{$varName};
    }
    throw new Exception("The $varName attribute doesn't exist");
}

Pour au final avoir:

class Child extends Parent1 {
	private $_tTraits          = array('Trait1', 'Trait2');
	private $_tTraitsInstances   = array();

	/**
	* Constructeur
	* création des instances de chaque classe Trait
	*/
	public function __construct() {
	// ::::: build instance for each Trait class :::::
	foreach($this->_tTraits as $className) {
		$this->_tTraitsInstances[] = new $className;
	}
	}

	/**
	 * Méthode magique __call()
	 * On va reporter chaque appel sur une des instances des classes mères
	 * @param string $funcName
	 * @param array $tArgs
	 * @return mixed
	 */
	public function __call($funcName, $tArgs) {
	    foreach($this->_tTraitsInstances as &$object) {
		if(method_exists($object, $funcName)) {
			return call_user_func_array(array($object, $funcName), $tArgs);
		}
	    }
	    throw new Exception("The $funcName method doesn't exist");
	}

	/**
	 * Méthode magique __get()
	 * On va reporter chaque lecture d'attribut (accesseur) sur une des instances des classes mères
	 * @param string $varName
	 * @return mixed
	 */
	public function __get($varName) {
	    foreach($this->_tTraitsInstances as &$object) {
		$tDefinedVars   = get_defined_vars($object);
		if(property_exists($object, $funcName)) return $object->{$varName};
	    }
	    throw new Exception("The $varName attribute doesn't exist");
	}
}

Nous avons tout ce qu'il nous faut pour pouvoir utiliser notre classe :

$oObject = new Child;

// appel d'une méthode d'un Trait
$oObject->method2(); // affiche "Cette fonction est dans le Trait 1"

// lecture d'une variable
echo $oObject->attribute2; // affiche "demo"

Vous voilà prêt à utiliser les Traits en PHP :-) Pour plus d'info, vous pouvez consulter la RFC de PHP sur les Traits.

plus rapide et facile qu'un array_merge : l'opérateur +

2011-03-04T00:00:00+00:00

Aujourd'hui, j'ai envie de partager avec vous une astuce PHP peu connue, mais qui est bien pratique : l'union (+) de deux tableaux

Utiliser la fonction array_merge est un vrai casse-tête quand il s'agit de fusionner des tableaux en préservant les clefs.

Or il existe un opérateur bien pratique : l'opérateur +, qui fusionne deux tableaux :

$t1 = array('a','b','d');
$t2 = array(3 => 'f',4 => 'g');
$t3 = $t1 + $t2;
print_r($t3);
<p>Array</p>
(
    [0] => a
    [1] => b
    [2] => d
    [3] => f
    [4] => g
)

Pratique non ?

Et en plus, utiliser l'opérateur + est légèrement (à peine) plus rapide qu'un array_merge classique (sur 10 000 occurrences de fusion de deux petits tableaux en PHP 5.3, sous Ubuntu, j'obtiens un très léger écart de 0.05 secondes ^^)

Attention, le comportement en cas de clefs communes est différent entre array_merge et + :

$array1 = array(
    'brand' => 'peugeot',
    'car' => '206',
    'color' => 'red'
);
$array2 = array(
    'brand' => 'renault',
    'car' => 'scenic',
    'color' => 'blue'
);

Avec array_merge : la dernière valeur rencontrée écrase la précédente :

$array4 = array_merge($array1, $array2);
print_r($array4);
Array
(
    [brand] => renault
    [car] => scenic
    [color] => blue
)

Avec l'opérateur +, la première valeur est conservée :

$array3 = $array1 + $array2;
print_r($array3);
Array
(
    [brand] => peugeot
    [car] => 206
    [color] => red
)

Merci à gege2061 de m'avoir fait remarquer une absence dans ce billet, désormais corrigée ;-)

Performance PHP : l'héritage

2011-02-25T00:00:00+00:00

Quand on parle d'orienté objet, une crainte récurrente est celle de la performance.Or le moteur PHP Objet est très bien optimisé :

(les benchs suivants portent sur des moyennes de tests executés 10 000 fois minimum, sous Linux en PHP 5.3.3 standard, et sont exprimés en secondes)

Héritage

Contrairement aux idées reçus, instancier une classe qui en hérite de plusieurs autres n'est pas plus lent qu'instancier une classe mère :

Appel de classes statiques (secondes):

Occurrences	4 héritages	aucun héritage
10000	0,7106118202	0,7099120617
1000	0,0733890533	0,0721051693

Appel de classes instanciées (secondes):

Occurrences	4 héritages	aucun héritage
10000	0,7323720455	0,7246758938
1000	0,0770690441	0,0738449097

La différence est négligeable, même sur une grosse application.

En conclusion, l'utilisation massive de l'héritage ne nuit pas à la performance d'une application...

Forum AFUP : Slides disponibles

2010-11-17T00:00:00+00:00

Tous les slides des conférences AFUP 2010 sont disponibles. Ca se passe ici : Slides Forum AFUP 2010

Forum AFUP 2010

2010-11-14T00:00:00+00:00

Le forum AFUP c'est quoi ? C'est LE lieu de rencontre des professionnels PHP à ne pas manquer. Et cette année, on fêtait les 15 ans de PHP !

On a eu le droit à des grands noms, comme Rasmus Lerdof, Zeev Suraski (respectivement créateur de PHP et de Zend quand même ! Si si, pour la petite anecdote si beaucoup de fonctions PHP en C sont préfixées par zend_ c'est pour ZEev Surasky et aNDy Gutmans, l'autre fondateur de Zend).

Et aussi d'autres noms moins connus mais qu'il est bon de connaître et suivre en France : Julien Pauli, Pascal Martin, Eric Daspet...

Bref, un forum intéressant, je pense essayer d'y retourner l'année prochaine ! En attendant je vous prépare une petite synthèse des conférences que j'ai préferées...

Forum AFUP 2010 : Plein PHAR

2010-11-14T00:00:00+00:00

Première conférence intéressante : Plein Phar, de Fréderic Hardy.

Je vous livre mes notes en vrac, en espérant que ce soit lisible :

Introduction

Phar = JAR en Java (archive qui regroupe et éventuellement compresse plusieurs fichiers en un)

Concaténer plusieurs fichiers en 1
Compression (zLib, Tar…)
Sécurité : openSSL possible, signatures
Executable ou non

Peut être inclus très facilement en PHP :

require "phar://...";

Structure

Un fichier Pahr contient:

Un fichier de démarrage (Stub) en PHP
- Environnement
- Autoload
- Configuration
Un manifeste (structure)
les fichiers
[Éventuellement une Signature]

Métadonnées

Utilisation possible de metadonnées (un peu comme les annotations). On peut y mettre n'importe quoi : Auteur, release, version…

Je pense que ça peut être très pertinent de les utiliser pour gérer les versions : si avec un SVN c'est assez simple, le SVN ne fonctionne que dans un seul sens (on connaît la version en amont). Pour un serveur qui déploie souvent, sur des serveurs clients dont il n'est pas maître, prévoir une surcouche des versions par le Phar permet de mettre en place des systèmes de mise à jour automatique... Bref, une piste à creuser.

Compression

3 extensions :

- Phar - PharTar - PharZip

Il est possible de créer ses propres extensions, mais il vaut mieux utiliser ces 3 principales

Point de montage

On peut monter dans le phar des fichiers externes (mount)

Test unitaires

A la création, le stub n’est pas testé. Une fois le phar créé, les erreurs sont difficiles à gérer et opaques.

On peut utiliser des tests unitaires pour :

S’assurer que les données sont complètes (utilisation de la signature)
S’assurer des injections de dépendance
En utilisant des mocks (objets répliquant virtuels d’objets, qui permettent de modifier son comportement. Ex : créer un mock d’une connexion mysql)

Performance

Varie selon l’environnement.

Compressé : chute des perfs de 10/15%. C’est résolu par l’utilisation de phar.cache_list. (mais on a évidemment de l'autre côté des gains de Ram)
Standard : baisse de 2/3%

Phar est compatible avec APC (et ça c'est une bonne chose ^^)

Obfuscation

Un phar n’est pas obfuscé ! Il ne faut pas compter dessus pour protéger le code (même s'il n'existe aucune solution ultime, Phar n'en est pas du tout une)

Déploiement et SVN

Une bonne idée : il suffit d’utiliser Hudson pour regénerer le Phar à chaque commit

Avec le Zend Framework

On peut imaginer mettre tous les fichiers du ZF dans un Phar, puis mettre le controller frontal dans le Stub.

Ressources

Un bon tutoriel (et au passage un bon blog) : http://blog.pascal-martin.fr/post/php-5.3-phar-php-archive

Voici mes notes en vrac. Cette conférence m'a donnée pas mal d'idée, je pense que je vais m'en servir dès lundi. Prochaine étape la prod' ?

Un blog est né (encore!)

2010-11-14T00:00:00+00:00

Aujourd'hui, ouverture de mon blog. Développeur PHP à plein temps et fan de SEO à mes heures, je compte vous proposer une synthèse de ce que je pense pertinent de connaître, aussi bien en veille qu'en contenu de fond.

J'espère que cela vous plaira ! ^^