Première étape de mon passage en revue des classes de PEAR. Les Package PEAR pour l'Authentification

Stables

• Auth : Création d'un système d'authentification. PHP License
• Auth_HTTP Authentification http PHP License nécessite Auth_HTTP
• Auth_PrefManager Classe de gestion de "préférences" PHP License
• Auth_RADIUS Classes Wrapper pour le packege PECL RADIUS BSD
• Auth_SASL Abstraction d'une série de mécanisme de réponse SASL BSD

Beta

• LiveUser Boite à outil de gestion de comptes utilisateur et permissions LGPL
• LiveUser_Admin Boite à outil pour l'administration des comptes gérés par LiveUser LGPL

Alpha

• Auth_PrefManager2 Nouvelle version en préparation de la classe de gestion de "préférences" PHP License

---

Un peu plus sur le sujet

Auth

• Explication : http://www.hotandspicy.fr/2007/01/26/authentification-avec-pearauth/
• http://circle.ch/blog/p566.html
• exemple : http://www.circle.ch/projects/2/8
• Un article : http://www.webreference.com/programming/php/php5-advanced2/3.html
• Utilisation par claroline : http://doc.claroline.net/fr/index.php/Authentification_externe

LiveUser

• Toute l'info : http://wiki.pooteeweet.org/LiveUser/Complete

Smashing Magazine publie une liste de 50 tools utiles pour le développement PHP.

On y trouve des grands classiques, mais avec 50 il y en a peut-être que vous ne connaissez pas encore.

C'est "50 Extremely Useful PHP Tools"

Dans le même style

• 50 Extremely Useful And Powerful CSS Tools
• 15 Helpful In-Browser Web-Development Tools

Personnellement

J'utilise

• SimpleTest
• phpDocumentor
• GeSHi - Generic Syntax Highlighter
• phpLangEditor <- Yeeeeeeeeahhh c'est de Sébastien Piraux, développeur de claroline
• Zend Framework
• phpMyAdmin
• Smarty
• PHPEclipse
• Zend Studio
• Aptana PHP
• PhpED
• PDT

Première astuce à propos des Refactoring en "transistion".

Le renommage des fonctions et variables est une tâche courante de refactoring.

Voici une technique douce quand on ne peut être sur de renommer partout d'un coup. (Il arrive qu'un search and replace puisse causer des "dégâts", qu'il faille vérifier au cas par cas.

Je l'ai fortement utilisée pour la transformation qui effectuaient un affichage et que je voulais transformer en return.

Typiquement

<?php 
 
/**
 *
 * affiche la chaine  à propos de foo
 *
 * @return true;
 */
 
function print_foo()
{
 
   echo 'foo';
   return true; //<- souvent manquant ceci dit
}
 
// devient 
 
/** 
 * construit la chaîne  à propos de foo
 * 
 * @return string chaîne  à propos de foo
 *
 */
function getHtml_foo()
{
   $html = 'foo';
   return $html; 
}
?>

Le problème rencontré c'est tout ces print_foo() qui trainent dans le code.

Généralement je laisse les deux fonctions, très proches dans le fichier.

La nouvelle fonction fait le boulot, l'ancienne demande à la nouvelle de sous-traiter et logue avec un trigger_error le fait qu'on l'utilise encore.

J'ai ai mis un peu trop dans le trigger, je vous conseille les 4 premiers morceaux

[php]
<?php 

/**
 *
 * Affiche la chaine construite à propos de foo
 *
 * Cette fonction n'est plus à utiliser.
 * utilisez un echo  print_foo();
 * L'utilisation de cette fonction est reprise dans les logs .
 *
 * @deprecated
 * @see  print_foo()
 *
 * @return true;
 */
function print_foo()
{

   $db = debug_backtrace();
   trigger_error(
     'print_foo()! is use '
    . ' funct : ' . $db[1]['function'] . '()'
    . ' file : ' . $db[1]['file'] 
    . ' line : ' . $db[1]['line'] 
 #  . 'PHP_SELF : '.$_SERVER['PHP_SELF']
 #  . date('Y-m-d H:i:s') . "\n"
 #  . $_SERVER['SERVER_ADDR'] . "\n"
 #  . $_SERVER['REQUEST_URI'] . "\n"
   , E_USER_WARNING);

   echo getHtml_foo();
   return true; 
}
?>

Ensuite tous les matins un petit grep sur le log

grep print_foo | cut pour retirer les dates | sort -u

retourne la liste du boulot pour la journée vous en attaquez 3 par jour et ça va avancer tout seul.

Si vous travaillez avec une communauté open source, il n'est pas bête de publier cette liste, et de récolter les patches.

Un autre cas d'utilisation : un fichier qui ne devrait plus être utilisé.

Vous pouvez le retirer simplement de votre serveur et subir les foudres s'il est encore appelé quelque part et que son absence provoque un fatal error ou alors lui mettre un espion.

[php]
<?php 

mail( 'christophe@gesche.org'
    , 'ce foutu fichier reste appelé ici !!!!!'
    , 'PHP_SELF : '.$_SERVER['PHP_SELF']
    . "\n"
    . date('Y-m-d H:i:s') . "\n"
    . $_SERVER['SERVER_ADDR'] . "\n"
    . $_SERVER['REQUEST_URI'] . "\n"
    . var_export(debug_backtrace(),1)
    . "\n"
    
    );
    
    trigger_error( 'ce foutu fichier reste appelé ici !!!!!'.$_SERVER['SERVER_ADDR'] .' ' .date('Y-m-d H:i:s'),E_USER_WARNING);
?>

Comme je le disait ici, j'avais envie d'écrire à propos d'astuces sur des pratiques qui permettent la transition.

Il y a des transitions de longues durées et d'autre de courtes durées

Longue durée

Une transition de longue durée est une amélioration qui ne peut être faite en un coup. Partout où j'ai travaillé, que ce soit chez delcampe, sur claroline, sur arena51 sur kidcity, the World Scout Shop ... c'est toujours la même raison. Il y a des résidus d'erreurs du passé, pour lesquelles, un jour, il a été prouvé/trouvé une meilleurs façon de faire mais il est inconcevable de s'y atteler en exclusivité et d'arrêter tout le reste le temps d'appliquer cette nouvelle façon de faire.

Généralement ça concerne les performances, la sécurité, les normes d'écriture du code ... Bref au niveau fonctionnel. Des éléments qui changent peu de manière "visible", du coup on diffère. Ou pire, on s'en fait deuil en disant "On ne peut pas se permettre de consacrer tant de temps à cela, ça fonctionne sans".

Dans ce cas, la transition permet de créer les conditions pour faire selon la nouvelle méthode. On se fixe alors une règle du style : dès qu'on touche à un script, on applique la nouvelle façon de faire. Le vieux code lui reste comme il est, on ne va pas risquer de casser quelque chose qui fonctionne et auquel on a pas besoin de toucher.

Courte durée

J'utilise cela parfois pour pouvoir faire des mises à jour sans interruption de service. C'est à dire ordonnancer les remplacements de fichiers pour que à chaque instant le code soit cohérent.

Par exemple, je met à jour une classe et un code qui l'utilise.

1. -> ajout de la classe dans un fichier ou un nom temporaire
2. -> remplacement du fichier qui l'exploite pour qu'il utilise la classe temporaire
3. -> modification de l'ancienne classe ou de l'ancien fichier
4. -> remplacement du fichier qui exploite la nouvelle classe mais dans son nom officiel

Note pour des applications distribuées c'est moins évident. On doit plutôt voir ça en "upgrade" automatique. On a une transition de courte durée ... "qui reste longtemps" sur le serveur. On fait une mise à jour (release) préparatrice et puis une seconde finalisant la transition.

Durée moyenne ?

On va plutôt dire qu'il y a des inconvénients dans les transition à longue durée qu'il faut éviter et que ca implique donc que la durée ne soit pas trop longue:

1. ° si ça touche à la sécurité... Même si le problème existe depuis le "début", on va quand même essayer d'y mettre un coup de fouet.
2. ° si ça touche aux performance ou au règles de codage, il faut tenter de mesurer combien on gagne à le faire, combien on y perd à laisser ca comme ça.
3. ° éviter le chevauchement des transitions. Si on lance une transition il faut être sûr de son coup et viser une fin de transition avant la probable suivante. Les transitions augmentent le taux de "mélange de pratique" pour un nouveau collaborateur ça crée d'autant plus de méthode de travail à découvrir. Donc on perd du temps et de l'efficacité.

Vous en pensez quoi ?

Mise en garde

Il y a surement aussi des erreurs ou de mauvais choix dans ma façon de faire. C'est aussi pour cela que j'en parle sur ce blog, pour en discuter et les améliorer.

Je parle pas des remarques d'éventuels intégristes ou de jeunes sortis de l'école qui pense que dans l'informatique on passe son temp à créer du neuf.

Beaucoup trop de tuto ou articles que je lis dans la presse (Programmez, PHPSolution, ...) ou sur le net, présentent le "comment bien faire" en partant de zéro.

Trop peux parlent de "comment transformer". Il y a énormément d'existant qui est là et qui ne peut être simplement mis à la poubelle parce que on a trouvé une meilleures méthode.

Je voulais commencer à écrire dans ce sens des réflexions sur ce qui porte à la pratique de la transition et voilà que Sébastien Piraux, partage un article sur son compte fb.

Passer son code en UTF 8

C'est sur kitpages et ca explique Comment basculer un code PHP en UTF-8

Voici son intro

Si vous souhaitez coder un outil ou un site qui fonctionne avec des caractères ésotériques (Chinois, Arabe, Indien,...), vous devez changer la façon de coder vos caractères et de les transmettre sur le réseau. Cette façon de coder les caractères s'appelle le Charset. Le plus courant par nos latitudes est le charset ISO-8859-1. Il contient les caractères européens.

Pour écrire des textes en chinois, arabe, hébreux, indien, japonais... vous devez utiliser un charset qui permettent de coder tous les caractères de ces langues. Le charset le plus standard pour coder tout ça est UTF-8.

En attendant que je commence à m'y mettre, si vous avez d'autre ressources du style n'hésitez pas à me les faire connaitre.

Ressources signalées :

• Script de conversion pour COPIX

Voici un probablement inutile mais génial Moteur de stockage MySQL ... en PHP par Johannes Schlüter

Je ne me casse pas la tête à le traduire. c'est très facile à comprendre.

Johannes Schlüter sur les Connecteurs MySQL et est étudiant à l'Université des Sciences Appliquées de Munich . Il est release manager de PHP 5.3.