The configuration is pretty straight forward and can be set up to update a private account on your private StatusNet instance. In your .hgrc file, just add this section:

[statusnet]
username = hgstatusnet
password = secret
server = http://localhost
path = /statusnet
;preprend =


The server and path settings are used to locate the StatusNet instance. In my example, my instance lives at http://localhost/statusnet. I’m also updating hgstatusnet’s account. If I wanted, I could preprend a little bit of text to every message to differentiate repositories, for example.

You also need to configure the hook, like so:

[hooks]
incoming.hgstatusnet = python:hgstatusnet.statusnetutils.post_statusnet_hook


Be sure that the hgstatusnet module is in your python path. Otherwise, it won’t work. Also, be aware that this is an early version and I may want/need to implement more features in the future and that this code comes without warranty.

update (jan. 5th):
If you have any questions, comments or just want to share your experience, please don’t hesitate.

Je pense que c’est une bonne opportunité d’en apprendre en dehors de mes recherches personnelles et du travail en équipe, mais aussi de clarifier mes idées en les exposants.

Qu’est-ce que VeHO?

VeHO sera, si tout se déroule comme prévu, une plateforme de vente et de distribution électronique. Oui, une autre. Elle s’apparente aux Steam, Impulse, et autres. Sauf qu’elle sera moins complète/complexe. Il n’y aura pas de système de protection (DRM, ou autre), pas de système d’intégration des jeux grâce à une API, etc. Après tout, nous ne sommes que 2 et nous n’avons pas vraiment d’application concrète pour pouvoir tester tout ça. Mais le système devra être assez souple pour permettre et faciliter la mise en place de fonctionalités semblables.

VeHO sera d’abord et avant tout un site Web où les usagers pourront effectuer leurs achats. Nous ne souhaitons pas réinventer les systèmes e-commerce, alors nous allons nous baser sur un déjà existant. Chaque usager, qu’il soit publieur ou acheteur, pourra donc se utiliser complètement le catalogue à partir d’un navigateur Web. Aussi, les publieurs d’applications aura la possibilité de consulter les statistiques de ventes selon plusieurs critères.

Mais VeHO est aussi une application cliente multi-plateforme. Elle servira d’interface avec le site Web, mais permettra aussi aux usagers de communiquer entre eux. Le but étant de joindre communauté et magasin en ligne. Nous en sommes toujours à déterminer si l’application supportera les tranfers pas le biais d’un réseau P2P ou si nous nous limiterons aux transfers de fichiers plus classiques (c-à-d server->client).

Et pis ma job dans tout ça?

J’agis comme chef d’équipe et de coordonnateur. Certes, c’est pas très difficile de coordonner une équipe de deux personnes, moi inclus, mais c’est une autre chose de s’assurer que les fonctionalités sont prêtes en temps et que notre plan de projet est respecté et sera respectable selon les délais déjà définis.

De plus, depuis le début, j’ai consacré mon temps à l’exploration de technologies possibles utilisables pour le projet. L’objectif est d’utiliser quelque chose de simple et de portable sans nous mettre des batons dans les roues d’ici à la fin du projet. Ensuite, j’ai consacré mes efforts sur le client VeHO. Chose qui continuera durant les prochaines semaines.

La suite?

Le projet en est encore à ses débuts, mais nous avons pas mal déterminé les technologies que nous allons utiliser comme fondation. Maintenant, nous devons construire par dessus.

L’interface utilisateur principale avance, mais est dépourvue de fonctionalités utiles. Le problème est que le serveur doit supporter ces fonctionalités d’abord avant qu’on puisse les implémenter dans le client.

Mais je vais arrêter de parler de ce qui n’existe pas encore et donnerai plus de détails concernant le client dans un autre billet.

Hah et j’oubliais, les sources du produit final (i.e. tel qu’on le remettra) seront disponibles ouvertement. À suivre.

Récemment, Libre.FM est apparu. Ce service se veut, essentiellement, être un Last.FM libre à tous points de vue. Or, j’ai eu idée d’étendre ses fonctionalités durant un projet s’échelonnant sur une session. Avec l’accord de mes coéquipiers, si le projet était pour être réalisé en équipe, nous pourrions donner au projet le fruit de nos efforts.

L’idée de « scrobbler»  les chansons jouant sur notre ordinateur n’est pas nouvelle. J’ai donc élaboré une idée qui pourrait faire office de preuve de concept et qui, plus tard, pourrait être mise en application si le concept se veut réalisable et intrinsèquement viable.

Le but serait de coupler le service à plusieurs autres systèmes :

Le premier gros morceau comporte d’abord un module d’analyse sonore. Le but serait d’analyser des chansons afin d’en extraire un maximum d’informations : le tempo, la sonorité, etc. Ensuite, un système de classification utiliserait ces données afin d’essayer de classifier automatiquement les chansons dans différentes classes (je sais, l’apprentissage risque d’être ardu). Une fois ces données receuillies, l’utilisateur pourrait demander la génération automatique d’une liste d’écoute (playlist, si vous préférez) selon certains critères. Par exemple, un tempo élévé et tout ce qui touche de près ou de loin à du hard rock. La transition entre les chansons devrait se passer relativement en douce (donc pas de techno au pop en passant par du métal). Cette liste d’écoute pourrait alors être sauvegardée au format XSPF ou pls afin d’être enregistrée sur son baladeur.

Le deuxième gros morceau rejoint une philosophie plus importante. La base de données d’une instance devra contenir les chansons disponibles sur des services de partages de musique libre de téléchargement. Je pense nottament à Jamendo dont j’ai déjà fait mention ici. Les chansons auraient été pré-analysées et catégorisées automatique et par l’aide des utilisateurs. Parce que leur musique est disponible gratuitement, l’idée d’analyser les chansons devient possible.

Ensuite, reste à joindre les deux morceaux ensemble : rendre la musique disponible en écoute sur des serveurs de diffusion électronique (je pense à IceCast comme serveur) dont les listes d’écoute auront été générées automatiquement. Et c’est ici que la preuve de concept apparait : si le tout se veut efficace et que les utilisateurs sont intéressés, l’intégration de publicité non-intrusive pourrait permettre un certain revenu qui serait distribué aux musiciens durant un période donnée. Je suis conscient que ce n’est pas un moyen de faire vivre tous les artistes et que l’argent de la publicité généré par les serveurs d’écoute ne serait pas vraiment important. Surtout compte-tenu des frais de bande passante, de maintenance, etc. Au moins, le service pourrait vivre et faire découvrir la musique aux utilisateurs.

De plus, les utilisateurs pourraient voter et donner leurs opinions. Autant sur les artistes qu’ils écoutent que sur la qualité du service.

C’est donc l’idée préliminaire d’un projet que je voudrais, et aurait du plaisir à, développer. Qu’en pensez-vous?

Toujours par un dimanche après-midi à ne pas savoir par où commencer dans mes tâches, j’ai décidé de suivre l’exemple de ma semaine dernière et de faire du duct-tape ! La mallette étant déjà faite et très fonctionnelle, j’étais tanné de la trainer dans mes bras tout le temps perdant ainsi son usage. Une lanière (ou courroie, comme vous voulez, mais je l’appelle lanière), j’ai donc confectionné. Voici le résultat final :

Pour réaliser mon but, j’ai dû tricher un peu. Comme je voulais une lanière ajustable, j’ai dû utiliser des morceaux de plastiques que j’ai récupéré ailleurs. Pratique de ne pas toujours tout jeter. Ensuite, le principe est plutôt simple : faire une boucle autour d’un morceau de plastique servant à faire un bout.

Puis, répéter l’opération, mais avec le morceau qui fait office de « bloqueur»  (celui qui sert à bloquer l’ajustement de la lanière) sans oublier l’autre morceaux de plastique et de passer la courroie dans le premier morceau de plastique. Voici le résultat, vous allez peut-être mieux comprendre :

Ensuite, il faut joindre les 2 bouts de la lanière à la mallette. Pour ça, il faut de petits bouts de duct-tape qui deviendront des boucles. Entrez ces bouts de duct-tape dans les anneaux de plastique, puis dans les incisions dans la mallette préalablement réalisées. Repliez les bouts de duct-tape sur eux-mêmes pour compléter les boucles. Résultats :

Statistiques de réalisation :
• Temps de confection : aucun
• Temps de réalisation : ±30 min.
• Matériel : 3m de duct-tape et 3 morceaux de plastiques que vous avez déjà

Et voilà quelqu’un d’heureux arborant fièrement sa réalisation :

Certains d’entre vous on déjà vu mon porte-feuille en duct-tape que j’ai fait il y a déjà très longtemps par un dimanche après-midi. Ayant encore un dimanche après-midi à ne pas savoir par où commencer (dimanche passé en fait) et ayant encore du duct-tape à la traine, j’ai décidé de me faire une mallette pour mon portable… entièrement faite de duct-tape. Et le résultat est pas mal !

Biensûr, je n’ai pas terminée la mallette, puisqu’elle ne contient que très peu d’espace de rangement et de fonctionnalités, mais ça va venir ! Assez parlé, je vous montre :

Alors voilà, la malette a moins d’un pouces chaque côté du portable de libre, donc il ne bouge pas trop, 2 pochettes à CD/DVD pouvant en contenir un minimum de 2 (je n’ai pas essayé d’en mettre plus).

Spécifications sur le projet :
• Matériel : Duct-tape seulement
• Quantité : 1 rouleau
• Temps de confection : aucune confection, ça venait au fur et à mesure que je construisais la mallette
• Temps de fabrication : ± 1h15

Planification :
• Ajout de plus d’espace de rangement à l’intérieur
• Ajout d’une pochette à l’avant
• Ajout d’une courroie pour le transport
• Trouver une forme de rembourage

Laissez vos commentaires / suggestions !