Propositions de conférences pour ConFoo 2012
Comme chaque année, la conférence ConFoo aura lieu fin février à Montréal. Il y a cependant une nouveauté de taille : la possibilité pour le public de voter pour les propositions.
Cette année, j'ai proposé les conférences suivantes :
- Environnements de développement avec Vagrant
- Reprendre du code historique
- Organiser efficacement son dépôt de code
- Revues de code
- La qualité au-delà du code
- Reprise sur incident
Si vous voulez les voir à ConFoo 2012 ou simplement me donner un coup de main, vous pouvez voter en cliquant sur les liens ci-dessus.
Il vous faudra être connecté et donc vous créer un compte si vous n'en avez pas déjà un. Je vous rassure les gens de ConFoo sont très bien. Vous ne serez pas spammés suite à cette inscription.
Distributions PHP
Il y a quelques semaines Cal Evans émettait l’idée que Drupal devrait forker PHP. L’idée est surprenante et audacieuse mais pas forcément aussi idiote qu'elle en a l'air au premier abord.
Tout d’abord pour ceux qui n’ont pas assistés à la table ronde « 2010 l’année des forks : et l’avenir ? Quelles sont les meilleures pratiques pour pérenniser une communauté ?» au salon Solutions Linux , rappelons ce qu’est un fork.
Je vais reprendre la définition donnée par l’AFUL dans un article récent :
« En informatique une fourche (d'après le Jargon français), ou encore un embranchement (selon Wikipédia), est un programme développé à partir des sources d'un autre. Le mot anglais original pour ce concept est le mot "fork". Une fourche a souvent pour cause une divergence profonde dans la vie d'un projet informatique qui vise à créer un logiciel. Une telle divergence dans la vie d'un projet est un élément fort, une crise, générant généralement de fortes perturbations aussi bien pour les personnes qui gèrent le projet que pour les utilisateurs du logiciel géré par le projet. On pourrait comparer la création d'une fourche au niveau informatique à un divorce pour un couple d'humains. »
Forker, si vous me permettez ce néologisme répandu, revient donc à prendre le code source d'un projet et de continuer de construire dessus sans le concours des auteurs originaux. Cela n'est bien entendu possible que grâce aux libertés accordées par les licences libres. Le monde propriétaire n'est pas concerné par ces considérations.
On voit donc que forker un projet n’est pas anodin alors pourquoi vouloir faire cet effort ?
Pourquoi forker PHP ?
Cal Evans évoque 4 raisons pour un projet comme Drupal de forker PHP :
- Amélioration du processus de développement : Il est de notoriété publique que le développement de PHP est parfois chaotique et pourrait grandement être amélioré. La communauté Drupal a prouvé qu’elle sait gérer un développement d’envergure et PHP pourrait profiter de cet expérience ;
- Adaptation du langage aux besoins de Drupal : La communauté Drupal pourrait retirer de PHP tout ce qui ne sert pas au CMS et ainsi améliorer la maintenabilité de PHP ainsi que ses performances ;
- Améliorer l’intégration entre le langage et Drupal : La communauté pourrait ajouter du code spécifique à Drupal et notamment des extensions pour une meilleure intégration des besoins du CMS dans le langage lui-même ;
- Maîtriser leur avenir : Le monde de l’Open Source est en perpétuelle évolution. Ne dépendre que de soit peut-être un facteur de stabilité et de sérénité pour un projet.
Maintenir un fork de PHP est-il réaliste pour un projet ?
Développer un langage informatique est très différent de développer un programme.
Dans le cas de PHP, maintenir un fork nécessiterait d'avoir de solides compétences en développement C ainsi qu'une connaissance approfondie des mécanismes internes de PHP. Ce sont des compétences difficiles à trouver car longues à acquérir et en partie spécifiques à PHP. Cela ne décourage pourtant pas certains comme Robert Eisele qui a annoncé avoir forké PHP 5.3.6 pour y ajouter de nombreuses améliorations alors même que je rédigeais cet article.
Cependant, un fork ne consiste pas seulement à copier un code à un instant T et à l'adapter à ses besoins. Encore faut-il le faire vivre par la suite. Cela veut dire en maintenir la sécurité mais aussi et surtout y ajouter de nouvelles fonctionnalités.
Les trolls réguliers entre communautés montrent à quel point la compétition pour l'innovation est importante dans le domaine des langages de programmation. Pour forker avec succès PHP, il faut être en capacité de le faire évoluer de manière efficace et ce n'est pas donné à tout le monde.
Quand on regarde l'histoire des langages informatiques, il y a beaucoup d'inspiration au niveau des concepts mais rarement des forks au sens strict du terme. En préparant cet article, je n'ai en fait pas trouvé le moindre fork qui ait passé le stade de l'expérimentation anecdotique.
Il y a-t-il des alternatives aux forks ?
Les forks ne sont probablement pas la bonne réponse au problème soulevé mais au fond cela ne change pas la légitimité de la question soulevée : comment adapter le plus possible PHP aux besoins spécifiques de certains logiciels d'envergure ?
La plupart des projets de ce type proposent des suggestions pour optimiser les performances sous forme de paramétrage recommandé ou d'usage de cache en mémoire. C'est un bon début mais on est loin du compte.
Certains projets ont envisagé par le passé de remplacer les parties les plus gourmandes de leur logiciel par une extension PHP afin d'améliorer les performances. Ça a notamment été le cas de Smarty. Malheureusement, l'usage massif d'hébergements bas de gamme ne permettant pas la compilation de module tiers a tué ces initiatives. Cependant, l'idée reste intéressante et le contexte n'est plus le même. L'usage de PHP s'est professionnalisé et les plate-formes d'hébergement avec.
Des distributions de PHP
Le monde Linux a une approche particulière du développement et de la distribution des logiciels. Des développeurs développent le noyau du système, le Kernel, qui est la fondation de tout le reste mais qui en soit ne fait pas grand chose d'exploitable par le commun des mortels. D'autres développeurs prennent ensuite ce noyau, le complète de nombreux logiciels additionnels, effectuent des réglages pour optimiser tel ou tel aspects et diffusent le résultat sous forme de distributions Linux. Les plus célèbres sont probablement Red Hat, Debian ou encore Ubuntu qui est elle-même basée sur Debian.
Imaginons qu'au lieu de forker PHP un projet en propose une distribution optimisée pour ses besoins. Cela commencerait par la reprise de la dernière version de PHP éventuellement patchée pour en optimiser certains aspects, débarrassée des parties inutiles pour le projet, et compilée avec toutes les options adaptées.
Ce socle serait ensuite complété par des extensions spécifiques qui viendraient par exemple remplacer du code peu adapté à une exécution par PHP pour en optimiser les performances ou bien apporter de nouvelles possibilités fonctionnelles.
Une fois cette distribution élaborée elle serait diffusée et maintenue par le projet lui-même.
Cela ne résout pas tous les problèmes et nécessite toujours des compétences C et une connaissance approfondie des mécanismes internes de PHP mais le périmètre sur lequel porte ces efforts est bien plus réduit. Cela permet également de profiter de la vitalité de la communauté PHP et des nouvelles versions qui sortiront.
Enfin, réduire la base de code pour en optimiser les performances revient à réduire les possibilités offertes par le langage et donc compliquer la création d'extensions qui sont souvent la richesse des applications. La désactivation sera donc probablement une piste à privilégier.
Une approche réservée à quelques projets d'envergure
Soyons clair : cette approche n'est pas adaptée à l'immense majorité des projets PHP. Pour être en capacité de la mettre en œuvre il faut selon moi plusieurs critères.
Tout d'abord le projet doit concerner un public disposant des ressources humaines et matérielles pour déployer ces applications sur des systèmes permettant l'installation de logiciels tiers (serveurs dédiés, VPS, cloud, etc. ). Des projets comme Drupal, Magento ou encore WordPress rentrent dans cette catégorie mais en revanche un logiciel pourtant très utilisé comme phpBB me semble trop orienté amateurs, par opposition à professionnels, il n'y a pas de jugement de valeur dans mes propos.
Ensuite, il faut que le projet soit suffisamment gros et structuré pour pouvoir mettre en place une équipe spécialisée. Comme je l'ai dit précédemment, ce n'est pas une mince affaire. Il s'agit véritablement d'un projet dans le projet.
On le voit, la liste des prétendants est courte mais pour eux les gains pourraient être importants.
Solutions Linux 2011
J'aurai le plaisir de participer demain à la table ronde "2010 l’année des forks : et l’avenir ? Quelles sont les meilleures pratiques pour pérenniser une communauté ?" au salon Solutions Linux, au CNIT à La Défense.
Par ailleurs, avec mes collègues Damien Seguy et Julien Pauli nous serons présents sur le stand d'Alter Way de 12h à 14h pendant les 3 jours du salon pour discuter industrialisation et PHP alors n'hésitez pas à passer nous voir !
Mots-mêlés PHP
Durant le forum AFUP, vous avez été nombreux à tenter votre chance et vous prendre la tête sur les mots-mélés PHP. Pour rappel, la grille ci-dessous comporte un grand nombre de structures PHP : noms de classes, fonctions, constantes, opérateurs, ainsi que des contributeurs et des applications PHP connues.
Il y en a 71, tels qu'ils ont été créés, mais dans la pratique, on peut en trouver encore plus, en recherchant des mots courts (dl est présent sans être identifié dans les solutions) ou des sous parties (array_intersect_key contient en fait 3 noms de fonctions distincts). Et non, mon propre nom m'apparait pas dans cette grille (certains d'entre vous l'on cherché longtemps).
Vous pouvez imprimer l'image ci-dessus, et tester vos connaissances avec les réponses ci-dessous.
Un grand merci aux gagnants qui se sont partagés 2 bouteilles de champagne, ainsi que 2 t-shirts dédicacés par les gourous qui étaient sur le forum : Martin Supiot, Bochu Marie, Michael Marchal, Paul Ferret. Par ailleurs, si vous vous appelez Romain B. ou Loic LF, vous avez gagné 10% de réduction sur les formations Alter Way Formation.
Grand jeu PHP sur le forum AFUP
Je viens de mettre la touche finale à un petit jeu PHP qui sera disponible durant le forum AFUP de la semaine prochaine. Il va falloir affuter ses connaissances de notre plate-forme de développement préférée, et aller sur place pour se mesurer à toute la communauté.
Outre le défi, Alter Way proposera aux meilleurs (et aux plus mauvais) des prix collectors assez spéciaux : je n'en dit pas plus, cela vaut la peine de tenter votre chance.
Concours PHP au Forum AFUP 2010
Les utilisateurs ont-ils confiance en l’avenir de PHP
Le désormais incontournable Frédéric Hardy a eu une idée intéressante : demander à 5 utilisateurs français de PHP de répondre à un questionnaire sur la manière dont ils voient l'avenir de PHP.
Ces interviews, toutes basées sur le même modèle, ont réalisées avec le concours de gens connus ou moins connus, professionnels ou étudiants, consultants ou développeurs :
La confrontation de ces points de vue est très intéressante … et je ne dis pas cela uniquement parce que j'ai eu la chance que Frédéric me demande de m'exprimer sur le sujet. 
TestFest PHP 2010
Une campagne baptisée TestFest est organisée chaque année par la communauté PHP. Cette année elle s'étale du 1er mai au 31 août bien que son annonce officielle vienne seulement d'être faite.
Son but est d'élargir le cercle des personnes qui écrivent des tests unitaires pour PHP. Il s'agit bien de tests pour vérifier le comportement du langage lui-même. Si PHP est écrit en C, les tests sont eux rédigés au format PHPT. Ce format est relativement facile à prendre en main du fait de sa simplicité. La seule chose déroutante au début est que l''on teste forcément par rapport à un affichage. Pour les fonctions qui n'en produisent pas, ce qui est le cas de la plupart d'entre elles, on affiche le contenu de la valeur de retour au moyen des fonctions echo() ou var_dump().
PHP possède déjà plus de 7 000 tests mais il reste des parties qui sont peu couvertes par des tests unitaires. On peut les repérer grâce à la liste des fonctions testées et au rapport de couverture de code.
Une fois la fonction à tester choisie et le test rédigé, il est temps de l'exécuter. Pour cela, il faut mettre en place un environnement contenant les dernières versions des branches 5.2 et 5.3 ainsi que du tronc du code source. Cette année, des instructions détaillées sont fournies pour Windows, Mac OS X et Ubuntu. Ce dernier bénéficie en plus d'un script qui automatise l'ensemble du processus de mise en place. Bien que conçu pour Ubuntu 9.10, il fonctionne parfaitement sur la version 10.04 sortie récemment.
Des manifestations locales sont organisées un peu partout dans le monde par des volontaires pour aider toutes les bonnes volontés à faire leurs premières armes. Avec un peu d'accompagnement, on écrit son premier test en moins d'une heure et beaucoup moins pour les suivants. C'est très gratifiant de savoir qu'on contribue directement à la qualité de PHP et que des morceaux de son propre code sont distribués avec PHP.
Pour le moment, aucune manifestation n'est prévue en France mais n'hésitez pas à proposer d'en organiser une si vous le souhaitez. Enfin, le TestFest vise à initier des vocations. Si vous souhaitez continuer au-delà de la campagne, n'hésitez pas à le faire.
Mise à jour : Frédéric Hardy a rédigé un article très détaillé sur l'écriture de tests unitaires pour PHP que je vous encourage à lire.
2 000 téléchargements pour le livre blanc Industrialisation PHP
A peine 6 mois après sa publication, le livre blanc Industrialisation PHP vient de franchir la barre des 2 000 téléchargements. Ce chiffre important montre l'intérêt actuel des entreprises pour les problématiques d'industrialisation des développements PHP.
En près de 60 pages, ce livre blanc dresse un panorama des outils et des méthodes qu'il est possible de mettre en place au sein d'une entreprise pour produire des projet de qualité en respectant à la fois les délais et le budget. Quelque soit le degré d'avancement des procédures d'industrialisation dans votre entreprise, vous trouverez probablement dans ce livre blanc des éléments pour améliorer vos pratiques.
Pour fêter l'évènement, nous travaillons actuellement sur une version remaniée qui tiendra compte des remarques qui nous ont été faites et apportera quelques compléments notamment au niveau des outils. Par ailleurs, des illustrations supplémentaires et une bibliographie plus fournie seront également au menu de cette nouvelle édition qui devrait sortir avant l'été.
Statistiques d’usage de PHP sur Debian
La distribution Debian recueille des statistiques d'usage des différents paquets qui la composent et publie les résultats dans le cadre de l'initiative Debian Popularity Contest.
Un mot sur la méthodologie
Comme toujours avec ce genre d'études, la première chose à regarder est la méthodologie. Les statistiques sont recueillies à l'aide du paquet popularity-contest qui n'est pas installé par défaut. Seuls les serveurs l'ayant installé sont donc pris en compte ce qui représente tout de même un peu plus de 90 000 serveurs à ce jour.
Plusieurs informations sont disponibles pour chaque paquet dont celles concernant leur installation, leur mise à jour récente et leur usage, appelé "vote". L'outil considère qu'un serveur "vote" pour un paquet si un programme du paquet ou d'un paquet dépendant a été lancé au cours des 30 jours précédents la mesure. Les données anonymisées sont envoyées à Debian chaque semaine.
Il faut bien entendu garder en tête que ces statistiques ne comprennent pas les installations faites à partir des sources ou à l'aide de piles LAMP packagées comme Zend Server ou Xampp. Ces chiffres sont donc en dessous du nombre d'installations réelles de PHP.
PHP 5 a clairement supplanté PHP 4
La comparaison des statistiques de PHP 5 avec celles concernant PHP 4 est intéressante. On peut remarquer que le paquet php4-common est installé sur 6,37% des machines et utilisé sur à peine 2,06% d'entre elles contre respectivement 45,44% et 34,44% pour son équivalent PHP 5. Cela montre clairement que PHP 5 a supplanté PHP 4, ce qui bon signe tant les avantages apportés par la dernière version majeure de PHP sont importants.
PHP 4 étant désormais de l'histoire ancienne, nous allons nous concentrer sur les statistiques de la version 5.
Le SAPI le plus utilisé est mod_apache
Un SAPI, ou Server API, est le moyen de mettre en œuvre PHP soit en ligne de commande (CLI) soit au travers d'un serveur HTTP (mod_apache, CGI, etc.). On peut constater que le module pour Apache est le SAPI le plus utilisé avec près de 30 % tandis que le mode CGI n'est utilisé que dans 5 % des cas.
A noter le taux d'usage de près de 18% de PHP en ligne de commande (php5-cli) ce qui est intéressant car ce mode pourtant très pratique est très souvent ignoré ou négligé.
| Paquet | Installé | Utilisé | Mis à jour |
|---|---|---|---|
| libapache2-mod-php5 | 39,66% | 29,12% | 11,02% |
| php5-cli | 24,86% | 17,92% | 11,27% |
| php5-cgi | 8,05% | 5,34% | 3,54% |
| libapache2-mod-php5filter | 0,09% | 0,08% | 0,03% |
MySQL domine largement les autres connecteurs
Sans surprise, l'extension mysql domine largement les autres connecteurs de base de données avec un taux d'usage presque trois fois supérieur à celui des autres connecteurs réunis. A noter, le très faible usage d'ODBC tandis que Sqlite obtient un succès plutôt mitigé.
| Paquet | Installé | Utilisé | Mis à jour |
|---|---|---|---|
| php5-mysql | 29,55% | 20,98% | 7,95% |
| php5-pgsql | 5,19% | 3,54% | 1,87% |
| php5-sqlite | 3,69% | 2,59% | 1,57% |
| php5-odbc | 1,47% | 0,89% | 0,54% |
| php5-sybase | 0,98% | 0,60% | 0,37% |
| php5-interbase | 0,39% | 0,25% | 0,12% |
PEAR est peu utilisé
Avec un taux d'usage de 3,41%, PEAR déçoit. S'il est en perte de vitesse constante depuis plusieurs années, certains de ses paquets restent pertinents comme PHP_CodeSniffer qui permet de s'assurer de l'application de règles de codage. Par ailleurs, de nombreux outils de qualité comme PHPUnit, Phing ou encore les eZ Components sont distribués par des canaux PEAR alternatifs mais qui nécessitent l'usage du client officiel.
Les extensions PECL semblent peu utilisées
L'une des particularités de PHP est son découpage en extensions, chacune étant dédiée à une tâche précise. Il est donc aisé de compléter la panoplie de base avec les nombreuses extensions disponibles notamment au travers de PECL, le pendant de PEAR pour les extensions écrites en C.
Le taux d'installation très faible du paquet php5-dev, qui est nécessaire pour compiler ces extensions, montre leur faible utilisation.
Qu'en conclure ?
Il est difficile de tirer des conclusions de ces statistiques car elles ne sont pas représentatives de l'usage global de PHP. Cependant, elles confirment globalement ce que nous constatons au quotidien, à savoir qu'Apache et MySQL sont les outils les plus souvent associés à PHP.
Enfin, elles rappellent que si certains tirent pleinement parti des possibilités de PHP en utilisant PEAR et les extensions PECL, la majorité des utilisateurs se contentent d'un usage plus simple de PHP.
De l’intérêt de MVC pour tester son application
Quand on utilise une couche d'abstraction de base de données, comme PDO ou n'importe quelle couche écrite en PHP, la raison invoquée est souvent de pouvoir supporter différentes bases de données. Dans la pratique, sauter du jour au lendemain de MySQL à Oracle, ou le contraire, ne se fait jamais aussi simplement. En pratique, c'est même assez fallacieux comme argument.
Communément, il y a une bonne raison pour utiliser une telle couche : faire des tests. Et ça, cela arrive beaucoup plus souvent que de changer de base de données. À l'aide d'un simple changement de configuration, la couche d'abstraction de base de données vous permet de faire tourner facilement votre application sur une base de tests, ou celle de production, ou celle de recette, ou encore de vieilles versions... En disposant de jeux de données de tests, il devient alors possible de reproduire différentes situations, voire même de les faire cohabiter.
C'est une application qui justifie même l'utilisation de MVC de manière pratique : on utilise MVC au quotidien pour pouvoir faire des tests d'une partie de l'application sans perturber l'autre. C'est le principe même de séparation des objectifs.
En fait, la souplesse de la couche d'abstraction est également disponible avec le moteur de gabarits (aussi appelée la vue). Combien d'entre vous se plaignent de devoir envisager d'installer Selenium pour faire tourner des tests sur les gabarits ? C'est long, ça fait peur.
Or, un truc tout simple consiste à utiliser les gabarits pour faire les tests : au lieu de produire une page HTML complexe et pleine de Javascript et de CSS, vous pouvez produire une page XML ou JSON, qui contient toutes les informations à afficher, et dépouillée de la couche de présentation. En fait, n'importe que format facile à analyser dans le cadre de vos opérations sera une bonne idée.
Les tests unitaires deviennent alors beaucoup plus aisés à écrire, et vous ne dépendez plus de la couleur du bouton "OK", ou de la CSS. Vous appelez simplement le site, qui produit une page contenant les informations sans leur présentation. Si les bonnes informations sont présentes, il ne restera plus qu'à tester effectivement les couleurs du site : la logique métier est maintenant sous contrôle.
C'est d'autant plus intéressant que l'on utilise ici les gabarits de deux manières : une pour les tests, et une pour la production. Il manque encore une utilisation tierce des gabarits pour avoir trois utilisations modulaires, et être tranquille quant à la qualité de l'interface modèle / gabarit. Quand on met en place une interface, il faut généralement trois utilisations différentes pour être sûr que l'interface est bien modulaire.
En utilisant MVC pour faire les tests, vous allez gagner beaucoup en qualité de code : d'abord parce que vous allez faire des tests automatisables sur une partie de votre application; ensuite parce que vous allez utiliser la structure de votre application et non plus vous targuer d'utiliser simplement un motif de conception; et aussi comprendre un peu mieux vos différentes interfaces.
Livre blanc
Suivez nous sur Twitter
Catégories
Blogroll
Lectures
- APPLICATION.INI CheatSheet for your Zend Framework Application
- GraphicsMagick Image Processing System
- Comment veiller et faire de la médiation numérique efficacement avec Google reader et Diigo | Bibliobsession
- Writing Robust Bash Shell Scripts
- Open Jail - The Jailer Project Web Site
- Finding and Purging Big Files From Git History
- Git Immersion
- URL Design
- How to Improve Communication Between QA and Development
- Les frameworks c'est bien, développer "en dehors" c'est mieux