Gauret - Mot-clé - libre

Mais c'est quoi l'ESS ?

Aurélien — Fri, 09 Sep 2011 14:50:00 +0200

On parle beaucoup d’Économie Sociale et Solidaire, mais finalement savez-vous ce que c’est ? La page Wikipedia donne une courte définition, mais le novice que je suis ne sait pas toujours où elle commence et où elle s’arrête.

Heureusement, une amie geekette travaille dans ce domaine, et a publié un article très clair sur le sujet. Merci Antoinette !

J’en profite pour lui faire un peu de pub, puisqu’elle travaille en tant qu’indépendante dans la sociologie des organisations : c’est quelqu’un de tout à fait équilibré, suffisamment geek pour comprendre une conversation d’informaticiens (et c’est pas toujours facile avec nous ;-)), mais aussi suffisamment persévérante pour détricoter les problèmes relationnels qui freinent les entreprises et les associations. Voilà, la pub s’arrête là, si vous êtes intéressés voici son site.

Pour en revenir à l’économie sociale et solidaire, son lien avec les logiciels libres en terme de valeurs partagées n’est plus à démontrer. Là aussi de très bons articles ont été écrits sur le sujet, je vous recommande cet article de Framasoft et un article de la SCIL qui détaillent bien le sujet. On voit aussi que les associations de ces deux mondes commencent à se rapprocher, notamment avec la création de l’AI2L.

Il semble clair aujourd’hui qu’il y a là un vaste terrain d’entente, et que nous avons beaucoup à apprendre les uns des autres pour faire avancer nos causes communes. Affaire à suivre, et de près.

XHTML2ODT sort en version 1.3

Aurélien — Sat, 16 Jul 2011 15:11:00 +0200

Après environ 1 an de développements épisodiques, voici une nouvelle version de la bibliothèque XHTML 2 ODT, permettant de convertir du HTML bien formé en ODT, le format standard de bureautique.

Parmi les nouveautés, des améliorations de conversion de certaines balises (dl et span par exemple), des améliorations dans la gestion des images, l’ajout de paquets RPM et Deb, et la gestion du HTML généré par Lyx et Elyxer.

En ce qui concerne le packaging, des paquets RPM et Deb sont générés par le OpenSuSE Build Service, qui est un outil vraiment très intéressant quand on cible plusieurs distributions. Pour cette version, j’ai aussi créé un feed Zero Install. Zero Install est une méthode d’installation d’applications qui vient en parallèle du système natif de la distribution (mais qui s’intègre avec). C’est très utile pour des applications qui sont mis à jour très fréquemment, comme Firefox par exemple, ou pour distribuer une application sous une forme indépendante de la distribution. Je vous laisse creuser le sujet si ça vous intéresse, mais c’est un ensemble d’outils qui mériteraient d’être plus connus.

Rendez-vous sur le site du projet xhtml2odt ou directement sur la page de téléchargement pour récupérer la dernière version de la bibliothèque.

Comment écrire du code testable

Aurélien — Sun, 03 Apr 2011 20:55:00 +0200

Je vous propose les diapositives d’une présentation que j’ai réalisée récemment, concernant les méthodes de développement permettant d’écrire un code facilement testable.

Il y a quelques semaines, j’ai visionné la présentation de Miško Hevery chez Google à ce sujet, et j’ai tout de suite été conquis par sa clarté et son pragmatisme. Avec son accord, j’ai entrepris de la traduire et de l’adapter en français.

Mon objectif était avant tout de garder une présentation généraliste (indépendante du langage de programmation, du framework ou du projet), et de pouvoir l’utiliser dans le cadre de mon travail pour essayer de diffuser les bonnes habitudes de la testabilité auprès de mes collègues.

J’ai finalement eu l’occasion de donner cette présentation sur mon lieu de travail, qui s’est très bien passée, mais dont l’enregistrement n’est malheureusement pas diffusable. Quoi qu’il en soit, j’ai pu tester “en conditions réelles” la qualité des diapos et l’importance des concepts présentés par Miško.

Si le sujet vous intéresse, j’attache à ce billet le fichier ODP^[1] de la présentation. Les points à aborder oralement sont dans la section “notes” de chaque diapo, pensez-donc à la lire. De plus, certaines diapos utilisent des animations, il est donc préférable de lire la présentation en mode “diaporama”.

Quand j’ai demandé à Miško si je pouvais réutiliser ses diapos, il n’a demandé qu’une citation de son nom. Dans le même esprit, je place donc cette présentation sous licence Creative Commons Attribution (BY), c’est à dire que vous pouvez la réutiliser comme bon vous semble à condition de citer le nom des auteurs (Miško et moi).

Pour pouvoir comprendre et suivre cette présentation, il faut connaître au minimum les concepts suivants :

Programmation Orientée Objet
Quelques design patterns courants (Factory et Singleton)
Tests unitaires

Les sujets abordés au cours de la présentation sont :

Le développement piloté par les tests (ou Test-driven development)
L’injection de dépendances
La loi de Déméter
La théorie des bugs (par Miško)

Les exemples de codes utilisés dans la présentation sont en Python, parce que c’est le langage que je maîtrise le mieux et celui avec lequel je travaille au quotidien, mais les concepts sont applicables à n’importe quel autre langage. De plus, un des principaux exemples de code est disponible aussi en Java, pour ceux qui préfèrent.

La présentation dure environ une heure. Si vous décidez de réutiliser ces diapos, vous n’êtes évidemment pas obligés de m’en faire part, mais j’aimerais bien si possible avoir des retours pour les améliorer et intégrer les meilleures remarques.

“Comment écrire du code testable” au format ODP
Une version lisible dans le navigateur web (nouvelle fenêtre), grâce à un procédé qui fera l’objet d’un prochain billet…

J’espère que ces diapos pourront vous aider à diffuser la “bonne parole” de la testabilité aussi largement que possible !

Notes :

[1] S’ouvre avec LibreOffice ou OpenOffice.

De l'action sur le front de la conversion ODT

Aurélien — Fri, 13 Aug 2010 21:34:00 +0200

L’été s’est révélé très fructueux pour mes différents projets logiciels autour du format ODT. Voici un petit tour d’horizon des dernières nouveautés.

Dokuwiki

J’ai publié une nouvelle version de mon plugin d’export ODT pour Dokuwiki. Le changement principal est la prise en compte de la coloration syntaxique fournie par Dokuwiki. Vous pouvez voir un exemple de ce que ça donne sur cette page de mon wiki. Les couleurs du wiki et celles du document ODT ne sont pas exactement les mêmes, c’est normal :

C’est une fonctionnalité qu’on m’avait déjà demandé par le passé, et il s’est avéré que ce n’était pas si compliqué que ça à réaliser, principalement grâce au fait que la syntaxe CSS et la syntaxe des styles dans ODT XML sont très similaires. Ça c’est un format bien conçu, chapeau.

La nouvelle version du plugin est disponible en téléchargement depuis la page officielle du plugin ou directement chez moi. Vérifiez la signature GPG si vous le voulez/pouvez.

XHTML2ODT

Mon projet principal autour du format ODT est clairement XHTML2ODT, le convertisseur XHTML vers ODT (comme son nom l’indique ). Au début de la semaine, j’ai publié la version 1.0, ce qui est toujours une étape importante dans un projet logiciel. Le code qui la constitue a servi de fondation à deux plugins d’export depuis plusieurs mois maintenant, et est très largement couvert par plus d’une centaine de tests unitaires.

J’ai profité des jours suivants dans la semaine pour avancer le développement du projet sur certaines fonctionnalités qui semblaient intéressantes. Dans la même veine que pour le plugin Dokuwiki, j’ai ajouté la prise en compte de la coloration syntaxique fournie par deux moteurs : Pygments (en Python) et GeSHi (en PHP). Tout n’est pas encore parfaitement géré, mais le fonctionnement de la coloration syntaxique pour GeSHi ouvre peut-être la voie à une gestion plus large des styles CSS inclus directement dans le code HTML, par le biais de la balise <style> (c’est ainsi que GeSHi procède).

Enfin, GeSHi a aussi une fonctionnalité amusante : il peut numéroter les lignes du code. Cette fonctionnalité est aussi prise en compte et conservée lors de la conversion en ODT.

Tout ce nouveau code a été publié dans la version 1.1 de XHTML2ODT, que vous pourrez trouver sur la page de téléchargement. Au passage, j’en ai profité pour corriger un petit bug dans la conversion des espaces en mode préformaté, et pour ajouter un petit script de conversion en bash. Le but n’est pas de l’amener au même niveau de fonctionnalités que ses cousins Python et PHP, mais de montrer simplement comment mettre en œuvre les feuilles XSL.

Enfin, autre changement non technique mais non moins important : la licence s’est assouplie. J’ai passé le code de GPL v2 ou plus à LGPL v2 ou plus. Concrètement, cela signifie que si vous insérer le code dans une autre application, et que vous la distribuez, vous n’avez plus besoin de mettre votre application sous GPL. La seule contrainte restante est de publier les changements que vous avez fait sur le code XHTML2ODT lui-même, si vous en avez fait. C’est tout, rien d’autre.

Dernière petite nouvelle, j’ai écrit un article de quatre pages pour le magazine (papier !) Programmez! au sujet d’XHTML2ODT, il devrait sortir à la rentrée. Je vous tiendrai au courant, ça va de soi

Export ODT pour Trac

J’ai publié une nouvelle version du plugin d’export Trac, pour profiter des évolutions de la bibliothèque principale en ce qui concerne la coloration syntaxique. Vous pouvez voir le résultat en vous rendant sur la page WikiProcessing (fournie par défaut dans Trac) et en cliquant tout en bas sur le lien “OpenDocument”. Ou plus directement, en cliquant ici. Tada ! Le petit bout de code en C au milieu de la page est colorisé.

Dans cette nouvelle version, j’ai aussi tiré parti du système d’ajout de styles proposé maintenant directement dans XHTML2ODT, ce qui simplifie grandement le plugin. Si vous voulez faire un plugin d’export ODT pour une appli en Python, le plugin Trac peut être une bonne source d’inspiration.

Export ODT pour Dotclear

Là aussi, j’ai publié une nouvelle version du plugin d’export Dotclear pour profiter des avancées de la bibliothèque. Dotclear ne fait pas de coloration syntaxique par défaut, mais il existe un plugin pour cela, qui s’appelle syntaxehl, et qui utilise GeSHi en dessous. Le plugin peut fonctionner avec ou sans numérotation des lignes, les deux modes sont traduits en ODT.

Pour que ce soit plus parlant, voici un exemple de ce qui est produit par le plugin SyntaxeHL :

/* Commentaire */
class syntaxeHl
{   
 
    public static function registerFunc($wiki2xhtml)

    {   
        $dir = dirname(__FILE__).'/geshi/geshi/';
        $od = opendir($dir);

        while($f = readdir($od))
        {   
            if(is_file($dir.$f) && substr($f,-4,4)=='.php')

            {   
                $lang = str_replace('.php','',$f);
                $wiki2xhtml->registerFunction('macro:['.$lang.']',array('syntaxeHl','parse'));

            }
        }
    }
 
    public static function parse($text,$args)

    {   
        global $core;
        $settings = $core->blog->settings->syntaxehl;

 
        $text = trim($text);
        $args = preg_replace("/^(\[(.*)\]$)/","$2",$args);

        $geshi = new GeSHi($text,$args);
 
        if(!$settings->get('syntaxehl_enable_klink'))  $geshi->enable_keyword_links(false);

        if($settings->get('syntaxehl_enable_linenum')) $geshi->enable_line_numbers(GESHI_NORMAL_LINE_NUMBERS);
        //if($settings->get('syntaxehl_enable_css_classes')) $geshi->enable_classes();

        $geshi->enable_classes();

Et maintenant, avec la numérotation des lignes :

/* Commentaire */
class syntaxeHl
{   
 
    public static function registerFunc($wiki2xhtml)
    {   
        $dir = dirname(__FILE__).'/geshi/geshi/';
        $od = opendir($dir);
        while($f = readdir($od))
        {   
            if(is_file($dir.$f) && substr($f,-4,4)=='.php')
            {   
                $lang = str_replace('.php','',$f);
                $wiki2xhtml->registerFunction('macro:['.$lang.']',array('syntaxeHl','parse'));
            }
        }
    }
 
    public static function parse($text,$args)
    {   
        global $core;
        $settings = $core->blog->settings->syntaxehl;
 
        $text = trim($text);
        $args = preg_replace("/^(\[(.*)\]$)/","$2",$args);
        $geshi = new GeSHi($text,$args);
 
        if(!$settings->get('syntaxehl_enable_klink'))  $geshi->enable_keyword_links(false);
        if($settings->get('syntaxehl_enable_linenum')) $geshi->enable_line_numbers(GESHI_NORMAL_LINE_NUMBERS);
        //if($settings->get('syntaxehl_enable_css_classes')) $geshi->enable_classes();
        $geshi->enable_classes();

Pour voir ce que cela donne en ODT, il vous suffit d’exporter ce billet de blog (le bouton est en haut à droite). Sympathique, non ?

Enfin, comme pour le plugin Trac, j’en ai profité pour déléguer l’ajout des styles à XHTML2ODT lui-même, ce qui simplifie grandement le code. Si vous cherchez à faire un plugin d’export ODT en PHP, le plugin d’export Dotclear est un bon candidat pour chercher l’inspiration.

Vous pouvez télécharger et installer le plugin depuis sa page sur DotAddict.

Flattr

Ça fait plusieurs semaines que j’entends parler de Flattr, ce nouveau service qui veut révolutionner le micro-paiement. Tuxicoman y a même consacré un article assez élogieux. En deux mots, la différence par rapport à PayPal, c’est qu’on affecte avant toute chose un “budget”, c’est à dire une somme fixe d’argent, qui sera distribuée entre les différentes choses pour lesquelles vous aurez cliqué sur le bouton “Flattr”. Son concernés bien évidemment les logiciels (libres ou pas), mais aussi la musique, les vidéos, les écrits, et autres.

À la fin du mois, votre budget mensuel est donc réparti, et si vous n’avez cliqué sur rien il est distribué à des organisation caritatives. Le budget minimum est de deux euros, c’est donc pas la mort. Si vous ne remplissez plus votre compte, il est désactivé temporairement bien sûr.

Le fait d’affecter un budget mensuel fixe, qui partira de toute façon, est à mon avis ce qui fait toute la différence. J’ai décider de me créer un compte pour voir ce que ça donne à l’usage, et pour soutenir les projets qui me plaisent. Bien sûr, j’en ai profité pour enregistrer les projets dont je suis l’auteur, mais que ce soit clair : je ne m’attends pas à rouler sur l’or du jour au lendemain Toutefois, si mes quelques bouts de code vous plaisent et que vous avez un compte sur Flattr, vous trouverez tous les liens sur mon profil. Les projets de conversion ODT ci-dessus sont normalement tous enregistrés.

À vous les studios

Voilà pour le flash nouveautés concernant mes projets de conversion ODT, j’espère que ces nouvelles versions vous plairont. N’hésitez pas à remonter les bugs sur les trackers associés, que vous pourrez trouve à partir de ma page d’index.

Bon, OK, certaines personnes pourraient objecter qu’il y aurait de meilleures façons de passer ses vacances.

Une plate-forme pour mes développements

Aurélien — Sun, 25 Jul 2010 19:22:00 +0200

Un bon gros weekend de geek. Mais il fallait le faire, ça commençait à trop tarder, avec les petits plugins que j’éparpille un peu partout, et les quelques développements que je réalise, il était temps que je mette en place une plate-forme pour assurer la maintenance de tout cela. Mon choix s’est porté sur Trac, voici pourquoi.

Mais pourquoi, au fait ?

J’avais installé un wiki sur mon site il y a quelques mois, pour noter tout ce qui n’a pas la même durée de vie qu’un article de blog. Et j’ai pris aussi l’habitude de développer avec Git, en hébergeant le code source chez Gitorious.

Gitorious est un très bon hébergeur de code source, basé sur Git donc, avec une interface assez jolie et ergonomique. Il est sous licence AGPL contrairement à son concurrent le plus direct, GitHub, qui est propriétaire. Vu mon penchant pour le logiciel libre, je me suis naturellement orienté vers Gitorious. Il a toutefois un défaut important : il n’y a pas de gestionnaire de tickets. C’est prévu, mais pour l’instant ils en sont à la conception, puisqu’ils voudraient mettre en place un système vraiment décentralisé et communiquant. On pourrait ainsi référencer et suivre les tickets ouverts sur d’autres instances de Gitorious.

C’est bien beau, mais pour l’instant ça veut dire que je dois trouver un autre moyen pour gérer les tickets des logiciels que je développe et auxquels je contribue. Ce n’est pas bien grave, il y a de nombreuses options en logiciel libre, donc j’ai cherché celle qui me conviendrait le mieux. Parmi mes contraintes, il y a :

être en développement actif
être relativement simple et facile à manipuler, je n’ai pas envie de noyer des rapporteurs de bugs potentiels
la possibilité d’utiliser OpenID. Je n’ai pas envie de forcer les rapporteurs de bugs à ouvrir un n^ième compte à usage unique. En plus, grâce à OpenID, je déporte la problématique de gestion du spam sur le fournisseur OpenID, ce qui m’arrange pas mal.
la possibilité de personnaliser sommairement l’interface, pour l’adapter au thème du reste du site.

Voici le résultat des courses (à mettre bien entendu en regard de mon besoin, qui n’est pas forcément celui de tout le monde).

La gestion de ticket en logiciel libre

Tout d’abord, j’ai cherché ce qui m’imposerait un minimum de dépendances. Sachant que mon espace web fonctionne très majoritairement en PHP/PostgreSQL, j’ai cherché des gestionnaires de tickets sur les mêmes technos.

Flyspray

Flyspray est un gestionnaire de tickets léger en PHP. Il a l’air pas mal du tout, mais son activité de développement semble relativement faible, et il n’a pas encore OpenID, donc j’ai laissé tomber.

Mantis

Attention, gros poids lourd. Mantis est un gestionnaire de tickets très puissant, mais qui échoue sans réserves au point n°2. Peut-être que ce sera un outils parfait pour quelqu’un dont c’est le métier, qui va rester toute la journée devant et apprendre à le maîtriser, mais pour moi et le quidam moyen qui ouvrira des tickets chez moi, c’est trop compliqué.

InDefero

Ça c’est très intéressant. InDefero est un petit dernier qui se veut être un clone de Google Code en PHP. Il a l’air vraiment très bien, mais pour l’instant il ne gère pas OpenID. Dommage, tout le reste avait l’air très bien.

Bon, ne voyant rien sortir en PHP/PostgreSQL, j’ai décidé de relâcher la contrainte PHP, et d’aller regarder ce qui se fait dans les autres langages.

Bugzilla

Je connais pas mal, vu que c’est ce qui est installé chez Fedora. Trop complexe à utiliser, trop complexe à installer, et trop gourmand en ressources.

Redmine

Là, on a du très lourd. Redmine est un gestionnaire de projets écrit en Ruby, qui fait exactement tout ce que je veux, et même plus. Le mec cool qui m’héberge a en plus déjà installé un Redmine sur le serveur, mais vu que mes réglages sont assez différents (accès à tout le monde), il faudra que je m’installe une autre instance. A priori pas un problème.

Trac

Trac, je connais déjà. C’est un très bon gestionnaire de projets, simple et efficace, écrit en Python (donc un plus pour moi), et pour lequel j’ai déjà écrit plusieurs plugins. Lui aussi, il fait tout ce que je veux.

Redmine ou Trac

Les deux finalistes sont donc Redmine et Trac. Je me suis dit que c’était l’occasion d’essayer Redmine, donc j’ai essayé de comprendre comment c’était installé sur la machine. Et bien, je dois dire que je n’ai pas compris. C’est manifestement installé dans Apache avec Passenger, mais à part ça je n’ai rien réussi à recoller. En plus j’ai essayé de ne pas toucher aux fichiers pour éviter de casser quoi que ce soit, ce qui fait qu’au bout d’une demi-heure de farfouillages et de recherches sur le net, j’ai perdu la motivation. Ça marche, mais je ne comprends pas pourquoi, et ça j’aime pas tellement.

Donc bon, je me suis rabattu sur le bon vieux Trac que je connais bien maintenant. Finalement, le fait qu’il soit écrit en Python fait que je peux mieux le maîtriser, et écrire des plugins si nécessaire, plugins qui pourront peut-être servir à d’autres.

Comme j’ai plusieurs projets indépendants, je vais faire gérer plusieurs “environnements” à la même instance de Trac, ce qui économisera la mémoire. Cela se fait assez facilement grâce à la fonctionnalité correspondante de Trac, c’est à dire --env-parent-dir pour tracd ou la variable d’environnement TRAC_ENV_PARENT_DIR dans mod_wsgi (que j’utilise). Toutes les instructions sont sur le site de Trac.

Adaptations

Alors, reprenons le besoin : mon code est hébergé chez Gitorious, il ne me faut donc qu’un gestionnaire de tickets. Comme Trac fournit un wiki, je vais m’en servir à la place de celui de Gitorious, pour pouvoir référencer les tickets d’incidents, et profiter des possibilités d’adaptation graphique de Trac. Par contre, Trac fournit aussi un gestionnaire de code source, et ça je n’en ai pas besoin.

Le navigateur de sources

Et oui, si mon code est hébergé chez Gitorious, ça serait bizarre de se servir de l’explorateur de code de Trac. J’ai donc cherché plusieurs solutions pour remplacer le navigateur de Trac par un lien vers Gitorious, mais rien ne s’est révélé très satisfaisant. En plus de ça, la syntaxe wiki de Trac permet de référencer un fichier dans l’arborescence des sources, avec un lien du type [source:monfichier.ext]. Dans le meilleur des mondes, ces liens arriveraient directement dans Gitorious, sur le bon fichier, et même à la bonne ligne.

J’allais quand même pas rater une occasion d’améliorer le monde, non ? Donc j’ai fait un plugin Gitorious pour Trac qui fait exactement ça : il remplace le lien du navigateur de sources par un lien vers Gitorious (il faut configurer le nom du projet cible), et intercepte tous les liens vers les sources en les réécrivant pour pointer vers le navigateur de Gitorious. Si vous êtes dans le même cas que moi, n’hésitez pas à vous servir de mon plugin.

Il y a des fonctionnalités de Trac qui n’existent pas chez Gitorious, je n’ai donc pas tout remplacé, mais c’est déjà assez sympa.

Autres plugins

Trac dispose d’un plugin pour l’authentification par OpenID, donc y’a qu’à installer. Il me fallait aussi évidemment le plugin Git, histoire que mes modifications apparaissent dans la timeline. Et j’en ai bien sûr profité pour installer mon plugin d’export ODT. Enfin, j’ai installé le plugin TranslatedPages pour faciliter la traduction des pages du wiki.

La quantité de plugins disponible pour Trac est vraiment phénoménale, on trouve tout ce qu’on veut !

Graphisme

Je n’allais pas quand même laisser les visiteurs et les rapporteurs de bugs avec une rétine intacte, c’est pas le genre de la maison. J’ai donc modifié le template de Trac par défaut pour que mon espace de développement soit aussi moche que le reste de mon site. La cohérence, c’est important. Les instructions se trouvent sur le site de Trac, avec quelques exemples pour les cas classiques (ajouter une CSS, etc.).

Le langage de templates utilisé par Trac est Genshi, c’est très proche du XML/XSL, ça me rappelle le langage TAL de Zope, donc c’est marrant. En plus je commence à bien le connaître puisque je l’utilise au boulot.

J’ai aussi modifié la page qui sert d’index aux projets. Là aussi, les instructions sont déjà toutes prêtes sur le site de Trac. Je vous laisse ~~souffrir~~ admirer.

Téléchargements

Il existe plusieurs moyens de proposer un espace de téléchargement de fichiers dans Trac. On peut tout simplement faire un lien vers un répertoire d’Apache. On peut ajouter un lien dans la barre de navigation principale pour pointer vers ce répertoire. On peut aussi attacher les fichiers à une page du wiki, mais ce n’est pas ce qu’il y a de plus pratique. Et évidemment, il y a trois plugins différents pour gérer un véritable espace de téléchargement (Trac : there’s a plugin for it).

Mais moi je voulais quelque chose d’un peu différent : je voulais pouvoir générer automatiquement des archives de la branche de développement toutes les nuits, je voulais pouvoir signer les publications, etc. J’ai donc opté pour un dossier dans Apache, qui est rempli par un script externe. Ce script tourne toutes les nuits et créée deux archives (tar.gz et zip) pour chaque tag de chaque projet, ainsi que deux archives de la branche de développement. Il en profite pour générer un bel index, et un flux Atom. C’est pas très compliqué, il y a peut-être 50 lignes de shell, donc pour l’instant je ne le publie pas sauf si quelqu’un se déclare intéressé. La génération du flux Atom est laissée à un autre script que j’ai écrit.

Conclusion

Je dispose maintenant d’une bonne plateforme d’hébergement de code, simple, bien intégrée avec Gitorious, extensible, automatisée, et surtout que je connaît bien.

Si jamais je décide de pousser l’auto-hébergement plus loin et de me passer de Gitorious, Trac est tout à fait à même de répondre au besoin. Je ne tire pas un trait sur Redmine pour autant, peut-être qu’un jour j’aurais l’occasion de l’utiliser activement. En attendant, le fait que je sois capable d’écrire des plugins pour Trac est quand même un facteur de poids dans la balance.

Si vous voulez plus de détails sur l’implémentation de tout ça, n’hésitez pas à me contacter (mais c’est pas très sorcier au final).

Des scripts divers et variés

Aurélien — Fri, 14 May 2010 11:20:00 +0200

J’ai (enfin) fait une page pour décrire les quelques scripts que j’ai fait et qui pourraient servir à d’autres. Pour faciliter la lecture des utilisateurs de flux RSS et pour éviter un clic aux autres, je vais tout recopier dans ce billet, mais la page de référence est sur mon wiki.

J’ai écrit un certain nombre de scripts pour me faciliter la vie de tous les jours. Et oui, comme tout bon informaticien, je suis prêt à passer 8 heures à peaufiner un script qui me fera gagner 30 secondes tous les mois… Mais bon, là n’est pas la question.

Mes scripts

Il se trouve que je pense que certains de ces scripts pourraient être utiles à d’autres, donc dans le plus pur esprit du Logiciel Libre, je les met à disposition sur cet espace de développement. Tous ces scripts sont sous licence GPL v3. Voici une petite présentation.

backup-delicious.py

Un simple script pour sauvegarder ses signets stockés sur delicious.com dans un fichier XML, au cas où Delicious aurait un problème (site cassé, perte de données, politique commerciale à la con, revente de Yahoo, etc.).

birthdaysfromvcard.py

Le script créé un fichier iCalendar avec les anniversaires des gens trouvés dans un fichier vCard (vcf).

Très pratique pour ne plus oublier les anniversaires des ses connaissances (voire de sa famille…)

files2feed.py

Le script créé un ficher Atom XML (équivalent RSS) à partir des derniers fichiers modifiés ou ajoutés dans un répertoire et ses sous-répertoires.

Cas d’utilisation : je partage mes fichiers par le web, et j’aimerais bien proposer un flux RSS pour les mises à jour et les nouveaux fichiers partagés (ici c’est un flux Atom, mais c’est le même principe).

make-songs-list.py

Le script créé un PDF à partir des chansons disponibles pour Performous, un excellent jeu de karaoké.

Il utilise la pochette de l’album si elle est dispo, et essaye d’en mettre un maximum sur le minimum de pages, pour qu’il n’y ait plus qu’à imprimer et à distribuer aux joueurs.

podcast-transcode.py

Cas d’utilisation : je dispose d’un lecteur de vidéos portable que j’utilise dans les transports en commun, mais il n’est pas assez puissant pour décoder les vidéos d’aujourd’hui (résolutions assez élevées, codecs gourmands, etc.) Il faut donc que je convertisse et que je redimensionne les vidéos des podcasts auxquels je suis abonné.

Fonctionnement : le script prend en entrée un flux RSS, et convertit toutes les vidéos incluses en attachement au format AVI/DivX/MP3, en les redimensionnant à la taille demandée. Une fois la conversion effectuée, la balise d’attachement est mise à jour pour pointer sur l’adresse de la vidéo convertie.

Pour les vidéos de TED, le script peut même ajouter les sous-titres s’ils sont dispo, et si le script tedtalksubs.py est installé (c’est à dire dans le PATH). C’est un autre de mes scripts, téléchargeable au même endroit (enfin, dans ce cas-là, dire “de mes scripts” est un peu fort, puisque j’ai quasiment tout pompé sur un autre).

Le script tedtalksubs.py est indépendant, il permet de lister, télécharger et convertir au format SRT les sous-titres des vidéos de TED.

rss-mirror.py

Cas d’utilisation : quand je tombe sur une page web intéressante mais que je n’ai pas le temps de lire là tout de suite, je la sauvegarde dans Instapaper. Le service me fournit ensuite un flux RSS des pages en attente de lecture. Pour utiliser au mieux le temps que je passe dans les transports en commun, j’aimerais y lire ces pages, mais je n’ai pas d’abonnement internet mobile. Par contre, j’ai un lecteur portable qui dispose d’un navigateur web.

Fonctionnement : le script prend un ou plusieurs flux RSS en entrée, et fait un miroir local de toutes les entrées en utilisant wget ou httrack. Le niveau de profondeur des liens récupérés est configurable, mais par défaut il ne prend que la page indiquée, pas les liens trouvés sur cette page. Il créé ensuite un index des pages téléchargées en utilisant le fabuleux iUI.

Le répertoire de téléchargement peut ensuite être synchronisé sur un lecteur portable, qui n’a alors besoin que d’un navigateur web. Dans mon cas, je l’utilise avec Instapaper, mais n’importe quel flux RSS peut être utilisé. Par exemple, des signets sur Delicious, les favoris de Tiny Tiny RSS ou Google Reader, etc.).

C’est en quelque sorte le lecteur de flux hors-ligne du pauvre

Conclusion

Voilà, si vous avez des commentaires, des remarques, ou des propositions d’amélioration à faire sur ces scripts, n’hésitez pas. Une petite description est disponible en en-tête de chacun d’eux, et vous pouvez les lancer avec --help pour connaître les options disponibles. Ils nécessitent tous au moins python 2.5, les autres dépendances étant spécifiques à chacun des scripts.

XHTML2ODT est annoncé sur LinuxFR

Aurélien — Mon, 12 Apr 2010 08:08:00 +0200

Pour essayer de faire connaître XHTML2ODT, j’ai écrit un article sur LinuxFR qui en fait la promotion, ou du moins qui annonce à tout le monde que ça existe. Oui oui, écrire un article sur LinuxFR, c’est parler au monde. Rien que ça

Je rappelle brièvement de quoi il s’agit : XHTML2ODT a pour objectif de convertir une page web (HTML) en document ODT, éditable ensuite par tous les traitements de texte qui utilisent ce format, notamment OpenOffice. Pour ce faire, il s’appuie sur un document OpenOffice “modèle”, dans lequel on peut définir les styles que l’on veut.

Comme il n’y a pas de gestionnaire de bugs pour l’instant, vous pouvez éventuellement utiliser les commentaires de cet article pour ça. Mais bon, il faudrait que j’en installe un quand même, ce serait plus propre. Je pencherais bien pour un Trac, mais maintenant faut voir si mon gentil hébergeur sera d’accord…

Mise à jour : Finalement j’ai fait un site dédié pour XHTML2ODT, avec Trac. Le code reste hébergé par Gitorious pour l’instant.

Nouveau plugin pour Dotclear : notes de bas de page

Aurélien — Fri, 26 Feb 2010 22:14:00 +0100

Quand on écrit un billet avec Dotclear, on dispose de deux modes : le mode “wiki” ou le mode “xhtml”.

En mode wiki, on dispose d’une syntaxe codifiée et simplifiée, mais il faut apprendre cette syntaxe, et ce qui est affiché à l’écran est très différent de ce qui sera affiché sur le site ensuite. Il y a quelques temps, je préférais ce mode de rédaction (c’est plus rigolo ), mais c’est moins facile d’accès pour les débutants, et après tout, on ne fait pas des programmes que pour les informaticiens.

Le second mode affiche le texte dans la zone d’édition avec le formatage qu’il aura à l’affichage final, un peu comme votre traitement de texte préféré^[1]. En plus, et c’est important pour moi, il y a un onglet “source” qui permet de voir le XHTML généré, et éventuellement de faire des retouches, ou d’ajouter des blocs de code.

Mais voilà, le mode wiki a beaucoup plus de fonctionnalités que ce qui est repris dans la barre de formatage du mode xhtml. Notamment, il y en a une que j’aime bien utiliser : les notes de bas de page^[2]. En mode wiki, on entoure la note par des symboles “$$”, et Dotclear génère automatiquement l’appel de note, la note de bas de page, et les liens entre les deux. C’est très pratique, je voulais retrouver cette possibilité en mode xhtml.

J’ai donc fait un plugin pour Dotclear qui ajoute un bouton à la barre de formatage, et qui génère les appels de note, la zone de notes de bas de page, les liens entre les notes, tout en s’occupant d’incrémenter le numéro de note à chaque fois. Le plugin s’appelle footnotesToolbar, et il est disponible sur le lab Dotclear. Si vous pensez qu’il peut vous être utile, n’hésitez pas à le télécharger et à me donner votre avis !

Bonne rédaction

Mise à jour : j’ai aussi ajouté un bout de code pour lui faire afficher les notes de bas de page au survol de l’appel de notes. C’est une très bonne idée que j’ai piquée à Dokuwiki, sur conseil d’antistress (voir commentaires ci-dessous).

Notes :

[1] par exemple OpenOffice.org.

[2] c’est ça