dimanche 14 décembre 2008

Forum PHP 2008 : le retour (thanks to PHP TV)

Pour ceux (nombreux me semble-t-il) qui n'ont pu se rendre sur le Forum, l'équipe de PHP TV vous offre une session de rattrapage, avec les vidéos des conférences !

Celles-ci seront mises en ligne au fil des prochaines semaines, sauf quelques-unes qui sont déjà en ligne !

J'en profite pour rappeler que PHP TV, c'est une "webission" de TV dédiée à PHP (ça vous l'aviez deviné), dont un numéro environ sort chaque mois (voir lien dans la colonne de droite...).

mercredi 10 décembre 2008

Forum PHP 2008, that's over

de nombreux événements m'ont une fois n'est pas coutume privé du peu de temps libre dont je dispose habituellement.

Parmi ces événements, il y a en a un dont j'aimerais dire quelques mots : le Forum PHP 2008, organisé par l'AFUP.

J'ai eu l'occasion d'y passer deux journées (sans compter les after avec le staff de l'AFUP ;)) durant lesquelles les rencontres et expériences ont été nombreuses et enrichissantes, que ce soit avec les organisateurs, les conférenciers ou les visiteurs.

Cette édition du Forum PHP fut donc particulière pour ce qui me concerne, à la fois à titre personnel et professionnel.

Pour information, j'ai eu l'honneur (mais aussi la lourde tâche ;)) de porter la parole de Zeev Suraski, qui n'a malheureusement pu se rendre à Paris pour le forum, en assurant la conférence sur la place de PHP dans l'entreprise mardi 9.

Et à-propos des conférences, PHP TV en diffusera la plupart dans les prochains jours sur son site, ainsi que des interviews de différents participants (où est Charlie ?? :)). Merci à eux pour leur présence, patience, et passion !

A l'année prochaine, Forum PHP, quant à l'AFUP, à très bientôt !

lundi 27 octobre 2008

encore un peu de patience...

oui, de la patience, il va m'en falloir pour me ner à bien ce projet de documentation alternative pour le Zend Framework.

Cependant, ça avance déjà... les premiers scripts sont créés, même si je ne les ai pas encore rendus publiques.

Pour ceux que ça intéresse, le détail de la progression est tenu à jour dans le post d'annonce initial sur z-f.fr.

à bientôt !

vendredi 17 octobre 2008

Détournement d'attention !

Je désespère de trouver plus de temps pour continuer d'alimenter ce blog... non pas que je tombe dans le piège classique du manque d'inspiration ou de la lassitude après quelques posts seulement.

Loin de là. Des sujets à traiter, j'en ai beaucoup en réserve, et j'ai très envie de les traiter en outre !

Mais il se trouve que je me suis engagé plus avant dans une contribution active à la documentation du Zend Framework, et ce de deux façons :

- bien sûr, en procédant à des traductions. J'ai démarré ; c'est long, mais intéressant, et surtout nécessaire absolument !

- en écho à mon billet précédent et à une discussion sur le forum z-f.fr (Forum francophone dédié au Zend Framework), j'ai annoncé (prématurément par rapport à mes intentions premières d'ailleurs) la naissance prochaine d'un projet de documentation alternative pour le Zend Framework (c.f. le post sur z-f.fr pour l'idée de base).

J'en posterai les détails prochainement, sur z-f.fr et ici-même. Entre temps, n'hésitez pas à manifester votre intérêt pour le projet, nous aurons besoin de monde !

dimanche 12 octobre 2008

De l'importance de la documentation !

Un court post aujourd'hui, de l'ordre du billet d'humeur...

Je voulais juste rappeler à tous ceux qui produisent des API/frameworks/librairies que rien ne sert de proposer des fonctionnalités formidables s'il est malaisé de les utiliser.

Dans certains cas, on passe tout simplement à côté de fonctionnalités uniquement faute de documentation adéquate. Et il n'y a rien de plus rageant que de s'apercevoir qu'on a du implémenter quelque chose qui était déjà présent, mais non-documenté.

Pour tout ce qui concerne ces catégories de logiciels, je ne peux que renvoyer au modèle du genre qu'est la documentation de PHP. Je crois sincèrement que sa qualité est pour beaucoup dans le succès de ce langage.

Cette documentation est :
  • multi-lingue
  • collaborative (nombreux commentaires et exemples précieux des utilisateurs)
  • exhaustive (précise pour chaque section les versions du langage compatibles)
  • abondante
  • simple d'accès (php.net/fonction pour un accès direct !)
  • rapide
  • atomique (chaque section se suffit à elle-même, et ne nécessite pas la lecture d'autres passages)
Bref, c'est du bonheur... L'organisation des thèmes permet facilement de trouver de manière très intuitive des fonctions dont on ne connaissait même pas l'existence !

Alors, je ne citerai personne, mais beaucoup sont concernés ;) Il n'y a pas de honte à reprendre un modèle qui fonctionne... j'espère pouvoir le démontrer prochainement. En attendant, pensez aux utilisateurs néophytes de vos outils, qui ont un réel besoin de documentation performante pour être eux-mêmes performants avec vos API/frameworks/librairies.

dimanche 5 octobre 2008

GwtPHP, un framework hybride

Google Web Toolkit (GWT) est une librairie écrite en Java, avec laquelle on code donc en Java, pour générer des interfaces graphiques web/2.0 en JavaScript et HTML. L'avantage de ce sytème étant de recourir à un langage fortement structuré (Java) pour fabriquer un code qu'il serait souvent épouvantable d'écrire à la main (JavaScript), surout pour atteindre un support aussi étendu de navigateurs que le propose GWT.

En revanche, utiliser Java côté serveur (pour la partie métier) n'est pas toujours des plus enthousiasmant... en tout cas moi je ne suis pas très partisan. Mais GWT est un peu compliqué à intégrer sur un serveur lambda (i.e. autre que Tomcat, qui ).

La société QualityUnit a choisit d'unir plus intimement GWT et PHP, en créant... GwtPHP.

Je n'ai pas encore testé, pour la simple raison que le produit n'est pas encore disponible (il devrait l'être début Novembre), mais il est possible d'accéder à une démo en ligne depuis le site officiel. La démo est plutôt impressionnante je dois l'admettre : c'est joli, ça marche bien, et ça semble vraiment très carré (j'attendrai les sources du produit pour confirmer ce dernier point :)).

Mais un point me chiffonne quand même : que doit-on penser de cette réplication des interfaces de Vista et OsX ? Est-ce une bonne chose, car cela permet d'une part de prendre le meilleur d'interfaces intensivement réfléchies, et dont les utilisateurs sont familiers ? Ou bien peut-on se demander si singer les interfaces des applications de bureau dans le cadre d'une application web est vraiment adequat du point de vue de l'ergonomie ?

Je ne peux m'empêcher de penser qu'il s'agit là d'un gâchis de créativité - le web permet une grand liberté dans la conception d'interfaces, il a déjà beaucoup influencé les interfaces de bureau (simples clics, design très visuel, etc.), aussi me semble-t-il dommage de faire l'inverse maintenant...

Cela dit, peut-être s'agit-il d'une évolution logique, un monde entraînant l'autre, et inversement ? Le mimétisme entre les bureaux webs et traditionnels est une tendance qui date déjà maintenant, et elle n'a jamais vraiment pris. L'influence que chacun des environnements a désormais sur l'autre conduira peut-être à une convergence totale dans les années à venir ?

N'oublions d'ailleurs pas que cette convergence existe déjà partiellement, par le biais des "gadgets", qui peuvent être compatibles à la fois avec Netvibes, Google et Vista par exemple.

mardi 30 septembre 2008

Bonnes pratiques PHP : faut-il privilégier les frameworks ou les moteurs ORM ?

Voici ce qui pourrait fort bien devenir le premier troll de ce blog...

La question revient régulièrement ces dernières années, notamment du fait de l'apparition de frameworks toujours plus complets et perfectionnés. Avant d'émettre un quelconque avis, il convient de revenir sur certaines notions essentielles à la compréhension de la problématique :

Comment faisait-on avant ?

Si l'on se demande aujourd'hui quoi utiliser comme cadre à ses développements, du framework ou de l'ORM, il ne faudrait pas oublier comment l'on faisait avant l'apparition de ces couches de haut-niveau. Ni pourquoi on faisait autrement.

Oui, je suis bien en train de vous parler de cette époque antédiluvienne, de ce temps béni où l'on faisait n'importe quoi avec PHP, parce que l'idée même que l'on puisse faire mieux en termes de conception et de réutilisabilité ne nous effleurait même pas.

Certes, j'exagère un peu. Mais pas tant que ça. Puisque l'on avait tendance à repartir de zéro à chaque projet ou presque, et que l'on codait tout "à la main", on a usé et abusé de la permissivité de PHP.

Cela a conduit à un résultat curieux : à la fois une adoption massive de PHP, notamment de la part de non-développeurs, alors pourtant que le code produit était vraiment de piètre qualité, les performances et la sécurité totalement négligées etc.

Un premier effort vers la standardisation : les ORM

Dès lors que ces problématiques ont été identifiées, certains ont commencé à réfléchir à des solutions. La première réponse tangible proposée pour réduire la quantité de code à réécrire tout en systématisant certaines optimisations et certains contrôles de validité sur les données fut les ORM (Object/Relationnal Mapping). Très fortement liés à la programmation orientée objet, les ORM ont pour vocation de permettre la représentation (le stockage) d'objets directement dans une base de données.

Parfois qualifiées elles-mêmes de framework (pour compliquer un peu les choses), ces librairies permettent d'uniformiser l'accès aux données, en offrant en outre une certaine dose d'abstraction (possibilité d'interchanger les moteurs de bases de données auxquelles se connecte l'application sans devoir modifier le code). Plus encore, les ORM proposent d'automatiser certains traitements (simples) sur les données, comme la création, suppression ou modification d'enregistrements, y compris en tenant compte des contraintes relationnelles.

De ce fait, les ORM ont forcé les développeurs à prendre conscience de l'importance de la conception, notamment du design de la base de données. Celle-ci devant respecter les normes et nomenclatures imposées par la couche ORM, il devenait indispensable de prendre le temps de réfléchir à l'organisation de ses données avant de commencer le code.

Les Design Patterns : le trait-d'union entre ORM et Framework

Parallèlement l'apparition des ORM, qui en sont pour ainsi dire une émanation, un certain nombre de bonnes pratiques de conception ont été formalisées dans des "design patterns", sortes de modes d'emploi générique pour gérer dans son code des situations typiques.

Non pas d'ailleurs que ces design patterns soient apparus si récemment, mais c'est leur application au développement web, et PHP notamment, qui a été tardive. Pour l'anecdote, le design pattern "MVC" (Model-View-Controller, qui permet de séparer efficacement logique métier et présentation) date des années 70, mais semble n'avoir été découvert que vers 2004/2005 par les développeurs web.

Car en effet, un design pattern ne comporte pas de code : seulement du texte, présentant une solution générique, applicable à une problématique classique. Charge aux développeurs ensuite de l'implémenter au sein de leurs projets.

Le mix des deux : les frameworks

Le recours aux design patterns est devenu de plus en plus courant. Ce qui a impliqué la production d'un code assez important lors des implémentations les plus rigoureuses, à commencer par celle de MVC. Puisque les design patterns règlent des problèmes génériques, leurs implémentations ont également été génériquées.

Les ensembles constitués de ces implémentations de design patterns accompagnées d'une couche ORM ont constitués les premiers frameworks.

Et alors, que choisir ?

Framework ou ORM ? ORM ou JRLR* ? Comme vous vous en doutez, il n'y a pas de réponse universelle à ces questions. Encore que pour la deuxième, entre le recours à un ORM ou l'écriture "from scratch" de l'accès aux données, il me semble raisonnable de dire que la seconde solution ne l'est pas, raisonnable !

Pour ce qui concerne le choix d'un framework ou non, il faut prendre divers facteurs en considération :

  • La couverture fonctionnelle : l'intérêt premier de recourir à un framework est de bénéficier de ses composants pour éviter l'écriture de code inutile, et ainsi gagner du temps, beaucoup de temps (si l'on tient compte en plus du développement des tests etc.). Pour que l'intérêt d'adopter un framework soit attesté, il faut en premier lieu que sa couverture fonctionnelle soit supérieure ou égale aux spécifications du projet.
    • celle-ci est-elle suffisamment large pour englober l'ensemble des besoins inhérents à votre projet ?
  • La souplesse : si certaines fonctionnalités font défaut au framework, il sera nécessaire de les implémenter. Ceci ne doit pas être intrusif, c'est-à-dire que le code du framework lui-même doit rester inchangé, pour pouvoir profiter de ses mises-à-jour ultérieures.
    • Le framework offre-t-il la possibilité d'étendre ou de compléter ses composants ?
    • Si oui, cette possibilité permet-elle de garantir l'intégrité des sources d'origine du framework ?
  • Les compétences existantes : l'équipe doit posséder une maitrise suffisante du framework et être capable de l'utiliser de manière fluide (i.e. sans passer une heure et demie dans la doc 4 fois par jour pour pouvoir avancer à sa guise) pour réellement bénéficier de son emploi.
    • L'équipe dispose-t-elle de ses compétences ?
    • Ai-je le temps et/ou le budget pour la faire monter en compétence ?
    • L'investissement est-il à la hauteur de mon projet ?
  • Les contraintes de performances : un framework, c'est bien. Il peut faire gagner énormément de temps au développement. En retour, il en fera assurément perdre à l'exécution. Mathématiquement, plus on automatise de traitements, plus ils seront lents. Dans certains cas extrêmes, on peut d'ailleurs signaler que même un ORM peut s'avérer trop couteux en performances.
    • Puis-je m'offrir les quelques centaines de millisecondes de surcharge par page que m'imposera un framework ?
Bien sûr, cette liste n'est pas exhaustive, mais une fois que l'on a répondu à ces questions, on peut déjà se rendre compte, dans les grandes lignes, de la pertinence ou non de l'adoption d'un framework pour un projet donné.

* JRLR = Je Réinvente La Roue :)

Conclusion

La conclusion de tout ceci est simple : les frameworks modernes, orientés objet, représentent une avancée considérable pour PHP. Pour autant, les adopter de manière systématique, quels que soient les projets à porter, ne me semble pas être une bonne idée.

Les ORM ne sont pas morts, et peuvent rendre de grands services, tout particulièrement lorsque la machinerie déployée par un framework est sans rapport ni par la taille ni par les fonctionnalités avec un projet donné.

Une solution intéressante pour conserver une certaine uniformité des pratiques pourrait être de recourir à un framework dont la couche ORM peut être utilisée de manière autonome, ou encore d'implémenter un ORM donné dans un framework sous forme de plugin.

samedi 27 septembre 2008

Logiciels Libres : 25 ans déjà, 25 seulement !

Le 27 Septembre 1983, Richard Stallman envoyait un message sur différents newsgroups du réseau du MIT, dans lequel il décrivait et expliquait le concept de logiciel libre, tel qu'il souhaitait l'appliquer à l'implémentation d'un nouveau système Unix.

L'enthousiasme déclenché par ce projet a rapidement dépassé tout ce que Stallman avait pu imaginer. L'objectif initial, de créer un système d'exploitation libre, s'est élargi de façon exponentielle au fur et à mesure que de nouveaux contributeurs ont adhéré à la philosophie exposée par Stallman dans ce message, plus tard repris et complété pour devenir le "GNU Manifesto", et ayant conduit à la création de la Free Software Foundation.

Paradoxalement, le projet GNU n'a encore pas atteint son objectif, et ce malgré l'engouement qu'il a suscité tant auprès des développeurs que des utilisateurs : il aura fallu l'apparition de Linux pour apporter au système libre de GNU le noyau qui lui faisait, et lui fait encore défaut. En contre-partie, l'association GNU+Linux a donné naissance à un véritable système d'epxloitation, parfaitement utilisable au quotidien, qui a encore décuplé la communauté d'utilisateurs, et ce faisant le nombre de projets libres apparus depuis.

La diversité de ces projets, ainsi que l'extension du concept au-delà des seuls logiciels (documentations, créations artistiques...) a également étendu la sphère d'influence du concept porté par la FSF. Dans les faits, le logiciel libre a impacté notre société, dans son acception la plus modeste qualifiant la "vie quotidienne", finalement bien plus qu'il n'a déstabilisé la seule économie du logiciel.

Ne prenons qu'un seul exemple : Internet ! Le logiciel Apache, qui à lui seul permet de faire fonctionner autour de 70% des serveurs web du monde, est un logiciel libre. Mieux, c'est à cette qualité de logiciel libre qu'il doit d'avoir été retenu, avec le protocole HTTP dont il est la première implémentation, comme standard du réseau mondial ouvert succésseur d'Arpanet... La gratuité du logiciel, et du système qui le fait fonctionner, ainsi que l'accès aux sources pour l'adapter aux besoins nouveaux émergeant au fil de la création de nouveaux sites, a permis la mise en place de la fameuse "toile", coeur du réseau. Sont ensuite apparus les différents langages libres, tels Perl, Python, PHP, Ruby... qui pour les même raisons qu'Apache, ont permis une métamorphose du web, depuis les sites statiques des débuts jusqu'au web 2.0 et aux réseaux sociaux qui s'y rattachent aujourd'hui.

Sans la liberté d'accéder à ces logiciels et de modifier leurs sources pour assurer leur évolution accélérée (sans autre contrainte que la seule volonté de satisfaire les besoins des utilisateurs), je ne serais sans doute pas en train de rédiger ce message sur ce blog, car son concept même n'existerait probablement pas. Ceci n'étant qu'un seul exemple des nouveaux moyens de communication dont le logiciel libre a seul pu engendrer l'apparition, modifiant profondément la notion même de diffusion de l'information.

25 années se sont donc écoulées depuis l'annonce de la naissance du projet GNU. 25 ans déjà... qui aurait pu prédire, en 1983, que le concept extravagant porté par Richard Stallman allait rencontrer une telle adhésion, et impacter à ce point la société de l'information. Mais 25 ans seulement, au regard du travail prodigieux fourni par tous les contributeurs de ce projet insensé.

En conclusion, bon anniversaire GNU, et longue vie !

Voir l'annonce initiale sur le site officiel GNU