Christophe Le Bot

  • Navigation rapide
Pratique de la conception numérique

Derniers commentaires

  • Une excellente thèse sur Simile Exhibit
    • Olivier Rossel | Bonjour. Malgre les annees, avez vous toujours en memoire vos usages d’Exhibit? Je serais ravi d’en discuter avec vous. Cordialement, Olivier Rossel.
  • Utiliser le planificateur de tâches OVH (crontab) avec PHP
    • Max | Bonjour, comme faire pour appeler une version de PHP qui n’est plus proposée par défaut dans le manager ? J’essaie de lancer un cron avec php 5.3 mais le log affiche No such file...
    • Christophe | @absolument Merci pour ces précisions. Je n’ai pas mis en place de tâches cron récemment, mais j’ai reçu quelques notifications étranges d’OVH il y a quelques...
  • Récupérer le dernier auto-incrément MySQL avec PHP
    • Thy | Sujet toujours *très* utile en 2015 ! Je réponds à Serge tsimba qui récupère un « Resource id ». (Et à tous ceux qui ont le même souci mais qui ne le disent pas) :)...
  • Régler l’heure de serveurs virtuels sous Debian
    • Ares_XL | Il semble que sur Débian la commande « tzconfig &ra quo; soit dépréciée et remplacée par : « dpkg-reconfigure tzdata » elle donne accès à une...
 

Magentips, mon nouveau blog Magento

Magentips

Il y a deux ans, quand j’ai commencé à mettre le nez dans Magento, il n’y avait rien ou quasiment rien sur le web pour traiter le sujet. Alors j’ai toujours eu l’idée d’un blog pour centraliser l’information pratique au quotidien. Mais comme souvent, les autres priorités ont gelé cette initiative assez rapidement…

Depuis, il s’est passé beaucoup de choses autour de Magento. De nombreux sites dédiés ont fleuri et m’ont fait douter de l’intérêt de créer un YABAM (Yet another blog about Magento). Alors tout cela est resté dans un carton, à moitié achevé, pendant une dizaine de mois.

Et pourtant, voilà Magentips ! Comme quoi tout arrive. Je doute de ma disponibilité pour en faire le YABAM le plus riche de la planète, mais je souhaitais partager mes expériences Magento en dehors des sentiers battus et des premières évidences. La page A propos détaille cela.

Je vois donc cette initiative personnelle comme un complément à des outils existants. Certains partages de contenu se feront donc naturellement vers des sites de référence comme le blog français officiel Magento, Fragento et Wikigento. Comme dirait Philippe Humeau (Wikigento), « on peut œuvrer ensemble dans le même sens, sans perdre son indépendance et sa liberté de ton ».

Bienvenue sur Magentips !

Vous pouvez aussi retrouver Magentips sur Twitter.

Magento sur le Journal du Net

Le JDN|Développeurs publie une très bonne présentation de Magento. Un tour d’horizon plutôt flatteur, mais très réaliste.

Il faut dire que son auteur, Fabrice Beck, commence à bien maîtriser la bête puisqu’il est aussi l’auteur de deux jolis modules Magento pour Fia-Net : FIA-NET Core et FIA-NET ReceiveAndPay.

Du bon usage des exceptions

Si nous intégrons tous la gestion des exceptions dans notre code source (enfin, je l’espère…), en faisons-nous vraiment bon usage ? Entre les « maniaco-dépressifs » qui en mettent partout et les « bricolo-codeurs » qui savent à peine les mettre en place, il y a un compromis… qui n’est pas toujours évident à trouver.

Erreur, dysfonctionnement et exception

Par définition, une exception n’est levée qu’en cas d’état exceptionnel de l’application. Le tout est d’arriver à définir l’état d’exception. Est-ce un dysfonctionnement applicatif grave (connexion à une base de données qui tombe, fichier applicatif introuvable, allocation mémoire excessive, objet corrompu) ? Est-ce un fonctionnement normal mais exceptionnel (erreur d’authentification utilisateur, données entrantes non conformes) ? Est-ce une situation fréquente mais ne répondant pas au scénario optimal d’utilisation (mauvaise utilisation de l’application, erreurs de saisie d’un utilisateur) ?

Après avoir vu tous les cas sur le terrain, mais aussi dans des documents de référence, j’avoue ne plus savoir où placer le curseur…

Réserver l’exception aux dysfonctionnements

Pour ma part, je préfère garder l’exception pour les situations les plus rares et les plus graves, ce que je définis comme des situations exceptionnelles. Elles sont généralement dues à des dysfonctionnements de l’application, c’est-à-dire des états qui n’ont pas été prévus dans les séquences d’utilisation.

Sur ce principe, une erreur de saisie d’un utilisateur ne devrait jamais déclencher une exception lorsque sa valeur est contrôlée par l’application. Si j’entre une adresse e-mail invalide dans un formulaire, l’application traitera l’événement comme une erreur utilisateur et non comme un dysfonctionnement interne. Elle retournera le formulaire avec un joli message d’erreur… qui n’a rien d’exceptionnel puisque ce traitement fait partie du fonctionnement normal de l’application (mais pas de sa séquence nominal !). Même si cela semble évident (pour moi, du moins…), l’utilisation des exceptions pour ces cas est loin d’être anecdotique.

Bien sûr, si après validation de l’adresse e-mail l’application ne peut pas traiter normalement le formulaire, l’utilisation des exceptions permettra de trouver l’origine du dysfonctionnement, sans mettre les données dans un état inconsistant.

Trouver le bon équilibre

Dans le cas d’applications complexes où la modularité de code est de rigueur (genre « full MVC avec intégration de tous les designs patterns du GoF » !), savoir instancier puis récupérer une exception au meilleur endroit (ou moment pour les aficionados de la programmation événementiel) est déjà moins évident. Quels rôles jouent les différents niveaux de la partie M (modèle) ? Comment réagit la partie C (contrôleur) ? Comment gérer efficacement l’imbrication des exceptions (du noyau à l’interface en passant par les couches métiers) sans perturber la compréhension du problème par l’utilisateur ? Bien sûr, chaque cas est particulier, mais j’avoue que je souhaiterais bien discuter du sujet, autour de vos expériences.

Je vous passe la main !

Bug Labs crée les « user generated devices »

BUG 2
BUG de Bugs Labs.

Après l’ère du contenu généré par l’utilisateur (user generated content) et alors que nous commençons tout juste à avoir les outils pour créer facilement nos applications (user generated applications), Bug Labs commercialise des briques matérielles bien réelles pour créer ses propres appareils électroniques. Les user generated devices sont nés.

La gamme BUG se compose de BUGbase, la brique de base sur laquelle viennent se greffer les BUGmodules, tels qu’un capteur GPS, une caméra vidéo, un écran tactile, un capteur de mouvement, des touches, etc.

BUGbase
La BUGbase…
BUGmodules
… et ses BUGmodules.

Même si Lego le fait depuis longtemps, n’allez pas croire que BUG est un simple jouet ! Vous avez un potentiel créatif sans limite, servi par une excellente utilisation de la programmation orientée objet, l’objet ayant dans ce cas une réalité matérielle peu fréquente. Pour développer les fonctions de son appareil, le « créateur-concepteur-utilisateur » dispose d’un environnement de développement (BUG SDK, fonctionnant sous Eclipse) qui repose sur des technologies éprouvées (Java + framework OSGi).

BUG SDK
Le BUG SDK en action.

C’est donc tout naturellement que Bug Labs vient de remporter un CES award 2008.

PHP4, PHP5, PHP6 : la saison des grandes migrations

Logo PHP

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

PHP4 en fin de course

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

Migrer de PHP4 à PHP5

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

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

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

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

Préparer l’arrivée de PHP6

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

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

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

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

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

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

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

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

Une opportunité pour les entreprises… et leurs prestataires

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

Y a-t-il des spécialistes d’Exhibit dans la salle ?

Logo Simile

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

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

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

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

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

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

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

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

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

Zend Framework dans les starting-blocks

Logo Zend Framework

Le Zend Framework passe en RC1 (release candidate 1). C’est donc la dernière étape avant sa sortie officielle prévue cet été (peut-être fin juin, disent certains).

Son arrivée dans l’arène bien encombrée des frameworks PHP a déclenché des débats passionnés, avec des clans résolument contre (« ce n’est pas un framework ! ») et des clans qui ne jurent que par lui (« il est soutenu par Zend et IBM autour du langage le plus populaire du web ! »). Je ne parle même pas des allergiques au PHP qui trouvent stupide de construire un framework autour d’un langage aussi immature…

Bref, chacun se fera son avis. Pour ma part, je trouve le projet très pertinent.

C’est vrai que Zend Framework n’est pas aussi complet que Symfony (un très beau projet, je vous conseille de l’étudier !). On peut effectivement le voir comme une bibliothèque d’objets respectant les principes classiques de l’architecture MVC (Modèle Vue Contrôleur). Dans ce cas, je pourrais aussi bien dire que prototype n’est pas un framework Javascript mais une collection de classes. C’est étrange, mais personne n’y songe…

On peut aussi se demander pourquoi ce framework n’est pas intégré directement dans PHP, suivi d’un bon ménage pour éliminer une myriade de fonctions inutiles. En cela, PHP est plus proche de Perl (36 façons de faire une chose) que de Python (1 seule façon de faire un chose). Mais il est difficile de mettre une croix sur ce qui a fait le succès de PHP : sa facilité de prise en main et son approche procédurale. PHP atteindra difficilement la beauté théorique d’une usine à gaz Java ou l’efficacité pragmatique d’un projet Ruby, mais il est partout.

Donc, considérons que le Zend Framework est un framework PHP léger. Quels sont ses avantages ? Pour moi, ils dépassent clairement le cadre purement technique, ce qui en fait déjà une solution incontournable :

  • Il a été créé à l’initiative de Zend, the PHP company (comme elle le dit si bien), pour des applications professionnelles lourdes.
  • Il est soutenu par des acteurs puissants (IBM en tête) qui garantissent sa pérennité.
  • Il utilise le langage le plus répandu sur les serveurs web.
  • Il repose sur les avancées majeures en programmation objet de la version 5 de PHP (il était temps…).
  • Il fonctionne par simple inclusion, donc sur toutes les offres d’hébergement existantes (serveurs mutualisés, notamment).
  • Il donne enfin un cadre de travail aux développeurs PHP (réputés comme les cancres de la programmation).
  • Comme tout framework, il réduit le temps de développement par la mise en facteur des bonnes pratiques et une meilleure définition de l’architecture.
  • Il offre une documentation complète, à jour et claire, un atout essentiel pour son adoption en entreprise.
  • Il bénéficie de l’élan autour d’Eclipse, grâce au développement parallèle de PDT (PHP Development Tools).

Cette orientation très professionnelle, tout en gardant la simplicité de PHP grâce à un framework léger, devrait décider un bon nombre de développeurs et d’architectes à considérer ce choix.

L’avenir me dira si j’ai vu juste…

Soirée spéciale “PHP pour l’entreprise” le 14 mai 2007 à Paris

L’Association française des utilisateurs de PHP (AFUP) organise le 14 mai 2007 une soirée spéciale PHP pour l’entreprise. Andi Gutmans (co-architecte de PHP et co-fondateur de Zend) sera présent pour faire le point sur les évolutions d’un des langages les plus utilisés dans les applications web. Ce sera surtout l’occasion de montrer les atouts du Zend Framework dont la version 1.0 est attendue en septembre 2007.

La soirée est gratuite, mais l’inscription obligatoire.

» Voir le communiqué de presse