Christophe Le Bot

Encore 9 jours de patience avant de découvrir un livre très attendu : Scrum, de Claude Aubry, chez Dunod. Les méthodes agiles ont le vent en poupe et les précurseurs, comme Claude, ont maintenant suffisamment de recul et d’expérience pour nous expliquer Scrum avec beaucoup d’efficacité et de pédagogie.

A lire sans retenue !

Si après ça, vous n’êtes pas convaincus, je ne sais plus quoi faire. Ah si, venir aux ateliers du SigmaT (dont Claude Aubry est le président !). Le prochain est mercredi 3 février et ce sera un XP Game, parfait pour découvrir l’efficacité d’une démarche agile.

Jeudi dernier se tenait le Barcamp PHP Cheese & Wine. Même si le vin et le fromage ont été très appréciés, nous n’étions pas venus (seulement) pour ça. Alors pour les absents qui ont eu tort de l’être, voici une petite synthèse de cette longue soirée.

Un vrai barcamp

Premier bon point : c’est un vrai barcamp où les participants se présentent et définissent le contenu des ateliers. Tous les barcamps ne respectent pas cette règle de base… Xavier Gorse, président de l’AFUP, a donc joué le rôle de « maître de cérémonie » pour établir le programme d’après les souhaits de chacun  :

• PHP et sécurité
• PHP 5.3
• Déploiement d’applications PHP
• PHP et les bases de données « NoSQL »
• Outillage PHP
• PHP et testing
• Frameworks PHP

Pour ma part, j’ai participé aux ateliers :

• Déploiement d’applications PHP
• PHP et les bases de données « NoSQL »
• PHP et testing

Je limite donc mon article à ces sujets, sachant que d’autres synthèses ont déjà été publiées :

• Synthèse du Barcamp PHP toulousain, par Raphaël Rougeron
• Synthèse du Barcamp PHP toulousain, par Thomas Gasc

Déploiement d’applications PHP

Cet atelier a mis en évidence la difficulté de déployer des applications web en général (technologies nombreuses et environnement hétérogène). Tous les outils existants ont été passés en revue, du paquet Linux (.deb) aux outils spécifiques à PHP (PEAR, Phing, Phar) en passant par des intermédiaires parfois plus adaptés (makefile, Puppet, Capistrano, Ant). Deux groupes de participants étaient clairement représentés, avec des besoins très différents :

• Déploiement d’une solution sur un parc important et hétérogène (cas des éditeurs de solutions, comme Linagora avec OBM)
• Déploiement d’un projet sur-mesure sur un ou quelques serveurs, mais très fréquemment et avec des contraintes d’intégration de contenus externes (cas des agences web, avec plusieurs déploiements par jour).

Dans le premier cas, la difficulté est d’identifier la configuration des serveurs cibles et de préparer les paquets d’installation correspondants (.deb pour chaque distribution Linux, .msi pour chaque version de Windows, etc.), tout en assurant la compatibilité des données sans toujours les connaître (tests de régression).

Dans le second cas, il faut savoir intégrer pendant le déploiement les données du site en exploitation (base de données, templates gérés par un web designer externe, etc.), avec d’éventuelles transformations (ETL, Extract Transform Load).

J’ai ajouté qu’un déploiement ne se limite pas à la livraison de la partie applicative mais doit aussi savoir traiter la mise à jour des outils liés au projet (plate-forme de gestion de tickets, extranet, feuille de route, tests, sauvegardes, alertes, etc.).

En dehors de PEAR, trés utilisé et qui est un outil de déploiement à l’origine, j’ai une préférence pour Ant + Phing et Capistrano.

Bases de données « NoSQL »

Là, on entre dans une autre dimension. Les bases « NoSQL » sont des bases de données non relationnelles. En gros, on ne retrouve pas le schéma habituel « tables contenant des champs et étant reliées entre elles ». L’avantage est d’obtenir des performances exceptionnelles sur des entrepôts de données énormes. Parmi les acteurs majeurs qui développent et utilisent des bases « NoSQL », on peut citer : Google (projet Big Table qui a inspiré le projet Cassandra), Facebook ou Linkedin.

Si on revient à la dure réalité d’un acteur de dimension modeste, on constate que ces technologies émergentes et prometteuses sont encore très spécifiques. Les bases relationnelles ont de beaux jours devant elles. La difficulté est notamment de réintégrer dans l’application PHP ce qui fait la force des systèmes SQL : sélection, jointures, intégrité référentielle, etc. Le volet testing des projets en prend un coup…

PHP et testing

Atelier en petit comité (6 personnes), en concurrence déloyale avec l’atelier Frameworks qui a fait le plein ! Nous avons tenté de lister les types de tests liés à une application web, en dépassant autant que possible la simple vue du développeur :

• Tests unitaires (PHP et Javascript)
• Tests fonctionnels
• Tests d’IHM (via Selenium Core, Selenium RC et Selenium IDE)
• Tests de recette
• Tests de non régression
• Tests de performance
• Tests de charge
• Tests de conformité (normes, W3C, accessibilité, etc.)
• Tests ergonomiques (tri par cartes, paper prototyping, tests utilisateurs, etc.)
• A/B testing

Les échanges sur nos expériences ont été très instructifs. Nous étions tous d’accord pour insister sur la définition précise des cas d’utilisation qui facilite la gestion des tests pendant toute la durée du projet avec le client. D’où une phase de spécifications sérieuse qui conditionne la qualité du travail livré. Certains tests peuvent faire l’objet de validation contractuelle, comme les wireframes issus de tests ergonomiques qui servent ensuite de feuille de route aux intégrateurs et développeurs.

La difficulté avec les tests, c’est de savoir placer le curseur pour ne pas s’y noyer. Il n’est pas réaliste d’appliquer les tests de façon exhaustive. C’est un idéal en contradiction avec les budgets et les délais imposés en pratique. Il faut donc savoir réaliser les bons tests, au bon endroit et au bon moment. Par exemple, sur le calcul des prix d’un panier de site e-commerce, sur l’intégration des données lors d’un couplage entre deux systèmes, sur l’ergonomie d’une interface riche, etc.

En résumé

Une excellente soirée qui a largement dépassée les 5 heures prévues ! L’accueil de Linagora et de l’AFUP était parfait, l’ambiance très sympathique et le niveau des échanges très pointu. Il y a des gens qui savent faire des choses avec PHP en Midi-Pyrénées ! Je pense qu’on remettra ça sous peu. Prochaine étape : le Bargento, lundi 9 novembre à Paris. Je serai présent avec l’équipe de l’AFUP pour organiser et animer cette journée qui s’annonce exceptionnelle. Et à la suite, le Forum PHP 2009, tout aussi exceptionnel. Sur ce coup-là, je déclare forfait. Il faut bien travailler un peu !

L’Agile Tour est de retour à Toulouse ! Le principe reste le même : faire découvrir les méthodes agiles et partager les retours d’expérience de leur application sur des projets réels.

L’édition 2008 a été un réel succès, alors ne boudez pas celle de 2009 ! L’efficacité des organisateurs et un contenu riche et utile vous rempliront la tête d’idées.

Ce sera le 22 octobre toute la journée, mais pas au même endroit que l’an dernier. Hélas ! Je ne pourrai pas m’y rendre, c’est une catastrophe… Heureusement, les comptes-rendus sont toujours complets, avec une copie des présentations faites à l’assistance. Que du bon en somme.

Informations et inscription : Agile Tour 2009

Il y a deux ans, quand j’ai commencé à mettre le nez dans Magento, il n’y avait rien ou quasiment rien sur le web pour traiter le sujet. Alors j’ai toujours eu l’idée d’un blog pour centraliser l’information pratique au quotidien. Mais comme souvent, les autres priorités ont gelé cette initiative assez rapidement…

Depuis, il s’est passé beaucoup de choses autour de Magento. De nombreux sites dédiés ont fleuri et m’ont fait douter de l’intérêt de créer un YABAM (Yet another blog about Magento). Alors tout cela est resté dans un carton, à moitié achevé, pendant une dizaine de mois.

Et pourtant, voilà Magentips ! Comme quoi tout arrive. Je doute de ma disponibilité pour en faire le YABAM le plus riche de la planète, mais je souhaitais partager mes expériences Magento en dehors des sentiers battus et des premières évidences. La page A propos détaille cela.

Je vois donc cette initiative personnelle comme un complément à des outils existants. Certains partages de contenu se feront donc naturellement vers des sites de référence comme le blog français officiel Magento, Fragento et Wikigento. Comme dirait Philippe Humeau (Wikigento), « on peut œuvrer ensemble dans le même sens, sans perdre son indépendance et sa liberté de ton ».

Bienvenue sur Magentips !

Vous pouvez aussi retrouver Magentips sur Twitter.

Ouf ! Ce fut long et difficile, mais le résultat est là. Magento 1.4 arrive bientôt… avec un contrôle bien plus fin des calculs de prix et de TVA ! Suffisamment pour respecter les lois françaises sur les sites ouverts aux particuliers et pour programmer les promotions les plus folles en déclarant correctement la TVA !

Ceux qui se sont arraché les cheveux avec ça comprendront tout de suite l’intérêt de cette simple capture d’écran…

Je remercie l’équipe de Varien pour cet excellent travail et pour sa compréhension des subtilités de la fiscalité française. Vu des Etats-Unis, ce n’était pas gagné d’avance…

Donc, c’est un grand jour. Il faut maintenant attendre la validation de la version 1.4 qui devrait sortir bientôt. A Varien d’en faire l’annonce !

Fini le développement web approximatif ! Aujourd’hui, les applications web deviennent de véritables usines à gaz qu’il faut savoir maîtriser. Certains regrettent l’époque du développement procédural avec ses projets de moins de 2000 lignes de code, mais il faut se rendre à l’évidence : le web est la plate-forme, il a besoin d’applications riches, complexes et stables. Un exemple, Magento : 300.000 lignes de code…

Sans outils d’aide au développement, il n’est plus possible de garantir la qualité de son code. Heureusement, ils ne manquent pas, encore faut-il les installer et les configurer correctement.

Parmi les outils indispensables, le debugger et le profiler arrivent en tête. Ils permettent de tracer tout ce que le code source est censé faire : inclusions, chargement de données, valeurs de variables, temps d’exécution, contenu des objets, etc. Avec eux, on gagne déjà la moitié du temps de test ! Je devrais plutôt dire : sans eux, on ne fait pas de vrais tests !

Je vais prendre l’exemple d’une application web PHP développée avec Eclipse et son extension PDT (PHP Development Tools), en utilisant Xdebug comme debugger. Cela n’a rien d’original, des milliers de développeurs PHP utilisent cette configuration, mais je vais sortir des sentiers battus pour traiter un cas plus délicat, mais plus courant en entreprise : comment utiliser xdebug sous Eclipse quand mon serveur web de test n’est pas mon poste de travail, mais un serveur distant ?

Lire la suite »

Excellente journée, aujourd’hui !

Pour commencer, une jolie acquisition finalisée ce matin (la 4^e entreprise du groupe) dont je laisse au padrone le soin d’annoncer la nouvelle. Ce sera le 21 octobre. Oui, je sais, ça fait un peu buzz…

Et puis, c’était surtout la journée Agile Tour 2008 à Toulouse ! Inutile de tourner autour du pot : j’ai été très agréablement surpris ! Et ce, pour plusieurs raisons :

• L’organisation était parfaite : accueil sympathique, horaires respectés, pauses gourmandes généreuses, matériel et salles adaptés, atmosphère détendue propice aux échanges.
• Les salles étaient combles, preuve que les méthodes agiles commencent à s’installer doucement mais surement.
• Les intervenants étaient passionnés, passionnants et pédagogues.
• Les exemples d’utilisation étaient clairs et convaincants.
• La programmation était judicieuse pour avoir une vision globale du sujet (1. Origine, théorie ; 2. Application via les ateliers ; 3. Retours d’expérience).
• L’effort des sponsors a permis d’ouvrir gratuitement cette journée à tous, sans rogner sur la qualité des interventions.

Que du bonheur ! Il faut dire que c’était facile : l’organisation de ces journées Agile Tour a elle-même bénéficié d’une approche agile…

Sur ce coup, les absents ont eu tord, mais ils pourront (légèrement) se rattraper en consultant les supports des conférences sur le site de la SigmaT dès demain.

Pour finir, voici en vrac ce que je retiens de cet événement :

• Lire deux livres : The Mythical Man-Month, de Frederick P. Brooks, et Peopleware, de Tom DeMarco et Timothy R. Lister.
• L’Agile Manifesto et ses 12 principes.
• La complémentarité de l’approche Lean sur les projets agiles.
• Le constat à l’origine de la création de Scrum : « le processus de développement est imprévisible ».
• Scrum est utilisé dans 3 projets agiles sur 4 (Scrum seul 49%, Scrum + XP 22%).
• Le coeur de cible agile : un nouveau projet pas trop critique, piloté par un management accomodant, sur une architecture définie, développé à temps plein par une équipe de 5 à 12 personnes réunies en un même lieu, s’appuyant sur des outils et systèmes interactifs ! C’est un idéal, bien sûr…
• Sélectionner les méthodes agiles adéquates et les adapter au contexte.
• Shu Ha Ri : suivre, comprendre, adapter. Auquel j’ajouterais améliorer.
• Bien penser son architecture avant d’appliquer un développement agile.
• Ne pas oublier de documenter son travail (non par formalisme, mais parce que tout ne peut pas être déduit du code, comme les séquences).
• L’atelier XP Game qui a vite montré à tous les participants l’intérêt de l’Extreme Programming pour piloter un projet.
• L’excellent retour d’expérience d’Igeoss qui a adopté les méthodes agiles dès l’origine pour développer ses solutions, avec un réel avantage productif et qualitatif.
• L’excellente discussion avec Ramiro Sarmiento, agile coach chez Agilii et organisateur de l’Agile Tour 2008.

Parmi les blogs que je lis régulièrement sur le sujet, je vous recommande :

• SigmaT
• Être agile, de Thierry-Gabriel Cros (qui a organisé l’événement et anime la SigmaT)
• Scrum – Méthodes agiles, de Claude Aubry (qui a organisé l’événement et anime la SigmaT, lui aussi !)
• Agilex
• QualityStreet

Merci à tous les organisateurs d’Agile Tour 2008 pour cette belle réussite ! Leurs efforts méritent bien ce petit retour.

Mettre au point des sites web qui fonctionnent avec Internet Explorer 6 relève du défi ! Ce qui devait arriver, arrive : Save the developers!

Pour ma part, j’ai pu mesurer le temps passé à mettre au point une interface pour Internet Explorer 6 : 15 à 25% du temps de développement des interfaces web ! Sans parler de l’énervement au sein des équipes de développement…

Alors, s’il vous plaît, mettez à jour votre navigateur web ! Ce sera bénéfique pour tout le monde : les développeurs pourront concevoir des interfaces plus rapidement, les applications web seront plus stables et vous bénéficierez d’un outil efficace et adapté au web d’aujourd’hui.

Vous avez l’embarras du choix :

Si vous tenez à rester dans le giron de Microsoft, installez dès que possible Internet Explorer 7. Les améliorations sont notables, même si nous sommes encore loin d’un résultat idéal. Il paraît qu’Internet Explorer 8 sera enfin un navigateur digne de ce nom. J’attends de voir… Bref, vous l’aurez compris : ce n’est pas mon préféré.

Firefox 2 est le navigateur web le plus utilisé par les développeurs, grâce à une interface intuitive et une multitude d’extensions. Seule ombre au tableau : sa gourmandise en terme de ressources mémoire. Mais Firefox 3 apportera un sérieux changement de ce côté. Incontournable et recommandé par les professionnels.

Opera, c’est LE navigateur web par excellence. Léger, rapide, complet, il a tout pour plaire, en particulier son support quasi parfait des normes du W3C. S’il reste marginal sur les ordinateurs, il est le roi du web mobile !

Proposé par Apple, Safari est le navigateur web par défaut de MacOS, mais il fonctionne aussi sous Windows. Un bon produit qui possède la magie Apple. Parfait pour l’utilisateur qui ne veut pas s’embarrasser de technique.

Quel que soit votre choix, le plus important est d’abandonner Internet Explorer 6 !

Si nous intégrons tous la gestion des exceptions dans notre code source (enfin, je l’espère…), en faisons-nous vraiment bon usage ? Entre les « maniaco-dépressifs » qui en mettent partout et les « bricolo-codeurs » qui savent à peine les mettre en place, il y a un compromis… qui n’est pas toujours évident à trouver.

Erreur, dysfonctionnement et exception

Par définition, une exception n’est levée qu’en cas d’état exceptionnel de l’application. Le tout est d’arriver à définir l’état d’exception. Est-ce un dysfonctionnement applicatif grave (connexion à une base de données qui tombe, fichier applicatif introuvable, allocation mémoire excessive, objet corrompu) ? Est-ce un fonctionnement normal mais exceptionnel (erreur d’authentification utilisateur, données entrantes non conformes) ? Est-ce une situation fréquente mais ne répondant pas au scénario optimal d’utilisation (mauvaise utilisation de l’application, erreurs de saisie d’un utilisateur) ?

Après avoir vu tous les cas sur le terrain, mais aussi dans des documents de référence, j’avoue ne plus savoir où placer le curseur…

Réserver l’exception aux dysfonctionnements

Pour ma part, je préfère garder l’exception pour les situations les plus rares et les plus graves, ce que je définis comme des situations exceptionnelles. Elles sont généralement dues à des dysfonctionnements de l’application, c’est-à-dire des états qui n’ont pas été prévus dans les séquences d’utilisation.

Sur ce principe, une erreur de saisie d’un utilisateur ne devrait jamais déclencher une exception lorsque sa valeur est contrôlée par l’application. Si j’entre une adresse e-mail invalide dans un formulaire, l’application traitera l’événement comme une erreur utilisateur et non comme un dysfonctionnement interne. Elle retournera le formulaire avec un joli message d’erreur… qui n’a rien d’exceptionnel puisque ce traitement fait partie du fonctionnement normal de l’application (mais pas de sa séquence nominal !). Même si cela semble évident (pour moi, du moins…), l’utilisation des exceptions pour ces cas est loin d’être anecdotique.

Bien sûr, si après validation de l’adresse e-mail l’application ne peut pas traiter normalement le formulaire, l’utilisation des exceptions permettra de trouver l’origine du dysfonctionnement, sans mettre les données dans un état inconsistant.

Trouver le bon équilibre

Dans le cas d’applications complexes où la modularité de code est de rigueur (genre « full MVC avec intégration de tous les designs patterns du GoF » !), savoir instancier puis récupérer une exception au meilleur endroit (ou moment pour les aficionados de la programmation événementiel) est déjà moins évident. Quels rôles jouent les différents niveaux de la partie M (modèle) ? Comment réagit la partie C (contrôleur) ? Comment gérer efficacement l’imbrication des exceptions (du noyau à l’interface en passant par les couches métiers) sans perturber la compréhension du problème par l’utilisateur ? Bien sûr, chaque cas est particulier, mais j’avoue que je souhaiterais bien discuter du sujet, autour de vos expériences.

Je vous passe la main !

Le cryptage de mots de passe par MD5 est sans doute la mesure de sécurité la plus utilisée par les développeurs. Son intérêt : crypter une chaîne de caractères, sans avoir la possibilité mathématique de faire l’opération inverse. Enfin presque…

Depuis 2004, on sait que MD5 n’est plus très sûr. Cependant, casser cet algorithme n’est pas à la portée de tout le monde. Aucun risque pour vos bases de données utilisateurs ? C’est sans compter sur les bases de hash MD5. Leur but : stocker des chaînes de caractères et leur hash. Comme les utilisateurs entrent souvent des mots communs ou connus, il est très simple d’interroger ces bases pour obtenir la liste des chaînes de caractères compatibles avec un hash MD5. GData en est un exemple particulièrement efficace et complet.

Vous voulez connaître le mot de passe caché derrière le hash MD5 fe01ce2a7fbac8fafaed7c982a04e229 ? Le voici en 1/10^e de seconde : demo. Et celui-ci, assez fréquent dans les bases mal paramétrées : 21232f297a57a5a743894a0e4a801fc3. C’est admin !

Il est temps de changer de méthode de cryptage…

Source : Nexen