Mirmo Dynamics

Pour installer le serveur PEAR, c'est simple:

pear channel-discover pear.chiaraquartet.net
pear install chiara/Chiara_PEAR_Server
pear run-scripts Chiara_PEAR_Server

Ensuite on répond aux question, et c'est automagique.

Après, pour créer des packages, ça se corse. Tout d'abord, on a besoin de PEAR_PackageFileManager:

pear install PEAR_PackageFileManager

Ensuite, le but est de générer les package.xml qui vont bien. Voilà comment j'ai procédé pour le package Zend:

mkdir -p ~/pear/zend/src && cd ~/pear/zend
wget http://framework.zend.com/download/tgz -O - | tar xzC ~
mv ~/ZendFramework-0.8.0/library/Zend* src/
php ./mkpkg.php make
cd src && pear package

Ceux qui ont bien suivi auront noté que mkpkg.php est sorti un peu de l'espace :-) Vous trouverez son contenu à la fin du billet.

Pour résumer, on créé un répertoire de travail (~/pear/zend/), dans lequel on créé un répertoire src, qui contiendra tous les fichiers du package, puis le script mkpkg.php se charge 1) d'analyser le contenu de src, et 2) de créer le package.xml qui va bien, selon les instructions qui lui sont fournies.

Nous disposons désormais d'un package Zend-0.8.0.tgz dans ~/pear/zend/src, que nous n'avons plus qu'a uploader via l'interface d'administration du serveur PEAR précédemment installé :-)

Le fichier mkpkg.php:

<?php

require_once('PEAR/PackageFileManager2.php');

PEAR::setErrorHandling(PEAR_ERROR_DIE);

$packagexml = new PEAR_PackageFileManager2;

$e = $packagexml->setOptions(array(
    'baseinstalldir' => '/',
    'packagedirectory' => dirname(__FILE__).'/src',
));

$packagexml->setPackage('Zend');
$packagexml->setSummary('Zend Framework');
$packagexml->setDescription('The Zend\'s PHP Framework');
$packagexml->setChannel('pear.phpmafia.net');
$packagexml->setAPIVersion('0.8.0');
$packagexml->setReleaseVersion('0.8.0');
$packagexml->setReleaseStability('devel');
$packagexml->setAPIStability('devel');
$packagexml->setNotes("Still a preview release");
$packagexml->setPackageType('php'); // this is a PEAR-style php script package
$packagexml->addRelease(); // set up a release section
$packagexml->setPhpDep('5.1.2');
$packagexml->setPearinstallerDep('1.4.0a12');
$packagexml->addMaintainer('lead', 'ash', 'Geoffrey Bachelet', 'geoffrey+pear@zubrowka.org');
$packagexml->setLicense('New BSD License', 'http://framework.zend.com/license/new-bsd');
$packagexml->generateContents(); // create the <contents> tag

$pkg = &$packagexml->exportCompatiblePackageFile1(); // get a PEAR_PackageFile object

if (isset($_GET['make']) || (isset($_SERVER['argv']) && @$_SERVER['argv'][1] == 'make')) {
    $pkg->writePackageFile();
    $packagexml->writePackageFile();
} else {
    $pkg->debugPackageFile();
    $packagexml->debugPackageFile();
}

?>

Méthode bourrin, je ne sais pas si il en existe une meilleure. Disons qu'on veut annuler la révision 329 (et que c'est la dernière en date):

$ svn update
$ svn merge -r 329:328 .
$ svn commit -m "cancel 329"

En tout cas chez moi ça a marché.

L'implémentation du Front Controller du Zend Framework inclue un système bien pratique de plugins, qui va nous permettre de réaliser plus simplement et proprement l'automatisation des vues, initialement embarquée dans une extension de Zend_Controller_Action (ce qui pose quelques problèmes, nottament au lors de l'utilisation de __forward() et _redirect()).

Comme je le disais plus bas, le Zend Framework Preview 0.2.0 est dans les bacs ! Cette nouvelle mouture apporte son lot de nouveautés, et nous allons nous pencher sur une des plus interressantes: le RewriteRouter. Le RewriteRouter est un routeur pour le composant MVC du Zend Framework qui va nous permettre de configurer nos URL comme dans Ruby on Rails, c'est à dire (en gros), via un fichier de configuration, et c'est là que Zend_Config entre en jeu.

Pour économiser la bande passante au boulot, j'ai décidé de relayer le stream Club ! de 1.fm sur le LAN. Après avoir vainement tenté d'utiliser streamripper (on verra plus tard pourquoi vainement), j'ai sorti l'artillerie lourde: icecast2:

sudo apt-get install icecast2

Si on sait un peu lire, le script de post-configuration nous incite à aller fourrer notre nez dans /etc/default/icecast2, où l'on apprend (vers la fin) que icecast est désactivé par défaut à cause de la directive ENABLED=false. C'est en fait une feinte pour nous pousser à configurer le bousin (de toute façon si on le configure pas, il marchera pas). Direction /etc/icecast2/icecast.xml donc, pour un brin de configuration (les explications qui suivent se basent sur le fichier par défaut d'une installation sur une ubuntu).

La première partie qui nous interresse s'intitule authentication (vers la ligne 23). Elle contient les informations d'authentification pour les clients qui se connectent en tant que source (source-password), les serveurs qui se connectent en tant que slave (relay-password, en fait je ne suis pas sur à 100%, c'est une déduction) et pour l'interface d'administration (admin-user et admin-password). Une fois ces informations modifiées, direction la directive hostname, qu'on remplira avec au choix, le nom de la machine, son ip, etc. J'ai personellement mis l'ip privée de ma machine (172.16.x.y), pour que ça correspondent à la prochaine directive qui nous interresse: listen-socket. Ici on définit le port et l'ip sur laquelle icecast va écouter. En gros, si vous spécifier 127.0.0.1, votre serveur de streaming ne sera accessible qu'en local. On y met donc en général la même chose que dans hostname (172.16.x.y par exemple), avec un port qui va bien, libre de préférence (8000 par défaut).

Maintenant on passe a la partie qui nous interresse vraiment, la section relay. Rien de bien compliqué ici. Le stream que je souhaite relayer se trouve là: http://64.62.253.223:8060/, or icecast nous demande un server, un port, un point de montage (mount) et un point de montage local (local-mount). Vous avez déjà compris qu'on arrive a cette configuration:

   <relay>
       <server>64.62.253.223</server>
       <port>8060</port>
       <mount>/</mount>
       <local-mount>/1.fm</local-mount>
       <on-demand>0</on-demand>
       <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
   </relay>

Ainsi parés, il ne nous reste plus qu'a lancer modifier la directive ENABLED=false en ENABLED=true dans /etc/default/icecast2 et à lancer icecast:

sudo /etc/init.d/icecast2 start

Si vous avez bien tout fait, vous devriez pouvoir streamer depuis http://172.16.x.y:8000/1.fm, et vos collègues également ! Vous pouvez avoir une vue d'ensemble du serveur ainsi que quelques options d'administration en vous rendant sur l'interface d'admin: http://172.16.x.y:8000/ et en utilisant admin-user et admin-password pour vous authentifier.

A cela on peut ajouter un petit streamripper:

streamripper http://172.16.x.y:8000/1.fm -d ~/streamripped

Pour enregistrer. En parlant de streamripper, j'avais tenté au début de relayer avec streamripper -r, mais malgrès les apparences du netstat -pl (*:8000 LISTEN), il ne bind qu'en local, donc impossible d'en faire profiter les collègues :-)

Nous avons parcouru dernièrement la création du bootstrap HTTP qui sert de socle à une application utilisant le Zend Framework. Le même principe peut s'appliquer aux scripts CLI, mais comme les besoins sont fondamentalements différents, l'implémentation sera elle aussi complètement différente. Nous viserons les objectifs suivants:

1. Ne pas être obligé d'executer le bootstrap en ligne de commande
2. Simplifier au maximum l'écriture ultérieure des scripts CLI
3. Définir un jeu d'options de ligne de commande obligatoire
4. Mettre en place un environnement d'execution

Bon voilà, je viens de suivre ce howto, et ça marche très bien. Passé le stade mais où sont mes efferalgans ?, on arrive rapidement au stade mais où mon smecta ?, tellement c'est gerbant de fluidité. Bref, le desktop mappé sur un cube, c'est sympa, mais on lui preferrera de loin les effets moins psychédéliques tels que la vraie transparence et les animations des fenetres (et encore).

Le rebutement principal que j'ai eu au début avec le Zend Framework était l'impossibilité (a priori) d'automatiser le rendu des vues en fonction du controlleur et de l'action appelés. Mes pérénigrations webesques m'ont finalement fait entrevoir la solution.

EDIT: mes nouvelles pérégrinations dans les sources du Zend Framework m'ont fait entrevoir une meilleure solution :-)

Tout se passe dans le destructeur du controlleur, et nous allons voir ici une version édulcorée de celle disponible dans le lien sus-cité. L'astuce qui sauve, c'est de savoir que l'objet Controller possède un membre _action, qui lui même propose (entre autres) deux méthodes bien utiles: getControllerName et getActionName. Il suffit donc de récupérer ces informations pour construire dynamiquement le chemin de la vue à utiliser pour un controlleur donné:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __destruct() {
		$view = Zend::registry('view');
		$controller = $this->_action->getControllerName();
		$action = $this->_action->getActionName();
		$viewPath = sprintf('%s/%s.php', $controller, $action);
		try {
			echo $view->render($viewPath);
		} catch (Exception $e) {
			trigger_error('Unable to render view: ' . $e->getMessage(), E_USER_ERROR);
		}
	}
}

Fichier source

Ce controlleur requiert que vous ayez instancié, configuré et enregistré Zend_View au préalable. Il ira, lors de sa destruction, chercher la vue dont le nom correspond à controller/action.php, c'est à dire:

• pour une URL du type http://example.com/foo/bar/, foo/bar.php,
• pour http://example.com/, index/index.php,
• pour http://example.com/foo/, foo/index.php.

Pour une raison obscure, on ne peut pas laisser trainer l'éventuelle exception générée par Zend_View dans le cas d'une vue inexistante. Cela entre en conflit avec une autre Exception qui traine, j'essayerai de tirer ça au clair :-)

Souvent les gens ne voient PHP que comme un langage de script orienté web. Même si il est vrai que c'est son but premier, ce n'est pas la seule chose que PHP peut faire. Penchons nous un peu sur l'utilisation de PHP en CLI, qui permet d'utiliser PHP comme un langage de script classique. Nous utiliserons pour se faire un système linux (ubuntu pour être précis) avec un binaire php-cli déjà installé.

Ce billet est une traduction d'un article que j'ai trouvé sur kuro5hin. Ayant trouvé l'article très interressant, et me disant que putain faudrait que je mette du stuff utile sur digital fashion un jour, j'ai contacté l'auteur qui s'est empressé de me donner l'autorisation de traduire et publier son article sur mon blog, ainsi qu'une version plus actuelle de l'article sur son site. C'est cette version que je vous livre ici traduite. C'est ma première vraie traduction, donc soyez indulgent merci :) si vous rencontrez des fautes d'orthographe, de style, ou de tournure n'hésitez pas à le signaler dans les commentaires, je corrigerais en conséquence.

Je tiens à remercier l'auteur, Jonathan McPherson, pour avoir publié un si bon article et pour m'avoir autorisé à le traduire et à le publier, ainsi que Renaud Littolff, pour la relecture.

Voilà, bonne lecture.