dimanche 20 décembre 2009

MacOSX et PHP, la révélation !

Alors que ça fait pourtant plusieurs années maintenant que je vois de plus en plus de développeurs passer sur Mac, pendant que dans le même temps les PC m'exaspéraient eux aussi de plus en plus, et pourtant je n'avais pas encore établi le lien de causalité entre les deux phénomènes.

Ce paradoxe m'est apparu clairement il y a quelques mois maintenant. Je n'ai pourtant succombé que la semaine passée. En effet, j'ai longtemps refréné mes envies d'achat car je craignais franchement de regretter mon achat une fois l'effet "wahouh" dissipé, me disant que finalement, tout ça, ça restait de l'informatique d'ordinateur.

Et bien non, trois fois non. Les machines d'Apple sont tout simplement incomparables aux PC. Et je tiens à préciser PC, et non Windows. Certes je n'ai jamais eu de plaisir particulier à utiliser le système de Microsoft, sans pour autant tomber dans l'anti-windows bête et méchant. Le problème d'ailleurs, c'est que les systèmes GNU/Linux commençaient aussi (depuis un moment) à me causer la même frustration que les différents Windows : c'est souvent joli, plein de bonnes idées, mais ça ne marche pas très bien, et surtout pas très longtemps. Sans compter que même quand ça marche, il est préférable de ne garder qu'un minimum d'applications simultanément, faute de quoi on s'expose à la sanction suprême : le recours au swap, et là, c'est le drame.

A ces différents facteurs s'en sont ajoutés deux autres pour m'amener à choisir Mac : un support brillant de la virtualisation et bien sûr la disponibilité native de très nombreux outils de développement, à commencer par ceux que j'utilise le plus : la suite Zend (Studio + Server particulièrement).

Bref, me voilà donc l'heureux possesseur d'un iMac. Une petite bête ; la plus petite de la gamme en fait, à ceci près que j'ai doublé sa mémoire dès l'achat (pour passer de 4 à 8 Go). Et depuis, c'est le bonheur :)

C'est bien simple, je n'ai jamais vu de machine aussi réactive. Même avec quatre machines virtuelles en cours d'exécution (deux Ubuntu Server avec 512 Mo de RAM, une autre Desktop avec 2 Go et un Windows Vista lui aussi doté de 2 Go), je ne constate aucun ralentissement notable des applications natives de Mac OS !

Par comparaison, j'utilise régulièrement une seule de ces quatre VM sur mon laptop Dell (Centrino Duo, 2 Go de RAM) habituellement, et elle est infiniment plus lente :(

Le propos, vous l'aurez compris, est très clair : si vous n'êtes ni un inconditionnel de Microsoft ni un intransigeant du logiciel libre, et qu'accessoirement, vous souhaitez travailler sur une machine qui tourne bien, qui est plutôt esthétique et très ergonomique (je ne vous ai même pas parlé de la nouvelle Magic Mouse !), aucune hésitation, achetez un Mac !

Un dernier mot pour ceux qui pensent que c'est cher, je dirai... oui et non. Les iMac c'est franchement peu cher même comparé à PC, ça tient la route. Quand aux portables, certes ils sont plus chers, mais comment dire... bref, le prix ne doit pas être le seul critère de choix, sinon c'est le mauvais achat assuré. Je précise cependant que même le entrées de gamme Mac sont très nettement au-dessus du niveau moyen des PC. A bon entendeur... :)

dimanche 22 novembre 2009

Debrief Forum PHP 2009 - de l'avenir de PHP...

Je n'ai guère trouvé le temps de publier quoi que ce soit depuis un moment, pas même sur l'édition 2009 du Forum PHP de l'AFUP. Pas question cependant de faire moi-même le réumé de ce qui s'est dit et passé, puisque vous trouverez de nombreuses ressources sur le sujet, notamment les slides des diverses conférences,  sur le site de l'AFUP.

Je souhaitais en revanche publier une réflexion sur la perception de PHP en entreprise qu'en ont les gens qui sont au coeur de PHP en France (et en Belgique pour certains, ne les oublions pas, nos voisins d'Outre-Quiévrain ayant été nombreux cette année encore à faire le déplacement).

Deux éléments ressortent particulièrement à mes yeux : d'une part la réelle prise de conscience de la majorité des acteurs quant à l'importance du respect des bonnes pratiques et autres méthodologies éprouvées dans le développement d'applications, comme de sites, en PHP, et d'autre part le sentiment que PHP en entreprise, c'est désormais non seulement crédible, mais également une réalité. La deuxième observation découlant sans aucun doute de la première.

Naturellement, on ne peut que se réjouir de cette évolution de l'écosystème PHP professionnel, qui se démarque enfin de l'image d'amateurisme, voire de "bidouille" dont a été longtemps entaché la réputation de PHP aux yeux des entreprises, notamment des plus importantes. La qualité des présentations, l'approche des professionnels rencontrés sur place, ainsi que l'omniprésence des termes "industrialisation" et "bonnes pratiques" m'en ont covaincu.

Je suis donc globalement en accord avec ce constat, mais j'y apporterais un bémol. D'abord parce que cette évolution ne concerne malheureusement pas la totalité de la profession, et ensuite parce qu'il reste de grosses lacunes dans les outils logiciels impliqués par une telle industrialisation du développement en PHP ; je pense tout particulièrement aux solutions de déploiement qui sont encore, n'ayons pas peur des mots, indigentes. En effet, cette problématique absolument critique est aujourd'hui encore très majoritairement adressée par des scripts dans le meilleur des cas, totalement manuellement dans la plupart des situations...

Cette faiblesse handicape également l'émergence de solutions d'intégration continue, qui sont elles aussi essentielles à la mise en place de nouvelles pratiques plus fiables et efficaces de manière industrielles. Malgré certaines initiatives intéressantes en matière d'intégration continue (comme sismo de Sensio Labs, qui n'est pas encore - à ma connaissance _ disponible publiquement), cette catégorie d'outils n'est pas encore suffisamment pourvue pour PHP.

Aussi dirais-je en conclusion que s'il est juste de dire que PHP en entreprise est prêt, il faut se rendre compte que nous ne sommes qu'au bas de la pente... il reste du travail, et il faudrait prendre garde à ce que de gros projets ne soient confiés à PHP sans que ne soient appliquées ces pratiques et méthodologies relatives à l'industrialisation qui sont indispensables à leur réussite. Faute de quoi... je crains que des échecs trop retentissant ne ternissent (définitivement ?) la crédibilité de PHP comme plateforme majeure de l'industrie logicielle en entreprise.

Mais nous n'en sommes pas là, bien au contraire ! Alors le rendez-vous en 2010 pour démontrer que mes craintes étaient infondées, à l'occasion des dix ans de l'AFUP et des 15 ans de PHP - quels meilleurs symboles pour mettre en avant la pérennité de la technologie comme celle de sa communauté ?

dimanche 11 octobre 2009

Rappels sur la normalisation

Qu'est-ce que la normalisation ?

Ce que l'on appelle normalisation (ou "formes normales") en matière de bases de données relationnelles est un ensemble de règles à respecter pour préserver l'intégrité des données (c'est-à-dire la cohérence des relations) tout en limitant les redondances (stockage répété de valeurs identiques).

On pourrait faire le parallèle entre les formes normales et les design patterns : dans un cas comme dans l'autre, il s'agit de décrire une solution éprouvée à un problème courant. Tous deux permettent de guider la conception (soit de la base, soit d'un programme ou d'une partie d'un programme), laissant au développeur le soin de l'implémentation.

Outre les deux objectifs principaux cités plus haut (préservation de l'intégrité des données et prévention de la redondance), les formes normales offrent aussi pour avantage, lorsqu'elles sont respectées avec scrupule (mais discernement, nous en reparlerons plus tard) de faciliter la maintenance et la collaboration. En effet, en normalisant ses bases de données, on s'assure que quiconque connaissant les formes normalisées saura les reconnaitre, et comprendre d'autant plus aisément l'organisation des données.

Les principales formes normales

Une fois n'est pas coutume, ceux qui ne connaissent pas la normalisation vont s'apercevoir que dans les faits, ils la pratiquent déjà, comme la prose de M. Jourdain (on ne se lasse pas de cette référence !). Ceci pour une simple raison : comme beaucoup de bonnes pratiques, la normalisation a été tout d'abord édictée par le bon sens.

Voici une brève présentation des 3 premières formes normales :
  • 1FN (1ère forme normale)
    • La plus élémentaire de toutes, la première forme normale impose que toute donnée soit indivisible (atomique), que la table dispose d'une clé primaire, composée d'une ou plusieurs colonne, et que les données redondantes soient extraites dans leur propre table, disposant d'une clé primaire elle-aussi.
      • Exemple
        • employes(secu, date_embauche, nom, prenom)
      • Contre-exemple
        • employes(secu, ancienneté, nom), où nom servirait à stocker à la fois le nom et le prénom, et poste la définition du poste de l'employé.
    • Concrètement, le respect de la première forme normale garantit la possibilité de filtrer, trier et/ou lier une table sur n'importe laquelle de ses colonnes. Dans le contre-exemple, il serait impossible de sélectionner toues les employés portant le même nom sans recourir à un traitement sur la colonne (ex. nom LIKE 'nom_de_famille%'), ce qui n'est ni des plus performants, ni des plus pertinents (imaginez avoir un employé nommé 'Martin' et un autre nommé 'Martinot'...). 
    • Remarquez également que l'on aura préféré stocker la date d'entrée de l'employé dans l'entreprise plutôt que son ancienneté exprimée en durée, tout simplement parce que dans ce dernier cas, une mise-à-jour régulière de l'enregistrement est nécessaire pour  maintenir l'exactitude de cette donnée. Ceci constitue une autre règle essentielle de normalisation.

  • 2FN (2ème forme normale)
    • La respect de la deuxième forme normale implique tout d'abord le respect de la 1ère. Cette règle est valable pour chaque règle ultérieure. La 2FN s'applique aux tables employant des clés composites. Elle prescrit que toutes les données ne faisant pas partie de la clé doivent en dépendre directement (mais pas d'une partie seulement de la clé).
      • Exemple : 
        • fonctions(departement, poste)
        • emplacement(departement, batiment)
      • Contre-exemple :
        • fonctions(departement, poste, batiment)
    • En admettant que dans cette société, chaque département se voit attribuer un et un seul bâtiment, respecter la 2NF a entraîné la scission de la table en deux, car l'attribut batiment ne dépendait que d'une partie de la clé (departement) et non pas de la totalité.

  • 3FN (3ème forme normale)
    • La troisième forme normalisée impose que chaque attribut qui n'est pas une clé dépende de la  clé primaire.
      • Exemple : 
        • employes(secu, nom, date_embauche, prenom, poste)
        • salaires(poste, ancienneté, salaire)
      • Contre-exemple :
        • employes(secu, nom, date_embauche, prenom, poste, salaire)
    • Ici, on considère que le salaire dépend de l'ancienneté (déduite de la date d'embauche) et du psote occupé. Dans ce cas, pour respecter la 3NF, il nous faut séparer l'information salaire de la table employes car cette information ne dépend pas de la clé (secu) mais d'autres attributs  (date_embauche et poste) qui ne font pas partie de la clé primaire.

Appliquer ces règles de conception à toutes ses tables est le plus souvent une bonne idée. S'il existe d'autres formes normalisées un peu plus complexes, le respect de ses trois là permet déjà de s'assurer d'un maximum de cohérence pour un minimum de redondance, le tout selon une façon standardisée de faire qui devrait grandement faciliter la compréhension de tous les intervenants.

Bien sûr, on peut redouter que le fait de multiplier le nombre de tables peut avoir un impact négatif sur les performances globales de l'application, et complexifier légèrement l'écriture des requêtes. Si cette observation n'est pas sans fondement, on s'aperçoit souvent à l'usage que des tables designées de façon anarchiques ne sont guère plus performantes, et que les requêtes à écrire pour les interroger sont d'autant plus complexes qu'elles ne répondent pas à des schémas standards. Autrement dit, quelle que soit la façon d'aborder le problème, la conception de bases de données reste un exercice délicat, et dans la plupart des cas, même si l'on est pas convaincu d'emblée, il est préférable de s'en remettre aux règles de normalisation pour éviter de commettre des erreurs dont les conséquences peuvent s'avérer colossales selon l'ampleur des projets !

    lundi 13 juillet 2009

    Drupal or not Drupal

    Comme tout blogueur amateur qui se respecte, je m'efforce à laisser plusieurs mois entre chaque post... j'ai failli atteindre 6, ce qui aurait été un record, mais je craque ;)

    Plaisanterie à part, j'ai été fort occupé ces derniers temps par de multiples changements tant personnels que professionnels. Et ce sont précisément ces derniers qui m'amènent à rompre le silence...

    PHP est la plateforme de prédilection pour coder des CMS depuis longtemps. C'est même probablement sa virtuosité en la matière qui est à l'origine de son succès. En n'oubliant pas naturellement sa légendaire permissivité, à la fois la cause et la solution de tous nos problèmes de développement avec ce langage.

    Donc les CMS, systèmes de gestion de contenu, sont la spécialité de PHP (dans le contexte de sites internet j'entends). Une rapide recherche auprès de notre ami Google nous apprends qu'il en existe plusieurs centaines, plus ou moins aboutis, mais ayant tous en commun de se présenter comme le meilleur CMS Open Source/du marché, ça dépend des chapelles.

    Je n'ai à titre personnel que peu utilisé ce genre d'outils, car d'une part j'ai beaucoup plus travaillé sur des applications que sur des sites webs, et que d'autre part, à l'époque où j'avais cette problématique, aucun ne m'avait satisfait.

    Pour diverses raisons, je me suis récemment intéressé de nouveau à la question. Et là, stupéfaction : les mêmes noms reviennent encore et encore ! Les stars du domaines n'ont guère changé depuis plusieurs années. Et parmi ces stars... Drupal.

    Alors certes, je pourrais me répendre en calomnies plus ou moins fondées sur les absurdités rencontrées dans les sources de ce CMS, dont je précise que j'utilise une version 5, histoire de couper court aux trolls sur Drupal c'est bien/Drupal c'est pas bien. Mais ce débat ne m'intéresse pas.

    Déjà parce que la question est tranchée : du point de vue de la conception, Drupal, c'est mal. Encore une fois, je parle de la version 5, qui ne comprend pas le moindre objet, qui use et abuse des variables globales, qui prend un plaisir pervers à surcharger la base de données pour un oui pour un non, etc. Petite précision, un rapide coup d'oeil aux sources de la dernière version, 7.x, me laisse à penser qu'il n'y a toujours pas eu de refactorisation orientée objet d'opérée sur le projet.

    Bref, poursuivons : la vraie question, à mon sens, n'est pas là, mais est : pourquoi n'y a-t-il pas de relève digne de ce nom ? Une partie de la réponse va me permettre d'édulcorer un peu mes propos. Drupal (comme beaucoup d'autres CMS de la même eau par ailleurs) a atteint une richesse fonctionnelle, il est vrai, remarquable. Mais ça ne fait pas tout.

    De nouvelles problématiques apparaissent sans cesse, et les CMS réputés stables aujourd'hui ne proposent soit pas de solution, soit des rustines sur d'autres rustines déjà accumulées...

    Si j'avais le temps de rédiger plus d'un message tous les six mois, je crois que je me mettrais immédiatement au travail pour plancher sur une alternative qui répondrait aux besoins simples qui sont les suivants : évolutivité (conception full objet), réponse à la charge, considération concernant le déploiement, la sauvegarde (découplage structure/contenus propres), et la synchronisation d'environnements multiples (dev, test, prod...).

    A moins que, et c'est un peu ce que j'espère en écrivant ceci, je ne me trompe lourdement et que cette alternative existe déjà, auquel cas je compte sur vous pour m'en informer en commentaire :)

    samedi 28 février 2009

    Certification Zend Framework

    Malgré la pression et les problèmes techniques, j'ai obtenu hier la certification Zend Framework :)


    La pression... forcément, en tant que formateur sur ZF, échouer à ce test ne m'était pas permis ! Pourtant, ce n'était pas du domaine de l'impossible, car le test n'est pas des plus faciles, sans compter que comme toujours certaines des questions sont d'une pertinence discutable. Bref, ce fut un mauvais moment à passer, mais récompensé par le soulagement d'avoir réussi cette épreuve :)

    Malgré les reproches que l'on peut faire à ce type de certifications (sous forme de QCM), s'y préparer présente un intérêt majeur : se forcer à découvrir parfois des pans entiers du framework que l'on ne connaissait pas parce que l'on a jamais eu l'occasion, le courage même de s'en servir.

    En résumé, ce ne sont pas les réponses aux questions posées lors de l'examen qui témoignent de ses connaissances, mais la somme de connaissances qu'il aura fallut engranger pour être capable de répondre.

    Dernier point, éviter de passer de trop nombreuses certifications, parce que sinon il vous faudra des feuilles A4 pour imprimer vos cartes de visites, qui en outre ressembleront au catalogue Pearson Vue ;)

    mardi 13 janvier 2009

    Une barre de débuggage pour Zend Framework

    Petite news pour parler d'un petit utilitaire très pratique pour débugger, et partiellement profiler (de façon sommaire), les applications ZF.

    Il s'agit de Scienta ZF Debug Bar. Alors autant être clair, ce projet n'est révolutionnaire ni dans son concept (très largement inspiré d'outils similaires pour Ruby On Rails et symfony notamment), ni dans sa conception (elle aussi très inspirée des projets cités précédemment).

    Pour résumer, l'outil se présente sous la forme d'un unique fichier PHP, contenant une unique classe héritant de Zend_Controller_Plugin_Abstract. Son utilisation est fort simple : après avoir extrait l'archive à la racine du projet ZF, il suffit d'inclure le fichier dans le bootstrap, de créer une instance du plugin que l'on configure à l'aide d'un simple tableau de paramètre fourni au constructeur, et enfin d'enregistrer cette instance dans le contrôleur frontal de l'application avec sa méthode registerPlugin().

    Cela suffit en effet à générer sur chaque page de l'application une petite barre d'outils en Javascript, utilisant jQuery, qui pourra afficher différents types d'informations sur la requête, comme son temps d'exécution, les différentes requêtes SQL et leur durée, la mémoire consommée, les fichiers inclus, et enfin les différentes variables. Mais le mieux consiste à consulter le site officiel pour se rendre compte de ce que propose l'outil, puis surtout de l'utiliser :)

    Une petite note au sujet du choix de jQuery. Je ne débatterai pas de la qualité de la librairie, de la pertinence de son utilisation etc., mais je rappellerai simplement que cela vous posera des problèmes si 1) vous utilisez déjà jQuery ans votre application 2) vous utilisez Prototype (qui est incompatible) 3) sans doute d'autres librairies similaires vous poseront le même problème. Enfin, si la qualité globale du code est discutable, il a le mérite d'être fonctionnel, et je souligne également les deux astuces qui consistent pour la première à utiliser une distribution en ligne de jQuery et la seconde à avoir embarqué le binaire des icones directement dans le source, permettant ainsi la distribution de ce fichier sous la forme d'un unique fichier comme signalé plus haut.

    Si l'on peut espérer que l'outil s'étoffe (j'imagine que toute contribution sera par ailleurs bienvenue), il est incontestable que tout développeur ZF peut d'ores et déjà considérer l'utiliser au quotidien. Ce qui lui permettra, entre autre, de ne plus se faire railler par ses collègues utilisant symfony et qui en dispose donc déjà depuis un bon moment ;)

    Mini-tuto et téléchargement