PHPPRO

Introduction sur les Tests Unitaires - Support de Formation

Olivier Hoareau — Sun, 09 Sep 2012 22:42:00 +0200

Demain je donnerai une formation sous forme de Dojo sur le refactoring par les tests d'une application métier chez un de mes clients. Voici mon support de formation pour la première partie de la matinée sur le rappel théorique sur les tests unitaires. Demain je donnerai une formation sous forme de Dojo sur le refactoring par les tests d'une application métier chez un de mes clients.

Nous avons prévu une petite remise à niveau théorique sur le sujet des tests unitaires.

Je vous livre ici mon support de formation pour cette première partie théorique.

Intro sur les tests unitaires from PHPPRO

PS: 1 an déjà depuis mon dernier billet sur ce blog, espérons que le prochain ne soit pas dans un an !

Présentation Drupal au Bordeaux PUG le 22/09 à 19h

Olivier Hoareau — Tue, 30 Aug 2011 15:35:00 +0200

Dans le cadre d'une PHP User Group de Bordeaux que je co-organise, nous accueilleront Stéphane Jaulin le 22 septembre 2011 à 19h qui viendra nous parler de Drupal.

L'annonce sur le site du Bordeaux PUG

Fonctionnalité PM du jour : commencer à utiliser PM sur un projet existant

Olivier Hoareau — Tue, 19 Apr 2011 18:42:00 +0100

Vous travaillez déjà sur un projet de développement. Vous avez entendu parler (ou pas) d'un outil en ligne de commande qui s'appellerai PM et qui aurait certaines fonctionnalités obscures... Vous avez envie de le tester mais vous ne savez pas comment vous y prendre, ce billet est fait pour vous...

Pour rappel, PM est mon outil en ligne de commande pour "augmenter la productivité d'équipe", vous trouverez des informations, le code source et la dernière version (0.1.3.4 à l'heure ou j'écris ces lignes) sur le site officiel : http://github.com/phppro/pm.

Première étape : disposez d'un projet existant

Commencez par choisir un projet (code source) sur lequel vous travaillez déjà (ou avez déjà travaillé). Mettez le dans un répertoire sur votre disque local, disons $HOME/dev/ze-project (ou $HOME est /home/<login> sous linux, et C:\Users\<login> ou C:\Documents and Settings\<login> sous windows XP et supérieure).

Vous êtes prêt ?

Deuxième étape : télécharger pm.phar

L'outil PM est empaqueté sous la forme d'un fichier unique pm.phar qu'il faut télécharger à l'adresse : http://github.com/downloads/phppro/pm/pm.phar (attention, votre navigateur pourrais modifier le contenu du .phar en le téléchargeant, pour ne pas avoir de problème accédez via votre navigateur à http://github.com/phppro/pm, cliquez sur le bouton Download/Télécharger à droite de l'écran et cliquez-droit sur pm.phar, et enregistrer la cible sur le disque dur.

Une fois téléchargé, copiez/déplacer pm.phar dans le répertoire $HOME/dev/ze-project/pm.phar

Troisième étape : installer PHP 5.3 (si il n'est pas encore installé sur votre système)

Bien qu'il puisse "gérer" des projets utilisants n'importe laquelle des versions de PHP (même PHP 4 !), PM nécessite lui-même PHP 5.3 ou supérieure (version CLI / Ligne de Commande) pour fonctionner. Pour vérifier que vous avez une version suffisante de PHP installée :

ouvrez une console / shell et exécutez :

$ php -v

PHP 5.3.5 (cli) (built: Jan  5 2011 20:29:28)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

Si vous avez une version inférieure à 5.3.0, alors vous ne pourrez pas utiliser PM avec cette version de PHP. Si c'est le cas, pas de panique, il vous suffit juste d'installer une version complémentaire de PHP sur votre système. Bien sûr, vous pouvez décider de mettre à jour votre version actuelle de PHP pour utiliser une version >= 5.3.0, cependant vérifier bien avant que toutes vos applications locales et tous les développements sur lesquelles vous travaillez sont compatibles avec cette nouvelle version majeure.

Installer une version supplémentaire de PHP 5.3 sur votre poste

Suivant que vous soyez sur Windows ou Linux, la méthode pour installer une version complémentaire de PHP sera différente.

Vous êtes sous Windows

Téléchargez la dernière version de PHP 5.3.x sur le site officiel, en choisissant le paquet binaire windows en version zippée (quelque chose php-5.3.6-nts-Win32-VC9-x86.zip)
Dézippez le paquet téléchargé n'importe où sur votre disque dur, par exemple dans C:\Program Files\PHP-5.3, de sorte que vous ayez C:\Program Files\PHP-5.3\php.exe
Créez le fichier C:\Windows\php-5.3.bat avec le contenu suivant :

@echo off
"C:\Program Files\PHP-5.3\php.exe" -c "C:\Program Files\PHP-5.3\php.ini-development" %*

ouvrez une ligne de commande windows, exécutez :

$ php-5.3 -v

PHP 5.3.6 (cli) (built: Mar 17 2011 10:48:37)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

Vous êtes sous Linux

Avec la grande majorité des distributions, il est recommandé d'installer vos logiciels avec un système d'installation de paquets, tel que aptitude / apt / yum / rpm / ... Un des problèmes récurrents avec l'utilisations de ces outils est qu'il est difficile (certains pourront peut être nous conseiller la dessus ;)) d'installer plusieurs versions d'un logiciel en même temps sur le même système. A moins que vous ayez trouvé une solution spécifique à votre distribution, je vous propose donc de passer par la case compilation (désolé ;)) :

Je propose une méthode de compilation de PHP en ligne de commande basique pour Ubuntu 10.04 LTS 64 bits

L'important est d'arriver à avoir un exécutable php (quelque soit sont chemin et son nom) qui peut utiliser son propre php.ini et ses propres extensions .so (si besoin) sans "toucher" à votre installer actuelle de PHP.

Quatrième étape: exécuter PM pour la première fois

Ca y est, vous avez PHP 5.3+ installé/disponible sur votre machine et accessible par la commande php-5.3 (ou bien php !)

reouvrez une console / shell
rendez-vous depuis la console dans le répertoire $HOME/dev/ze-project, puis exécutez la ligne suivante et répondez aux questions posées :

$ php-5.3 pm.phar

PM v0.1.3.4 par PHPPRO http://github.com/phppro/pm

Voulez-vous activer le support de PM pour votre projet (Y,n) [Y] : Y

Vous n'avez pas encore defini vos parametres projet, voulez-vous les definir maintenant (Y,n) [Y] : Y
Quelle est la langue d'affichage par defaut pour tous les membres de l'equipe (<auto>,en-us,fr-fr) [<auto>] : fr-fr
Quel est le nom de code (minuscules, sans accent, sans espace) du projet [ze-project] : ze-project
Quelle est le nom de l'entreprise / l'organisation proprietaire de ce projet : PHPPRO
Quelle est l'adresse du site internet de 'PHPPRO' [http://www.phppro.com] : http://www.phppro.fr

Merci ! le projet s'appelle maintenant "ze-project".
Vous pourrez mettre a jour a tout moment les preferences du projet dans le fichier _pm/project.ini ou project.php (les deux sont fusionnes)

Vous n'avez pas encore defini vos parametres utilisateur, voulez-vous les definir maintenant (Y,n) [Y] : Y
Quelle est votre langue d'affichage preferee (<auto>,en-us,fr-fr) [<auto>] : fr-fr
Quel est votre nom [ohoareau] : Olivier Hoareau
Quelle est votre adresse email : me@email.com

Merci ! vous serez maintenant identifie "ohoareau" sur ce projet.
Vous pourrez mettre a jour a tout moment vos preferences dans le fichier _pm/users/ohoareau.ini

Pour afficher l'aide : "pm -h [<action|prefixe>]"
Un bug ? une fonctionnalite ? http://github.com/phppro/pm, merci !

Ca y est ! le support de PM est activé pour votre projet !

Il vous faudra ensuite éventuellement modifier le contenu des fichiers pm (linux) ou pm.bat (windows) pour remplacer "php" par le nom de l'exécutable (chemin complet ou nom spécifique) PHP à utiliser pour exécuter la version PHP 5.3+.

Vous devriez maintenant pouvoir exécuter PM directement avec la commande pm.

Enfin presque, si vous êtes sous linux, il vous faudra utiliser ./pm après avoir fait :

$ chmod u+x ./pm

$ pm

PM v0.1.3.4 par PHPPRO http://github.com/phppro/pm

Pour afficher l'aide : "pm -h [<action|prefixe>]"
Un bug ? une fonctionnalite ? http://github.com/phppro/pm, merci !

Cinquième étape: afficher la liste des commandes

Pour afficher la liste des commandes PM disponibles (certaines sont activées en fonction des fichiers contenus dans votre projet et des outils que vous utilisez, comme svn et phpunit par exemple), exécutez depuis la racine de votre projet :

$ pm -h

PM v0.1.3.4 par PHPPRO http://github.com/phppro/pm

Syntaxe : pm [<options-communes>] <action> [arg1] [arg2] [...] [options]

Listes des options communes disponibles :

 -d <cle>=<valeur>        modifie une directive INI de PHP
 -h [<action>|<prefixe>]  affiche cette aide ou l'aide de l'action specifiee
 -l=<langue>              modifie la langue d'affichage (en-us*, fr-fr, ...)
 -o                       active le mode debug
 -s                       liste tous les pre-reglages charges
 -v                       affiche la version de PM
 -i                       active le mode interactif
 -u                       mets a jour a la derniere version de PM

Liste des actions disponibles :

 new      cree une nouvelle action/commande personnalisee

 pkg      cree un paquet contenant le code source du projet (format par defaut: phar)
 publish  publie le code source du projet ou le paquet specifie sur la cible distante specifiee

 tpl      utilise un modele pour generer une arborescence de fichiers
 tpl:new  cree un nouveau modele d'arborescence vide


Pour afficher l'aide : "pm -h [<action|prefixe>]"

Un bug ? une fonctionnalite ? http://github.com/phppro/pm, merci !

La liste des commandes qui s'affichent pour vous peut être légèrement différente car PM tente de détecter la présence de certains fichiers dans votre projet (.project par exemple ou .svn) ou bien la présence de certains exécutables dans le PATH système (comme phpunit) pour vous ajouter éventuellement des commandes supplémentaires.

Vous pouvez maintenant commencer à utiliser pleinement PM !

Je vous invite à parcourir le document de présentation de PM accessible sur SlideShare, vous pourrez notamment y découvrir les principales commandes, que je décrirais prochainement sur le blog.

Alors, tout s'est bien passé ? ;)

Vos idées / remarques / critiques sont bien entendus les bienvenus directement sur http://github.com/phppro/pm/issues

Compiler PHP 5.3.x sous linux

Olivier Hoareau — Tue, 19 Apr 2011 18:10:00 +0100

Pour les besoins d'un futur billet sur ce blog, je décris ici un exemple de méthode de compilation de PHP sous Linux Ubuntu 10.04 LTS (64 Bits). La méthode reste la même dans les grandes lignes sur l'ensemble des distributions modernes, vous aurez peut être à personnaliser quelques dépendances de paquets par ci par là.

(Attention: l'opération "make" peut prendre plusieurs minutes à plusieurs dizaines de minutes en fonction de la capacité de votre machine)

$ cd ~
$ mkdir test-compilation
$ cd test-compilation
$ wget 'http://fr.php.net/distributions/php-5.3.6.tar.bz2'
$ tar xjvf php-5.3.6.tar.bz2 > /dev/null
$ cd php-5.3.6/
$ sudo apt-get install libc-dev libxml2-dev libmcrypt-dev gcc
$ ./configure --disable-cgi --enable-mbstring --with-mcrypt
$ make clean
$ make

Si aucune erreur de compilation n'est survenue, vous devriez avoir votre exécutable dans :

sapi/cli/php

Pour tester votre nouvel exécutable :

$ ./sapi/cli/php -c ./php.ini-development -v

PHP 5.3.6 (cli) (built: Apr 19 2011 18:53:16)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

Vous pouvez maintenant créer un script shell pour accéder rapidement a votre exécutable :

$ mkdir -p ~/bin
$ vi ~/bin/php-5.3

#!/bin/sh

~/test-compilation/php-5.3.6/sapi/cli/php -c ~/test-compilation/php-5.3.6/php.ini-development $*

$ chmod u+x ~/bin/php-5.3
$ source ~/.profile

Testez maintenant votre script :

$ php-5.3 -v


PHP 5.3.6 (cli) (built: Apr 19 2011 18:53:16)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

Vous pouvez maintenant utiliser votre exécutable *php-5.3* en ligne de commande

Bien sûr il s'agit d'une procédure minimaliste de compilation de PHP, l'objectif étant d'avoir le strict nécessaire pour avoir PHP exécutable en ligne de commande en version 5.3, sans désinstaller la version actuelle de PHP

PM : Développeurs, augmentez votre productivité !

Olivier Hoareau — Wed, 13 Apr 2011 22:39:00 +0100

Ce soir, lors de la première séance du PHP User Group Bordeaux, j'ai présenté mon nouvel outil en ligne de commande pour augmenter la productivité au quotidien : PM. Voici la slides de ma présentation, vos commentaires sont les bienvenus !

PM : code faster

View more presentations from PHPPRO

ARM : "Array Relational Mapping", où comment faire du lazy loading avec des arrays en PHP...

Olivier Hoareau — Thu, 31 Mar 2011 23:14:00 +0100

Considérez

$user = array('login' => 'ohoareau', 'company_id' => 12);

Imaginez que vous puissiez directement l'utiliser pour faire ça :

$login = $user['login'];
// récupères les données de l'entreprise en réalisant
// une jointure automatique
$companyName = $user['company']['name'];

Sans avoir besoin d'utiliser un "objet" (ou classe) User pour charger "à la demande" les jointures avec la table organization...

PHP 5 propose un mécanisme natif permettant d'utiliser un objet (i.e. une instance d'une classe) comme un array. Cela permet par exemple d'utiliser la même syntaxe pour accéder aux propriétés d'un objet et aux index d'un array :

$arrayObject = new MyLazyLoadingClass();
$arrayObject['key1'] = 'value1';
$theValue = $arrayObject['key1'];

// et

$array = array();
$array['key1'] = 'value1';
$theValue = $arrayObject['key1'];

Pour obtenir ce comportement il suffit juste que votre classe "implémente" une interface native nommée "ArrayAccess" et imposant d'implémenter les méthodes suivantes :

public function offsetGet($key);
public function offsetSet($key, $value);
public function offsetExists($key);
public function offsetUnset($key);

Voila ce que nous souhaiterions maintenant pouvoir faire :

$user = array('login' => 'ohoareau', 'company_id' => 12);

$user = new LazyArray($user);

or directly create a lazy array the same way you create array

$user = lazy(array('login' => 'ohoareau', 'company_id' => 12));

echo sprintf(
    "User '%s' is working at '%s' in '%s', but living in '%s' (%s)",
    $user['login'],
    $user['company']['name'],
 );

L'idée étant que lorsqu'un index du tableau qui n'est pas initialement disponible est accédé, alors un mécanisme dynamique de chargement automatique permet de récupérer les données de façon transparente. On peut donc imaginer que la jointure en base de données organization_id soit effectuée dans une seconde requête SQL uniquement que si l'indice "organization" est accédé, et donc pas de façon systématique.

Ci-dessous vous trouverez un exemple de classe LazyArray et de fonction lazy() :

<?php

class LazyArray implements \ArrayAccess
{
	protected $_data;
	protected $_loader;
	protected static $_defaultLoader = null;
	
	public static function setDefaultLoader($loader)
	{
		static::$_defaultLoader = $loader;
	}
	public static function getDefaultLoader()
	{
		if (null === static::$_defaultLoader) {
			static::$_defaultLoader = function($key, $value, $data) {
				return $value;
			};
		}
		
		return static::$_defaultLoader;
	}
	public function __construct($data, $loader = null, $recursive = true)
	{
		if (false === is_bool($recursive)) {
			$recursive = true;
		}
		if (false === is_array($data)) {
			$data = array();
		}
		if (true === $recursive) {
			foreach($data as $k => $v) {
				$data[$k] = is_array($v) ? new LazyArray($v, $loader, $recursive) : $v;
			}
		}
		$this->_data = $data;
		$this->_loader = null === $loader ? static::getDefaultLoader() : $loader;
	}
	public function offsetGet($key)
	{
		if (false === isset($this->_data[$key])) {
			if (true === isset($this->_data[$key . '_id'])) {
				$callback = $this->_loader;
				if (true === is_array($callback)) {
					$this->_data[$key] = new LazyArray(
                                            $callback[0]->{$callback[1]}(
                                                $key, $this->_data[$key . '_id'], $this->_data)
                                             );
				} else {
					$this->_data[$key] = new LazyArray(
                                            $callback($key, $this->_data[$key . '_id'], $this->_data)
                                        );
				}
				return $this->_data[$key];
			}
			throw new \RuntimeException("Unknown key '$key'");
		}
		
		return $this->_data[$key];
	}
	public function offsetSet($key, $value)
	{
		$this->_data[$key] = $value;
		
		return $value;
	}
	public function offsetExists($key)
	{
		return true === isset($this->_data[$key]) || true === isset($this->_data[$key . '_id']);
	}
	public function offsetUnset($key)
	{
		unset($this->_data[$key]);
	}
}

function lazy($data, $loader = null, $recursive = true)
{
	return new LazyArray($data, $loader, $recursive);
}

function myLoadingFunction($key, $value, $data)
{
        // you can easily do your SQL selection stuff here

	switch($key) {
		case 'company':
			return array(
				'name' => 'phppro',
				'city_id' => 3,
			);
		case 'city':
			switch($value) {
				case 3:
					return array(
						'name' => 'bordeaux',
						'zipcode' => '33000',
					);
				case 4:
					return array(
						'name' => 'talence',
						'zipcode' => '33400',
					);
			}
		default:
			throw new \RuntimeException("Unknown loadable type '$key'");
		
	}
}

// in this example we have a previously defined function that provide loading feature
LazyArray::setDefaultLoader('myLoadingFunction');
// in this example we have an anonymous function (closure) that provide loading feature
LazyArray::setDefaultLoader(function ($key, $value, $data) { /* ... */ });
// in this example we have a $db object instance that provide a load($key, $value, $data) method
LazyArray::setDefaultLoader(array($db, 'load'));


$user = lazy(array('login' => 'ohoareau', 'company_id' => 12));
$company = $user['company'];

On peut très bien imaginer mettre en place d'autres conventions, comme par exemple :

// récupères tout les utilisateurs de l'entreprise courante
$users = $company['users']; 

// supprime le lien entre cet utilisateur et son entreprise
unset($user['company']); 

// récupères tous les utilisateurs s'appellant olivier dans l'entreprise
$users = $company['users#name~olivier'];

Cette technique (ou une dérivée) vous permettra certainement d'éviter d'utiliser des framework ORM complexe pour vos besoins les plus simples, et notamment éviter d'avoir des dizaines de classes type "DAO" ...

Et vous utilisez vous ArrayAccess ou un équivalent pour tirer partie de la puissance des tableaux en PHP ?

Le comportement attendu d'une méthode : où comment se servir des conventions de nommage plutôt que des commentaires

Olivier Hoareau — Wed, 23 Mar 2011 07:00:00 +0000

Quel comportement attendez-vous quand vous appellez setX() ? getX($id) ? checkX() ? isX() ? listX() ? Chaque préfixe de nom de méthode à son propre "comportement attendu", voici une proposition de comportements communément utilisés...

Le nommage des méthodes est tout un art, plus le nom de la méthode est claire et logique, plus le ou les développeurs qui l'utilisent sauront comment bien l'utiliser.

Le nom d'une méthode est composée d'au moins 2 informations utiles :

un préfixe (souvent court, le premier mot)
un suffixe (souvent long, de plusieurs mots)

L'utilisation judicieuse de préfixes "connus" permet de connaître à l'avance le comportement qu'une méthode aura.

Voici les conventions d'utilisation de préfixes que je préconise régulièrement aux équipes de développement PHP :

En plus des préfixes, certaines "préfixes génériques" altère le comportement d'une méthode ayant déjà un préfixe :

Enfin, il convient de respecter certaines conventions lors du développement de l'implémentation d'une méthode, permettant ainsi de faciliter son utilisation :

L'utilisation de toutes ces conventions (préfixe, modifieurs et conventions communes) permet de rendre le code plus claire et logique, l'utilisation de commentaire dans la logique (i.e. à l'intérieur d'une méthode) est donc souvent moins nécessaire.

Et vous, utilisez vous des conventions différentes ?

Au secours j'ai trop de log !

Olivier Hoareau — Sun, 20 Mar 2011 22:26:00 +0000

Et vous comment faites vous pour n'activer que certaines lignes de debug mais pas toutes dans vos applications ?

Régulièrement il est nécessaire de mettre en place des traces et logs dans nos applicatifs, qu'ils soient batchs ou web pour avoir un peu plus d'information sur ce qu'il se passe lors de l'exécution, notamment suite à la détection d'un bug en production.

On commence souvent par implémenter quelque chose comme :

$this->log('info',"Mon message de log pour tracer '$v'");

// ...

$this->log('debug', "Mon autre message de log");

Puis on se rend compte que l'on souhaite mutualiser certains messages, les rationnaliser, éviter de repasser profondément dans le code pour mettre à jour les messages et préférer la centralisation dans un fichier de paramétrage par langue par exemple. On améliore alors notre méthode log() pour prendre une clé de message et une liste de paramètres variables (optionnels), le message sera alors chargé depuis un fichier de paramétrage :

$this->log('info', 'my.message.key', $variable);

// ...

$this->log('debug', 'my.other.message.key');

avec un fichier de langue :

my.message.key=Mon message de log pour tracer '%{1}'
my.other.message.key=Mon autre message de log

Enfin, et c'est l'objectif de ce billet, on se rend compte que cela n'est pas très pratique de mettre en dur dans le code source le niveau d'erreur des messages, car à l'exécution il peut être intéressant d'afficher certains messages debug mais pas tous car cela serait trop verbeux, on enlève alors le premier paramètre :

$this->log('my.message.key', $variable);

// ...

$this->log('my.other.message.key');

et on peut ainsi mettre en place un mécanisme au chargement (bootstrap) de la requête ou du script qui prend en compte un fichier de paramétrage complémentaire ou bien une variable d'environnement ou en ligne de commande :

# niveau info pour le message my.message.key
my.message.key=info
# niveau debug pour tous ceux commencant par my.other
my.other=debug

Au final l'utilisation d'une clé au lieu d'un message, nous permet :

de centraliser la traduction des messages dans un fichier de paramétrage
de sélectivement définir le niveau d'erreur du message à l'exécution

Si vous choisissez judicieusement les préfixes de vos clés, vous pourrez être en mesure de :

n'activer les traces que pour les appels systèmes ou les accès disques
désactiver complètement les logs pour certaines catégories de logs

Et vous comment faites vous pour n'activer que certaines lignes de debug mais pas toutes dans vos applications ?

Conférence au Bordeaux PUG sur un nouvel outil d'industrialisation PHP le 13/04/11

Olivier Hoareau — Sun, 20 Mar 2011 22:01:00 +0000

Le 13 avril prochain je présenterai mon outil de "gestion de projet" pour développeur PHP (version beta, open source, under heavy development).

En fait, vous aurez reconnu un outil en ligne de commande qui est un mix entre zf.bat / sf.bat et maven (entre autres ;)).

Voici le teaser de la conférence pour ceux que ca intéresse : http://bordeauxpug.org/2011/03/20/session-du-13-avril/

Je mettrai en ligne les slides de la présentation une fois celle ci passée, restez connecté !

Un petit avant gout :

Générer une classe avec votre propre cartouche de commentaires, la date et votre nom, avec en plus sa classe de test vide associée :

pm template:apply service
pm t service

Lancer les tests unitaires, que vous utilisiez Symfony, Zend Framework ou whatever framework :

pm tu

Lancer les tests unitaires avec le rapport HTML de couverture de code :

pm tuc

Créer un paquet Phar ou PEAR de votre code source :

pm package
pm package:pear

et pleins d'autres fonctionnalités :

installer un poste de développeur from scratch et checkouter un projet en une ligne de commande (plus fort que Wamp ;))
indexer l'ensemble de votre code source dans une base de données SQLite pour réaliser des statistiques sur votre code (toujours en une ligne de commande)
créer vos propres raccourcis de commandes (en pur PHP) !
utiliser un outil traduit (ou que vous pouvez traduire) dans votre langue
support avancée et évolué des traces/logs
...

Piste pour gérer les spécificités de plusieurs clients (versions) au sein d'une même application (version)

Olivier Hoareau — Mon, 29 Nov 2010 08:24:00 +0000

C'est naturel (enfin pour la majorité) : on commence toujours par développer "spécifique" :

écran et boutons d'actions spécifiques à notre client
règle de gestion et workflow spécifiques à notre client
messages d'erreurs et envoi d'emails spécifiques à notre client
...

Puis notre produit / logiciel est un premier succès et un autre client nous le demande, puis un autre, ... Nous devons alors faire face à un problème sans forcément nous en rendre compte : Comment gérer plusieurs mode de fonctionnement (i.e. un fonctionnement pour chaque client) au sein de la même application ? Comment éviter de dupliquer / cloner l'application et maintenir N versions en parallèle ?

Etudions un cas simple, notre premier client indique que tous les utilisateurs ont le droit de créer des messages, nous commençons donc par écrire :

<?php

namespace Message;

class Service
{
    public function add($data)
    {
        // create a new row in database and return ID
        return $this->getAdapter()->create($data);
    }
}

Puis un deuxième client nous indique que seul les internautes connectés ont le droit de créer des messages (le premier client n'a pas changé ses spécifications, lui) :

<?php

namespace Message;

class Service
{
    public function add($data)
    {
        if ('client2' === $GLOBALS['client']) {
            if (false === isset($GLOBALS['user']) {
                throw new \RuntimeException('Denied');
            }
        }
        // create a new row in database and return ID
        return $this->getAdapter()->create($data);
    }
}

En quelques lignes, nous avons traité les spécificités du client 2 tout en restant compatible avec le client 1. Oui, mais :

à chaque nouveau client, il faut repasser sur le code pour le spécialiser
il risque soit d'y avoir beaucoup de copier/coller soit beaucoup de complexité
les méthodes vont s'allonger et ne seront plus trop compréhensibles
...

Un troisième client nous appelle et nous demande de vérifier que l'internaute est connecté et à le profil "admin", ...

Nous pourrions décider de "sortir" la logique contenant les règles de gestion du code métier d'ajout de message:

<?php

namespace Message;

class Service
{
    public function add($data)
    {
        $this->checkRights('message.add');
        return $this->getAdapter()->create($data);
    }
    public function checkRights($operation)
    {
        $operationKey = $GLOBALS['client'] . '.' . $GLOBALS['userProfile'];

        $allowed = false;

        switch($operationKey) {
        case 'client1.all.message.add': $allowed = true; break;
        case 'client2.logged.message.add': $allowed = true; break;
        case 'client3.admin.message.add': $allowed = true; break;
        }

        if (false === $allowed) {
            throw new \RuntimeException('Denied');
        }

        return $this;
}

Puis nous pourrions finalement décider de complètement sortir la liste des "règles" dans un fichier de paramétrage "par clients" :

<?php

namespace Message;

// chargement des règles spécifiques au client en cours
$GLOBALS['rules'] = include 'configs/rules/' . $GLOBALS['client'] . '.php';

class Service
{
    public function add($data)
    {
        $this->checkRights('message.add');
        return $this->getAdapter()->create($data);
    }
    public function checkRights($operation)
    {
        // check if all profiles are allowed for this operation
        if (true === isset($GLOBALS['rules']['all.' . $operation])) {
            return $this;
        }
        // check if current profiles is allowed for this operation
        if (true === isset($GLOBALS['rules'][$GLOBALS['userProfile'] . '.' . $operation])) {
            return $this;
        }
        // check if user is logged and if logged users are allowed
        if (true === isset($GLOBALS['userLogin']) && isset($GLOBALS['rules']['logged.' . $operation])) {
            return $this;
        }

        throw new \RuntimeException('Denied');
    }
}

Avec un fichier les fichiers de paramétrages suivants :

<?php
// configs/rules/client1.php
return array(
    'all.message.add' => true,
);

<?php
// configs/rules/client2.php
return array(
    'logged.message.add' => true,
);

<?php
// configs/rules/client3.php
return array(
    'admin.message.add' => true,
);

Vous pouvez maintenant aisément ajouter des règles dans vos fichiers de configuration et utiliser votre méthode "checkRights()" pour vérifier que l'utilisateur connecté à le droit d'exécuter l'opération. Une fois mis en place l'utilisation de checkRights() partout dans votre code, vous n'aurez plus qu'à modifier vos fichiers de règles pour :

ajouter un nouveau client
ajouter ou modifier des règles existantes

Bien sûr cette "implémentation" reste très basique et vous pourriez vouloir traiter en plus les points suivants :

fichiers de paramétrages dans un DSL (Domain Specific Language) plus facile à appréhender que PHP pour vos collaborateurs commerciaux ou fonctionnels
utilisation d'un meilleur mécanisme que les variables globales (passage en paramètre du contexte, registry, ...)
prise en compte des données dans les règles (ex: si le sujet commence par "TEST" alors tout le monde peut créer le message)
prise en compte de post-operations comme l'envoi d'email (pour certains clients), ...
mise en place d'une classe abstraite / générique fournissant checkRights() à toutes les fonctionnalités de votre application
utilisation / mutualisation des règles dans la partie IHM écrit en Javascript
...

Toutes ces fonctionnalités restent assez simples à mettre en oeuvre en partant de la base présentée ci-dessus.

Sans le savoir, vous avez mis en place un véritable petit moteur de règles !

Et vous quels sont vos techniques pour gérer les spécificités de vos clients au sein de la même application ?

Autoloader de classes : comment prendre en compte les namespaces de PHP 5.3+

Olivier Hoareau — Sat, 27 Nov 2010 14:46:00 +0000

Pour ceux qui ne connaissent pas (encore), le mécanisme d'autoload en PHP permet (entre autres) d'inclure "à la demande" les fichier-classe. Classiquement en PHP, nous faisons :

require_once 'My/Service.php';

$o = new My_Service();

Le mécanisme d'autoload permet d'écrire uniquement :

$o = new My_Service();

...

l'inclusion (require_once ou équivalent) étant réalisé implictement par le mécanisme autoload lorsqu'il est activé comme suit :

function my_autoload($class)
{
    // My_Service => My/Service.php
    include str_replace('_', '/', $class) . '.php';
}

spl_autoload_register('my_autoload');

Cette méthode fonctionne bien jusqu'à PHP 5.2.x, mais n'est plus suffisante en PHP 5.3 avec l'arrivée des namespace (~ package), en effet, les namespaces permettent maintenant de créer officiellement des "packages" :

<?php

namespace My;

class Service
{
    // ...
}

qui s'utilise donc comme suit (par exemple) :

require_once 'My/Service.php';

$o = new \My\Service();

Nous devons donc améliorer le mécanisme d'autoload pour prendre en compte la nouvelle syntaxe pour les namespaces :

function my_autoload($class)
{
    /**
     * My_Service => My/Service.php
     * \My\Service => My/Service.php
     */
    include str_replace(
        array('_', '\'), '/', $class
    ) . '.php';
}

spl_autoload_register('my_autoload');

Notre autoload (simpliste) permet donc de prendre en compte les classes classiques (PHP <= 5.2) et les classes appartenant à des namespaces (PHP >= 5.3). Nous pouvons d'autre part améliorer légèrement notre autoloader pour utiliser une fonction anonyme et éviter ainsi les éventuelles collision de nommage avec des fonctions d'autoload portant le même nom, notre code devient alors :

<?php

spl_autoload_register(function($class) {
    include str_replace(
        array('_', '\'), '/', $class
    ) . '.php';
});

Et vous, quels sont vos implémentations d'autoloader en PHP 5.2 et 5.3 ?

" " : où comment afficher un compteur de lignes traités dans un batch, plutôt qu'un log volumineux

Olivier Hoareau — Mon, 26 Apr 2010 00:10:00 +0100

Vous avez un batch qui analysent des fichiers et qui affichent une ligne de log par fichier traités, voici une technique pour avoir un (fichier de) log moins volumineux

Habituellement, on fait souvent quelquechose de similaire à :

foreach($files as $file) {
    try {
        $this->processFile($file);
        echo "Fichier '$file' traité.
";
    } catch(Exception $e) {
        echo "Erreur de traitement du fichier '*file' : ".$e->getMessage()."
";
    }
}

Ce qui nous donne des logs du type :

Fichiers 'fichier1.csv' traité.
Fichiers 'fichier2.csv' traité.
Fichiers 'fichier3.csv' traité.
Fichiers 'fichier4.csv' traité.
Fichiers 'fichier5.csv' traité.
...
Fichiers 'fichier101.csv' traité.
Erreur de traitement du fichier 'fichier102.csv": mauvais format.
Fichiers 'fichier103.csv' traité.
Erreur de traitement du fichier 'fichier104.csv": mauvais format.
...

Ce log peut être volumineux si le nombre de fichier (ou d'élément à traiter) est important, si il n'est pas primordial d'avoir le nom du fichier traité mais juste un résumé des traitements, il est envisageable d'imprimer, en fin de traitement une ligne du type :

Fichiers analysés: 104, traités: 102, rejetés: 2

En utilisant par exemple le code :

$counters = array('success'=>0, 'errors'=>0);
//$errors = array();
foreach($files as $file) {
    try {
        $this->processFile($file);
        $counters['success']++;
    } catch(Exception $e) {
        $counters['errors']++;
        // on peut éventuellement stocker l'erreur dans un tableau pour l'afficher à la fin
        // $errors[] = $e;
    }
}
echo 'Fichiers analysés: '.($counters['success']+$counters['error']);
echo ', traités: '.$counters['success'].', rejetés: '.$counters['error']."
";

Cet affichage "résumé" peut être moins consommateur en terme de log et plus intéressant pour avoir un résumé, cependant si le "batch" prend beaucoup de temps à s'exécuter, nous devront attendre que l'ensemble des traitements soient terminés pour avoir cette ligne de résumé.
Une autre possibilité serait d'afficher "au fur et à mesure" l'avancement des traitements sous le même format en faisant évoluer les compteurs au fur et à mesure des traitements des lignes / fichiers :

$counters = array('success'=>0, 'errors'=>0);
//$errors = array();
foreach($files as $file) {
    try {
        $this->processFile($file);
        $counters['success']++;
    } catch(Exception $e) {
        $counters['errors']++;
        // on peut éventuellement stocker l'erreur dans un tableau pour l'afficher à la fin
        // $errors[] = $e;
    }
    echo "
                                                                           
";
    echo 'Fichiers analysés: '.($counters['success']+$counters['error'])
    echo ', traités: '.$counters['success'].', rejetés: '.$counters['error']."
";
}

A chaque fichier traité, la ligne de résumé sera "mise à jour" grâce au retour chariot ( ) et on verra évoluer les compteurs sur la même ligne.
Un des avantages est qu'on aura une information "temps réel" sur la vitesse d'exécution en voyant évoluer les compteurs.
On pourrait mettre à jour un compteur de "temps passé" et de nombre de fichiers traités par secondes assez aisément, toujours sur la même ligne.
Il est de plus envisageable de faire un dump des erreurs stockées à la fin du traitement (attention à leur volumétrie et à la mémoire vive nécessaire pour leur stockage).

Et vous comment réalisez vous des compteurs de traitements succinct et résumé ?

Batch : Attention à la mémoire vive

Olivier Hoareau — Thu, 22 Apr 2010 22:46:00 +0100

Le sujet des batch (en php) est assez récurrent dans le développement applicatif. On a souvent besoin de faire des scripts d'import, au hasard d'un catalogue de produits, par exemple.
Dans cette article je reviens sur une maladresse souvent implémentée dans les batchs et qui a un impact négatif sur les perfs et l'utilisation de la mémoire vive : le chargement de l'ensemble des données et l'utilisation du for(each).

// le fichier fait par exemple plus de 100.000 lignes ...
$lines = file('the-very-big-file-containing-my-product-catalog.csv');

$products = array();

foreach($lines as line) {
    $products[] = convertLineToProduct($line);
}

addProductsToDb($products);

et dans la fonction addProductsToDb ...

foreach($products as $product) {
    addProduct($product);
}

Ca vous rappelle des choses ?

Qu'y a-t-il de maladroit dans ce code ? Au moins deux choses :

l'ensemble des lignes du fichier est chargé en mémoire vive via la fonction file (notre fichier est gros... très gros...)
on effectue 2 fois la boucle sur les produits (à deux endroits du code, mais quand même)

Comment aurais-t-on pu faire autrement pour traiter ces deux points ?

$fp = fopen('the-very-big-file-containing-my-product-catalog.csv', 'r');
$i = 0;
while(!feof($fp)) {
    try {
        addProductToDb(convertLineToProduct(fgets($fp)));
    } catch (Exception $e) {
        echo 'Erreur ligne #'.$i."
";
    }
    $i++;
}
fclose($fp);

Dans cette version du code, un peu plus courte en plus ;) :

une seule ligne est stockée en mémoire vive à la fois
le fichier est traité ligne par ligne
si un problème survient à l'insertion dans notre base (pas à la lecture du fichier), on sait à quelle ligne du fichier l'import à planté

Et vous quelles techniques mettez vous en oeuvre pour traiter vos imports volumineux de données ?

Externaliser les messages d'erreurs des exceptions, pour les internationaliser, par exemple

Olivier Hoareau — Wed, 14 Apr 2010 23:53:00 +0100

Dans certains contexte, il est important de pouvoir fournir des messages d'erreurs dans différentes langues, par exemple en fonction de langue de l'utilisateur.
Parmi les sujets à mettre en oeuvre pour adresser ce point, les exceptions et leur messages sont à ne pas oublier, voici une technique que vous pouvez mettre en oeuvre.

Habituellement, on utilise les exceptions comme ceci :

    throw new RuntimeException("There was an error on user '" . $login . "'", 503);

ou alors :

    throw new MySpecificException("There was a specific error on user '" . $login . "'" , 503);

Imaginons que nous ayons une structure (que l'on pourrait mettre dans un fichier de "configuration" autonome bien entendu) comme ceci :

$messages = array(
    'fr-fr' => array(
        503 => "Une erreur spécifique a été détecté pour l'utilisateur '%s',
    ),
    'en-us' => array(
        503 => "There was a specific error on user '%s',
    ),
);

Imaginons que nous ayons une fonction i18n($code, $args) qui renvoie le message "internationalisé" en fonction de la langue utilisateur (je vous laisse développer votre méthode pour récupérer la langue de l'utilisateur et la mettre, par exemple dans une variable de session).

function i18n($code, $args)
{
    global $messages;
    // il est possible d'utiliser bien d'autre technique qu'une variable globale

    $lang = ... ; // mettez ici votre méthode pour récupérer la langue
    return call_user_func_array('sprintf', array_merge(array($message[$lang][$code]), $args));
}

Puis une classe d'exception spécifique :

class MySpecificException extends RuntimeException
{
    public function __construct()
    {
        $args = func_get_args();
        $code = array_shift($args);
        parent::__construct(i18n($code, $args), $code);
    }
}

Banco, nous pouvons maintenant utilisez nos exceptions comme ceci :

    throw new MySpecificException(503, $login);

Ainsi, nous n'avons plus besoin de mettre les messages de nos exceptions en dur dans notre code, nous pouvons les externaliser dans un fichier de paramétrage (au format PHP ou pas) et renvoyer le message internationalisé dans la langue de l'utilisateur.
Cette technique est bien entendu utilisable dans des applications web, mais aussi dans des batchs, des applications graphiques (en PHP)....

Et vous, comment faites vous pour externaliser vos messages d'erreurs et/ou d'exceptions ?

Interface ArrayAccess : où des objets que l'on utilise comme des array

Olivier Hoareau — Fri, 09 Apr 2010 22:26:00 +0100

Cette semaine j'ai fait découvrir l'interface ArrayAccess à un des développeurs Parisiens que je coache.
Cette fonctionnalité lui a permis d'appréhender facilement les tests unitaires sur du code legacy, je reviens sur cette "expérience"

Nous travaillons sur une application très populaire du grand public qui vend des produits High Tech, entre autres.
Cette application est en maintenance évolutive, avec de nouveaux développements plutôt réalisés en PHP.

Dans cette application il existe entre autres des objets "entités" qui représentent des "concepts" principalement stockées en base (on peut parler de quelque chose de similaire à un ORM pour le mapping Objet-Relationnel).
Nous avons une entité Product :

class Product
{
    protected $id;

    public function setId($id)
    {
        $this->id = $id;
    }
    public function getId()
    {
        return $this->id;
    }

    // ... plein d'autres propriétés du Product

    public function uneFonctionQuiFaitLeCafé()
    {
        // ....
    }
}

Notre entité est utilisée par une méthode d'une autre classe, qui liste des produits depuis la base et retourne une liste (array) d'objet Product.

Le problème dans notre cas est que nous souhaitions amener une démarche de tests unitaires type TDD (Test Driven Development ou Test-First) sur de nouveaux développements, mais que nous avions déjà pas mal de code, dont la classe Product, qui était déjà développé sans aucun test.
Notre démarche a donc été de créer une nouvelle classe pour la nouvelle méthode que nous souhaitions créer et de petit à petit porter le code existant dans cette classe au fur et à mesure que nous écrirons les tests unitaires.
Quand on adopte ce type de démarche (intéressante de mon point de vue), on met rapidement le doigt sur les zones existantes du code qui sont "dépendantes" d'autres classes / méthodes par encore testées, et très rapidement on peut être découragé car on tir un fil et c'est toute la pelotte qui vient avec...

Pour tenter de garder "espoir" dans cet effort de "portage" et couverture par les tests du code existant, une technique est de "bouchonner" le code existant qui ne nous intéresse pas (encore) grâce à un code / classe simulateur.
C'est à ce niveau que l'interface ArrayAccess peut s'avérer utile.

En effet, voici comment nous utilisons habituellement notre entité Product :

$product = new Product();
$product->setId(12);
$product->setPrice(25.12);
...
$description = $product->getDescription();

$product->uneFonctionQuiFaitLeCafé();
...

Si la méthode qui fait le café ne nous "intéresse" pas pour l'instant (ou que nous souhaitons la "sortir" de la classe Product in fine, et que pour l'instant nous décidons de ne pas travailler sur les tests de cette méthode), alors il ne nous reste plus que des "getters" et "setters" sur l'objet Product, et finalement que penseriez vous de ceci :

$product = new Product();
$product['id'] = 12;
$product['price'] = 25.12;
...
$description = $product['description'];

$product->uneFonctionQuiFaitLeCafé();
...

Il est en effet possible d'utiliser ce type de syntaxe si l'objet Product implémente l'interface (native) ArrayAccess :

class Product implements ArrayAccess
{
    protected $properties = array();

    public function setId($id)
    {
        return $this->offsetSet('id', $id);
    }
    public function getId()
    {
        return $this->offsetGet('id');
    }

    // ... plein d'autres propriétés du Product

    public function uneFonctionQuiFaitLeCafé()
    {
        // ....
    }

    // implémentation des méthodes "obligatoires" de l'interface ArrayAccess

    public function offsetSet($offset, $value)
    {
        $this->properties[$offset] = $value;
        return $value;
    }

    public function offsetExists($offset)
    {
        return isset($this->properties[$offset]);
    }

    public function offsetUnset($offset)
    {
        unset($this->properties[$offset]);
    }

    public function offsetGet($offset)
    {
        return isset($this->properties[$offset]) ? $this->properties[$offset] : null;
    }
}

Imaginons maintenant que nous nous passions par une "factory" pour créer de nouvelles entités Product :

// on ne fait plus new Product() mais :

$product = createABlankProduct();
...

Imaginons que nous ne travaillons pas encore sur la méthode qui fait le café mais uniquement que sur les données stockées dans l'entité, à savoir que nous souhaitons tester unitairement une méthode qui "crée" une liste d'entité produit à partir de données en base, c'est à dire qu'elle "rempli" des entités avec les valeurs selon une certaine logique :

/**
 * @return array of Product
 */
public function listProductByUniversAndPriceInterval($univers, $minPrice, $maxPrice)
{
    // ... sélection des données en base de données via PDO, par exemple, triée dans l'ordre de prix
    $productsData = $this->listRawProductsDataByUniversAndPriceInterval($univers, $minPrice, $maxPrice);
    // ...
    $products = array();
    foreach($productsData as $rank => $row) {
        $product = $this->createABlankProduct();
        $product['id'] = (int)$row['id'];
        $product['price'] = (double)$row['price'];
        $product['universe'] = $univers;
        $product['rank'] = $rank + 1;
        // ... 
        $products[] = $product;
    }
    return $products;
}

Imaginons maintenant que la creation d'un "blank product" et la récupération des données brutes de la base soient déléguées à un objet "adapter" (i.e. délégué de la classe courante) :

        $productsData = $this->getAdapter()->listRawProductsDataByUniversAndPriceInterval($univers, $minPrice, $maxPrice);
        ...
        $product = $this->getAdapter()->createABlankProduct();
        ...

Imaginons que la classe courante propose un "setter" qui permette de "changer" l'objet adapter courant :

    public function setAdapter(MySpecificAdapterInterface $adapter)
    {
        $this->adapter = $adapter;
        return $this;
    }

Nous avons donc un objet qui doit implémenter l'interface MySpecificAdapterInterface et qui doit donc implémenter une méthode createABlankProduct() qui doit renvoyer une structure qui doit être accessible via la notation array (pour l'instant nous n'utilisons pas la méthode qui fait le café) :

class MySpecificAdapterStandardVersion implements MySpecificAdapterInterface
{
    public function createABlankProduct()
    {
        return new Product();
    }
    public function listRawProductsDataByUniversAndPriceInterval($univers, $minPrice, $maxPrice)
    {
        // faite ce que vous faisiez avant pour récupérer les données brutes en base ici
        // ...
        return $rows;
    }
}

Imaginons maintenant que nous ayons une version "simulateur" de notre adapter qui l'on pourrait paramétrer pour lui indiquer ce qu'elle doit retourner lorsqu'on appelle une de ces 2 méthodes :

class MySpecificAdapterMockVersion implements MySpecificAdapterInterface
{
    protected $expectedResult;

    public function createABlankProduct()
    {
        return array();
    }
    public function setExpectedResult($result)
    {
        $this->expectedResult = $result;
        return $this;
    }

    public function listRawProductsDataByUniversAndPriceInterval($univers, $minPrice, $maxPrice)
    {
        return $this->expectedResult;
    }
}

Ainsi dans nos tests unitaires nous pourrons facilement "tester" la méthode listProductByUniversAndPriceInterval :

class MyClassTest extends PHPUnit_Framework_TestCase
{
    public function testListProductByUniversAndPriceIntervalForExistingProductsInDatabaseReturnProductList()
    {
        $mock = new MySpecificAdapterMockVersion();
        $objectToTest = new MyClass();
        $objectToTest->setAdapter($mock);
        $mock->setExpectedResult(array(
            array('id'=>10, 'price'=>"11.99"),
            array('id'=>4, 'price'=>"15.99"),
            array('id'=>7, 'price'=>"27.99"),
        ));
        $products = $objectToTest->listProductByUniversAndPriceInterval('games', 10.0, 30.0);

        // vérification des données du 1er produit

        $this->assertEquals(11.99, $products[0]['price']);
        $this->assertEquals(1, $products[0]['rank']);
        $this->assertEquals(10, $products[0]['id']);
        $this->assertEquals('games', $products[0]['univers']);

        // vérification des données du 2ème produit

        $this->assertEquals(15.99, $products[1]['price']);
        $this->assertEquals(2, $products[1]['rank']);
        $this->assertEquals(4, $products[1]['id']);
        $this->assertEquals('games', $products[1]['univers']);

        // vérification des données du 3ème produit

        $this->assertEquals(27.99, $products[2]['price']);
        $this->assertEquals(3, $products[2]['rank']);
        $this->assertEquals(7, $products[2]['id']);
        $this->assertEquals('games', $products[2]['univers']);
    }
}

Grâce à l'utilisation de array() et de l'adapter mock, dans un premier temps, nous pouvons donc tester facilement la logique de la méthode listProductByUniversAndPriceInterval() sans devoir "porter" tout l'objet Product (qui vient de notre code legacy).
Maintenant que nous avons portez cette première méthode (voire d'autres), si nous avons besoin de porter d'autres méthodes "qui font le café" de l'entité product nous pouvons alors utiliser l'implémentation de l'interface ArrayAccess présenté au début et les tests unitaires et le contenu de la méthode déjà développé reste toujours valable, à savoir le fait d'utiliser un objet plutôt qu'un array n'a pas d'impact sur le code de la méthode listProductByUniversAndPriceInterval() car notre objet implémente l'interface ArrayAccess qui permet de l'utiliser, quand cela nous intéresse, comme un array() avec des crochets.

En conclusion, nous pouvons retenir que l'utilisation de l'interface ArrayAccess peut nous permettre de commencer à travailler avec des structures de types array() notamment pour introduire des tests unitaires, puis de migrer sans douleur vers une structure plutôt objet qui sera enrichie par des méthodes "qui font le café" mais qui restera compatible avec la notation array()

Et vous, dans quels cas utilisez-vous, ou non, l'interface ArrayAccess ?

Comment maîtriser la montée de version d'un framework dont votre application dépend ?

Olivier Hoareau — Sat, 27 Mar 2010 21:05:00 +0000

Vous utilisez très certainement un ou plusieurs framework comme fondations de votre projet / application (Symfony, Zend Framework, CakePHP...). Une des premières évolutions majeures (d'un point de vue technique, mais pas fonctionnel) consiste en la montée de version des frameworks dont vous dépendez. ...

En effet, les frameworks comme Zend Framework ou Symfony (entre autres) évoluent très vite et de nouvelles fonctionnalités voient le jour très régulièrement. Vous pourriez être intéressés par utiliser la nouvelles version (ou une version plus récente que la version) d'un de vos frameworks, cependant qu'est-ce qui garantie que votre application continuera à fonctionner ?

Réponse: les tests unitaires et l'include path.

En effet, les tests unitaires nous permettent de construire petit à petit notre application et de vérifier la non régression aux cours des évolutions. Il est donc très facile d'exécuter les tests unitaires de votre application (si ils existent) en utilisant des versions différentes de votre framework. Pour cela il vous suffit de modifier l'include path.

installez la version actuelle (utilisée par votre application) du framework dans le répertoire c:/dev/framework/v1
installez la version plus récente du framework dans le répertoire c:/dev/framework/v2
modifiez la directive include_path (dans le php.ini) pour y ajouter c:/dev/framework/v1
exécutez vos tests unitaires

Il est tout à fait envisageable d'automatiser l'exécution des tests unitaires sur différentes versions du framework si vous utilisez par exemple un serveur d'intégration continue. Ainsi vous pouvez créer un "job" (ou projet selon les outils d'intégration continue) par version de framework et déclencher l'exécution du "build" suite à un commit sur votre outil de gestion de version (i.e. SVN ou Git...), ainsi vous saurez en temps réel quels tests unitaires ne passent pas avec la nouvelle version du framework.

Je vous conseille très fortement de mettre en place cette technique, à minima quelques temps avant de faire la migration, et au mieux dès le début ou la sortie d'une version plus récente de la librairie que vous utilisez.

Bien sûr, il faut relativiser l'intérêt de cette technique qui devient totalement inutile si vous n'avez pas de tests unitaires ou si la couverture des tests est non significative (< 90%), il faudra donc travailler d'abord à cette couverture, avant de pouvoir tirer partie de cette technique. Vous pourrez cependant commencer par implémenter les tests unitaires liés aux fonctionnalités basées sur des composants connus pour avoir évolué dans les nouvelles versions du framework.

Il existe bien entendu d'autres techniques utiles pour vérifier la compatibilité avec de nouvelles versions de frameworks, mais celle-ci est très facile à mettre en oeuvre si vous avez déjà des tests unitaires.

Et vous quels sont vos techniques pour maîtriser les montées de versions des frameworks dont vous dépendez ?

Magento demystified : global picture de la séquence d'exécution d'une requête Magento

Olivier Hoareau — Wed, 24 Mar 2010 09:00:00 +0000

Ces 6 derniers mois, j'ai fait pas mal de R&D autour du produit Magento.
Je ne vous livre pas ici mes convictions sur le produits, mais juste une cartographie globale de la séquence d'exécution d'une requête Magento.

(Analyse basée sur la version Magento Community Edition 1.3.2.4, qui n'est pas toute récente et qui date de 2009)

Don't reinvent the wheel ... invent the car !

Olivier Hoareau — Sat, 20 Mar 2010 23:57:00 +0000

Vous avez déjà croisé des projets / équipes qui décident d'utiliser le dernier framework en vogue ? oui, certainement.
Par contre avez-vous déjà croisé des projets / équipes qui décident d'en changer (de framework) car ils se rendent compte que le choix n'est plus forcément pertinent ou le plus meilleur ? moi, non, pourtant c'est bien connu le la version parfaite d'un framework sur tous les sujets et ad vitam eternam n'existe pas...

J'entends souvent :

nous on fait du MVC
nous on fait du design pattern
nous on utilise des adapters
nous on utilise des couches d'abstraction
nous on utilise certains composant du framework X
...
nous <whatever the generic term you want here>

Mais quand on creuse, on se rend compte qu'il fallait plutôt entendre :

"nous notre application est fortement couplée au / motorisée par le framework X"
"nous on utilise l'implémentation MVC du framework X"
"nous on utilise certaines implémentations de certains designs patterns proposés par le framework X"
"nous on aimerait bien utiliser le composant XYZ du framework X mais on sait pas comment ca pourrait nous être utile concrètement"
"nous on comprend pas tout dans le framework X mais il parait que c'est bien alors on l'utilise"
"nous on utilise le mécanisme d'abstraction du composant W du framework X"
"nous on met notre code dans un fichier Controller.php en utilisant les helpers et les vues du framework X"
...
nous <whatever the framework-specific implementation you want here>

Et les 40 lignes de code dans la méthode indexAction() ca vous rappelle quelque chose ?
Et les X heures / jours / semaines passés à se demander quand et comment on va faire pour migrer tout notre code application de la version 1.5.3 du framework X vers la toute nouvelle version 2.0.0 qui déchire et qui n'est plus totalement compatible sur bien des aspects mais tout le monde dit qu'il faut l'utiliser, ca ne vous rappelle pas quelque chose ?
Et la complexité intrinsèque de l'architecture et design patterns des composants du framework X que vous vous "obligez" à utiliser parce que tout le monde dit que maintenant c'est comme et c'est pas autrement en PHP, ca ne vous rappelle pas quelque chose ? Vous êtes certainement comme moi, développeur, fier de montrer que je utiliser la nouvelle version du dernier framework à la mode sur mon projet. Mais pour les 10 autres projets sur lesquels mes collègues travaillent, tout le monde ne sera peut être pas aussi enthousiaste de perdre 1 semaine ou 2 semaine de développement pour réécrire tous les "controller" et retranscrire tous les "formulaires" avec le dernier composant à la mode...

Plus concrètement mon point de vue est le suivant :

"re-" développer ce que d'autres on déjà développé, rendu mature et éprouvé, c'est bof
les designs patterns c'est bien
les frameworks c'est (presque) bien aussi

mais :

utiliser un design pattern sans le comprendre c'est moins bien
utiliser un framework sans comprendre les "problématiques" sous-jacentes auquel il répond c'est encore moins bien (j'ai pas dit "c'est mal", mais j'aurais pu...)
insérer 5 (ou 10, 50 ou 100 ...) lignes de code "spécifique framework X" pour implémenter un composant XYZ du framework X sans le cloisonner en dehors de votre code applicatif / métier ... ca c'est mal !

Pourquoi être "trop / très" couplé avec un framework c'est mal ? (d'après moi)

"Moi, oui, je mélange les choux et les carottes"

Un framework c'est souvent technique, votre logique applicative elle est souvent plutôt métier / fonctionnelle, le framework évoluera il faudra faire un effort pour savoir quel ligne concerne le framework et quelle ligne concerne de la logique métier invariante, cela peut être long

"Moi, oui, j'ai peur de monter de version de framework"

Un framework c'est souvent imparfait, en perpétuel évolution (surtout les Open Source, pour notre grand bonheur), donc souvent 3 mois après avoir implémenté la dernière version, une nouvelle version sort et vous êtes tiraillé entre migrer au bout de 6-9 mois vers cette version ou ... tout réécrire votre application en v2 ! Pourquoi attendre 6-9 mois ? Pourquoi réécrire la logique métier de l'application alors qu'en 6-9 mois votre fonctionnel / métier n'a pas forcément évolué tant que ça, lui ?

"Moi, je suis certifié framework X, je sais bien l'utiliser, je connais tous les composants, et je développe toutes mes applis avec"

Et votre collègue aussi il connait aussi "parfaitement" ce truc si génial ? Et lui aussi il sait "bien" l'utiliser ? Et lui aussi il a compris tous les concepts complexes de patterns qui y sont implémentés ? Non ? Donc il a besoin de vous ? Oui ! Bravo, vous avez trouvé un moyen de ne pas vous faire virer, par contre pour ce qui est de la maintenabilité (i.e. par quelqu'un qui n'a pas vos connaissances), la simplicité (pour quelqu'un qui veut aller droit à la solution technique la plus simple pour répondre aux besoins) c'est peut être moins rose...

"Moi je fais des DAO et j'ai une couche d'abstraction de la base de données avec modélisation de mes tables en classe..."

Et si votre source de données changent et vous fusionnez 2 tables en une ou scinder 1 table en 2 ? Si vous décidez de stocker via l'appel de webservices plutôt que dans une base locale ? Si vous changez de moteur de base de données (mysql => oracle, sqlite => mysql, mysql => sql server...), vous êtes sûr que votre couche d'abstraction sera si parfaite que ça ? Nous c'est vrai, à vous ca ne vous arrivera pas tout ça...

"Moi, j'utilise a fond les composants du framework X, de toute façon il est bien fait, ca ne peut qu'être bon pour moi"

Pensez-vous sincèrement que ce soit la qualité du framework ou la qualité de "l'usage" que vous en avez qui garantira maintenabilité / évolutivité / robustesse / performance / ... ? Personnellement, je ne parierai pas QUE sur la qualité du framework...

Pour conclure, je dirais que les frameworks c'est bien, mais maîtriser l'usage que l'on a des frameworks et être conscient que l'ON DEVELOPPE DU CODE pour mettre en vie le framework c'est beaucoup mieux... De nos jours, il n'est plus question de "réinventer" la façon d'implémenter tel ou tel design pattern (i.e. "la roue / the wheel" dans mon analogie) mais plutôt d'"inventer" le code applicatif et la façon dont tout ça va se mettre en jeu pour rendre une application fonctionnelle ET UTILE (i.e. "la voiture / the car"), ne perdez pas de vue, que comme des ingrédients et ustensiles pour faire un gâteau en cuisine, un framework reste un socle / outil / matériel, mais la réussite finale du gâteau (i.e. de l'appli) dépend du cuisinier (le développeur) et de sa capacité à être rigoureux, organisé, méthododiques, homogène, rationnel...

Les frameworks, c'est bon ! mangez-en, mais sans que ça se voit !

Retour d'expérience sur les métriques qualité d'une application Symfony d'un de mes clients

Olivier Hoareau — Sat, 20 Mar 2010 09:11:00 +0000

En novembre dernier je suis intervenu chez un client pour améliorer les pratiques de développements sur une application basée sur Symfony.
A cette occasion j'ai réalisé un audit de l'application, voici quelques métriques à noter sur cette application (il ne s'agit ni d'une tendance ni d'une moyenne, je vous livre ici les métriques brutes pour que vous puissiez comparer).

Il est à noter que le développement était relativement "habituel" pour du code applicatif Symfony, même si de nombreuses amélioration ont été envisagée par la suite dans la pratique lié au développement et notamment pour la maintenance et la réutilisabilité.

Et vous quelles sont les valeurs habituelles de métriques qualité que vous rencontrez sur vos différents projets ? (Symfony ou autre)

Marathon de l'industrialisation : où comment outiller vos troupes en les motivant

Olivier Hoareau — Sat, 13 Mar 2010 09:00:00 +0000

Depuis quelques temps j'ai mis en place une activité spéciale que je propose à mes clients : Le Marathon de l'Industrialisation.

L'idée: focaliser toute l'équipe de développement au même moment sur un temps court, pour améliorer significativement les pratiques, et ce grâce à l'adoption de nouveaux (variable en fonction des clients) outils et techniques de développement. Je vous livre ici un de mes supports utilisé en Juin 2009 chez un de mes clients.

Marathon De L Industrialisation

View more presentations from PHPPRO.

Modèle PDF : où comment éviter de perdre son temps

Olivier Hoareau — Wed, 10 Mar 2010 22:49:00 +0000

Chez nombre de mes clients la "génération de PDF" est un vrai sujet / enjeux. Mais que veux-t-on vraiment générer ?

Dans nos applications, on doit souvent générer des PDF :

pour fournir une preuve / un récapitulatif (imprimable)
pour transmettre une pièce justificative à un tiers
pour archivage
...

Il est très souvent hors de question d'afficher des données brutes dans un PDF, l'entreprise à une identité visuelle, le PDF doit forcément la respecter.
On se retrouve donc très très souvent à devoir fricoter avec le sujet des chartes graphiques, du design et autres images et couleurs dans nos PDF.

Dans un nombre non négligeable de cas (ce n'est pas tout le temps vrai, mais souvent quand même), nous souhaitons formater un ensemble de type de données connues dans un format plus lisible via le PDF.
Voici ce que nous "maitrisons" :

la charte graphique attendue (le gabarit, ...)
la liste des données à formater
l'emplacement des données, leur taille maximum et leur style graphique (police, taille, couleur...)

En dehors des données que nous n'avons pas à l'avance (celles qui arrivent au moment de la génération), il peut (dans un grand nombre de cas) être envisageable de créer un "modèle" de document (i.e. PDF) vide de toutes données (en tout cas celles qui sont dynamiques), et utiliser pour cela nos bons vieux logiciels de design graphique (ou équivalent), par exemple ... Word ;) ou OpenOffice Writer (il y a mieux, mais vous serez surpris de la facilité déconcertante à créer des documents au format A4 pour ce type de besoin avec word ou ooo writer), si vous utilisez une ancienne version de Word, un bon vieux PDFCreator (plugin gratuit pour windows) vous permettra d'"imprimer" le document au format PDF.
Nous reviendrons plus tard sur l'intérêt d'utiliser des outils bureautiques pour la génération du modèle.

Une fois votre "modèle" disponible, il devient du coup tout de suite envisageable de le "remplir" avec les données dynamiques, on peut concevoir que cela est infiniment plus simple à réaliser que de créer l'ensemble du document PDF avec Zend_PDF ou autre qui fournissent uniquement que des primitives graphiques (dessiner une ligne, un rond, une image, du texte...).
Vous conviendrez que placer du texte ou une image d'une certaine taille à un certain endroit (positionnement absolu) est relativement simple avec n'importe quelle librairie PDF PHP.

Du coup, pourquoi ne pas "décrire" le positionnement des données sur le document PDF dans un format moins "technique" que des instructions PHP ? On pourrait avoir par exemple une description XML du type :

<document>
	<styles>
		<font id="default" family="Helvetica" bold="true" size="10"/>
	</styles>
	<pages>
		<page number="0">
			<!-- numéro de dossier -->
			<text top="670" left="260">100001001</text>
			<!-- nom / prénom -->
			<text top="604" left="180">Hoareau, Olivier</text>
			<!-- titre / civilité -->
			<text top="588" left="180">M.</text>
			<!-- date de naissance -->
			<text top="572" left="180">07/12/1901</text>
			<!-- adresse -->
			<text top="505" left="70">8, rue de la colline
33540 GRADIGNAN
France</text>
			<!-- mobile -->
			<text top="395" left="180">0601020304</text>
			<!-- email -->
			<text top="380" left="180">olivier@phppro.fr</text>
			<!-- optionnel: statut -->
			<image top="650" left="390" width="190" height="109" file="refus.png"/>
		</page>
	</pages>
</document>

Grâce à SimpleXML et à, par exemple, Zend_PDF, il est très facile en quelques lignes de code de "dessiner" les éléments text et image définis dans la description xml sur un PDF existant (Zend_PDF permet de charger un PDF existant et de le modifier, ce que ne permettent pas toutes les librairies PDF, c'est une fonctionnalité essentielle dans cette technique).

Pour permettre une génération avec des données dynamiques, on peut très bien imaginer la génération à la volée de la description xml à partir de données de la base de données via PHP/MySQL par exemple. Il devient ainsi tout à fait envisageable de créer une "vue" (voir Pattern MVC) qui contient un modèle dynamique de la description xml :

<?php

echo '<?xml version="1.0" encoding="UTF-8" ?>'."
";
?>

<document>
	<styles>
		<font id="default" family="Helvetica" bold="true" size="10"/>
	</styles>
	<pages>
		<page number="0">
			<!-- numéro de dossier -->
			<text top="670" left="260"><?php echo $this->dossier ?></text>
			<!-- nom / prénom -->
			<text top="604" left="180"><?php echo strtoupper($this->nom) ?>, <?php echo ucfirst($this->prenom) ?></text>
			<!-- titre / civilité -->
			<text top="588" left="180"><?php echo strtoupper($this->titre) ?></text>
			<!-- date de naissance -->
			<text top="572" left="180"><?php echo $this->dateNaissance ?></text>
			<!-- adresse -->
			<text top="505" left="70"><?php echo $this->adresse . "
" . $this->codePostal . " " . strtoupper($this->ville) . "
" . strtoupper($this->paysLogement) ?></text>
			<!-- mobile -->
			<text top="395" left="180"><?php echo $this->mobile?></text>
			<!-- email -->
			<text top="380" left="180"><?php echo $this->email?></text>
			<!-- adresse logement -->
			<text top="305" left="70"><?php echo $this->adresseLogement . "
" . $this->codePostalLogement . " " . strtoupper($this->villeLogement) . "
" . strtoupper($this->paysLogement)?></text>
			<!-- optionnel: statut -->
			<required property="statut">
				<image top="650" left="390" width="190" height="109" file="<?php echo dirname(__FILE__).'/images/'.($this->statut==='refusé' ? 'ko' : ($this->statut==='accepté' ? 'ok' : 'unknown')).'.png' ?>"/>
			</required>
		</page>
		<page>
			<text top="400" left="300">Bonjour !</text>
			<text top="600" left="200">Hello <?php echo strtoupper($this->nom)?> !</text>
		</page>
	</pages>
</document>

Vous noterez au passage, la possibilité d'ajouter des pages sur un pdf, en rajoutant tout simplement des balises <page>, si la page n'existe pas dans le pdf, il est envisageable de la créer à la volée.

En résumé, il peut être très intéressant d'"enrichir" un fichier PDF existant avec des données plutôt que de créer le fichier PDF depuis zéro avec la même librairie.
Enfin, revenons un peu sur "la création avec word (and Co.)" du modèle. Pourquoi utiliser un logiciel "bureautique" pour créer le modèle ? Pour le faire faire par les autres ! Si vous êtes développeur, vous n'êtes pas graphiste (certains le sont, pas la majorité loin de là), laissez le travail de création graphique à des spécialistes, voir à des fonctionnels qui savent ce qu'ils souhaitent (et surtout qui passeront du temps à positionner les éléments, à faire des compromis, à changer les couleurs...).

Et vous quels sont vos techniques pour générer du PDF ? Vous passez par du HTML/CSS ? Quelles sont vos douleurs ?

Bonus: faire des tests unitaires sur du XML, c'est très très facile, pensez-y quand vous souhaiterez faire des tests (unitaires) sur vos PDF...

Entretien avec un développeur et un chef de projet

Olivier Hoareau — Sat, 06 Mar 2010 21:11:00 +0000

Voici le déroulé d'un entretien que j'ai animé en fin d'année dernière dans une petite entreprise qui fait du développement Symfony.
Mon objectif était de comprendre leurs pratiques (de développement), les outils qu'ils utilisent et surtout d'avoir leur ressenti sur leur niveau d'industrialisation et les problèmes qu'ils rencontrent.
Cet entretien téléphonique m'a permi de bien préparé la journée "marathon" d'industrialisation que j'ai effectuée chez eux le lendemain.

A quel systèmes d'exploitation êtes vous confrontés (et sur quels environnements) ?

Donnez-moi dans votre quotidien la part de (en 1/4, 1/3, 1/2):
- développement
- tâches techniques
- réunions
- autres

Quelle est l'activité qui vous prend le plus de temps au quotidien ?

Citez moi les 3 logiciels que vous utilisez le plus au quotidien (notamment pour le développement)

Décrivez moi en quelques mots l'utilité des applications symfony que vous développez

Quelles sont vos douleurs actuellement pour mener à bien vos activités: ce qui vous fait perdre du temps en dev, en déploiement en prod...

Ou en êtes vous dans la roadmap produit (début, milieu, fin) ?

Votre sentiment sur la qualité du produit (d'abord du service rendu à vos clients, ensuite du code) ?

Votre niveau de connaissance dans le framework Symfony:
- 0 = on fait faire les développements par d'autres
- 1 = on fait en cherchant systématiquement dans la doc/internet
- 2 = on connait pas encore tous les concepts mais globalement on s'en sort sans perdre trop de temps
- 3 = on est experts

Décrivez moi comment vous vous y prenez pour : corriger un bug détecté en production, développer une nouvelle fonctionnalité planifiée, fournir le même service à un nouveau client

Quelles opérations à réaliser pour mettre en production (depuis un dev jusqu'à l'utilisation possible par un client en production ) ?

Donnez moi la liste des 5 ou 10 commandes en ligne de commande que vous utilisez le plus au quotidien

Quels sont les outils que vous avez envie d'utiliser et que n'utilisez pas encore ?

Quels sont les outils que vous ne voulez pas utiliser, ou que vous fuyez volontairement ?

Si vous deviez utiliser un outil pour les tests unitaires ce serait ? OK pour utiliser PHPUnit pour les tests unitaires ?

Si vous deviez utiliser un outil pour le déploiement ce serait ? OK pour utiliser Phing pour le package et le déploiement, plutôt que les outils SF (trop liés à SF ?)

Qu'attendez vous de mon intervention ?

Questions adressées au Patron

Quelles sont les douleurs actuellement ?
Où en êtes-vous dans la roadmap produit ?
Votre sentiment sur la qualité du produit (d'abord du service rendu à vos clients, ensuite du code) ?
Qelles sont les prochains grand axes d'évolutions ?
Quid du besoin d'exposer des services web dans le futur ?
Votre position par rapport à l'ajax ou a flash / flex ?

Et vous comment menez-vous des entretiens de début de mission avec vos clients ? avez-vous d'autres pratiques pour appréhender le contexte ?

Le Mode Hébergé (ou Application Service Provider) : où comment changer le business model de votre client

Olivier Hoareau — Wed, 03 Mar 2010 09:00:00 +0000

J'ai récemment répondu à un appel d'offres concernant la conception et le développement d'une base de données centralisée sur des données géographiques, je livre ici quelques pensées et remarques liées à cette réponse

Mon (futur) client est un organisme qui réalise des cartographie de population.
Il utilise des données géographiques pour faire des filtrage, aggregation, recoupement et cartographie tout ceci est avec un SIG type ArcView.

Récemment il a décidé de s'outiller un peu plus car il travaille malheureusement encore avec Access, entre autres, pour faire ses traitements et les fichiers de données peuvent atteindre 5 millions de lignes...

Il s'est dit que monter une vraie base de données serait peut être plus qu'intéressant pour lui.
J'ai donc tout naturellement pensé au couple PHP/MySQL pour créer une application simple d'emploi qui propose un formulaire non technique (liste déroulante) de sélection/filtrage qui traduit et génère une requête SQL complexe.

Qui dit PHP et MySQL dit serveur, idéalement pas sur un poste bureautique, surtout quand les traitements d'insertion en base doivent travailler sur 5 millions de lignes.
Cette structure n'étant pas spécialisé dans l'informatique, l'hébergement d'un serveur (qui aurait été sous Windows 2003 pour sur...) aurait dû être nécessaire sur site (pas d'informaticien de métier sur place a priori) avec les SLA que vous pouvez imaginer (non acceptable...).
J'ai donc tout naturellement pensé à l'hébergement de cette application sur un (en fait plusieurs) serveurs dédiés en location chez un hébergeur populaire sur le marché.
Jusque là, rien d'extraordinaire.

Et bien si, en fait cela change tout pour mon client.
En effet, jusqu'alors les traitements étaient fait chez lui et donc utilisables par lui et ses collègues uniquement, mais il se trouve que ce type de traitement est réalisé par d'autres structures (pas vraiment concurrente mais travaillant sur des périmètre géographique différents), mais sur les mêmes données (c'est pour ça que ca fait 5 millions de lignes).
Si l'application est disponible via internet, mon client peut aisément y accéder depuis ses locaux ou en mobilité, mais ses partenaires et homologues aussi !
Le budget que mon client va dépenser pour la réalisation de cette application peut probablement être financé pour partie par une location qu'il proposerait à ses partenaires et homologues (évolution fonctionnelle pour eux qui pourront accéder plus régulièrement à l'information traitées et même faire baisser leur coût car ils n'auront plus à réaliser eux mêmes certaines de ces opérations).

Si mon client avait choisi la solution "serveur interne", il aurait eu plus de difficulté à "monétiser" ce service auprès de ces partenaires (problème de garantie de disponiblité de service et surtout d'accès puisqu'il faudrait adresse ip fixe et tout le toutim dans ces locaux, ce qui n'est pas impossible soit...). Autre détails non négligeables, l'insertion des données peut prendre plusieurs heures, voire plus et la volumétrie est historisée tous les ans, ce qui peut engendrer de gros volumes (plusieurs dizaines de millions de lignes), et la capacité à passer de 1 à 2 puis 3 puis n serveurs (en passant sur Amazone EC2 ou autres) est un plus indéniable qui lui aurait couté beaucoup plus cher en interne et qui aurait été beaucoup moins réaliste (ou stocker ces serveurs ?).

Pour les internautes avides de techniques, voici quelques schémas sur ma réponse (anonymisé), il s'agit d'une architecture relativement simple, le contexte n'en impose pas de plus compliqué à priori.

Le reverse proxy sera réalisé par HAProxy, qui est libre et très performant
La réplication de la base de données sur le serveur de sauvegarde par l'intermédiaire du mode réplication (simple) de MySQL.

Un mécanisme de plugin pour l'import et l'export sera mis en place pour permettre d'ajouter de nouvelles sources de données (i.e. formats de fichier, url http...), et d'exporter dans des formats facilitant l'intégration et permettant de faire gagner du temps (pourquoi pas ArcView, PDF, ...)

Vos questions / remarques / retours d'expériences sur des problématiques similaires sont bien entendus les bienvenus !

Complémentarité PHPUnderControl / Phing

Olivier Hoareau — Sun, 28 Feb 2010 22:56:00 +0000

Suite à une demande d'un internaute, j'explique la complémentarité entre PHPUnderControl et Phing

PHPUnderControl

PHPUnderControl est un version adaptée pour PHP de l'outil open source CruiseControl qui est un logiciel serveur d'intégration continue développé en Java et initiallement pour la technologie Java (i.e. pour gérer des projets écrit en Java).
L'adaptation de PHPUnderControl consiste en la mise à disposition d'une IHM un peu plus contextualisée pour PHP avec des graphiques de métriques qualité récupérés depuis les outils disponibles avec PHP (phpunit notamment).

Le principe de ce type de logiciel est de détecter des modifications dans un dépôt de code distant (par exemple un serveur Subversion - SVN) et de déclencher une commande suite à cette détection de modification. Il s'agit donc d'un espèce de méga-ordonnanceur qui est bête et méchant et ne sait finalement que "déclencher" des commandes sur des "stimuli" prédéfinis (i.e. la détection d'un commit sur SVN).

Phing

Phing est un port du logiciel Ant qui provient du monde Java. Ant est un outil pour écrire des scripts batchs en XML, les rendant ainsi multi-plateformes. Il n'est plus nécessaire de se soucier du format .bat de windows ou .sh des linux-like, les commandes sont écrites en XML : on dispose par exemple de balises mkdir, copy, tar... et il est possible de créer ses propres balises de commande (task) voir ses propres séquences de commandes (target).
Phing est l'implémentation full-PHP de Ant, c'est à dire qu'il suit le même principe, met à disposition globalement les mêmes commandes selon la même syntaxe, mais l'implémentation est réalisée en PHP et est extensible en PHP. Il se base sur l'écriture d'un fichier de commandes nommés build.xml qu'il est coutume de mettre à la racine de votre projet (à subversionner) et qui doit contenir l'ensemble des commandes dont vous avez besoin pour gérer le code de votre projet (lancer les tests, packager le code, déployer le code, qualifier le code...)

PHPUnderControl + Phing et non PHPUnderControl = Phing

Phing est donc un moyen de décrire la ou les commandes à exécuter suite à un stimuli détecter par PHPUnderControl. PHPUnderControl est "compatible" phing en standard ce qui permet de décrire/configurer facilement l'exécution de commande phing dans le fichier de configuration de PHPUnderControl (config.xml). Cependant, même si cette intégration n'existait pas, l'exécution d'une commande phing consiste en faite en l'exécution de la commande shell phing suivi des quelques paramètres, ce qui permet d'intégrer cet outils avec n'importe quel logiciel ordonnanceur, même les tâches planifiées windows.

PHPUnderControl et Phing sont donc complémentaires mais indépendant et autonomes.

Bien sûr il est possible de remplacer PHPUnderControl par un autre logiciel du même type (Hudson, Xinc, Continuum, ...), ainsi que Phing (makefile, shell script, script bat, ...)

Pour obtenir plus de documentation, voici quelques liens :

PHPUnderControl : http://phpundercontrol.sourceforge.net
Phing : http://phing.info
CruiseControl : http://www.cruisecontrol.net
PHPUnit : http://www.phpunit.de

Avez-vous des questions complémentaires ou des remarques ?
Et vous, comment utilisez vous PHPUnderControl et Phing ? Avez-vous des exemples de build.xml que vous utilisez régulièrement ?

Les frameworks c'est bien, développer "en dehors" c'est mieux

Olivier Hoareau — Sat, 27 Feb 2010 09:00:00 +0000

J'explique mon point de vue sur les frameworks et sur une erreur (de mon point de vue) qui coute cher aux entreprises...

Les frameworks c'est génial :

en 1 minute on a une application "vierge" super pro qui se connecte à notre base de données
en 2 minutes je rajoute un écran sur mon appli
en 3 minutes je rajoute un web service
en 4 minutes je rajoute un mécanisme d'authentification SSO avec le plugin tartanpion
...

ok ?

On oublie aussi :

en 2 mois j'apprends à coder AVEC le framework (i.e. maintenable, performant, ...)
en 3 mois je réalise la migration de la v1.9 du framework à la v2.0 (ca fait mal hein ?)
au bout de 4 mois je comprends vraiment comment ca marche et que je n'aurais pas développé telle classe comme ça si j'avais su avant :(
...

toujours ok ?

Une erreur (ce n'est que mon point de vue) courante que je rencontre sur "le terrain" (i.e. chez mes clients), est l'inconditionnelle mixage entre du code applicatif (i.e. développé par vous) et du code technique (contraint par le framework).
On se retrouve alors souvent à avoir des classes MyPluginSpecificForZF par ci ou sfMonPluginParLa ... qui contient du code que vous développez qui se connecte à la base de données fait des traitements et renvoie OK ou NOK (exception, boolean, ce que vous voulez).

Une question me vient alors à l'esprit :

Pourquoi diable avez vous créé une classe (ou une fonction) dont le nom est si framework-dependant avec un contenu qui ne l'ai pas forcément toujours, et qui surtout vous est tellement spécifique que vous auriez pu le développer même si vous utilisiez un autre framework ?

Personnellement, j'aurai créé une classe autonome suivant mes conventions avec mes packages, dans mon arborescence, capitalisée dans mon dépôt de code, testé unitairement dans un contexte non framework-isé, c'est à dire beaucoup plus simplement en fait, puis, j'aurais créé la même classe que vous (enfin qu'eux), mais il n'y aurai que quelques lignes (uniquement technique, pas applicative) :

try {
    MyPackage_MyClass::factory()
        ->mySpecificMethod($param1, ...);
} catch (Exception $e) {
    // do something with the exception if this plugin
}

La même remarque me vient à l'esprit pour tous les "adapters" que l'on peut créer pour les différents frameworks.

Tout ça manque "d'illustration" ? Pensez aux centaines de lignes de code que vous (ou les autres) écrivez pour réaliser des plugins Zend Framework, Symfony, Drupal, Magento, eZPublish, Joomla, <WhatEverFrameworkYouWant>et qu'il faut (difficilement) porter à chaque nouvelle version d'un framework ou carrément réécrire quand vous changez de framework...

D'un point de vue maintenance vous y gagneriez, non ? Vous pourriez même faire des tests unitaires sur votre propre code sans devoir mettre en place des pseudo-artifices a base de XXXXControllerTest et autres, puisqu'au final vous n'auriez que votre classe à tester, pas le framework.
Mais si me dites-vous, car moi j'utilises massivement les "features" du framework dans mon code spécifique (par exemple un Mage::singleton('....')->retrouveMoiMagiquementMesProduits(...) donc je ne peux pas extraire mon code de cet endroit la car il est trop "dépendant" au framework, je vous conseillerais alors d'aller faire un tour du côté des adapters et de ne plus utiliser en direct dans votre des méthodes que vous n'avez pas développé vous même, sauf si il s'agit d'une classe dite "adapter", ...

Que les auteurs de frameworks (que j'ai été et que je suis toujours aussi ;)) ne se formalisent pas, ce que je dénonce ce ne sont pas les frameworks, mais l'usage qui en est fait, qui pour moi est le plus important à long terme (surtout quand on voit que la majorité des frameworks sont réécrits au bout de 2 ou 3 ans)

Donc, si je peux me permettre un conseil :

Ne placez jamais de code à vous dans une classe dont on vous contraint le nom ou l'héritage (extends).
Instanciez plutôt dans cette classe, une classe à vous qui est autonome et que vous avez développé par ailleurs.

SimpleTest, installation via mon PEAR

Olivier Hoareau — Thu, 25 Feb 2010 17:18:00 +0000

Pour les besoins de l'AFUP, je dois me mettre un peu à SimpleTest (j'ai plus l'habitude sur PHPUnit). Je n'ai pas trouvé de channel PEAR (a priori) fournissant un package installable via PEAR de SimpleTest et fournissant l'outil en ligne de commande (comme peux le proposer PHPUnit ou d'autres outils). Je vous propose donc celui de mon cru...

Grâce à un de mes outils de packaging compatible PEAR, j'ai packagé la version 1.0.1 de SimpleTest pour un faire un package PEAR valide et installable via mon channel :

$ pear channel-discover pear.phppro.fr
$ pear upgrade phppro/simpletest

ou un téléchargement puis une installation locale :

$ wget http://pear.phppro.fr/get/simpletest-1.0.1.tgz
$ pear upgrade simpletest-1.0.1.tgz

Puis pour l'utilisation :

$ cd myproject
$ simpletest my_simpletest_test.php

Pour l'implémentation de tests SimpleTest, je vous laisse bien entendu faire un tour sur le site officiel : http://www.simpletest.org

Dès qu'un channel / package officiel apparaît (ou que quelqu'un m'indique l'adresse) je supprimerai le mien ;)

Et vous comment faisiez vous pour installer SimpleTest ?

Cloner une arborescence projet modèle

Olivier Hoareau — Wed, 24 Feb 2010 09:00:00 +0000

Vous créez souvent de nouveaux projets pour vous ou pour les autres ?
Vous réalisez souvent des tâches répétitives de "clonage" d'arborescence en changeant certains noms de fichiers ou contenu pour les contextualiser ?
Ce script certainement peut vous aider !

Créer le fichier clone-tree.php avec le contenu suivant :

<?php

class TreeCloner
{
    public function cloneTree($src, $dest, $vars)
    {
        if (false === is_dir($dest)) {
            mkdir($dest);
        }
        foreach(scandir($src) as $item) {
            if ('.' === $item || '..' === $item) {
                continue;
            }
            $sPath = $src . '/' . $item;
            $dPath = $dest . '/' 
                . $this->replace($item, $vars);

            if (true === is_dir($sPath)) {
                mkdir($dPath);
                $this->cloneTree($sPath, $dPath, $vars);
            } else {
                $raw = file_get_contents($sPath);
                $generated = $this->replace($raw, $vars);
                file_put_contents($dPath, $generated);
            }
        }
        return $this;
    }
    
    public function replace($txt, $vars)
    {
        $m = null;
        if (0 >= preg_match_all(
        	"|\%\{([^\}]+)\}|",$txt,$m
            )) {
            return $txt;
        }
        
        for($i = 0; $i<count($m[0]);$i++) {
            $key  = $m[1][$i];
            $sPos = strpos($key, ':');
            $func = null;
            if (false !== $sPos) {
                list($func, $key) = explode(':', $key, 2);
            }
            if (null !== $func) {
                if ('php' === trim(strtolower($func))) {
                    $value = eval('return ('. $key . ');');
                } else {
                    if (false === isset($vars[$key])) {
                        continue;
                    }
                    $value = $vars[$key];
                    $value = $func($value);
                }
            } else {
                if (false === isset($vars[$key])) {
                    continue;
                }
                $value = $vars[$key];
            }
            $txt = str_replace($m[0][$i], $value, $txt);
        }
        return $txt;
    }
}

if (4 !== count($_SERVER['argv'])) {
    die("Syntax: php ".basename(__FILE__).
    " <src> <dest> <variables.ini>
"
    );
}

$cloner = new TreeCloner();
$cloner->cloneTree(
    $argv[1], $argv[2], parse_ini_file($argv[3])
);

Vous pouvez maintenant utiliser le cloneur d'arborescence comme suit :

créer une arborescence modèle dans un répertoire (appellons le 'source'), vous pouvez utiliser des "variables" comme suit: %{name} sera remplacé par la valeur de la variable name dans le fichier ini. Vous pouvez utiliser %{maVariable} dans le contenu d'un fichier (txt, php, xml, pptx, docx, csv, js, css ...) ou bien même dans le nom d'un fichier ou d'un répertoire !
créer un fichier de paramétrage avec les différentes variables et leur valeur (appellons le vars.ini) :

name=Olivier
lastname=Hoareau
email=olivier@phppro.fr
...

exécutez la ligne de commande suivante pour générer l'arborescence à partir de votre modèle :

$ php clone-tree.php source destination vars.ini

Vous devriez avoir une belle arborescence finale dans le répertoire destination !

Et vous, comment faites vous pour générer des arborescences complexes pour vos projets ? Zend_Tool et autres Symfony et CakePHP pour les projets de ce type, mais pour les autres types de projets ?

Une variante possible : réaliser un .phar ou bien utiliser la directive / fonction __halt_compiler() (voir http://php.net/manual/fr/function.halt-compiler.php) pour embarquer l'ensemble de l'arborescence (zippée) dans votre fichier php (un peu le principe des .phar), ce qui permettra de ne fournir que le fichier de paramètres et le nom du répertoire de destination !

Capitaliser, Améliorer et Rationnaliser les développements PHP en interne

Olivier Hoareau — Sun, 21 Feb 2010 17:36:00 +0000

Je vous livre ici un document de travail anonymisé sur la présentation d'un outil que je développe pour un client pour cadrer les pratiques de développements, ainsi que les enjeux et la démarche à adopter en interne.

20100221 my phingtool - blog

View more presentations from PHPPRO.

Utilisez PEAR pour gérer vos dépendances

Olivier Hoareau — Fri, 19 Feb 2010 23:28:00 +0000

PEAR (http://pear.php.net) est très mal connu dans les entreprises (en tout cas celle que je visite...).

Je ne vais pas vous décrire ici tous les fondements et usages de cet outil, cependant, au delà d'une "librairie" vieillotte, il s'agit d'un outil puissant qui vous donne le pouvoir de réutiliser votre code et de gérer vos dépendances.

Commençons par créer un projet vide dans le répertoire myproject :

mkdir myproject
cd myproject

Créons ensuite un "repository" pear local à notre projet grâce à l'utilisation d'un fichier de configuration personnalisé de PEAR :

mkdir configs
mkdir dependencies dependencies/bin dependencies/doc dependencies/ext
mkdir dependencies/library dependencies/cache dependencies/cache
mkdir dependencies/data dependencies/download dependencies/temp
mkdir dependencies/test dependencies/www
pear -c configs/pear.conf -s
pear -c configs/pear.conf bin_dir `pwd`/dependencies/bin
pear -c configs/pear.conf doc_dir `pwd`/dependencies/doc
pear -c configs/pear.conf ext_dir `pwd`/dependencies/ext
pear -c configs/pear.conf php_dir `pwd`/dependencies/library
pear -c configs/pear.conf cache_dir `pwd`/dependencies/cache
pear -c configs/pear.conf data_dir `pwd`/dependencies/data
pear -c configs/pear.conf download_dir `pwd`/dependencies/download
pear -c configs/pear.conf temp_dir `pwd`/dependencies/temp
pear -c configs/pear.conf test_dir `pwd`/dependencies/test
pear -c configs/pear.conf www_dir `pwd`/dependencies/www

Créons ensuite une commande raccourci pour éviter de devoir spécifier le fichier de configuration à chaque fois :

vi mypear
---contenu de mypear---
#!/bin/sh

pear -c configs/pear.conf $*
---
chmod +x mypear

Nous pouvons maintenant exécuter toutes les commandes pear habituelles qui auront pour effet de mettre à jour notre repository local i.e. le répertoire dependencies/ de notre projet
Il est maintenant tout à fait concevable d'installer vos propres dépendances localement :

mypear channel-discover pear.mycompany.com
mypear upgrade mycompany/mypackage1
mypear upgrade mycompany/mypackage2
...

(je ne décris pas ici comment créer vos propres package pear et installer votre propre channel pear, probablement pour de prochains billets ;) je vous conseille tout de même de regarder du côté de pirum, l'outil de Fabien Potencier qui est un must have pour votre channel pear: http://www.pirum-project.org)

Il ne vous reste plus qu'à mettre le répertoire dependencies/library dans l'include path (avec set_include_path()) de votre application, d'activer éventuellement le mécanisme d'autoloading (avec spl_autoload_register()) et les différentes classes de votre repository seront alors disponible dans votre application.

Enfin, vous n'aurez plus qu'à "zipper" le contenu de votre répertoire projet pour avoir un package complet que vous pourrez déployer en production (il est bien sûr envisageable de construire programmatiquement ce package à déployer, mais cela est simplifié grâce au fait que vous avez toutes les classes nécessaires dans dependencies/library)

Au passage, je conseille vivement l'utilisation de "pear upgrade" plutôt que "pear install", en effet l'action upgrade va installer les dépendances du paquets (et mettre à jour les dépendances trop anciennes), alors que l'action install sortira en erreur si les des dépendances ne sont pas installées ou sont dans des versions trop anciennes.

Cette technique (i.e. l'utilisation d'un fichier de configuration personnalisé de PEAR) peut vous permettre de gérer en parallèle plusieurs versions de packages et plusieurs versions de PHP. Notamment très utile si vous travaillez au quotidien avec plusieurs applications fonctionnant avec des versions différentes de dépendances ou d'outils (je pense par exemple à des plateformes d'intégration continue qui ont besoin de fonctionner avec plusieurs versions de phing / phpunit et php notamment).

Et vous quels sont vos conseils d'utilisations de PEAR ?

PS: Pyrus, la nouvelle version de PEAR est déjà disponible depuis quelques temps, elle n'est a priori cependant compatible qu'avec PHP 5.3.1, elle ne sera donc utilisé dans nos système d'information que dans quelques années lumières...

Incompatibilité Phing 2.3.3 et PHPUnit 3.4.x+

Olivier Hoareau — Sat, 09 Jan 2010 10:04:00 +0000

Phing, le port de Ant (java) en PHP, propose des tasks (balises xml) permettant d'exécuter des classes PHPUnit (tests unitaires en PHP). La version stable de Phing n'est maintenant plus compatible avec la dernière version stable de PHPUnit (3.4.3 actuellement) voir avec la branche 3.4.x, et on obtient l'erreur :

[PHP Error] require_once(PHPUnit/Util/Log/XML.php): failed to open stream: No such file or directory [line 22 of C:\Program Files\PHP\PEAR\phing\tasks\ext\phpunit\phpunit3\XMLPHPUnit3ResultFormatter.php]

Voici une piste pour y remédier :

Le problème vient du fait que les nouvelles versions de PHPUnit (a priori depuis la branche 3.4.x) ont supprimé notamment le fichier PHPUnit/Util/Log/XML.php suite à du refactoring. Ce fichier étant inclus par une classe de phing, le plantage est donc compréhensible (voir le ticket de rapport de bug).

Il existe 2 solutions :

remplacer l'inclusion de XML.php par JUnit.php (telle que décrit dans le ticket de rapport de bug)
mettre à jour la version de phing pour utiliser la branche 2.4.x encors en version Release Candidate (2.4.0RC3 actuellement).

Personnellement je préconise la deuxième solution, plus pérenne et plus propre. Voici comment faire :

pear upgrade --alldeps --force phing/phing-2.4.0RC33

(certaines dépendences de package seront mises à jour notamment VersionControl_SVN qui devra être à minima en version 0.3.3)
Vous devez ensuite remplacer toutes les utilisations de tasks "phpunit2" ou "phpunit2report" par "phpunit" dans vos build.xml.

Session "Oui ! PHP est industriel !" au forum PHP 2009 @Paris

Olivier Hoareau — Tue, 17 Nov 2009 11:33:00 +0000

Le forum PHP 2009 de Paris s'est déroulé la semaine dernière, je vous livre le support de session que nous avons utilisé avec Damien Seguy à l'occasion de la présentation de notre session sur l'industrialisation en PHP.

AFUP Forum PHP 2009 : Oui ! PHP est industriel !

View more presentations from PHPPRO.

Grâce à PHPTV, Vous pouvez aussi écouter le podcast de la session !

Que vous ayez participé à la session ou non, vos retours / remarques / critiques sont les bienvenues !

Forum PHP AFUP : 12 et 13 novembre 2009, Paris : mon planning

Olivier Hoareau — Tue, 10 Nov 2009 11:02:00 +0000

De retour de congé aux pays des requins, je vous livre mon planning prévisionnel pour le prochain évènement PHP parisien de cette semaine, si certains veulent venir discuter PHP / Agilité, ca peut aider !

Jeudi 12 novembre 2009

07h00 - 09h30 : arrivée sur Paris, libre
09h30 - 10h00 : Ouverture Forum
10h00 - 11h00 : session "Comment améliorer PHP ? avec un préprocesseur !" => Salle 2
11h00 - 11h30 : libre
11h30 - 12h30 : "Un web ouvert avec PHP, Eric Daspet", Amphi, ou éventuellement libre
12h30 - 14h00 : déjeuner, pour l'instant libre ;)
14h30 - 15h00 : session "Optimisation des performances Magento avec Zend Server", Amphi
15h00 - 16h00 : "Meilleur support Cloud et Open Source : Le point sur PHP et Microsoft", Amphi, ou éventuellement libre
16h00... : libre

Vendredi 13 novembre 2009

09h00 - 10h00 : Jouons avec PHP 5.3, Amphi
10h00 - 11h00 : Motiver ses développeurs, Amphi
11h00 - 14h00 : libre
14h00 - 15h00 : Je présenterai ma conférence "Oui ! PHP est industriel !" avec Damien Seguy, Amphi, venez nombreux !
15h00 - 16h00 : Bonnes pratiques de développement en PHP, Salle 2
16h00 - 16h30: libre

Tout au long des 2 jours, vous pouvez me joindre par email (olivier@phppro.fr) ou téléphone (0631207479), n'hésitez pas, je serais ravi de discuter PHP / Agilité avec vous !

Bon forum à tous !

Analyse de dépendances classes/fichiers

Olivier Hoareau — Sun, 25 Oct 2009 11:48:00 +0000

Dans mon précédent post sur "Zend Framework 1.8.3 demystified, Act I", je vous avais livré un schéma de dépendances entre packages générés grâce à un de mes outils... Je vous livre maintenant l'outils.

WDependency est un outil réalisé en PHP et utilisant le programme GraphViz/Dot pour générer des graphes de dépendances entre classes , fichiers, projets, packages...

Installation

pear channel-discover pear.phppro.fr
pear install --alldeps phppro/wdependency

(Un package requis nommé 'WFramework' sera aussi installé, il s'agit d'un framework d'abstraction que je développe avec mes conventions pour illustrer des pratiques / conventions chez mes clients)

Vérifiez que l'installation c'est bien passée :

wdependency

(Vous devriez voir l'aide repris ci-dessous)

Il est ensuite nécessaire d'installer GraphViz/Dot (le binaire 'dot' doit être accessible en ligne de commande)
Vous pouvez vérifiez si il est installé sur votre poste :

wdependency :check-dot-support

Si la version de dot ne s'affiche pas, c'est que vous devez l'installer, rendez-vous sur http://www.graphviz.org rubrique downloads, téléchargez et installez l'outil dot.
Une fois installé, re-vérifiez que wdependency est bien cablé avec dot en relançant un :

wdependency :check-dot-support

Ensuite pour utiliser l'outil :

cd my-source-directory
wdependency :help

Vous obtiendrez l'aide de l'outil ci-dessous :


 ***** [Syntax] ***************************************************************

   $ wdependency [commands] [options] [<directory>[,<directory>,...]]

 ***** [Available commands] ***************************************************

   use: :<command> , ':' is required

   :help                  display this help
   :instances             computes the instances (use of new operator) dependencies
   :cache                 parses directory content and caches result in all.php for further use
   :clean-cache           cleans existing cache file
   :often-used            top rank node that heavily depend on others
   :classes               computes the classes dependencies (children => mother)
   :package0-inheritances  computes the classes inheritances reduced to first package level
   :package1              computes the classes dependencies reduced to second package level
   :inheritances          computes the inheritances dependencies
   :includes              computes the includes dependencies
   :packages              computes the packages dependencies
   :dependent-nodes       list all mostly dependent nodes (top ranked)
   :check-dot-support     display the version of dot binary if available (required for dot/picture export)
   :popo                  list Plain Old PHP Objects (no extends / no implements)
   :supers                computes the hierarchy dependency (mother => children)
   :testcases             list all classes that extends PHPUnit_Framework_TestCase
   :untestedpackages      list all packages that does not contain phpunit test cases
   :testedpackages        list all packages that contains phpunit test cases
   :hubs                  list all classes that are very used by others
   :self-dependent        list all classes that are self-dependent (depend on themself)
   :dependent             list all classes that are dependent to others (more than 4 links to the same)
   :very-dependent        list all classes that are very dependent to others (more than 10 links to the same)
   :extra-dependent       list all classes that are extra dependent to others (more than 20 links to the same)
   :describe-X            display content of specific interface, where X is:
         * listener     for displaying W_Dependency_Listener_Interface
         * exporter     for displaying W_Dependency_Exporter_Interface
         * analyzer     for displaying W_Dependency_Analyzer_Interface
         * filter       for displaying W_Dependency_Filter_Interface
         * aggregator   for displaying W_Dependency_Aggregator_Interface
         * source       for displaying W_Dependency_Source_Interface
         * action       for displaying W_Dependency_Action_Interface

 ***** [Available options] ****************************************************

   use: -<option> , no value (no '=...')

   -v      verbose mode, debug information logged in ./wdependency.log
   -h      display this help
   -c      activate/use cache file for parsing optimization (generate/use ./wdependency.cache file)
   -cc     clean existing cache file

   use: --<option>=<value> , no default value, '=<value>' is required

   --action      load custom action(s) (list separator: ,), specified by class name
   --aggregator  load custom aggregator(s) (list separator: ,), specified by class name
   --analyzer    load custom analyzer(s) (list separator: ,), specified by class name
   --bottom      keep only nodes that are in the specified bottom rank (top X) when computing weight from links
   --by          aggregate nodes using the specified algorithm:
         * dir          aggregate by directories (dirname on / of node)
         * package      aggregate by package (dirname on _ of node)
         * package#X    aggregate by package at position X
         * dir#X        aggregate by directory at position X
   --class       keep only nodes that are used by specified class
   --dir         keep only nodes that are used by file in specified directory
   --exporter    load custom exporter(s) (list separator: ,), specified by class name
   --file        keep only nodes that are used by specified file
   --filter      load custom filter(s) (list separator: ,), specified by class name
   --format      list of export format:
         * png          PNG picture file
         * jpg          JPG picture file
         * gif          GIF picture file
         * dot          GraphViz DOT text format
         * graphml      GraphML xml format
         * json         JavaScript Object Notation text format
         * php          PHP file (return array(...);)
         * svg          Scalable Vector Graphics picture format (xml)
   --has         keep only nodes that have links
   --layout      graphviz (dot) layout to use, by default 'dot', type dot -K? to see available list
   --link        keep only nodes that have link to specified node
   --linked-to   keep only links to specified dependency
   --listener    load custom listener(s) (list separator: ,), specified by class name
   --load        loads the specified file as a data source (from previous analyzes, PHP format supported only)
   --max         keep only nodes that have a maximum of links specified
   --max-link-weight  keep only links that have less than specified weight
   --min         keep only nodes that have at least the minimum links specified
   --min-link-weight  keep only links that have more than specified weight
   --n           keep only nodes that have number of nodes specified
   --node        keep only nodes that are used by specified node
   --nolink      keep only nodes that have not link to specified node
   --none        keep only nodes that have no links
   --package     keep only nodes that are used by class in specified package
   --pattern     keep only nodes that have name matching specified pattern
   --prefix      keep only nodes that have name beginning with specified prefix
   --reverse     reverse link order (user become used and used become user)
   --source      load custom source(s) (list separator: ,), specified by class name
   --subdirs-as-projects  use subdirectories as autonomous projects
   --template    php file template to render export (file exporter only), use $options and $data
   --top         keep only nodes that are in the specified top rank (top X) when computing weight from links

 ***** [Additional information] ***********************************************

   * additional options could be available dependending on the renderer
     template (i.e. phtml view file if used)

   * for schema / graph export in dot, png, jpg, ... you must have the
     graphviz binaries installed (dot binary)

 ***** [Software information] *************************************************

   wdependency v0.0.7, built on 2009-10-25
   Under BSD License, Olivier Hoareau <olivier a t phppro.fr> - PHPPRO

   PEAR package

Le principe est simple :

vous vous positionnez dans le répertoire racine à analyser
vous indiquez l'action a effectuer et le format d'export voulu
vous indiquez éventuellement les "filtres / tri" et les "aggrégations" voulues
vous lancez wdependency avec tous ces paramètres
wdependency va analyser chaque fichier PHP de répertoires du répertoire courant (récursif)
il va construire un modèle de donnée en mémoire pour réprésenter les dépendances
il va trier/filtrer les données
il va exporter en jpg/png/... (i.e. le(s) format(s) que vous avez choisis)

Exemples

Vous pourrez ensuite générer le graphiques de dépendances entre vos répertoires de second niveau par exemple grâce à la commande :

wdependency :package1

un fichier png devrait apparaître dans le répertoire courant

Ou bien générer le graphe d'héritage de vos classes :

wdependency :inheritances

Le graphe d'héritage d'une classe en particulier :

wdependency :inheritances --node=MyPackage_MyClass

...

Mise en cache du parsing pour aller plus vite

Il est possible de parser une fois et de mettre en cache le modèle de données résultant pour ensuite faire plusieurs "requêtes" sans devoir tout reparser à chaque fois :

Commencez par vider le cache et regénérer le fichier de cache (./wdependency.cache):

wdependency -cc
wdependency :cache

Puis exécutez n'importe laquelle des commandes comme d'habitude, vous verrez c'est plus rapide ;)

Bien sûr il s'agit d'une version alpha certainement buggée, merci par avance pour vos retours sur le gestionnaire d'issues : http://code.google.com/p/wdependency/issues/list

Bon usage !

Zend Framework demystified, act I...

Olivier Hoareau — Sun, 18 Oct 2009 18:48:00 +0100

Voici une vue des dépendances entre package dans Zend Framework 1.8.3 réalisé avec un de mes outils d'analyse de code.

Je travaille actuellement sur l'analyse des dépendances entre classes, packages, applications / frameworks pour notamment cartographier les zones mortes des applis (i.e. code non utilisé), les zones de complexité ou de dette technique (i.e. point central ayant beaucoup de liaison...).
Après plusieurs heures de recherches d'une librairie de visualisation temps réel sur un graphe, je n'ai toujours pas trouvé mon bonheur pour parcourir en temps réel le graphe, je vous livre donc pour l'instant ma version graphviz (dot)

Avez-vous d'autres techniques pour représenter les dépendances classes/applications/frameworks ?

PS: le noeud ROOT correspond aux classes située à la racine du répertoire library/Zend, les autres noeuds correspondent aux répertoires situés dans library/Zend/

PHP : Une plateforme industrialisable au service de l'Agilité

Olivier Hoareau — Mon, 28 Sep 2009 19:51:00 +0100

Je publie sur slideshare une version refactorée d'une présentation draft que j'avais réalisé il y a quelques mois pour l'Université du S.I avant de préférer avec Damien Seguy une version plus light... Au programme, PHP et Agilité, encore et toujours ;)

PHP : Une Technologie Au Service De L'Agilité

View more presentations from PHPPRO.

Vu que je n'ai jamais joué cette présentation pour l'instant, vos critiques et remarques sont, encore et toujours, les bienvenus !

Test unitaire: comment bouchonner ?

Olivier Hoareau — Sat, 26 Sep 2009 16:59:00 +0100

L'exécution d'un test unitaire nécessite en règle générale la mise en place de bouchon (mock en anglais) qui permettent de simuler les appels systèmes ou d'api sous jacent.
En effet, il peut être difficile de tester une partie de votre code qui a des impacts sur le système externe (enregistrement sur disque, appels réseaux / webservices, stockage mémoire vive, appels base de données...), le principe du bouchon est alors bien pratique pour tester la logique sans déclencher toutes les opérations.

Le schéma ci-dessous décrit un exemple de séquence d'exécution permettant de mettre en oeuvre un test unitaire (test avec bouchon) sur une méthode d'une classe (appellée "Service") qui elle même utilise une méthode d'une autre classe pour récupérer la liste non triée brute des commandes. Il est ici nécessaire de bouchonner car la récupération de la liste des commandes brutes est ici réalisées par l'appel d'un webservice SOAP, qu'il est hors de question de déclencher lors de l'exécution des tests unitaires (nous utiliserons alors le bouchon) :

Voici un exemple de code que l'on pourrait associer à ce schéma :

La classe de test

<?php
 
class MyApp_Order_ServiceTest extends PHPUnit_Framework_TestCase
{
	public function setUp()
	{
		$this->fixture = new MyApp_Order_Service();
		$this->fixture->setAdapter(
			new MyApp_Order_Adapter_Mock());
		/**
		 * ou bien:
		 *
		 * $this->fixture =
		 * 	Myapp_Order_Service::factory('mock');
		 */
	}
 
	public function
	 test_listOrdersForDate_forNoOrders_returnEmptyArray()
	{
		// 1. Paramétrer le mock
		$this->fixture->getAdapter()
			->addMethodExpectedResult(
				'listForDate',
				array());
 
		/**
		 * 2,3,4,5,6 et 7. Appeller la méthode du
		 *                 service que l'on teste
		 */
		$result = $this->fixture
			->listOrdersByDate('2009-09-26');
 
		/**
		 * 8 et 9. Demander au mock si il a été
		 *         appellé et avec quels paramètres
		 */
		$params = $this->fixture->getAdapter()
			->getLastMethodCallParams('listForDate');
 
		/**
		 * 10. Vérifier (tester) le résultat du
		 *     service
		 */
		$this->assertEquals(array(),$result);
 
		/**
		 * 11. Vérifier (tester) les paramètres
		 *     envoyés par le service à l'adapter
		 */
		$this->assertEquals(array('2009-09-26'),$params);
	}
        // ...
}

Le "Service"

<?php
 
/**
 * Fonctionnalités liées aux "Commandes"
 *
 * La classe parent (MyApp_Abstract_Service) fournis
 * toutes les méthodes génériques pour les services:
 *
 * setAdapter(), getAdapter()...
 */
class MyApp_Order_Service extends MyApp_Abstract_Service
{
	public function listOrdersForDate($date)
	{
		if (false === preg_match(
			"|^20[0-9]{2}\-[0-9]{2}\-[0-3][0-9]$|",
			$date)) {
			throw new RuntimeException(
			 "Bad date format ".
			 "(expected YYYY-MM-DD, got: '$date')");
		}
		try {
			$rawList = $this
				->getAdapter()
					->listForDate($date);
		} catch (Exception $e) {
			MyApp_Logger::logException($e);
			throw new RuntimeException(
			"An error occured when retrieving ".
			"orders list for date ".
			"'$date': ".$e->getMessage());
		}
		$orders = array();
		foreach($rawList as $order) {
			$orders[$order['id']] = array(
				'nbItems'=>count($order['items']),
				'amount'=>$order['price'],
			);
		}
		asort($orders);
		return $orders;
	}
        // ...
}

L'Adapter Mock (bouchon)

<?php
 
/**
 * Bouchon pour les fonctionnalités "Commandes"
 *
 * La classe parent (MyApp_Abstract_Mock) fournis
 * toutes les méthodes génériques pour les bouchons:
 *
 * getLastMethodCallParams(), 
 * markMethodExecutionAndReturnExpectedResult(), ...
 */
class MyApp_Order_Adapter_Mock extends Myapp_Abstract_Mock
	implements MyApp_Order_Adapter_Interface
{
	public function listForDate($date)
	{
		$args = func_get_args();
		return $this
		 ->markMethodExecutionAndReturnExpectedResult(
			__FUNCTION__,
			$args);
	}
        // ...
}

L'Adapter standard (celui qui appelle le SOAP, mais qui n'est pas utilisé dans les tests unitaires)

<?php
 
/**
 * Implémentation native pour les fonctionnalités "Commandes"
 *
 * L'interface MyApp_Order_Adapter_Interface définit la liste
 * des méthodes à implémenter dans cet adapter
 */
class Myapp_Order_Adapter_Default
	implements MyApp_Order_Adapter_Interface
{
	/**
	 * @var SoapClient
	 */
	private $soapClient;
 
	public function __construct()
	{
		$this->soapClient = new SoapClient(...);
	}
 
	public function listForDate($date)
	{
		return $this->soapClient->listForDate($date);
	}
 
        // ...
}

La séquence

La séquence d'appel est donc la suivante :

Paramétrage du mock : on dit au bouchon quel est le résultat qu'il doit renvoyer quand on va l'appeller
Appel de la méthode testée par le test unitaire: on exécute la méthode avec les paramètres en dur depuis le test unitaire
Pré-logique du service : la méthode commence par traiter les arguments et se préparer avant l'appel de l'adapter (mock dans notre cas)
Appel de l'adapter par le service: le mock est alors appelé par le service avec d'éventuels arguments préparés
Renvoie du résultat par l'adapter: le mock renvoie "bêtement" le résultat qu'on lui a demandé de renvoyer lors du paramétrage (étape 1)
Post-logique: le service traite le résultat de l'adapter (filtrage, trie, transformation...)
Renvoie du résultat attendue par le test: le service renvoie le résultat final au test unitaire
Le test vérifie que le mock a bien été appelé par le service (pour être sur que tout s'est bien passé, n'oublions pas le service est une boite noire, lorsque l'on fait un test on n'est pas censé savoir comment le service est implémenté, mais uniquement que son comportement)
Le test récupère les paramètres d'appel du mock par le service
Vérification du résultat attendu: 1ère assertion sur le résultat final, on vérifie que la liste retournée par le service est celle attendue dans le cadre de ce test
Vérification des paramètres fournis par le service à l'adapter (mock): 2ème assertion sur l'appel du mock par le service, on vérifie que le service a bien eu le comportement attendu sur l'adapter (mock)

Les étapes 8, 9 et 11 sont souvent oubliés, elles sont cependant de mon point de vue nécessaire pour garantir que le test unitaire met en oeuvre un véritable bouchon et que seul la logique que l'on souhaite testée est exécutée (sinon, il ne s'agit pas d'un test unitaire, mais plutôt d'un test d'intégration...).
Cette technique est bien entendu a utiliser pour bouchonner les appels à la base de données...

Et vous, comment faites vous pour bouchonner votre code, notamment dans le cadre des tests unitaires ?

Agilité, Tests et Industrialisation en PHP

Olivier Hoareau — Wed, 23 Sep 2009 16:50:00 +0100

Je publie sur slideshare la présentation faite ce jour. Je parle de méthodologie agile au travers de l'histoire d'une équipe, et d'industrialisation des développements PHP (Intégration Continue, Tests, ...)

Agilité, Tests Et Industrialisation

View more presentations from ohoareau.

Vos retours, remarques, critiques sont les bienvenues !

PS : c'est vraiment pas mal : [...], me suis bien éclaté aujourd'hui ;-)

Olivier Hoareau — Tue, 22 Sep 2009 18:14:00 +0100

Retours sur la satisfaction d'un développeur.

Récemment j'ai mis en place une pratique un peu particulière pour suivre des développeurs à distance et garder le contact : "La méthode du jour".
Le principe est simple, je leur demande de m'envoyer chaque soir par email un extrait du code développé dans la journée, une méthode de leur choix :

une méthode du code applicatif
une méthode de test
un fragment de méthode
...

L'idée est de faire en sorte, que le lendemain matin, ils aient un feedback extérieur sur leur développement de la veille. Par mes soins (ils pourraient l'envoyer à d'autres développeur d'une autre équipe, ca marcherait aussi pour cet aspect). Un autre aspect intéressant est que je garde le contact avec le code en ne regardant que les échantillons "sélectionnés" par l'équipe (un par jour ET par développeur tout de même).

Au delà de la revue de code technique, je peux capter les humeurs / ressentis / comportements, et proposer mon aide sur des sujets qui peuvent paraître moins triviaux :

isolement d'un développeur
sentiment de non confiance en soi
divergence de pratiques
baisse de la vélocité
...

Je voulais vous faire partager cette pratique qui m'est bénéfique, et qui doit l'être à mes développeurs ;)

La petite citation du jour d'un de mes développeurs illustre bien cet aspect "behind the scene" que l'on peut évaluer au delà de la réalité du code technique :

PS : c'est vraiment pas mal: ..., me suis bien éclaté aujourd'hui :-)

Et vous avez vous d'autres pratiques pour "faire" parler vos développeurs et/ou entretenir des relations de suivi et d'échange à distance avec eux ?

La loi de Demeter où le principe de la connaissance minimale

Olivier Hoareau — Mon, 21 Sep 2009 10:17:00 +0100

Vous avez certainement déjà fait : $this->getFirstObject()->getSecondObject()->doSomething() ? Vous avez déjà certainement eu des soucis a repasser à différents endroits de votre code quand l'interface du "SecondObject" change, voici un principe de développement logiciel qui alors nous être utile...

Le principe de Demeter dit qu'un objet a le droit d'accéder aux méthodes/opérations d'un autre objet, mais pas à celles d'un objet encapsulé dans un autre objet. Concrètement, nous avons le droit de faire :

$this
    ->getFirstObject()
        ->doSomething(...);

Mais nous n'avons pas le droit de faire :

$this
    ->getFirstObject()
        ->getSecondObject()
            ->doSomething();

Ce qui nous oblige donc dans le "first object" à fournir autant d'opérations que nécessaire pour éviter que la classe (représentée par $this dans notre cas) ne sache quel objet réalise réellement l'opération.

Par exemple, dans la ligne suivante :

$this
    ->getAdapter()
        ->getTypeDispositifService()
            ->contientDesPhases(
                $this
                    ->getAdapter()
                        ->getIdTypeDispositifConcours($concours));

Le principe de Demeter n'est pas respecté car depuis le service (représenté par $this) nous n'avons pas le droit d'appeller une méthode sur le "TypeDispositifService", nous n'avons le droit d'appeller que des méthodes de l'adapter, nous devons donc créer une méthode dans l'adapter qui encapsule tout ca, par exemple :

$this
    ->getAdapter()
        ->contientDesPhases(
             $this
                 ->getAdapter()
                     ->getIdTypeDispositifConcours($concours));

avec l'implémentation suivante :

class ...._Adapter_Default implements ..._Adapter_Interface
{
    ...
    /**
     * @return boolean
     */
    public function contientDesPhases($typeDispositif)
    {
        return $this
                         ->getTypeDispositifService()
                             ->contientDesPhases($typeDispositif);
    }
    ...
}

Une des conséquences positives de l'application de la loi de Demeter est l'augmentation des degrés d'adaptabilité, évolutivité, maintenabilité du code / de l'application. Une inconvénient est la nécessité d'encapsuler systématiquement les appels de second niveau, augmentant le nombre d'appel de méthodes à réaliser pour exécuter un code, ce point pouvant être relativement maîtrisé en mettant en oeuvre une architecture de type services la plus applatie possible (i.e. en évitant tant que possible les dépendances de dépendances de dépendances ... d'objets).

J'applique cette loi sur tout mes développements et je la conseille à mes développeurs, et personnellement nous avons un retour d'expériences positifs.

Pour une définition plus théorique et complète de la loi de Demeter, je vous propose de consulter Wikipédia.

Et vous, est-ce une règle que vous appliquez ? En appliquez vous d'autres contradictoires / complémentaires ?

Faire le ménage dans le code : mettre le code mort à la poubelle ou le garder au cas où ?

Olivier Hoareau — Mon, 14 Sep 2009 09:30:00 +0100

Une question d'un développeur:
La prochaine itération va comporter un bon nombre de tâches techniques et nous avons pensé « faire le ménage » dans notre code, mais que faire du code mort ? Faut-il supprimer les sections inutilisées ... en partant du principe qu’elles polluent les classes ... ou bien les conserver si un jour elles venaient à resservir ?" Ma réponse...

Mon avis: supprimer sans état d'âme le code dit "mort", à partir du moment ou il a été committer au moins une fois dans subversion.

Il peut être envisageable de noter le numéro de révision ou la date ou de créer un tag dans subversion avant tout nettoyage de printemps. Ce qui vous permettra de retrouver plus facilement/rapidement le code ensuite.

Rien ne vous empêche de garder une version en local du trunk à la révision actuelle, en plus du trunk sur lequel vous travaillé. Ce qui vous permettra d'avoir directement sous la main le code source "legacy" qui pourrait être de nouveau nécessaire.

Ne laissez pas de code mort dans le trunk, "la mort amène la gangrène" ;)

Si vous pensez que les développements réalisés mettent en oeuvre un concept qui pourra être réutilisable, par contre le code lui non, alors écrivez un article wiki pour décrire ce pattern / concept / technique, ca vous prendra 15-30 minutes et ce sera facilement accessible pour tout le monde.

N'oubliez pas qu'un de vos objectifs utopique est d'avoir le moins possible de lignes de code, et qu'elles soient le plus simple possible.

Ma maxime préférée : "L'excellence attire l'excellence" : si votre code est propre, enviables, beau, clean, smart (whatever you want), les nouveaux développements auront beaucoup plus de chances de l'être.

Et vous qu'auriez vous répondu ?

Service/Adapter : mes adapters sont trop gros mon capitaine !

Olivier Hoareau — Fri, 11 Sep 2009 15:17:00 +0100

Si vous implémentez le pattern Adapter, ou bien si vous suivez mes posts, vous avez entendu parler de la notion d'Adapter. Mon point de vue sur la question est qu'ils doivent être minimals (1 à 2 lignes par méthodes, aucune logique autre que l'appel à une méthode native php / extension). On arrive alors de temps en temps à une problématique : les adapters ont tendance à vouloir "grossir", quand on veux "généraliser" la logique dans le service (et qu'on relègue l'implémentation dans l'adapter). La contrainte des 1 à 2 lignes est alors difficile à respecter... ou presque !

Quand vous développez ou refactorez un morceau de code (Service, Adapter, ...) posez vous la question suivante :

"Si je devais tester unitairement ce morceau de code quels seraient les impacts extérieurs (appels de méthodes externes à la classe, utilisation de singleton ou d'objet externes non passés en arguments et par exemple instancié dans le code...) ?"

Si la réponse est "aucun", alors vous êtes en face d'un service. Si la réponse n'est pas "aucun" alors vous êtes AUSSI en face d'un service si vous utilisez if, while, for, try, foreach, ... (i.e. si vous avez de la logique qui "créé, modifie, contrôle l'information)

Ensuite, imaginez que vous êtes un "parser" technique bête et méchant (je sais que ce n'est pas le cas), parcourez alors votre morceau de code, instruction par instruction, ligne par ligne de haut en bas. A chaque fois que vous tombez sur une utilisation d'une fonction native php qui a un impact sur le système (réseau, système de fichiers, mémoire vive / partagée, base de données, extension c...) alors vous êtes en face d'une méthode d'un adapter à fournir potentiellement.

Souvent quand on me demande de regarder des adapters déjà développés, ils ont beau s'appeller ..../Adapter/....php, il s'agit de service ! car ils ont une succession de méthodes qui sont volumineuses (beaucoup plus qu'une ligne chacune) avec de la logique de if, while, for, try, foreach...

Par contre, je suis d'accord que certaines au moins de ces méthodes doivent être dans l'adapter et pas dans le service (peut être pas toutes cependant).

Quand vous êtes en face d'un problème comme cela, vous devez au moins vous poser 2 questions :

1/ Est-il possible de déplacer cette méthode de cet adapter dans son service (au dessus), en fournissant éventuellement de nouvelle méthodes dans l'adapter qui sont plus unitaires et qui sont orchestrées par cette logique qui arrive dans le service ? 2/ Est-il plus pertinent de garder cette méthode dans l'adapter (bien placée) et de créer un nouveau service, dit "technique", qui sera utilisé par l'adapter en une seule ligne, ce nouveau service proposant une ou plusieurs méthodes, et ayant lui même un adapter ?

Si S = Service, A = Adapter, le schéma habituel / commun est le suivant :

S1 => A1.1  (i.e. Le service 1 utilise son adapter 1)

Mais on peut aussi chainer les utilisations de services :

S1 => A1.1 => S2 => A2.1  (i.e. Le service 1 utilise son adapter 1 qui lui même devant réaliser des opérations complexes, utilise un second service (2) qui lui même utilise son adapter 1)

Par exemple,dans le cas simple (avec beaucoup de lignes dans l'adapter), l'implémentation est :

Service(ex: AccuseReception) => Adapter(ex: Feed)

dans le but de simplifier l'adapter Feed, de rendre le code plus testable et plus module on peut avoir :

Service(ex: AccuseReception) => Adapter(ex: Feed) => Service(ex: XMLParser) => Adapter(ex: Native ou SimpleXMLElement)

Ce qui nécessite la création d'un service technique 'XMLParser' avec sa batterie d'adapter (Default/Native, Mock, ...)

Le service XMLParser devient utilisable à son tour directement en tant que service depuis un contrôleur (MVC), ou un adapter.

L'intérêt est alors que l'on peut facilement tester unitairement (PHPUnit, SimpleTest) les services (i.e AccuseReception et XMLParser dans notre exemple), alors qu'il est difficile (personnellement je le déconseille) de tester les adapter (et donc l'implémentation initiale Feed qui faisait plusieurs centaines de lignes).

Attention cependant à respecter la règle suivante dans la mesure du possible :

"Un service a le droit uniquement d'appeller ses propres méthodes ou celle de son adapter, mais pas celle d'un autre service".

Idéalement il faut donc créer une méthode dans l'adapter et passer par cette méthode pour appeller le XMLParser, et non utiliser le XMLParser en direct.

Il peut être envisageable d'avoir "plusieurs" adapter en même temps pour un même service (adapter read, adapter write...), cela est potentiellement intéressant car permet une réutilisabilité accrue, attention par contre à la complexité de gestion. Je recommande de n'avoir qu'un seul adapter par service, cela est plus facile à gérer, et permet de garantir qu'un adapter est 100% adapté au service qui l'utilise (on ne se retrouve pas dans des situations d'interblocage dans lesquels l'adapter générique de lecture dans un fichier qu'on utilise n'a pas la méthode toto qui est utile par un des services qui l'utilise (mais uniquement que par celui la !))

Tout cela est un peut théorique, j'en conviens, dans la forme.

Je peux tenter d'illustrer mon propos sur des exemples précis / ciblés si vous me le demandez.

Et vous quelles sont vos pratiques concernant le découpage Service/Adapter ?

Tests d'intégration, quézako ?

Olivier Hoareau — Fri, 14 Aug 2009 11:17:00 +0100

Les tests unitaires c'est bien, mais ce n'est pas suffisant, surtout quand on a besoin de tester que notre application s'intègre effectivement bien avec un webservice d'un de nos fournisseurs... Parlons de tests d'intégration, donc.

Qu'est ce q'un test d'intégration ?

De mon point de vue, un test d'intégration sert à tester l'intégration (ca paraît trivial mais il est important de le rappeller).
Je ne pense donc pas qu'il soit nécessaire de tester TOUTE l'application, ou TOUTES les fonctionnalités de l'application, ou toutes les lignes de code de l'application grâce aux tests d'intégrations, mais uniquement que les "intégrations" (i.e. "les communications / intéractions de notre code avec un autre code que nous n'avons pas développé") qui sont effectivement réalisées dans notre application.

Lister et catégoriser les intégrations

Il faut donc commencer à lister les "intégrations" de notre application. Elles peuvent être multiples :

utilisation de base de données type SQL
utilisation de webservices (soap, rest, xml, http, ...)
import / export de fichiers
intéractions avoir d'autres applications grâces à des protocoles non web standard ou propriétaire (ssh, ftp, scp, cft, ldap...)

et pour les plus puristes d'entre nous :

utilisation du système de fichier
utilisation de toute fonction native à la plateforme ayant un impact sur le système ou l'éco-système (réseau, disque, mémoire vive...)
utilisation de librairies spécifiques (génération de pdf, génération d'images et de graphiques...)

En résumé, une "intégration" concerne l'utilisation de tout code ou librairie que vous N'AVEZ PAS développé vous même et qui est utilisé par votre application.

On peut les classer en deux types d'intégration :

les intégrations distantes : i.e. "ressources utilisées / accédées via un protocole réseau", sont les plus "visibles" et facile à tester, elles concernent les utilisations de ressources externes telles que des webservices ou du ldap par exemple.
les intégrations locales : i.e. "API intégrées dans le langage du code développé", sont les plus vicieuses et les plus difficile à tester, elles concernent l'utilisation de librairies (notamment PHP), d'extension / module, de framework, de ressources locales (disque dur, mémoire vive...)

Les types de tests d'intégration

Basiquement, on distingue 2 types de test d'intégration :

les tests qui coûtent cher (long ou financièrement coutêux)
les tests qui ne coûtent pas cher (rapide et sans / peu d'impact notable sur notre éco-système)

Une chose est sûr, tout test d'intégration qui est (facilement) automatisable doit être automatisé.
Attention cependant, en fonction du type de test (cher / pas cher), on peut décider d'exécuter régulièrement ou non le test d'intégration, tout n'est pas nécessairement candidat à l'exécution régulière (imaginez un test d'envoi de bulk massif de 100 sms via un broker, cela pourrait vite vous coûter cher en temps (lire les 100 sms) et en argent (à 0,07 centimes minimum le sms, ca fait quand même 7€ par exécution du test qui partent en fumée !, imaginez si vous exécutez ce test automatiquement à chaque commit, cela va vite vous faire mal d'appuyer sur le bouton "commit" !).
De mon point de vue, il y a donc une différence entre automatisation et exécution régulière. Je distingue donc 3 niveaux d'automatisation de tests d'intégration :

test d'intégration manuel : i.e. procédure de contrôle décrite mais réalisée manuellement (via des clics et des saisies clavier par exemple)
test d'intégration semi-automatique : i.e. test qui a été codé, est reproductible et déclenchable via un programme pré-programmé, mais nécessite une action humaine comme déclencheur. L'action humaine peut être un clic, une commande console à exécuter ou une url à appeller via un navigateur, par exemple.
test d'intégration automatique : i.e. idem semi-automatique mais déclenché sans l'intervention de l'homme par un évènement pré-programmé (ex: commit subversion, build nocturne ...)

"Quel outil choisir pour mes tests d'intégration ?" où la question dont la réponse n'est pas (la plus) importante

Je vous voit tous à attendre avec une impatience une liste d'outils populaires pour rédiger et exécuter vos tests d'intégrations. Donc, la voici !

PHP.

Trève de plaisanterie, de mon point de vue, le vrai sujet au-delà de la question de savoir si vous allez pouvoir utiliser tel ou tel outils meilleur que son voisin pour vos tests d'intégrations, est plutôt de savoir et de comprendre les enjeux des tests d'intégration, et les problèmes que vous allez devoir résoudre.
Je vous conseille d'utiliser des outils que vous maîtrisez et qui permettent de faire des rapports d'erreurs d'exécutions tels que les outils de type xUnit (PHPUnit, voire SimpleTest) qui sont adaptés pour exécuter du code PHP et faire un rapport sur des assertions bonnes ou fausses sur le résultat.

Les contexts d'intégration : où le niveau de cloisonnement des tests

Qu'est ce qui se cache derrière le terme barbare de "cloisonnement des tests d'intégrations" ? Tout simplement le niveau d' "impact" que vous avez sur l'application avec laquelle vous êtes intégré, on peut en effet distinguer différents niveaux d'impact en fonction des environnements mis à disposition pour l'intégration :

bouchon local : cloisonnement total car pas de persistence côté application distante, mais vous devez installer localement et avec vos compétences le bouchon éventuellement fourni par l'équipe de l'application à laquelle vous souhaitez vous intégrer
bouchon distant : cloisonnement total car pas de persistence côté application distante
environnement de test dédié : cloisonnement fort car votre application est la seule à appeler cette instance de l'application distante
environnement de test mutualisé : cloisonnement faible mais impact minime (instance de test)
environnement de préproduction : cloisonnement faible voir inexistant mais impact non critique (instance de préproduction)
environnement de production : aucun cloisonnement, impact maximal (instance de production)
...

Plus vous aurez un cloisonnement fort, plus vos tests seront faciles et peu coûteux pour une exécution (très) régulière, et inversement.

L'idée reçue : un test d'intégration est un test de bout en bout graphique ou fonctionnel

Il sera toujours plus difficile d'automatiser (et de rejouer régulièrement) le test de bout en bout qui vise à vérifier que la valeur 2 est bien présente dans la case 3 du tableau de la deuxième page (sachant que la valeur 2 est récupérée via un appel de webservice) plutôt que d'appeller en direct le webservice via une API développée dans votre code.

Attention donc, de mon point de vue un test d'intégration n'est pas un test bout en bout graphique ou fonctionnel, mais plutôt un moyen de tester que les couches basses de votre application savent communiquer avec l'application distante selon le ou les contrats de services définis.

L'API locale : La clé pour rédiger facilement vos tests d'intégration

Pour tester "uniquement" l'intégration, il faut donc privilégier le développement d'API interne à votre code qui permet de "cacher / envelopper" l'appel à l'application distante à laquelle vous vous intégrée. Ce qui vous permettra de facilement développer des scripts php de tests d'intégration en utilisant PHPUnit par exemple. Cette API locale devra fournir l'"enrobage" de l'appel à l'application distante en fournissant à votre code des fonctionnalités "locales" faciles à utiliser et faciles à bouchonner (notamment pour vos tests unitaires).
Ainsi lors de vos développements, vous devriez à minima avoir 2 types de fonctions / méthodes / classes :

les fonctions / méthodes / classes du coeur de votre application
les fonctions / méthodes / classes fournissant une API d'accès aux applications et fonctionnalités distantes à intégrer

Une fois développé cette couche / API locale, il vous sera plus facile de réaliser des scripts PHP de tests d'intégration utilisant cette API en direct et manipulant l'API pour tester les différentes fonctionnalités disponibles.
Une piste pour la réalisation de cette API locale serait la création systématique d'une classe <ApplicationAIntegrer>Service qui fourni les différentes fonctionnalités à intégrer sous forme de méthode, et de créer pour ce service un adapter sous-jacent par défault (réalisant effectivement les appels distants) et à minima un adapter bouchon (mock) utile pour les tests unitaires par exemple et le développement. Je vous invite à lire mes billets sur le concept de service et d'adapter pour plus de précision et d'exemple sur comment s'y prendre en PHP via un exemple.

Cette technique d'API locale (peu importe le protocole réseau ou non) est systématiquement utilisée par les grands fournisseurs de webservices de nos jours (eBay / PayPal / Google ...) avec de plus en plus une intégration dans les frameworks populaires alla Zend Framework ou Symfony.

Où placer mes tests d'intégrations ?

Dans le répertoire locale de votre application : ./tests/integration, par exemple ;)
Vous pouvez créer un répertoire par "intégration" et un fichier par cas de test d'intégration, ou bien si vous utilisez PHPUnit par exemple, une classe de test par "intégration" et une méthode de test par cas d'intégration.

Pour la suite, à vous de me dire ce que vous voulez...

Je vais m'arrêter là pour l'instant, si vous souhaitez des précisions ou des exemples sur des aspects ou des points concrets, vous n'avez qu'à demander ;)

Et sinon, vous comment faite vous pour écrire vos tests d'intégration ?

PS: Bien sûr il manque encore au moins un test, le test de bout en bout ;)

Tests Unitaires : ma philosophie via un exemple

Olivier Hoareau — Mon, 10 Aug 2009 08:38:00 +0100

Je vois souvent des tests dit unitaires chez mes clients, mais qui se connectent à la base de données, font des requêtes réseaux...
Voici une petite présentation de ce que personnellement j'appelle tests unitaires, par l'exemple.

Qu'est ce qu'un test ?

Un test est un morceau de code écrit dans un langage quelconque (pas forcément celui du code de votre application, peut être le langage naturel, un document word...), qui :

permet de vérifier que le comportement de l'application (ou d'un morceau de l'application) est conforme au comportement attendu
permet de décrire une façon reproductible de réaliser une vérification précise sur l'application

Il existe plusieurs typologies de tests et outils associés en PHP :

tests unitaires (ex: PHPUnit, SimpleTest, ...)
tests fonctionnels (ex: GreenPepper, Fitnesse, ...)
tests d'intégrations (ex: PHPUnit, ...)
tests graphiques (ex: Selenium, ...)
...

Qu'est ce qu'un test unitaire ?

Définition générale

Un test unitaire est un morceau de code de préférence minimaliste qui a pour but de valider le bon fonctionnement de l'utilisation d'une routine / fonction / méthode dans un CAS PRECIS (et non dans tous les cas d'utilisation possible de la routine).
L'objectif d'un test unitaire étant de tester la logique d'une routine en particulier, il est nécessaire de ne pas être parasité par les éventuels bugs ou mauvaises utilisations de méthodes/fonctions/routines dont la méthode testées aurait besoin.
C'est pour cela qu'on met en oeuvre un mécanisme de bouchonnage des dépendances visant à ne pas déclencher tout code logique qui ne doit pas être testé dans ce test unitaire.

Implémentation commune en PHP

Un test unitaire PHP est un test unitaire écrit en PHP en utilisant dans la plupart des cas un framework de test unitaire de type xUnit.
Le plus populaire étant PHPUnit développé par Sebastian Bergmann depuis plusieurs années et écrit 100% en PHP.

Le principe est simple :

on écrit une classe de test qui hérite d'une classe du framework
on écrit autant de méthode à l'intérieur de cette classe que de tests unitaire à réaliser
en général on écrit une classe de tests pour tester une classe (ou une fonction native) du code applicatif (relation 1<=>1)

Exemple de fichier de test tests/phpunit/StrlenTest.php :


<?php
class StrlenTest extends PHPUnit_Framework_TestCase
{
    public function testStrlenForEmptyStringReturn0()
    {
        $this->assertEquals(0,strlen(''));
    }
    public function testStrlenForNotEmptyStringReturnStringLength()
    {
        $this->assertEquals(3, strlen('php'));
        $this->assertEquals(14,strlen('rasmus lerdorf'));
    }
    public function testStrlenForArrayReturn1()
    {
        $this->assertEquals(1,strlen(array());
    }
}

Implémentation sur un projet exemple

Les tests unitaires dans le projet exemple, sont des tests unitaires dont l'objectif est de bouchonner un maximum les dépendances.

Que ne dois-je pas tester avec les tests unitaires ?

On pourrait rephraser le titre de ce paragraphe en : "Que ne dois-je pas tester/exécuter/déclencher/appeller avec les tests unitaires ?", la réponse serait donc :

les connexions / requêtes sur la base de données depuis PHP
les appels réseaux depuis PHP
l'utilisation de fonctions / classes/méthodes natives depuis PHP (sauf à des fins didactiques)
l'utilisation d'api / librairies / frameworks / code source non développées expressément dans la classe que je suis en train de tester
le contenu du bootstrap ou de l'initialisation de votre application

Que dois-je tester avec les tests unitaires ?

Autrement dit quand vous faites un tests unitaires, vous n'avez le droit d'exécuter (au sens "passer par les lignes php") que :

le code écrit dans la méthode de test
le contenu (intégral) de la méthode en cours de test
le contenu des bouchons nécessaires au fonctionnement de la méthode testée

c'est tout.

Aucun appel :

système/disque
réseau
mémoire vive (autre que l'exécution des lignes de code listées ci-dessus)

n'est autorisé dans un test unitaire.

Comme toujours il existe des exceptions :

vous avez le droit de faire un appel système/disque pour lire un fichier qui contient des données de tests, si ce fichier est utilisé par le bouchon

Comment détecter ce qu'il faut tester de ce qu'il faut bouchonner ?

Prenons un exemple, on souhaite développer une fonctionnalité de listing filtrée des accusés réception de bordereaux de dépôt de plis.
Notre application contacte un webservice pour récupérer la liste des bordereaux de dépôt de plis sur une date précise et tris cette liste par numéros de plis:

Voici notre démarche :

nous choisissons le nom de notre service: library/Bordereaux/Service.php (classe Bordereaux_Service) :
nous créons un fichier/classe de test pour notre nouveau service: tests/phpunit/Bordereaux/ServiceTest.php (classe Bordereaux_ServiceTest)

<?php

require_once dirname(__FILE__).'/../../../contexts/phpunit.php';

class Bordereaux_ServiceTest extends PHPUnit_Framework_TestCase 
{
    /**
     * Service testé
     * 
     * @var Bordereaux_Service
     */
    private $f;
    /**
     * Adapter bouchon (mock)
     *
     * @var Bordereaux_Adapter_Mock
     */
    private $m;

    public function setUp()
    {
        $this->f = new Bordereaux_Service();
        $this->m = new Bordereaux_Adapter_Mock();

        // bouchonne le service testé
        $this->f->setAdapter($this->m);
    }
}

nous créons la première méthode de test unitaire pour le cas en erreur (plantage du webservice)

<?php
...
    public function testListSortedBordereauxForNetworkErrorThrowException()
    {
        $this->m->addExpectedResult('listBordereaux',new RuntimeException('This is my network exception'));
        try {
            $this->f->listSortedBordereaux('2009-08-03');
            $this->fail('No network exception thrown');
        } catch (RuntimeException $e) {
            $this->assertEquals('This is my network exception',$e->getMessage());
        }
    }
...

* nous créons l'adapter "bouchon" (ou mock) dans le fichier library/Bordereaux/Adapter/Mock.php

<?php

class Bordereaux_Adapter_Mock implements Bordereaux_Adapter_Interface
{
    /**
     * List of results/exceptions to return/throw
     *
     * @var array
     */
    private $methods;

    public function addExpectedResult($method,$result)
    {
        if (!isset($this->methods[$method])) {
            $this->methods[$method] = array();
        }
        $this->methods[$method][] = $result;
        return $this;
    }

    protected function processMethod($method)
    {
        if (!isset($this->methods[$method])) {
            throw new RuntimeException("No result set for method '$method'");
        }
        $r = array_shift($this->methods[$method]);
        if (true === ($r instanceof Exception)) {
            throw $r;
        }
        return $r;
    }

    public function listBordereaux($day)
    {
        return $this->processMethod(__FUNCTION__);
    }
}

nous créons/développons l'adapter par défault qui réalisera le travaille réel d'appeler le webservice dans le fichier library/Bordereaux/Adapter/Default.php

<?php

class Bordereaux_Adapter_Default implements Bordereaux_Adapter_Interface
{
    /**
     * à noter l'utilisation d'un service Rest_Service, à développer.
     * Comme nous en avons besoin maintenant, nous devons arrêter temporairement
     * le développement en cours, pour développer (avec la même pratique !)
     * ce service. Une fois totalement testé et développé, nous pourrons revenir
     * à ce développement.
     *
     * Il est important de noter ici, que dans la méthode ci-dessous :
     * - il est INTERDIT de faire plus d'une ligne de code
     * - il est INTERDIT de faire un try/catch ou de lever explicitement une exception
     */
    public function listBordereaux($day)
    {
        return Rest_Service::factory()->get(str_replace(array('%{day}'),array($day),cfgGet('ws.bordereaux.url')));
    }
}

nous créons l'interface des adapter dans le fichier library/Bordereaux/Adapter/Interface.php :

<?php

interface Bordereaux_Adapter_Interface
{
    /**
     * List all bordereaux picked up from the webservice
     * 
     * @return array of bordereaux
     * @throws Exception if network error
     */
    public function listBordereaux($day);
}

nous créons le fichier et la classe (minimale) du service avec la méthode (vide) dans le fichier library/Bordereaux/Service.php


class Bordereaux_Service
{
    /**
     * Underlying adapter
     *
     * @var Bordereaux_Adapter_Interface
     */
    private $adapter;

    public function __construct()
    {
        $this->adapter = new Bordereaux_Adapter_Default();
    }

    public function listSortedBordereaux($day)
    {
        $bordereaux = $this->adapter->listBordereaux($day);
        // les deux lignes qui suivent ne seront présentes qu'à partir du 2ième test unitaire
        usort($bordereaux,array($this,'compareBordereauxByPliNumber'));
        return $bordereaux;
    }
    /**
     * Compare pli id and return -1, 0, 1 (helper method used by usort())
     *
     * @return integer
     */
    public function compareBordereauxByPliNumber($bordereau1,$bordereau2)
    {
        return -1;
        // à partir du deuxième test unitaire nous pourrons faire des tests sur cette méthode, qui contiendra alors (commentez alors la ligne ci-dessus) :
        return $bordereau1['pliId'] < $bordereau2['pliId'] ? 1 : ($bordereau1['pliId'] > $bordereau2['pliId'] ? -1 : 0);
    }
}

nous pouvons maintenant faire nos tests unitaires pour les autres cas et notamment le cas nominal qui renvoie des bordereaux précis pour une date précise :

<?php
...
    public function testListSortedBordereauxForDateContainingBordereauxReturnBordereauxListAsArray()
    {
        $expected = json_decode('[{"pliId":"903"},{"pliId":"1001"},{"pliId":"1354"}]',true);

        $this->m->addExpectedResult('listBordereaux',json_decode('[{"pliId":"1001"},{"pliId":"903"},{"pliId:"1354"}]',true));
        
        $result = $this->f->listSortedBordereaux('2009-08-03');

        $this->assertEquals($expected,$result);
    }
}

Dans ces tests unitaires le webservices n'est JAMAIS appelé ! Pourtant nous réalisons quand même des tests et notre application fonctionne correctement. Nous avons bouchonné l'appel réseau en interceptant la méthode listBordereaux() de l'adapter et en faisant en sorte qu'elle renvoie ce que nous souhaitons pour nos tests.

Bien entendu il manque un test (non unitaire cette fois-ci) qui nous permet de vérifier que l'intégration avec le webservices est fonctionnelle.

Et vous qu'est ce que l'expression "test unitaire" signifie pour vous ?

subversion + fichier .ini + include_path = gestion dynamiques des dépendances (librairies,...)

Olivier Hoareau — Fri, 07 Aug 2009 08:50:00 +0100

Votre application utilise certainement le tout dernier framework dernier cri, ou encore LA librairie ultime pour faire du PDF ou de l'ODT en PHP.. Ou encore, votre application dépend d'une autre application que vous avez réalisé ou interne à votre entreprise, elle a besoin de certaines classes par exemple.

Voici une méthode (il en existe certainement plein d'autres !) vous permettant de gérer vos dépendances pour être sûr de travailler toujours sur la bonne version d'une librairie, et pas sur une version modifiée en local sur votre poste et qui serait différente de celle sur votre serveur de production !

Subversion : la base de tout

Subversion (ou CVS, même si je conseille de l'abandonner au profit de SVN) est un outil de gestion de source/version qui permet de centraliser une copie du code source de votre application sur un serveur central.
Cet outil permet entre autre de gérer la synchronisation des développement entre plusieurs développeurs d'une équipe, et de garder la version officielle du code source de votre application, ainsi qu'éventuellement toutes les releases officielles que vous auriez sorties.

Au delà de "maintenir" le code source de votre application, SVN, de son petit nom, peut aussi maintenir le code source de plusieurs applications, chacune ayant une adresse :

(exemple d'une installation de subversion en mode DAV/Svn avec Apache)

Mon application 1 => http://mon-serveur-svn/mon-application-1/trunk
Mon application 2 => http://mon-serveur-svn/mon-application-2/trunk

Imaginons que l'application 1 ait besoin de certaines classes de l'application 2 pour fonctionner, il est nécessaire lorsque l'on récupère le code source de l'application 1 de récupérer aussi le code source de l'application 2.

Ces opérations peuvent être réalisées grâce à un "checkout" via subversion (i.e. "récupération en local du code source de l'application en restant lié au serveur central), ou bien une mise à jour via un "update" (i.e. "je synchronise la copie locale du code source que j'ai sur mon ordinateur avec celle du serveur en récupérant toutes les différences sur mon ordinateur local")

En règle général, ces opérations sont manuelles, on utilise souvent un client SVN pour cela, comme par exemple TortoiseSVN ou bien Eclipse/Subclipe/Subversive (entre autres).

Dépot de dépendances local

Quand je développe en local, j'ai donc besoin :

du code source de mon application (en cours de développement : trunk)
du code source de toutes les dépendances dont mon application à besoin (versions précises)

Si j'ai récupéré en local les différentes dépendances de mon application, il faut maintenant que je paramètre mon application pour qu'elle trouve les fichiers en fonction de leur emplacement.
Typiquement les répertoires qui contiennent les classes de l'application 2 dont j'ai besoin dans l'application 1 doivent être disponible dans l'include path de mon application :

Exemple dans le fichier contexts/@common.php (inclus par tous les fichiers de mon application) :

<?php

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/../dependencies/mon-application-2/');

// ...

Imaginons que mon-application-2 contiennent entre autres des classes mais aussi des fichiers d'autres types, en règle général on va plutôt isoler dans un répertoire les classes php, par exemple library/, nous aurons donc :

Exemple dans le fichier contexts/@common.php (inclus par tous les fichiers de mon application) :

<?php

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/../dependencies/mon-application-2/library');

// ...

Vous n'êtes pas développeur de l'application 2, donc elle peut être en cours de développement. Vous devez être sûr que la version que vous utilisez est compatible avec vos développements dans votre application (les signatures de méthodes doivent être les bonnes, les fonctionnalités doivent être celles que vous attendez...). Pour garantir ces points, il est nécessaire que vous récupériez une VERSION précise de la dépendance que vous savez compatible avec le mode de fonctionnement que vous attendez. Vous allez donc récupérer un "tag" subversion de la dépendance 2 :

Mon application 2 dans la version 0.1.1 (compatible avec mes développements) : http://mon-serveur-svn/mon-application-2/tags/0.1.1

En local, vous allez mettre le code source de cette version dans un répertoire qui porte le numéro de version pour que ce soit plus explicite :

Exemple dans le fichier contexts/@common.php (inclus par tous les fichiers de mon application) :

<?php

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/../dependencies/mon-application-2/0.1.1/library');

// ...

Vous avez maintenant dans votre répertoire dependencies/ l'ensemble de vos dépendances qui proviennent de tags subversion (i.e. de versions précises).

Détection de dépendances et modification de l'include path automatisé

Au cours du temps vous serez amenez à utiliser des versions successives de vos dépendances, au rythme de leur développement.
Vous passerez peut être à la version 0.1.2 de mon-application-2 (votre dépendance) puis 0.1.5 puis 0.2 puis ... puis 1.0.

N'oubliez pas alors de modifier votre fichier contexts/@common.php (ou équivalent) qui spécifie l'include_path :

<?php

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/../dependencies/mon-application-2/1.0.0/library');

// ...

Un moyen plus pratique, surtout quand il y a plusieurs dépendances, est d'utiliser un fichier de configuration que vous chargez et qui vous permet de modifier l'include path.
Ce fichier peut être au format php, ini, xml ... au choix, voici un exemple en utilisant un fichier ini (utilisable par phing) :

Fichier config/dependencies.ini :


;; liste des dépendances

dependencies.list = "ma2"

;; dépendance mon-application-2

dependencies.ma2.name    = "mon-application-2"
dependencies.ma2.version = "1.0.0"
dependencies.ma2.base    = "library"

Vous pouvez maintenant ajouter la lecture et l'analyse de ce fichier dans votre "bootstrap" :

Fichier contexts/@common.php (inclus par tous les scripts php) :

<?php

$paths = array();
$depsInfo = parse_ini_file(dirname(__FILE__).'/../config/dependencies.ini');
foreach(explode(',',$depsInfo['dependencies.list']) as $depName) {
    $depKeyPrefix = 'dependencies.'.$depName.'.';
    $paths[] = dirname(__FILE__).'/../dependencies/'.$depsInfo[$depKeyPrefix.'name'].'/'.$depsInfo[$depKeyPrefix.'base'];
}

set_include_path(get_include_path().PATH_SEPARATOR.implode(PATH_SEPARATOR,$paths));

// ...

Grâce à ce fichier config/dependencies.ini et à ces quelques lignes de code PHP, vous n'avez plus besoin de vous préoccuper de votre include_path, il sera automatiquement paramétré à l'exécution de votre application. Si vous souhaiter changer la version d'une dépendance, commencer par faire un checkout dans le répertoire dependencies/<nom-dependence>/<version>/ puis modifier le fichier config/dependencies.ini pour y paramétrer le numéro de version ou ajouter la dépendance (utilisez la "," pour spécifier plusieurs dépendances dans la liste).

Subversion : maintenir le code source des dépendances

Au delà de 'maintenir' le code source de VOS applications (i.e. de vos développements), le serveur Subversion (même local dans votre entreprise) peut aussi maintenir une copie du code source des dépendances externes (i.e. open source, publique...) que pourraient avoir vos applications.
Par exemple, je développe souvent avec Zend Framework (entre autres), et je peux donc stocker le code source de ces librairies chez moi, sur mon serveur subversion par exemple dans les urls suivantes :

Zend Framework 1.8.3 => http://mon-serveur-svn/ZendFramework/tags/1.8.3
Zend Framework 1.9.0 => http://mon-serveur-svn/ZendFramework/tags/1.9.0
...

Il me suffit alors de faire un checkout de l'url http://mon-serveur-svn/ZendFramework/tags/1.8.3 et de modifier mon fichier de configuration des dépendances :

Fichier config/dependencies.ini :


;; liste des dépendances

dependencies.list = "ma2,zf"

;; dépendance mon-application-2

dependencies.ma2.name    = "mon-application-2"
dependencies.ma2.version = "1.0.0"
dependencies.ma2.base    = "library"

;; dépendance zend-framework

dependencies.zf.name    = "zend-framework"
dependencies.zf.version = "1.8.3"
dependencies.zf.base    = "library"

Dépendances de type ressources

Certaines dépendances concernent des fichiers images, css, javascript, ... comme par exemple les frameworks javascript tels que Dojo, ExtJS, JQuery...
Il est tout a fait possible de gérer ces dépendances via ce même canal en altérant un peu le principe.
L'idée est de stocker les dépendances en local au même endroit que précédemment, cependant il ne faut pas forcément ajouter le répertoire à l'include path.
Par contre il faut faire en sorte que les fichier ressources (images, css, js...) soit accessible dans le document root (htdocs/public/html) du serveur web :

Fichier config/dependencies.ini :


;; liste des dépendances

dependencies.list = "ma2,zf,ej"

;; dépendance mon-application-2

dependencies.ma2.name    = "mon-application-2"
dependencies.ma2.version = "1.0.0"
dependencies.ma2.base    = "library"

;; dépendance zend-framework

dependencies.zf.name    = "zend-framework"
dependencies.zf.version = "1.8.3"
dependencies.zf.base    = "library"

;; dépendance ext-js

dependencies.ej.name    = "ext-js"
dependencies.ej.version = "1.0.0"
dependencies.ej.public  = yes
dependencies.ej.path    = no
dependencies.ej.htdocs  = ""

On subversionne ensuite la dépendance ext-js dans svn :

ExtJS 1.0.0 => http://mon-serveur-svn/ExtJS/tags/1.0.0

Fichier contexts/@common.php (inclus par tous les scripts php) :

<?php

$paths = array();
$depsInfo = parse_ini_file(dirname(__FILE__).'/../config/dependencies.ini');
foreach(explode(',',$depsInfo['dependencies.list']) as $depName) {
    $depKeyPrefix = 'dependencies.'.$depName.'.';
    if (!isset($depsInfo[$depKeyPrefix.'path'])) {
        $depsInfo[$depKeyPrefix.'path'] = 'yes';
    }
    if ('yes' === $depsInfo[$depKeyPrefix.'path']) {
        $paths[] = dirname(__FILE__).'/../dependencies/'.$depsInfo[$depKeyPrefix.'name'].'/'.$depsInfo[$depKeyPrefix.'base'];
    }
}

set_include_path(get_include_path().PATH_SEPARATOR.implode(PATH_SEPARATOR,$paths));

// ...

Fichier .htaccess ou fichier de configuration apache (pour le virtual host par exemple) :


# ...
Alias /extjs <chemin-vers-la-racine-de-votre-application>/dependencies/ext-js/1.0.0

# ...

Conclusion

Cette technique vous permet de gérer un include_path dynamique et notamment :

utiliser plusieurs versions différentes de la même dépendance pour des applications différentes sur le même serveur / poste
maîtriser le paramétrage de vos dépendances
éviter de mettre l'url subversion de votre projet les différentes dépendances comme si il s'agissait de code source que vous aviez développé (cela alourdi considérablement le dev)
...

Une amélioration possible, testée, est l'automatisation avec phing du checkout/update des dépendances, ainsi vous laissez à phing le soin de récupérer les dépendances en fonction du fichier dependencies.ini, notamment juste avant d'exécuter les tests unitaires ou de faire un déploiement.

Et vous quels sont vos pratiques pour gérer vos dépendances ?

Les fichiers de contextes : où comment utiliser la même appli sur le web, les tests unitaires, fonctionnels, la ligne de commande, ...

Olivier Hoareau — Wed, 05 Aug 2009 09:03:00 +0100

Votre application peut être exécutée via :

* un navigateur (web)
* une ligne de commande (batch)
* PHPUnit (tests unitaires ou tests d'intégration)
* GreenPepper / Fitnesse (tests fonctionnels)
* ...

Les points d'entrées

Chacun de ces "points d'entrées" de votre application a besoin d'un contexte de travail particulier, par exemple :

en mode web, l'uri de la requête et les paramètres GET/POST... sont nécessaire à l'application
en mode batch, les paramètres saisies en ligne de commande sont nécessaire à l'application
en mode tests unitaires, les classes du frameworks PHPUnit ainsi que les classes de tests doivent être disponible
en mode tests fonctionnels, les classes de Fixtures doivent être disponible
...

Bien que chacun de ces "contextes" a des spécificités particulières, l'ensemble de ces contextes ont besoin de :

l'ensemble des classes développées pour la logique de l'application
de la connexion à la base de données
des paramétrage éventuels dans le fichier de configuration
d'écrire dans un fichier de log
...

L'objectif a atteindre est donc de faire en sorte que le maximum de code développé pour l'application soit fonctionnel et ce peut importe le point d'entrée (i.e. le contexte) par lequel l'application a été lancée.

Les fichiers contextes

Si nous résumons, nous avons besoin de :

un fichier spécifique à chacun des contextes
un fichier commun inclus par chacun des contextes

Voici donc un exemple de fichiers contextes :

Fichier contexts/http.php :

<?php

$context = 'http';

require_once dirname(__FILE__).'/@common.php';

// traitement spécifique: traite la requête HTTP, exemple avec Zend Framework :

$controller = Zend_Controller_Front::getInstance();

// ...

$controller->dispatch();

Fichier contexts/phpunit.php :

<?php

$context = 'phpunit';

require_once dirname(__FILE__).'/@common.php';

// ligne suivante pas nécessaire si PHPUnit est dans l'include path et que l'autoload est actif
require_once 'PHPUnit/Framework/TestCase.php';

// traitement spécifique: paramètre l'include path pour trouver les classes de tests, injecte les données de tests

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/../tests/phpunit');

// injecte les données de tests situées dans config/db/phpunit/create-schema.sql et create-data.sql
// ...

Fichier contexts/greenpepper.php :

<?php

$context = 'greenpepper';

require_once dirname(__FILE__).'/@common.php';

// traitement spécifique: paramètre l'include path pour trouver les fixtures, injecte les données de références

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/../tests/greenpepper');

// injecte les données de références situées dans config/db/greenpepper/create-schema.sql et create-data.sql
// ...

// ajoute la fonction adhoc de logging dans le fichier greenpepper.log

function gpLog($txt)
{
    $fp = fopen(dirname(__FILE__).'/../logs/greenpepper.log','a+');
    $msg = '['.date('Y-m-D H:i:s').'] '.$txt.PHP_EOL;
    fputs($fp,$msg);
    fclose($fp);
}

Fichier contexts/batch.php :

<?php

$context = 'batch';

require_once dirname(__FILE__).'/@common.php';

// traitement spécifique: aucun, ils sont réalisés dans les scripts qui inclus le contexte batch

Fichier contexts/@common.php :

<?php

// sur quel environnement (prod, preprod, ...) sommes nous ?
$env     = getenv('PHP_ENV');

// sets the include path : library/ ...

// load configuration file
// ...

// load database connection
// ...

// load file logger
// ...

// activate autloader (pour l'include automatique des
// fichiers contenant la définition des classes instanciées)
// ...

L'utilisation des fichiers contextes

Maintenant que nous avons nos différents contextes prêt à l'emploi il faut faire le branchement pour qu'ils soient appeller au bon moment.

Contexte HTTP

Le fichier contexte http doit être le premier fichier appellé dans une application de type MVC(2), voici comment faire :

Fichier public/index.php :

<?php

require dirname(__FILE__).'/../contexts/http.php';

Fichier public/.htaccess (compatible Apache 2 uniquement) :

RewriteEngine On

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} !-f
RewriteRule ^.*$ /index.php [L}

Contexte Batch

Fichier bin/mon-batch1-qui-fait-quelque-chose-de-precis.php :

<?php

require_once dirname(__FILE__).'/../contexts/batch.php';

// écrire ici la logique spécifique du batch 1
// ...

Fichier bin/mon-batch2-qui-fait-quelque-chose-de-precis.php :

<?php

require_once dirname(__FILE__).'/../contexts/batch.php';

// écrire ici la logique spécifique du batch 2
// ...

Contexte Tests Unitaires (PHPUnit)

Fichier tests/phpunit/MonPackage/MonServiceTest.php :

<?php

require_once dirname(__FILE__).'/../../../contexts/phpunit.php';

class MonPackage_MonServiceTest extends PHPUnit_Framework_TestCase
{
    public function setUp()
    {
        $this->f = new MonPackage_MonService();
    }

    public function testSomethingForNormalCaseReturnTrue()
    {
        $this->assertTrue($this->f->someting());
    }

    // ...
}

Contexte Tests Fonctionnels (GreenPepper)

Fichier tests/greenpepper/MonPackage/MonServiceFixture.php :

<?php

require_once dirname(__FILE__).'/../../../contexts/greenpepper.php';

class MonPackage_MonServiceFixture
{
    public function something()
    {
        $r = null;
        try {
            $s = new MonPackage_MonService();
            $r = $s->something();
        } catch (Exception $e) {
            $r = 'erreur: '.$e->getMessage();
            return $r;
        }

        // for debug only
        gpLog(__METHOD__.' => '.var_export($r,true));

        return $r;
    }

    // ...
}

Ajouter un nouveau contexte d'appel

Si vous avez besoin d'ajouter un nouveau contexte d'appel à votre application, par exemple PHP-GTK (si votre application doit tourner en mode desktop client lourd PHP-GTK), vous pouvez créer le fichier suivant par exemple :

Fichier contexts/php-gtk.php :

<?php

$context = 'gtk';

require_once dirname(__FILE__).'/@common.php';

// traitement spécifique à GTK : ajout du répertoire des classes graphiques à l'include path, initialisation des évènements, ...

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/../library-gtk');

// ...

Il vous suffit maintenant de faire en sorte que vos script d'appel GTK utilise votre nouveau fichier de contexte :

Fichier bin/gtk-main.php :

<?php

require_once dirname(__FILE__).'/../contexts/php-gtk.php';

// lancement de l'application avec les spécificités du script GTK...
// ...

Conclusion

Il est important de distinguer le code commun et le code spécifique aux contextes d'appel de votre application, cela vous permettra entre autre :

de factoriser votre code
de capitaliser sur un coeur applicatif pouvant être réutiliser dans d'autres mode de lancement (ligne de commande, web, graphique...)
de ne pas charger l'ensemble de toutes les configurations nécessaires pour tous les contextes à chaque fois (ajout des répertoires de tests à l'include path...)
...

Et vous quels sont vos pratiques pour rendre une application multi-contextuelle ?

include_path + conventions + autoload = chargement automatique des classes PHP

Olivier Hoareau — Mon, 03 Aug 2009 11:52:00 +0100

Vous avez des dizaines de require/include en début de chacun de vos script ?
Pire dans vos scripts PHP, un peu partout ?
Et si l'autoload vous changeait la vie !

Les fonctions d'inclusion en PHP

Les fonctions include et require permettent à tout endroit d'un script PHP d'inclure le contenu d'un autre fichier php à un endroit précis. Voici un exemple d'utilisation :

<?php
require 'MonEntreprise/Xml/Service.php';

Plus que des fonctions, il s'agit de directives PHP, elles peuvents donc être appelées avec ou sans leur parenthèses :

<?php
require ('MonEntreprise/Xml/Service.php');
require  'MonEntreprise/Xml/Service.php' ;

Les 4 fonctions disponibles

Il existe 4 fonctions principales pour inclure un fichier PHP dans un autre :

require $file : inclusion systématique du fichier PHP avec erreur fatale si $file n'existe pas
include $file : inclusion systématique du fichier PHP avec warning si $file n'existe pas (mais le script continue)
require_once $file : inclusion du fichier $file uniquement que si il n'a jamais été inclus (une seule inclusion même si plusieurs appels), même comportement d'erreur que require
include_once $file : inclusion du fichier $file uniquement que si il n'a jamais été inclus (une seule inclusion même si plusieurs appels), même comportement d'erreur que include

Attention, dans le cas de l'utilisation des inclusions en *_once, le chemin transmis en tant que paramètre doit être strictement le même pour que l'inclusion ne se fasse qu'une seule fois :

<?php
/**
  * les deux lignes suivantes sont exécutées et le fichier
  * est inclus 2 fois, bien que ce soit physiquement le même fichier :
  */

require_once 'contexts/http.php';
require_once 'c:/dev/workspace/depot-silo/contexts/http.php';

Chemin du fichier à inclure

Il existe plusieurs possibilités pour indiquer le nom du fichier :

un chemin absolu, ex: c:/dev/workspace/mon-projet/library/MonEntreprise/Xml/service.php
un chemin relatif, ex: ../../library/MonEntreprise/Xml/service.php
un chemin basé sur l'include path, ex: MonEntreprise/Xml/Service.php

l'Include path

L'include path en PHP est une notion similaire au concept de class path en Java.
Il s'agit d'une liste de répertoire dans lesquels PHP tentera de chercher les ressources (fichiers) à inclure.

Les fonctions d'inclusions (require/include) sont donc massivement basées sur l'include path et tente de cherche les fichiers indiqués dans ces répertoires.

D'autres fonctions PHP (ex: file_get_contents) peuvent utiliser l'include_path.

L'include path est donc une " chaîne de caractère " listant un ensemble de répertoires, séparés par un séparateur dépendant de la plateforme (: pour *nix, ; pour windows) :

Exemple sous windows: .;c:/php/pear
Exemple sous linux:   .:/usr/share/pear

Paramétrer l'include path

Il existe plusieurs possibilités pour positionner/modifier l'include path PHP :

soit pour tout les scripts / requêtes
soit pour l'exécution précise / requête en cours

Paramétrage global pour tout les scripts

Il suffit de modifier la directive "include_path" du fichier php.ini :

include_path = .:/usr/share/pear:/opt/mon-repertoire-perso

Paramétrage local à l'exécution du script en cours

Il suffit d'utiliser la fonction "set_include_path()" n'importe où dans votre script :

<?php
set_include_path(get_include_path() . PATH_SEPARATOR
     . '/opt/mon-repertoire-perso');

L'utilisation de get_include_path() permet de récupérer l'include_path actuel (pour éviter de perdre les répertoires déjà listés).
La constante PATH_SEPARATOR est automatiquement positionnée par PHP avec ":" sous linux et ";" sous windows.

Exemple d'utilisation peut importe le type de paramétrage

Si le répertoire /opt/mon-repertoire-perso a été ajouté à l'include_path, et si le fichier /opt/mon-repertoire-perso/mon-script.php existe, alors les lignes suivantes permettront d'inclure le fichier :

<?php
// par rapport à /opt/mon-repertoire-perso/
include 'mon-script.php';

// par rapport à /opt/mon-repertoire-perso/
require 'mon-script.php'; 

// par rapport à /opt/mon-repertoire-perso/
include '../mon-repertoire-perso/mon-script.php'; 

// par rapport à /usr/share/pear/
include '../../../opt/mon-repertoire-perso/mon-script.php';

L'instanciation de classes

PHP est compatible programmation orientée objet. Il est possible de développer en utilisant classes, méthodes, interfaces...

Voici un exemple de classe php qui hérite de la classe standard Exception, avec un constructeur (attention pas de polymorphisme en php) :

<?php
// définie la classe d'exception

class MonException extends Exception
{
    private $params;

    public function __construct($message,$code,$params)
    {
        parent::__construct($message,$code);
        $this->params = $params;
    }

    public function getParams()
    {
        return $this->params;
    }
}

// instancie l'exception

$exception = new MonException();

// lève l'exception instanciée

throw $exception;

Il est aussi possible, et recommandé de déplacer la définition des classes dans des fichiers bien distinct portant le nom de la classe :

Fichier library/MonException.php :

<?php
class MonException extends Exception
{
    private $params;

    public function __construct($message,$code,$params)
    {
        parent::__construct($message,$code);
        $this->params = $params;
    }

    public function getParams()
    {
        return $this->params;
    }
}

Script principal mon-script.php :

<?php
set_include_path(get_include_path().PATH_SEPARATOR
    .dirname(__FILE__).'/library');

require_once 'MonException.php';

throw new MonException();

L'utilisation de set_include_path() permet d'ajouter le répertoire library/ dans l'include path et permet ainsi aux fonctions d'inclusions de trouver le fichier contenant la classe.
L'utilisation de require_once permet de ne charger qu'une seule fois le fichier MonException.php, au cas où il aurait été déjà chargé si le script mon-script.php est lui même inclus par un autre script qui avait déjà chargé le fichier MonException.php, et donc permet de ne charger qu'une seule fois la définition de la classe MonException (sinon PHP lève une erreur fatale dès que 2 définitions de classes portent le même nom).

Autoload: où chargement automatique des classes en PHP

Lors de la première utilisation d'une classe dans un script, il est possible d'inclure automatiquement sa définition si elle placée dans un fichier respectant certaines conventions.
En effet, le script mon-script.php suivant :

<?php
class MaClass
{
    public function maMethod()
    {
       return 'result';
    }
}

$o = new MaClass();
echo $o->maMethod();

peut être remplacé par 2 fichier :

library/MaClass.php :

<?php
class MaClass
{
    public function maMethod()
    {
       return 'result';
    }
}

mon-script.php :

<?php
set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__).'/library');
function  __autoload($className)
{
    require_once $className.'.php';
}

$o = new MaClass();
echo $o->maMethod();

En effet, PHP propose le mécanisme d'autoload permettant de définir une fonction qui sera automatiquement appelée dès que PHP détectera l'utilisation d'une classe inconnue.
Dans notre cas, dans le fichier mon-script.php, la première utilisation de la classe MaClass est faite lors de l'utilisation de l'opérateur d'instanciation (new) : nous tentons d'instancier la classe sans avoir inclus le fichier de définition de la classe. PHP déclenche alors le mécanisme d'autoload CAR nous avons définit avant une fonction callback spéciale nommée __autoload($className), charge à notre fonction d'inclure le fichier qui porte le nom de la classe en espérant qu'il existe dans l'include path.

Autoload, classes et packages

Avec PHP < 5.3, le concept de package/namespace n'existe pas réellement et nous sommes obligés d'avoir recours à certains artifices pour simuler le concept de package (comme nous pourrions l'avoir dans d'autres langages objet) :

par exemple la classe MaClass dans le package MonPackage situé dans le fichier library/MonPackage/MaClass.php :

<?php
class MonPackage_MaClass
{
    public function maMethod()
    {
        return 'result';
    }
}

et le script mon-script.php qui utilise cette classe grâce à un autoload adapté :

<?php
set_include_path(get_include_path().PATH_SEPARATOR
    .dirname(__FILE__).'/library');
function  __autoload($className)
{
    require_once str_replace('_','/',$className).'.php';
}

$o = new MonPackage_MaClass();
echo $o->maMethod();

Autoload à la mode SPL (Standard PHP Library)

la fonction magique autoload() est un mécanisme standard php. Cependant l'extension SPL, devenu standard depuis quelques temps en PHP 5 permet de fournir plusieurs fonctions autoload selon une syntaxe légèrement différente (le principe est le même) :

<?php

function maFonctionAutoload1($className)
{
    if ('Pkg1_' !== substr($className,0,5)) {
        return false;
    }
    require_once 'repertoire1/'
        .str_replace('_','/',$className).'.php';
}

function maFonctionAutoload2($className)
{
    if ('Pkg2_' !== substr($className,0,5)) {
        return false;
    }
    require_once 'repertoire2/'
        .str_replace('_','/',$className).'.php';
}

spl_autoload_register('maFonctionAutoload1');
spl_autoload_register('maFonctionAutoload2');

// ...

Classe d'autoload

Pour ceux qui développe 100% en objet, il est possible d'utiliser une méthode d'autoload plutôt qu'une fonction via SPL :

Fichier library/Autoloader.php :

<?php
class Autoloader
{
    public function __construct()
    {
        // ajout du répertoire parent (library/) à l'include path

        set_include_path(get_include_path()
            .PATH_SEPARATOR.realpath(dirname(__FILE__).'/..'));
        spl_autoload_register(array('Autoloader','autoload'));
    }
    public function autoload($className)
    {
        require_once str_replace('_','/',$className).'.php';
    }
}

Script mon-script.php :


/**
  * inclusion de l'autoloader avec chemin absolu
  * car l'include path n'est pas encore positionné
  */

include dirname(__FILE__).'/library/Autoloader.php';

$o = new MaClass();

echo $o->maMethod();

Conclusion

Grâce à cette technique vous n'aurez plus besoin d'utiliser les require/include dans vos scripts, si vous développez objet et si vous nommez correctement vos classes/fichiers Les frameworks Zend Framework, Symfony, ... proposent des modules d'auto-chargement basés sur ces principes (dans les grandes lignes).

Attention cependant à certains points :

plus il y a de répertoires listés dans l'autoload et plus vous aurez potentiellement un impact sur les performances
les répertoires contenant les classes les plus "populaires" (i.e. les plus utilisées dans votre code) doivent se situer au début de l'include path, pour optimiser les performances, notamment les répertoires des frameworks
si vous développez un framework ou une librairie, privilégiez l'utilisation explicite des require_once plutôt que l'autoload, car votre librairie sera incluse dans une application qui aura peut être son propre mécanisme d'include path potentiellement incompatible avec le votre
vous devez avoir une rigueur à toute épreuve pour le nommage et le placement de vos classes/fichiers : 1 fichier par classe, 1 classe par fichier, les fichiers portent le même nom que les classes.

Et vous quelles sont vos pratiques pour le nommage / rangement et auto-chargement de vos classes ?

DNS + Proxy + Header, où comment gérer le déplacement d'un site internet en douceur

Olivier Hoareau — Fri, 24 Jul 2009 18:15:00 +0100

Cela vous est probablement déjà arrivé de devoir déplacement un site internet sur un autre serveur. L'adresse IP du serveur n'étant plus la même, il faut alors modifier l'entrée DNS (souvent A, mais peut être CNAME) pour que le nom de domaine pointe maintenant sur l'adresse IP du nouveau serveur. Mais cela peut prendre du temps pour se propager...

Si vous aviez prévu votre opération depuis longtemps, vous aviez certainement "abaissé" les TTL (i.e. Time To Live), à 10 minutes par exemple, qui permettent d'indiquer aux différents équipements internets combien de temps ils doivent garder en cache la correspondance DNS<=>IP récupérée depuis le serveur DNS primaire.

Que vous ayez prévu ou pas de baisser les TTL, certains (vieux) équipements ne suivent pas forcéments à la lettre ce paramétrage, et alors c'est le drame, tout une partie de vos utilisateurs accèdent toujours à l'adresse IP de l'ancien serveur pendant un peu plus longtemps.

Voici une technique que je mets en place pour pallier à ce problème :

dupliquer / (ré-)installer le site sur le nouveau serveur
tester le nouveau serveur en mettant la correspondance DNS <=> IP dans votre fichier etc/hosts de votre ordinateur personnelle (portable,...) temporairement
une fois le test ok, modifier les DNS chez votre registrar/serveurs dns en migrant le DNS vers la nouvelle IP
sur l'ancien serveur, modifier la configuration apache pour que le serveur apache fasse proxy vers le nouveau serveur apache
ajouter la même ligne que vous aviez précédemment mise dans votre etc/hosts perso dans celui de l'ancien serveur
remplacer la directive DocumentRoot de votre virtual host de l'ancien serveur par ces lignes

ProxyPass / http://mon.domaine.com/
ProxyPassReverse / http://mon.domaine.com/
Header add Old-Server yes

redémarrer votre ancien serveur apache

Le principe est simple : tant que l'équipement internet utilisé par l'internaute n'a pas mis à jour son cache, il pointera toujours sur l'ancienne IP, mais ce serveur fera proxy vers le nouveau serveur pour servir exactement le même contenu et surtout, si vous avez une base de données derrière votre site internet, ira mettre à jour la nouvelle base de données (pas besoin de faire une seconde migration ! Lorsque l'équipement utilisé par l'internaute sera à jour il pointera directement sur l'adresse IP du nouveau serveur et ne passera donc plus par le proxy.
Si vous utilisez Firefox, vous pourrez par exemple vous servir du plugin Firebug pour vérifier que le header "Old-Server: yes" n'est plus transmis, car tant qu'il est transmis, vous pointez sur l'ancien serveur.

Comment savoir quand je pourrais désinstaller / supprimer l'ancien serveur ?

Il vous suffira de regarder dans les logs de l'ancien serveur web, si vous site internet est très utilisé / populaire, vous allez pouvoir observer une baisse significative des logs à un moment donné. Lorsque plus aucune ligne de log n'apparaîtra depuis plusieurs heures/jours, vous pourrez sereinement supprimer cet ancien serveur.

Et vous, quelles sont vos pratiques ? Il s'agit d'une "bidouille" pour être plus serein, je suis sûr que vous en avez d'autres !

10 conseils pour réussir son projet de développement en équipe

Olivier Hoareau — Wed, 22 Jul 2009 09:50:00 +0100

Voici 10 conseils pragmatiques que j'utilise au quotidien chez mes clients...

Si parmi vos enjeux vous avez :

développer votre business / sortir un service concurrentiel
montrer rapidement votre avancement à vos commanditaires
rationnaliser les développements pour éviter les dispersions, pertes de temps et hétérogénéité du code
utiliser au mieux les compétences de chacun, faire en sorte que les meilleurs ne s'ennuient pas et que les meilleurs poussent les autres à l'excellence
capitaliser des compétences / briques techniques / logiciels
...

Voici 10 conseils pour réussir et performer dans votre/vos projet(s) :

Gardez le contrôle sur le code (mesurer, vérifier, tester)
L'excellence attire l'excellence : (innover, exprimer, montrer l'exemple)
rationnalisez les pratiques (documenter, vérifier)
rationnalisez les outils (choisisser, installer, former)
utilisez l'intégration continue (installer, paramétrer)
mettez en place une méthodologie itérative courte (raccourcir, itérer)
utilisez la technique de l'entonnoir (laissez-vivre => rationnalisez, laissez-vivre => rationnalisez, ...)
prenez en compte le feedback à tous les niveaux (observer, apprendre, corriger)
KISS : Keep It Short and Simple (faire TOUJOURS simple)
DRY : Don't Repeat Yourself, ou factorisez / réutilisez (faire TOUJOURS 1 seule fois)

Bien sûr, ces conseils ne sont pas exhaustifs, vous en avez probablement d'autres vous aussi, quels sont-ils ?

AgileTour 2009 @ Bordeaux : 3 sessions proposées

Olivier Hoareau — Wed, 22 Jul 2009 08:15:00 +0100

Cette année l'AgileTour passe à Bordeaux le 29 Octobre, l'occasion pour moi de proposer quelques sujets de sessions...

Pour ceux qui ne connaissent pas l'AgileTour, il s'agit d'une "tournée" dans plusieurs villes de france (mais pas uniquement), pour :

promouvoir massivement l'Agilité
partager nos visions de l'Agilité
fédérer
soutenir

Le 29 octobre 2009, l'AgileTour 2009 s'arrêtera à Bordeaux, aux quelques rues de chez moi ;), à cette occasion, je vous propose quelques sujets de sessions autour de l'agilité et de PHP :

TDR : Tests Fonctionnels Automatisables / Exécutables, où l'outil qui redonne la maîtrise au MOA (30min, Dojo)
TDD : Test Driven Development en PHP (1h, Dojo)
Le quotidien d'une équipe Agile, retours d'expériences (30min, conférence)

Venez nombreux si ces sujets ou bien d'autres vous intéressent !

Le site internet de l'évènement : http://agiletour.org

Intégration PHPUnit dans Eclipse

Olivier Hoareau — Wed, 08 Jul 2009 23:18:00 +0100

Une nouvelle intégration de PHPUnit 3.x dans Eclipse à la mode JUnit

J'utilise Zend Studio et Eclipse PDT au quotidien chez mes clients.
Adepte du TDD (Test Driven Development), le support de PHPUnit dans Zend Studio est devenu plus qu'un confort pour moi, une véritable nécessité.
Pour mes clients qui choisissent Eclipse PDT plutôt que Zend Studio, j'étais jusqu'alors résigné à créer des boutons external tools dans Eclipse pour lancer en ligne de commande phpunit (efficace, mais rendu non graphique en mode console qui peut rebuter certains).
Sur ma demande d'aide, un de mes anciens collègues, Java-iste dans l'âme, et PHP-iste à ses heures perdues, a développé une intégration de PHPUnit 3.x dans Eclipse en open source. Il s'agit d'un wrapper au plugin JUnit 4 existant dans Eclipse JDT permettant de lancer les tests unitaires PHPUnit (via la ligne de commande en fait) et d'afficher les résultats tel que JUnit le fait (et tel que le plugin PHPUnit de Zend Studio le fait). Bien sûr il s'agit d'un premier jet, vos idées / remarques / demandes d'amélioration sont les bienvenues !

Sans plus attendre le site du projet open source : http://code.google.com/p/phpunit4eclipse/wiki/j2phpUnitWrapper

La question est posée : "PHP : POO ou (exclusif) Procédural ?"

Olivier Hoareau — Thu, 25 Jun 2009 23:12:00 +0100

Un de mes clients se pose la question "PHP : Faire du POO ou du Procédural ?"

Certains clients sont à juste titre souvent réticent à passer à du tout objet, notamment en PHP.

De mon point de vue, le débat n'est pas forcément POO ou Procédural (même si, je l'avoue je suis un POO-convaincu), mais plutôt, industrialisés/rationnalisés/maîtrisés/testables/bouchonnables versus "non homogènes, non-bonnes pratiques,non cadrés, non-testable".

L'implémentation POO que je propose en règle général de mettre en place à mes clients correspond dans une certaine mesure à une compilation de fonctions rangées par groupes qui correspondent à des classes et des packages (répertoires).
Concrètement il ne s'agit pas de POO pure mais plutôt d'une forme de POO "allégée" avec des fonctionnalités de procédural (ex: une classe "PliService" qui contient une liste de méthodes listPlis(), getPlis(), deletePli($pliId), addPli($pliInfos), ...) en POO pur on aurait plutôt eu une classe "Pli" avec les méthodes "save(), delete(), check(), send()...".
Les avantages induits, sont qu'étant en programmation objet (même non puriste), nous pouvons bénéficier d'un certains nombre de design patterns pertinents tels que Adapter, Mock, Singleton, MVC... et bien sûr ne pas réinventer la roue et utiliser des composants tout fait tels que ceux proposer par ZF (ou d'autres frameworks) et pouvoir les étendre facilement pour les adapter à nos besoins (pas possible en procédural).

D'autre part, je suis loin d'être omniscient, mais je ne connais aucune librairie ou framework, développée récemment ou activement développée (en dehors de produit sur étagère bien spécifique) qui soient full procédural, tous sont POO-enabled, a priori, cela marque bien la mouvance actuelle que prend PHP pour sa professionnalisation.

Au delà de POO versus procédural, les questions concrètes auxquelles il faut répondre sont :

comment j'organise mes fichiers
comment je factorise mes fonctionnalités
comment je rend testable / bouchonnable mes fonctionnalités
comment je séparer la logique, du rendu, comment j'utilise une seule fois la logique pour plusieurs rendu différent
comment j'interface les outils de tests fonctionnels exécutables (une NECESSITE pour les fonctionnels et donc pour ceux qui motivent les développements)
comment je garanti qu'un nouveau développeur pourra prendre en main n'importe quelle partie du code sans trop de douleurs
comment je garantie qu'il n'y aura pas de collision de nommage entre mes fonctionnalités
comment je garantie que mes développeurs ne seront indépendants et ne s'interbloqueront pas mutuellement dans leur développement (i.e. travailleront sur des fichiers différents)
comment je package mon application pour qu'elle soit facilement déployable sur un environnement de production différent de l'environnement de développement
comment j'intègre mon code à une usine de développement de type intégration continue
comment je garantie que mes développeurs peuvent à tout moment exercer leurs connaissances précédemment acquises sans forcément avoir assimilé tout les concepts, frameworks, librairies, techniques, méthodes (what ever you want), qui composent la stack applicative et de pratiques mises en place pour les développement.
comment je capitalise sur mes développements pour tout mon parc applicatif (pas seulement que pour une seule application)
... (j'ai de multiples questions de ce type encore...)

De mon point de vue, POO-allégée (celle que je propose au quotidien à mes clients), permet avec tout un tas de conventions (que je propose aussi à mes clients) de répondre à la majorité de ces questions. Une utilisation procédurale-exclusive de PHP avec des conventions adaptées pourraient je pense répondre positivement à pas mal de ces questions, toutes je ne sais pas (admettons, je n'ai pas essayé), elle irait juste à rebrousse-poil de tout ce que la communauté PHP met en oeuvre depuis l'arrivée de PHP 5 (et des iterators, des exceptions, des interfaces, des classes, ...).

Petit rappel, en PHP, contrairement à Java, TOUT N'EST PAS OBJET, ce qui veut dire que finalement si on fait des classes et objets, à l'intérieur de leurs méthodes, ce sont des fonctions (procédurales) qui sont utilisées (toutes la batteries de fonctions très fournies que PHP propose en standard). La structuration en classe, est donc une coquille qui permet de s'organiser et de rendre plus clair la modélisation et la séparation de responsabilité (MVC et autres joyeusetées).

Zend Framework (ou Symfony dans une certaine mesure) n'est finalement qu'une implémentation de tout un tas de design patterns (i.e. de réponses à des problèmes connus, traités une bonne fois pour toute), ne pas utiliser ni Zend Framework, ni tout autre framework, reviendrait à faire une croix sur les solutions aux problèmes communs déjà trouvés par toutes les communautés.
Une limitation cependant, tout framework "généraliste" prend sa force dans la généralité, pas dans l'adéquation à des besoins spécifiques (tels que la performance, la finesse, l'exhaustivité...). Il est donc très souvent nécessaire de se poser la question "Pour ce besoin précis, dois-je prendre tel composant de tel framework ou dois-je mettre en oeuvre mon propre développement ?", la réponse dépend du contexte, 8 fois sur 10, il ne sera pas nécessaire de redévelopper votre propre composant, ceux déjà existant suffiront (et seront éprouvés / matures / stables / documentés / utilisés contrairement à vos éventuels développements à mener), mais 2 fois sur 10, les composants spécifiques montreront leurs limites et vous devrez créer le vôtre aux petits oignions. Faire une croix sur la POO et/ou les frameworks existants vous pénalisera dans 8 cas sur 10, et ne vous aidera pas non plus dans les 2 autres cas sur 10 (c'est dommage, vous êtes dans le monde de l'open source avec PHP, vous auriez pu prendre/étendre/réutiliser/améliorer) il faut en être conscient. Il est possible alors de créer son propre framework (c'est peut être ce que certains ont fait), pourquoi serait-il mieux qu'un framework téléchargé plus de x millions de fois, financé par Google, Adobe, IBM,... et utilisé chez de plus en plus de grand comptes entre autres français ?

Le grand débat dans les grands comptes est souvent ZF ou Symfony, jamais POO ou Procédural (en tout cas chez ceux que j'ai eu la chance de croiser jusqu'alors), mais bon pourquoi pas, c'est peut être les autres qui se trompent me dira-t-on...

Et vous, la communauté, quel est votre point de vue ?

PS: PHP 4 n'est plus supporté depuis plus d'un an, si vous développez procédural only, n'oubliez pas de mettre à jour vos pratiques pour être au moins compatibles avec les bonnes pratiques de développement procédural en PHP 5 ;)

Installer HUDSON sur Ubuntu 8.10 sur le port 80

Olivier Hoareau — Fri, 05 Jun 2009 19:02:00 +0100

Voici la procédure que j'ai déroulée pour installer l'outil d'intégration continue Hudson (v1.3.09) sur un serveur sous Ubuntu 8.10 (64 bits) complètement vierge.

Connexion SSH sur le serveur en mode root
Création d'un utilisateur ayant les droits sudo

adduser ohoareau
adduser ohoareau admin

Nommer à la machine

echo nomdelamachine > /etc/hostname

Redémarrage pour prendre en compte le nom de machine

reboot

Connexion en SSH avec l'utilisateur nouvellement créé (ohoareau)
Mise à jour de APT

sudo apt-get update

Installation de PHP et PEAR

sudo apt-get install php5
sudo apt-get install php5-pear

Paramétrage de l'horloge réseau

sudo ntpdate fr.pool.ntp.org

Installation d'un serveur de mail pour l'envoi des mails vers l'extérieur

sudo apt-get install postfix

Installation des channels et paquets PEAR nécessaire pour le build avec Phing

sudo pear upgrade pear
sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover pear.xplib.de
sudo pear channel-discover pear.pdepend.org
sudo pear channel-discover pear.phing.info
sudo pear channel-discover pear.phppro.fr
sudo pear update-channels
sudo pear upgrade pear
sudo pear install --force VersionControl_SVN Console_ProgressBar XML_Serializer
sudo pear install --alldeps phpunit/PHPUnit
sudo pear install phpunit/phpcpd
sudo pear install --alldeps PHP_CodeSniffer
sudo pear install --alldeps --force pdepend/PHP_Depend
sudo pear install --alldeps --force PHP_UML
sudo pear install PHP_CompatInfo
sudo pear install --alldeps phing/phing
sudo pear install phppro/phpcr
sudo pear install PhpDocumentor
sudo pear install XML_Beautifier

Installation de XDebug pour PHP (pour la couverture de code)

sudo apt-get install php5-xdebug

Mise à jour du paramétrage par défaut de PHP

sudo vi /etc/php5/cli/php.ini

Modifiez la ligne suivante dans le fichier /etc/php5/cli/php.ini :

memory_limit = 128M

Installation de Java (JDK/JRE) pour Hudson

sudo apt-get install openjdk-6-jdk openjdk-6-jre

Ajout du repo hudson distant

vi /etc/apt/sources.list

Ajoutez la ligne suivante dans le fichier /etc/apt/sources.list :

deb http://hudson-ci.org/debian binary/

Installation d'Hudson (par défaut sur le port 8080)

sudo apt-get install hudson

Installation de LightHTTPD sur le port 80 pour faire proxy vers Hudson

sudo apt-get install lighttpd
sudo vi /etc/lighttpd/conf-available/10-hudson.conf

Copiez le contenu suivant dans le fichier /etc/lighttpd/conf-available/10-hudson.conf :

## Let lighttpd act as a proxy server for special file types, hosts etc
##
## Documentation: /usr/share/doc/lighttpd-doc/proxy.txt
##                http://www.lighttpd.net/documentation/proxy.html

server.modules   += ( "mod_proxy" )

## Balance algorithm, possible values are: "hash", "round-robin" or "fair" (default)
# proxy.balance     = "hash"


$HTTP["host"] == "nomdelamachine" {
  proxy.balance = "hash"
  proxy.server  = ( "" => ( ( "host" => "nomdelamachine", "port" => 8080 ) ) )
}

Rédemarrage de Lighttpd

sudo /etc/init.d/lighttpd restart

Normalement, vous pouvez accédez à l'interface d'Hudson via l'url http://nomdelamachine (attention à mettre à jour votre etc/hosts sur le poste du navigateur si il s'agit d'un nom qui n'est pas renseigné sur les dns publique internet)

Il est possible que des erreurs ce soient glissées n'hésitez pas à le dire !

Exemple de fichier build.xml pour un projet utilisant l'intégration continue

Olivier Hoareau — Fri, 05 Jun 2009 16:08:00 +0100

Vous utiliser PHP, Phing et vous souhaitez utiliser hudson, Xinc ou PHPUnderControl avec Phing

Voici un fichier build.xml qui me sert souvent de base pour automatiser mes builds php en intégration continue. Il n'est pas parfait, n'hésitez pas à proposer des améliorations ou proposer vos variantes / exemples, ils sont les bienvenus !

<?xml version="1.0" encoding="UTF-8"?>

<!-- vim: set expandtab tabstop=4 shiftwidth=4: -->

<project name="php" default="help">

    <!-- ================================================================== -->
    <!-- Properties                                                         -->
    <!-- ================================================================== -->
    
    <!-- *** Project General Properties *********************************** -->

    <property name="home"         value="${project.basedir}"/>
    <property name="src.dir"      value="library"/>
    <property name="test.dir"     value="tests"/>
    <property name="report.dir"   value="reports"/>
    <property name="doc.dir"      value="docs"/>
    <property name="context.dir"  value="contexts"/>
    <property name="config.dir"   value="config"/>
    <property name="convention"   value="PEAR"/>

    <!-- *** Project Custom Properties ************************************ -->

    <property file="${home}/${config.dir}/build.properties"   override="true"/>
    <property file="${home}/${config.dir}/${conf}.properties" override="true"/>

    <!-- *** Project Common Properties ************************************ -->

    <property name="package.name"   value="${application.name}"/>

    <!-- ================================================================== -->
    <!-- Targets                                                            -->
    <!-- ================================================================== -->

    <!-- *** $ phing help ************************************************* -->

    <target name        = "help"
            depends     = ""
            description = "Information about this build file">

        <echo>${package.name} Phing Build commands</echo>

    </target>

    <!-- *** $ phing inits ************************************************ -->

    <target name        = "inits"
            depends     = ""
            description = "Initializes the application environment">

        <!-- /library -->
        <mkdir dir="${home}/${src.dir}"/>

        <!-- /tests -->
        <mkdir dir="${home}/${test.dir}"/>
        <mkdir dir="${home}/${test.dir}/phpunit"/>
        <mkdir dir="${home}/${test.dir}/fitnesse"/>
        <mkdir dir="${home}/${test.dir}/selenium"/>
        <mkdir dir="${home}/${test.dir}/jsunit"/>

        <!-- /reports -->
        <mkdir dir="${home}/${report.dir}"/>
        <mkdir dir="${home}/${report.dir}/phpunit"/>
        <mkdir dir="${home}/${report.dir}/coverage"/>
        <mkdir dir="${home}/${report.dir}/codesniffer"/>

        <!-- /docs -->
        <mkdir dir="${home}/${doc.dir}"/>
        <mkdir dir="${home}/${doc.dir}/api"/>

        <!-- /contexts -->
        <mkdir dir="${home}/${context.dir}"/>

    </target>

    <!-- *** $ phing tests-unit ******************************************* -->

    <target name        = "tests-unit"
            depends     = "inits"
            description = "Executes unit tests (PHPUnit)">

        <php expression="require_once '${home}/${context.dir}/phpunit.php'"/>

        <phpunit2 haltonfailure="false" printsummary="true">
            <batchtest classpath="${home}/${src.dir}">
                <fileset dir="${home}">
                    <include name="${test.dir}/phpunit/**/*Test.php" />
                </fileset>
            </batchtest>
            <formatter type    = "xml"
                       todir   = "${home}/${report.dir}/phpunit"
                       outfile = "tests-report.xml" />
        </phpunit2>

        <phpunit2report
            infile = "${home}/${report.dir}/phpunit/tests-report.xml"
            format = "frames"
            todir  = "${home}/${report.dir}/phpunit" />

    </target>

    <!-- *** $ phing tests-unit-with-coverage ***************************** -->

    <target name        = "tests-unit-with-coverage"
            depends     = "inits"
            description = "Executes unit tests (PHPUnit), coverage (XDebug)">

        <php expression="require_once '${home}/${context.dir}/phpunit.php'"/>

        <coverage-setup database="${home}/${report.dir}/coverage/coverage.db">
            <fileset dir="${home}">
                <include name="${src.dir}/**/*.php" />
                <exclude name="${src.dir}/**/*Test.php" />
            </fileset>
        </coverage-setup>

        <phpunit2 haltonfailure = "false"
                  printsummary  = "true"
                  codecoverage  = "true">
            <batchtest classpath="${home}/${src.dir}">
                <fileset dir="${home}">
                    <include name="${test.dir}/**/*Test.php" />
                </fileset>
            </batchtest>
            <formatter type    = "xml"
                       todir   = "${home}/${report.dir}/phpunit"
                       outfile = "tests-report.xml" />
        </phpunit2>

        <coverage-report outfile="${home}/${report.dir}/coverage/coverage.db">
            <report todir="${home}/${report.dir}/coverage" />
        </coverage-report>

        <phpunit2report
            infile = "${home}/${report.dir}/phpunit/tests-report.xml"
            format = "frames"
            todir  = "${home}/${report.dir}/phpunit" />

    </target>

    <!-- *** $ phing tests-functional ************************************* -->

    <target name        = "tests-functional"
            depends     = "inits"
            description = "Executes functional tests (Fitnesse)">


    </target>

    <!-- *** $ phing tests-javascript ************************************* -->

    <target name        = "tests-javascript"
            depends     = "inits"
            description = "Executes javascript tests (JSUnit)">


    </target>

    <!-- *** $ phing tests-gui ******************************************** -->

    <target name        = "tests-gui"
            depends     = "inits"
            description = "Executes graphical user interface tests (Selenium)">


    </target>

    <!-- *** $ phing tests ************************************************ -->

    <target name        = "tests"
            depends     = "tests-unit-with-coverage,tests-functional,tests-javascript,tests-gui"
            description = "Generates all tests reports for project">



    </target>

    <!-- *** $ phing checks-convention ************************************ -->

    <target name        = "checks-convention"
            depends     = "inits"
            description = "Checks the quality of the code towards convention">
            
        <php expression="$cwd = getcwd()" returnProperty="cwd"/>

        <phpcs  outputFile   = "${home}/${report.dir}/codesniffer/checks-report.xml"
                standard     = "${convention}"
                showWarnings = "true"
                tabWidth     = "4"
                format       = "checkstyle">
                <fileset dir="${home}/${src.dir}">
                <include name="**/*.php" />
                <include name="**/*.phtml" />
            </fileset>
        </phpcs>

        <php expression="chdir('${cwd}')"/>
        
        <xslt file   = "${home}/${report.dir}/codesniffer/checks-report.xml"
              tofile = "${home}/${report.dir}/codesniffer/index.html"
              style  = "${home}/${config.dir}/codesniffer.xsl" />

    </target>

    <!-- *** $ phing checks-syntax **************************************** -->

    <target name        = "checks-syntax"
            depends     = "inits"
            description = "Checks the syntax of the code (Lint)">

        <phplint haltonfailure="true">
            <fileset dir="${home}">
                <include name="${src.dir}/**/*.php"/>
                <include name="${src.dir}/**/*.phtml"/>
            </fileset>
        </phplint>

    </target>

    <!-- *** $ phing checks *********************************************** -->

    <target name        = "checks"
            depends     = "checks-convention,checks-syntax"
            description = "Executes checking operations (convention,syntax)">



    </target>

    <!-- *** $ phing builds-on-commit ************************************* -->

    <target name        = "builds-on-commit"
            depends     = "tests-unit"
            description = "Continous integration Light-build on svn commit">



    </target>

    <!-- *** $ phing builds-nightly *************************************** -->

    <target name        = "builds-nightly"
            depends     = "tests,checks,docs"
            description = "Continuous integration full nightly-build">



    </target>

    <!-- *** $ phing docs-api ********************************************* -->

    <target name        = "docs-api"
            depends     = "inits"
            description = "Generates the PHPDocumentor API Documentation">

        <phpdoc title               = "${package.name} API Documentation"
                destdir             = "${home}/${doc.dir}/api"
                sourcecode          = "yes"
                output              = "HTML:Smarty:PHP"
                defaultcategoryname = "${package.name}"
                defaultpackagename  = "${package.name}">
            <fileset dir="${home}">
                <include name="${src.dir}/**" />
                <include name="${test.dir}/phpunit/**" />
                <include name="${test.dir}/fitnesse/**" />
            </fileset>
            <projdocfileset dir="${home}/${src.dir}">
            </projdocfileset>
        </phpdoc>

    </target>

    <!-- *** $ phing docs ************************************************* -->

    <target name        = "docs"
            depends     = "docs-api"
            description = "Generates all documentation for project">



    </target>
    
    <!-- *** $ phing deploys-testfunc ************************************* -->

    <target name        = "deploys-testfunc"
            depends     = "tests-unit"
            description = "Executes unit tests and deploys a tag of the application on functional tests platform">

        <echo>Deploying on functional tests platform...</echo>

        <echo>@todo: specific function tests platform pre-deployment tasks...</echo>

        <phingcall target="_template-deploys">
            <property name="${deploy.platform}" value="testfunc"/>
        </phingcall>
        
        <echo>@todo: specific functional tests platform post-deployment tasks...</echo>

        <echo>Application deployed on functional tests platform.</echo>

    </target>

    <!-- *** $ phing deploys-integ **************************************** -->

    <target name        = "deploys-integ"
            depends     = "tests-unit"
            description = "Executes unit tests and deploys a tag of the application on integration">

        <echo>Deploying on integration...</echo>

        <echo>@todo: specific integration pre-deployment tasks...</echo>

        <phingcall target="_template-deploys">
            <property name="${deploy.platform}" value="integ"/>
        </phingcall>
        
        <echo>@todo: specific integration post-deployment tasks...</echo>

        <echo>Application deployed on integration.</echo>

    </target>

    <!-- *** $ phing deploys-preprod ************************************** -->

    <target name        = "deploys-preprod"
            depends     = "tests-unit"
            description = "Executes unit tests and deploys a tag of the application on pre-production">

        <echo>Deploying on preproduction...</echo>

        <echo>@todo: specific preproduction pre-deployment tasks...</echo>

        <phingcall target="_template-deploys">
            <property name="${deploy.platform}" value="preprod"/>
        </phingcall>

        <echo>@todo: specific preproduction post-deployment tasks...</echo>

        <echo>Application deployed on preproduction.</echo>

    </target>

    <!-- *** $ phing deploys-prod ***************************************** -->

    <target name        = "deploys-prod"
            depends     = "tests-unit"
            description = "Executes unit tests and deploys a tag of the application on production">

        <echo>Deploying on production...</echo>

        <echo>@todo: specific production pre-deployment tasks...</echo>

        <phingcall target="_template-deploys">
            <property name="${deploy.platform}" value="prod"/>
        </phingcall>
        
        <echo>@todo: specific production post-deployment tasks...</echo>

        <echo>Application deployed on production.</echo>

    </target>

    <!-- *** internal task ************************************************ -->

    <target name        = "_template-deploys"
            depends     = "tests-unit"
            description = "Template - Executes unit tests and deploys a tag of the application on a platform">

        <if>
            <isnotset property="deploy.platform"/>
            <then>
                <fail>You must set the deploy.platform property with the name of the platform to deploy on</fail>
            </then>
        </if>

        <if>
            <isnotset property="tag"/>
            <then>
                <fail>You must provide a svn tag in order to deploy this tag on ${deploy.platform}</fail>
            </then>
        </if>

        <property file="${home}/${config.dir}/platforms/${deploy.platform}.properties" override="true" />

        <property name="deploy.src.dir" value="${home}/${build.dir}/${deploy.platform}/${tag}" />
        <property name="svn.url"        value="${svn.repo}/tags/${tag}" />

        <svnexport svnpath       = "${svn.bin}"
                   username      = "${svn.username}"
                   password      = "${svn.password}"
                   force         = "true"
                   nocache       = "true"
                   repositoryurl = "${svn.url}"
                   todir         = "${deploy.src.dir}"/>
        
        <echo>@todo : deployment (zip ${deploy.src.dir, then ftp, ...) </echo>

        <fail>@remove: Not yet implemented</fail>

    </target>

</project>

Des valeurs par défaut ... qui cachent des bugs !

Olivier Hoareau — Sat, 30 May 2009 16:18:00 +0100

function mafunction($param1,$param2='yes') { ... }

Que se passe-t-il si vous faites cet appel :

mafunction("monparam1",null);

ou bien :

mafunction("monparam1",$value2);

avec $value2 = null ?

Nous sommes souvent tenté de créer des fonctions et/ou des méthodes pour réaliser nos tâches et logique de code. C'est normal
Dans bien des cas, nous revenons sur notre code plusieurs jours/semaines/mois après pour améliorer certaines fonctionnalités ou tout bonnement en ajouter. C'est normal

Il nous arrive alors de rajouter des paramètres facultatifs (avec ces fameuses valeurs par défaut) pour ajouter une fonctionnalité tout en restant compatible avec l'existant :

/**
 * Lists enabled items of specified type
 *
 * @param string $type type of items to return
 *
 * @return array of enabled items
 */
function listItems($type) {
    // ...
    return $items;
}

vers par exemple :

/**
 * Lists items of specified type and specified status
 *
 * @param string $type type of items to return
 * @param string $status optional status (default is 'enabled')
 *
 * @return array of items
 */
function listItems($type,$status = 'enabled') {
    // ....
    if ('enabled' === $status) {
        // ...
        $items = ...
    } else {
        // ...
        $items = ...
    }
    return $items;
}

Puis nous appellons notre fonction par exemple comme ceci :

$items = listItems('users');
$items = listItems('users','enabled');
$items = listItems('users','disabled');

Jusque là tout va bien... enfin vous êtes sûr ? Finalement peut être pas tant que ça, en effet, que se passe-t-il si nous faisons ces appels :

$items = listItems('users',null);
$items = listItems('users',$status); // isset($status) === false
$items = listItems('users',$status); // $status = null

Et bien le deuxième paramètre étant fourni (null dans les 3 cas), la valeur par défaut ne sera pas prise en compte ! et la variable locale '$status' dans votre fonction 'listItems' aura la valeur ... null !
Vous saisissez le problème ? En fait, au lieu d'avoir la valeur 'enabled', valeur que vous vous attendez à avoir si le paramètre $status est non fournie (et par abus de langage, null - ce qui est donc faux), vous aurez la valeur null.
Il est donc nécessaire systématiquement de rajouter un test à l'intérieur de la fonction :

function listItems($type,$status = 'enabled') {
    if (!$status) {
        $status = 'enabled';
    }
    // ....
    if ('enabled' === $status) {
        // ...
        $items = ...
    } else {
        // ...
        $items = ...
    }
    return $items;
}

voir même si vous êtes parano :

function listItems($type,$status = 'enabled') {
    if (!$status || !in_array($status,array('enabled','disabled'))) {
        $status = 'enabled';
    }
    // ....
    if ('enabled' === $status) {
        // ...
        $items = ...
    } else {
        // ...
        $items = ...
    }
    return $items;
}

Vous me direz, oui mais au lieu d'utiliser une string ('enabled') on aurait pu utiliser un boolean et le problème était réglé pas besoin de cette verrue. Vous aurez raison, mais du coup pour tous les paramètres qui ont des valeurs par défaut autre que string (regardez votre code je pense qu'il y en plein ;) ) on fait comment sinon ? ;)

Alors, gare aux bugs ! L'utilisation des valeurs par défaut pour les paramètres de fonctions/méthodes, ne vous dispense pas de vérifier leur valeur !

LivePHP.net : tester les différentes versions de PHP !

Olivier Hoareau — Mon, 18 May 2009 08:00:00 +0100

PHP.net est notre référence à tous pour trouver LA documentation sur PHP. Mais si vous êtes comme moi, vous êtes peut être souvent confronté à plusieurs versions de PHP sur vos projets ou chez vos clients. Comment être sûr qu'une fonction PHP se comporte de la même façon dans une version plus ancienne que la doc PHP.net ? suivez le guide ;)

Voici un nouveau service en ligne qui vous permettra de tester une bonne partie (toutes les fonctions ne sont pas couvertes, pour raisons de sécurité ;)) des fonctions PHP sous forme d'une API Web services (format XML, json...).

Le principe est simple vous pouvez récupérer le résultat d'une fonction php en appelant l'url :

http://livephp.net/functions/<nom-de-la-fonction>/<param1>/<param2>/....?format=<format>&version=<liste-des-versions-php>

Voici quelques exemples :

Liste des services disponibles

http://livephp.net

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<service id="http://livephp.net/functions">array (
  0 => 'Call http://livephp.net/functions to get the list of available function for specified PHP version (version= parameter, or default PHP version)',
  1 => 'Call http://livephp.net/functions/[function_name]/[arg1]/[arg2]/... to call function_name(arg1,arg2,...) and get the result back',
  2 => 'You can use parameters : format=[format], version=[version], reference=[version,version,...|all]',
)</service>
		<service id="http://livephp.net/formats">Call http://livephp.net/formats to get the list of available formats to use with the 'format=' parameter</service>

		<service id="http://livephp.net/versions">Call http://livephp.net/versions to get the list of available PHP versions with the 'version=' parameter</service>
	</results>
</response>

Liste des versions disponibles

http://livephp.net/versions

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<version>4.4.9</version>
		<version>5.0.5</version>

		<version>5.1.0</version>
		<version>5.1.6</version>
		<version>5.2.0</version>
		<version>5.2.1</version>
		<version>5.2.2</version>
		<version>5.2.3</version>

		<version>5.2.4</version>
		<version>5.2.5</version>
		<version>5.2.6</version>
		<version>5.2.8</version>
		<version>5.2.9</version>
		<version>5.3-dev</version>

		<version>6.0-dev</version>
	</results>
</response>

Liste des formats disponibles

http://livephp.net/formats

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<format>xml</format>
		<format>json</format>

		<format>php</format>
		<format>js</format>
		<format>raw</format>
		<format>csv</format>
	</results>
</response>

Liste des fonctions disponibles pour la dernière release stable de PHP

http://livephp.net/functions

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<return version="5.2.9" duration="0.00588488578796">array (
  'internal' => 
  array (
    0 => 'zend_version',
    1 => 'func_num_args',
    2 => 'func_get_arg',
    3 => 'func_get_args',
    4 => 'strlen',
    5 => 'strcmp',
    6 => 'strncmp',
    7 => 'strcasecmp',
    ...
  ),
  'user' => 
  array (
  ),
)</return>
	</results>
</response>

Ex: substr('test',0,3) => 'tes'

http://livephp.net/functions/substr/test/0/3?version=all&format=csv

type,value,version,duration
return,tes,4.4.9,0.0035560131073
return,tes,5.0.5,0.00384306907654
return,tes,5.1.0,0.00425505638123
return,tes,5.1.6,0.00440287590027
return,tes,5.2.0,0.00467205047607
return,tes,5.2.1,0.0046968460083
return,tes,5.2.2,0.00472688674927
return,tes,5.2.3,0.00475788116455
return,tes,5.2.4,0.00470304489136
return,tes,5.2.5,0.00474095344543
return,tes,5.2.6,0.00479793548584
return,tes,5.2.8,0.00478100776672
return,tes,5.2.9,0.00476813316345
return,tes,5.3-dev,0.00529599189758
return,tes,6.0-dev,0.00888299942017

Ex: array_merge(array(1,2,3),1) => comportement différent entre PHP 4 et PHP 5

http://livephp.net/functions/array_merge/[1,2,3]/1?version=all

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<return version="4.4.9" duration="0.00359106063843">array (
  0 => 1,
  1 => 2,
  2 => 3,
  3 => '1',
)</return>
		<return version="5.0.5" duration="0.00379920005798">false</return>

		<return version="5.1.0" duration="0.00418400764465">false</return>
		<return version="5.1.6" duration="0.00437688827515">false</return>
		<return version="5.2.0" duration="0.00474405288696">false</return>
		<return version="5.2.1" duration="0.00470590591431">false</return>
		<return version="5.2.2" duration="0.004723072052">false</return>
		<return version="5.2.3" duration="0.00476813316345">false</return>

		<return version="5.2.4" duration="0.00476694107056">false</return>
		<return version="5.2.5" duration="0.00478100776672">false</return>
		<return version="5.2.6" duration="0.00486397743225">false</return>
		<return version="5.2.8" duration="0.00476217269897">false</return>
		<return version="5.2.9" duration="0.0047550201416">false</return>
		<return version="5.3-dev" duration="0.00532984733582">false</return>

		<return version="6.0-dev" duration="0.00882506370544">false</return>
	</results>
</response>

md5() non dispo dans PHP 6 (pour l'instant ?)

http://livephp.net/functions/md5/aaaaaaaaaaaaaga?version=6.0-dev,5.2.9&reference=5.2.9

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<return version="6.0-dev" duration="0.00935697555542" regression="true">false</return>
		<return version="5.2.9" duration="0.00510597229004">a2543fd1f2af3fac6b0e273a18bbe219</return>

	</results>
</response>

Lister les numéros de versions

http://livephp.net/functions/phpversion?version=all

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<return version="4.4.9" duration="0.00354194641113">4.4.9</return>
		<return version="5.0.5" duration="0.00374889373779">5.0.5</return>

		<return version="5.1.0" duration="0.00420808792114">5.1.0</return>
		<return version="5.1.6" duration="0.00435781478882">5.1.6</return>
		<return version="5.2.0" duration="0.00470304489136">5.2.0</return>
		<return version="5.2.1" duration="0.00473499298096">5.2.1</return>
		<return version="5.2.2" duration="0.00475382804871">5.2.2</return>
		<return version="5.2.3" duration="0.00475478172302">5.2.3</return>

		<return version="5.2.4" duration="0.00473499298096">5.2.4</return>
		<return version="5.2.5" duration="0.0047550201416">5.2.5</return>
		<return version="5.2.6" duration="0.004802942276">5.2.6</return>
		<return version="5.2.8" duration="0.00480198860168">5.2.8</return>
		<return version="5.2.9" duration="0.00478005409241">5.2.9</return>
		<return version="5.3-dev" duration="0.00531506538391">5.3.0RC3-dev</return>

		<return version="6.0-dev" duration="0.00883913040161">false</return>
	</results>
</response>

Récupérer la valeur de retour de la fonction au format brut

http://livephp.net/functions/substr/my-test/0/2?format=raw

my

Format CSV !

http://livephp.net/functions/ucfirst/my test?version=all&format=csv&sep=;

type;value;version;duration
return;My test;4.4.9;0.00356388092041
return;My test;5.0.5;0.00379014015198
return;My test;5.1.0;0.0042290687561
return;My test;5.1.6;0.00434899330139
return;My test;5.2.0;0.00467896461487
return;My test;5.2.1;0.00471687316895
return;My test;5.2.2;0.004723072052
return;My test;5.2.3;0.00476217269897
return;My test;5.2.4;0.00476408004761
return;My test;5.2.5;0.00472712516785
return;My test;5.2.6;0.0047709941864
return;My test;5.2.8;0.00476121902466
return;My test;5.2.9;0.00476288795471
return;My test;5.3-dev;0.00525689125061
return;My test;6.0-dev;0.00884604454041

Certaines fonctions sont désactivées

http://livephp.net/functions/exec/ls

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>403</code>
	<message>Function 'exec' has not been enabled</message>
	<results>
	</results>
</response>

Utilisez la notation json pour passer un argument tableau ou objet

http://livephp.net/functions/json_encode/[1,2,3]?version=all

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<return version="4.4.9" duration="0.00357604026794">Error: Function 'json_encode' does not exist in PHP version '4.4.9'</return>
		<return version="5.0.5" duration="0.00391697883606">Error: Function 'json_encode' does not exist in PHP version '5.0.5'</return>

		<return version="5.1.0" duration="0.00429391860962">Error: Function 'json_encode' does not exist in PHP version '5.1.0'</return>
		<return version="5.1.6" duration="0.0044469833374">Error: Function 'json_encode' does not exist in PHP version '5.1.6'</return>
		<return version="5.2.0" duration="0.00477600097656">[1,2,3]</return>
		<return version="5.2.1" duration="0.00473999977112">[1,2,3]</return>
		<return version="5.2.2" duration="0.00473594665527">[1,2,3]</return>
		<return version="5.2.3" duration="0.00478887557983">[1,2,3]</return>

		<return version="5.2.4" duration="0.00479698181152">[1,2,3]</return>
		<return version="5.2.5" duration="0.00476408004761">[1,2,3]</return>
		<return version="5.2.6" duration="0.00474905967712">[1,2,3]</return>
		<return version="5.2.8" duration="0.00475907325745">[1,2,3]</return>
		<return version="5.2.9" duration="0.00477600097656">[1,2,3]</return>
		<return version="5.3-dev" duration="0.00535202026367">[1,2,3]</return>

		<return version="6.0-dev" duration="0.00893187522888">[1,2,3]</return>
	</results>
</response>

http://livephp.net/functions/json_decode/\[1,2,3]?version=all

<?xml version="1.0" encoding="UTF-8" ?>

<response>
	<code>200</code>
	<message>success</message>
	<results>
		<return version="4.4.9" duration="0.00359201431274">Error: Function 'json_decode' does not exist in PHP version '4.4.9'</return>
		<return version="5.0.5" duration="0.00375604629517">Error: Function 'json_decode' does not exist in PHP version '5.0.5'</return>

		<return version="5.1.0" duration="0.00430989265442">Error: Function 'json_decode' does not exist in PHP version '5.1.0'</return>
		<return version="5.1.6" duration="0.00447916984558">Error: Function 'json_decode' does not exist in PHP version '5.1.6'</return>
		<return version="5.2.0" duration="0.00474095344543">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.2.1" duration="0.00470018386841">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.2.2" duration="0.00474286079407">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.2.3" duration="0.00478100776672">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>

		<return version="5.2.4" duration="0.00489497184753">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.2.5" duration="0.00485587120056">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.2.6" duration="0.00483107566833">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.2.8" duration="0.0047619342804">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.2.9" duration="0.00485610961914">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
		<return version="5.3-dev" duration="0.00533699989319">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>

		<return version="6.0-dev" duration="0.00902605056763">array (
  0 => 1,
  1 => 2,
  2 => 3,
)</return>
	</results>
</response>

A quand un tel service intégrer à la documentation en ligne de PHP.net ? ;)

Bonne utilisation

PS: vous souhaitez voir d'autres fonctionnalités ? Envoyer un email à features@livephp.net

Installer son propre channel pear en local (par exemple chez un client...)

Olivier Hoareau — Tue, 12 May 2009 13:44:00 +0100

Un petit tutorial rapide pour vous faire un retour d'expérience sur l'installation de Chiara PEAR Server (aka un channel PEAR perso)

Juste pour partager avec vous ma dernière installation du Chiara PEAR Server sur une machine windows avec wamp (désolé).

installation de apache / mysql / php (par exemple via wamp, zend server CE, ...)
ajout du répertoire racine de php dans le PATH

$ pear config-set http_proxy <my-proxy-host>:<my-proxy-port>
$ pear update-channels
$ pear upgrade pear
$ pear channel-discover pear.chiaraquartet.net 
$ pear install --alldeps MDB2-2.5.0b2
$ pear install --alldeps MDB2_Schema-0.8.5
$ pear install --alldeps MDB2_Driver_mysqli-1.5.0b2

créer la base mysql pear accessible pour le user pear, pour le host %
ajouter le user mysql pear avec le mot de passe pear pour le host localhost
flusher les privileges mysql
créer le répertoire c:/wamp/apps/pear-channel (il s'agit du document root, vous pouvez le mettre ailleurs !)
créer le fichier c:/wamp/alias/pear-channel.conf :

NameVirtualHost *:80
<VirtualHost *:80>
	ServerName pear
	DocumentRoot "c:/wamp/apps/pear-channel/"
	<Directory "c:/wamp/apps/pear-channel/">
		Options All
		AllowOverride all
        Order Deny,Allow
		Allow from all
	</Directory>
	DirectoryIndex admin.php
</VirtualHost>

ajouter l'alias de host dans etc/hosts (et dans le etc/hosts de tout vos postes bureautiques devant accéder au channel, ou bien via le contrôleur de domaine windows):

127.0.0.1	mypear
$ pear install --alldeps chiara/Chiara_PEAR_Server-0.19.0
$ pear run-scripts chiara/Chiara_PEAR_Server

modifier l'admin channel (6) et mettre 'admin'
modifier la channel uri (7) et mettre 'mypear' (nom de la machine)
tapez entrée
modifier le suggested channel alias et mettre '<votre-alias-ici>' (par exemple 'mypear')
mettre 'My PHP Pear channel' pour le channel description
mettre 'pear' comme mot de passe
tapez entrée
modifier le Path to document root et mettre 'C:\wamp\apps\pear-channel'
modifier le temporary path et mettre 'c:/tmp'
tapez entrée
reporter l'include path du fichier c:/wamp/bin/php/php5.2.6/php.ini dans tous les fichiers php.ini notamment celui d'apache (c:/wamp/bin/apache/...)
redémarrer le serveur web apache
accéder à http://mypear/, login=admin, pass=pear
commencez à créer les mainteneurs, les catégories, les packages et à uploader des versions de package.

pour ajouter le "channel" sur un poste développeur, faire :

$ pear -u http_proxy channel-discover mypear

ensuite pour installer une release d'un package situé sur le channel :

$ pear -u http_proxy install --alldeps mypear/<nom-du-package>

redémarrer le serveur apache (wamp)

Pour ajouter des packages et des releases, je vous laisse prendre connaissance du fonctionnement de Chiara PEAR Server. En gros, vous commencez par ajouter des mainteneurs, vous créez des catégories, ensuite vous créer un package que vous affectez à une catégorie. Vous ajouter alors des mainteneurs pour ce package. Le mainteneur doit alors se connecter à l'admin avec son compte et peut alors "uploader" une version (release) du package, préalablement packagée dans un fichier .tgz avec un fichier package.xml à la racine et un répertoire <nom-du-package>-<version> qui contient tous les fichiers. Un fois la release uploadée, elle est directement disponible à l'installation / l'update via pear :

$ pear install mypear/<my-package>

ou bien :

$ pear update mypear/<my-package>

PHP Tree Match : Vérifiez que vos arborescences projets sont standardisées !

Olivier Hoareau — Mon, 11 May 2009 18:41:00 +0100

"Et alors, mes 18 projets ont tous la même arborescence ? Ils sont tous standard (i.e. respectent "nos" standards) et sont tous "faits" de la même façon ?" Certains d'entre vous se sont déjà vus poser cette question ? Si, c'est la cas, PHP Tree Match pourra probablement vous aider...

PHP Tree Match, ou PHPTM de son petit nom, est un nouvel outil "basique" (dans la série des phpcpd, phpmd...) qui permet de vérifier que l'arborescence de votre/vos projets respectent bien une norme que vous vous donnez. Par exemple, vous avez l'habitude mettre une arborescence du type :

/
    application/
        default/
            controllers/
            models/
            views/
    config/
         application.ini
    html/
        index.php
        .htaccess
    ...

Vous devez gérer 1, 5, 10 ... projets similaires et vous voulez vérifier d'un seul coup que tous vos projets respectent bien vos conventions, que le fichier config/application.ini contient bien la section "production", que le fichier .project n'existe pas en prod...

Installation

à partir du Channel PEAR

$ pear channel-discover pear.phppro.fr
$ pear install phppro/phptm

mise à jour

$ pear upgrade phppro/phptm

à partir du package compatible PEAR en téléchargement sur Google Code

$ wget http://phptreematch.googlecode.com/files/phptm-0.1.0.tgz
$ pear install phptm-0.1.0.tgz

Usage

Avant d'utiliser phptm vous devez "décrire" votre arborescence projet dans un fichier de description au format xml. Voici un exemple :

<?xml version="1.0" encoding="UTF-8"?>
<tree>
    <item name=".project" present="false"/>
    <item name="bin/phptm.bat" hash="8c8d25cde4142e4b945792c2ca9a31cc"/>
    <item name="bin/phptm.php" hash="635f67483f575310a904c02a2068d0dd"/>
    <item name="build/package.xml" hash="ca34d98facbc5ff461976d5f18910cbe"/>
    <item name="build.xml" hash="a25ebe507f99623d266aeee4d1ed4463"/>
    <item name="config/build.properties">
        <contains>version=</contains>
        <contains>name=</contains>
    </item>
    <item name="config/package.xml"/>
    <item name="docs/README.markdown"/>
    <item name="library/PHPTM/Analyzer.php"/>
    <item name="library/PHPTM/Log/XML/XML.php"/>
    <item name="library/PHPTM/Log/XML.php"/>
    <item name="library/PHPTM/TextUI/Command.php"/>
    <item name="library/PHPTM/TextUI/Getopt.php"/>
    <item name="library/PHPTM/TextUI/ResultPrinter.php"/>
    <item name="library/PHPTM/Util/FilterIterator.php"/>
</tree>

Le fichier ci-dessus permet notamment de vérifier que certains fichier sont bien absent(present=false), que certains fichiers existent et ont un contenu précis (calculé à partir de "hash"), que certains fichiers existent et contiennent une chaîne de caractère précise ("contains", mais vous pouvez aussi utiliser "notcontains")...

Inspirez vous de l'exemple ci-dessus pour construire votre fichier de description, ou bien exécutez la commande suivante sur une arborescence type :

$ phptm --build-tree my-typical-directory > typical-tree.xml

Pour "passer" ensuite phptm sur votre application, exécutez :

$ phptm --expected-tree=typical-tree.xml my-directory

ou bien pour exporter aussi le résultat sous forme xml :

$ phptm --log-xml=phptm-report.xml --expected-tree=typical-tree.xml my-directory

Description du rapport calculé

Le rapport en ligne de commande ou bien le rapport xml vous indique alors si des erreurs de cohérences sont détectées et si oui, lesquelles :

missing : absence de fichier listé
present : présence de fichier listé comme devant être absent
hash : contenu de fichier non identique à celui attendu
contains : fichier contenant une chaîne marquée comme devant ne pas être dans le fichier
not-contains : fichier ne contenant pas une chaîne attendue

Limitations

PHPTM est loin d'être un outil parfait et exhaustif, n'hésitez pas à remonter des éventuels bugs et des demandes d'évolutions sur l'espace du projet sur Google Code http://code.google.com/p/phptreematch/issues/list ! ou à partir la documentation sur http://code.google.com/p/phptreematch

Bonne utilisation !

PHP Code Ratio : calculez le ratio de commentaires dans vos fichiers !

Olivier Hoareau — Tue, 05 May 2009 11:23:00 +0100

"Et alors, quel est le pourcentage de commentaires dans mon appli ?" Certains d'entre vous se sont déjà vus poser cette question ? Si, c'est la cas, PHP Code Ratio pourra probablement vous aider...

PHP Code Ratio, ou PHPCR de son petit nom, est un nouvel outil "basique" (dans la série des phpcpd, phpmd...) qui permet de connaître le pourcentage de commentaire dans vos fichiers php.

Installation

à partir du Channel PEAR

$ pear channel-discover pear.phppro.fr
$ pear install phppro/phpcr

mise à jour

$ pear upgrade phppro/phpcr

à partir du package compatible PEAR en téléchargement sur Google Code

$ wget http://phpcoderatio.googlecode.com/files/phpcr-0.1.0.tgz
$ pear install phpcr-0.1.0.tgz

Usage

Pour "passer" phpcr sur votre application, exécutez :

$ phpcr my-directory

ou bien pour exporter aussi le résultat sous forme xml :

$ phpcr --log-xml=phpcr-report.xml my-directory

Description des métriques calculées

Metrique 'code' : pourcentage de code php sans les espaces, sans les commentaires et sans le HTML "inline"
Metrique 'code-with-space' : pourcentage de code php avec les espaces mais sans commentaires et sans HTML "inline"
Metrique 'code-with-space-and-html' : pourcentage de code php avec espaces, HTML "inline" mais sans commentaire
Metrique 'html' : pourcentage de HTML "inline" dans les fichiers PHP
Metrique 'whitespace' : pourcentage d'espace dans les fichiers php

Extensions parsées

php
php3
php4
php5
phtml
inc

mais vous pouvez modifier cette liste en utilisant le paramètre ligne de commande "--suffixes="

Limitations

PHPCR est loin d'être un outil parfait et exhaustif, n'hésitez pas à remonter des éventuels bugs et des demandes d'évolutions sur l'espace du projet sur Google Code http://code.google.com/p/phpcoderatio/issues/list ! ou à partir la documentation sur http://code.google.com/p/phpcoderatio

Bonne utilisation !

Pourquoi Eclipse et les annotations ont révolutionné ma façon de coder

Olivier Hoareau — Tue, 21 Apr 2009 08:55:00 +0100

Comme beaucoup d'entre vous, "vi" (prononcez "vi-aille") a longtemps été mon ami pour développer mon code PHP.
Il me plaisait bien, j'avais l'air d'être un geek et tout allait bien.

Et puis il y a quelques temps (2-3 ans), j'ai du travailler chez un client avec Eclipse + Plugin PHP (que je connaissais en Java mais qui ne m'attirait pas à l'époque pour PHP au vu du peu de fonctionnalités que je pensais disponible pour cette plateforme).
Ce type d'outils généère un bloc de commentaire au dessus d'une fonction ou méthode quand on en créé une (après le passage à la ligne par l'appui sur la touche entrée).
J'ai vu qu'il rajoutait des annotations ou doclet :

/**
 * ...
 * 
 * @return unknown
 */

Je me suis dit que j'allais alors remplacer unknown par le type retourné quand il s'agissait d'un objet, par exemple :

/**
 * ...
 * 
 * @return Sms
 */

(en ce temps là, j'avais encore le temps de perdre mon temps à faire des choses d'apparences inutiles dans le code...).
Jusque là, rien de transcendant. Et puis dans un autre fichier, j'ai utilisé ma méthode nouvellement créé, et là, surprise ! Eclipse me propose une autocomplétion avec la liste de toutes les méthodes de la classe Sms ! Cool !
Je me suis dit alors que j'allais essayer de systématiquement mettre les @return, et que ca m'aiderait à aller plus vite (plutôt que de chercher le nom des méthodes dispos en switchant entre les fichiers).

Puis je remarque aussi qu'il me met des @param au-dessus des méthodes / fonctions, pour décrire les paramètres de mes fonctions.

/**
 * ...
 * 
 * @param unknown $sms
 * @param unknown $xmlelement
 *
 * ...
 */

Je décide alors d'essayer de mettre des types, par exemple :

/**
 * ...
 * 
 * @param Sms $sms le sms à envoyer
 * @param SimpleXMLElement $xmlelement le document xml
 *
 * ...
 */

Et je me rends compte qu'il m'indique ces types dans l'autocompletion, ce qui m'aide dans de nombreux cas pour savoir quoi passer à la fonction / méthode.

Par contre, j'ai souvent plein de méthodes qui ne renvoient rien, donc je ne bénéficie d'aucune complétion automatique dans ces cas là.
Je me dis alors, et si je renvoyait $this ?
Je mets alors des :

...
{
    ...
    return $this;
}

à la fin de chaque méthode qui n'est pas censée renvoyer un résultat (par exemple les setters !) et je rajoute l'annotation @return <la-classe-de-$this>.
Du coup, je peux chainer certains de mes appels :

$sms = new Sms();
$sms->setSender(...)
          ->addRecipient(...)
          ->addRecipient(...)
          ->setMessage(...)
          ->send();

Cool ! Pas mal, mon code devient plus concis et du coup, j'essaye de nommer mes méthodes pour que leur "enchainement" soit compréhensible et lisible. En plus, j'ai l'auto-complétion pour chacune des lignes grâce à mon @return !

La cerise sur le gâteau : j'utilise alors le pattern Factory (avec une méthode statique) :

    /**
      * Returns a new instance of this class
      *
      * @return Sms
      */
    public final static function getInstance()
    {
        return new self;
    }

Ce qui me permet de simplifier encore mon utilisation de mes classes :

Sms::getInstance()
    ->setSender(...)
    ->addRecipient(...)
    ->addRecipient(...)
    ->setMessage(...)
    ->send();

On pourrait même mettre tout sur une ligne ! (attention à la lisibilité).

Si je résume, grâce à Eclipse et aux annotations :

j'ai tendance à utiliser plutôt les structures objet pour avoir l'auto-complétion (plutôt que de multiple paramètre string)
je fais des return $this systématiques pour les méthodes qui ne renvoient rien
j'ai simplifié et rendu plus lisible les noms de mes méthodes pour qu'elles s'inscrivent harmonieusement dans un enchainement
j'ai typé mes paramètres de fonctions / méthodes ce qui me permet d'avoir l'auto-complétion sur les paramètres dans mes fonctions
je crée quasi systématiquement des factories pour éviter de passer par une variable inutile
...

Une vraie révolution, à l'époque, pour moi !

Et vous, quels sont les petits trucs qui ont révolutionné votre manière de coder ?

Générer un document OpenXML à partir d'un modèle (pptx, xlsx,docx) et de variables: où comment générer vos documents à la volée simplement

Olivier Hoareau — Sat, 18 Apr 2009 10:08:00 +0100

Vous avez produit pour un client un document powerpoint vraiment bien, avec l'entête de votre entreprise, votre logo... sur un sujet qui revient souvent pour vous.
Le temps passe, et voilà qu'on vous redemande le même sujet ou très similaire mais avec quelques informations différentes ou bien à actualiser.

Si vous êtes capable d'extraire dans un fichier toute les informations qui ont changé, vous trouverez ci-dessous un script qui peut vous faire gagner du temps pour re-générer le document mis à jour.

Principe du script

Les fichiers OpenXML (*.pptx, *.docx, *.xlsx) sont en fait des fichiers zippés qui contient des répertoires et des fichiers xml (entre autres). Après avoir extrait le zip (avec l'extension PHP Zip, qui est donc nécessaire !), il est donc facile de remplacer des mots ou "variables" dans les fichiers xml (texte). Le script ci-dessous utilise la fonction preg_match_all() pour trouver les occurences de l'expression '${*}' ou '*' est le nom d'une variable. Si vous mettez donc '${mavariable}' n'importe où dans votre document (avec votre bien vieux microsoft Office), elle sera trouvée et remplacée par la valeur que vous aurez indiquée pour cette variable dans un fichier de configuration (ini).

Le principe est simple, limité, mais fonctionnel. Abusez-en !

Création du fichier template

Commencez par créer / modifier votre fichier pptx (ou docx ou xlsx) en ajoutant des '${mavariable}' à la place des mots, phrases, ou valeurs que voulez modifier dynamiquement, appellons ce fichier 'template.pptx' (par exemple)

Création du fichier de propriétés

Créer un fichier 'properties.ini' (par exemple) qui contient la liste de toute les variables que vou voulez utiliser dans votre document :

doc.title = Le titre du document ici
doc.author.name = Mon nom ici
...

Création du script de génération

Copier le script ci-dessous dans le fichier 'openxml.php'

<?php
/**
 * Content of the openxml.php file
 *
 * @usage php openxml.php <iniFile> <templateFile> <finalFile>
 *
 * @copyright none.
 */

/**
 * Replaces all ${variable.name} by the value of 'variable.name' of your configuration file in the specified file
 *
 * @param string $file the source file
 * @param array  $vars the list of variable to replace
 *
 * @return void
 */
function parseFile($file,$vars)
{
    $content = file_get_contents($file);

    $matches = null;
    if(preg_match_all('/\$\{([^\}]+)\}/',$content,$matches)>0) {
        for($i=0;$i<count($matches[0]);$i++){
            $v = '$vars';
            $vl='';
            $found = trim($matches[1][$i]);
            foreach(explode('.',$found) as $t){
                $v.= '["'.strip_tags($t).'"]';
                $vl.=($vl?'.':'').strip_tags($t);
            }
            eval('$value = isset('.$v.') ? '.$v.' : (isset($vars["'.$vl.'"]) ? $vars["'.$vl.'"] : "[Variable not found: \'$vl\']");');
            $content = str_replace('${'.$matches[1][$i].'}',$value,$content);
        }
    }

    file_put_contents($file,$content);
}

/**
 * Lists all files in specified location
 *
 * @param string $location the location to list files in
 * 
 * @return array
 */
function listFiles($location,$root=null)
{
    if(null==$root) {
        $root = $location;
    }
    $files = array();
    if (is_dir($location)){
        $dh = opendir($location);
        while(false !== ($file = readdir($dh))){
            if ('.'===$file || '..' === $file) continue;
            $files = array_merge($files,listFiles($location.'/'.$file,$root));
        }
        closedir($dh);
    }
        $files[] = $location;
    sort($files);
    if($root === $location) {
        array_shift($files);
    }
    return $files;
}

/**
 * Deletes all files in specified locaton
 *
 * @param string $location
 *
 * @return void
 */
function delete($location)
{
    if (is_dir($location)){
        $dh = opendir($location);
        while(false !== ($file = readdir($dh))){
            if ('.'===$file || '..' === $file) continue;
            delete($location.'/'.$file);
        }
        closedir($dh);
    }
    @unlink($location);
}

$iniFile = $_SERVER['argv'][1];
$templateFile =  $_SERVER['argv'][2];
$finalFile = $_SERVER['argv'][3];

// 1. imports ini file

$vars = parse_ini_file($iniFile);

// 2. unzips the file into a temporary directory

$tempDir = sys_get_temp_dir().'/openxml';
if(!file_exists($tempDir)){
    mkdir($tempDir,0777,true);
}

$zip = new ZipArchive();
if (true !== $zip->open($templateFile)) {
    throw new RuntimeException("Unable to read zip file '$templateFile'");
}
$zip->extractTo($tempDir);
$zip->close();

// 3. parses extracted files to replace variables

$files = listFiles($tempDir);

foreach($files as $file) {
    if(substr($file,strlen($file)-4)!=='.xml') continue;
    parseFile($file,$vars);
}

// 4. Re-zip all files into the final pptx file

$zip = new ZipArchive();

if(file_exists($finalFile)){
    unlink($finalFile);
}
if ($zip->open($finalFile, ZIPARCHIVE::CREATE)!==TRUE) {
    throw new RuntimeException("Unable to create zip archive '$finalFile'");
}

foreach($files as $file) {
    $fileName = str_replace('\','/',substr($file,strlen($tempDir)+1));
    $zip->addFile($file,$fileName);
}
$zip->close();

// 5. Deletes all artifacts

delete($tempDir);

echo "Your openxl document has been generated in '$finalFile' from template '$templateFile' and variables set in configuration file '$iniFile'
";

Exécutez le script !

$ php openxml.php properties.ini template.pptx document.pptx

Vous devriez avoir un fichier 'document.pptx' créé à partir du fichier template (modèle) et dont les variables ont été remplacé par leur valeur trouvée dans le fichier de configuation.

Pour aller plus loin

Ce script n'est pas parfait, mais il fonctionne très bien pour les cas simples. Sous excel, vous aurez peut être quelques petits soucis car les valeurs remplacées sont considérées comme du texte et pas des chiffres, ce qu posent problèmes ou formule (il y a un palliatif)

Je vous laisse le soin de faire évoluer ce script pour :

ajouter des images générées dynamiquement par php
réaliser une api objet à intégrer dans vos scripts et applications/sites.

N'hésitez pas à poster vos commentaires surtout si vous trouvez des outils plus complets ailleurs, ou que vous faites évoluer ce script !

dirname(FILE), où comment éviter d'utiliser define('ROOT',...);

Olivier Hoareau — Tue, 14 Apr 2009 09:26:00 +0100

Comment récupérer le répertoire courant du fichier dans lequel on se trouve ...

La technique du dirname(FILE)

/**
 * Exemples:
 *
 * /home/moi-meme/public_html/index.php => /home/moi-meme/public_html
 * c:\public_html\index.php => c:\public_html
 */
$cwd = dirname(__FILE__);

Si vous voulez le chemin réel sur la machine (enlever les lien symboliques et les ../), vous pouvez aussi faire :

/**
 * Exemples:
 *
 * /home/moi-meme/public_html/index.php => /var/users/moi-meme/public_html (avec lien symbolique de /home vers /var/users)
 * c:\public_html\index.php => c:/public_html
 */
$cwd = realpath(dirname(__FILE__));

Pour obtenir un chemin normalisé avec des / au lieu de \ sur windows (utile pour le cross plateforme windows/linux ou pour la comparaison de sous-chaîne sans se soucier de la plateforme) :

/**
 * Exemples:
 *
 * /home/moi-meme/public_html/index.php => /home/moi-meme/public_html
 * c:\public_html\index.php => c:/public_html
 */
$cwd = str_replace(DIRECTORY_SEPARATOR,'/',realpath(dirname(__FILE__)));

La technique du dirname(FILE).'/../'

Comme lorsque vous êtes dans un fichier vous savez où il se trouve relativement par rapport aux autres (par exemple mon fichier ./includes/functions.php, je sais qu'il est dans le sous-répertoire includes à partir de la racine de mon application), vous pouvez ensuite vous servir de se "positionnement" relatif pour include des fichiers :

Dans le fichier ./includes/all.php

require_once dirname(__FILE__).'/functions/database.php';

...

Imaginez que vous ayiez un répertoire ./html/ qui contient index.php et un répertoire ./includes/ qui contient le fichier functions.php (de sorte que le fichier functions.php ne soit pas directement accessible dans l'arborescence du serveur web qui pointe sur ./html) .
Vous pouvez donc include le fichier functions.php de la manière suivante dans le fichier index.php :

require_once dirname(__FILE__).'/../includes/functions.php';

...

même si vous déplacez votre application dans un autre répertoire du système ou sur un autre serveur, tant que l'arborescence des fichiers de votre application ne change pas, il n'y a aucun impact sur votre code source !
Plus besoin de tenir (pour ceux qui n'utilisaient pas déjà cette technique) un fichier de configuration avec des define qui est a modifié à chaque installation.

Et vous comment gérez vous les chemins absolus (inclusions de fichiers ou lecture de fichier sur le disque) dans vos applications ?

"Injectabilité / Mockabilité" : Un indicateur simple de la qualité de votre design de code

Olivier Hoareau — Tue, 14 Apr 2009 08:30:00 +0100

On parle souvent d'indicateur de qualité de code avec nombre de tests unitaires qui passent au vert, nombre d'erreurs détectées pour le non respect des standards, nombre de lignes de code...
Tous ces indicateurs donnent une information intéressante sur la qualité du code mais pas sur la qualité de l'architecture ou design du code, c'est à dire aucune évaluation de la conception de votre code.

Voici un indicateur simple que vous pouvez mettre en place (par exemple avec un petit développement complémentaire à l'outil PHP_CodeSniffer ou avec 2 ou 3 expressions régulières) pour avoir une indication de la qualité de votre design: l'indicateur d'injectabilité / mockabilité

Concrètement, il s'agit de mesurer la capacité que votre code a de se faire injecter ses dépendances, et sa capacité à être bouchonné ("mock" en anglais).
Plus un code est bouchonnable, plus il est testable unitairement et modulaire.

Pour mesurer cet indicateur "i" simplement, il suffit de comparer le nombre de getter/setter de propriété de classe, au nombre de propriété de classe, une formule (proposition) pourrait être par exemple:

i = (nb getters + nb setters) / (2 * nb propriétés)

avec 0 <= i <= 1

Plus i est proche de 1, plus votre classe est "mockable" et donc plus facile à tester unitairement...
Attention, comme tout indicateur, il a des limites, il ne s'agit que d'un outil de plus pour vous aider à qualifier votre code ou votre application !

A quand cet indicateur dans PHPUnderControl, ou ailleurs !

Et vous, quels sont vos indicateurs de qualité de design de code ?

Le lien symbolique : ou comment maîtriser son déploiement

Olivier Hoareau — Sat, 11 Apr 2009 08:12:00 +0100

Vous avez déjà fait des mises en production ou mises en ligne.
Vous savez que les problèmes arrivent, que l'on peut faire des erreurs, par exemple supprimer malencontreusement un répertoire au moment du remplacement par la nouvelle version, etc...

Il existe une technique simple qui permet de simplifier les mises en production, de faciliter le retour en arrière et de gérer l'archivage : le lien symbolique.

La technique est triviale: vous ajoutez dans un répertoire racine petit à petit toutes les nouvelles versions (par exemple /opt) :

/
    opt/
        mon-appli-1.0/
        mon-appli-1.1/
        ...
        mon-appli-1.7/
        ...
        mon-appli-2.2/

A chaque fois, une fois le répertoire de la nouvelle version ajouté, vous créez un lien symbolique qui pointe vers la version (à priori la dernière) qui vous intéresse:

$ rm -f /opt/mon-appli
$ ln -s /opt/mon-appli-2.2 /opt/mon-appli

La première fois, vous faites pointez le DOCUMENT_ROOT de votre application PHP sur /opt/mon-appli/...
Lors de la prochaine mise en production, vous n'aurez qu'à créer un répertoire portant le nom de la nouvelle version, y mettre les fichiers de la nouvelle version, et modifier le lien symbolique (rm -f, puis ln -s) lorsque vous serez prêt vers le nouveau répertoire.
Il n'y aura aucune indisponibilité de l'application et si vous détectez un problème vous n'aurez qu'à rechanger le lien symbolique pour remettre l'ancienne version !

Bien sûr cette technique ne gère pas votre base de données. Si des changements de schémas ou de données interviennent entre les différentes versions il faudra gérer cela.

Et vous quelles sont vos pratiques ?

Université du S.I 2009 : Oui ! PHP est industriel !

Olivier Hoareau — Thu, 09 Apr 2009 14:55:00 +0100

Vous connaissez l'Université du Système d'Information ? ou USI !

Organisé par OCTO Technology (Paris), ce séminaire mélange Geek et Boss en proposant 4 thématiques de conférences :

Gouvernance
Technologies
Méthodologies
Usabilité

Côté Technologies, a côté de Java, .NET, Grails, Ruby..., nous aurons cette année ... PHP !

Lors de la prochaine édition, 1 et 2 juillet 2009 à Paris, nous essaierons avec Damien Seguy (Alterway/Nexen) de démontrer que PHP est aujourd'hui une technologie / plateforme / environnement industriel.
Parmi les sujets abordés dans notre session :

Frameworks PHP professionnels
Intégration continue
Environnement de développement
Outillage
Test Driven Development
Tests fonctionnels automatisables
...

Plus d'info sur l'évènement ? Allez voir sur le site !

Venez nombreux !

Constuire une librairie "maison" : ou comment capitaliser à moyen terme

Olivier Hoareau — Tue, 07 Apr 2009 14:53:00 +0100

Vous avez déjà développé des dizaines de milliers de ligne de code.
Vous avez déjà contribué à plusieurs (2, 5, 10 ...) projets d'applications PHP dans votre entreprise.
Vous avez déjà, comme moi, eu ce sentiment quand vous étiez sur le développement d'un morceau de code, que vous aviez déjà codé cela une fois, mais impossible de vous souvenir "comment" et "où" retrouver le code.
"Ah, si j'avais un listing bien organisé de tout ce que j'ai codé rangé par fonctionnalité..."

Vous connaissez certainement le KISS (Keep It Simple and Stupid), mais connaissez-vous le DRY (Do no Repeat Yourself) ?
Voyons ensemble une méthode simple pour commencer à capitaliser sur vos développements.

Centraliser le code

Commencez par créer un repository SVN pour votre "librairie" de code "commun". Appellons la "phpcommon" (vous pouvez utiliser CVS ou un Git-like).

Organisez la librairie

Créez l'arborescence suivante à la racine de phpcommon :

/
    library/
    tests/
        unit/

Installez votre librairie (pour l'instant vide)

Faites un checkout de votre projet PHPCommon sur votre serveur dans un répertoire permanent par exemple /opt/phpcommon ou c:/php/phpcommon.
Puis ajoutez ce chemin /opt/phpcommon/library dans la directive include_path de votre fichier php.ini (si vous utilisez des serveurs pré-packagés tels que Wamp, EasyPHP ou Zend Server, veuillez à modifier tous les fichiers php.ini: mode CLI, mode CGI...).

Pensez "réutilisation" / "PHPCommon" avant tout

Dorénavant, lorsque vous avez un besoin de développement, posez-vous en premier la question :

Pour ce développement, que puis-je mettre dans ma librairie centrale, et que dois-je laisser dans cette application ?

Prenons un exemple concret:
Je dois ajouter la fonctionnalité d'envoi de SMS lorsque l'utilisateur réalise une action de modification sur le site / l'application.
Dans ce cas, que puis-je mettre dans ma librairie centrale ?
Réponse: peut être une fonctionnalité (nous parlerons de "service") d'envoi d'un SMS à un numéro donné.
Que dois-je laisser dans l'application ?
Réponse: la collecte des paramètres d'envoi du SMS (expéditeur, destinataire, message) ainsi que l'affichage de l'information à l'utilisateur ("message envoyé", "erreur survenue", ...)

Implémentez 1 fois dans PHPCommon / Utilisez plusieurs fois dans vos applications

Pour continuer sur l'exemple du SMS, nous pouvons alors coder un "service" d'envoi de SMS dans notre librairie en faisant par exemple 1 classe "Sms" qui nous propose une méthode constructeur qui prend les paramètres du SMS (expéditeur, destinataire, message...) et une méthode send() qui est censée envoyer le SMS (en utilisant par exemple une API HTTP fournie par un broker SMS), tout cela dans le fichier library/Sms.php

Une fois cette classe "codée" nous pourrons l'utiliser dans n'importe laquelle de nos applications en faisant :

<?php

...

require_once 'Sms.php';

$sms = new Sms($exp,$dest,$message);
$r = $sms->send();

... // tester $r pour savoir si il y a eu une erreur

Notre fonctionnalité d'envoi de SMS est devenue "utilisable" dans n'importe laquelle de nos applications, nous avons commencé à capitaliser sur nos "services" techniques "transverses".

Attention aux collisions !

En nommant votre classe Sms, vous prenez le risque de rentrer en collision de nommage avec une autre classe d'une autre librairie qui porterait le même nom. Il y aurait alors une erreur fatale à l'exécution du scripts.
Pour pallier à ce problème, il vous suffit de préfixer vos classes par le nom de votre entreprise ou un nom arbitraire, par exemple:

class Phpcommon_Sms
{
    ...
}

et mettre le fichier dans librairie/Phpcommon/Sms.php

Organisez vos fonctionnalités: Soyez modulaire

Vous allez donc pouvoir centraliser vos développements "communs" pour pouvoir les réutiliser. Mais petit à petit vous allez avoir de plus en plus de fichiers dans votre répertoire library et cela va devenir très vite chaotique car vous ne saurez plus quels fichiers vont ensemble...
Une possibilité serait d'avoir une organisation modulaire de vos fichiers en sous-répertoire "fonctionnels". Vous allez donc créer des "packages" (cette notion n'existe pas en PHP < 5.3 mais est simulable, PHP 5.3 apporte les namespaces).
Voici un exemple d'arborescence typique de votre répertoire librairie avec quelques exemples de briques de service:

/
    library/
        Phpcommon/
            Mail/
                Interface.php
                Service.php
            Sms/
                Adapter/
                    Orange.php
                    Sfr.php
                    Smsbox.php
                Interface.php
                Service.php
            Soap/
                Interface.php
                Service.php
            ...

De cette façon vous retrouverez facilement les classes nécessaires à telle ou telle fonctionnalité.

Testez et documentez votre code !

Tous vos développements "communs" ont de fortes chances d'être réutilisés dans plusieurs de vos applications. S'ils contiennent des bugs, des regressions au cours du temps ou bien si ils sont écrits trop rapidement, vous fragiliserez toutes les applications qui les utilisent et inversement, si vous développez avec soins dans cette librairie, que vous réalisez des tests unitaires et faites attention à la qualité de votre code, vous rendrez plus robuste et plus maintenable toutes les applications qui l'utilise.

Investissez sur votre librairie commune !

Et vous quelles sont vos pratiques pour factoriser votre code ?

Typer vos exceptions: les types d'exception génériques mais utiles

Olivier Hoareau — Sat, 04 Apr 2009 13:53:00 +0100

Si vous utilisez le mécanisme d'exception de PHP, vous devez savoir qu'il est possible de créer vos propres exceptions en héritant des classes Exception ou RuntimeException. (SPL), par exemple comme ceçi :

class MyException extends Exception
{
}

...

class MyException extends Exception
{
}

A l'usage vous vous êtes certainement rendu compte que vous levez des exceptions dans un nombre de cas limité, par exemple:

si une donnée nécessaire est nulle
si un enregistrement en base existe déjà
si une information fournie n'est pas au bon format
si l'information demandée n'a pas été trouvée
...

Vous pourriez créer une exception pour chaque cas précis de chacune des classes, mais cela vous obligerait à la longue à maintenir des dizaines de classes d'exceptions. Une autre solution est de rationnaliser vos exceptions en créant une liste limité et "immuable" (enfin presque) de types d'exceptions. Vous obligeant ainsi, quand vous souhaitez lever une exception à piocher dans les types d'exceptions déjà existant.

Voici la liste de classes d'exceptions que j'utilise personnellement régulièrement :

Adapter : type générique pour toute sous-couche d'implémentation technique
AlreadyExists : à utiliser pour indiquer qu'une opération de création d'une entité n'a pas aboutie car l'entité existe déjà (un fichier, une ligne en base, ...)
AlreadySet : à utiliser pour indiquer qu'une propriété modifiable une seule fois à déjà été modifié et qu'elle n'est plus modifiable
Assertion : à utiliser pour indiquer qu'un test systématique a échoué
BadFormat : à utiliser si le format de l'information fourni n'est pas correcte (email non valide, entier ou lieu de boolean ...)
Database : à utiliser comme surcouche aux exceptions PDOException par exemple, pour indiquer qu'une requête ou qu'une opération sur une base de données a échoué
Denied : à utiliser pour indiquer que l'accès à la fonctionnalité ou à la ressource n'est pas permi dans ce contexte (par exemple en fonction de la session ou d'un login ou profil d'utilisateur)
Missing : à utiliser pour indiquer qu'une information est manquante pour terminer l'opération
Multiple : à utiliser pour indiquer qu'il n'est pas possible de retourner l'information précise demandé car plusieurs entités existent (en base de données par exemple)
NotFound : à utiliser pour indiquer qu'une ressource ou information demandée n'a pas été trouvé (par exemple la lecture d'un fichier de configuration...)
NotYetImplemented : à utiliser pour indiquer un endroit du code non terminé (non implémenté). Cette exception est assez utile, mais si vous faite du TDD, vous ne devriez pas l'utiliser ;)
Null : à utiliser pour indiquer qu'une information d'entrée requise est nulle ou non fournie (par exemple une clé d'un array fourni, un objet normalement setté via un setter dans la classe...)
Timeout : à utiliser pour indiquer que le temps d'attente maximum à été dépassé (par exemple dans le cas d'une connexion réseau...)
TooMany : à utiliser pour indiquer que le nombre d'information à retourner est trop important
Unexpected : à utiliser en dernier recours pour indiquer une branche du code qui ne devrait jamais être déclenché (en règle générale je l'utilise dans un morceau de code compliqué pour lequel je ne maîtrise pas toute la logique...)

Cette liste n'est pas forcément exhaustive, vous pouvez en rajouter/supprimé bien sûr ! Par contre, je vous conseille de ne pas dépasser 15-20 types d'exceptions maximum, Ce qui vous permettra de bien les connaître et les avoir en tête et de ne pas dupliquer certains cas très similaires car trop précis.

Bien sûr pour éviter que les noms de classes rentrent en collision avec d'autres classes de votre code ou des librairies externe que vous utilisz, vous pouvez les mettre dans un pseudo package (avant php 5.3, en préfixant le nom de classe par Xxx_Exception_<Nom-de-l'exception>) ou un namespace (php 5.3+).

Il peut être judicieux de créer une classe centrale (par exemple Xxx_Exception) de laquelle toutes vos exceptions héritent. Ce qui vous permettra, de faire vos try/catch uniquement que sur l'ensemble des exceptions "normalisées" et laisser ainsi passer les autres exception non typées, très utile quand vous faites des tests unitaires ou pour détecter si votre code est robuste ou pas.

Une possibilité complémentaire est d'indiquer un code et/ou un message spécifique à vos exceptions, ce qui vous permettra par exemple de manipuler ce code dans des réponses AJAX ou HTML pour renvoyer un message d'erreur dans la langue de l'utilisateur. Sachant que vous maîtrisez les types d'exceptions (un maximum de 20 par exemple) vous pouvez leur donner des codes d'erreurs précis :

class Xxx_Exception_NotFound extends Exception
{
    const CODE = 1001;
    const MSG    = 'Resource not found';

    public function __construct($message=null)
    {
        parent::__construct(null === $message ?
               self::MSG : $message,self::CODE);
    }
}

Et vous quels sont vos usages en terme de typage d'exception ?

Salon Solutions Linux 2009 : Massacre d'éléPHPants !

Olivier Hoareau — Fri, 03 Apr 2009 14:11:00 +0100

Le salon Solutions Linux 2009 s'est déroulé du 31/03 au 02/04 au Parc des Expositions de Paris Porte de Versailles (Hall 2.2). Retour sur ma journée du Jeudi sur place...

Le salon Solutions Linux 2009 s'est déroulé du 31/03 au 02/04 au Parc des Expositions de Paris Porte de Versailles (Hall 2.2).

J'ai pu y participé le Jeudi (02/04), au programme, il y avait entre autre une journée avec pas mal de sessions PHP, notamment sur des retours d'expériences (20minute.fr) et des présentations de frameworks (ZF ...). Le stand AFUP, placé dans le village associatif, a été pris d'asso par les amateurs d'ElePHPant (vous avez ce petit éléphant bleu avec un gros logo PHP !), plusieurs dizaines d'ElePHPant ont été sacrifié par l'AFUP au profit de leur nouveau maître...

Parmi les points que j'ai noté sur le sujet PHP, ont a pu y voir :

Le stand AFUP ayant permis d'échangé avec des entreprises qui utilisent PHP sur leur sites ou applications à forte volumétrie (plusieurs millions de visiteurs par mois)
Des débats sur "Alors je prends ZF ou Symfony ?"
Alterway et son stand d'essai de certification PHP
Zend et son nouveau Zend Server
L'AFUP qui réglait des bugs PHP en live
Bull et sa forge (usine de développement) Novaforge pour PHP (entre autres)
La dédicace du livre sur PDO de notre trésorier préféré de l'AFUP (Christophe V.)
FAASCAPE qui lance son service de Feature As A Service sur le nuage (avec des devs en PHP peut être à venir)
...

Une journée forte intéressante ! J'attends l'année prochaine avec impatience !

En attendant vous pouvez voir quelques photos prises pour l'occasion par J. Pauli.

Chasser les dépendances implicites : où comment rendre votre code moins obscur

Olivier Hoareau — Tue, 10 Feb 2009 09:04:00 +0000

En PHP, comme dans beaucoup d'autres langages, nous pouvons faire des fonctions et des méthodes qui prennent des arguments.

Prenons la fonction suivante : ...

En PHP, comme dans beaucoup d'autres langages, nous pouvons faire des fonctions et des méthodes qui prennent des arguments.

Prenons la fonction suivante :

function loadConfig()
{
    global $CFG;
    $CFG = parse_ini_file(dirname(__FILE__).'/config/main.ini',true);
}

Cette fonction peut être appelée comme suit dans un fichier index.php :

...
loadConfig();
...

Mais que se passe-t-il si :

vous déplacez votre fichier index.php (relativement par rapport au fichier config/main.ini), ou inversement ?
vous changez le nom de la variabe $CFG dans votre script index.php ?

Ainsi la fonction loadConfig() a une double dépendance :

elle dépend de l'existence d'un fichier de configuration config/main.ini au format ini
elle dépend de l'utilisation de la variable globale $CFG

Pourtant rien n'indique clairement ces dépendances dans son utilisation ou même sa déclaration (la signature de la fonction). Si vous développez cette fonction, vous vous souviendrez qu'elle a ces 2 dépendances; par contre, si vous la développez et que quelqu'un d'autres l'utilise dans son script (vous êtes en équipe par exemple et des nouveaux arrivent régulièrement) alors à moins de lire le code source de cette fonction rien ne lui indiquera ces 2 dépendances, ce qui peut occasionner des erreurs (renommage de fichiers ou de variable).

Comment faire ?

Expliciter systématiquement les dépendances externes de vos fonctions ou de vos méthodes / classes. Pour cela, vous pourriez faire une variante de votre fonction loadConfig() comme suit :

function loadIniConfigFileIntoArray($configFile,&$cfg)
{
    if(false===file_exists($configFile)) {
        throw new RuntimeException("Configuration file '$configFile' does not exist");
    }
    $cfg = parse_ini_file($configFile);
}

ou alors en retournant une référence (on pourrait aussi renvoyer un objet sans faire de référence en PHP5, ce qui est automatique) :

function &loadIniConfigFile($configFile)
{
    if(false===file_exists($configFile)) {
        throw new RuntimeException("Configuration file '$configFile' does not exist");
    }
    $cfg = parse_ini_file($configFile);
    return $cfg;
}

Vous pourriez ainsi indiquer dans les commentaires de la fonction :

/**
 * Parses the specified configuration file (ini format) and returns an array
 *
 * @param string $configFile the full path of the configuration file to parse
 * 
 * @return array the data structure containing the configuration
 *
 * @throws RuntimeException if file does not exist
 */

Dans le même principe, veuillez à rendre plus explicite les dépendances externes de vos fonctions envers :

les variables globales (ou de registre si utilisation de framework tel que Zend Framework)
les connexion base de données ou les ressources (fichiers,...)
les constantes
les fichiers
...

De la nécessité de vérifier l'état des connexions/requêtes à la base

Olivier Hoareau — Wed, 04 Feb 2009 11:41:00 +0000

Imaginez un site marchand sur lequel olivier@email.fr a un compte et sur lequel il fait un achat d'ordinateur, au moment de la validation et du paiement, nous écrivons en base de données : ...

Imaginez un site marchand sur lequel olivier@email.fr a un compte et sur lequel il fait un achat d'ordinateur, au moment de la validation et du paiement, nous écrivons en base de données :

mysql_query("INSERT INTO commandes (produit,prix,compte) VALUES ('Ordinateur',699,'olivier@email.fr')");
...
mysql_query("UPDATE comptes SET montant = montant + 699 WHERE email = 'olivier@email.fr')");

Question : que se passe-t-il si la connexion à la base de données est perdu lors de la première requête (problème réseau par exemple) ou bien que le nombre de visiteurs sur votre site marchand est tellement important que le nombre de connexion base de données maximum est atteint et que PHP retourne une erreur sur la première requête SQL (du style "unable to connect to ...) ?

Ce qui va se passer : vous allez avoir une erreur de type warning (si vous les avez désactivées en prod, elle sera passée sous silence et juste inscrite dans le fichier de log de php), la deuxième requête va alors être exécutée, et par chance, la connexion refonctionne (les problèmes de charge peuvent être très volatile). Vous allez alors vous retrouver avec un problème d'intégrité en base de données (la commande n'aura pas été ajouté mais le montant des achats du compte aura été mis à jour). Les effets de bord peuvent être alors multiples et dépendent de la logique qui suit. Si vous affichez dans l'espace client de l'utilisateur le montant de ses achats, vous aurez des valeurs erronées et il manquera une des commandes de l'utilisateur.

Comment faire ?

Il est nécessaire de vérifier systématiquement le statut de l'exécution de la requête que vous avez effectuée :

$result = mysql_query("INSERT INTO commandes (produit,prix,compte) VALUES ('Ordinateur',699,'olivier@email.fr')");
if (false === $result) {
    // une erreur d'exécution de la requête SQL a été détecté, il est nécessaire de ne pas continuer le processus et de traiter l'erreur
    // une façon apropriée est de lancer une exception, qui sera "catchée" par la méthode ou la fonction appelante
    throw new RuntimeException("Unable to add commande to database: ".mysql_error());
}
...
$result = mysql_query("UPDATE comptes SET montant = montant + 699 WHERE email = 'olivier@email.fr')");
if (false === $result) {
    // une erreur d'exécution de la requête SQL a été détecté, il est nécessaire de ne pas continuer le processus et de traiter l'erreur
    // une façon apropriée est de lancer une exception, qui sera "catchée" par la méthode ou la fonction appelante
    throw new RuntimeException("Unable to update comptes in database: ".mysql_error());
}
...

D'accord, mais que se passe-t-il si l'erreur survient sur la deuxième requête SQL ? nous allons bien détecter l'erreur mais la première requête en base (l'insertion) aura déjà été effectuée et nous aurons donc une inconsistance en base de données si nous ne réalisons pas la seconde requête. Il est donc nécessaire d'introduire la notion de transaction, c'est à dire d'une séquence de requêtes considérées comme atomique (indissociable) :

$result = mysql_query("BEGIN");
if (false === $result) {
    // impossible de commencer la transaction, on doit afficher une page d'erreur générique au client par exemple
    throw new RuntimeException("Unable to begin transaction: ".mysql_error());
}

$result = mysql_query("INSERT INTO commandes (produit,prix,compte) VALUES ('Ordinateur',699,'olivier@email.fr')");
if (false === $result) {
    // une erreur d'exécution de la requête SQL a été détecté, il est nécessaire de ne pas continuer le processus et de traiter l'erreur
    // une façon apropriée est de lancer une exception, qui sera "catchée" par la méthode ou la fonction appelante
    mysql_query("ROLLBACK");
    throw new RuntimeException("Unable to add commande to database: ".mysql_error());
}
...
$result = mysql_query("UPDATE comptes SET montant = montant + 699 WHERE email = 'olivier@email.fr')");
if (false === $result) {
    // une erreur d'exécution de la requête SQL a été détecté, il est nécessaire de ne pas continuer le processus et de traiter l'erreur
    // une façon apropriée est de lancer une exception, qui sera "catchée" par la méthode ou la fonction appelante
    mysql_query("ROLLBACK");
    throw new RuntimeException("Unable to update comptes in database: ".mysql_error());
}
...

$result = mysql_query("COMMIT");
if (false === $result) {
    // impossible de commiter la transaction. aucune donnée ne sera inserée/modifiée en base
    // il est nécessaire d'afficher une page d'erreur à l'utilisateur pour lui indiquer que sa commande n'a pas été prise en compte
    throw new RuntimeException("Unable to commit transaction to database: ".mysql_error());
}

Ce type de technique est intéressant car il sécurise et rend votre application plus robuste. Un point cependant a noter est que l'application deviendra alors moins silencieuse au problème et le moindre problème de connexion ou de charge sera tout de suite mis en exergue et déclenchera des exceptions. A vous donc de vérifier systématiquement dans vos méthodes/fonctions appelantes qu'il n'y a pas eu une exception.

Les fonctions mysql_query/mysql_error ont été utilisée pour l'exemple, mais cette technique s'applique sans soucis à des frameworks/lirairies d'abstraction de connexion au base de données tels que PDO, Zend_Db (Zend Framework), ... Il faut toujours vérifier dans la documentation la valeur ou le type de retour d'une fonction/méthode d'appel à la base base de données en cas d'erreur (les fonctions standards PHP retourne souvent FALSE au lieu d'une ressource si un problème est survenu en plus de lancer un warning).

Et vous quelles sont vos techniques pour gérer ce genre de problème ?

Points de contrôle automatisés avant un développement ou comment maîtriser un déploiement

Olivier Hoareau — Fri, 23 Jan 2009 08:51:00 +0000

Vous avez une mise en production hyper importante aujourd'hui. Votre client (interne) vous a mis la pression et vous avez dû raccourcir les délais pour être à l'heure. Vous packagez votre release d'application, vous la passez sur l'environnement de tests fonctionnels, tout se passe bien. Vous la passez sur l'environnement d'intégration et tout se passe bien, mais vous noter un ou deux comportement étrange, sans gravité, bizarre. Vous décidez de la passer en pré-production, et là ... Tout plante ! L'application ne se lance même plus et c'est la page blanche...

Pourquoi ?

Vous investiguez et vous découvrez que l'environnement de pré-production n'est absolument pas à jour (choisissez une ou plusieurs lignes dans la liste) :

- mauvaise version de PHP

- mauvaise version de votre framework MVC habituel

- mauvaise version de votre librairie de composants interne partagée

- extension SOAP manquante

- répertoire de log inexistant sur la machine (votre application ne le crée pas si il n'existe pas...)

- connexion à la base de données non fonctionnelle car les identifiants ont changé...

- ...

La catastrophe.

Vous décidez donc de regarder sur la machine de production, et bien sûr vous faites les mêmes découvertes...

Résultat: votre mise en production est décalée de 1/2 journée, vous mettez la pression aux équipes plateformes pour qu'elles mettent tous les environnements à jour, et vous prenez un savon par votre client (interne) qui vous prend pour un amateur.

Comment éviter cela ?

Vous pouvez acheter le dernier outils à la mode qui compte XXXX k€ et qui vérifie tout, mais c'est long à mettre en place et surtout ca coûte très cher dans votre budget (ou celui des équipes plateformes), en plus les tests réalisés seront soit très générique soit il faudra peut être un peu tordre l'outils pour faire certaines vérifications un peu spécifique à votre application (test de la connexion mysql, vérification de la version de votre framework préféré...)

Une autre solution consiste à réaliser un petit script, PHP, qui va faire tous les tests spécifiques qui vous intéresse et vous faire un rapport directe. Appellons le "PHP Sanity Check(er)".

Une contrainte cependant : tout doit tenir dans un script (1 fichier) et aucune installation ou dépendance autre que le dépôt du fichier dans l'arborescence du serveur web ne doit être nécessaire. En effet, il serait dommage que votre script ne fonctionne qu'avec une dépendance à la librairie TUTU et que cette librairie ne soit pas installée sur la plateforme (qui le vérifierait ?)

Le script peut être très simple et faire une série de version_compare(), de stream_socket_client(), de file_exists(), extension_loaded(), de vérification de variable $_SERVER.... c'est du PHP, vous pouvez donc tout faire ;), par contre, avant d'utiliser mysql(i)_connect, vérifiez (via un test dans le script) que l'extension mysql(i) est bien chargée !

Oui mais j'ai plusieurs applications croisées avec plusieurs environnements, ce qui m'oblige à faire des suites de tests différentes, comment faire ? je duplique le script pour chacun des cas et je maintiens les différentes versions ? une usine à gaz !

Non.

Vous êtes malin.

Vous développez donc une seule fois, vous faites des fichiers de configuration spécifiques à chacun des applications/environnements et "vous générez un script spécifique pour chacun des cas".

Comment ?

Grâce, par exemple à Phing et Phar.

Vous créez votre script générique qui prend une liste de tests écrit dans un fichier de configuration (par exemple xml). Voici un exemple de fichier :

<?xml version='1.0' encoding='iso-8859-1' ?>

<psc>
	<test info="PHP Version" type="php:minimum-version" arg1="5.0.0"/>
	<test info="Windows Platform" type="php:os" arg1="winnt"/>
	<test info="Google is Reachable" type="network:tcp-port-reachable" arg1="www.google.com" arg2="80"/>
</psc>

Votre script lit le contenu du fichier xml, en sort une liste de tests correspondant à des appels de méthodes de classes :

- Php::checkMinimumVersion('5.0.0')

- Php::checkOs('winnt')

- Network::checkTcpPortReachable('www.google.com','80')

Vous écrivez ensuite les classes Php (dans Php.php ;)) et Network (dans Network.php) qui contiennent chacunes les méthodes listées, vous pouvez bien sûr en rajouter d'autres, si elles ne sont pas listées dans le fichier de configuration elle ne seront pas utilisées.

Vous faites en sorte que chacune des méthodes lève une exception si le test ne passe pas avec un message d'erreur compréhensible sur le problème.

A l'exécution, vous récupérez le résultat d'exécution de chacune des méthodes (en faisant un try/catch par dessus) et vous affichez cela dans un tableau HTML qui va bien avec des couleurs verte et rouge.

Mais à quoi sert Phar ?

Venons-en à Phar. Phar ou encore "PHP Archive" permet de condenser plusieurs scripts PHP dans un seul fichier (.phar), il peut être compressé ou non. Le moteur PHP saura exécuter le fichier .phar comme si il était un script .php La seule différence est que le .phar contenant plusieurs fichiers php, il faut lui indiquer précisément quel est le premier script a exécuter (celui-ci pourra faire des includes des autres éventuellement).

Vous pouvez donc faire plein de fichiers/scripts/classes dans votre outils et les packager dans un seul et même fichier .phar en y embarquant même le fichier de configuration nécessaire. A l'exécution, vos scripts se comporteront comme si ils étaient dans un répertoire sur le disque et vous pourrez utiliser les includes.

Mais à quoi sert Phing ?

Phing, est un outils de scripting cross-platform (xml) écrit en PHP (port de Ant venant de Java). Il permet de décrir des batchs de commandes (systèmes souvent) à réaliser sous forme xml (ca marche donc sous windows, mac, linux...), voici ce que nous pourrions faire pour packager notre PHP sanity Checker pour générer un .phar à installer sur les plateformes pour notre application TOTO :

    <target name="package" depends="init" description="Packages the phar script to deploy on platform (use -Dsuite=<your-suite>)">
    	<delete dir="tmp/package"/>
    	<mkdir dir="tmp/package"/>
    	<mkdir dir="tmp/package/config/suites"/>
    	<copy file="config/suites/${suite}.xml" tofile="tmp/package/config/suites/default.xml"/>
    	<copy todir="tmp/package">
    		<fileset dir=".">
    			<include name="**/*.php"/>
    		</fileset>
    	</copy>
    	<phar to="tmp/check.phar">
    		<fileset dir="tmp/package">
    			<include name="**/*"/>
    		</fileset>
    	</phar>
    </target>

Pour exécuter cette liste de commandes, vous faites :

$ phing package -Dsuite=mon-application

ce qui aura pour but de packager le fichier mon-application.xml avec vos scripts php (ceux de votre outils de tests) dans un fichier tmp/check.phar.

Dernière étape, vous déployez (vous copiez) le fichier check.phar sur votre plateforme cible dans l'arborescence du serveur web, et vous accédez à ce fichier comme si il s'agissait d'un fichier .php (configurer apache pour qu'il traite les fichiers .phar comme les fichiers .php).

Des commentaires ?

Charger un fichier de configuration à la demande sans changer l'url

Olivier Hoareau — Mon, 24 Nov 2008 16:03:00 +0000

Votre application est exécutée sur plusieurs environnements différents (dev, integration, preprod, prod, ...).
Vous avez bien fait les choses, les différences entre les environnements sont externalisées dans un fichier de configuration de sorte que le code (php) soit identique sur l'ensemble des environnements.
Dans votre code, vous détectez l'environnement sur lequel est exécuté votre code grâce à l'utilisation d'une variable d'environnement "système" (ex: PHP_ENV) qui contient le nom de l'environnement. La valeur de cette variable est donc différente sur chacun des serveurs. Vous utilisez soit une variable d'environnement système et la directive PassEnv d'Apache, soit la directive SetEnv d'Apache pour positionner la valeur dans vos fichiers de configuration Apache des différents serveurs, par exemple dans le fichier httpd.conf du serveur de pré-production :

SetEnv PHP_ENV preprod

Si vous êtes dans ce cas là, Apache vous permet de surcharger facilement la valeur de la variable PHP_ENV lors d'une requête HTTP, rajoutez la ligne suivante dans votre fichier httpd.conf :

SetEnvIf X-PHP-Env "(.+)" PHP_ENV=$1

Maintenant si vous faites une requête HTTP en passant le header HTTP :

X-PHP-Env: integration

Même si votre application est exécutée sur l'environnement de pré-production, elle chargera le fichier (ou la section de configuration) liée à l'intégration.

Cette technique peut vous aider dans différents cas :

vous n'avez qu'un seul serveur, mais vous souhaitez gérer plusieurs environnements sur la même version du code (l'url reste la même, c'est juste le header X-PHP-Env qui change)
vous souhaitez charger une base de tests facilement, vous créez alors un environnement prod_test qui à les mêmes caractéristiques que prod mais qui pointent sur une base de tests au lieu de pointer sur la base de production. (l'url reste la même c'est juste le header X-PHP-Env qui change)
...

Vous voyez d'autres utilisations ?

PS: dans mon cas, cela permet d'effectuez des tests de non regressions sur des WebServices, sans changer l'url, mais en chargeant une base de données distantes qui contient un jeux de données de tests

PS2: pour tester manuellement (i.e. avec un navigateur) cette solution, vous devrez installez un plugin à votre navigateur qui vous permettent de modifier les headers http de la requête (LiveHTTPHeaders de mémoire sous Firefox fait cela très bien)

Comment utiliser le même fichier build.xml (Phing) pour plusieurs projets

Olivier Hoareau — Thu, 20 Nov 2008 16:39:00 +0000

Voici un problème que l'on rencontre souvent quand le nombre de projets grossit, grossit...

Au début, nous avons un projet.

On créé un fichier build.xml, que l'on versionne avec le code. ...

Voici un problème que l'on rencontre souvent quand le nombre de projets grossit, grossit...

Au début, nous avons un projet.

On créé un fichier build.xml, que l'on versionne avec le code.

Ensuite, on crée un deuxième projet, en utilisant les mêmes pratiques que le premier (ce sont les mêmes développeurs ou les mêmes outils / pratiques de développpement).

Solution de facilité, on copie le fichier build.xml du premier projet dans le second et on le versionne (duplicata) dans le deuxième projet.

Ensuite on créé un 3ième, 4ième, ..., Nième projet (toujours en dupliquant le fichier build.xml).

Viens le jour ou nous mettons à jour nos pratiques / outillage de développement. On se rend alors compte qu'il faut une "cible" PHING de plus pour gérer le déploiement sur notre nouveau serveur de préprod. Et la : Damned ! Il faut modifier tous les fichiers build.xml de chacun de projets (qui au passage ont certainement évolué chacun dans leur coin...)

Comment faire pour mutualiser ce fameux fichier (build.xml) ?

Build.xml, c'est du XML non ? On aurait pu se dire, nous n'avons qu'à utiliser un mécanisme d'inclusion ou d'héritage (par exemple un extends="c:/common/build.xml"), oui, mais ce n'est pas possible (aujourd'hui) a priori.

Comment faire ?

Phing propose le paramètre en ligne de commande "-f" ou "-buildfile" permettant de spécifier un fichier build.xml alternatif. En effet, par défaut c'est celui du répertoire courant qui est utilisé si il existe (l'exécution de phing plante si il n'existe aucun fichier build.xml dans le répertoire courant)

L'idée est alors la suivante :

créer un fichier build.xml "générique" que vous positionnez dans un répertoire précis de votre système (ex: c:\dev\phpcommon\phing\build.xml, ou /etc/phpcommon/phing/build.xml)
créer un script myphing.bat ou myphing.sh qui contient le code suivant :

phing -f $PHPCOMMON_HOME/bin/build.xml $*

ajouter la variable d'environnement PHPCOMMON_HOME avec la valeur c:/dev/phpcommon ou /etc/phpcommon dans la liste des variables d'environnement système
ajouter le répertoire %PHPCOMMON_HOME%/bin dans le path de votre système (variable d'environnement)
redémarrer votre système (ou la ligne de commande)
créer le fichier c:/dev/phpcommon/phing/build.xml avec le contenu suivant :

<?xml version="1.0" encoding="UTF-8"?>

<project name="php" basedir="." default="build">

    <property name="common.dir"      value="${project.basedir}/../"  override="true"/>
    <property name="project.basedir" value="${application.startdir}" override="true"/>

     ...

</project>

Vous pouvez maintenant utiliser la ligne de commande :

$ myphing <target>

pour exécuter la cible <target> situé dans le fichier c:/dev/phpcommon/phing/build.xml, à partir de la racine de votre projet.

Vous n'avez plus forcément besoin d'un fichier build.xml local à votre projet, sauf si vous avez des cibles (targets) spécifiques à votre projet (ce que je vous déconseille si vous avez plusieurs projets, je pense qu'il vaut mieux rationnaliser vos cibles). Si vous décidez toutefois de garder un fichier build.xml local à votre projet, vous pourrez l'utiliser en appelant la ligne de commande habituelle :

$ phing <target>

Maintenant, il ne vous reste plus qu'à créer l'ensemble de vos cibles communes / génériques à tous vos projets. Je vous propose d'ailleurs les miennes dans ce billet.

Entreprises du CAC 40 : Quelles plateformes pour leur site internet ?

Olivier Hoareau — Fri, 14 Nov 2008 08:00:00 +0000

Voici un graphique de répartition des plateformes utilisées par les entreprises du CAC40 pour leur site internet

(Analyse réalisée en Juin 2008)

Vous pouvez télécharger la feuille excel qui a permi de construire cette synthèse

D'une application mono-marque à une application multi-marque : comment faire simple ?

Olivier Hoareau — Wed, 12 Nov 2008 08:00:00 +0000

Vous avez développé une application PHP complexe (ou pas).

Le succès de votre application auprès de votre client (interne ou externe) vous amène à devoir décliner votre application dans plusieurs versions : ...

Vous avez développé une application PHP complexe (ou pas).

Le succès de votre application auprès de votre client (interne ou externe) vous amène à devoir décliner votre application dans plusieurs versions :

une pour votre client historique
une pour un nouveau client (concurrent de l'autre ?!)
une "marque blanche" pour démontrer les fonctionnalités de votre application en mode démo
...

Votre application n'a pas été prévu pour cela, vous avez donc plusieurs options :

dupliquer le code, purement et simplement
mutualiser le code, et l'altérer pour qu'il gère les différences entre les versions (marques)

La première solution, bien que potentiellement plus rapide à mettre en oeuvre, se révèle couteuse dans le temps car il faut maintenir deux versions de l'application en parallèle (et répercuter les fix de bugs sur les différentes versions,...).

Pour implémenter la deuxième solution, il vous faut principalement :

externaliser les paramètres de configuration de l'application susceptible de changer en fonction de la version (connexion base de données, nom du client...)
mutualiser le code du coeur de l'application (i.e. la logique)
spécialiser la charte graphique (pour tel ou tel client ou version)
ajouter des "plugins" spécifiques à votre application qui seront spécifiques à telles ou telles versions (pour tel ou tel client)

Concrètement, il s'agit pour vous à minima (si il s'agit de la même application fonctionnellement) pour chacune des versions de :

donner un nom de code à votre version, ex: client1
créer un virtual host Apache spécifique, ex: client1.mondomaine.com
réaliser un fichier CSS spécifique, ex: styles/client1.css
réaliser un fichier JS spécifique, ex: scripts/client1.js
réaliser un fichier de configuration spécifique, ex: configs/client1.php
réaliser un fichier d'initialisation PHP spécifique, ex: inits/client1.php

Vous faites ensuite pointer tous les Virtual Hosts sur le même DocumentRoot (i.e. il n'y a qu'une seule application, un seul répertoire racine) définissez ensuite à l'intérieur du virtual host de chacune des versions une variable d'environnement dont la valeur prend le nom de code de la version, par exemple :

SetEnv APP_NAME client1

Ensuite au début de (chacun de vos|votre) scripts?, vous pouvez récupérer la valeur de cette variable d'environnement et la positionner dans une constante :

<?php

define('APP_NAME',$_SERVER['APP_NAME']);
...

Vous disposez maintenant d'une constante disponible dans tous vos fichiers inclus qui contient le nom de l'application, elle peut servir pour charger les bons fichiers :

<?php

require_once dirname(__FILE__).'/../configs/'.APP_NAME.'.php';
require_once dirname(__FILE__).'/../inits/'.APP_NAME.'.php';

...
// la logique de votre application ici
...
?>
<html>
    <head>
        ...
        <link rel="stylesheet" type="text/css" href="/styles/@common.css"/>
        <link rel="stylesheet" type="text/css" href="/styles/<?php echo APP_NAME ?>.css"/>
        <script type="text/javascript" src="/scripts/@common.js"><!-- --></script>
        <script type="text/javascript" src="/scripts/<?php echo APP_NAME ?>.js"><!-- --></script>
        ...

Si la logique de votre application diffère quelques peu en fonction de la version, vous avez 2 solutions :

faire des switch(APP_NAME) dans la logique et coder les spécificités dans le même fichier
externaliser les spécificités dans des fichiers distincts (de préférence des classes ;)), faire un include('features/'.APP_NAME.'.php'); au début de votre script et coder différentes versions de la fonction ou de la classe dans chacun des fichiers features/*.php

Si vous travaillez en objet, vous pouvez réaliser des interfaces que devront implémenter vos implémentations spécifiques de vos "features" et charger la bonne classe en faisant par exemple :

<?php

...
$featureClass = ucfirst(APP_NAME).'_Feature1Service';
require_once dirname(__FILE__).'/../classes/'.str_replace('_','/',$featureClass).'.php');
$feature = new $featureClass;

$result = $feature->laMethodeQuiMInteresse($leParam1,$leParam2);

...

Vous n'avez plus qu'à coder le fichier classes/Client1/Feature1Service.php :

<?php

class Client1_Feature1Service implements Feature1Interface {
    public function laMethodeQuiMInteresse($leParam1,$leParam2) {
        // votre code spécifique ici
        ...
    }
}

Si un nouveau client vous demande une version de votre application adapté à ses besoins, vous créez simplement ou nouveau virtual host Apache, un nouveau nom de code pour la version (ex: client2), un nouveau fichier de configuration et d'initialisation (configs/client2.php, inits/client2.php), des nouveaux fichiers CSS et JS (styles/client2.css, scripts/client2.js) et une nouvelle version de vos features spécifiques (classes/Client2/Feature1Service.php)

Ce type de méthode peut être mise en conjonction avec l'utilisation de frameworks comme Zend Framework, pensez à la variable d'environnement APP_NAME dans Apache !

Et vous quelles sont vos pratiques ?

Les 10 commandements du développeur PHP en entreprise : ma proposition

Olivier Hoareau — Mon, 10 Nov 2008 19:22:00 +0000

Si PHP développeur tu es, ces 10 commandements tu respecteras : ...

Si PHP développeur tu es, ces 10 commandements tu respecteras :

Faire simple ET propre
Développer en TDD : le test d’abord, le code ensuite
Committer sur barre verte (tests en succès)
Respecter des conventions de codage connus en dehors de l'entreprise
Développer 1 fois, Réutiliser plusieurs fois
Tester unitairement toutes les fonctionnalités du coeur de l'application
Utiliser les comparaisons de valeurs ET de types (===, !==)
Réaliser systématiquement des implémentation mocks (bouchons)
Ne pas dépasser plus de 80 lignes aérées et commentées pour une fonction/méthode
Always Have Fun !

Qu'en pensez-vous ?

(TDD = Test Driven Development)

Phing : mes targets préférés

Olivier Hoareau — Fri, 07 Nov 2008 08:00:00 +0000

$ phing -l

et voici mes targets phing préférées : ...

$ phing -l

et voici mes targets phing préférées :

check-code : Checks the quality of the code towards PEAR standard and display errors
check-code-xml : Checks the quality of the code towards PEAR standard and export to xml file
check-source : Checks the quality of the source files and print HTML report with metrics
check-syntax : Checks the syntax of the code (Lint)
checks : Checks the quality of the code (check-syntax, check-code-xml, check-source)
doc-api : Generates the PHPDocumentor API Documentation
docs : Generates the documentation
init : Preparation/initialization of the build
test-functional-fitnesse : Executes functional tests (Fitnesse)
test-functional-greenpepper : Executes functional tests (GreenPepper)
test-gui-selenium : Executes GUI tests (Selenium)
test-unit : Executes unit tests (PHPUnit) and code coverage (XDebug)
tests : Executes all tests (unit, functional, gui)
build : Automatic Build executed by Hudson (checks, tests)
post-build : Automatic Post-build executed by Hudson (docs)
generate-package-xml : Prepare PEAR package2.xml
package-tar : Create a Tar package of the application
packages : Launches all the packages
prepare-package : Prepare packages

Quelles sont les vôtres ?

Pattern Factory : Ou comment faire tout en 1 ligne

Olivier Hoareau — Wed, 05 Nov 2008 08:00:00 +0000

Vous révez de ça :

<?php

$service = new MonService()
    -> setConfig(...)
    -> setAdapter(...)
    -> setModel(...)
    -> process();

...

Vous révez de ça :

<?php

$service = new MonService()
    -> setConfig(...)
    -> setAdapter(...)
    -> setModel(...)
    -> process();

Mais ce n'est pas possible en PHP et vous avez l'erreur suivante (ligne 4 = ligne du setConfig() ) :

PHP Parse error:  syntax error, unexpected T_OBJECT_OPERATOR in <votre-fichier-ici> on line 4

Du coup, désespérement vous devez faire :

$service = new MonService();
$service
    -> setConfig(...)
    -> setAdapter(...)
    -> setModel(...)
    -> process();

Imaginez d'autre part, qu'à plusieurs endroits dans votre application vous utilisez systématiquement toujours la même classe, avec des instances différentes, mais qu'à chaque fois vous deviez reconfigurer l'objet de la même manière en faisant par exemple :

$service1 = new MailService();
$service1->setOutgoingAdapter(new SendmailAdapter());
$service1->setIncomingAdapter(new PostfixAdapter());
...
$service1->send(...);
...
...
$service2 = new MailService();
$service2->setOutgoingAdapter(new SendmailAdapter());
$service2->setIncomingAdapter(new PostfixAdapter());
...
$service2->send(...);

A chaque fois que vous désirez instancier votre MailService, vous avez le droit d'écrire 3 lignes de code...

Le pattern Factory peut alors vous aidez. Vous pourriez définir un "paramétrage" par défaut de votre service qui soit déjà tout préconfiguré :

class MailService {
   ...
   public final static function factory($type='default') {
       $service = new MailService();
       switch($type) {
       case 'default':
           $service->setOutgoingAdapter(new SendmailAdapter());
           $service->setIncomingAdapter(new PostfixAdapter());
           break;
      case 'mock':
          $service->setOutgoingAdapter(new MockOutgoingAdapter());
          $service->setIncomingAdapter(new MockIncomingAdapter());
          break;
      default:
          throw new RuntimeException("Unknown factory type '$type'");
      }
      return $service;
   }
}

Vous pourrez maintenant appeler votre service en une seule ligne de code :

$result = MailService::factory('default')->send(...);

Pensez à factoriser votre code !

Web Services : Avoir le réflexe mise en cache pour optimiser la charge serveur

Olivier Hoareau — Mon, 03 Nov 2008 08:00:00 +0000

Vous avez développé votre tout dernier web service destinés à être utilisé par 2 ou 3 autres équipes en interne (voire en externe par des partenaires).

Il (le web service) fonctionne bien, tellement bien, que vous commencez à avoir plusieurs dizaines de requêtes par jour. ...

Vous avez développé votre tout dernier web service destinés à être utilisé par 2 ou 3 autres équipes en interne (voire en externe par des partenaires).

Il (le web service) fonctionne bien, tellement bien, que vous commencez à avoir plusieurs dizaines de requêtes par jour.

Vous n'aviez pas forcément optimisé les performances du web service, les temps de réponses ne sont pas au beau fixe car vous chargez 150 classes PHP qui sont nécessaires au tout dernier framework à la mode pour accéder à une table de base de données et faire une requête select sur un champ avec une clé primaire pour retourner la fiche descriptive d'un utilisateur, d'un partenaire ou d'un produit. Ou bien, pire encore, pour renvoyez votre catalogue de produits qui fait 150Ko une fois transformé au format XML.

Vous êtes vous posé la question suivante :

A quelle fréquence mes données changent-elles ?

En effet, à quoi cela vous sert-il de générer par une logique complexe un export (xml, json, text, soap...) de vos données si elles ne changent pas à la même fréquence que les requêtes qui vous parviennent ?

De façon plus optimale, vous pourriez générer une première fois cet export, la première fois qu'il vous est demandé par exemple, et le mettre en cache dans un fichier. Ce fichier pourrait alors être servi pour toutes les requêtes successives, et ce jusqu'à temps que vos données ne changent (en base de données par exemple), vous auriez alors à supprimer le fichier de cache et faire en sorte que votre application le détecte et le régénère à la demande.

Comment faire ?

Si vous utilisez Apache, vous pouvez mettre en oeuvre l'url rewriting en créant un fichier .htaccess à la racine publique de votre application en y mettant, par exemple :

...
RewriteEngine On

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_URI} !-f
RewriteRule ^/mon-webservice/(.*).xml monwebservice.php?id=$1
...

Ainsi, Si un utilisateur requête /mon-webservice/voitures/peugeots.xml, Apache commencera par vérifier si le fichier 'mon-webservice/voitures/peugeots.xml' existe sur le disque dur (dans votre DocumentRoot) et si c'est le cas, il le renverra directement sans passer par aucun script PHP. Si le fichier n'existe pas, alors votre script 'monwebservice.php' sera appelé et sera chargé de renvoyer le contenu.

Vous pourriez alors avoir dans monwebservice.php un code similaire à celui-ci :


ob_start();

// votre logique ici
// ...

$xml = ob_get_contents();
ob_end_clean();

file_put_contents(dirname(__FILE__)."/mon-webservice/$id.xml",$xml);

header('Content-Type: text/xml');
echo $xml;

Ainsi, à chaque fois qu'il sera appelé, votre script générera le xml, l'écrira dans un fichier sur le disque (le fichier de cache visible dans votre DocumentRoot) et renverra le contenu XML au navigateur.

Dernière étape, il vous reste maintenant à supprimer le fichier de cache lorsque celui-ci devient obsolète, par exemple quand les données en base de données changent ou bien que certaines données temporelles ou calculées doivent être mises à jour. Dans le premier cas, la mise à jour de la base de données se fait en règle général par l'intermédiaire d'un autre de vos script (par exemple /admin/index.php), il suffit d'include dans ce script la ligne suivante :

...
unlink(dirname(__FILE__).'/../mon-webservice/voitures/peugeot.xml');
...

Si vous ne maîtrisez pas la mise à jour de la base de données ou que le cache devient obsolète à cause de données temporelles, songez à proposer un script déclenchable à distance (par un cron ou bien pas l'application mettant à jour la base de données) qui supprimerait les fichiers de cache incriminés.

SessionSwitcher : Ou comment accélerer vos tests IHMs manuels en 60 lignes de code

Olivier Hoareau — Fri, 31 Oct 2008 23:42:00 +0000

Vous avez développé une belle appli toute sympathique avec plein de jolis formulaires qui sont tellement bien faits, qu'ils vous rendent la vie moins sympathique lorsqu'il s'agit de tester "manuellement" votre application. ...

En effet, vous devez saisir, re-saisir et re-re-saisir très régulièrement toutes les informations du formulaire en 56 étapes pour accéder à la 57ème étape qui est, justement, celle que vous voulez tester manuellement. Vous avez donc perdu plusieurs (précieuses) secondes (voire minutes) à la fin de la journée, presque inutilement.

Comment faire pour ne plus perdre autant de temps ?

Nous pourrions très bien automatiser les tests IHM, mais c'est compliqué (ou pas ?) et c'est long à maintenir (pas toujours, ca dépend des cas)...
Nous pourrions accéder directement à la "page" qui nous intéressent, mais nous n'aurions pas les données de session... Voila la solution !

Les données de session justement, cela nous aiderait énormément si nous pouvions charger à la demande les données de sessions pour un scénario donné (par exemple, le scénario ou j'ai rempli les 2 premières pages de formulaires mais pas la 3ième, un autre ou j'ai tout rempli mes 7 onglets/pages de formulaire de dossier en ligne et je suis prêt à appuyer sur le bouton envoyer...)

Imaginons la démarche suivante :

je me loggue sur mon appli (je créé alors une session dans mon appli, et je récupère un cookie de session, dans la plupart des cas)
j'évolue dans mon application jusqu'à un point précis (3ème onglet rempli sur 5 par exemple)
je prend une "photo" de la session à cet instant, je la mets de côté de manière à la recharger à tout moment quand j'en ai besoin
je continue dans mon appli, j'évolue dans mes développements
je recharge un peu plus tard, quand j'en ai besoin, ma session préalablement sauvegardée, et hop !
j'accède directement (à la main) à l'url de la page qui m'intéresse avec cette session rechargée et je peux refaire mon test
je réutilise à volonté ma session sauvegardée et j'en sauvegarde d'autres sur différents écrans de mon application
...

L'idée vous intéresse ?

Les 60 lignes de code PHP suivantes, à mettre dans sessionswitcher.php, probablement aussi alors :

<?php

if (!array_key_exists('sessionswitcher',$_GET)) return;

list ($mode,$value) = explode(':',$_GET['sessionswitcher']);

$sessionpath = session_save_path();
if (strpos ($sessionpath, ";") !== FALSE)
  $sessionpath = substr ($sessionpath, strpos ($sessionpath, ";")+1);

switch ($mode) {
case 'show': 
	session_start();
	header('Content-Type: text/plain');
	print_r($_SESSION);
	exit;
case 'reset': 
	session_start();
	$_SESSION = array();
	if (isset($_COOKIE[session_name()]))
		setcookie(session_name(), '', time()-42000, '/');
	session_destroy();
	header('X-Session-Switcher-Result: destroyed');
	break;
case 'save': 
	session_start();
	$file = "$sessionpath/sessionswitcher-$value.session";
	$_SESSION['sessionswitcher']['name'] = $value;
	file_put_contents($file,session_encode());
	header('X-Session-Switcher-Result: saved');
	header("X-Session-Switcher-Session: ".$value);
	break;
case 'del': 
	$file = "$sessionpath/sessionswitcher-".urlencode($value).".session";
	if (!is_file($file)) break;
	unlink($file);
	header('X-Session-Switcher-Result: deleted');
	break;
case 'list': 
	if (!is_dir($sessionpath)) break;
	$dh = opendir($sessionpath);
	echo "<p>Choose a session in the list to switch on it:</p>
";
	echo "<table border=1>
";
	while (($file = readdir($dh))!==false) {
		if(!preg_match('/^sessionswitcher\-(.+)\.session$/',$file,$matches))
			continue;
		echo "<tr><td><a href='?sessionswitcher=use:{$matches[1]}'>{$matches[1]}</a></td></tr>
";
	}
	echo "</table>
";
	header('X-Session-Switcher-Result: listing');
	exit;
case 'use':
	$file = "$sessionpath/sessionswitcher-$value.session";
	if (!is_file($file)) break;
	session_decode(file_get_contents($file));
	header('X-Session-Switcher-Result: switched');
	header("X-Session-Switcher-Name: {$_SESSION['sessionswitch']['name']}");
	break;
default:
	header('X-Session-Switcher-Result: unknown');
}

Comment utiliser le SessionSwitcher ?

Ajoutez la ligne suivante dans votre fichier php.ini (en local sur votre poste de développement, ou bien sur le serveur de recette interne, pas en production !) :

auto_prepend_file = "<chemin-vers-le-fichier-contenant-le-code-ci-dessus>/sessionswitcher.php"

(vous pouvez aussi faire un 'require "sessionswitcher.php";' au tout début de vos fichiers/scripts php si la solution de l'auto_prepend ne vous convient pas et que vous avez ajouté le fichier sessionswitcher dans l'include_path PHP ou que vous indiquez le chemin absolu)

Rédémarrez votre serveur web (local ou de recette)
Accédez comme d'habitude à votre application via votre navigateur, connectez vous éventuellement si vous avez un formulaire de connexion/authentification
Naviguez dans votre application, notamment sur les pages/formulaires qui modifient votre session (i.e. qui stockent des données dans votre session)
Dès que vous atteignez une étape que vous souhaitez sauvegarder, ajoutez les paramètres suivant dans l'url :

?sessionswitcher=save:mon-etape

(vous pouvez mettre ce que vous voulez comme nom de sauvegarde à la place de 'mon-etape')

Notez l'url sur laquelle vous étiez (sans le ?sessionswitcher...)
A partir de maintenant, vous pourrez recharger à tout moment votre session telle qu'elle était, en ajoutant le paramètre suivant dans l'url :

?sessionswitcher=use:mon-etape

A tout moment vous pouvez voir le contenu de votre session en ajoutant le paramètre suivant dans l'url :

?sessionswitcher=show

A tout moment vous pouvez lister les différentes sauvegardes que vous avez faites en ajoutant le paramètre suivant dans l'url :

?sessionswitcher=list

Si vous utilisez certains plugins de navigateurs qui permettent de voir le contenu des entêtes HTTP renvoyées par le serveur, vous pourrez voir les entêtes suivantes :

X-SessionSwitcher-Result: xxxxx
...
X-SessionSwitcher-Name: yyyyy

Ce code est expérimental et assez condensé (le but étant de ne pas impacter trop les performances de votre application...), mais vos retours sur son utilisation sont les bienvenus !

1 application = plusieurs environnements

Olivier Hoareau — Wed, 29 Oct 2008 08:00:00 +0000

Lorsqu'on nous développons nos applications PHP, nous sommes très souvent confrontés à plusieurs environnements d'exécution :

local (développement)
tests (build continue, ...)
intégration
recette
pré-production
production
...

Lorsqu'on nous développons nos applications PHP, nous sommes très souvent confrontés à plusieurs environnements d'exécution :

local (développement)
tests (build continue, ...)
intégration
recette
pré-production
production
...

Bien souvent les paramétrages sont légèrement différents suivant les environnements notamment sur les points suivants :

type de base de données (ex: sqlite en développement, oracle en production)
serveur ou identifiants de connexion base de données (ex: root en développement, user restreint en production)
niveau de log et d'erreurs (ex: debug en développement, info en production)
système d'exploitation (ex: windows en développement, linux en production)
emplacements de fichiers et de l'application
...

Une chose est sûre, la logique de votre application doit, elle, être identique sur tous ces environnements (sauf cas particulier...).

Comment faire ?

Voici une méthode simple qui permet de gérer le multi-environnements :

externaliser tous les paramétrages dépendants de l'environnement dans un fichier de configuration (ex: run.ini)
lister tous les environnements dans ce fichier (ex: dev, tests, preprod, prod), le fichier contient donc toutes les "versions" de paramétrages sous forme de section
réaliser un code d'initialisation de l'application qui se base sur une variable d'environnement (ex: PHP_ENV) pour détecter l'environnement sur lequel tourne l'application
lire le fichier de configuration à l'initialisation et récupérer les paramétrages spécifiques à la section d'environnement courante (ex: prod)
injecter ces paramétrages dans l'application.

Proposition d'implémentation avec Zend Framework

Voici comment implémenter cela avec le Zend Framework :

Fichier config/run.ini

[prod]

database.adapter=pdo_mysql
database.params.host=dbserver
database.params.dbname=dbprod
database.params.username=dbprod
database.params.password=XXxxxxX

logger.level=info

[test]

database.adapter=pdo_sqlite
database.params.host=
database.params.dbname=:memory:
database.params.username=
database.params.password=

logger.level = debug

[dev]

database.adapter=pdo_mysql
database.params.host=localhost
database.params.dbname=dbdev
database.params.username=root
database.params.password=

logger.level = debug

Fichier html/index.php (ou bien votre bootstrap, ou bien votre fichier commun à tous vos contextes) :

// ...
env = $_SERVER['PHP_ENV'];
Zend_Registry::set('config', new Zend_Config_Ini(dirname(__FILE__).'/../config/run.ini', $env));
// ...

Votre application peut alors utiliser la variable de registre Zend_Registry('config') pour récupérer toutes les informations concernant l'environnement dans lequel elle évolue (dev, test ou prod) Il vous suffit maintenant de définir la variable système PHP_ENV au niveau des serveurs de test, de production et en local. Typiquement vous pouvez soit positionner une variable d'environnement au niveau système, soit créer une variable d'environnement au niveau serveur web, sous Apache il suffit de faire :

PassEnv PHP_ENV

ou bien pour définir la variable uniquement à l'intérieur du serveur web :

SetEnv PHP_ENV prod

Tests unitaires et Exception : attention aux try/catch !

Olivier Hoareau — Mon, 27 Oct 2008 09:00:00 +0000

Les tests unitaires, pour ceux qui les utilisent, sont bien pratiques pour tester notre code. Malheureusement ils peuvent introduire, si ils sont rédigés de façon maladroite des problèmes qui peuvent être compliqués à comprendre a posteriori. Imaginons le code suivant (volontairement) mal codé : ...

class UserService {
    /**
      * Checks user access rights
      *
      * @param User $user the user
      *
      * @return null
      * @throws Exception if access is denied for the specified user
      */
    public function checkAccess($user) {
        // ... (100 lignes)
        if($user->role==='standard') {
            throw new Exception("Access denied");
        }
        if($user->role==='basic-admin') {
            throw new Exception("Access denied");
        }
        if($user->role==='editor') {
            throw new Exception("Access denied");
        }
        // ... (100 lignes)
    }
}

Imaginons que nous n'avions pas écrit ce code nous même, et qu'il soit assez volumineux et complexe (plus de 300 lignes). Nous désirons rajouter des tests unitaires sur cette méthode, nous réalisons le premier test suivant :

class UserServiceTest extends PHPUnit_Framework_TestCase {
    public function testGetUserForIdNullThrowException() {
        $svc = new UserService();
        try {
            $svc->checkUser(null);
            $this->fail("No exception thrown");
        } catch(Exception $e) {
        }
    }
}

Nous exécutons le test pour voir le résultat et ... le test est vert (succès). Confiant dans notre code, nous pensons que ce cas ($user null) est traité. Grosse erreur (je vous le dis, cela n'est pas traité dans le code, mais le test est quand même vert) !

Nous sommes en effet devant un énorme effet de bord du au fonctionnement du framework PHPUnit...

En effet, lorsque nous appelons checkUser(null), le code de checkUser ne vérifie pas la nullité du paramètre $user, il fait les différents if($user->role === ...), (avec $user == null), mais comme vous le savez PHP est permissif et ne va donc pas planter, les if seronts juste faux et aucune exception ne sera levée par notre code applicatif. la ligne en gras suivante:

        try {
__            $svc->checkUser(null);__
            $this->fail("No exception thrown");
        } catch(Exception $e) {
        }

ne va donc pas lever d'exceptions (comme attendu), et la ligne suivante dans le tests unitaires va être exécutée :

        try {
            $svc->checkUser(null);
__            $this->fail("No exception thrown");__
        } catch(Exception $e) {
        }

Cette ligne (le fail), va en réalité lever une exception de type Exception (c'est le fonctionnement standard de PHPUnit). Or, comme nous avons fait un try/catch par dessus, cette exception va être attrapé et le bloc catch va être exécuté, comme il est vide, aucune assertion fausse ne sera déclenchée et la fin du test sera atteinte sans aucune erreur, le test sera donc : vert (succès) !

Le test sera donc en succès alors que notre code ne lève pas d'exception quand le $user est null !

Je vous l'accorde, il est recommandé de mettre des assertions dans toutes les branches d'un test, nous aurions pu alors écrire :

        try {
            $svc->checkUser(null);
            $this->fail("No exception thrown");
        } catch(Exception $e) {
            $this->assertTrue(true);
        }

Le problème aurait été le même et nous serions passé dans le catch, l'assertions triviale aurait été vraie et le test sera toujours vert !

Nous aurions pu voir apparaître le problème si nous avions fait une assertions légèrement différente dans le catch :

        try {
            $svc->checkUser(null);
            $this->fail("No exception thrown");
        } catch(Exception $e) {
            $this->assertEquals("Access denied",$e->getMessage());
        }

Le test aurait été rouge (cool !) mais le message d'échec aurait été le suivant :

Failed asserting that <string:No exception thrown> is equal to <string:Access denied>

Quézako ?

En fait, dans la branche catch(), $e contient l'exception levée par le fail() (car notre code ne lève pas d'exception dans ce cas puisqu'il est buggé) et PHPUnit tente donc de faire une assertion entre la chaîne "Access denied" écrite en dur dans le test, et le message de l'exception qui est en fait "No exception thrown" !

Une méthode plus sûre

Mais alors qu'elle est la bonne méthode pour écrire un test qui aurait mis en exergue le bug de notre méthode checkAccess() ?

Le problème réel vient du fait que nous réalisons un catch sur le même type d'exception que celui levé par le framework PHPUnit (Exception), il suffit juste de réaliser le catch sur un type d'exception plus spécialisé, par exemple NullPointerException (classe à créer) comme ceci :

        try {
            $svc->checkUser(null);
            $this->fail("No exception thrown");
        } catch(NullPointerException $e) {
            $this->assertEquals("Access denied",$e->getMessage());
        }

Lorsque nous exécuterions le test, il échouerait, et le message d'erreur serait :

No exception thrown

Gagné ! Nous aurions vu que notre code applicatif était buggé et qu'il ne traite pas le cas ou le user est nul. Cela impose cependant que l'exception levée par notre méthode checkAccess() dans le cas d'un user null soit par exemple du type NullPointerException (et non pas Exception).

Récemment, PHPUnit a ajouté le support des "annotations" dans le commentaire de la méthode de test pour indiquer que le test doit lever une exception, nous aurions pu utiliser le test suivant :

class UserServiceTest extends PHPUnit_Framework_TestCase {
    /**
      * @expectedException NullPointerException
      */
    public function testGetUserForIdNullThrowException() {
        $svc = new UserService();
        $svc->checkUser(null);
    }
}

il est bien plus concis !

Conclusion :

Spécialisez toujours vos exceptions dans votre code, n'utilisez jamais des exceptions de type Exception si vous voulez réaliser des tests unitaires.

1 application = de multiples contextes d'exécution

Olivier Hoareau — Thu, 23 Oct 2008 21:28:00 +0100

Votre application PHP (script, pages, sites, application complexe) est avant tout développée pour être exécutée dans un contexte unique :

soit par serveur web
soit en ligne de commande
soit sous forme d'application graphique

(dans la majeure partie des cas) ...

Votre application PHP (script, pages, sites, application complexe) est avant tout développée pour être exécutée dans un contexte unique :

soit par serveur web
soit en ligne de commande
soit sous forme d'application graphique

(dans la majeure partie des cas)

Votre application est souvent "optimisée" pour son contexte d'exécution principal et même très souvent ne peut fonctionner que dans ce contexte (est-il possible de faire tourner votre site internet en ligne de commande ? d'accéder à des fonctionnalités de votre application graphique depuis un serveur web ? ...)

C'est normal.

Imaginons que vous souhaitiez réaliser des tests sur votre application (par exemple unitaire avec PHPUnit), pourrez vous tester unitairement une fonctionnalité qui a besoin d'une connexion à une base de données ou de lire dans un fichier de config, depuis la ligne de commande (exécutable PHPUnit ou bien même batch Phing) ?

Ou encore, si vous développez une fonctionnalité "non graphiques", comme par exemple la gestion des utilisateurs, l'appel d'un webservices distant, le stockage d'information en base de données, l'envoi de sms ou de mail, ... il peut être intéressant de pouvoir réutiliser vos développements (ou en tout cas une partie) dans un script de migration ou de mise à jour en ligne de commande, même si initiallement le développement a été réalisé pour être exposé sur le web.

Pour répondre à ce besoin "multi-contextes", voici ma méthode.

Créer un répertoire "contexts/" à la racine de votre projet
Ajouter les différents contextes nécessaires à votre application :
- web.php => le fichier inclu par votre index.php ou votre page.php
- unit-tests.php => le fichier inclu systématiquement dans vos classes de tests unitaires
- functional-tests.php => le fichier inclu systémtatiquement dans vos fixtures greenpeper-php ou fitnesse-php
- ...
- @common.php => le fichier central inclu par tous les autres, il est censé contenir les functions communes et les inclusions de vos développements

Concrètement ces fichiers (à part @common.php) contiennent en règle générale quelques lignes seulement. Voici quelques exemples :

Exemple: web.php

$env = $_SERVER['PHP_ENV'];
/**
 * Includes the test application functions.
 */
require dirname(__FILE__) . '/@common.php';
/**
 * Setup controller
 */
$controller = Zend_Controller_Front::getInstance();
$controller->addModuleDirectory('../application/default');
$controller->addControllerDirectory('../application/default/controllers');
$controller->setControllerDirectory('../application/admin/controllers');
$controller->throwExceptions(false); // should be turned on in development time
/**
 * Bootstrap Layouts
 */
Zend_Layout::startMvc(array(
    'layoutPath' => '../application/default/layouts',
    'layout' => 'main'
    ));
/**
 * Runs
 */
$controller->dispatch();

Exemple: unit-tests.php

$env = 'tests';

require dirname(__FILE__) . '/@common.php';

$svc = new DatabaseService();

$dbFile = dirname(dirname(__FILE__)).'/tmp/db/test.sqlite';
if(is_file($dbFile)) {
    @unlink($dbFile);
}
$dsn = 'sqlite://'.$dbFile;
$svc->create($dsn,dirname(__FILE__) ."/../config/db/{$env}/schema.xml");
$svc->update($dsn,dirname(__FILE__) ."/../config/db/{$env}/all.xml");

Exemple: @common.php

require 'Zend/Loader.php';
require dirname(__FILE__) . '/../application/functions.php';

/**
 * Registers autoload
 */
Zend_Loader::registerAutoload();

/**
 * Sets the root directory of the application
 */
$root = dirname(dirname(__FILE__));

/**
 * Sets the global include path of the application
 */
set_include_path(// the list of include paths
    $root                                   . PATH_SEPARATOR .
    $root."/application/default/controllers". PATH_SEPARATOR .
    $root."/application/default/models"     . PATH_SEPARATOR .
    ...
    get_include_path());

/**
 * Loads the main configuration from the specific environment section of the
 * configuration file.
 */
if(!$env) {
     die('You must set $env variable.');
}
$cnf = new Zend_Config_Ini(dirname(__FILE__).'/../config/run.ini', $env);
Zend_Registry::set('_cnf', $cnf);

// ...

/**
 * Sets the database connection configuration
 */
if (@$cnf->database!==null) {
    Zend_Db_Table_Abstract::setDefaultAdapter(Zend_Db::factory($cnf->database));
}

Comment utiliser ces "contextes" ?

Exemple d'utilisation du contexte web dans un fichier html/index.php

<?php
require_once dirname(__FILE__).'/../contexts/web.php';

Exemple d'utilisation du contexte unit-tests dans une classe de tests PHPUnit dans tests/MyServiceTest.php

<?php
require_once dirname(__FILE__).'/../contexts/unit-tests.php';

// no requires anymore since we use autoloading

class CityServiceTest extends PHPUnit_Framework_TestCase {

    /**
      * @expectedException NullPointerException
      */
    public function testGetCityNameFromZipCodeForNullZipCodeThrowException() {
         $svc = new CityService();
         $svc->getCityNameFromZipCode(null);
    }

}

Exemple d'utilisation du contexte cli dans un script en ligne de commande scripts/migrate-data.php

<?php

require_once dirname(__FILE__).'/../contexts/cli.php';

// no requires anymore since we use autoloading

$svc = new MigrationService();

try {
    $result = $svc->migrateFromTo($from,$to);
} catch(Exception $e) {
    die("Error occured when data migration : ".$e->getMessage());
}

echo "Migration completed";

Le pattern Adapter : Quezako par l'exemple

Olivier Hoareau — Mon, 20 Oct 2008 21:15:00 +0100

Imaginons une classe qui est censé fournir une liste de villes et de départements qui seront utilisés dans une balise HTML select pour permettre à un internaute de sélectionner sa ville de naissance à partir d'une liste.

Nous commençons simplement par récupérer la liste des villes disponibles dans un fichier texte CSV ayant la structure suivante : ...

Nous commençons simplement par récupérer la liste des villes disponibles dans un fichier texte CSV ayant la structure suivante :


code_ville;nom_ville
PAR;Paris
NYK;New York
SVL;Seville
BXL;Bruxelles
...

Puis nous récupérons la liste des villes comme suit en PHP :

class VilleService {
    public function getVilles() {
        $handle = fopen("villes.csv", "r");
        while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) {
           $villes[$data[0]] = $data[1];
        }
        fclose($handle);
        return $villes;
    }
}

$service = new VilleService;
$villes = $service->getVilles();

// $villes contient la liste des villes comme suit :
// $villes = array('PAR'=>'Paris', 'NYK'=>'New York','SVL'=>'Seville','BXL'=>'Bruxelles');

Notre script est alors fonctionnel et nous pouvons utiliser la variable $villes pour construire notre balise HTML select (liste déroulante). Notre application évolue et nous voulons utiliser une base de données pour stocker la liste des villes, ce qui nous donneras plus de souplesse pour mettre à jour cette liste, par exemple depuis un formulaire. Nous devons alors recoder la récupération de la liste de villes depuis zéro depuis la base de données, notre script est impacté.

Imaginons que nous avions eu le code suivant :

$service = new VilleService;
$adapter = new CsvAdapter;
$adapter->setFile('villes.csv');
$service->setAdapter($adapter);
$villes = $service->getVilles();

La classe CsvAdapter correspond à une implémentation de la récupération des villes depuis un fichier CSV. Voici le contenu des classes :

class VilleService {
    protected $adapter;
    public function setAdapter(AdapterInterface $adapter) {
        $this->adapter = $adapter;
    }
    public function getVilles() {
        return $this->adapter->listRows();
    }
}

interface AdapterInterface {
    public function listRows();
}

class CsvAdapter implements AdapterInterface {
    public function listRows() {
        $handle = fopen("villes.csv", "r");
        while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) {
            $rows[$data[0]] = $data[1];
        }
        fclose($handle);
        return $rows;
    }
}

A quoi cela nous aurait-il servit ? Revenons à notre besoin d'évolution : nous voulions faire évoluer notre script pour récupérer les données en base de données et non plus à partir d'un fichier. En utilisant les concepts de service et d'adapter, nous pourrions créer un nouvel adapter, DatabaseAdapter, qui implémenterait l'interface AdapterInterface et fournirait donc la méthode listRows() comme suit :

class DatabaseAdapter implements AdapterInterface {
    protected $dsn;
    protected $user;
    protected $password;
    public function setConnectionParameters($dsn,$user,$password) {
        $this->dsn = $dsn;
        $this->user = $user;
        $this->password = $password;
    }
    public function listRows() {
        try {
            $dbh = new PDO($this->dsn, $this->user, $this->password);
            foreach($dbh->query('SELECT * from villes') as $row) {
                $rows[$row[0]] = $row[1];
            }
            $dbh = null;
        } catch (PDOException $e) {
            $rows = array();
        }
        return $rows;
    }
}

Nous pourrions ainsi utiliser notre nouvel adapter dans notre script comme suit :

$service = new VilleService;
$adapter = new DatabaseAdapter;
$adapter->setConnectionParameters('mysql:host=localhost;dbname=mydb','myuser','mypassword');
$service->setAdapter($adapter);
$villes = $service->getVilles();

Soit 2 lignes de changées dans notre script (c'est peu !).

Nous pourrions faire encore évoluer par la suite notre script pour récupérer la liste des villes depuis un webservice SOAP, simplement en ajoutant un adapter, par exemple SoapAdapter :

$service = new VilleService;
$adapter = new SoapAdapter;
$service->setAdapter($adapter);
$villes = $service->getVilles();

Notre classe SoapAdapter devrait implémenter AdapterInterface et notamment la méthode listRows() :

class SoapAdapter implements AdapterInterface {
    ...
    public function listRows() {

        $soapClient = new SoapClient(...);
        ...
        $villesList = $soapClient->getVilles();
        ...
        return $viles;
    }
}

Le pattern Adapter vous permet d'externaliser des opérations (récupération d'une liste de villes par exemple) dans une classe d'implémentation spécifique (récupération depuis un fichier csv, récupération depuis une base de données...) vous permettant ainsi de changer l'implémentation (passer d'un fichier à une base) sans impacter votre script (vous créez un nouvel adapter, le code d'appel reste le même).

Nous verrons plus tard (autre article) que le concept d'Adapter est souvent utilisé dans les tests unitaires en conjonction avec le pattern Mock (fausse implémentation) pour réaliser des tests sans déclencher certains opérations couteuses (par exemple tester la logique de construction d'un email sans envoyer réellement l'email).

Refactoring : ma démarche

Olivier Hoareau — Thu, 16 Oct 2008 00:20:00 +0100

Lorsque je dois étendre une fonctionnalité de mon application (existante au travers d'une méthode), voici ma démarche : ...

Lorsque je dois étendre une fonctionnalité de mon application (existante au travers d'une méthode), voici ma démarche :

Je commence par identifier dans la méthode existante les macro-blocs, c'est à dire les bloc de code "atomique" et autonome, en règle générale il y en a entre 3 et 6. Je commence par mettre une ligne de commentaire au dessus de chaque ligne de début de macro-bloc. Puis j'externalise chaque macro-bloc dans une méthode à part (par exemple une méthode protected, voire public si je fais des tests unitaires sur cette méthode uniquement) Je me retrouve donc avec un nouveau corps de méthode initiale qui fait quelques lignes (3 à 6). Je créé alors une nouvelle méthode censée répondre à mon évolution à côté de la méthode existante, en essayant de réutiliser au maximum les méthodes sous-jacentes que j'ai fait apparaître (les macro-blocs). Ma nouvelle fonctionnalité impose certainement la création d'un nouveau macro bloc que j'externalise dans une méthode à part.

Je me retrouve donc à avoir le schéma suivant :

Je constitue ainsi une architecture de code "zoomable" en partant des méthodes "haut niveau" qui ne contiennent que des appels vers les méthodes sous-jacentes bas niveau. Cela me permet aussi de réaliser des tests unitaires sur les méthodes bas niveau et de tester mon code plus facilement. Accessoirement mes méthodes font rarement plus de 80 lignes car elles sont découpées.

Une arborescence projet typique avec Zend Framework

Olivier Hoareau — Sat, 11 Oct 2008 13:54:00 +0100

Voici une proposition d'arborescence de projet zend framework typique...

Code HTML/JS simplifié (sans framework) pour faire de l'ajax

Olivier Hoareau — Fri, 10 Oct 2008 15:42:00 +0100

Pour des besoins internes, j'ai spiké un code html/js de quelques lignes pour faire des requêtes Ajax (POST/PUT/DELETE/GET/HEAD) en voyant par exemple du contenu xml (REST ;) )

Je l'ai mis en ligne, vous pouvez récupérer à tout moment le code source (code source html) à l'adresse : ...

Pour des besoins internes, j'ai spiké un code html/js de quelques lignes pour faire des requêtes Ajax (POST/PUT/DELETE/GET/HEAD) en voyant par exemple du contenu xml (REST ;) )

Je l'ai mis en ligne, vous pouvez récupérer à tout moment le code source (code source html) à l'adresse :

http://octo.warkodev.net/ajax/

C'est bâteau, mais ca arrive qu'on ait besoin d'un morceaux de code de ce type rapidement sous la main.

Hope this helps (même si ca remplace pas prototype, extjs et autres jquery ;) )

PS: testé et fonctionnel sur FF3, IE7, GChrome

Lille : Rencontre AFUP sur PHP 5.3 le 20/10

Olivier Hoareau — Thu, 09 Oct 2008 15:54:00 +0100

L'AFUP organise une rencontre pour présenter les nouveautés de PHP 5.3 le 20 octobre prochain à Lille (19h30 - 21h30)

Detail ci dessous : ...

L'AFUP organise une rencontre pour présenter les nouveautés de PHP 5.3 le 20 octobre prochain à Lille (19h30 - 21h30)

Detail ci dessous : http://www.afup.org/article.php3?id_article=366

Je ne pourrais malheureusement pas y être...

Scrinch : Outil de gestion de projet agile

Olivier Hoareau — Wed, 08 Oct 2008 15:46:00 +0100

Bonjour à tous amis Agilistes,

Que pensez-vous de cette outils pour gérer les projets Agile : ...

Bonjour à tous amis Agilistes,

Que pensez-vous de cet outil pour gérer les projets Agile :

http://social.hortis.ch/2008/09/25/16-octobre-08-mardi-gras-sur-scrinch-outil-de-gestion-de-projet-agile/

Ca ne remplace pas nos bons vieux post-it sur les murs mais cela peut-il avoir une pertinence à vos yeux pour le Product Owner et pour l'équipe.

A vos plumes

PHP, Oracle et Zend Framework

Olivier Hoareau — Fri, 03 Oct 2008 15:49:00 +0100

Après avoir potassé un peu la doc sur Oracle et les character set, voici un script et surtout la documentation d'explication de certaines choses à avoir à l'esprit quand on travaille avec Oracle, PHP et Zend Framework...

<?php

/**
 * Connecting to Oracle database
 *
 * @author Olivier Hoareau <olivier@phppro.fr>
 * @license New BSD License
 *
 * The NLS_LANG variable is used to specify the character set of the
 * client or server.
 *
 * The NLS_LANG must reflect the charset of the operating system.
 *
 * [Server]
 *
 * To check Oracle Database Server NLS values:
 *
 * NLS_LANGUAGE      => SELECT NLS_LANGUAGE      FROM NLS_DATABASE_PARAMETERS;
 * NLS_TERRITORY     => SELECT NLS_TERRITORY     FROM NLS_DATABASE_PARAMETERS;
 * NLS_CHARACTERSETS => SELECT NLS_CHARACTERSETS FROM NLS_DATABASE_PARAMETERS;
 *
 * The NLS_LANG value is <NLS_LANGUAGE>_<NLS_TERRITORY>.<NLS_CHARACTERSETS>
 *
 * Example: NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P15
 *
 *
 * [Session or Client]
 *
 * To check Oracle Database Client NLS values:
 *
 * NLS_LANGUAGE      => SELECT NLS_LANGUAGE      FROM NLS_SESSION_PARAMETERS;
 * NLS_TERRITORY     => SELECT NLS_TERRITORY     FROM NLS_SESSION_PARAMETERS;
 * NLS_CHARACTERSETS => SELECT NLS_CHARACTERSETS FROM NLS_SESSION_PARAMETERS;
 *
 * The NLS_LANG value is <NLS_LANGUAGE>_<NLS_TERRITORY>.<NLS_CHARACTERSETS>
 *
 * You can set the NLS_LANG variable on windows using the registry key:
 *  => for Oracle XE : HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_XE\NLS_LANG
 *
 * You can set the NLS_LANG variable on windows command line using:
 *  => set NLS_LANG=<value>
 *
 * You can set the NLS_LANG variable on *nix command line using:
 *  => export NLS_LANG=<value>
 *  => export LANG=en_US (or fr_FR, ...)
 *
 * Tips #1: Do not forget to use Apache's PassEnv directives on environment vars.
 * Tips #2: Check your php.ini default_charset directive value
 *
 * Example: NLS_LANG = FRENCH_FRANCE.WE8MSWIN1252
 *
 * You can modify the NLS_LANG variable for the current session using:
 *  => ALTER SESSION SET NLS_LANGUAGE='<value>';
 *  => ALTER SESSION SET NLS_TERRITORY='<value>';
 *
 * @see http://fadace.developpez.com/oracle/nls/
 * @see http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm
 * @see http://download.oracle.com/docs/cd/B25329_01/doc/install.102/b25143/toc.htm#BABHJAID
 */

require 'Zend/Loader.php';
Zend_Loader::registerAutoload();

$params = array(
    'dbname'   => 'XE',
    'username' => 'TESTUSER',
    'password' => 'TESTUSER',
    'host'     => 'localhost',
    'port'     => '1521',
    'options'  => array(
        Zend_Db::AUTO_QUOTE_IDENTIFIERS => false,
#       Zend_Db::CASE_FOLDING => 2,
#       autoQuoteIdentifiers => 0,
    ),
);


$sql = "SELECT * FROM MYTABLE";

$db = Zend_Db::factory('Pdo_Oci',$params);

$r = $db->query($sql);

print_r($r);

Forum PHP 2008 Paris

Olivier Hoareau — Wed, 24 Sep 2008 15:38:00 +0100

Les 8 et 9 décembre prochains se tiendra à Paris le Forum PHP 2008 de l'AFUP (Association Française des Utilisateurs de PHP).

Les sujets intéressants à retenir : ...

Les 8 et 9 décembre prochains se tiendra à Paris le Forum PHP 2008 de l'AFUP (Association Française des Utilisateurs de PHP).

Vous trouverez la liste des sessions à cette adresse : http://afup.org/pages/forumphp2008/sessions.php

Les sujets intéressants à retenir :

Retours d'expériences

retour d'expérience 20minutes.fr (volumétrie, déploiement)
retour d'expérience rue89.com (Drupal : gestion de contenus)
retour d'expérience BNP Paribas + Zend Technologies
retour d'expérience Mozilla (sites des add-ons réalisées avec CakePHP)
Retour d'expérience placedestendances.com (RIA Ajax)

Outillage et Bonnes Pratiques

Javascript Best Pratices (jQuery)
Best Pratices Performance Web (Yahoo)
Rapports de Qualité et Outillage (Phing, rats, PHP_CodeSniffer, PHP Depend, PHP Beautifier, spikePHPSecAudit, spikephpcoverage...)
IDE : Le cas d'Eclipse + PDT
Analyse statique et dynamique de code (~XDepend ?)
Design Patterns et PHP 5 (Injection de dépendances et Observateur)

Autres Tech

Oracle 11g DRCP (20000 SQL connections simultanées)
Solutions de Haute disponibilité avec MySQL (Cluster, Replication, Shared Disk Clustering)
séance Audit sécurité (boite noire et boite blanche)

Manager

Histoire et évolution de la Plateforme PHP en Entreprise
PHP, a mystery success story

Les sponsors

Zend Technologies Oracle Anaska / AlterWay Eyrolles Nexen Services Open States

Le prix

180€ / 2 jours / pers.

Le lieux

ASIEM 6, rue Albert de Lapparent 75007 Paris Tél. : 01 42 73 13 36 Metro : Ségur (ligne 10)

Malheureusement, je ne pourrais pas y assister, mais si certains sont intéressés et y vont, merci de me ternir au courant ;)

Zend PHP5 Certified Engineer

Olivier Hoareau — Fri, 29 Aug 2008 17:18:00 +0100

Ca y est, c'est fait !

PHPPro (en ma personne ;) ) est Zend PHP5 Certified Engineer depuis le Vendredi 29 aout 2008 à 12h00.

Prochaine étape, Zend Framework certified Engineer ? ;)