Mirmo Dynamics

Les liens interressants (ou pas) de la semaine:

• http://microformats.org/
• http://www.georss.org/
• http://www.thinkvitamin.com/feature...
• https://features.launchpad.net/dist...
• http://iwantmyopenid.org/bounty
• http://devzone.zend.com/node/view/i...
• http://weierophinney.net/matthew/up...

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

Il y a tout un tas de raisons d'écrire des tests unitaires pendant ses développements, comme raccourcir radicalement le cycle code, test, debug, fix, assurer le fonctionnement de la globalité de l'application tout au long du développement, etc. Une autre que je viens de découvrir, c'est qu'écrire des tests unitaires, c'est tout simplement réfléchir à des situations susceptibles de casser votre application. On y passe beaucoup plus de temps que lorsque l'on développe vraiment, et du coup, on trouve beaucoup plus de choses, et on fait directement les modifications nécessaires. Chouette ça.

Liens en vrac:

• MySQL DBA, le blog d'un DBA de chez flickr.
• Serving Javascript Fast, par un développeur de chez flickr (décidément...) A noter que cet article parle des méthodes de cache d'une manière assez généraliste pour être appliquée à autre chose que du JavaScript, et n'oubliez pas non plus de lire les commentaires, il y en a de très interressants.
• AJAX & Protoype: A Primer, explication simple et claire sur l'utilisation d'AJAX et des Classes avec Prototype.
• Akra's Devnotes: Zend Framework, la catégorie Zend Framework du blog de Rob Allen, très interressante.