Première conférence intéressante : Plein Phar, de Fréderic Hardy.

Je vous livre mes notes en vrac, en espérant que ce soit lisible :

Introduction

Phar = JAR en Java (archive qui regroupe et éventuellement compresse plusieurs fichiers en un)

• Concaténer plusieurs fichiers en 1
• Compression (zLib, Tar…)
• Sécurité : openSSL possible, signatures
• Executable ou non

Peut être inclus très facilement en PHP :

require "phar://...";

Structure

Un fichier Pahr contient:

• Un fichier de démarrage (Stub) en PHP
  • Environnement
  • Autoload
  • Configuration
• Un manifeste (structure)
• les fichiers
• [Éventuellement une Signature]

Métadonnées

Utilisation possible de metadonnées (un peu comme les annotations). On peut y mettre n'importe quoi : Auteur, release, version…

Je pense que ça peut être très pertinent de les utiliser pour gérer les versions : si avec un SVN c'est assez simple, le SVN ne fonctionne que dans un seul sens (on connaît la version en amont). Pour un serveur qui déploie souvent, sur des serveurs clients dont il n'est pas maître, prévoir une surcouche des versions par le Phar permet de mettre en place des systèmes de mise à jour automatique... Bref, une piste à creuser.

Compression

3 extensions :

- Phar - PharTar - PharZip

Il est possible de créer ses propres extensions, mais il vaut mieux utiliser ces 3 principales

Point de montage

On peut monter dans le phar des fichiers externes (mount)

Test unitaires

A la création, le stub n’est pas testé. Une fois le phar créé, les erreurs sont difficiles à gérer et opaques.

On peut utiliser des tests unitaires pour :

• S’assurer que les données sont complètes (utilisation de la signature)
• S’assurer des injections de dépendance
• En utilisant des mocks (objets répliquant virtuels d’objets, qui permettent de modifier son comportement. Ex : créer un mock d’une connexion mysql)

Performance

Varie selon l’environnement.

• Compressé : chute des perfs de 10/15%. C’est résolu par l’utilisation de phar.cache_list. (mais on a évidemment de l'autre côté des gains de Ram)
• Standard : baisse de 2/3%

Phar est compatible avec APC (et ça c'est une bonne chose ^^)

Obfuscation

Un phar n’est pas obfuscé ! Il ne faut pas compter dessus pour protéger le code (même s'il n'existe aucune solution ultime, Phar n'en est pas du tout une)

Déploiement et SVN

Une bonne idée : il suffit d’utiliser Hudson pour regénerer le Phar à chaque commit

Avec le Zend Framework

On peut imaginer mettre tous les fichiers du ZF dans un Phar, puis mettre le controller frontal dans le Stub.

Ressources

Un bon tutoriel (et au passage un bon blog) : http://blog.pascal-martin.fr/post/php-5.3-phar-php-archive

Voici mes notes en vrac. Cette conférence m'a donnée pas mal d'idée, je pense que je vais m'en servir dès lundi. Prochaine étape la prod' ?