Agile Barcamp Lyon : Kanban

Je connais la méthode Scrum, pour en pratiquer une partie dans mon équipe, et j’étais intéressée par l’approche Kanban, qui n’est pas itérative avec des sprints isolés comme Scrum, mais qui prend en compte les arrivées en cours de route (les bugs, par exemple) et permet de les intégrer au flux. (Nous traitons ces demandes entrantes dans nos sprints en utilisant la focalisation.) De plus, mon envie de découvrir Kanban a été récemment augmentée, surtout à travers un retour d’expérience, car je suis passée à un travail de maintenance qui peut se faire sans sprint.
… 

 

Nous avons intégré les technologies open sources OpenLayers et OpenStreetmap à nos logiciels

L’objectif du projet était de pouvoir projeter l’effectif (RSS ou patient) défini par le filtrage PMSIpilot sur une carte interactive.

Le mécanisme de filtrage existant dans PMSIpilot permet de visualiser les aire de recrutement selon tous les axes d’analyses présents : GHM, DMS, âge, actes, diagnostics … et toutes leurs combinaisons.

Voici un petit aperçu des résultats.

Répartition de la chirurgie ambulatoire en Bretagne

Répartition de la chirurgie ambulatoire en Bretagne

 

Astuces PHPStorm

Pour coder, nous utilisons majoritairement l’IDE PHPStorm. PHPStorm est vraiment agréable à l’utilisation, et plutôt riche en fonctionnalités, tout en gardant une personnalisation fine. La personnalisation nous permet d’avoir chacun les raccourcis-clavier de notre choix, du coup, quand on souhaite intervenir sur un autre poste de travail, c’est souvent suprenant.

Mais c’est également l’occasion de découvrir et d’échanger sur le logiciel, voilà des astuces pour PHPStorm que j’ai découvertes petit à petit, par hasard ou par transmission directe de la part des collègues.

Connexion avec SCM (Git)

PHPStorm implémente les fonctions du SCM dans des menus contextuels, mais parmi mes collègues, je crois que nous utilisons majoritairement la ligne de commande pour interagir avec Git.

Rollback dans la marge

Les marges affichent les modifications faites sur le fichiers par une barre de couleur dans la marge, et en cliquant sur la barre, il est proposé de faire un rollback de nos modifs. Pratique pour supprimer les lignes vides ajoutées en plus (et éviter des modifications sur un fichier qui n’a pas été réellement amélioré au final).

Je soupçonne le Colonel Moutarde avec une Regex dans la lib

Un clic-droit dans la marge du fichier propose “Annotate”, cela revient à utiliser le Blame de Git. On a donc un affichage sur le dernier commit (hash et auteur) pour chaque ligne du fichier.

Configuration du panneau TODO

Tout comme Eclipse, PHPStorm propose des panneaux pour les différentes fonctionnalités. Un des ces panneaux (numéro 6) se nomme TODO. Par défaut, il présente une liste de fichiers indexés parce qu’ils ont un TODO dans leur contenu.

Le plus ?

On peut configurer des filtres, pour indexer n’importe quel autre contenu.
Par exemple, on peut imaginer indexer le mot-clef DEBUG, et laisser dans notre code des DEBUG pour signifier qu’il faudra repasser à cet endroit avant publication des fichiers, pour ôter le code spécial Debug Mode.

Le petit défaut est que le panneau garde son nom de TODO, quelle que soit la configuration.

Rechercher dans vos fichiers modifiés

Un choix de scope de recherche intéressant se trouve dans la boîte de dialogue de recherche : “Changed Files” au sens Git du terme. Cela permet de chercher dans les fichiers modifiés et pas encore commités.
Quel intérêt ?
La recherche sur tout le projet s’avère assez longue, pour nous qui avons une énorme base de code.

Find Usage…

En menu contextuel sur le nom d’une méthode ou d’une fonction, on peut lancer une recherche “Find Usage…” et PHPStorm recherche tous les fichiers contenant cette méthode.
La liste des éléments est filtrée sur : usage en lecture, appel de la méthode, nommage uniquement (en commentaire par exemple).

Bémol : cela fonctionne parfaitement pour des méthodes nommées et moins pour tout ce qui est système de Factory  (construction selon le nom des méthodes/objets).

Zoom à la molette

Comme dans beaucoup de logiciels, cette manipulation agrandit la police du texte (zoom).


Le petit plus de PHPStorm : chaque onglet est indépendant dans son zoom. Encore plus fort : quand on splitte notre fenêtre de travail en deux, on peut zoomer sur un fichier dans une partie du splitte sans impact sur l’autre partie (oui, sur le même fichier).

Utiliser ses deux écrans

Quand on saisit un onglet et qu’on le glisse-déplace hors de la fenêtre applicative de PHPStorm, l’onglet se met dans une fenêtre autonome, et on peut lui ajouter d’autres onglets. Ensuite, on peut replacer les onglets dans la fenêtre principale.
C’est plutôt intéressant pour avoir un fichier sur un second écran, sans avoir à splitter la vue.

Toute la ligne

Et une astuce tellement simple qu’on se demande pourquoi ne pas y avoir pensé avant : quand on fait un Ctrl+C sans sélection, la ligne sur laquelle on se trouve est copiée (fonctionne avec couper aussi). Pas besoin de sélectionner la ligne auparavant.

Et vos astuces ?

Ces astuces sont celles que j’ai notées au cours du dernier mois, et qui pourront vous servir. Evidemment, cet article est loin d’être exhaustif, alors n’hésitez pas à l’enrichir.

 

PMSIpilot était présent au forum PHP 2010

PMSIpilot team au #forumPHP 2010

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.

Frederic Hardy

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.

 

Code coverage des tests unitaires d’un projet symfony et intégration dans Hudson CI

Après avoir écrit quelques tests unitaires, on peut se demander si les tests écrits couvrent
une partie assez importante du code de la classe testée, quelles peuvent être les classes restantes à tester ou tout simplement avoir une idée de l’étendue du projet couverte par des tests unitaires.

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

    executer_script

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

graph

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

tableau_floute

 

De qui se moque-t’on ?

Derrière ce titre un peu faible, se cache un billet qui va, potentiellement, changer votre vie. Pour autant que vous écriviez des tests unitaires (mais tout le monde fait ça ici non ? en tout cas on en fait chez PMSIpilot …). En effet, je vais vous parler d’un truc génial: Mockery. Mockery, c’est un framework de Mock (il parait qu’on dit Bouchon en français, mais c’est vraiment trop ridicule), écrit par Pádraic Brady, qui fait partie de la core team du Zend Framework. Du lourd quoi. … 

 

Symfony chez PMSIpilot

PMSIpilot conçoit et réalise une suite informatique dédiée à l’amélioration de la gouvernance des hopitaux publics. Le périmètre fonctionnel peut s’apparenter à un outil décisionnel ou de Business Intelligence concernant l’activité, d’un point de vue financier et médical, de l’hôpital.

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.

lines of code

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

emma code coverage

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

navigateurs

tests selenium

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.