• création d’une branche de travail à partir de la branche stable,
• réalisation du développement,
• validation du développement en exécutant les tests sur la branche de travail,
• merge de la branche de travail sur la branche stable.

À PMSIpilot, nous utilisons Jenkins pour notre intégration continue et l’exécution des tests de validation techniques. Chaque développeur a, sur son poste, une instance de Jenkins branchée sur son dépôt.

Il est vite apparu que le rendu de Jenkins, dont l’interface est plus orientée vue “par job”, ne convenait pas dans le cadre de la validation de nos développements. C’est là où Jenkins Khan intervient, en nous fournissant une interface orientée vue par branche afin de suivre la validation.

En cumulant les branches à valider, avec, pour chacune, différents tests à valider, il est vite devenu difficile de suivre quels étaient les jobs lancés pour chaque branche et l’état de ces différents jobs au fur et à mesure du développement.

Les développeurs se trouvaient en manque d’outil pour faire ce suivi de validation. Chacun faisait alors avec sa propre méthode (papier, feuille de calcul, etc.).

Une version plus synthétique correspondrait au tableau ci-dessous :

Le maintien d’une telle feuille est vite devenu fastidieux, un correctif entraînant, la plupart de temps, la relance d’un nouveau build Jenkins. De plus, Jenkins ne nous facilite pas la tâche pour suivre l’état d’un même job s’il est lancé sur plusieurs branches : aucune vue n’affiche la liste des builds avec ses paramètres utilisés. Il faut donc aller sur la page d’affichage des paramètres transmis de chacun des builds pour visualiser la branche concernée par le build.

C’est pourquoi nous avons développé Jenkins Khan. L’objectif principal de cet outil est de visualiser l’état global de chacune des branches testées et l’état de ses différents jobs. Contrairement à Jenkins qui offre une vue orientée par job, Jenkins Khan a une vue orientée branche.

La partie de gauche permet de visualiser les différentes branches en cours de validation, la couleur indiquant l’état (succès, échec, en cours de traitement, en attente, etc.). La partie de droite liste pour chaque job de cette branche :

• son état,
• sa progression,
• sa date de lancement,
• sa durée,
• un lien pour le relancer,
• des liens d’accès aux pages Jenkins (résultats, console, etc.).

Désormais, lors de la validation technique d’une branche, nous saisissons le nom de la branche de travail, choisissons la liste des jobs à lancer, et voilà : il ne reste plus qu’à attendre que tous les jobs soient terminés.

Basé sur l’API de Jenkins, Jenkins Khan nécessite peu de configuration :

• l’url du Jenkins,
• un paramètre BRANCH dans les jobs.

Le reste de la configuration (vues, paramètres des jobs) est fourni par Jenkins.

Nous avons également ajouté la possibilité de planifier des jobs pour qu’ils puissent être lancés à une heure donnée. On peut ainsi lancer les jobs coûteux en ressource machine hors horaire de travail.

Jenkins Khan possède une API permettant de créer et lancer des jobs pour une branche donnée. Nous l’avons ainsi intégré dans notre dashboard qui monitore les tickets sur lesquels nous sommes en train de travailler pour indiquer l’état de la validation.

Si vous voulez en savoir plus sur cet outil, vous pouvez consulter le dépôt Github qui héberge les sources https://github.com/pmsipilot/Jenkins-Khan. Le wiki du projet https://github.com/pmsipilot/Jenkins-Khan/wiki contient la documentation sur l’installation, l’API fournie, branchement sur un LDAP, etc. sur. Vous trouverez également sur le dépôt https://github.com/pmsipilot/jenkins-php-api les classes PHP nous permettant de manipuler les serveurs Jenkins grâce à leur API.

Un Bar Camp est une « non-conférence » ouverte qui prend la forme d’ateliers-événements participatifs où le contenu est fourni par les participants qui doivent tous, à un titre ou à un autre, apporter quelque chose au Barcamp, l’objectif est avant tout de partager des idées.

Tous les participants sont invités à parler du Barcamp autant avant leur participation, qu’après, pour rendre compte de leurs échanges.

  1ère règle: Tu parleras du BarCamp.

2ème règle: Tu blogueras à propos du BarCamp.

3ème règle: Si tu veux faire une présentation, tu dois inscrire ton sujet et ton nom dans un slot de présentation.

4ème règle: Des intros de 3 mots seulement.

5ème règle: Autant de présentations à la fois que l’infrastructure le permet.

6ème règle: Pas de présentations réservées à l’avance, pas de touristes.

7ème règle: Les présentations iront tant et aussi longtemps qu’elles le doivent, où jusqu’à ce qu’elles se heurtent à l’heure de début de la présentation suivante.

8ème règle: Si c’est votre première fois au BarCamp, vous DEVEZ présenter. (Bon, on ne va pas vous forcer, mais essayez de trouver quelqu’un avec qui présenter, ou posez des questions et soyez un participant actif.)

par Tantek Çelik, en parodie des Règles de Fight Club.

L’accès se fait via une inscription préalable et est limité à 40 participants, pour des raisons légales. Au delà de 40, vous serez en liste d’attente.

Nous vous attendons samedi 3 mars de 10h à 18h dans les locaux de PMSIpilot, 61 r Sully, Lyon 6ème.

Plus de détails sur la page Barcamp de l’événement.

Le but est d’intégrer les personnes progressivement dans les équipes de nos managers techniques : Eric, William et Denis (blog de son équipe) (qui sont tout de même des types supers).

Vous rejoindrez l’une de nos 3 équipes, qui sont chaque jour confrontées à des problématiques métier complexes. Pour ce faire ces équipes structurées agissent en mode agile, avec des outils qualitatifs (git, redmine, jenkins).

Nous rechercons tout type de profil, motivé par le developpement web, désirant intégrer un editeur reconnu dans son domaine.

Voici les technos utilisés chez nous :

• PHP5, symfony 1.4 et 2
• html/css, ajax
• Jenkins
• Linux
• MySQL

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

Ils se sont assurés :
- des modalités de gestion des produits PMSIpilot (maintenance, mises à jour)
- que PMSIpilot ne disposait d’aucun accès à des données non anonymes contrôlées, optimisées et analysées aujourd’hui par plus de 550 hôpitaux grâce aux logiciels PMSIpilot.
- de l’usage fait des données d’activités médicales anonymes faites par PMSIpilot dans le cadre de notre produit BRN Bases RégioNales.

Suite au contrôle, un avis favorable de la CNIL a été émis précisant que les différentes activités contrôlées étaient conforme aux lois en vigueur.

Le code en question :

// Dans le code de mon formulaire :
$this->setWidgets(array(
...
'my_field' => new sfMyWidget(array('default' => 'my_value')),
));

// Dans le code de mon action :
if ($my_form->getDefault('my_field') == 'some_value')
{
...
}

Dans ce cas, la méthode getDefault() appelée sur mon formulaire me renvoie null alors que j’ai explicitement donné une valeur par défaut à mon widget. Pourtant, en lisant la doc de symfony sur le sujet je retiens ceci :

The setDefault(), getDefault(), setDefaults(), and getDefaults() methods manages the default values for the embedded widgets. They are proxy methods for the getDefault() and setDefault() widget methods.

Les méthodes setDefault() et getDefault() au niveau de la classe sfForm sont censées êtres des raccourcis pour les méthodes setDefault() et getDefault() de la classe sfWidgetForm().

En fait il s’avère que ce n’est absolument pas le cas et que la méthode getDefault() du formulaire ne fait jamais appel à la méthode getDefault() du widget associé.

L’appel à $my_form->getDefault(‘my_field’) n’est donc pas équivalent à $my_form['my_field']->getWidget()->getDefault().

Par conséquent, il est important de bien comprendre quelle méthode appeler et dans quel cas.

A savoir, $my_form->getDefault(‘my_field’) quand le setDefault a été utilisé au niveau du formulaire. Exemple :

// Valeurs passées dans mon formulaire :
$this->setWidgets(array(
...
'my_field' => new sfMyWidget(),
));
$this->setDefault('my_field', 'my_value');

// Ou alors valeurs passées dans mon action :
$my_form = new myFormClass(array(
...
'my_field' => 'my_value',
));


Et, $my_form['my_field']->getWidget()->getDefault() quand le setDefault() a été utilisé au niveau du widget. Exemple :

// Dans le code de mon formulaire :
$this->setWidgets(array(
...
'my_field' => new sfMyWidget(array('default' => 'my_value')),
));


Voilà, désormais vous êtes prévenus…

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.

Expérience enrichissante pour tout le monde, que nous ne manqueront pas de réitérer !

Le développement, comment y êtes vous venu ?

Pourquoi nous avez-vous rejoint ?

Les tâches variées qui sont proposées, la bonne ambiance de travail, l’aspect technique et la liberté laissée aux équipes de développement ont été pour moi les arguments principaux dans ma venue chez PMSIpilot.

Quel système d’exploitation préférez vous ?

Quel est le problème technique le plus important que vous avez rencontré ici ?

Je dirais la réalisation et le test d’un module de répartition d’une valorisation sur plusieurs éléments et selon différents paramètres. Il m’a fallu comprendre le besoin métier et réussir à le transformer en code tout en garantissant la fiabilité des calculs.

En quelques mots, quelles sont vos tâches ?

Je travaille principalement au développement de nouvelles fonctionnalités ou à l’amélioration de nos produits. J’ai la chance d’avoir en général des tâches plutôt variées. Dans une journée, mes tâches peuvent être du développement de fonctionnalités, un refactoring de l’existant, la réalisation de tests, une intervention au support afin d’aider les clients, l’optimisation de code ou de base de données, etc.

Quelle serait votre spécialité au sein de l’entreprise ?

Ayant participé à sa mise en place dans le projet, je dirais que je connais bien Propel et son Criteria. Étant dans l’équipe depuis quelques temps, j’ai plutôt une bonne connaissance globale du projet sans être forcement pointu sur un aspect en particulier.

Quels sont vos styles musicaux préférés ?

J’écoute pas de mal de rock et autres dérivés. Je suis un grand fan de Muse, et ma liste Spotify passe par des groupes pouvant aller de Placebo à Slipknot en passant par Prodigy, Transplants, The Offspring, Korn.

Votre sport préféré ?

A la base, je ne suis pas un grand sportif. J’ai quand même retenté une approche cette année entre le PMSIbasket hebdomadaire et les sorties skis. Si jamais je trouve un jour suffisamment de motivation, il faudra que je me remette au ping pong ou me mette au badminton.

Que faites-vous de votre temps libre ?

J’aime bien la lecture, rentrer dans ma Creuse natale, etc. J’apprécie également les sports mécaniques à 4 roues et faire du karting. Sinon, je geeke et ai une trop grosse consommation de séries TV.