Aller au contenu | Aller au menu | Aller à la recherche
Lors d'un exercice en Licence Professionnelle Informatique Web Développeur à l'INSSET de Saint-Quentin, mes élèves ont constaté un comportement étrange avec le destructeur d'une classe. Voici un exemple minimal du problème :
<?php
class Exemple
{
public function __destruct()
{
file_put_contents('log.txt', 'Test');
}
}
$exemple = new Exemple();
Ce code ne pose a priori pas de problème et pourtant si vous l'exécutez avec Apache sur Unix vous risquez d'avoir des problèmes de droit d'écriture :
Warning: file_put_contents(log.txt) [function.file-put-contents]: failed to open stream: Permission denied in /var/www/test/destruct.php on line 6
En fait l'explication est aussi étonnante que simple et comme souvent on la trouve dans la documentation de PHP : lors de la phase de clôture d'un script, le contexte peut changer sur certains SAPI dont Apache.
Cela veux dire que notre instance étant détruite implicitement lors de la clôture du script, PHP ne va pas essayer de créer le fichier, dont le chemin est relatif, dans le même répertoire que le script mais dans un autre répertoire où il n'a pas forcément le droit d'écrire.
Pour contourner ce problème, il suffit soit de donner au fichier un chemin absolu pour le fichier, soit de détruire explicitement l'instance afin que cela se fasse avant la phase de clôture du script :
$exemple = null
ou
unset($exemple);
Le numéro de décembre du magazine Programmez ! contient un dossier spécial PHP avec des articles par mes collègues Christophe Villeneuve et Damien Seguy ainsi qu'un article par votre serviteur sur l'industrialisation des développements PHP.

Comme chaque fin de semaine, voici la revue de presse hebdomadaire pour vous faire découvrir ce qui se dit d'intéressant sur PHP. Il s’agit d’articles en français ou en anglais que j’aimerais partager avec vous.
Et cette semaine, vous ne trouverez pas un mais deux articles bonus qui n'ont pas directement de rapport avec PHP mais qui me semblent importants.
Et voici les articles bonus de la semaine :
Comme chaque semaine, voici la revue de presse hebdomadaire pour vous faire découvrir ce qui se dit d'intéressant sur PHP. Il s’agit d’articles en français ou en anglais que j’aimerais partager avec vous.
Et parce qu'il n'y a pas que PHP au monde, vous trouverez également un article important mais dans un domaine libre et n'ayant pas forcément de rapport avec PHP.
Et voici l'article bonus de la semaine :
Josianne et Robert sont dans un projet
Le blog d'Octo nous narre l'histoire de Josianne et Robert qui travaillent sur le même projet. Josianne est une analyste expérimentée et connaît bien la boutique. Robert connait bien l’environnement technique. Nous allons voir comment certaines méthodes de gestion même avec les bonnes personnes peuvent mener à des conflits et des échecs.
... et ça ne se passe visiblement pas très bien. Après les problèmes avec Zend Server et Zend Studio, voilà maintenant que c'est PHP et par ricochet PEAR qui ont des problèmes avec la dernière version d'Ubuntu.
Le problème vient de la librarie zlib. Certaines de ses fonctionnalités ne sont plus disponibles dans PHP ce qui provoque l'échec silencieux du package PEAR Archive_Tar, empêchant toute installation de package PEAR.
Heureusement, il existe un contournement. Il suffit d'ajouter l'argument "-Z" afin de demander l'installation de packages non compressés :
pear install -Z phpdocumentor
Après une longue pause estivale (et un peu plus), voici le retour de la revue de presse hebdomadaire.
Le but est de vous faire découvrir ce qui se dit d'intéressant sur PHP. Il s’agit d’articles en français ou en anglais que j’aimerais partager avec vous. Et parce qu'il n'y a pas que PHP au monde, vous trouverez également un article important mais dans un domaine libre et n'ayant pas forcément de rapport avec PHP.
Et voici l'article bonus de la semaine :
Fake Rocks, Salami Commanders, and Just Enough to Start
On a probablement tous vécu un jour le syndrome de la feuille blanche. Cette peur de se lancer qui nous pousse souvent à choisir la facilité et à remettre au lendemain.
Lutter contre la procrastination, puisque c'est le nom de ce comportement, n'est pas facile et il n'y a pas de remède miracle. Cependant, un peu de méthode et beaucoup de courage peuvent en venir à bout.
Décidément la nouvelle mouture d'Ubuntu pose des problèmes aux produits Zend. Après Zend Server qui refuse de s'installer, voici que certains boutons sont inopérants dans la dernière version de Zend Studio.
Il existe là encore un contournement en attendant la correction du bug de GTK à l'origine du problème. Pour cela, il suffit de créer un script contenant les lignes suivantes et de l'utiliser pour lancer Zend Studio :
#!/bin/bash export GDK_NATIVE_WINDOWS=1 <CHEMIN>/ZendStudio
Remplacez <CHEMIN> par le chemin vers votre exécutable Zend Studio et le tour est joué.
Karmic, la nouvelle version d'Ubuntu est sortie comme prévu jeudi dernier. En essayant d'installer Zend Server dessus, j'ai eu la désagréable surprise de constater qu'un paquet nécessaire, "libkrb53", n'est plus disponible sur celle-ci.
Voici le genre de message d'erreur que l'on obtient :
The following packages have unmet dependencies: php-imap-zend-ce: Depends: libkrb53 (>= 1.4.2) but it is not installable E: Broken packages
En fait, ce paquet a été séparé en plusieurs nouveaux paquets : libkrb5-3, libgssapi-krb5-2, libk5crypto3 et libkrb5support0. En attendant qu'Ubuntu ou Zend corrige ce problème, il est possible de le contourner en créant soit-même un paquet transitionnel faisant office d'alias pour ces nouveaux paquets.
Package: libkrb53 Version: 1.6.dfsg.2+fake1 Depends: libkrb5-3, libgssapi-krb5-2, libk5crypto3, libkrb5support0
Il ne vous reste plus qu'à relancer l'installation de Zend Server.

Le programme du Forum PHP 2009 a été annoncé il y a quelques mais sans les horaires. Cet oubli est à présent réparé. L'agenda du forum est disponible sur le site de l'AFUP.
J'y serai et vous, y serez vous ?
Après quelques jours d'efforts pour tout boucler, Alter Way vient de publier le premier livre blanc sur l'industrialisation des développements PHP. Ce livre blanc a été écrit par Damien Seguy, figure du monde PHP, et moi-même.
En près de 15 ans, PHP a conquis la plupart des entreprises. Au début utilisé pour des projets annexes, il est aujourd'hui au cœur du SI. Les projets se complexifient, les délais se raccourcissent : il est temps d'industrialiser les processus de développement.
Ce Livre Blanc dresse un état de l'art des outils et méthodes qui permettent aujourd'hui d'industrialiser ses développements PHP.

Voici le sommaire complet :
Pour le télécharger, il suffit de vous rendre sur le site Alter Way.
Enfin ce livre blanc est diffusé sous licence OpenContent. Nous vous encourageons donc à le diffuser le plus possible pour porter la bonne parole dans tout le monde PHP voire au delà !
L'édition 2009 du Forum PHP se tiendra les 12 et 13 novembre à la Cité des sciences de la Villette, à Paris.
Le programme vient d'être dévoilé et il fait la part belle au duo PHP / MySQL. Cet évènement sera d'ailleurs organisé en collaboration avec Le MUG, l’association francophone des utilisateurs de MySQL.
Voici quelques conférences qui ont particulièrement retenu mon attention :
Olivier Hoareau évoque dans son dernier billet la gestion du code mort. C'est un sujet très intéressant car il montre que dans un domaine technique comme le développement, certaines notions très humaines et donc irrationnelles ont parfois une grande importance.
Il y a effectivement un attachement quasi affectif du développeur à son code. Une fois le code écrit on cherche souvent à toute force à lui trouver une utilité.
Comme Olivier, je pense qu'il faut savoir "jeter" son code s'il n'est plus pertinent. J'utilise des guillemets car un code conçu reste souvent en mémoire même s'il n'est finalement pas utilisé. Par ailleurs, si le code est suffisamment bon, bien qu'inadapté à la situation, on prendra soin de le stocker quelque part en vue d'une autre utilisation.
Pour résumer, je pense qu'il ne faut pas confondre dépôt et galerie de code. Le premier est dédié à une application précise tandis que le second est un recueil de morceaux de code dont on pense qu'ils seront probablement utiles plus tard mais sans en connaître l'usage que l'on en fera.
Je teste Zend Server depuis quelques semaines. Mes premières impressions sont plutôt bonnes mais il y a une chose qui me dérange. Il est possible d'installer phpMyAdmin afin d'administrer des bases de données MySQL mais l'accès à cet outil ne peut se faire que depuis la machine locale. Cela pose donc problème si on utilise Zend Server sur autre chose qu'un poste de développement.
Heureusement, il est très facile de désactiver cet excès de zèle. Pour cela, il suffit d'éditer le fichier /usr/local/zend/gui/lighttpd/etc/lighttpd.conf et de commenter les lignes suivantes :
$HTTP"remoteip" !~ "127.0.0.1" { $HTTP"url" =~ "^/phpmyadmin/" { url.access-deny = ( "" ) server.errorfile-prefix = "//usr/local/zend/gui/lighttpd/share/lighttpd-custom-errors/errorcode-" } }
Il faut ensuite redémarrer Lighttpd afin que la modification soit prise en compte :
# zendctl.sh stop-lighttpd # zendctl.sh start-lighttpd
Et voilà, le tour est joué.
Afin d'améliorer les méthodes de développement dans la société pour laquelle je travaille, j'ai mis en place un hook Subversion de type "pre-commit" pour vérifier que la syntaxe PHP des fichiers que l'on souhaite commiter est correcte. Je ne parle pas là de respect de standards de codage, juste du respect de la syntaxe PHP. Cela peut paraître inutile mais je retrouve régulièrement des fichiers avec des erreurs de syntaxes.
L'idée est simplement de récupérer la liste des fichiers impactés par le commit en cours et pour chacun d'en vérifier la syntaxe à l'aide de PHP en ligne de commande. J'ai cependant été confronté à une subtilité dont je voudrais vous faire part.
Voici le code complet du hook en question :
#!/usr/bin/php
<?php
$repositoryPath = $_SERVER['argv'][1];
$transaction = $_SERVER['argv'][2];
$stderr = fopen('php://stderr', 'w');
(..)
// autres vérifications
(...)
// Checks PHP files for syntax errors
$command = "/usr/bin/svnlook changed -t $transaction $repositoryPath";
exec($command, $lines);
$errorsFound = false;
$syntaxErrors = '';
foreach ($lines as $line) {
$file = trim(substr($line, 4));
if ('.php' == substr($line, -4)) {
// KLUDGE: PHP returns found syntax errors through stderr so "2>&1" must be added to redirect stderr to stdout
$command = "/usr/bin/svnlook cat -t '$transaction' '$repositoryPath' '$file' | /usr/bin/php -l 2>&1";
exec($command, $output, $returnValue);
if (0 != $returnValue) {
$errorsFound = true;
$syntaxErrors .= 'Fichier: ' . $file . PHP_EOL;
array_pop($output);
foreach ($output as $line) {
$position = strpos($line, ':');
$line = substr($line, $position + 1);
$syntaxErrors .= ' - ' . trim($line) . PHP_EOL;
}
$syntaxErrors .= PHP_EOL . str_repeat('-', 80) . PHP_EOL;
}
}
if ($errorsFound) {
fputs($stderr, str_repeat('-', 80) . PHP_EOL);
fputs($stderr, 'Des erreurs de syntaxe PHP on ete detectes :' . PHP_EOL . PHP_EOL);
fputs($stderr, $syntaxErrors);
fclose($stderr);
exit(1);
}
fclose($stderr);
exit(0);
La ligne qui nous intéresse principalement est la suivante :
$command = "/usr/bin/svnlook cat -t '$transaction' '$repositoryPath' '$file' | /usr/bin/php -l 2>&1";
La première partie, à gauche du pipe, demande à Subversion d'afficher le contenu du fichier $file du dépôt situé à $repositoryPath et cela pour la transaction $transaction. On parle ici de transaction et non de révision parce que nous sommes avant le commit. Enfin, la partie après le pipe reçoit le contenu du fichier renvoyé par Subversion et l'analyse syntaxiquement.
Je souhaitais afficher des informations sur les erreurs éventuellement rencontrées afin que le développeur sache exactement pourquoi son commit a été rejeté. Le problème est que PHP m'affichait bien les détails quand je capturais la sortie écran avec de l'output buffering mais je ne les avais pas dans la variable sensée contenir la sortie écran.
La raison est en fait toute bête mais on peut y passer un peu de temps avant de trouver si on n'a pas l'habitude du shell. Nous allons donc faire un petit rappel sur le sujet.
Sur Unix, il existe des flux standards. Ce sont des canaux pour l'entrée et la sortie de données. Ces flux sont au nombre de trois, au travers desquels les programmes peuvent faire entrer ou sortir des informations. Ceux qui nous intéressent en l'occurrence sont "stdout" et "stderr". Le premier correspond à la sortie classique tandis que le second correspond aux messages d'erreur.
Revenons maintenant à PHP. La fonction exec() permet de récupérer la sortie dans une variable. Le problème c'est que c'est le flux "stdout" qui est renvoyé et non l'ensemble de l'affichage. Les messages envoyés à "stderr" n'y figurent donc pas, ce qui explique le problème que je rencontrais.
Heureusement, il est possible de rediriger les messages du flux "stderr" vers "stdout" en ajoutant "2>&1" après la commande. Dès lors, la fonction exec() renvoie bien ce que j'attends et je peux afficher les messages d'erreur au développeur.
Comme chaque semaine, voici la revue de presse hebdomadaire pour vous faire découvrir ce qui se dit d'intéressant sur PHP. Il s’agit d’articles en français ou en anglais que j’aimerais partager avec vous.
Et parce qu'il n'y a pas que PHP au monde, vous trouverez également un article important mais dans un domaine libre et n'ayant pas forcément de rapport avec PHP.
Cette semaine, pour faire honneur à la sortie récente de la version 5.3 de PHP, 3 articles traitent de ce sujet.
Et voici l'article bonus de la semaine :
Le mythe des 24Mb/s
Les publicité des fournisseurs d'accès à internet font la course aux débits les plus fous. Eric Daspet démontre ici que les débits réels moyens sont bien loin des chiffres avancés. Il est important de garder cela en tête pour optimiser les performances de nos applications web.
La version 5.3 de PHP vient de sortir. Il s'agit d'une évolution majeure de la branche 5 de PHP. J'utilise sciemment le terme "majeur" pour une sortie dite mineure car la liste des modifications et améliorations est très importante comme l'a longuement et très bien expliqué Pascal Martin dans une série de billets.
Parmi toutes ces nouveautés, j'ai particulièrement apprécié les améliorations de la SPL et notamment les nouvelles classes comme splStack, splQueue, splPriorityQueue et splHeap.
La présentation suivante montre des exemples d'utilisation de ces nouvelles classes ainsi que des comparatifs de performances par rapport aux structures classiques de PHP.
PS: Saurez-vous trouver le gérant de No Parking caché dans cette présentation ? 
La première édition des PHP Days se déroulera lundi et mardi prochain. Ce cycle de formation a pour thème "Industrialisez votre PHP !" et vous permettront d'acquérir les compétences nécessaires à une utilisation professionnelle de PHP.
Au programmes 4 formations dispensées par les meilleurs experts PHP français :
Jour 1 - matinée : Environnement et procédures de développement
La première matinée permettra a tous les participants de mettre en place un environnement de travail complet, cohérent et optimisé (IDE, débogueur, normes, procédures, ...).
Animé par moi-même
Jour 1 - après midi : Utilisation d'un framework
Une fois votre environnement de travail mis en place direction les frameworks au travers d'une découverte pratique du Zend Framework. En une heure pour chaque nous mettrons en place une petite application de façon tutorée.
Animé par Julien PAULI
Jour 2 - matin : Sécurité de vos développements
Une application PHP sera lancée dans l'arène, et ce sera a vous de l'analyser et de tenter toutes les manœuvres retorses que vous connaissez pour en prendre le contrôle. L'atelier passera en revue a la fois les techniques d'attaques externes (boite noire, scanners, fuzzing), et interne (audit de code) pour illustrer les risques et exploitations de différentes vulnérabilités.
Animé par Damien SEGUY
Jour 2 - après midi : Optimisez vos performances
Cette conférence permettra de trouver des réponses a l'optimisation de PHP: éaluer un site existant, mettre en place une architecture scalable et optimale, optimiser les performances (configuration logicielle, cache, compilation, bases de données).
Animé par Cyril PIERRE de GEYER et Julien PAULI
Cela fait plusieurs fois que faute de temps, je décale la publication de ma revue de presse PHP du vendredi après-midi au lundi matin.
Que pensez-vous de ces périodes de publications ? Quand pensez-vous qu'il serait le plus pratique pour vous, et donc judicieux pour moi, de publier cette revue de presse ?
Comme chaque fin de semaine ou presque (cela devient une habitude
), voici la revue de presse hebdomadaire pour vous faire découvrir ce qui se dit d'intéressant sur PHP. Il s’agit d’articles en français ou en anglais que j’aimerais partager avec vous.
Et parce qu'il n'y a pas que PHP au monde, vous trouverez également un article important mais dans un domaine libre et n'ayant pas forcément de rapport avec PHP.
Et voici l'article bonus de la semaine :
Becoming a Better Programmer: Fighting Your Natural Instincts
Les développeurs ont souvent du mal à dévoiler leur code. Il est difficile d'accepter de soumettre son code et donc son expertise aux commentaire d'autres développeurs. C'est cependant le gage d'un code de qualité car il y a plus d'idées dans plusieurs cerveaux que dans un seul.
Comme chaque fin de semaine ou presque, voici la revue de presse hebdomadaire pour vous faire découvrir ce qui se dit d'intéressant sur PHP. Il s’agit d’articles en français ou en anglais que j’aimerais partager avec vous.
Et parce qu'il n'y a pas que PHP au monde, vous trouverez également un article important mais dans un domaine libre et n'ayant pas forcément de rapport avec PHP.
Et voici l'article bonus de la semaine :
XP sans Scrum, Scrum sans XP
Une courte analyse comparative de Scrum et XP, les deux méthodes agiles les plus en vue. L'auteur y décrit leur différences et leurs complémentarités.
© 2003-2010 Jean-Marc Fontaine - Tous droits réservés
XHTML - CSS - DotClear - Technorati
Les billets de ce blog sont sous licence Creative Commons