PHPPRO

"\r" : 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é.\n";
    } catch(Exception $e) {
        echo "Erreur de traitement du fichier '*file' : ".$e->getMessage()."\n";
    }
}

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']."\n";

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 "\r                                                                           \r";
    echo 'Fichiers analysés: '.($counters['success']+$counters['error'])
    echo ', traités: '.$counters['success'].', rejetés: '.$counters['error']."\n";
}

A chaque fichier traité, la ligne de résumé sera "mise à jour" grâce au retour chariot (\r) 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."\n";
    }
    $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" ?>'."\n";
?>

<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 . "\n" . $this->codePostal . " " . strtoupper($this->ville) . "\n" . 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 . "\n" . $this->codePostalLogement . " " . strtoupper($this->villeLogement) . "\n" . 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>\n"
    );
}

$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 !