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 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.
Le concept n’est pas plus compliqué qu’un carnet de santé en ligne :
inscription gratuite et anonyme (disons, pas plus que les autres réseaux sociaux),
saisie de vos données médicales horodatées,
possibilité de consulter (tableaux graphiques) et d’extraire ces données à tout moment.
Bénéfices immédiats :
suivi de votre santé (maladies, traitements, état général, …) sur le long terme,
fourniture simplifiée d’un historique complet et plus fiable que votre simple mémoire, à chaque rencontre avec un médecin (le nombre de fois ou on m’a demandé de réciter par cœur l’historique de la pathologie et les traitements de mon fils …),
prise de contact simplifiée avec les personnes souffrant d’affections similaires (échanges, prévention, soutien, partage).
Bénéfices induits :
consultation d’une base de données importante sur des évaluations de traitements (par exemple, le Cellcept pris par mon fils ou l’Inexium pour moi même) et de symptômes,
meilleure aperçu de l’évolution supposée d’une pathologie.
PatientsLikeMe est un véritable exemple de la puissance des données. Il n’y a pas d’administrations ni de médecins derrière la création de cet outil. Simplement des individus partageant des expériences. Bien sur, la plupart des professionnels de santé expliqueront doctement que ces analyses ne valent pas grand chose, car elles ne sont pas réalisées dans un cadre rigoureusement scientifique ; Jamie Heywood, le créateur du site, n’est pas de cet avis. Je vous invite à l’écouter (via TED).
Aujourd’hui, PatientsLikeMe n’existe qu’en anglais et n’accueille que les patients atteints de certaines maladie graves. Je rêve d’une initiative de ce genre plus ouverte et localisée en français … y a qu’a !
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.
La rumeur enflait enflait et finalement on a eu la confirmation de ce projet fou qu’une poignée de développeurs (un puis trois) menaient en secret chez Facebook.
Le but étant d’améliorer les performances globales de PHP. Et tout ce travail (300 000 lignes de code) va être distribué en open source. Même si on ne sait pas si ce système sera vraiment utilisable, chapeau Facebook !
On utilise couramment l’expression développeur web pour désigner le développeur travaillant à l’élaboration d’un site web ou d’une application en client léger. Même si cette expression ne me satisfait pas énormément, je vais m’en contenter pour ce modeste article.
Voici, selon moi, ce qu’il faut savoir pour être un bon développeur web.
Ce premier jour de 2010 je lisais diverses prédictions pour l’année au sujet du high tech et d’internet. Il est beaucoup question de sujets qui me laissent un peu froid :
Voici un retour de sondage. Réalisé par Linkedin auprès de sa communauté.
Il y a des stats intéressantes sur les revenus des sondés ainsi que sur la confiance qu’ils accordent à certaines marques. Mais dommage que les questions IT soient si nulles, d’autant plus que la base consultée est énorme (il y a même moi !). On y apprend que :
Dans la catégorie « desktop solution » Excel est préféré à l’Iphone,
Adobe est préféré à Eclipse qui est préféré à PHP dans les outils de développement,
Je suis un vieux con. Je radote les mêmes trucs que d’autres radotaient avant moi avant de me les transmettre. Afin que toi aussi, cher lecteur, tu deviennes un vieux con comme moi, je me permets, en toute modestie, de te donner également ces très modestes conseils.
1/ De nouveaux besoins tu n’inventeras pas (dans un premier temps au moins)
L’informatique est la science de la gestion de l’information (bim !). En fait, on fait de l’informatique depuis bien avant l’ordinateur ou la machine a calculer. Si vous voulez que votre projet réussisse, commencer par informatiser les flux d’informations existants (genre le papier que untel dépose dans la bannette de untel pour le valider afin qu’il soit ensuite archivé etc…). Déjà ça ce sera pas mal. Ceci fait, vous pourrez optimiser tout ça.
2/ La lettre au père Noël tu n’écriras pas
C’est vrai qu’en phase de spécifications l’imagination à tendance à se débrider au détriment des fonctions clés : à relire sur ce blog. (omg ! ça date de 2006).
3/ Les plus petites itérations tu feras
Et ce n’est pas si facile à faire ! ¨Pourtant, les connaisseurs des méthodes agiles seront bien d’accord avec moi pour dire que plus on livre tôt et souvent, plus le cout de retour en arrière est faible, le projet tolérant aux erreurs de conception et les risques de répondre à coté de la plaque aux attentes des utilisateurs diminué. Enfin, on y pense peu, mais quand on programme un projet de plus de 4-5 ans (si si ça existe !), il faut s’attendre à gérer un turnover au sein même de ce projet (y compris à la direction).
Quand je vois le projet de DMP – Dossier Médical Personnel – tous ces indicateurs passent au rouge, ce qui selon moi est de mauvaise augure. A mon sens, une étape intelligente aurait été de commencer à informatiser ce bon vieux carnet de santé : facile + bénéfices immédiats. (c’est un avis personnel)
il faut attendre la fin pour comprendre l’effet, en 1984, sur une foule qui découvre un ordinateur qui parle, a différentes polices de caractères et permet de dessiner à l’écran.
et juste après il est licencié ! « comment peut on être licencié d’une boite que l’on a créée ?! »
