Le blog sans prétentions d'Olivier Mansour
Et c’était bien. J’espère pouvoir y retourner l’année prochaine, surtout pour pouvoir échanger avec quelques personnes que je ne rencontre qu’à ce genre d’évènements.
Je me suis fendu d’un petit retour sur le .org de pmsipilot.
Comme j’en suis à revenir deux ans en arrière je me souviens, quittant ma précédente entreprise (une SSII), et étant assez sollicité par des anciens clients pour continuer ou poursuivre des missions de conseils (AMOA mais surtout AMOE). Sur le moment, je n’avais guère la tête à ça mais j’ai un peu envisagé la création d’une structure permettant de faire ces missions. Au final, je n’ai pas donné suite et j’ai simplement conseillé quelques anciens clients au téléphone (dont un qui devais gérer une équipe de dev à l’île Maurice … ).
En lisant le twitter de Simon Sineck j’ai réalisé pourquoi je n’avais pas fait ce choix.
« Si tu veux aller vite, vas y seul. Si tu veux aller loin, vas y en groupe. » (traduction horrible par mes soins)
C’est un peu pourquoi je ne suis pas freelance. Seul, il est plus difficile de changer le monde comme je voudrais le faire avec mon entreprise.
Un petit retour sur comment nous utilisons symfony chez PMSIpilot. Commentaires et questions bienvenus !
ps : au delà des trucs de geek, ce qui est sympa à la technique chez PMSIpilot, c’est l’ambiance et la qualité des collaborateurs côtoyés ; croyez moi, c’est pas partout comme ça.
La liste des modestes contributions à symfony a été mise à jour sur pmsipilot.org. On a trouvé deux trois petites choses ;-) et proposé pas mal de patchs.
http://www.pmsipilot.org/2010/03/25/contributions-a-symfony/
Nous utilisons maintenant symfony 1.4 qui propulsera la prochaine version majeure de nos outils de pilotage.
Lors du symfony live 2010 (non, je ne vous ferais pas un compte rendu de symfony live 2010, il y en a de très bien déjà partout sur l’internet) beaucoup de personnes ont interpellées la core team au sujet des problèmes de compatibilité descendante avec symfony.
Récemment, dans ma société, j’ai migré un projet de symfony 1.2 à 1.4. Pas un petit, 220 000 lignes de code (hors symfony, code généré et plugins). A vrai dire, vu comme ça, je me disais que ça marcherait jamais.
J’ai utilisé les documents suivants :
J’ai commencé par mettre à jour lib/vendor/symfony en 1.3 et fait tourner la tache ./symfony project:upgrade1.3. La plupart des YLM ont été modifiés correctement, tous les héritages des formulaires, la gestion de la disparition du common filter … tout ça a été fait automatiquement pour moi ! project:validate m’a ensuite indiqué la liste des méthodes et fonctions dépréciées. Un peu de surcharge de méthodes, de récupération de vieux helpers, et voila. En quelques heures le projet était d’équerre. Ceci fait, j’ai ensuite migré vers la 1.4.
Le plus pénible à gérer fut la fin de la gestion des tableaux dans les méthodes de sfParameterHolder. project:validate a bien indiqué les classes des contrôleurs à changer mais n’a pas pu chercher dans les autres classes les (maintenant) mauvaises utilisations des tableaux. Pour ça, les tests ont bien aidé, et le reste de l’équipe à résolu quelques occurrence de ce problème les jours suivant.
Pour ma part, des migrations comme ça j’en veux bien tout le temps !
Je travaille avec symfony depuis la version 0.6.3, et je ne l’ai jamais trouvé aussi facile à utiliser.
Mais c’est pour améliorer les performances de nos applications grâce à un plugin développé par un de mes brillants collègues : elXHProfPlugin.
Mon équipe l’utilise sans douleurs depuis plusieurs semaines et avec de nombreux gains à la clef. C’est la démocratisation du profiling qui, jusqu’alors, était plus réservé aux CP techniques tant sa mise en place, avec xdebug, était pénible.
Plus d’informations sur le .org de PMSipilot.
Le site de l’équipe technique de PMSIpilot est en ligne sur pmsipilot.org. La bise à celui qui nous trouve un joli thème !
Avec des trucs supers intéressants comme :
(infamie, il n’y a pas de favicon)
PMSIpilot (je travaille actuellement dans cette société), lance un nouveau produit destiné à équiper les services d’urgences des hôpitaux publics et privés.
Je vous invite à découvrir le site dédié à cette solution : http://dpu.pmsipilot.com.
Ce dernier comporte quelques vidéos qui vous permettront de découvrir l’application. Techniquement, la technologie client léger LAMP est utilisée et le framework de développement est Symfony (les treeviews sont fait avec extjs).
Je suis particulièrement content de cette réalisation. Parce qu’elle est de très bonne facture, tant sur le plan technique que fonctionnelle (je salue par ailleurs l’ensemble des développeurs de ce projet !) mais que son mode de commercialisation, si il est assez fréquent en informatique, est assez innovant, selon moi, dans le milieu de la santé.
Suite à la publication d’une tache permettant de lister les autorisations dans un projet symfony, j’ai packagé l’ensemble dans un plugin et libéré ça dans le repository de Symfony.
C’est disponible ici : http://www.symfony-project.org/plugins/omCredentialsMapPlugin
Exemple de sortie du plugin :
pmsipilot admin anonymiseur : admin_mco_donnees
pmsipilot admin atypie : acces_dossiers_medicaux AND acces_mco
pmsipilot admin baseMessageAccueil : acces_mco
pmsipilot admin coherence : admin_mco_donnees
pmsipilot admin datim : acces_dossiers_medicaux AND acces_mco
pmsipilot admin detailRss : acces_dossiers_medicaux AND acces_mco
portail accueil index : OFF
portail accueil saveData : OFF
portail default checkcalculencours : OFF
Les colonnes représentent respectivement : l’application, le module, l’action et les credentials associés. Merci de consulter le REAME pour plus d’infos. Tout retour est le bienvenu.
Encore un beau week end passé autour de Marseille avec mes collègues de PMSIpilot.
C’était quand même le pied !
