Graeme Johnson est développeur confirmé chez IBM et travaille sur les machines virtuelles et les EDI. Il connaît particulièrement bien VisualAge (pour Smalltalk et pour Java), ainsi que J9 Virtual Machine, pour avoir participé aux projets.

Julian Dolby est chercheur pour IBM, il est specialisé dans les techniques avancées d'analyse de programmes en vue d'améliorer leur qualité.

L'idée de cette session était principalement d'étudier le fonctionnement de PHP en le comparant avec d'autres langages (notamment le C). Cela permet de détecter d'éventuels problèmes et surtout de proposer des améliorations.

En tant que développeurs utilisant PHP, nous sommes concernés simplement par l'aspect "avertissement" de cette session. Les détails, je le crains, ne nous concernent pas.

Cette session s'organisait en deux parties : "Analyzable PHP" puis "PHP runtime".

Ici, les points clefs sont la sécurité et les performances.

Côté sécurité, PHP lui-même n'est pas vraiment en cause puisque tout dépend de comment le développeur utilise les données d'entrée.

Côté performances, Julian Dolby a beaucoup fait la comparaison avec le langage C, dans lequel de nombreuses choses sont faites au moment du pre processeur, donc avant la compilation et à plus forte raison avant l'exécution ; en comparaison, PHP a de nombreux aspects dynamiques : phpver(), inclusions dynamiques, etc. Selon lui, cela peut être un problème car, en réalité, la version de PHP du serveur n'est pas dynamique : appeler une fonction pour déterminer cette valeur est une perte futile. De mon point de vue, cela simplifie grandement le procédé d'installation.

Cependant, il est certain que les packages d'installation de solutions comme phpBB pourraient définir une constante à l'aide de la fonction phpver() (plutôt que l'utiliser systématiquement). Ainsi, le numéro de version de PHP serait hardcoded dans la configuration, ce qui poserait moins de problème, tout en étant dynamique dans le sens où phpBB s'installerait correctement sur tous les serveurs. Globalement, tout ce qui n'est pas variable dans une page devrait être défini en tant que constante et tout ce qui ne change pas d'une exécution à l'autre devrait se trouver en tant que constantes (ne faisant pas appel à des fonctions) dans un fichier de configuration. PHP permet de le faire : je ne crois pas qu'il soit justifié d'avoir des macros comme dans le langage C.

Les includes dynamiques (dénoncés par Julian) sont, à mon humble avis, bien trop pratiques pour être évincées. Julian propose un troisième couple : include_static() et require_static()... L'idée a son mérite mais je ne sais pas si cela serait très utile. Certaines choses doivent rester à la charge du développeur afin de ne pas trop compliquer le code, tout de même.

Le réel problème semble être dans les références. En effet, PHP permet de gérer toute variable comme appartenant à un scope global (au moyen du tableau $GLOBALS ou bien du mot clef global), ce qui pose évidemment un souci de constance : après avoir appelé une fonction, nous n'avons aucune assurance de ce que nos variables locales n'ont pas été modifiées. Il nous faut vivre avec cette crainte et coder en conséquence...

Pour conclure, les applications PHP ont énormément de chemin à faire pour être toutes bien écrites, ainsi que le prouvent des solutions comme Chorizo! Actuellment, elles utilisent trop le dynamisme offert par le langage PHP pour permettre une analyse fiable.

Cette analyse de PHP n'en est qu'à ses débuts. IBM poursuit sa quête...

Dans certaines situations (compatibilité avec PHP 4), PHP ne peut pas savoir exactement ce que l'on attend de lui au niveau de l'affectation de mémoire.

Il est probable que PHP évolue vers une machine virtuelle (comme Java ou .NET) afin de proposer une compatibilité accrue.

L'une des tâches effectuées a été de recompiler PHP sans utiliser les headers de Zend. Pour cela, une approche "trial and error" a été adoptée : essayer de compiler, corriger les erreurs, essayer à nouveau, etc. Le résultat est un PHP avec un moteur "pluggable", c'est-à-dire que l'on peut brancher sur d'autres moteurs que le Zend Engine. L'intérêt est notamment de s'affranchir d'un moteur prédéfini, ce qui devrait donner davantage de flexibilité.

L'étape suivante est de reprendre le code source des extensions afin d'aller dans le même sens (avoir un moteur interchangeable). Le souci est que les extensions utilisent beaucoup le fonctionnement interne du Zend Engine.

Si j'ai bien suivi, car cela me semble extraordinaire, IBM a développé une branche de PHP utilisant une machine virtuelle et des extensions qui se sont affranchies des particularités du Zend Engine. Les avantages sont nombreux, notamment la possibilité d'utiliser les binaires d'un OS à l'autre ou encore de remplacer des fonctions lors de l'exécution (une seule extension le permet à ma connaissance, or elle ne fonctionne pas correctement d'après mes essais).

Julian et Graeme continuent à explorer ce domaine et encouragent toutes les personnes intéressées à les contacter, à partager leurs résultats, à informer leur entourage, etc. N'hésitez pas à les contacter pour davantage d'informations (les adresses sont à la fin du PDF).

Ben Ramsey est ingénieur pour Art & Logic et co fondateur du PHP Security Consortium (ai-je déjà parlé ici de Chris Shiflett ?).

La sécurité est un point crucial dans les développements sur internet. Il existe très peu d'applications sécurisées, il n'y en a pour ainsi dire aucune. PHP a évolué au cours des versions, notamment en désactivant les variables autoglobales en PHP 4.

Ben Ramsey s'est penché sur les méthodes les plus intéressantes du marché : ext/filter (intégré à PHP) et Zend_Filter (du framework Zend).

J'utiliserai la technique proposée par Chris Shiflett permettant d'identifier les variables selon leur utilisation : le tableau $clean contient les variables filtrées.

Tout d'abord, ce n'est plus une extension PECL depuis PHP 5.2, dont la sortie officielleChangelog de PHP 5.2 eut lieu le 2 novembre dernier. C'est maintenant intégré par défaut à PHP.

Malgré tout, Filter est encore expérimental : ses fonctions ne sont pas totalement stables. En particulier, les fonctions apparaissant dans la documentation officielle ne semblent pas correspondre avec les fonctions réelles.

<?php

if(!empty($_POST))
{
    $clean = array();
    $clean['login'] = filter_input(INPUT_POST, 'login', FILTER_SANITIZE_STRING);
    $clean['password'] = filter_input(INPUT_POST, 'password', FILTER_SANITIZE_STRING);

    echo 'Pseudonyme : '.$clean['login'].'<br/>';
    echo 'Mot de passe : '.$clean['password'].'<br/><br/>';
}

?>

<form method="post">
Pseudonyme : <input type="text" name="login" /><br />
Mot de passe: <input type="text" name="password" /><br />
<input type="submit" value="Connect" />
</form>

Pour commencer, Zend_InputFilter a changé de nom pour Zend_Filter_Input depuis la version 0.1.4 du framework (le 29 juin dernier). Le framework version 0.2.0 est disponible depuis le 31 octobre dernier.

<?php

set_include_path('./ZendFramework-0.2.0/library/');

include 'Zend.php';

Zend::loadClass('Zend_Filter_Input');

if(!empty($_POST))
{
    $clean = array();
    $filterPost = new Zend_Filter_Input($_POST);

    $clean['login'] = $filterPost->getAlnum('login');
    $clean['password'] = $filterPost->getAlnum('password');

    echo 'Pseudonyme : '.$clean['login'].'<br/>';
    echo 'Mot de passe : '.$clean['password'].'<br/><br/>';
}

?>

<form method="post">
Pseudonyme : <input type="text" name="login" /><br />
Mot de passe: <input type="text" name="password" /><br />
<input type="submit" value="Connect" />
</form>

Les deux filtres ont des approches résolument différentes. Comme le souligne Ben dans sa présentation, ext/filter est un "opt-in", c'est-à-dire que le développeur choisit de l'utiliser ; en revanche, Zend_Filter est un "opt-out" qui contraint le développeur à utiliser des méthodes pour accéder aux propriétés de la classe.

Je suis partisan de l'approche de Zend_Filter_Input mais je suppose qu'ext/filter peut être utilisé en "opt-out" si on l'implémente correctement.

Ce serait bien que les classes de Zend_Filter utilisent les fonctions d'ext/filter, cela permettrait d'avoir une méthode homogène et puissante de filtrer les données. Pour le moment, Ben a rencontré des problèmes avec les deux méthodes, ce qui suggère un manque de maturité. Filter est assez imbuvable à utiliser mais il n'est pas impossible de l'encapsuler dans une classe.

Tim Bray a un CV bien trop volumineux pour être décrit ici convenablement. Je me contenterai de rappeler qu'il a lancé l'un des premiers moteurs de recherche en 1995 et qu'il a co inventé XML 1.0. Aujourd'hui, il est (entre autres activités) directeur des technologies Web chez Sun Microsystems.

Soit Tim Bray est un artiste de la flatterie, soit Sun fera davantage pour la communauté PHP à l'avenir. J'ai quand même du mal à croire à la seconde option...

Toujours est-il qu'il est revenu sur un ancien comportement de Sun : "Java is the answer... What was your question?". Tim Bray ironisait à ce sujet, comme l'illustre la photographie comparative Java/PHP/Rails ci-dessus.

Tim Bray semblait considérer PHP et Java comme des frameworks de développement Web, au même titre que Ruby on Rails.

PHP 5 a des problèmes de performances. À la ZendCon 2006, tout le monde parlait de performances ; en revanche, à la conférence Ruby de la semaine précédente, personne ne semblait s'en préoccuper.

Les systèmes d'exploitation ont des temps d'accès très réduits à leurs fichiers. Lorsque c'est possible, il est bon d'utiliser des fichiers plutôt que des bases de données. Les ordinateurs ont fini de gagner en rapidité d'exécution des instructions, il faut donc recommencer à s'en préoccuper.

Il faut mesurer la rapidité, pas la deviner.

• Pas de compilation manuelle ;
• Pas de déploiement ;
• Taille du code ;
• Processus de configuration (Rails est en avance là-dessus).

• L'élément principal est l'EDI ;
• Capacité d'utiliser des gabarits (Java a plus de 75 langages de gabarits) ;
• Capacité à lier les objets et la base de données (object relational mapping, comme en Rails avec ActiveRecord) ;
• Documentation (davantage à voir avec l'aspect "culture" que technologie pure) ;
• Performances.

• L'architecture MVC (ce n'est plus expérimental) ;
• Le modèle orienté objet ;
• Le nombre de langages (réutilisation des langages) ;
• La taille du code (plus il est petit, mieux c'est) ;
• La lisibilité (gros point positif pour Java, tandis que Perl est à la traîne) ;

• Il y a un problème d'identité sur Internet : chaque site demande de créer une nouvelle identité (login+password), mais il y a tout de même des tentatives pour y remédier (OpenID, Liberty Alliance, Passport.NET) ;
• La majorité des gens ne travaille pas uniquement avec PHP ;
• SOA (cf. la session sur SCA) ;
• Web : pas d'APIs, seulement des messages => la solution : REST (Google Calendar) ;
• WS* (WS star, cf. image ci-dessus) : une tentative d'interfacer tous les frameworks (.NET, PHP, etc.) ;
• Web 2.0 : Tim Bray a perdu patience mais il y a de bonnes idées : flickr, YouTube, del.licio.us, LiveJournal.

Tim Bray a visiblement une très bonne vision d'ensemble du Web.

D'après lui, PHP est largement dans la course. Chose étrange, il a parlé de Microsoft mais pas de .NET. Selon lui, les trois seules technologies intéressantes semblent être Java, PHP et Ruby on Rails, avec probablement une préférence pour le dernier.

Pour ma part, et comme l'a remarqué quelqu'un à la fin de la session, je pense qu'il méconnaît les outils à disposition des développeurs PHP : il y a d'excellents EDIs pour PHP, certains ayant assurément de meilleures idées que ce qui est disponible pour Java. Je pense par exemple à l'aide constamment disponible avec PHPEditTest d'EDI : PHPEdit. Par ailleurs, un plugin PHP est disponible pour Eclipse (=> PHP EclipseTest d'EDI : PHP Eclipse), l'environnement phare pour le développement en Java.

Steph Fox est principalement active sur divers sites de php.net et zend.com, ainsi que pour le projet PHP-GTK.

Cette session eut lieu pendant la pause de midi, puisqu'elle n'a pas pu avoir lieu la veille à l'heure prévue. C'est dommage, car le nomre de participants a été divisé par trois à cause de cela.

PHP-GTK 2 est une extension permettant de développer des applications de bureau, c'est-à-dire qui s'exécutent dans l'espace utilisateur (Windows, Linux, MacOS, etc.) plutôt que sur le serveur (environnement Web classique). Cela permet de développer des scripts .php pouvant être exécutées sur n'importe quelle machine (pour peu de disposer de PHP-GTK 2), un peu à la manière des fichiers .class de Java.

Je trouve les scripts PHP-GTK 2 très similaires à des applets Java, tout en restant du PHP.

Le plus simple est vraiment d'utiliser Gnope. Téléchargez l'installeur, exécutez-le, laissez-le faire jusqu'au bout et vous aurez un PHP-GTK 2 prêt à utiliser.

Créez le script suivant (de la démo officielle de PHP-GTK 2), puis double cliquez dessus pour l'exécuter :

<?php

$window = new GtkWindow();
$window->set_title('Hello world');
$window->connect_simple('destroy', array('gtk', 'main_quit'));

$lblHello = new GtkLabel("Just wanted to say\r\n'Hello world!'");
$window->add($lblHello);

$window->show_all();
Gtk::main();

?>

Cet exemple démontre parfaitement à quel point programmer en PHP-GTK 2 est différent de programmer en PHP pour le Web.

Il faut dire adieu à de nombreuses choses auxquelles nous sommes habitués, comme les sessions et les cookies qui n'ont aucun sens ici.

En revanche, de nouveaux concepts font leur apparition, comme les widgets (éléments visuels) et connecter un évènement à un widget (afin de faire en sorte que l'application réagisse aux actions de l'utilisateur). Ceux d'entre vous qui connaissent PHP::Ming y sont un peu habitués.

PHP est passé de la version 4.x à 5.x et dispose maintenant d'un modèle objet bien plus mature. Par conséquent, quelques choses ont changé...

De même, GTK+ est passé en verson 2, ce qui implique l'apparition de nouvelles classes et le passage d'autres en deprecated (utilisation déconseillée).

Retrouvez tout cela dans la documentation officiellePHP-GTK 2 : Changes since PHP-GTK 1.

Faisant elle-même partie de l'équipe de développeurs de PHP-GTK 2, Steph maîtrise évidemment le sujet. Cependant, j'ai eu l'impression qu'elle a eu moins de temps que ses collègues pour préparer son intervention : le Powerpoint était moins attrayant visuellement et nous avons débordé sur la session suivante (deadly sins) sans avoir pu couvrir tous les aspects prévus.

Toutefois, Steph n'est pas entièrement en cause, car les auditeurs étaient tous très intéressés et ils ont posé de nombreuses questions, ce qui a obligé Steph à faire diverses démonstrations chronophages.

Concernant PHP-GTK 2, il semble qu'une version bêta sera diffusée avant Noël. Le code fait actuellement environ 5600 lignes (plus les includes) et la majorité des fonctions ont été réécrites.

Pour le coup, PHP-GTK 2 est complètement hors de la portée de PHPT...

Si vous cherchez la séparation logique/présentation comme avec des templates, penchez-vous sur Glade. Si c'est l'internationalisation qui vous préoccupe, alors renseignez-vous sur Pango.

Arjen Lentz est ingénieur de support et formateur pour MySQL AB.

Cette session était la plus divertissante de toutes. À la fin de quatre jours de discussions sérieuses, cela fait du bien (même si, pour ma part, je n'étais là que pour deux jours).

Arjen maîtrise son sujet, depuis le temps qu'il présente cette session à diverses conférences. Le principe est de faire prendre conscience à l'audience des bêtises les plus courantes.

Malheureusement, il m'a été demandé de ne pas diffuser les diaporamas de la présentation. Cela se comprend, dans le sens où tout le code qui s'y trouve correspond à de mauvaises pratiques... Ainsi, je ne pourrai pas vous faire partager cette expérience comme je le fais pour les autres.

Je tiens à remercier Arjen pour le chocolat qu'il m'a attribué pour ma bonne réponse. Le sachet a survécu au voyage de retour et j'ai pu en profiter tranquillement, de retour chez moi. Succulent ;-)

C'était une session très instructive. Les participants ont vite compris qu'il s'agissait d'une session interactive (les chocolats sont un appât efficace...) et certains avaient de réelles compétences, j'en étais impressionné. Même Arjen était parfois dépassé, et il a été obligé de distribuer quelques chocolats pour avoir le droit de reprendre la parole...

Gerd Schaufelberger a développé la communauté my.nero.com et il travaille maintenant en freelance.

C'était la seconde session en allemand à laquelle j'assistais. Je ne savais pas exactement à quoi m'attendre avant de m'asseoir...

Je n'ai malheureusement pas pu récupérer les diaporamas de la présentation, puisque je devais partir pour prendre l'avion.

Gerd parlait de trouver le juste milieu entre le Web 1.0 (une page complète pour chaque requête) et le Web 2.0 (à l'extrême, cela donne une page qui n'est jamais rechargée).

Quelques outils conseillés : PEAR::HTML_AJAX (JavaScript) et Prototype (PHP). Pourquoi ne pas mélanger les deux ?

C'était une session plutôt pour les nouveaux arrivants dans le monde d'AJAX. Je n'y ai pas trouvé d'idées novatrices, mais c'était certainement dû à mes compétences limitées dans la langue allemande.