jeudi 11 novembre 2010

Forum PHP 2010 : la grosse édition !

L'édition 2010 du Forum PHP a tenu toutes les promesses que le double anniversaire des 10 ans de l'AFUP et des 15 ans de PHP laissait supposer.

Ce forum a surclassé par bien des aspects toutes les éditions précédentes, notamment en terme de fréquentation : durant ces deux journées, ce sont plus de 500 personnes qui auront foulé les allées du forum et les salles de conférences ! On peut cependant citer également l'abondance de sponsors et la surface totale dévolue au forum au nombre des records battus cette année. Sans oublier bien entendu les "rock stars" qui nous ont fait le plaisir de participer au programme des conférences, comme Rasmus Lerdorf, Zeev Suraski, Derrick Rethans, etc.

Pour revenir à l'essentiel, c'est-à-dire l'affluence de visiteurs et plus encore l'appétit avec lequel ils ont dévoré les différentes conférences proposées, le nombre de suggestions en rapport avec les sessions elles-mêmes me semble très révélateur. On notera entre autre la proposition de programmer les conférences plusieurs fois, pour pouvoir y assister même si un autre sujet d'intérêt est présenté simultanément. Des demandes relatives à l'information sur les conférenciers et le niveau des présentations ont également été faites à plusieurs reprises. Certains ont même suggéré que le forum soit rallongé d'une journée pour proposer encore plus de sessions, et plus longues !

Ces différents points m'amènent à la conclusion que le forum PHP de l'AFUP, bien qu'il ait conservé son esprit très enthousiaste et décontracté, s'est parallèlement grandement professionnalisé. On ne va plus au Forum uniquement pour "réseauter" et croiser les stars évoquées ci-avant. On y va surtout parce que les sujets abordés sont en phase avec les problématiques quotidiennes du développement web en PHP, qui sont toujours plus complexes, et plus intéressantes.

Pour toutes ces raisons, je suis particulièrement heureux d'avoir pu participer à ce forum au triple titre de membre de l'organisation (étant membre du bureau de l'AFUP), de sponsor (avec VA Consulting) et de conférencier (introduction à Zend Framework, dont vous pouvez trouver le support sur slideshare) !

J'ajouterai enfin une conclusion basée sur un sentiment plus personnel par rapport à ce forum. L'aspect professionnel de l'évolution du monde PHP m'importe bien sûr tout particulièrement. A cet égard, le Forum PHP 2010 semble pour moi marquer une nouvelle étape majeure dans la professionnalisation de PHP : l'un des sujets que je le plus entendu aborder sur ce salon est probablement la difficulté de recruter des développeurs qualifiés, des architectes et des experts PHP. 

Débattre librement de ce problème signifie qu'un tabou est en train de tomber : oui, parmi les développeurs PHP qui se proposent sur le marché nombreux sont ceux qui ne sont pas à la hauteur des enjeux et des problématiques des projets PHP actuels. Schématiquement, on peut dire que l'écosystème s'est professionnalisé plus vite que les professionnels. Nous entrons donc probablement dans une nouvelle phase de l'évolution de cet écosystème, phase dans laquelle la formation devrait prendre une place centrale et offrir des défis passionnants.

Je remercie une fois encore les nombreux visiteurs du Forum 2010, et vous dis donc à l'année prochaine à tous, pour la 11ème édition !

mardi 21 septembre 2010

Tester unitairement, ce n'est pas tester une seule fois !

Quoique j'ai l'impression que je m'apprête à rédiger des évidences, il me semble malgré tout plus que nécessaire de revenir sur l'intérêt fondamental des tests unitaires, tests dont je parlerai ici dans un sens élargi. Ce billet s'adresse en priorité aux développeurs qui soit ignorent simplement ce que sont les tests unitaires, soit doutent de leur intérêt. Aussi, si ma démonstration vous convainc, je vous invite à en transmettre le lien à tous ceux parmi vos connaissances qui relèveraient de l'une de ces deux catégories !

1. Définitions

Je ne veux pas rentrer dans les détails, et encore moins les querelles techniques, que les puristes m'en excusent. Je préfère être plus schématique pour faciliter la compréhension du propos. Et ce précisément parce que j'ai pu constater que la défiance généralement observée à l'endroit des tests unitaires vient principalement du fait que l'on ne comprend pas vraiment de quoi il s'agit concrètement.

Pour bien comprendre donc de quoi l'on parle je vais tenter de définir ce type de tests par opposition à ceux que l'on pratique intuitivement, ou plus exactement que l'on est bien obligé de pratiquer au cours du développement, à savoir les tests manuels. Car c'est en effet là que réside la différence principale entre ces deux familles de tests : l'une est manuelle, l'autre est automatisée. Cette caractéristique est primordiale dans le concept de test unitaire. Nous verrons bien sûr que ce n'est pas tout, mais lorsque l'on a compris l'intérêt de l'automatisation, les autres concepts véhiculés par le test unitaire prennent tout leur sens de manière assez évidente.

Revenons donc à nos deux types de tests, et essayons de les caractériser :

  •  les tests "manuels"
    • écriture
      • on y procède le plus souvent en ajoutant des petits straps de code à l'intérieur du code de l'application, à grand renfort de var_dump, print_r, echo et autres die
    • exécution
      • ils s'exécutent en faisant tourner une application ou l'une de ses sous-parties (page, composant, ensemble de composant, etc.) dans son contexte final (i.e. en utilisant l'interface graphique)
    • validation
      • le résultat attendu est comparé au résultat obtenu par l'opérateur du test
  • les tests "automatiques"
    • écriture
      • ils sont écrits sous forme de classes dédiées, indépendantes de l'application, à l'aide d'un framework spécialisé, offrant toutes les méthodes nécessaires pour matérialiser sous forme de code ce que l'on veut tester (assertions)
    • exécution
      • ils sont  exécutés dans un environnement neutre, isolé, lui aussi indépendant de l'application
    • validation
      • le résultat attendu est écrit à l'avance, dans la classe de test, et lors de l'exécution, seule la vérification (ou non) de ce résultat attendu comparé à celui obtenu est reporté
2. Conséquences

Reprenons les trois points déterminants utilisés dans la section précédente pour comparer les deux approches :

  • Ecriture
    • Dans l'approche manuelle, il est nécessaire de modifier le code de l'application elle-même pour y insérer nos tests. Ceci rend par définition le code nécessaire au test éphémère, puisqu'il n'est pas question de le conserver de manière pérenne (par exemple dans son dépôt Subversion), bien qu'il soit à peu près impossible de ne pas oublier un echo ou un var_dump quelques part avant de sauver voire de déployer son code...
    • L'approche automatisée permet de déporter le code nécessaire au test dans une arborescence dédiée, et ne vient donc pas polluer l'application.
  • Exécution
    • Le caractère intrusif de l'approche manuelle expliqué ci-dessus implique qu'il existe un risque que le test lui-même altère le comportement de l'application, et donc le résultat du test. En outre, puisque ce code de test ne peut être conservé de manière persistante, il sera nécessaire de le supprimer puis de le réécrire à chaque fois qu'il sera nécessaire de modifier le composant, et donc de le tester de nouveau
    • A l'inverse, ces problèmes ne peuvent pas exister avec des test automatisés. Puisqu'ils sont écrits et maintenus parallèlement au code de l'application, ils n'en modifient jamais le comportement, et peuvent être rejoués à tout moment et en quelques secondes, ce qui est essentiel pour s'assurer tout au long du développement de l'application que ce qui fonctionnait à un moment fonctionne toujours à un autre moment.
  • Validation
    • Durant un test manuel, on vérifie que le code a produit le résultat auquel on s'attendait, laissant parfois l'interprétation des résultats à la subjectivité du testeur, ou même à sa simple concentration, à son attention du moment...
    • Dans un test automatique, on vérifie que le code a produit le résultat que l'on voulait ! Ce qui pourrait sembler être un détail est en fait essentiel. Il est objectif, ne dépend pas de l'opérateur. Il ne dépend que des assertions décrites dans la classe de test, qui ne changent ni avec le temps, ni avec l'opérateur.
3. Du test automatisé au test unitaire

Mais alors pourquoi parler de tests unitaires, et non pas simplement de tests automatisés ? Je ne doute pas que les explications ci-dessus vous auront convaincu de l'intérêt de cette approche, mais peut-être vous demandez-vous encore où est le piège ? Si c'était si simple, les tests unitaires, tout le monde les utiliserait depuis longtemps !

Si ces tests automatisés sont appelés "tests unitaires", c'est tout simplement parce qu'ils ne peuvent s'appliquer qu'à des fractions élémentaires de l'application ("unités"), puisqu'ils sont exécutés en-dehors. En règle générale, l'unité retenue pour un test est la classe, les assertions s'appliquant au retour des méthodes. Pour que chaque unité soit indépendante des autres, il faut ... qu'elle n'en dépende pas ! 

Prenons un exemple simple : une méthode qui doit travailler sur un objet X doit le recevoir en argument, et non pas l'instancier elle-même (principe de l'injection de dépendance). Au moment de tester cette méthode, elle sera invoquée avec en paramètre cet objet X que l'on aura pris soin d'instancier soit même dans le code du test, avec des données "en dur", et donc que l'on maîtrisera complètement. Ainsi, si le test échoue, on pourra éliminer l'hypothèse que peut-être l'objet X en question n'était pas ce qu'il aurait dû être, etc.  En résumé, l'échec d'une assertion ne doit pouvoir signifier qu'une seule chose : l'échec de la méthode testée !

Tester unitairement une application suppose que les classes qui la composent soit fortement découplées. Cela implique une vision très objet du code, qui n'est pas évidente à maîtriser. Et c'est probablement ce qui rend l'adoption massive de la pratique des tests unitaires si délicate. 

Pourtant, à bien y réfléchir, on peut aussi voir le code utilitaire comme un guide facilitant grandement la conception des objets composant une application ! En utilisant la phase d'écriture des tests comme support à la conception des objets eux-mêmes, avant même d'en écrire le code, vous vous obligez à créer des objets "propres", très faiblement couplés.

Cerise sur le gâteau, écrire vos tests avant d'écrire les objets vous donne une métrique précise de l'avancement de votre projet : le but étant d'écrire du code jusqu'à ce qu'il permette de faire tourner votre jeu de tests sans que plus aucun test n'échoue, la sortie de l'utilitaire de test vous informera avec précision du nombre de méthodes/objets finalisés, et conformes à vos spécifications (que matérialisent vos tests unitaires). En passant, pour ceux qui ne l'auraient pas identifiée, cette méthodologie est appelée Test Driven Development (dévelopement dirigé par les tests). 

Enfin, il est important de préciser que cette méthode, comme les tests unitaires eux-mêmes, doivent en priorité s'appliquer aux parties les plus critiques de l'application, et tout particulièrement la bibliothèque d'objets métiers (ceux qui manipulent vos données !).

Conclusion

Si certains pensent qu'écrire des tests unitaires représente une perte de temps, que l'on ne peut se l'offrir si l'on est pressé, je dirais que ceci n'est (partiellement) vrai que si et seulement si l'on n'est pas à l'aise avec l'écriture de test. Mais ceci, comme tout autre connaissance, vient avec la pratique. Et une fois la compétence acquise, on se rend compte qu'il n'est simplement pas raisonnable de développer sans tests unitaires, ou à tout le moins sans tests automatisés. Pour acquérir cette maîtrise, vous pouvez donc commencer par utiliser un framework de tests unitaires tel PHPUnit (le vénérable ancêtre) ou Atoum (le challenger) pour automatiser vos tests, quels qu'ils soient, et plus vous l'utiliserez, mieux vous le connaîtrez, plus vous affinerez votre code pour finalement créer un code totalement découplé, testable unitairement, plus facile à debugger, à maintenir et à faire évoluer !

vendredi 3 septembre 2010

Le programme du Forum PHP 2010 est en ligne !

Ce rapide petit billet juste pour relayer l'annonce du programme du Forum PHP 2010. Pour mémoire, cette édition sera l'occasion de fêter les 10 de l'AFUP ainsi que les 15 ans de PHP. On ne sait pas encore si on fera un gâteau avec 25 bougies ou deux séparés :)

Mais du côté des cadeaux, on a déjà fait le plein avec des conférenciers de qualité, et il va de soi que je ne parle pas de moi :) Je pense plutôt à Rasmus Lerdorf ou encore Jonathan Wage, Fabien Potencier, etc.

Bref, je vous invite à juger vous-même, et à réserver vos places si ce n'est déjà fait !

http://afup.org/pages/forumphp2010/deroulement.php

mercredi 18 août 2010

L'humilité, la première des bonnes pratiques ?

Je ne peux pas croire que je sois le seul à qui il arrive, en relisant un code produit par quelqu'un d'autre, de me dire "mais qu'est-ce qu'il a bien pu lui passer par la tête pour écrire quelque chose d'aussi absurde ?". 

A cette question, que je me suis tant de fois posée, et souvent en termes nettement moins châtiés, j'hésite souvent à apporter l'une des trois réponses suivantes :

1. Il était contraint par les délais...

C'est la raison la plus souvent invoquée pour justifier un travail bâclé. Mais l'excuse ne tient pas dès lors que l'on admet que négliger une partie d'un projet, si infime soit-elle, conduira nécessairement à de bien plus lourdes pertes de temps ultérieurement. En effet, un élément du système qui serait soit mal conçu, soit mal réalisé, ou encore mal voire pas testé, bloquera la mécanique tôt ou tard, et rendra d'autant plus difficile l'identification et la correction des problèmes engendrés.

Si l'on n'a pas de temps à perdre, on ne peut s'offrir le luxe de l'improvisation, et c'est précisément dans ce contexte que le respect des bonnes pratiques s'impose plus que jamais. Je pense très clairement qu'il faut, en tant que développeur, avoir l'humilité de ne pas penser que l'on peut faire son travail correctement au mépris de toute bonne pratique. Notez au passage que le développement est bien l'un des rares métiers dans lesquels on tolère ce genre d'attitudes. Un cuisinier qui déciderait de cuire un tournedos au micro-ondes pour gérer un afflux de commandes trop important se verra inviter à rendre son tablier sur-le-champ ! Le délai est une contrainte, mais pas la seule. La qualité est autrement plus importante, car elle conditionne notre capacité à continuer de s'adapter aux délais à plus long terme. Sans oublier la confiance qu'elle permet d'établir puis de maintenir avec les donneurs d'ordre.

2. Il ne savait pas faire autrement...

Le manque de maîtrise des outils et méthodes nécessaires à la réalisation des projets est également un grand classique. A cela il peut y avoir plusieurs raisons. Certains manquent tout simplement d'intérêt pour leur métier, d'autres de discernement quant à leur compétence, et ne se rendent pas vraiment compte qu'ils ne savent pas faire. Dans le premier cas, je ne vois guère de remède. 

Pour les autres, prendre quelques minutes après coup pour s'interroger sur ce que l'on vient de faire, avec un peu de recul, et se forcer toujours à se demander s'il n'y aurait pas d'autres façon d'y parvenir, suffit le plus souvent à corriger dès le début un travail qui sinon ne le sera jamais, et polluera l'ensemble de manière définitive. Solliciter des collègues est également un bon moyen, au travers d'un regard extérieur, de valider ou non ses choix. Enfin, il ne faut jamais hésiter à reconnaître ses lacunes, ou au moins à les envisager (on a parfois de bonnes surprises !), et à exiger d'être formé sur les outils que l'on nous demande d'employer. Je pense particulièrement aux frameworks : des responsables prennent parfois la bonne décision de baser les développements sur un framework sans l'accompagner de l'excellente initiative d'y former ses équipes.  Un développeur est supposé connaître un langage. Maîtriser un framework, même s'il est basé sur ce langage qu'il connait, n'est pas évident, et surtout pas inné. Une formation est un bon moyen d'en prendre possession rapidement, sans contracter de mauvaises habitudes par simple manque de connaissances, que l'on ne peut pas inventer !

3. Il n'est pas développeur, il est soudeur à l'arc

Ceci expliquant cela... 

Conclusion

Trêve de plaisanterie, aborder son métier avec humilité me semble être une nécessité absolue si l'on a la naïve mais essentielle ambition de continuer de progresser. Etre humble ne signifie pas douter de soi, et encore moins s'imposer de penser que ce que l'on fait n'est pas bon. Cela signifie être conscient que l'on peut toujours se tromper, et qu'il faut rester vigilant. Qu'il ne faut jamais douter que d'autres peuvent avoir une meilleure approche d'un problème, et se réjouir d'en profiter plutôt que de se morfondre de n'y avoir pas pensé soi-même, ou pire, rejeter en bloc et n'en faire qu'à sa tête. 

Enfin, être humble dans le développement, c'est aussi se rappeler que ce que l'on fait n'est pas une fin en soi, mais a pour vocation de soutenir un activité commerciale, associative, éducative... En gardant cela à l'esprit, on évite plus facilement de tomber dans le piège du "troll", ces fameux débats stériles et partisans infiniment nuisibles à la qualité du travail produit, mais aussi aux conditions dans lesquelles on le fait !

mardi 17 août 2010

france.fr

Bon je fais court, très court même. Mais après avoir longtemps résisté, tant c'était facile, et de fait presque indigne, je craque.

On pourrait croire que je n'assume pas mon billet sur Drupal (et tout le mal que j'en pense, pour résumer à l'attention de ceux qui ne l'auraient pas lu) si je ne faisais pas la moindre référence au délicieux fiasco qu'a été le lancement (et qui sait, peut-être le développement aussi ?) de www.france.fr.

Pour être honnête, je ne me suis pas plus intéressé que ça à ce dossier. J'ai simplement entendu beaucoup de monde railler abondamment les services de l'Etat avant de découvrir, par hasard soit dit en passant, que ce site avait été développé avec Drupal.

Je n'ai qu'une chose à dire : CQFD !

Série d'interviews sur PHP6

A l'initiative de mon camarade de jeu Frédéric Hardy, une série de plusieurs interviews sur l'avenir de PHP 6 a été publiée sur son blog personnel, que je qualifierais volontiers de professionnel.

Il m'a fait la gentillesse de solliciter mon point de vue sur la question, aussi je souhaitais faire connaitre cette publication car elle me semble tirer le débat un peu vers le haut, et nous donner l'occasion de réfléchir d'une manière un peu plus objective sur l'avenir de PHP.

Bien que je me pose moi-même la question depuis un moment, et qu'il me soit arrivé de m'exprimer sur le sujet, je me suis rendu compte en répondant aux questions de Frédéric à quel point nous pouvions parfois, en tant qu'utilisateurs (entendez "développeurs" naturellement), être très éloigné de la façon dont la plateforme évolue.

Alors j'espère que la lecture de ces différentes interviews vous amènera vous aussi à vous interroger plus avant sur l'implication que nous pouvons avoir dans l'évolution de PHP, en tant que professionnels aussi bien que de passionnés.

Pour ma part, j'en suis arrivé à la conclusion que JFK, qui n'en savait pourtant rien, avait déjà bien résumé la situation, du moins si on s'autorise à le paraphraser : "ne te demande pas ce que PHP peut faire pour toi, mais demande-toi ce que tu peux faire pour PHP".

mercredi 16 juin 2010

Pourquoi je déteste Drupal (et la plupart des autres CMS)

Voilà quelque temps que je me retrouve régulièrement empêtré dans des débats stériles concernant les CMS (système de gestion de contenus prêt-à-l'emploi) en PHP, et particulièrement Drupal, auquel j'ai été confronté lors de missions chez différents clients, et dont la popularité le désigne tout naturellement comme bouc-émissaire de premier choix pour traiter du mirage que sont les promesses des CMS.

Je vais donc tenter dans ce post de résumer les raisons objectives pour lesquelles je n'accepte plus de travailler sur des projets basés sur cet environnement. Bien sûr la liste n'est pas exhaustive, mais les problèmes qu'elle pointe sont tels qu'il ne devrait pas être nécessaire d'en ajouter plus. Ces observations sont issues de l'expérience, et dénoncent des défauts qui handicapent réellement les projets. Il faut les prendre pour ce qu'ils sont, à savoir une mise en garde.

Voici donc les reproches que je peux adresser à Drupal, même si encore une fois ils pourraient s'appliquer à l'essentiel des autres CMS disponibles à l'heure actuelle :
  1. L'approche procédurale

    Les CMS s'adressent principalement à un public de non-développeurs ; autrement dit, au grand public. Celui-ci ayant quasi systématiquement recours aux hébergements mutualisés, lesquels ont très longtemps (et continuent pour certains !) imposé PHP4 à leurs clients, les CMS ont dû se plier à cette contrainte et maintenir une compatibilité totale avec cette version désormais obsolète de PHP, sur laquelle beaucoup ont en plus été conçus, sans que leur design initial n'ait jamais été remis en cause.

    Ceci semble avoir parfaitement satisfait les développeurs de Drupal (ainsi que ceux de sa communauté), qui sont dans l'ensemble très fâchés avec le développement objet. Songez que l'un des seuls objets core de Drupal est le node (concept absolument central de Drupal), qui n'est autre qu'une bête StdClass !

    Je suis même tombé (merci Alex !) sur un article d'un évangéliste Drupal qui nous explique avec le plus grand sérieux que l'absence de classes dans le design de Drupal est un choix délibéré, mais que cela n'empêche pas Drupal d'appliquer la majorité des concepts du paradigme objet. Encore plus savoureux, il nous est exposé la thèse suivante : en se gardant d'utiliser les objets, il a été possible aux développeurs Drupal d'implémenter des concepts "encore plus objet" que ce que permet le moteur orienté objet de PHP ! Ca me fait penser à ceux des artistes contemporains qui mettent trente secondes à créer une "oeuvre", puis des années à en théoriser le concept, mais c'est une autre histoire... Bref, pour consulter ce chef-d'oeuvre de mauvaise foi, c'est par là !

    Nous pouvons donc constater que ces développeurs sont adeptes de ce que PHP a de plus médiocre à offrir, du fait d'une utilisation sans discernement de sa permissivité, au mépris de toute bonne pratique. Je pense ici notamment à ces fameuses variables globales, à commencer par $user (dont je vous laisse deviner ce qu'elle matérialise...), ainsi qu'au recours à eval(), le honni (encore présent dans Drupal 7, j'ai vérifié) !

    On se retrouve donc confronté à une base de code foisonnant de fonctions par milliers, très fermement couplées entre elles (puisqu'impossibles à redéfinir, naturellement), limitant de fait les personnalisations possibles. Ceci à conduit à la mise au point dans Drupal d'un système de module qui a paradoxalement fait sa renommée. Mais j'y reviendrai dans le point suivant.
  2. Une modularité très discutable
  3. Drupal offre à ses utilisateurs un aréopage de modules hétéroclites, et surtout très souvent en conflit les uns avec les autres. S'il est juste de dire que des modules existent pour couvrir fonctionnellement de très nombreux besoins concrets, il faut toutefois relativiser la soit disant valeur-ajoutée de cette manne :
    • le foisonnement en est tel qu'il est souvent long et difficile de sélectionner le plus approprié (étrangement, la communauté préfère réaliser deux modules disposant chacun de 3 fonctionnalités plutôt qu'un seul doté des 6...)

    • cette vilaine manie qu'ont les développeurs de recourir aux patches pour appliquer leurs modules vous amène très vite à casser toute compatibilité descendante avec les futures versions du CMS, ainsi qu'avec certains autres modules.

    • le recours à l'appel "à l'aveugle" de fonctions via call_user_func(), dans le contexte du mécanisme de hooks, est une plaie du point de vue des performances d'une part (au moins jusqu'à PHP 5.3, dont je ne suis pas certain de la compatibilité avec Drupal par ailleurs), mais aussi et surtout pour la compréhension du flux d'exécution ! C'est bien simple, on n'y comprend rien (point de vue confirmé par d'honnêtes Drupal fan boys...)
  4. Un emploi déraisonnable de la base de données

    Dans Drupal, tout ou presque se passe dans la base de données. Outre que ceci est parfaitement imbécile là encore du point de vue des performances (j'ai souvent vu des pages de sites Drupal nécessiter de 400 à 1000 requêtes SQL pour être générées, le cache n'arrangeant que peu les choses, sans compter les modules qui parfois produisent des requêtes de plusieurs dizaines de secondes), c'est absolument cataclysmique pour les tests (unitaires ou pas), la gestion des versions et des mises en production.

    En effet, les modifications que l'on apporte à un projet sous Drupal sont partagées entre le code et la base de données. Autrement dit, pour tester ce que l'on a fait localement sur un serveur de recette par exemple, il faut synchroniser les bases de données, ce qui n'est pas chose aisée. Bien sûr, cela sera également nécessaire pour que les autres collaborateurs du projet puissent appliquer vos modifications sur leurs environnements locaux. Et une fois de plus sur la production. Et procéder à l'opération inverse pour revenir en arrière, le tout en parfait accord avec le versionning SVN/GIT. Mission quasi impossible.

    Moralité, les développeurs travaillent sur des versions qui ne sont pas identiques, ce qui se révèle être une source intarissable de bugs les plus idiots qui soient.

Conclusion

J'en aurais encore beaucoup à dire sur le sujet, mais je préfère partir du principe que si nous ne sommes pas d'accord à ce stade, nous ne le serons jamais, et inversement !

Je finirai donc en rappelant simplement une fois de plus que les CMS sont conçus uniquement pour un public de non-développeurs, et qu'il ne faut pas y recourir si l'on à la moindre velléité de personnalisation (essayer d'intégrer un véritable workflow à Drupal, on en reparlera...).

Dans le cas contraire, c'est-à-dire dans tous les projets que l'on peut avoir à gérer dans un contexte professionnel (hors "web agencies de quartier" s'entend), ces CMS sont à proscrire. Ils ne sont pas faits pour vous, même si le succès rencontré auprès d'une foule d'amateurs et de quelques professionnels désoeuvrés leur a laissé croire le contraire.

Pour un développement sur la base d'un cahier des charges précis, utilisez des frameworks, c'est-à-dire des environnements maîtrisés de bout en bout, lesquels vous fourniront le cadre nécessaire pour écrire un code métier efficace et maintenable, les outils nécessaires à la mise en place d'un véritable cycle de développement, plutôt que l'illusion de vous fournir un code métier "clés en main" (ce qui est, convenons-en, proprement absurde !).

vendredi 11 juin 2010

Forum PHP 2010 : Appel à conférenciers !

En attendant un contenu propre qui reste en perpétuelle préparation, je me devais de le relayer ce communiqué de presse de l'AFUP, qui enjoint tous les experts PHP de la planète (non, je n'exagère pas :)) à soumettre des sujets de conférence pour le prochain Forum PHP, qui se tiendra le 9 et 10 Novembre 2010 à la Cité de Sciences de La Villette (Paris).

Voici le texte intégral, que vous pourrez également retrouver sur : http://afup.org/pages/site/?route=actualites/412/experts-php-participez-au-forum-php-2010






Experts PHP : participez au Forum PHP 2010 !


A l'occasion de cet anniversaire, l'Association Française des Utilisateurs de PHP organise un Forum plus ambitieux que jamais, prévoyant de nombreuses conférences et débats, ainsi qu'un espace d'exposition pour les équipes de projets libres souhaitant venir à la rencontre d'un public de professionnels (développeurs, décideurs, presse...).


Vous êtes expert sur un domaine, vous avez installé une ou plusieurs applications PHP (CMS, e-commerce, CRM, GED) dans un contexte spécifique (forte charge, client reconnu, projet innovant) ou bien vous participez à un projet Open Source lié à PHP, venez partager votre expérience !


Pour l'édition 2010, les thèmes particulièrement mis en lumière seront les suivants :


* PHP de A à Z : Débuter en PHP, Réussir un projet avec PHP, Choisir son hébergement


* Outils basés sur PHP : CMS et CMF, outils de e-commerce et de business, paiement en ligne, CRM et ERP


* Industrialisation de PHP : Performances, tests, authentification centralisée, frameworks


* Technologies autour de PHP (Javascript, HTML 5, microformats)


Pour soumettre votre sujet de conférence, rendez-vous surhttp://afup.org/pages/forumphp2010/appel-a-conferenciers.php et complétez une demande en ligne avant le 30 Juin 2010.


Vous souhaitez traiter un autre thème ? Vous n'avez pas d'expérience en tant que conférencier ? Vous souhaitez des renseignements sur la logistique que nécessite votre participation au Forum ?


Contactez Sarah sur organisation@afup.org

dimanche 17 janvier 2010

Solr : le SQL killer pour la recherche

Ceux qui connaissent le Zend Framework et qui ont été confronté à la problématique de mettre ne place un moteur de recherche sur un site ou une application ont certainement eu ne serait-ce que la curiosité de regarder de près Zend_Search_Lucene. Ce composant est une réécriture de Java Lucene, excellent moteur de recherche full-text (entre autre) développé et maintenu par la fondation Apache.

Le portage en PHP est parfaitement compatible au niveau binaire avec son homologue Java. Au niveau binaire signifie, en l'espèce, qu'il est capable d'interroger des index créés avec la version Java de Lucene, et qu'inversement, Java Lucene peut travailler avec les index créés par Zend_Search_Lucene. Et ces index sont stockés dans un format binaire, pour améliorer les performances.

Et c'est précisément là que le bât blesse dans la version PHP de Lucene... si vous avez non seulement regardé de près, mais aussi testé un minimum, avec un jeu de données réaliste, vous vous serez sans doute rendu compte que dès que l'on atteint quelques dizaines de milliers d'entrées dans l'index, ce n'est clairement plus utilisable.

C'est donc là que Solr intervient. Solr est une application Java à déployer sur un serveur d'application type Tomcat (ou encore Jetty, par ailleurs fourni avec l'archive). Son déploiement n'est d'ailleurs pas exactement trivial, du moins pour un habitué de PHP comme je le suis. Mais passons, j'ai tout de même réussi à m'en sortir sans trop de difficultés.

Pour un usage "basique" (mais déjà très impressionnant), peu d'étapes suffisent avant une réelle possibilité d'exploitation.

La première consiste à définir les caractéristiques de son index. Cela se passe dans un fichier XML, qui a l'avantage d'être fourni avec non-seulement un exemple de schéma, mais aussi et surtout de très abondant commentaires, qui constituent par ailleurs l'essentiel de la documentation sur le sujet (ce que l'on peut au passage déplorer, mais bon, imaginons que ça suivra). Définir son index ressemble approximativement à designer une table de base de données. Cela dit, il y a naturellement certaines différences fondamentales.

Parmi les premières notions à acquérir, il y a pas mal de jargon... les notions de "document", de "field types", "fields", "tokenizer"... qui nous sont le plus souvent familières, mais pas nécessairement selon les mêmes acceptions que celles retenues dans Solr/Lucene. Mais là encore, cela s'acquiert très vite. Déjà, quand on a retenu que Document (Solr) = Row (SQL), on a fait du chemin :)

Bref, une fois le schéma défini, on peut commencer de charger des données dans l'index (après avoir simplement redémarré Solr). L'alimentation de l'index, comme la plupart de opérations que l'on réalise sur Solr, se fait via un pseudo service web. En fait, il suffit d'appeler une URL, qui varie selon l'opération qui nous intéresse, et de lui adjoindre d'éventuels paramètres directement dans la "query string" (type ?param=value&otherParam=otherValue). Un peu finalement comme on le ferait pour appeler les différentes actions d'un contrôleur dans une application MVC.

Les actions principales avec Solr sont select (effectuer une recherche), update (ajouter/mettre à jour des documents), et admin (pour accéder à l'interface d'admin, qui, attention n'est pas protégée par défaut !).

Ce billet n'étant pas un tutoriel à proprement parler, je ne résisterai à la tentation de rentrer trop dans les détails, mais je conclurai en listant quelques unes des fonctionnalités de Solr, afin de vous inciter à aller télécharger le package et à suivre le getting started pour vous convaincre  que Solr est une mine d'or pour qui a besoin d'un service de recherche évolué, et somme toute d'une simplicité déconcertante à mettre en place (comparée à la complexité et à la lourdeur des requêtes SQL qu'il faudrait écrire pour s'en passer, sans même parler du degré de pertinence infiniment moindre avec cette deuxième solution) :

 - recherche ultra rapide sur un serveur standard, y compris sur des index allant jusqu'à +/- 1 million de documents
 - gestion native et simplissime des facettes de recherche (ajout de &facet=on&facet.field=NOM_CHAMP) pour l'activer
 - recherche par similarité
 - indices de pertinence natif (mais également personnalisable)
 - recherches spatiales (à partir de coordonnées - intégré à la v1.5, disponible en plug-in pour les précédentes)
 - différents formats de résultats possibles (json, source php, php sérialisé, XML...)
 - possibilité d'effectuer directement une transformation XSLT sur les résultats XML pour retourner du code HTML directement affichable en guise de résultats de recherche
 - etc.

Convaincu ? J'espère :) En tout cas, la suite, c'est par là !