Gauret

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.

Le bouddhiste serait-il agile ?

Aurélien — Sat, 25 Jun 2011 14:02:00 +0200

Non, il ne s’agit pas de disserter sur la souplesse des moines Shaolin… Voici un article de plus dans ma petite série reliant le bouddhisme à la culture occidentale contemporaine. Cette fois ci je vais essayer de faire un lien entre deux domaines qui m’intéressent au plus haut point : le bouddhisme et l’informatique.

Pour le public non-geek, il faut savoir que les méthodes organisationnelles utilisées pour développer du logiciel sont en pleine évolution depuis quelques années, avec l’arrivée de ce qu’on appelle les “méthodes agiles”. Petite introduction, les experts (dont je ne fais pas partie) voudront bien me pardonner les approximations.

Jusqu’à la fin des années 90 (et même un peu plus tard), les méthodes de développement informatiques étaient calquées sur les méthodes d’ingénierie classiques du monde matériel. Quand on veut construire un bâtiment, on demande d’abord à des architectes, qui vont passer un certain temps à écouter leur client et à définir des plans précis de ce qu’il faut construire. Quand les calculs et la rédaction sont terminés, la réalisation est confiée à des ouvriers, qui vont alors passer la majeure partie du temps du projet à construire le bâtiment.

“Antique-Architects-Folding-Rule-02D1208_1-2400” par Garrett Wade

Le monde de l’informatique étant relativement jeune à l’époque, on s’est inspiré de ce qui marchait bien ailleurs, et on a suivi la même organisation : un architecte logiciel traduit les besoins exprimés par le client en un document qu’on appelle “spécifications”, qui décrit quelles fonctionnalités le logiciel aura, et comment il fonctionnera. Ensuite, ce document est transmis à une équipe de développeurs qui va programmer le logiciel.

Au bout de plusieurs années, on s’est finalement rendu compte que ça ne fonctionnait pas, parce que le monde du logiciel est très différent du monde matériel, notamment en terme de temps nécessaire pour les différentes étapes, et en terme de vitesse d’évolution des besoins des clients. On s’est rendu compte que les besoins des clients évoluaient trop vite par rapport au temps nécessaire à la production du document de spécifications. Si vous êtes intéressé par les détails de cette comparaison, voici l’excellent article d’origine, que j’encourage tout professionnel de l’informatique à lire.

Pour en revenir à notre sujet, les informaticiens ont commis une erreur de jeunesse : ils ont essayé de figer dans le marbre quelque chose qui est intrinsèquement changeant : le besoin du client. Devant cet échec, ils ont inventé d’autres méthodes, appelées méthodes “agiles”, dont l’objectif n’est pas de bloquer le changement mais de s’y adapter (démos, itérations courtes, backlog, etc.). Ces méthodes sont très généralement reconnues comme une avancée positive, une évolution de la maturité de l’informatique en général : en reconnaissant que le changement est inévitable et en cherchant à s’y adapter, on est mieux en phase avec la réalité.

“Bhutan: Prayer Bubbles” par babasteve

Et c’est là que je vais faire le pont (voire le viaduc) avec le bouddhisme. Pour le bouddhisme, l’égo est une erreur d’interprétation de la réalité : l’Homme aime la stabilité, donc il se construit mentalement une sorte de “personne” qu’il considère comme ayant une existence propre, alors qu’en fait il n’en est rien : nous ne sommes que l’accumulation de nos expériences, de nos décisions, et de notre flux de conscience. Tout change, et tout est inter-dépendant.

Selon le bouddhisme, ou du moins ce que j’en ai compris, ce qu’on appelle “moi” ou “égo” n’a pas de réalité en soi, ce n’est qu’une convention. Quand on nomme un fleuve “Amazone” ou “Gange”, il s’agit d’une convention, il n’y a rien de concret et de stable dans ce fleuve (même son lit varie en permanence). C’est pour cela que le bouddhisme dit que l’égo est une imposture qu’il faut démasquer, une inadéquation avec la réalité.

De la même façon que l’informaticien cherchait à produire un document de spécification stable, fixe, en ignorant le fait qu’au fur et à mesure de sa rédaction il divergeait de plus en plus de la réalité, nous nous sommes mis dans la tête qu’il existe un “moi” ou un “égo” stable, fixe, et qui correspond à notre identité. Dans les deux cas, c’est une dissonance avec la réalité qui cause beaucoup de souffrances : l’informaticien refuse ou proteste de manière véhémente quand on le force à reconnaître que les besoins du client ont changé et qu’il faut modifier sa spécification, et l’humain se sent vexé voire insulté quand on met en lumière l’écart entre son égo et la réalité.

Les méthodes agiles, comme le bouddhisme, proposent de reconnaître que le changement est inévitable et qu’il vaut mieux savoir s’y adapter, plutôt que de s’accrocher à une stabilité éphémère et illusoire. C’est un progrès dans ce que le bouddhisme appelle la connaissance, c’est à dire tout simplement l’adéquation avec la réalité. On peut aussi parler de maturité. À la différence bien sûr que le bouddhisme travaille sur quelque chose de beaucoup plus fondamental que la gestion de projet informatique : l’esprit humain.

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.

Le plus gros pollueur de la planète

Aurélien — Tue, 21 Dec 2010 12:00:00 +0100

On dit un peu partout que la Chine a très récemment dépassé les États Unis sur le podium des pays les plus émetteurs de gaz à effet de serre, et a donc décroché la triste première place. Je voudrais faire part d’un commentaire que j’ai entendu récemment de la part d’un économiste^[1], et que je trouve très intéressant.

On sait tous que la Chine est devenue « l’usine du monde », c’est là qu’est concentrée la production manufacturière de la planète (ainsi que dans quelques pays voisins). Donc voilà : si moi, européen, je décide de m’acheter un ordinateur portable dernier cri qui sera fabriqué en Chine, à quel pays doit-on imputer les émissions associées ? Actuellement, elles seront imputées à la Chine, mais est-ce juste ?

De mon point de vue, puisque c’est moi qui ai commandé le produit, je porte la responsabilité des émissions liées à sa fabrication. On va bien sûr me rétorquer que les moyens de production choisis par la Chine (électricité au charbon, quasi-absence de normes anti-pollution, rejets toxiques etc.) ne sont pas sous mon contrôle, et que je n’y peux donc rien. Mais selon moi c’est faux : je peux influer sur la façon dont la Chine produit les marchandises, tout simplement en achetant ailleurs ! En faisant jouer le « marché » finalement. Si j’achète un produit fait par exemple en Suisse, en Norvège ou — horreur ! — en France, je sais que l’énergie électrique est assez peu émettrice de CO2, que les normes environnementales existent et sont appliquées, sans même parler des émissions liées au transport^[2].

Si on considère donc que c’est celui qui commande le produit qui est responsable de ses émissions, les États Unis sont encore loin devant la Chine, et nous, l’Europe, ne sommes pas mal placés non plus dans cette course vers le mur.

Je n’ai pourtant pas d’affinité particulière avec la Chine^[3], mais il faut reconnaître que cette fois on les accuse à tort, et qu’il faudrait commencer par balayer devant notre porte.

Notes :

[1] dont je ne retrouve plus le nom malheureusement, honte à moi

[2] et quelques autres “détails” comme : un salaire minimum pour les employés, une sécurité sociale, des horaires décents, quelques congés de temps en temps, … mais ce n’est pas le sujet ici, aussi vaste et important soit-il

[3] Tibet, droits de l’Homme, démocratie, environnement, etc… la liste est longue

Égollum

Aurélien — Sun, 12 Dec 2010 09:00:00 +0100

Je continue dans ma série des comparaisons anachroniques entre les idées bouddhistes et la culture contemporaine. C’est idiot mais je trouve ça marrant

En y réfléchissant, il me semble que l’égo est à la conscience ce que Gollum est à Sméagol (dans Le Seigneur des Anneaux bien sûr) : on est tentés de faire appel à lui pour passer des caps difficiles, attirés par le sentiment de sécurité et de puissance qu’il apporte, sans se rendre compte que le remède est pire que le mal.

Il me semble essentiel de bien distinguer la confiance en soi (en ses capacités en tant qu’être humain), et la croyance en l’égo, qui apparaît plus stable, plus facile et plus rassurant, mais qui est en fait bien plus fragile lorsqu’il est mis à l’épreuve de la réalité.

Gollum n’a jamais réussi à s’en libérer. Le pourrons-nous ?

Si j'étais président de l'Europe

Aurélien — Sun, 05 Dec 2010 15:36:00 +0100

Je suis tombé sur un petit jeu en Flash par la BBC qui propose de se mettre dans la peau du président de l’Europe entre 1990 et 2100. L’objectif étant d’éviter le changement climatique tout en gardant un continent prospère et en restant populaire.

Chaque tour dure 10 ans, et on choisit les politiques à mener dans 5 secteurs principaux. Chaque politique influence les ressources financières, l’énergie, la nourriture, l’eau et le rejet de gaz à effet de serre. Il y a aussi des négociations internationales pour décider les autres pays à prendre des engagements sur le climat.

Bref, un petit jeu sans prétentions mais assez rigolo, que je vous encourage à essayer. Mes scores : 96% en écologie, 27% en économie, et 50% en popularité (au bout du 3ème essai quand même ).

Merci à Cédric pour le lien. Dans le même esprit : Clim City.

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.