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.

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 ?

L’environnement de travail

Imaginons donc cette configuration : un serveur web de test sous Linux Debian Etch et un poste de développement sous Windows. Rien de plus classique. J’aurais pu prendre un poste sous Linux, cela ne change rien à la suite. J’aurais aussi pu prendre un serveur web sous Windows (XAMP), mais je trouve tellement dangereux de faire des tests sous Windows pour une application qui sera hébergée par un serveur Linux que je préfère ne pas en parler…

On part du principe que PHP et Apache sont installés et actifs sur le serveur web. De même, Eclipse et PDT sont prêts sur le poste client.

Configuration du serveur web

Pour installer Xdebug, le plus simple est d’utiliser PECL. Mais pour utiliser PECL, il faut PEAR ! Et pour utiliser PEAR, il faut la version client de PHP ! Pas de panique, c’est tout simple : on prend sa console shell (en root) et on y va.

Installation de la version client de PHP :

apt-get install php5-cli

Installation de PEAR :

apt-get install php-pear

Pour éviter de se retrouver coincé par phpize, il faut aussi installer les paquets de développement PHP :

apt-get install php5-dev

On peut enfin installer Xdebug :

pecl install xdebug

Ensuite, on modifie le fichier de configuration de PHP pour activer Xdebug sur les applications web installées sur le serveur :

vi /etc/php5/apache2/php.ini

Dans le bloc Dynamic extensions, on ajoute la ligne suivante :

zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so

On enregistre, on ferme et on redémarre Apache :

/etc/init.d/apache2 restart

Si on fait un phpinfo() sur le serveur web, on obtient déjà un résultat encourageant :

Oui, mais… Par défaut, Xdebug n’est pas en mode remote :

Or nous avons besoin du mode remote pour utiliser Xdebug depuis le poste client. Qu’à cela ne tienne ! Un autre petit tour dans la configuration PHP :

vi /etc/php5/apache2/php.ini

Dans le bloc Dynamic extensions, on ajoute la gestion du mode remote :

xdebug.remote_enable=1
xdebug.remote_host=192.168.1.2
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so

Attention, le paramètre xdebug.remote_host correspond à l’hôte distant… vu du serveur ! Il s’agit donc du poste de développement. Piège classique.

Après redémarrage d’Apache, le phpinfo() est déjà plus sympathique :

C’est fini pour le serveur !

Configuration d’Eclipse

Il reste à configurer Eclipse pour envoyer les requêtes vers le serveur web. On ouvre les préférences (menu Windows > Preferences) et on choisit PHP > PHP Servers pour définir le serveur de test :

Il ne faut pas oublier les chemins (Path Mapping) pour faire le lien entre les deux machines. Si vous avez déjà créé un projet, vous pouvez directement le sélectionner comme chemin local (celui du poste client puisque, cette fois-ci, on est sous Eclipse !). Attention à un détail qui tue, le nom de votre projet ne doit pas contenir d’espace, sinon Xdebug ne fonctionnera pas !

Le serveur est maintenant configuré :

Il reste à définir les paramètres par défaut du debugger PHP :

• PHP Debugger : XDebug
• Server : celui qui vient d’être configuré
• PHP Executable : on le laisse non défini puisque nous sommes en mode distant

Cerise sur le gâteau, on oblige Eclipse à utiliser un navigateur web externe. Je choisis Firefox qui me permettra de tester l’interface avec d’autres outils (Firebug, Web Developper Tools, etc.).

Voilà, c’est tout ! C’est un peu long, mais pas sorcier ! Maintenant on peut s’amuser et tester son code :

Depuis aujourd’hui, Simile Exhibit 2.0 supporte officiellement le français.

Je remercie David Huynh, créateur talentueux de cet outil précurseur des nouveaux usages du web, d’avoir accepter d’intégrer ma modeste contribution au code source officiel. Je remercie également les french beta testers qui m’ont permis d’affiner la version française, suite à mes précédents articles (ici et là). Et une mention spéciale à Got pour m’avoir remis sur les rails.

Si vous avez quelques exemples d’utilisation d’Exhibit en français, n’hésitez pas à les ajouter dans les commentaires. Amusez-vous bien !

MySQL Proxy, proposé par MySQL AB, est le genre d’outils dont le rôle semble si évident qu’on se demande pourquoi il n’existait pas avant. Comme tout proxy, il récupère les requêtes destinées à la base de données, effectue des traitements et adresse une requête modifiée au serveur MySQL. Bien entendu, l’opération inverse est aussi gérée : MySQL Proxy sait récupérer un résultat de requête et le transformer avant de l’adresser au client initial.

Fonctionnalités

Après cette petite présentation, on peut se demander pourquoi on aurait besoin d’un proxy, puisque les services applicatifs (s’ils sont correctement architecturés et codés…) devraient envoyer une requête optimisée au serveur MySQL. Une petite liste des fonctionnalités finit par convaincre de son intérêt :

• Analyse des requêtes
• Filtrage et modification des requêtes et des résultats
• Injection de requêtes
• Load balancing
• Exécution de scripts (basés sur le langage LUA)

Cas d’utilisation

Dans la pratique, on peut imaginer les situations suivantes :

• Corriger les erreurs de syntaxe communes.
• Garantir le fonctionnement d’anciennes applications utilisant des requêtes non supportées.
• Supprimer du résultat un mot de passe demandé dans la requête.
• Récupérer et fusionner avec le résultat des données externes à la base de données (fichiers, flux XML, RPC…)
• Router les requêtes vers un autre serveur MySQL ou vers une autre base de données du même serveur.
• Empiler un lot de requêtes et les contrôler avant de mettre à jour les tables.
• Dupliquer les requêtes en temps réel sur deux bases différentes.
• Exécuter un script shell avant ou après des modifications dans la base de données.
• Interdire certains motifs de requêtes.
• Verrouiller des tables selon le contexte.
• Contrer les injections SQL non désirées.

On le voit, les possibilités sont infinies et ne dépendent que des contextes de production et de l’imagination des développeurs. MySQL Proxy permet surtout d’éviter d’intégrer la gestion de l’exploitation des bases de données MySQL dans les services applicatifs. Voilà enfin une saine séparation du travail du développeur métier et de l’administrateur MySQL !

Mise en oeuvre

MySQL Proxy est encore en version alpha et son fonctionnement n’est garanti que pour les versions MySQL 5.0.x et ultérieures.

Pour découvrir ses possibilités, O’Reilly Network propose un didacticiel clair et très fourni : Getting Started with MySQL Proxy.

Source : Linuxfr.org

<?php

/* Le fichier de log à analyser */
$fichier = "fichier.log";

/* Le motif à chercher */
$s = "google.fr";

/* Analyse et résultat */
$motif = "/$s/";
$pointeur = fopen($fichier, "r");
$i = 0;
if ($pointeur) {
    while (!feof($pointeur)) {
        $ligne = fgets($pointeur);
        if (preg_match($motif, $ligne, $r)) {
            echo $ligne . '';
            $i++;
        }
    }
    fclose($pointeur);
    echo "Motif '$s' trouvé $i fois.";
}

?>

Avec un été aux allures d’automne, j’ai eu envie de présenter un flux migratoire d’exception. Nul discours écologique dans mes propos, puisqu’il est question de PHP, le langage le plus répandu pour créer des applications web. Entre la mort de PHP4, la gestation de PHP6 et PHP5 qui tarde à s’imposer, voici un point sur la situation, les enjeux… et les risques.

PHP4 en fin de course

C’est maintenant officiel, PHP4 ne sera plus supporté à partir du 1^er janvier 2008. En soit, l’annonce ne choque pas puisque PHP5 a pris le relais depuis 3 ans. Mais, sur le terrain, la percée de la version actuelle de PHP est moins évidente. En cause, les nombreuses applications PHP4 encore exploitées en ligne qui freinent les hébergeurs dans l’adoption de PHP5.

Migrer de PHP4 à PHP5

Sachant que la migration de PHP4 vers PHP5 devient obligatoire, comment la réaliser en douceur dans le temps imparti (5 mois) ?

Premier point : s’informer et comprendre la nécessité de migrer. Le site Go PHP5 est là pour ça !

L’initiative Go PHP5 pour promouvoir une migration rapide vers PHP5.

Ensuite, il faut mettre le nez dans l’existant et y apporter les corrections ou les évolutions nécessaires pour le rendre compatible avec PHP5. On s’aidera des ressources mises à disposition par le PHP Group :

• Migration de PHP 4 à PHP 5
• Migrating from PHP 5.0.x to PHP 5.1.x
• Migrating from PHP 5.1.x to PHP 5.2.x

Préparer l’arrivée de PHP6

Maintenant, quid de PHP6 ? Quitte à migrer cet automne, autant en profiter pour préparer son arrivée ! On sait maintenant à quoi ressemblera la nouvelle mouture PHP et ce qu’elle implique pour les développeurs.

A la lecture de Prepare for PHP 6, on remarque vite que PHP sera beaucoup moins permissif. On ne regrettera pas le Register Globals, ni le Safe Mode (même s’il peut gêner quelques hébergeurs à la traîne).

Bien sûr, l’abandon des Magic Quotes imposera de retoucher de nombreuses applications PHP4 pour éviter les injections de commandes (pour attaquer une base de données, par exemple). On me rétorquera que PHP5 les désactive par défaut… ce qui veut dire qu’on peut les activer pour éviter de « perdre » du temps à mettre en conformité son code ! Avec PHP6, point de salut, il faut s’y coller !

Parmi les fonctionnalités les plus attendues, les namespaces pour la programmation orientée objet, le support natif d’Unicode, l’accélérateur APC par défaut.

Le plus inattendu est sans doute goto pour spécifier où continuer l’exécution du code ! A oublier de suite en programmation orientée objet…

Après le discours, la pratique. Voilà une petite check-list (tirée du magazine Programmez, juin 2007) pour faciliter l’arrivée de PHP6 :

• Ne pas utiliser register_globals, mais $_POST, $_GET, $_COOKIE et $_REQUEST
• Ne pas utiliser $HTTP_POST_VARS et $HTTP_SERVER_VARS, mais $_POST et $_SERVER
• Mettre les directives magic_quotes_* à off
• Ne pas spécifier le passage par référence dans l’appel de fonction, mais dans le prototype
• Ne pas utiliser la fonction __autoload() (pratique mais très gourmande)
• Ne pas mettre une variable derrière un break, mais une constante, un nombre… ou rien
• Désactiver le safe_mode
• Ne pas utiliser la librairie GD1 pour traiter les images, mais la GD2
• Utiliser l’UTF-8 ou l’UTF-16

Le dernier point est, selon moi, le plus critique. Le support d’Unicode (UTF-8 ou UTF-16) impose de convertir la chaîne complète du développement : fichiers de code source, fichiers de données, base de données, navigateur web, etc. Or le support d’Unicode est loin d’être un réflex dans les projets web. Quel webdesigner se préoccupe de déclarer le support de l’Unicode dans Dreamweaver ? La question qui suit est : pourquoi la majorité des outils propose encore l’ISO-8851 ou CP1252 par défaut ? Bref, ce point dépasse le cadre des évolutions de PHP, mais deviendra un vrai Capharnaüm s’il n’est pas traité dans son ensemble.

Une opportunité pour les entreprises… et leurs prestataires

Inutile de tourner autour du pot : la migration nécessaire de PHP4 vers PHP5 demandera d’ici la fin de l’année un certain travail aux équipes de développement PHP de tous bords. Pour le bien des entreprises, c’est certain. Elles verront leur système d’information évoluer et gagner en maturité. Pour leurs prestataires aussi qui sauront profiter de l’opportunité pour aller plus loin qu’une simple mise en conformité iso-fonctionnelle.

Cela fait un certain temps que je suis avec beaucoup d’intérêt les travaux du MIT (Massachusetts Institute of Technology) autour de Simile (Semantic Interoperability of Metadata and Information in unLike Environments). Ses intervenants défrichent le terrain du web sémantique avec beaucoup de talent et sans oublier de passer de la théorie à la pratique.

Le projet le plus connu est sans doute Timeline qui se veut le « Google Maps du temps ». J’avoue que le résultat est plutôt à la hauteur de la comparaison, d’autant que l’intégration de Timeline dans un site web est triviale !

Par contre, je suis un peu moins enthousiaste avec Exhibit. Ce framework permet de publier des données structurées et de les manipuler dans une interface web avec une déconcertante facilité. Le concept est génial mais je trouve certains choix techniques très discutables.

Pourquoi avoir créé des attributs HTML spécifiques à Exhibit ? Par exemple, pour réaliser un filtre à facettes, il faut écrire le code suivant :

<div id="exhibit-browse-panel" ex:facets=".discipline, .relationship, .shared, .deceased"></div>

Résultat, le code source n’est pas conforme et la page n’est pas accessible (au sens ergonomique). Des inconvénients qui vont à l’encontre du web sémantique ! Pourquoi ne pas avoir développé une syntaxe particulière pour les valeurs des attributs HTML officiels ? C’est le principe de diffusion adopté par les microformats.

Quant aux données, elles proviennent d’un objet Javascript (plus précisément d’un objet JSON). Adopter JSON est une excellente idée… sauf pour le référencement de la page web. En effet, pour un robot d’indexation, une page Exhibit est vide ! Il y a bien quelques pistes pour résoudre le problème, mais je suis loin d’être convaincu. Il me semblerait plus judicieux d’intégrer les données par défaut dans le code source HTML et de les manipuler via des méthodes non intrusives (unobstrusive Javascript) par le DOM du navigateur.

Et de votre côté, utilisez-vous Exhibit dans vos projets ? Avez-vous trouvé des réponses à ces contraintes ?

Exhibit a un tel potentiel que je ne voudrais pas être bloqué par ces deux défauts majeurs. Surtout qu’un autre projet va en décupler l’intérêt : Potluck (merci Christian pour cette découverte !).