Deux conférences étaient animées par mes collègues Frédéric et Geoffrey dont une qui évoquait tout particulièrement un retour d’expérience de PMSIpilot : la migration de Subversion vers Git.

Nous avons pu tous les trois suivre les nombreuses conférences du forum et échanger avec les participants de qualité. Ce fut l’occasion de renouer contact avec les professionnels du secteur et prendre le pouls de la vitalité de l’écosystème PHP. J’ai particulièrement apprécié la conférence de Jean Marc Fontaine sur les revues de code et celle de Renaud Bidou sur les web services (hé oui, elles ne parlaient pas de PHP ;-) ).

Vous trouverez sur internet de nombreux compte-rendus et interviews, par exemple ceux de La Ferme du Web. Pour ma part je suis revenu du forum avec plein d’idées fraiches, pour l’équipe technique de PMSIpilot, issues des conférences et des échanges avec les participants.

Je retiens tout de même quelques points essentiels :

• l’industrialisation, le choix d’un framework, les méthodes de gestion de projet restent des sujets de débats centraux (mots polis pour ne pas parler de troll !),
• l’outillage périphérique autour des projets intéresse beaucoup,
• on trouve des décalages importants dans les pratiques autour du langage. Entre son usage chez Orange ou l’industrialisation est extrèment poussée et les pratiques de certains petits projet  il y a un gouffre,
• ce décalage se retrouve parmi les acteurs, on passe allègrement  du bidouilleur génial à l’industriel, du combo jean+t-shirt+barbe au costume cravate,
• le niveau technique des acteurs est finalement toujours très hétérogène (ce serait une bonne idée par exemple d’indiquer des pré-requis pour pouvoir suivre certaines conférences par exemple),
• a part quelques exemples tout ça manque de retours terrains ! Beaucoup de confs présentaient un état de l’art ; j’ai eu l’impression (dans les questions) que cela laissait quelques personnes sur leur faim.

Bravo à l’afup pour ce bel évènement. Ce sera un plaisir d’y participer l’année prochaine.

Olivier Mansour, notre directeur technique sera aussi présent. Si vous êtes également présent au forum, n’hésitez pas à venir à leur rencontre pour échanger autour de PHP et de l’activité de PMSIpilot.

Pour cela nous utiliseront le plugin Hudson Emma pour l’affichage dans Hudson, ainsi que le plugin symfony agEmmaCoverageReport pour générer le fichier xml au format emma.
Le format « emma » est à la basée utilisé en java, plus d’infos sur le site du projet.

Utilisation de la tache de génération du rapport xml

L’extension xdebug doit être installée (mais pas forcément activée).

Les fichiers testés sont trouvés en utilisant l’autoload, les fichiers de tests doivent être nommés de la façon suivante : nomDeLaClasseTesteeTest.php, par exemple le classe « qualifactCellFormatterEuro » aura pour fichier de test « qualifactCellFormatterEuroTest.php ».

Voyons tout d’abord comment fonctionne la génération du fichier xml de rapport :

Si xdebug est activé par défaut :

./symfony ecr:report --xml=cheminOuSauverLeXml.xml

Mais sur le serveur d’intégration cela n’est probablement pas le cas, et il serait
gênant d’avoir à l’activer pour les autres tests alors que qu’il est seulement utilisé pour le coverage.
Pour cela on peut indiquer à la tache le chemin ou se situe l’extension xdebug (par exemple sur une Mandriva il se situe ici : « /usr/lib/php/extensions/xdebug.so »). La tâche sera alors appelée de cette façon.

./symfony ecr:report --xml=cheminOuSauverLeXml.xml --xdebug-extension-path=/usr/lib/php/extensions/xdebug.so

Intégration dans Hudson CI

Création et configuration du job

• Dans le menu de gauche : « Nouvelle Tache »
• Cliquez sur « Construire un projet free-style »
• Donnez un nom au job
• Entrez alors l’url du dépôt
• Après checkout nous voulons lancer les tests unitaires ainsi que la tache créant

le rapport de coverage, nous allons donc ajouter une étape au build. Celle ci sera de
type « Executer un script shell »

• Dans la liste des commandes nous allons donc lancer les tests et le coverage de cette façon :

$WORKSPACE/symfony test:unit --xml=log/unit.xml
$WORKSPACE/symfony ecr:report --xml=log/coverage.xml



• Pour les résultats des tests unitaires, cochons la case « Publier le rapport des résultats de tests JUnit » puis dans « XML des rapports de test » nous indiquons ou chercher le fichier XML en saisissant : « log/unit.xml »
• Pour le code coverage, cochons la case « Record Emma coverage report » puis dans « Folders or files containing Emma XML reports » nous indiquons où chercher le fichier XML en saisissant : « log/coverage.xml »
• Il faudra ensuite exécuter le job

Affichage du rapport de code coverage

Après lancement du job les résultats du code coverage apparaissent dans la section « Coverage Trend ».

Pour un détail du coverage il faut cliquer sur le graphique.

La couverture du code par les tests unitaire est alors présentée par package ainsi que par classe, méthode, bloc et ligne.

Les blocs sont tous à 0 car c’est une notion seulement utilisée en java. Une méthode ou une classe est couverte si toutes les lignes qui la contiennent sont couvertes. Ainsi certaines classes, ne contenant aucune ligne de code, ayant juste leur déclaration, seront indiquées comme couvertes à 100%.

Bon, mais d’abord, pour les nouveaux, qu’est-ce donc qu’un Mock ? Je ne saurais mieux l’expliquer que Padraic dans son superbe blogpost, mais pour les pressés, on va faire une version courte. Un mock est un remplacement d’objet pour isoler un test. Par exemple, on peut créer des mocks de base de données pour éviter d’instancier tout Propel a chaque test. Voilà, ça c’est pour la théorie.

Toujours pas clair ? Un petit exemple alors. Tout à l’heure j’ai écris des tests (disons pour une classe qui s’appellerait Foobar). C’est une super classe, qui fait son job, pas de problème, mais qui demande en constructeur 2 objets: un Foo et un Bar. Disons que Foo et Bar coûtent un peu cher à instancier. J’ai donc 2 choix: instancier des vrais objets (c’est mal, mais c’est qu’on fait en général), ou utiliser des mocks (c’est bien, mais on le fait pas parcequ’on a la flemme d’écrire les mocks). Qu’à cela ne tienne, avec Mockery, c’est fait en 2 coups de cuiler a pot:
$foo = Mockery::mock('Foo', array('getCreatedAt' => date('Y-m-d H:i:s'));
$bar = Mockery::mock('Bar', array(
'getIsSaved' => true,
'getTitle' => 'recherche titre',
'getDescription' => 'recherche description',
'getIsPublic'=> true ));
$object = new Foobar($foo, bar);
Donc ça c’est la forme un peu « rapide » de création de mock. Pour chaque méthode que je spécifie dans l’array d’options, mockery assigne en valeur de retour la valeur en face. Donc $recherche->getTite() renverra « recherche titre » par exemple. C’est cool non ? Bien sur on peut aller super loin avec Mockery, comme par exemple dire « la méthode tartenpion de l’objet pmsipilotUser doit etre appelé avec en paramètre perlinpinpin et renvoyer un objet MerlinLenchanteur et ne doit être utilisée qu’une fois sinon la terre explose »:
$merlin = new MerlinLenchanteur();
$user = Mockery::mock('pmsipilotUser');
$user->shouldReceive('tartenpion')->with('perlinpinpin')->once()->andReturn($merlin);
(ok je triche encore un peu on ne peut pas vraiment faire exploser la terre) Par contre si on veut vérifier que tout a bien été appelé comme on l’a défini, il ne faut pas oublier de le dire a la fin: Mockery::close(); Un dernier exemple pour vous convaincre de la puissance de Mockery. On rencontre souvent du code qui viole la Loi de Demeter, et qui de fait devient difficile à tester. Point de chichi avec Mockery, car il permet aussi de Mocker une chaine d’appels complète très simplement: $mock = Mockery::mock('demeter'); $mock->shouldReceive('foo->bar->quux->roflpwn->demeter')->andReturn('omgponies'); Magique non ? Pour encore plus de trucs magiques, je vous invite à lire la doc sur la page github de mockery. Voilà j’espère que ça vous aura donné envie d’utiliser un peu plus de Mocks dans vos tests :-)

Exemple: disons qu’on a un fichier /tmp/foobar.csv avec le contenu suivant:

foo;bar
baz;quux

Nous pouvons simplement parcourir les lignes avec le code suivant:

<?php

$file = new SplFileObject('/tmp/foobar.csv');

foreach($file as $line)
{
  $data = explode(';', $line);
}

C’est pas mal non ?

On pourra arguer qu’on arrive au même genre de résultat en utilisant file, mais l’empreinte mémoire est loin d’être la même (sans compter l’approche object de SplFileObject qui va nous permettre plus tard de faire des trucs rigolos).

Mais il y a encore mieux. SplFileObject gère le format CSV, de deux manières différentes. Vous pouvez au choix utiliser SplFileObject#fgetcsv ou bien (pour garder une API cohérente) expliquer à SplFileObject que le fichier que vous traitez est un CSV.

Attardons nous sur cette dernière méthode (toujours avec le même /tmp/foobar.csv):

<?php

$file = new SplFileObject('/tmp/foobar.csv');
$file->setFlags(SplFileObject::READ_CSV);
$file->setCsvControl(';');

foreach($file as $data)
{
  var_dump($data);
}

Magique !

Vous pouvez bien évidemment (comme on le disait plus haut) surclasser SplFileObject pour lui ajouter tout un tas de trucs rigolos (par exemple chez nous on détecte les BOM, et on configure automatiquement les fichiers CSV).

Bien sur, SplFileObject permet bien d’autres choses, quasiment tout ce que vous pouvez faire avec les fonctions utilisant un handler fopen est disponible (à quelques exceptions près, comme par exemple fread) (globalement c’est assez orienté lecture ligne par ligne).

Il y a deux ans, le projet a connu un virage technologique important. D’une technologie obsolète et d’un conception un peu hasardeuse (PHP4, framesets, …), un projet de refonte vers symfony 1.2 a été lancé. Cette refonte a durée un peu plus de 20 mois / homme et a abouti à un seul projet symfony contenant plusieurs applications. PMSIpilot a, dès le début, pris le parti d’utiliser les conventions de symfony et le paradigme MVC.

En chiffres, aujourd’hui

• 12 développeurs (en constante augmentation !),
• 410 déploiements,
• environ 50 000 utilisateurs répartis sur toutes ces instances,
• environ 220 000 lignes de code PHP écrites et maintenues,
• la prochaine release importante intégrera symfony 1.4.

Comment symfony nous aide

La documentation et la communauté

La documentation de symfony nous permet d’intégrer rapidement une nouvelle recrue. Le fait de trouver de nombreuses contributions au framework (sur symfony-project.org ou bien ailleurs) est très facilitant également. Nous utilisons de nombreux plugins comme :

• sfPropelPlugin
• dwJpGraphPlugin
• sfDB4toPropelPlugin
• sfPropelSqlDiffPlugin
• sfJqueryReloadedPlugin
• sfValidatorHtmlPlugin
• sfJobQueuePlugin
• sfFormExtraPlugin
• …

Parfois tels quels, parfois un peu modifiés pour nos besoins.

Le développement

• le framework nous donne une bonne structure de base pour l’organisation du code source ainsi que des normes de codage, sur une équipe aussi importante cela permet de gagner du temps,
• mis à part i18n et l’admin générator, on utilise la quasi totalité de la stack de symfony : MVC, le cache, les filtres, les évènements, le système de gestion des utilisateur, l’ORM, les tasks, …
• symfony est suffisament flexible pour que nous puissions facilement l’adapter à nos besoins parfois bien spécifiques ; aujourd’hui nous avons étendu : sessionStorage, viewCacheManager, ApplicationConfiguration et ProjectConfiguration, sfAction, sfComponent, sfView, frontWebController, plein de choses autour de propel …
• nous ajoutons des fonctionnalités tous les jours, et une grande réactivité nous est demandé pour suivre l’évolution de la réglementation ; le framework de test nous permet de garantir aucune régression et de livrer des correctifs très rapidement si nécessaire (voir plus bas),
• le système de task, de gestions des fixtures, d’environnement de développement permet de proposer des méthodes faciles d’accès au développeur permettant d’instancier un environnement de dev complet et identique à ses collègues.

L’intégration continue

Dès la refonte du projet, sécuriser ces mises à jours a été une priorité. C’est pourquoi nous avons investi dans le développements d’un grand nombre de tests fonctionnels et leur suivi au sein d’une instance Hudson.

Les tests fonctionnels chez PMSIpilot vérifient des cas d’utilisation standards mais sont surtout utilisés pour valider la totalité des données chiffrées présentées. A ce titre les quelques 250 000 tests fonctionnels sont majoritairement générés (on ne teste pas vraiment « les tests » mais « les étalons des tests »).

La création de nouvelles classes a entrainé l’écriture d’une centaine de tests unitaires (avec des efforts pour optimiser la couverture du code).

Enfin, nous avons commencé l’écriture de tests d’interface avec Selenium (une dizaine aujourd’hui) afin de gérer plus facilement les différents navigateurs (parfois un peu datés) de nos clients. (oui, ça n’a rien à voir avec symfony …)

Pour boucler la boucle on a, en projet, l’intégration automatique de tests de montée en charge. (un outil à suggérer ?)

Comment nous tentons d’aider symfony

Dans la mesure du possible, nous tentons de faire bénéficier la communauté symfony de nos travaux, en remontant des bugs et en proposant des plugins . Nous essayons également de partager les slides des réunions techniques organisées au sein de l’équipe afin de diffuser les compétences au sein des équipes.

Chez PMSIpilot, on aime symfony. Si c’est votre cas aussi, n’hésitez pas à proposer votre candidature au service technique.

tickets :

• #1776 (fixed) [PATCH] checkbox arrays not checked with fillin enabled
• #2916 (wontfix) Bug in Spyc : losing data with successive load/dump
• #3792 (fixed) i18n XLIFF do not handle entities correctly
• #4306 (wontfix) sfDebugConnection does not handle correctly logging of nested transactions
• #4620 (fixed) [PATCH] – PHP5NestedSetBuilder generate a require to lib/model/om/Basesometing
• #5374 (fixed) Changeset [14122] breaks config parsing
• #5402 (fixed) sf doc refer to the getDispatcher() method but it doesnt exist
• #5964 (fixed) Notice sur sfTestBrowser
• #7446 (fixed) sfOutputEscaper::unescape($vars) appelé systématiquement dans _call_component
• #6639 (fixed) Option passed to a widget schema do not get passed through to an sfWidgetFormChoice’s renderer
• #8365 (opened) sfFinder not_name does not works if results intersects due to #6589
• #8384 (opened) sfPropelPluginConfiguration::filterAutoloadConfig should exclude vendor dir just like in the plugin autoload file
• #8402 (opened) sfPropelBaseTask should add propel include path by using sf_propel_runtime_path
• #8457 (fixed) sort the parameters in order to compute the cache key the same way when parameters are submited in different order

plugins :

• omCredentialsMapPlugin : This plugin allows you to check  all the credentials in your project and detect action not or badly securised
• omCrossAppUrlPlugin : Simple helper to get cross app urls
• elXHProfPlugin : Integration of XHProf profiler (simple API to profile + web debug toolbar integration)

Il arrive souvent lors d’un développement informatique que l’on soit confronté à un problème de performances.

On essaie souvent d’optimiser des bouts de code que l’on croit être la cause des ralentissements mais sur des projets assez complexes il arrive qu’on ne regarde pas forcément au bon endroit.

Les étapes à suivre pour résoudre des problèmes de performances sont donc les suivantes :

1. Mesurer : il est indispensable de connaître les performances actuelles de l’application/bout de code qui sous-performe.
2. Optimiser (ou en tout cas essayer) : cela est lié à votre code, je vous laisse faire cette partie :)
3. Comparer : est-ce que l’optimisation effectuée est vraiment efficace ? Tant qu’on n’est pas satisfait on revient à l’étape 2.

Je vais aborder dans cet article des solutions disponibles dans l’univers PHP pour permettre de travailler sur les étapes 1 et 3.

Mesurer les performances : le profiling.

Xdebug

Beaucoup de développeurs PHP connaissent xdebug qui propose des fonctionnalités de profiling.
Sous la forme d’extension PHP il permet d’avoir un fichier de profil de performances à partir du moment où l’on a activé le profiling.
On analyse ensuite ce fichier de résultat à l’aide d’outils comme KCacheGrind, WinCacheGrind, MacCallGrind… suivant notre plateforme.
Cela fonctionne bien pour du code PHP pas trop gros mais dès que le code se complexifie, les fichiers de profil peuvent devenir énorme (nous avons déjà ici vu des fichiers de plusieurs Go !).
L’activation du profiling a aussi pour effet de bord pas très pratique un gros ralentissement du code profilé.

En bref, on a longtemps utilisé xdebug par manque d’alternatives.

XHProf

Développé par Facebook et assez récent dans le monde PHP (il a été diffusé en mars 2009), XHProf est un profiler qui a énormément d’avantages sur xdebug.
Les fichiers de profil sont ridiculement petits quand on vient de xdebug (400ko vs 1.2Go pour un même code profilé sur notre projet).
L’activation de xhprof n’a quasiment aucun impact sur les performances du code analysé.
Facebook fournit des scripts PHP pour analyser directement en web les résultats du profiling.
Un dernier avantage, et non des moindres, est que l’on n’est pas obligé de profiler tout notre process PHP mais uniquement une portion de code. Cela n’est pas possible avec xdebug qui profile le process entier.

Comparer les résultats

Xdebug

Il est très difficile de comparer précisément deux profils de performances issus de xdebug. Si en plus les fichiers sont énormes cela rend la tâche impossible.

XHProf

La comparaison de profils est native dans XHProf ce qui permet très rapidement de voir si nos optimisations sont concluantes.

Intégration avec symfony

Après avoir commencé à utiliser XHProf, il nous a semblé judicieux de voir comment l’intégrer facilement dans un projet symfony. C’est ainsi que j’ai développé le plugin elXHProfPlugin qui nous permet d’avoir directement au niveau de la web debug toolbar de symfony la liste des profils de performances ainsi que la possibilité de comparer deux fichiers de profil (et ainsi profiter de la fonction native de comparaison de XHProf).
Voici 2 captures d’écrans qui illustrent l’intégration dans la web debug toolbar et la comparaison de profils.

Intégration de XHProf à la web debug toolbar de symfony

Comparaison de runs avec XHProf

Conclusion

Après avoir utilisé Xdebug pendant des années, nous utilisons XHProf avec beaucoup de facilité. Sa légéreté et son intégration à la debug toolbar de symfony nous permet de faire facilement des optimisations là où nous serions allé à reculons en utilisant Xdebug.

Et surtout n’oubliez pas cette phrase de Donald Knuth lors de vos développements :
« We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil« .

Merci à Eric Lemoine pour sa démo sur XHProf : l’intégration à la debug bar SF et la comparaison de runs va nous permettre d’être efficaces lors de nos profilings !