Numabilis - Maîtrise d'œuvre

Critères de choix d'un framework PHP

Wed, 30 May 2007 19:27:58 +0200

En tant que chef de projet dans une grosse structure, justifiant son poste par sa capacité à résoudre les problèmes qu'il a lui-même créés, vous êtes décidé à bâtir la prochaine application corporate sur un framework PHP. En plus des critères de choix déjà évoqués, vous veillerez à la présence de fonctionnalités qui permettent aux développeurs de se concentrer sur les particularités de l'application, en les libérant de l'écriture des briques de base :

Implémentation du design pattern MVC
Présence d'un module de logging
Contrôle total sur les URLs
Validation des formulaires
Gestion des accès aux bases de données
Implémentation de l'inversion de contrôle (IoC)
Gestion de l'internationalisation
Système de caching
Authentification et gestion des profils utilisateurs
Gestion de la montée en charge
Prise en compte de la sécurité (cross scripting, code injection, sql injection, vols de session, etc)
Système de communication entre les modules
Module Ajax

L'examen d'un certain nombre de framework (Zend Framework, CakePHP, Symfony Project, Seagull Framework, WACT, PHP on TRAX, ZooP Framework, Navigator, CodeIgniter) montre que se sont surtout des usines à gaz. Seul CodeIgniter sort du lot : il est très léger grâce aux modules indépendants, qui ne sont chargés qu'à la demande du contrôleur, mais il a le défaut de la rigidité des URLs. LE framework MVC est donc plus une collection de composants utilisables au sein d'un micro container. C'est la démarche de CodeIgniter et de Zend Framework, bien que ce dernier soit un peu plus complexe.

L'utilisation d'un framework nécessite toujours un investissement pour former les développeurs. Cet investissement sera d'autant plus important que le framework sera complexe. Cette complexité entrainera également des frais plus élevé de maintenance et d'évolution. Dans bien des cas, cet investissement est beaucoup plus rentable s'il est effectué dans le développement d'un micro-noyau maison...

Comment sauvegarder automatiquement une base de données MySQL à distance

Tue, 20 Feb 2007 21:14:44 +0100

Lorsque son site est hébergé sur un serveur auquel on n'a pas d'accès SSH (Free par exemple), il est quand même possible de sauvegarder sa base de données MySQL automatiquement et à distance.

Pour cela il faut disposer :

de phpMyAdmin installé sur le serveur (c'est le cas chez Free),
de Wget installé sur le poste à partir duquel doit se faire la sauvegarde.

Il suffit alors d'exécuter la commande :

wget --http-user=USER --http-passwd=PASSWORD --post-file=export.txt -O FICHIER http://phpmyadmin.free.fr/phpMyAdmin/export.php

En remplaçant USER par votre login, PASSWORD par votre mot de passe et FICHIER par le nom du fichier dans lequel vous souhaiter sauvegarder votre base. export.txt est un fichier contenant les paramètres de la requête envoyée au serveur :

what=sql&asfile=sendit&export_type=server&sql_structure=structure&sql_type=insert&sql_data=data&auto_increment=1&use_backquotes=1

Selon le type d'export voulu, il faudra fournir les bons paramètres. Afin de les déterminer précisément, l'extension Live HTTP Headers pour Firefox est d'un grand secours. Pour automatiser la procédure, il suffit d'ajouter la commande à la liste des tâche à lancer par cron (ou son équivalent sur un autre OS).

Édition 02/08/2007 : Lionel, un lecteur me signal la possibilité de passer par le service de backup de Free :

wget http://sql.free.fr/backup.php --post-data="login=USER&password=PASSWORD&check=1&all=1" -O backup.sql.gz

Merci Lionel.

Framework PHP MVC : pourquoi s'en passer

Mon, 15 Jan 2007 21:41:56 +0100

Beaucoup plus populaire que les conteneurs implémentant l'inversion de contrôle, les frameworks MVC (Model-View-Controller ou Modèle-Vue-Contrôleur) en PHP sont légion. Ils participent de cette attente irrationnelle du monde PHP envers la programmation orientée objet et son corollaire, le framework. Seul Rasmus Lerdorf semble percevoir le comique de la situation avec son no-framework PHP MVC framework. Avant de vous décidez de démarrer votre prochain projet avec un tel framework, considérez d'abord les inconvénients suivants :

Une application moins performante. Les diverses couches d'abstraction et la panoplie impressionnante de composants accompagnant tout framework en font un mécanisme lourd, consommant beaucoup de ressources matérielles. La mise en production peut alors s'accompagner de l'achat, en urgence, d'un système de cache performant pour remédier aux performance déplorables. Rappelons-nous des difficultés de lancement du GéoPortail ou plus récemment les débuts difficiles du comparateur de prix des carburants du Minefi.
Coût de développement accrus. La complexité du framework induit des salaires plus élevés pour les développeurs spécialisés en raison de leur rareté ou des frais de formation (ou de perte de productivité) pour les autres développeurs. Ajoutez les frais de formation à un nouveau langage de script si le framework s'appuie sur un moteur de template style Smarty, très à la mode chez les développeurs PHP. Ces moteurs n'ont aucune utilité (si ce n'est de complexifier le développement) comme le montre bien l'article PHP for designers de Matt Mullenweg (co-fondateur et développeur principal de WordPress). Seule compte la séparation des préoccupations.
Une application bridée. Une autre conséquence de la complexité d'un framework est la difficulté de l'étendre ou de l'adapter à ses besoins particuliers.
Une application ne répondant pas aux besoins des utilisateurs. La plupart des framework font des choix radicaux en termes de conception grévant les fonctionnalités de l'application. L'exemple le plus simple : l'URL rewriting. L'URL d'une page est généralement de la forme http://my.web.com/module/action/params pour invoquer l'action action du module module. Aussi lorsque l'on souhaite créer un site web dont les URLs représentent l'architecture fonctionnelle du site, cela s'avère très compliqué ! Ainsi au lieu d'avoir l'URL http://www.numabilis.com/services/realisation_de_sites_web on a quelque chose comme http://www.numabilis.com/article/view/id/35. Le module de réécriture fourni est généralement insuffisant : les sections Services et Réalisations étant toutes deux constituées d'articles, la réécriture ne permet pas de distingués les articles de ces deux sections ! Comme souvent les couches techniques imposent des contraintes fortes sur le fonctionnel.

Les frameworks PHP, dans leur très grande majorité, souffrent d'une trop grande complexité. Ils singent le monde Java (voir les implémentations PHP de Struts : Phrame, PhpMVC ou Studs) en faisant du tout objet avec force renfort de template engine et de mod_rewrite.

Par conséquent, sauf si vous êtes chef de projet dans une grosse structure, dont le poste n'est justifié que par votre capacité à résoudre les problèmes que vous avez vous même créés, vous devriez vous passer d'un tel framework.

Veni Vidi Wiki (dessin de Brad Fitzpatrick)

Technorati Profile

Le Monde parle de "mon" projet !

Sat, 23 Dec 2006 15:19:31 +0100

Dans son édition de mardi dernier, Le Monde a publié un article évoquant le projet que je dirige à l'Agence France Presse. J'ai commencé cette mission début novembre et un premier prototype a été présenté au PDG, Pierre Louette, ce même mardi 19 décembre. Je ne sais pas si l'interview a eu lieu avant ou après, mais je sais, qu'il est très satisfait de ce premier résultat.

Ultime innovation : le PDG souhaite lancer l'AFP vers le grand public, au risque d'entrer en concurrence avec ses propres clients. L'agence veut se doter d'un site Internet, hébergeur de blogs, où se retrouveraient journalistes professionnels et journalistes « citoyens », images d'agence et vidéos d'internautes. Ce site, « en anglais, sera testé en Asie et aux Etats-Unis, pas en France... », précise prudemment M. Louette.

Extrait de « L'AFP a gagné 3 millions d'euros en 2006 », Le Monde du 19 décembre 2006.

Même si la description donnée est assez réductrice, et que nous ne faisons pour le moment qu'un prototype, cela fait vraiment plaisir...

Critères de choix d'un logiciel (libre)

Mon, 02 Oct 2006 10:29:42 +0200

Comme le montrent régulièrement Bertrand Lemaire ou Louis Naugès, les décideurs choisissent trop souvent leurs logiciels en fonction de deux critères principaux : couverture fonctionnelle et notoriété de l'éditeur. (Voir par exemple les billets Diatribe à la Paresse ou To Vista or not to Vista, that is the question !.) Ce deuxième critère disparaissant, dans le cas des logiciels libres, on comprend mieux pourquoi, leur adoption est si lente en entreprise. Pourtant toute solution logicielle devrait être évaluée selon une grille de critères indépendants de sa caractéristique libre ou propriétaire. Voici quelques pistes.

Bien qu'il soit assez facile d'établir une liste de critères subjectifs (simple, ergonomique, etc), ceux-ci ne permettent généralement pas d'évaluer objectivement (autant que possible) les solutions disponibles. Pourtant, seule une évaluation objective s'appuyant sur des paramètres mesurables peut minimiser notre subjectivité. Pour dresser une telle liste de paramètres, nous partons des critères subjectifs que nous traduirons ensuite en une métrique. Par exemple, la liste suivante :

Simplicité d'apprentissage et de mise en oeuvre
Simplicité d'adaption à ses besoins : simple à étendre sans modification.
Fonctionnalités requises et souhaitées pour le projet
Interopérabilité
Stabilité
Pérennité
Qualité du support
Licence adaptée au projet

La satisfaction de ces critères peut être évaluée en mesurant des grandeurs plus objectives :
Sur le plan technique :

Simplicité de la conception : nombre de classes, de fichier, de lignes de code, etc.
Degré de modularité : nombre de modules (ou plugins), indépendance entre eux.
Utilisation de normes : Design Patterns, charte de codage, etc.
Respect des standards et des formats ouverts : formats d'entrée/sortie, protocoles de communications, etc.
Légèreté de la solution : emprunte mémoire, rapidité d'exécution.
Fiabilité et stabilité : nombre d'erreurs en stress test, nombre de bugs présents/corrigés sur le tracker.
Importance de la documentation : API (via un générateur de documentation), manuels, guide, tutoriel.

Sur le plan humain :

Taille de la communauté : développeurs, utilisateurs, organismes et sociétés de soutien.
Efficacité du support : forum, mailing list, etc.
Ancienneté de la solution, maturité.
Visibilité : nombre de citation google par exemple.
Références : acteurs et projets utilisant la solution.

Toute étude menée pour choisir une solution devrait dresser la liste des critères subjectifs puis objectifs guidant le choix. L'étude doit ensuite concevoir la métrique à partir de ces critères plutôt que de se servir d'une grille standard qui sert à tous les projets. Et malgré cela, des facteurs subjectifs non mesurables auront toujours un grand rôle dans le choix...