Mirmo Dynamics - Tag - configuration

symfony: use your own View class

Geoffrey — Mon, 23 Feb 2009 20:57:00 +0100

The view class name in symfony is determined per-module, it means that you need to use a module-level configuration setting via the module.yml configuration file. Say you want to use the myView class to handle your view in the default module of your frontend application, create the file sf_root_dir/apps/frontend/config/module.yml and put the following in it:

default:
  view_class:  my

Symfony will add the View suffix for you. Of course, you have to take care of making this class available to the framework. The sf_root_dir/apps/frontend/lib/myView.class.php file would be a good place for this.

As often with sfConfig, you could have put the module.yml config file in sf_root_dir/config/ to make it global to your whole project.

PS: extending the sfPHPView class could be a good idea to get you started too ;)

A specific stylesheet for each module

Geoffrey — Wed, 15 Oct 2008 00:43:00 +0200

So this is the first post of the newly opened symfony category of this blog, and I want to make things clear right now: you (most likely) won't find (yet) any protip or high level symfony tutorials here, as I'm still in the process of learning symfony. The good news though is that I'm currently assigned an 1.2-DEV project, so you may get some insight at what's up in the dev branch of the framework (especially regarding sfForm) :-)

If your are looking for more complete material on the subject, please redirect yourself to the official website (where you can find the documentation and a very interesting blog) or Fabien's blog.

That said, I think it could be interesting to post all the little things I learn everyday that make development with symfony easier for the everyday php developper that you might be if you made it this far into this post ;-)

Soooo, let's begin the show, with some yaml magic. Yaml I said ? Yaml I said. For those not knowing yet, yaml is the format of choice for symfony's configurations file. So what's the point between configuration files and stylesheets ? Let's say you've got a symfony application (say, frontend), and you'd like a particular module (say, news) in this application to have its own stylesheet in addition of the defaults stylesheets you defined already. Very simple, you start by creating the adequate configuration file:

cd apps/frontend/modules/news/
mkdir config
vi config/view.yml

All you have to do know is declare the stylesheet:

all:
  stylesheets: [news]

And that's all, no helper call in the layout, your news.css will automagically be appended to the <head> of your generated html. You can also declare multiples css, or control which actions get a particular css, and even specify to which media they apply:

all:
  stylesheets: [news, news_print: { media: print }]
list:
  stylesheets: [list]

Handy, heh.

But that's not all ! If you're not that much into yaml, you can use a view helper, directly into your template:

<?php use_stylesheet('news'); ?>

Or even add it from the controller:

<?php $this->getResponse()->addStylesheet('news'); ?>

Linux + gVim + Rox-filer = Mon IDE.

Geoffrey — Tue, 28 Nov 2006 22:39:00 +0100

Une des questions cruciales qui se pose à tout développeur à au moins un moment de sa vie (souvent plusieurs en fait) est le choix d'un environnement de développement. J'en ai testé pas mal, plus ou moins longtemps, et bien que je ne sois jamais complètement satisfait, l'idée de perdre du temps à développer le mien m'indispose. J'ai donc opté pour l'environnement qui me va le mieux: Linux + gVim + Rox-filer.

Note: je ne couvre pas ici les fonctionnalités de débuging avancé, que je n'utilise pas encore, mais pour lesquelles j'ai déjà en tête des solutions qui me conviendront bien mieux que les outils intégrés à un quelconque IDE (je pense fortement à Xdebug).

Comment définir un IDE ?

Commençons par le début: qu'est-ce qu'un IDE ? Acronyme de Integrated Development Environment, le terme peut prendre pas mal de signification selon la personne à laquelle on s'adresse. Pour certains, le plus c'est le mieux, alors que pour d'autre, le moins c'est le pas plus mal finalement. On pourra citer quelques exemples connus d'IDE full-featured, tels que les incournables Zend Studio, Eclipse et autres phpEdit, mais ce n'est pas le but de cet article. Ici, je vais vous expliquer pourquoi et comment j'utilise quotidiennement gVim et Rox-filer, et le tout sous Ubuntu.

Revenons en à nos moutons, un environnement de développement, c'est constitué de quelques briques primordiales:

Un éditeur de code
Un navigateur de fichier
Un truc qui fait tourner tout ça

Peu importe qu'ils soient intégrés ou non, finalement. Personnellement, je suis un fervent adepte du précepte une tâche, un outil, donc je preferre qu'ils soient dissociés.

L'éditeur de code: gVim

Certains perdent leurs moyens à la simple évocation de son nom, vim n'est pourtant rien de plus que le plus puissant des éditeurs de fichier aujourd'hui disponible dans le monde (un troll s'est malicieusement glissé dans cette affirmation, saurez-vous le retrouver ?). Ce qui déroute au premier abord dans vim, c'est finalement ce qui fait toute sa puissance: le mode commande. J'ai longtemps utilisé bluefish, et finalement las de ses quelques bugs bien énervants (wtf syntax color ?), j'ai décidé de faire le grand pas, et d'utiliser vim. J'avais bien sur déjà une expérience de cet éditeur, mais retenez bien que le meilleur moyen de maitriser un outil aussi puissant que vim, ce n'est pas de se jeter à corps perdu dans la doc, mais c'est d'investir du temps incrémentiellement: commencer à utiliser vim, et quand on souhaite faire quelque chose qu'on ne sait pas faire, lire la doc correspondante^[1]. Pour finir, j'ai traduit il y a quelque temps un excellent tutoriel sur vim: L'édition efficace avec vim, donc n'hésitez pas.

Un .vimrc qu'il est joli

Comme la plupart des applications *nix, vim autorise l'utilisation d'un fichier ~/.vimrc. S'il peut paraitre compliqué au premier abord d'élaborer un .vimrc efficace, il ne faut pas se décourager, car comme d'habitude, il y a tout ce qu'il faut sur le net. J'en veux pour preuve les excellents articles de Tobias Schlitt à ce sujet.

Pour info, quelques directives de configuration utiles qu'on peut trouver dans mon .vimrc:

" Supprime un buffer de la mémoire via le raccourci clavier Ctrl+W
noremap <C-W> :bdel!<CR>

" Active l'indentation automatique
set autoindent

" Active les plugins de type de fichier
filetype plugin on

" Active la coloration syntaxique
syntax on

" Thème de couleur pour gVim
colorscheme desert

" Utiliser des tabs de 4 caractères pour l'indentation
set noexpandtab tabstop=4 shiftwidth=4

" Activer la souris (molette, sélection, etc)
set mouse=a

" Afficher des infos dans la barre de status
set ruler
set laststatus=2

" Activer la numérotation des lignes
set number

" Utiliser la recherche incrémentielle
set incsearch

" Ne pas surligner les résultats de recherche
set nohlsearch

Quelques unes (beaucoup en fait) de ces directives sont tirées du .vimrc de Tobias.

Dernier détail pour les réfractaires de la ligne de commande, gVim s'execute en mode graphique, avec une interface GTK conviviale qui permet d'apprendre les raccourcis aisément, et qui gère la souris (défilement à la molette, etc, et d'ailleurs, même en console ça gère la souris, il suffit d'un :set mouse="a" pour l'activer).

Un ftplugin pour le PHP

Ce qu'on appelle ftplugin dans vim permet de configurer vim en fonction du type de fichier que l'on édite. Tobias fournit un ftplugin spécialisé dans l'édition du PHP plutôt bien foutu, qui gère la plupart des features convi-enabled des soit disants IDE évolués:

Complétion des fonctions
Complétion des mots-clés
Auto-fermeture des crochets, parenthèses, etc.
Auto-génération des docblocks PHPDoc
Vérification de syntaxe du fichier édité
Et d'autres trucs merveilleux !

La classe non ?

Un navigateur de fichier kirox (tm)

C'est pas moi qui le dit, en fait c'est comme le port-salut, rox-filer rox, c'est tout. Pour ceux que ma puissance de persuasion ne suffit pas, et bien rox-filer offre tout ce que vous pourriez attendre d'un gestionnaire de fichier moderne:

Navigation spatiale avec technologie oupas (tm)
Prévisualisation des images
Personnalisation (aisée !) des applications utilisées pour lancer les fichiers (en fonction du mimetype)
Navigation one-click (oupas (tm))
Navigation aisée au clavier
Monitorage des fichiers en cours d'utilisation (ils apparaissent en gras, ce qui est pratique).
Et j'en passe et des meilleurs.

Bref, il fait tout ce que ferait un filebrowser intégré, mais en mieux, puisqu'il est dédié dès le début à cette tache. Afin de le faire interragir au mieux avec gVim, j'utilise la Run action suivante sur le mimetype text/*:

gvim --servername ash0 --remote-silent-tab "$@"

Qui permet d'ouvrir le fichier dans un nouveau tab de vim, en créant une instance d'un server vim à la volée si il n'existe pas déjà (ici le server s'appelle ash0, mais vous pouvez bien évidemment en changer le nom).

Une distribution du bien: Ubuntu

Et parcequ'il faut bien faire tourner tout ça, j'utilise un système d'exploitation du bien (tm): GNU/Linux. Mais comme j'ai la flemme, j'utilise une configuration convi-enabled: Ubuntu. Pas besoin de s'étaler je pense, Ubuntu c'est bien, tout le monde en conviendra.

Un window-manager léger et puissant: fluxbox

Le choix du gestionnaire de fenêtre peut par contre préter a controverse. En effet, c'est ici avant tout une question de gout et de puissance de machine. J'ai personellement un penchant pour les logiciels puissants et légers. Là je vous vois venir avec vos gros sabots: tout le monde veut ce genre de logiciel. Et bien j'ai envie de répondre que non. La majorité des neo-geeks de la génération Ubuntu s'en donnent à coeur joie sous Gnome et/ou KDE, qui est loin de ce qu'il convient d'appeler un logiciel puissant et léger, sous prétexte que les autres WM (à part KDE), saitrocomplicai. Bon là ok, j'amalgame surement un peu (beaucoup même, tous les gens sous Gnome ne sont pas des neo-geek, et l'inverse également), mais il manquait un peu de trollitude dans cet article. Bref, quand on veut, on peut, et comme les gens ne switchent pas de Gnome à un WM plus puissant et plus léger, j'en conclus (peut-être à tord hein) qu'ils ne veulent pas.

Tout ça pour dire que j'utilise fluxbox, et ce depuis ma plus tendre enfance. Fluxbox est léger (osez prétendre le contraire...) et puissant: il permet:

de reconfigurer l'intégralité du comportement de vos fenêtres
une gestion fine et puissante des raccourcis claviers (j'ai pu reconfigurer les touches convi de mon clavier convi en quelques minutes dans mon .fluxbox/keys grâce à xev).
de controler facilement quelles applications se lancent au démarrage
de controler encore plus facilement sur quels bureaux se lancent les sus-citées applications

Par exemple, mon .fluxbox/startup démarre sur le premier bureau quelques terminaux, un gaim et un exaile; sur le deuxième bureau un firefox sur le troisième bureau: sylphee, et sur le quatrième bureau, un rox-filer. A coté de ça, je dispose de raccourcis claviers conviviaux pour lancer mes logiciels favoris: le terminal (Mod4^[2]+e), rox-filer (Mod4+r), etc. J'ai également à ma disposition des raccourcis claviers pour gérer mes fenêtres: maximiser (horizontalement (Ctrl+Alt+H), verticalement -Ctrl+Alt+V), ou les deux (Ctrl+Alt+M)), enrouler (Mod4+S), sticker (Ctrl+Alt+S), enlever les décorations (Ctrl+Alt+T), et j'en passe.

Enfin, et le plus important pour moi, fluxbox est non-intrusif. Par défaut, un bureau standard de mon fluxbox ne contient rien. Pas de barre des taches, pas d'icones, pas de menu, rien. Question de gout je vous l'accorde, mais là encore, notez que "c'est faisable": fluxbox ne vous impose rien, et surtout pas les choix discutables car subjectifs des développeurs.

Subversion en ligne de commande

Enfin, j'utilise le client subversion en ligne de commande. D'une part parceque je ne connais pas de client digne de ce nom en GTK (ma religion m'interdit d'utiliser Qt), d'autre part pour profiter pleinement de la puissance qu'offre un shell quand on sait un minimum s'en servir. Pouvoir passer mes commandes svn dans des awk, sed, et autres grep (surtout grep en fait), ça n'a pas de prix, et je pense vraiment qu'aucune interface graphique n'arrivera jamais à la cheville de la puissance d'un shell.

Deuxième avantage à utiliser svn en ligne de commande: le jour où je serais obligé de le faire, je saurais le faire.

Conclusion

Voilà, vous savez (presque) tout de mes habitudes de travail (il reste pas mal de domaines à couvrir quand même, je n'ai pas parlé par exemple de mes extensions firefox favorites, ni de mon utilisation intensive de trac, et encore moins des tests unitaires, peut-être une prochaine fois), et j'espère vous avoir donné l'envie de regarder d'un peu plus près ces outils à la réputation peut-être un peu geek, mais d'une puissance incomparable une fois maitrisés :-)

Notes

[1] :help commande est en général d'une grande utilité

[2] Le petit nom de la touche Windows

ViewHelper de génération d'urls

Geoffrey — Fri, 24 Nov 2006 20:27:00 +0100

Pré-requis: Zend_Controller_RewriteRouter.

Nous allons voir aujourd'hui comment générer automagiquement des URLs à partir des routes définies dans le RewriteRouter, ainsi que les avantages que cela présente. Le Helper que nous allons utiliser nécessite le stockage du routeur dans le registre:

Zend::register('router', $router);

Avant de voir le Helper lui même, un petit Use Case. Admettons que vous développiez une application de gestion de petites annonces, vous aurez à un moment ou un autre à créer un lien quelconque pour, par exemple, créer une annonce, et en voir les détails. Disons que vous ayez des routes route du genre (je zappe les defaults):

announceCreate.route = /announce/create
announceDetails.route = /announce/:id/details

L'objectif est de pouvoir créer les liens grâce au code suivant (à partir de la view):

<a href="<?php echo $this->href('announceCreate'); ?>">Créer une annonce</a>
<a href="<?php echo $this->href('announceDetails', array('id' => $announce->id)); ?>">Voir l'annonce</a>

Et comme le Zend Framework est bien fait, c'est très simple à réaliser sous forme de ViewHelper:

class Zend_View_Helper_Href {
	
	/**
	 * Returns the href to a given route
	 *
	 * @param string $routeName
	 * @param array $args
	 * @return string
	 */
	
	public function href($routeName, $args = array()) {
		try {
			return Zend::registry('router')->getRoute($routeName)->assemble($args);
		} catch (Zend_Controller_Router_Exception $e) {
			return '#404';
		}
	}
}

Tellement simple que pour combler un peu je vous offre le docblock qui va avec ;-)

Là où ça devient très pratique, c'est quand on souhaite localiser les URLs. Par exemple, imaginons que vous souhaitiez françiser les URLs pour, par exemple, améliorer votre référencement. Vous n'avez qu'a définir un jeu de routes fr_FR, par exemple ainsi:

[routes_fr_FR]
announceCreate.route = /annonce/creer
announceDetails.route = /annonce/:id/details

[routes_en_UK]
announceCreate.route = /announce/create
announceDetails.route = /announce/:id/details

[routes:route_fr_FR]
announceCreate.defaults.controller = announce
announceCreate.defaults.action = create

announceDetails.defaults.controller = announce
announceDetails.defaults.action = details

L'utilisation de l'héritage géré par Zend_Config nous permet ici d'éviter la redondance des defaults.

Elle est pas belle la vie ?

Note: cette fonctionnalitée est prévue pour être builtin plus tard.

Discussion sur l'optimisation en PHP chez NiKo

Geoffrey — Thu, 23 Nov 2006 13:40:00 +0100

Une petite discussion sur l'optimisation en PHP à lieu en ce moment chez NiKo ! Ce n'est pas souvent que je link directement comme ça, donc dites vous que quand je le fais, c'est que ça en vaut la peine ;-)

Howto: Utiliser Zend_Controller_RewriteRouter avec Zend_Config

Geoffrey — Tue, 31 Oct 2006 20:26:00 +0100

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.

Mettre en place le routeur

C'est bien beau tout ça, mais pour l'utiliser, il faut déjà en informer le controlleur. Pour cela, rien de plus simple, on utilise la méthode addRouter:

$router = new Zend_Controller_RewriteRouter;
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

Le RewriteRouter est pré-configuré avec deux routes qui permettent d'assurer la compatibilité descendante avec l'ancien routeur, donc jusque là, tout va bien.

Déclarer les routes

Nous utiliserons un fichier de configuration dédié aux routes, que nous appellerons sobrement routes.ini, et que nous placerons dans app/, à coté de son compagnon config.ini. Ce fichier de configuration contiendra une unique section [routes], qui contiendra à son tour les multiples définitions de routes que nous souhaitons y caser. Une route se compose de 5 éléments principaux:

L'identifiant de la route. C'est un identifiant interne utilisé par le RewriteRouter,
l'URL de la route, c'est ce qui permet au routeur de reconnaitre la route à utiliser,
les valeurs par défauts des variables,
les requirements de la route, qui permettent de déterminer si une route est bien formée ou non.

Sans plus attendre, un petit exemple: la route qui pourrait permettre d'accéder à un billet dans dotclear 2:

post.route = post/:year/:month/:day/:title
post.reqs.year = "\d+"
post.reqs.month = "\d+"
post.reqs.day = "\d+"
post.reqs.title = "[a-zA-Z0-9_:-]"+
post.defaults.controller = post
post.defaults.action = view
post.defaults.title =

Elle pourrait seulement, car en fait, la regexp du title est trop restrictive (une URL peut contenir d'autres caractères que ceux là), et de plus, les URL stockées par dotclear 2 en base de données comprennent tout ce qui se trouve après post/ (par exemple le champs post_url de ce billet contient: 2006/10/31/Howto:-Utiliser-Zend_Controller_RewriteRouter-avec-Zend_Config).

Cela étant dit, la route que nous venons de décrire s'appliquera aux URLs suivantes:

/post/2006/30/10/ZendFramework
/post/42/2006/56/Foobar
/post/2006/30/10/
etc.

Mais pas à:

/post/2006/Foobar
/post/Foobar/2006/30/01
etc.

On note donc d'ores et déjà:

que la validation des composants d'une route se fait par expression régulière
qu'on peut ommettre le dernier composant d'une route si il possède une valeur par défaut (récursivement)
qu'on ne peut pas modifier l'ordre des composants d'une route
qu'on doit spécifier manuellement le nom du controlleur et de l'action à utiliser
et c'est déjà pas mal.

Décortiquons maintenant une URL: /post/2006/30/10/ZendFramework. Le routeur va diviser cette URL ainsi:

Controller: post (d'après les defaults)
Action: view (d'après les defaults)
Paramètres: year: 2006, month: 30, day: 10, title: ZendFramework (d'après l'URL)

Les paramètres ainsi détectés seront disponibles via la méthode $this->_getParam($name); a l'intérieur du controlleur.

Dernier point de ce chapitre, une déclaration de route peut comporter deux variables spéciales: :controller et :action, qui servent respectivement à détecter le controller et l'action à utiliser dans l'url. Par exemple, la route builtin compat chargé d'assurer la compatibilité descendante se déclare ainsi:

compat.route = :controller/:action
compat.defaults.controller = index
compat.defaults.action = index

Assembler le tout

Dernière étape, transférer directement toutes ces déclarations dans le Routeur: n'y allons pas par quatre chemin:

$router->addConfig(new Zend_Config_Ini('/path/to/routes.ini', null), 'routes');

C'est aussi simple que ça. Ce qui nous donne, en prenant en compte le morceau de code du début de l'article:

$router = new Zend_Controller_RewriteRouter;
$router->addConfig(new Zend_Config_Ini($routes_path, null), 'routes');
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

And voilà. Je ne saurais que vous conseiller la lecture du manuel pour plus d'informations (sachant qu'en fait, addRoute attend en deuxième argument une instance de Zend_Controller_Router_Route, mais qui s'instancie avec les paramètres qu'ils passent à addRoute, petite coquille du manuel :p).

Mettre en place un SSO avec Invision Power Board

Geoffrey — Wed, 25 Oct 2006 23:02:00 +0200

Rien de plus simple, tout est déjà prévu. Après l'installation de votre forum IPB, nous allons enregistrer une nouvelle méthode de login. Pour se faire, dans le panneau d'administration, nous nous dirigeons vers Tools and Settings, puis dans Create New Log In du menu Log In Manager. On se retrouve devant un formulaire (assez explicite) que je vous laisse le soin de remplir. On dira juste que nous appellerons cette méthode de login Mon SSO (Log In Title) et qu'il vivra dans le répertoire mon_sso (Log In Files Folder Name). Pour que votre méthode de login soit active, vous devez cocher Log In Enabled, et il est toujours bon de passer en mode On-Fail, ainsi que d'autoriser la création d'utilisateurs (Log In Allow Member Creation), qui créera automagiquement les utilisateurs dans la base locale d'IPB.

Ensuite on met les mains dans le camboui. Dans le répertoire sources/loginauth/ de votre installation, il doit exister un repertoire external/, qui nous servira de base. On commence donc par le dupliquer:

cp -r external mon_sso

Puis on regarde un peu ce qu'il y a dedans:

mon_sso/
	auth.php
	conf.php
	index.html

Le fichier index.html n'est qu'un empécheur de tourner en rond pour les gens qui explorent un peu trop les arbos web. Le premier fichier qui nous interresse est conf.php, il contient les informations relatives à la base de données distantes. Là encore, c'est assez explicite et bien commenté. Le seul petit truc à savoir est que l'utilisateur qui se connectera à la base a besoin des droits SELECT sur toute la table, pas seulement sur les champs login / pass.

Dans le meilleur des cas, votre SSO est prêt :p Le fichier auth.php contient les méthodes appelées par le gestionnaire d'identification. Vous pouvez avoir besoin de modifier __compare_password, pour la vérification du mot de passe (j'ai par exemple changé la méthode de cryptage qui est md5 par défaut).

A ce stade, vos utilisateurs peuvent s'identifier, mais le forum leur demande quand même leur mail et quelques infos que j'ai oublié. Il est bien évidemment possible d'éviter ça :-) Dans la méthode authenticate, vers la fin, quand un utilisateur local est créé, la main est passée à la méthode create_local_member, qui redirige ensuite vers l'écran de complétion du compte. C'est là que nous intervenons. La méthode create_local_member n'est pas implémenté dans login_method, mais dans login_core, qui se trouve dans le fichier sources/loginauth/login_core.php, nous commençons par la copier/coller dans notre login_method, puis nous modifions sa déclaration pour lui permettre de recevoir $remote_member en paramètre:

function create_local_member( $remote_member )
{

Cette méthode permet de piocher dans les informations récupérées dans la base distante. Dans la partie Populate member table(s), par défaut, un faux mail est créé:

$email_tmp = $username.'@'.$timenow;

Qu'on peut remplacer par le mail qu'on a déjà potentiellement dans la base distante (disons que le champs s'appelle mail):

$email_tmp = $remote_member['mail'];

On peut ensuite récupérer les champs que l'on veut pour les ajouter au membre local, par exemple dans mon cas, le display_name (nickname chez moi):

$display_name = $remote_member['nickname'];

en les rajoutant dans le tableau $member.

Les deux derniers appels de méthode dans create_local_member, $this->ipsclass->DB->do_insert et $this->ipsclass->print->redirect_screen sont à commenter, et on rajouter avant le bout de code suivant:

$this->return_code = 'SUCCESS';
return;

Retour dans authenticate, dans la partie Got no member - but auth passed - create?, on modifie la première partie du if ainsi:

if ( $this->allow_create )
{
	$this->create_local_member( $remote_member );
	$this->_load_member($username);

	if ( $this->member['id'] )
	{
		$this->return_code = 'SUCCESS';
	}
	else
	{
		$this->return_code = 'NO_USER';
	}
	return;
}

And voilà, nos utilisateurs peuvent désormais s'identifier sans avoir a re-entrer des informations que l'on possède déjà :-)

Relayer un stream audio avec icecast2

Geoffrey — Fri, 20 Oct 2006 22:05:00 +0200

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 :-)

Un forum qu'il est bien: Invision Power Board

Geoffrey — Fri, 20 Oct 2006 14:13:00 +0200

Alors au taf on va déployer des forums sur l'ensemble des sites du groupe, et donc après un rapide tour des forums disponibles (tant libres que commerciaux), on a choisi Invision Power Board. Après une matinée de trifouillage, j'ai l'intime conviction que nous avons fait le bon choix. En effet, avec Invision Power Board, on peut mettre en place un SSO en moins d'une heure tout en

buvant son café
lisant ses RSS
discutant avec son chef
glandant sur IRC
rigolant avec les collègues

Et ça, c'est pas avec des forums libres que c'est possible.

Gestion de la configuration: Zend_Config

Geoffrey — Mon, 04 Sep 2006 22:57:00 +0200

Il existe au bas mot autant de manières de gérer la configuration d'une application qu'il y a de développeurs: fichier INI, variables, constantes, fichier XML, etc. Le composant Zend_Config développé par Rob Allen propose une approche simple et élégante basée sur un fichier INI qui permet de mettre en place aisément plusieurs environnements de configuration. Commençons par rappeler qu'un fichier INI s'écrit le plus simplement du monde en associant un nom de variable (composante gauche) à une valeur (composante droite) en leur interposant un signe d'égalité:

name = value

On peut également y ajouter des sections, qui permettent de structurer le fichier:

[database]
hostname = localhost
username = unprivilegieduser
password = someobscurepassword
database = mydatabase

Venons en au vif du sujet, l'utilisation proprement dite du sus-cité composant. N'y allons pas par quatre chemins, balançons directement un petit bout de code:

Zend::loadClass('Zend_Config');
Zend::loadClass('Zend_Config_Ini');

$config = new Zend_Config(Zend_Config_Ini::load('mon/fichier/ini', 'section'));

Rien de bien compliqué, on indique a Zend_Config_Ini un fichier INI à charger, et plus précisément quelle section de ce fichier nous interresse, puis il transmet les informations qui vont bien à Zend_Config, qui s'occupe de nous créer un bel objet de configuration. L'objet $config contient dès lors les valeurs du fichier INI comme autant de variables membres. Par exemple, si on utilise le fichier INI détaillé plus haut, on pourrait faire:

echo $config->username;

Ce qui afficherai unprivilegieduser. Simple non ? Simple, mais ne nous leurrons pas, ce n'est pas là l'usage que l'on fera de ce composant. En effet, quoi de plus rébarbatif que de devoir charger chaque section d'un fichier INI ? La vraie puissance de ce système réside dans le fait qu'il permet d'avoir des environnement de configuration séparés. Remanions légèrement notre fichier de configuration:

; Developement environement configuration
[dev]
db.hostname = localhost
db.username = unprivilegieduser
db.password = someobscurepassword
db.database = mydatabase

; Production configuration
[prod]
db.hostname = db.monsite.fr
db.username = someobscureuser
db.password = somereallyobscurepassword
db.database = mydatabase

Comme Zend_Config_Ini fait bien les choses, il analysera chaque nom de variable pour créer une arborescence d'objets en utilisant le . (point) comme séparateur. On aura ainsi:

$config = new Zend_Config(Zend_Config_Ini::load('./example.ini', 'dev'));
echo $config->db->username;

Il ne reste plus qu'a déterminer une manière de savoir quand on se trouve dans l'environnement de production ou dans celui de développement, il existe quelques méthodes pour cela:

un fichier .htaccess avec une directive SetEnv DEV 1, qui donnera la variable $_ENV['DEV'] dans le script
un test sur l'IP du serveur (IP locale, serveur de développement, IP publique pour le serveur de production)
un test sur la variable $_SERVER['HTTP_HOST'] (dev.monsite.fr, etc)

A titre personnel, j'utilise la solution du .htaccess, qui peut s'implémenter comme ça:

$section = isset($_ENV['DEV']) ? 'dev' : 'prod';
$config = new Zend_Config(Zend_Config_Ini::load('./example.ini', $section));

On peut bien entendu enregistrer notre instance de $config dans le Zend_Registry:

Zend::register('config', $config);

Ce qui nous permettra d'y avoir accès en toute simplicité par la suite:

$config = Zend::registry('config');

(Commentaires et Trackbacks sur PHP Mafia)