Pomme, poire & electro

Spéciale dédicace à tous ceux pour qui l'informatique est une souffrance...

Je vous fait par d'une action sympathique, à laquelle je participerai avec bonheur, qui m'a été transmise par email

Le 1er février 2007, dans toute la France :

Participez à la plus grande mobilisation des citoyens contre le Changement Climatique !

L'Alliance pour la Planète (groupement national d'association environnementales) lance un appel simple à tous les citoyens, 5 minutes de répit pour la planète : tout le monde éteint ses veilles et lumières le 1er février 2007 entre 19h55 et 20h00. Il ne s'agit pas d'économiser 5 minutes d'électricité uniquement ce jour-là, mais d'attirer l'attention des citoyens, des médias et des décideurs sur le gaspillage d'énergie et l'urgence de passer à l'action !

5 minutes de répit pour la planète : ça ne prend pas longtemps, ça ne coûte rien, et ça montrera aux candidats à la Présidentielle que le changement climatique est un sujet qui doit peser dans le débat politique.

Pourquoi le 1er février ? Ce jour là sortira, à Paris, le nouveau rapport du groupe d'experts climatiques des Nations Unies. Cet événement aura lieu en France : il ne faut pas laisser passer cette occasion de braquer les projecteurs sur l'urgence de la situation climatique mondiale.

Si nous y participons tous, cette action aura un réel poids médiatique et politique, moins de trois mois avant l'élection présidentielle!

Faites circuler au maximum cet appel autour de vous et dans tous vos réseaux ! Faites-le aussi apparaître sur votre site Internet et dans vos news letters.

Contact/ information : Cyrielle, Les Amis de la Terre : 01 48 51 18 95.

Le talent d'humoriste qui sommeille en moi me fait vous dire qu'il faudra bien penser à charger vos portables et GSM avant cet événement jovial et apocalyptique...

NPLB : Munissez-vous d'une bougie et d'une montre. Appuyez sur le gros bouton rouge dans le placard à droite en entrant. A 20h appuyez sur le bouton vert situé au-dessus du bouton rouge.

J'ai été confronté à un problème qui je crois n'est pas documenté dans la doc de DB_DataObject. En effet je me suis retrouvé avec une base de données MySQL dans laquelle les noms des champs étaient en camelCase. En faisant tourner DB_DataObject sur DB, celà ne pose aucun problème.

Il n'en est pas de même pour MDB2. En effet ce dernier pour des soucis de portabilité n'utilise que des champs en minuscule. Sans en modifier la configuration le remplissage de l'objet DB_DataObject ne se fait donc pas pour les champs contenant des majuscules. Heureusement DB_DataObject permet de modifier de façon globale la configuration de MDB2, grâce à la méthode PEAR::getStaticProperty, comme ceci :

// Configuration de DB_DataObject. Attention a bien recuperer une reference et pas une copie du tableau renvoye par 
// PEAR::getStaticProperty
 
$options = & PEAR :: getStaticProperty('DB_DataObject', 'options');
$options = array ('database' => 'mysql://'.$cfg['db']['user'].':'.$cfg['db']['password'].'@'.$cfg['db']['host'].'/'.$cfg['db']['db'], 
'generator_no_ini'=>true,
'schema_location' => APP_ROOT.'helpers/includes/DOclasses/', 
'class_location' => APP_ROOT.'helpers/includes/DOclasses/', 
'require_prefix' => 'DataObjects/', 
'class_prefix' => 'DataObjects_', 
'db_driver'=>'MDB2'
);
// Configuration de MDB2. Cette facon de configurer MDB2 est propre à DB_DataObject 
require_once ("MDB2.php");// Pour initialiser les constantes MDB2_PORTABILITY_*
$db_options = & PEAR::getStaticProperty('MDB2','options');
$db_options['portability']=MDB2_PORTABILITY_ALL ^ MDB2_PORTABILITY_FIX_CASE;// Tout sauf passage en minuscule pour
                                                                                        // les noms des champs

Voilà, si vous rencontrez d'autres problèmes vous pouvez jeter un oeil aux différentes constantes concernant la portabilité dans /repertoire/pear/MDB2.php

Voici une extension de DB_DataObject qui implémente l'interface Iterator.

Très pratique pour utiliser avec des moteurs de templates, qui possèdent quasiment tous leur "foreach".

<?php
 
class DB_DataObject_Iterator extends DB_DataObject implements Iterator {
    public function current() {
        return $this;
    }
    public function key() {
        global $_DB_DATAOBJECT;
        $result = &$_DB_DATAOBJECT['RESULTS'][$this->_DB_resultid];
        return $result->rowCount();
    }
    public function next() {
        $this->fetch();
    }
    public function rewind() {
        global $_DB_DATAOBJECT;
        $result = &$_DB_DATAOBJECT['RESULTS'][$this->_DB_resultid];
        if(!$result) return false;
        $result->seek();
        return $this->fetch();
    }
    public function valid() {
        global $_DB_DATAOBJECT;
        if (empty($_DB_DATAOBJECT['RESULTS'][$this->_DB_resultid]) || 
            !is_object($result = &$_DB_DATAOBJECT['RESULTS'][$this->_DB_resultid])) 
        {
            return false;
        }
        return true;
    }
}

Ne fonctionne qu'avec MDB2 (doit pouvoir être adapté à DB) et bien sûr nécessite PHP5, l'interface Iterator faisant partie des SPL.

Je hais Explorer, comme beaucoup de gens qui font le même métier que moi (encore que certains ont l'air de le défendre, ou de ne pas apprécier ce genre d'humour, enfin je ne sais pas trop), je perds beaucoup de temps à rendre les sites compatibles IE, du temps que je pourrais plutôt passer à améliorer mon travail (ou à aller ramasser des champignons, par exemple).

J'avais mis depuis quelques mois une protection par .htaccess empêchant IE d'afficher ce blog, je viens de changer de formule, histoire d'institutionnaliser la chose, j'ai opté pour la méthode 3 d'Explorer Destroyer.

J'espère juste ne pas être visité par des paranos qui désactivent le javascript sur leur IE....

MAJ : et voilà, ça me fout en pétard ! ce matin je regarde mes stats et qu'est-ce que je vois ?

Pourquoi les spammeurs utilisent systématiquement une identité IE ? Mon avis personnel, c'est que ce sont des machines infectées, qui se font commander l'IE pour aller polluer la toile. Si pour les commentaires, il y a Spamplemousse qui marche très bien, que faire pour ne pas se faire polluer les statistiques ? que de bande passante gaspillée. En outre je ne comprends toujours pas pourquoi je ne reçois que des commentaires critiquant mon comportement vis-à-vis de ce navigateur qui pour moi est une réelle problématique, aussi bien pour ses utilisateurs, abusés (sans le savoir), que pour les créatifs qui doivent se plier à ses règles et gommer ses tares.

Peut-être simplement parce que ce système qui génère tant de travail débile et de maintenance inutile est générateur d'emplois et de croissance ?

EDIT : pour le spamming par referer, voici un .htaccess qui va bien contre la co**erie humaine.

Vous avez monté une application web que vous utilisez régulièrement, et vous souhaitez rechercher un moyen de l'optimiser, ou vous avez besoin d'un outil de profiling dans le cadre de votre développement PHP ? Vous êtes sur mac osX, vous utilisez MAMP (1.3.1). Moi aussi !!

Je me suis donc décidé à voir ce que donne xdebug qui semble être l'outil incontournable pour accomplir cette tâche. J'ai rencontré quelques obstacles pour arriver à mes fins, qui justifient je pense l'écriture de ce billet.

Installer xdebug

Il n'existe pas de version précompilée de Xdebug pour mac, qui plus est la compilation dépend de la version du moteur Zend utilisé dans votre environnement. Donc, une compilation est nécessaire. Le problème avec MAMP, c'est que les librairies C en sont absentes, ce qui rend toute compilation de module PHP impossible.

Il faut donc, dans un premier temps, récupérer une distribution de php avec le même moteur Zend que la version de MAMP incluant les librairies (à savoir 20050922). Tout ça uniquement pour compiler le module...

Le package d'entropy étant passé en php 5.2, je me suis rabattu sur une autre solution (plus simple, voir note de bas de page)

Pour ce faire j'ai opté pour le package php de Marc Liyanage (ceux qui sont sur osX depuis le début doivent connaitre car il a été le premier à proposer des packages d'installation apache/php/mysql pour osX, qui soient à la portée d'un développeur web de base comme moi).

Le package php 5.1.6 se trouve ici. Récupérez-le, installez-le (c'est un .pkg). Toute l'installation est placée dans le dossier /usr/local/php5/. La version PHP de MAMP est 5.1.4, mais le moteur Zend est le même,c'est ce qui compte.

Cette fois on a les librairies C (dans le dossier include).

Allons nous placer dans une fenêtre terminal.

A savoir, le module php de marc liyanage a effectué une installation des binaires en root/wheel. Alors ceux de MAMP vous appartiennent. Il va donc falloir compiler le module en tant que root.

Pour ce faire, et comme je suis un partisan du moindre effort (il faut déjà en faire assez) nous allons utiliser le gestionnaire de packages PECL (celui du package PHP de Marc Liyanage, pas celui de MAMP !). comme ceci :

macbookpro:~/ moi$ sudo /usr/local/php5/bin/pecl install xdebug

après quelques dizaines de secondes, le téléchargement des source et la compilation sont effectués. le nouveau module a été copié dans /usr/local/php5/lib/php/extensions/no-debug-non-zts-20050922 . Il va falloir, d'une part basculer les droits pour coller avec ceux de MAMP, puis déplacer le module dans le dossier des extensions Zend de MAMP :

sudo chown moi /usr/local/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so
sudo chgrp admin /usr/local/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so
cp /usr/local/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so /Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so

Ne reste plus qu'à ajouter une ligne à notre php.ini :

echo zend_extension=/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so >> /Applications/MAMP/conf/php5/php.ini

Et redémarrer les serveurs depuis l'interface MAMP. Il ne vous reste plus qu'à vérifier que le module est bien chargé, en allant consulter le phpinfo(); (si vous lisez cet article, vous savez faire, non ?...)

Premières utilisations

On peut déjà utiliser Xdebug directement dans notre code PHP. Le module xdebug.so ajoute quelques fonctions PHP (consultez la liste complète dans la documentation de xdebug). Premier exemple de base, remplacer le gestionnaire d'erreurs de PHP par celui de Xdebug :

<?php
xdebug_enable();
fonction_a_la_con_qu_existe_pas();
?>

Allez voir ce que ça donne :

Wowo que c 'est bô !!! L'intérêt semble limité pour un simple appel de fonction, mais la pile de traçage devient vite très intéressante lorsque l'on se retrouve à gérer des erreurs dans une imbrication multiple d'objets.

Je vous invite, à partir de ce point, à explorer les différentes fonctions xdebug, dans la doc correspondant (voir lien plus haut). Attention la version 1.3 et la version 2 (celle qu'on a installé) fonctionnent tout à fait différemment.

En tout cas, le top avec xdebug, c'est d'utiliser une interface graphique pour profiler son application. Comme souvent sur mac, on est à la traine et il faut jouer des coudes pour trouver ce dont on a besoin. Heureusement que cet OS est le plus agréable du monde, ça fait oublier ces petits désagréments ;). Heureusement il y a Fink grâce auquel nous allons pouvoir installer Kcachegrind....

Installation de Kcachegrind

bas débit s'abstenir !

Pour installer Kcachegrind sur mac osX, il faut également récupérer un paquet de paquets liés à l'environnement graphique KDE. La solution la plus simple pour ne pas s'empêtrer dans les dépendances, est de laisser faire Fink. Il saura installer tout ce dont on aura besoin pour faire tourner la bête. Mais avant d'installer Fink, assure-vous d'avoir installé :

• Les Developer Tools (Fink a besoin de gcc entre autres)
• X11 (KDE tourne sur un moteur de ce type)

Ensuite, récupérez l'installeur de fink ici. L'installation se fait classiquement par un .pkg. L'installeur crée un répertoire sw en racine de votre disque système, tout ce que fink installera, ce sera dans ce dossier. Si vous êtes habitué à apt-get, pear, pecl ou dselect, sachez que fink est un gestionnaire de packages au fonctionnement similaire à ceux-ci, mais il est spécialisé dans le port d'application unix sur mac. Dans le même genre il existe Darwinports. Je n'ai pas testé, mais je pense que si les packages KDE sont dispo sur darwinports on doit arriver au même résultat.

Passons au rapatriement de kacachegrind et toute la cohorte de packages (140 pour moi) nécessaires à son bon fonctionnement. Je n'ai pas compté mais on doit pas être loin du gigaoctet, donc faites chauffer les modems ! D'abord, il faut configurer, et tant qu'à faire, mettre à jour Fink. Kcachegrind n'étant disponible qu'en statut beta, il faut indiquer dans la config que l'on souhaite pouvoir utiliser des packages en beta.

Retour dans le terminal :

vi /sw/etc/fink.conf

Et effectuez la modification suivante :

# Avant
Trees: local/main stable/main stable/crypto
# Après
Trees: local/main stable/main stable/crypto unstable/crypto unstable/main

voilà maintenant mise à jour de Fink et réindexation des packages :

fink selfupdate; fink index; fink scanpackages

Allez boire un café.... ... ... voilà, la journée doit être pas loin de se terminer pour lancer ce qui suit, téléchargement et compilation qui vont prendre... du temps :

sudo fink install kcachegrind

Répondez tout de même aux quelques questions (laissez les valeurs par défaut par exemple, ça suffit) pour que l'opération démarre. .... .... Le lendemain matin... Je vous souhaite de tout coeur qu'aucune erreur n'apparaisse dans votre terminal, en principe tout a bien du se passer, kcachegrind est prêt à être lancé. Il se trouve dans /sw/bin/kcachegrind.

Pour qu'il fonctionne correctement, il doit être lancé depuis X11, par le terminal. Vous pouvez ajouter le chemin de l'exécutable au menu Applications, c'est fait pour ça.

Vous devez obtenir quelque chose comme ça :

Vous savez quoi : on y est presque ! Ne reste plus qu'à configurer xdebug (on retourne dans le php.ini s'il vous plait)

xdebug.profiler_enable="1"
xdebug.profiler_output_dir="/Applications/MAMP/tmp/xdebug/"

Les valeur "xdebug.trace_output_dir" et "xdebug.profiler_output_dir" sont modifiables par l'emplacement où vous souhaiter enregistrer les fichiers de profiling.

Relancez le serveur apache

Lancez une page web PHP de votre serveur local, un fichier de profiling est créé à l'endroit que vous souhaitez. Il ne vous reste plus qu'à ouvrir ce fichier (extension .out) dans kcachegrind. Excellent ! Ci-dessous un profil d'un des sites que j'ai monté. Le retour visuel est immédiat et sans appel : mon système d'internationalisation, utilisant PEAR::XML_Serializer, a sérieusement besoin d'un système de cache :

Amusez-vous bien, n'hésitez pas à émettre remarques ou suggestions sur ce billet.

Voici la liste des articles écrits ça et là, qui m'ont aidé à monter cet environnement.

• http://xdebug.org/
• http://www.entropy.ch
• http://www.mamp.info
• http://classes.scriptsphp.org/article.Xdebug
• http://www.onlamp.com/pub/a/php/2002/02/28/profilingphp.html
• http://developpeur.journaldunet.com/tutoriel/php/060608-php-profiling-xdebug.shtml
• Stray notes : Running Kcachegrind on Mac OSX 10.4

EDIT : si vous êtes sur php 5.2 un brave ch'ti gars de chez Komodo propose les binaires pour Linux/macosX/Win32 par ici :

PHP 5.2 / xdebug builds

EDIT2 : souhaitant installer PHPunit 3, qui demande xDebug version 2, je me suis retrouvé coincé (après un changement de machine) car le package d'entropy est passé en php 5.2, et toujours pas MAMP (ben ouais j'ai pas upgradé). Donc là, le seul moeyn reste l'extension compilée de komodo. Elle est récupérable directement dans l'application elle-même.

Pour ceux qui utilisent DB_DataObject_FormBuilder, il faut bien avouer que ça peut devenir vite une charnière inévitable dans tout projet où il y a du formulaire et de la bdd. Il peut présenter cependant quelques défauts, notamment en ce qui concerne l'affichage de select avec des références étrangères. Chez Symfony et Propel, et chez d'autres Frameworsk certainement, que je ne connais pas, il est possible d'implémenter le fonction __toString(), qui depuis php5 (me semble-t-il) est la méthode appelée par défaut lorsque l'on tente de faire un echo d'un objet. C'est beaucoup plus souple que le $fb_linkDisplayFields qui sépare simplement les champs souhaités par une virgule. On se retrouvé vite limité.

ça peut paraitre c*n, mais j'ai mis un moment à me demander par quel bout prendre formBuilder pour l'étendre. Finalement, j'ai franchi le cap. En fait beaucoup de choses dans la prog objet, (me) semblent inaccessibles d'un premier abord parce que la solution est tellement simple qu'on passe à côté. Donc voilà, ce que ça donne :

require_once 'DB/DataObject/FormBuilder.php';
 
class myFB extends DB_DataObject_FormBuilder
{
  
  function DB_DataObject_FormBuilder(&$do, $options = false)
  {
    DB_DataObject_FormBuilder::DB_DataObject_FormBuilder(&$do, $options = false);
  }
  
  function &create(&$do, $options = false, $driver = 'QuickForm', $mainClass = 'myFB')
  {
 
    $fb = DB_DataObject_FormBuilder::create($do,$options,$driver,$mainClass);
 
    if(PEAR::isError($fb)) {
      die ($fb->getMessage());
    }
    return $fb;
  }
  
  function getDataObjectString(&$do, $displayFields = false, $linkDisplayLevel = null, $level = 1) {
    if($this->isCallableAndExists(array($do,'__toString'))) {
      return $do->__toString();
    } else {
      return parent::getDataObjectString($do, $displayFields, $linkDisplayLevel, $level);
    }
  }
}

Voilà, il suffisait juste de surcharger la méthode create, pour ensuite avoir un Formbuilder extensible à souhait. Ici simplement j'ajoute la possibilite d'invoquer __toString() sur l'objet lié, si la fonction est implémentée.

Evidemment lorsque l'on crée un nouveau formulaire il faut utiliser MyFB::create($dataobj); au lieu de DB_DataObject_FormBuilder::create($dataobj);

J'ai passé un été mouvementé, surtout au niveau des doigts, qui n'ont pas arrêté de courir sur le clavier. Au fur et à mesure des projets que j'attaque, je garde la même trame, toujours à base de briques PEAR pour la plupart et certaines classes commencent à murir.

Celle dont je voudrais vous parler, c'est une extension de DB_DataObject, celle que j'utilise sur tous les projets. Cette classe a commencé à prendre du poids au fur et à mesure que je lui ajoutais des fonctionnalités (upload et redimensionnement de photos, internationalisation, gestion de propriétaire ...). Donc j'ai voulu faire quelque chose qui puisse ne charger que ce dont a besoin l'objet au moment où il est fabriqué.

En fin de compte, j'arrive à une structure de 'plugins' pour mes objets d'accès aux données, et ma foi, ça permet de capitaliser le code de façon assez intéressante. Le résultat obtenu fait vaguement penser au pattern decorator. Voici le principe:

• La classe (Mdo) étend DB_DataObject, et les objets générés étendent cette classe Mdo.

<?php
class Mdo extends DB_DataObject
{
}

Dans cette classe, on crée quelques méthodes pour gérer le chargement des plugins. Voici un extrait :

      /**
       * Charge les plugins. Cette methode est appelee a la premiere invocation de _executePlugins
       * @access protected
       **/ 
	function _loadPlugins() {
		$pluginInfos=$this->getInstalledPlugins();
		foreach($pluginInfos as $aPluginInfos) {
			if(isset($this->$aPluginInfos['var'])){
				$this->_loadPlugin($aPluginInfos);
			}
		}
		$this->_pluginsLoaded = true;
	}
	/**
       * Cree une instance d'un plugin, associe a l'objet courant
	 * @access protected
	 **/
	protected function _loadPlugin($infos) {
		require_once PLUGIN_DIR.$infos['include_file'];
		$plugin = & new $infos['class_name'];
            // init va se charger de vérifier que les infos prodiguées sont correctes pour le fonctionnement du plugin
            if(!$plugin->init($this)) {
                 throw new Exception('Les paramètres envoyés au plugin ne sont pas valides');
            }
  		$this->_plugins[$infos['name']] = & $plugin;
      	Log::info('Chargement du plugin '.$infos['class_name'].' depuis '.get_class($this));
	}
	
	/**
       * Renvoie un tableau avec la liste des plugins installes
       * TODO : recuperer ces informations a partir d'un fichier separe (XML ou ini)
       * Et creer une methode qui permette d'installer des plugins supplementaires
	 * @access public
       * @return array
	 **/
	public function getInstalledPlugins() {
		if(count($this->_pluginInfos)>0) {
			return $this->_pluginInfos;
		} else {
			return array(
                                                  array(  'name'=>'images',
  									'include_file'=>'Images.php',
  									'class_name'=>'DOPlugin_Images',
  									'var'=>'photoFields'
  									),
									
									
  					                      array(  'name'=>'ownership',
  									'include_file'=>'Ownership.php',
  									'class_name'=>'DOPlugin_Ownership',
  									'var'=>'ownershipFields'
  									),
									);
		}
		return array();
	}
 
	/**
       * Execute un callback sur tous les plugins. 
       * Typiquement ce sont les methodes du meme nom que celles de DB_DataObject qui sont appelees
	 * @access private
	 **/
	private function _executePlugins($callback,$params=null) {
      	if(!$this->_pluginsLoaded) {
      	    $this->_loadPlugins();
      	}	
		if(is_array($params)) {
			$params[]=&$this;
		} else {
			$params=array(&$this);
		}
				
		foreach($this->_plugins as $plugin) {
				call_user_func_array(array($plugin,$callback),$params);
		}
	}
	/**
       * Renvoie une reference à un plugin active dans l'objet en cours
	 * @access public
       *
	 **/
	function &getPlugin($pname) {
	  if(!key_exists($pname,$this->_plugins)) {
	    throw new Exception('le plugin '.$pname.' est absent de '.get_class($this));
	  } else {
	    return $this->_plugins[$pname];
	  }    
	}

Des intéressés pour la suite ?

Grâce à l'arrivée des nouveaux Mac Pro, Apple renoue enfin avec ce qui l'avait quitté il y a si longtemps, à l'époque des 2fx : on peut avoir des configurations de follie avec le prix associé. Une petit extrait :

PS : à noter, encore plus pfff, la proposition d'échelonnement. vive ajax !