Tweekers' Blog

Aller au contenu | Aller au menu | Aller à la recherche

Balise - Développement

Fil des billets

AH ! Un menu indispensable pour les webmasters

Ou comment écrire un programme utile en 100 lignes de Python. AH pour Apache Helper et non Apache Helicopter est un menu et permettant de réaliser les opérations les plus courantes sur ses sites web. Le programme utilise AppIndicator ce qui fait qu'il sera directement utilisable sur une distribution récente telle que Lucid Lynx. Je laisse la migration du programme vers un plus classique gtk.StatusIcon comme exercice pour le lecteur ;)

ah Voici a quoi ressemble AH, il dispose des fonctionnalités suivantes :

  • édition de son fichier /etc/hosts
  • redémarrer Apache
  • changer le propriétaire de tous les fichiers servis par Apache à l'utilisateur www-data
  • ouvrir le répertoire d'un site dans son navigateur de fichiers
  • ouvrir un site dans son navigateur web
  • inspecter les logs d'erreur
  • nettoyer les logs d'erreur
  • éditer le fichier de configuration du vhost


Il y a quelques prérequis afin de profiter pleinement de cette application. Vous devez disposer du script permsite qui va modifier la permission des fichiers. Si ce n'est pas déjà fait, ajoutez vous au groupe www-data. Il faut aussi changer le chemin vers ce script qui est pour l'instant codé en dur dans l'application (os.system("xterm /home/strider/bin/permsite")).
Vous pouvez télécharger ah et apprécier le gain de temps pour l'administration de votre serveur de développement :)

Le programme étant sous GPL V3, vous devez évidemment me faire par des améliorations que vous apporterez au programme. Si vous n'avez pas les compétences requises en Python pour améliorer vous même le script, laissez une demande de fonctionnalité dans les commentaire et si elle est pertinente, je me ferai une joie de l'implémenter :)

Tweekers : le réseau social Open Source - 1: Cahier des charges

Ce billet est la continuation directe du précédent ( Comment aider la communauté du Libre ? ) où j'exposais l'idée un site communautaire pour faciliter le développement des logiciels Open Source.
J'ai eu plusieurs commentaires encourageants qui ont confirmé que l'idée valait la peine qu'on s'y penche dessus. Aujourdh'ui marque donc la première étape de développement qui est la publication de la première version du cahier des charges.

Télécharger le cahier des charges (format ODF, 10 pages)

Ce projet est aussi l'occasion de tester un autre modèle de développement, que je n'ai pas vraiment eu l'occasion de rencontrer parmi les logiciels Open Source : Tout est rendu public avant même que la moindre ligne de code soit écrite. On saute l'étape Cathédrale et on passe directement au Bazaar. Je ne met pas tout mes espoirs dans cette méthode de développement, mais je pense qu'elle peut être une solution envisageable pour concevoir des projets de taille conséquentes.
Cette méthode de développement aura au moins l'avantage de rendre les documents d'élaboration du projet public (cahier des charges, maquettes, schéma de BDD...), contraremenent à ce que j'avais critiqué par le passé en disant que la disponibilité du code source seul n'était pas suffisant pour encourager les contributeurs a participer.
Rien qu'en exposant l'idée de base dans le précédent billet, j'ai eu des commentaires qui ont mis le doigt sur des points importants sur lesquels je ne m'était pas attardé et j'espère que la publication du cahier des charges permettra a tout le monde d'exprimer ses idées sur le développement du projet.

Et maintenant ?


Une feuille de route préliminaire figure a la fin du document, la prochaine étape est la publication de maquettes d'écrans prévue pour prévue ce vendredi. Je prendrais en considération toutes les participations. Et pas besoin d'être un expert d'Inkscape pour apporter sa contribution, une maquette griffonée sur un vieux bout de papier peut aussi bien faire l'affaire. (Et si vous n'avez pas de scanner, un appareil photo est bien suffisant). Ce n'est pas un concours de design, le but est uniquement de structurer les pages de l'application.

Vos avis m'intéressent


Vous pouvez me faire part de vos remarques sur les commentaires de ce blog, ou en utilisant mon adresse mail / jabber : strycore@gmail.com . J'ai reçu plusieurs propositions pour aider au développement dans les commentaires du billet précédent, sachez juste que vous n'avez pas besoin de compétences de développement a ce stade de l'application et donc que la contribution est ouverte a tout le monde.

Comment aider la communauté du Libre ?

J'étais sur le point d'écrire un long billet sur ce que je perçois comme un problème majeur dans la communauté du Logiciel Libre. Sur le fait que de nombreuses personnes sont la uniquement par la haine du logiciel propriétaire, non pas par amour du libre; sur la passivité de certains membres qui ont pourtant un potentiel plus qu'intéressant; sur la mauvaise image qui est donnée au logiciel libre a cause de quelques membres zélés; sur l'hermétisme de la contribution et du développement et ainsi de suite...
Et puis non, ça n'avance a rien mis a part gagner des ennemis et insulter des gens qui ont pourraient être de précieux atouts dans l'avancée du libre.
Cela n'empèche pas que je trouve la situation presque désespérée, que je serai presque tenté de quitter définitivement cette communauté s'il y avait quelque part une meilleure alternative.
Malgré la souffrance provoquée par la pollution du Libre, je garde toujours un certain espoir de voir les choses s'améliorer si quelques personnes arrivent a canaliser les trolleurs et autres beaux parleurs pour les pousser vers quelque chose de plus constructif.
J'ai demandé la suppression de mon compte sur les forums d'Ubuntu-fr tout en étant parfaitement conscient que cela n'arrangerais rien au problème, c'est juste histoire de dire : "Je ne veux pas être associé avec ces quelques personnes qui sont en train de détruire ce que j'aime".

Dénoncer le problème ne le résoudra pas, ce qu'il faut c'est trouver des solutions qui feront que le problème n'aura plus aucune raison d'exister. Pour cela il faut prendre plusieurs choses en considération :

  • Le Logiciel Libre n'est pas en danger, il est la pour rester, et il est protégé par des licences extrêmement bien conçues. Je perçois toute personne qui tente de protéger le libre des "griffes" de Microsoft ou d'Adobe comme quelqu'un qui n'a pas confiance dans le Libre.
  • Les sociétés de logiciels propriétaires doivent être perçues comme des concurrents, pas comme des ennemis. La concurrence est quelque chose de sain et nécessaire a l'évolution (il peut aussi y avoir de la concurrence au sein du Logiciel Libre). La concurrence ne se fait pas avec des plaintes, ou des combats pseudo politico-philosophiques, mais en construisant des produits supérieurs. La philosophie du Libre est très bonne, j'y adhère complètement, mais un logiciel est un produit technique, pas une réligion , tout ce qu'on lui demande c'est de bien faire son travail.
  • Dans beaucoup de cas, on ne se préoccupe pas assez de la liberté N°1 : celle d'étudier le programme, je dirais même que cette liberté est bafouée a l'heure actuelle. Tout logiciel libre (même un projet énorme) doit être accessible a toute personne voulant s'y intéresser. Malheureusement les logiciels libres sont trop souvent maintenus par une équipe définie (ou une seule personne dans beaucoup de cas) et les contributions, ou même la simple compréhension d'un projet est très difficile d'accès.
  • Les systèmes d'exploitation libres ne sont pas encore prêt pour le grand public, il y a encore de nombreux points ou l'ergonomie mérite d'être améliorée. Certains disent "Linux ça se mérite, il faut apprendre et ne pas être assisté", je réponds à cela : "Ayez au moins la bonne foi d'avouer que vos programmes sont mal conçus, c'est le but premier d'un ordinateur que d'assister un humain". Lorsque nous demandons a un utilisateur non informaticien de taper des commandes dans un terminal, c'est une insulte faite aux systèmes GNU/Linux modernes et montre l'incapacité de la communauté à produire de bons scripts et des interfaces intuitives.
  • Les innovations faites dans le milieu du logiciel propriétaire doivent être suivies de prêt. Si le Logiciel Libre surpasse le propriétaire dans de nombreux domaines (pour les serveurs notamment), il reste a la traine dans bien d'autres notamment l'audio, la vidéo, le jeu vidéo, etc...
  • Certaines avancées logicielles présentes dans le domaine propriétaire sont totalement hors de portée pour des développeurs seuls, ou même une petite équipe. On avance souvent l'argument que les projets ambitieux sont le fruits de grosses sociétés avec beaucoup de moyens financiers mais je ne croit pas que ce soit le point crucial a la réussite de ces projets. Ce qui permet de mener a terme ces projets, c'est la structure fournie par une grosse société. La communauté du libre pourrait représenter une formidable force de travail, mais il manque quelques éléments fédérateurs, des outils permettant une meilleure gestion. Ne jamais oublier qu'un projet, aussi gros soit il est le fruit de plusieurs êtres humains, les membres de la communauté du libre n'ont aucune raison d'être moins doués. Aujourd'hui pour concevoir un logiciel digne de ce nom, travailler seul n'est plus une option.


Si tout ces éléments sont pris en considération, alors le Logiciel Libre et sa communauté cesseront d'être la risée du monde propriétaire, et sera perçu comme un concurrent a part entière. Pour l'instant, 1% de part de marché dans le domaine du desktop reste insignifiant pour être considéré avec sérieux.

Proposition de réseau social

Comme certain ont pu le remarquer, ce blog est une annexe du site que j'ai débuté il y a quelques années et qui n'a jamais vraiment décollé: Tweekers. J'ai poussé le vice jusqu'a donner comme sous titre "Plateforme de conception et d'architecture logicielle collaborative" alors que depuis le début je suis l'unique contributeur au site. Le site est plus ou moins a l'abandon et j'y poste de temps a autre quelques trucs et astuces concernant la programmation et l'administration. J'ai ajouté il y a peu de temps une section Documentation qui vise a répertorier et classifier les nombreuses documentations de projets libres mais c'est à peu prêt tout ce qu'il y a de nouveau sur ce site (Il me semble même que les inscriptions sont impossibles suite a l'ajout d'un antispam expérimental, personne n'a relevé le problème c'est dire le succès énorme du site).
Pourtant des le départ, le but était clair : a chaque problème sa solution, et le but du site était de la trouver, qu'il s'agisse d'une simple option de configuration sur Apache jusqu'a la conception entière d'une application.
J'ai utilisé ce site comme excuse pour apprendre le PHP et j'ai parfaitement conscience qu'il est buggé, que son code est à jeter a la poubelle, il n'en reste pas moins que l'idée de départ est toujours bonne et doit être gardée.
Il faudrait reconstruire ce site mais en mettant en avant le coté social du site. Il est hors de question de refaire un outil existant, surtout après la libération du code de Launchpad, qui est a mes yeux, la meilleure forge existante. Tweekers ne doit pas être une forge, ni un wiki, ni un forum, mais un réseau social axé sur l'étude de code et la conception de projets. Ce réseau social doit permettre de regrouper les personnes par domaine d'intérêts et de compétences.
Pour donner quelques exemples :

  • Peter a un concept génial pour un nouveau jeu vidéo, il publie l'idée sur son profil, 10 personnes sont intéressées. Steven a quelques connaissances de SDL propose de contribuer et d'écrire des tutoriaux, Hugues trouve que ce projet est l'occasion pour apprendre l'OpenGL, Georges cherchais a faire de nouvelles créations sur Blender, José a déja écrit un jeu vidéo et propose de réutiliser des morceaux de code de sa création, etc...
  • Jaqueline en a assez d'un bug très irritant qui n'a pas été résolu depuis des années. Le bug est répertorié sur Launchpad mais le programme est plus ou moins maintenu. Elle fait par du problème sur son profil. Dave est un autre utilisateur du programme et propose une analyse du code, il trouve le fichier qui pose problème mais n'a pas les connaissances pour résoudre le bug. Georges est un pro du C++ mais n'a pas beaucoup de temps a passer sur ce bug, mais cela tombe bien, on lui met devant les yeux la partie du programme a corriger, quelques minutes plus tard il soumet un patch (qui est automatiquement posté sur Launchpad). Dino applique le patch sur les sources, compile et construit un paquet qu'il publie sur son PPA.


Comme je l'ai bien fait comprendre, je ne comptes pas me lancer dans la refonte de ce projet tout seul, je cherche des personnes qui pensent que ce projet peut aboutir a un résultat intéressant. Pour information je compte développer le site avec le framework Symfony, probablement avec l'ORM Doctrine (je suis au beau milieu de mon autoformation a Symfony et j'ai commencé avec Propel, toutefois Doctrine semble être plus utilisé), et la librairie jQuery . Le site sera dans déplacé chez TuxFamily dans un premier temps (n'oubliez pas d'apporter votre soutien financier a TuxFamily !). A partir du moment ou j'aurais quelques volontaires, je mettrai a disposition le plus vite possible une première version du cahier des charges et pourrais organiser une réunion sur Jabber. Je précise qu'aucune connaissance n'est exigée tant que vous êtes motivés pour apprendre.

Quel avenir pour la video en ligne ?

La video en ligne est un domaine ou beaucoup de travail reste a faire. D'une part parce que ce moyen a de bonnes chances, à terme, de remplacer la télévision, et d'autre part parce que la situation actuelle est complètement absurde.
La suprématie de Flash a poussé de nombreux utilisateurs de logiciels libres a complètement tourner le dos a la vidéo en ligne, ce qui semble montrer qu'il y a un réel problème. Un utilisateur de logiciel libre ayant refusé d'installer le player Flash est tout autant, sinon encore plus, victime du coté propriétaire de ce format puisqu'il se voit interdit de 95% de la video en ligne. Certes il existe des solutions libres (gnash et swfdec) mais elles ne sont actuellement pas a la hauteur du logiciel d'Adobe et techniquement elles ne sont pas meilleures.
En 2009,soit plus de 15 ans après les premières video MPEG en plein écran, visionner une vidéo de qualité médiocre sur 1/8 de l'écran occupe entre 25% et 50% du temps de calcul d'un processeur moderne, voila où on en est arrivé...
Sur une machine plus modeste (le XO Laptop par exemple), visionner une video Flash dans le navigateur est juste impossible. Le format flv utilisé n'est pas en cause, celui est lisible par les lecteurs videos standards (totem, mplayer, vlc) sans aucun problème. C'est bien la lecture dans le navigateur qui pose un problème.
J'ai mis beaucoup d'espoirs dans le tag <video> implémenté dans le futur Firefox 3.5, afin de développer une alternative libre aux plateformes d'échange video, un peu comme ce que propose http://tinyvid.tv/ mais déployable sur n'importe quelle serveur aussi simplement qu'un Dotclear. Actuellement, j'ai principalement travaillé sur la récupération de video au format Flash via des scripts Python, ce qui n'est pas très compliqué mis a part pour le nouveau protocole rtmp qui pose énormément de problèmes. (Le même protocole utilisé pour débats de l'assemblée nationale).
La conversion dans un autre format, ne pose pas de problèmes non plus, donc il ne reste plus qu'a écrire l'interface Web pour regrouper tout cela. Mais avant de me lancer dans l'écriture de ce projet, j'ai bien évidemment voulu tester ce qui allait être la base de mon application : le tag <video>. J'ai malheureusement très vite déchanté, le support de la video par la beta de Firefox 3.1 est désastreux, avec une occupation du processeur allant de 50 à 70% sur un dual core (une charge partagée entre Firefox et Xorg sur GNU/Linux et limitée a Firefox sur Windows XP). Sur le XO Laptop, la lecture d'un ogg sur Firefox 3.1b3 occupe 100% du CPU avec un framerate d'environ 0.5 image par seconde ... Le bug est bien entendu connu comme on peut le constater sur le bugtracker de Mozilla ici ou ici. La question que je me pose actuellement est celle de savoir si je dois persévérer dans la conception de mon application avec l'espoir que le bug soit résolu pour la version finale de Firefox 3.5 (ce dont je doute) ou alors m'orienter vers d'autres solutions.
Je peux en effet me rediriger vers une solution utilisant le bon vieux tag <embed> qui n'a jamais posé de problèmes (puisque que ce sont des plugins qui vont s'occuper de la lecture et non le navigateur) ou encore, laisser tomber l'application en ligne pour uune application de bureau, comme ce que propose Miro mais avec la gestion de tous les principaux sites de streaming (youtube, dailymotion, wat.tv, videojug,etc ...). D'ailleurs mes essais sur ce domaine sont plutôt concluants, avec un programme qui permet de récupérer les video de Canal+. Capture-Canal_Plus_Ripper.png Ce script python est disponible ici et peut être démarré en exécutant openvish_gui.py (il faut patienter au démarrage pour la récupération des "chaines").
La vidéo sur le net, a encore beaucoup de chemin a faire avant de trouver une solution satisfaite pour l'utilisateur et tout espoir repose entièrement sur le logiciel libre étant donné la médiocrité proposée par le logiciel propriétaire (protocole RTMP, sites de VOD fonctionnant avec IE et WMP, etc...). Je relève aussi avec une certaine déception l'inutilité de nombreux détracteurs de Flash qui ont beau cracher sur les solutions existantes, n'apportent absolument rien comme solution libre. Si vous appréciez tant Richard Stallman, sachez que celui ci n'a pas formaté son système Unix propriétaire alors qu'il était en train de développer son système GNU !

Lancement de Open Source Developer Network

Dans le précédent billet, j'exposais certaines difficultés que le développeur novice peut avoir lors d'une première approche dans le monde du logiciel libre.
Une des difficultés est de savoir ou trouver la documentation, car si l'on me dit RTFM je répondrais : WFP ? (Which F**king Paragraph ?).
L'autre rengaine courante est GIYF (Google Is Your Friend), et bien pas vraiment a vrai dire. Google est surtout très fort pour indexer tous les forums, toutes les mailings list, tous les blogs et s'il est facile de trouver des personnes qui ont le même problème que celui posé, il l'est déjà moins de trouver la bonne réponse.
Voila où OSDN (déformation du nom d'un célèbre site de documentation, d'un éditeur logiciel pas très apprécié dans les parages) rentre en jeu.
OSDN, ce n'est rien de bien compliqué techniquement : Un peu de HTML, et d'Ajax mais c'est surtout un travail de recherche et de classification. Cette page vise a regrouper toutes les pages de documentation de tous les langages et toutes les technologies Open Source. Oui, rien que ça... et la page n'a même pas un jour qu'elle commence déjà à être assez fournie.
La page comporte un moteur de recherche qui ira chercher uniquement sur le site en cours de consultation. (ou sur google.com/linux si aucune documentation n'est affichée)
Bien entendu je suis ouvert a toutes les suggestions, n'hésitez pas a m'envoyer dans les commentaires ou par mailavec le formulaire dédié les liens vers les documentations que vous jugez essentielles. Et ne soyez pas limités aux documentations officielles non plus, un bon tutoriel peut avoir sa place.
Aussi, si vous jugez l'organisation de l'arborescence inappropriée a certains endroits, n'hésitez pas a le signaler.
J'espère que cette page Web sera aussi utile pour vous qu'elle l'est déjà pour moi ;)

Des difficultés de la participation aux logiciels libres

L'idée de ce billet m'est venu a la suite de celui de xbright intitulé La difficulté d'exister pour les petits projets de logiciel libre ou son auteur met en avant le manque de contributeurs sur les petits projets Open Source. Hormis le fait d'écrire des rapport de bugs, je n'ai jamais réellement codé pour un projet libre existant, donc j'ai voulu tenter l'expérience en prenant comme projet Bluemindo, le player audio de xbright écrit en Python.
Récupérer un projet et se lancer dans l'analyse de son code source est une tâche très intimidante au premier abord, il faut consacrer un certain temps afin d'apprivoiser les sources, tester le programme, repérer quelle fonction fait quoi, visualiser l'architecture du logiciel. Toutes ces tâches n'existent pas lorsque l'on est le créateur d'un projet puisque l'on est parti de zéro pour arriver au résultat que l'on a en tête.
Il faut dire que les développeurs ne facilitent pas toujours la vie de ceux qui passent derrière. Les difficultés sont multiples : manque de commentaires dans le code, noms de variable peu explicites, identifiants des widgets du fichier Glade laissé avec leur valeurs par défaut (button1, progressbar3, .....).
Un code source ouvert se doit avant tout d'être clair et lisible. Eric S. Raymond évoque ce problème dans le livre "The cathedral and the bazaar" en disant que la clarté du code est plus importante que sa vitesse d'exécution. De mon point de vue, un nom de variable composé d'une seule lettre est toujours un mauvais nom de variable. C'est une perversion venue du monde obscur des mathématiques et qui n'a rien a faire dans la programmation. Les éditeurs de code source modernes supportent tous l'autocomplétion des noms de variable, donc il n'y a aucune raison pour ne pas utiliser des noms explicites qu'ils fassent 15 caractères ou plus.
Une fois que l'on a parcouru une bonne partie du code source de l'application, on commence a saisir le fonctionnement global, et on peut s'attaquer a l'écriture de code... Ouhla, pas si vite ... Ne perdez pas une seule minute a écrire la moindre ligne de code avant d'avoir obtenu l'accord de l'auteur. Open Source ne veux pas dire que c'est la fête et que chacun écrit ce qu'il veut dans un projet, ne contribuez pas avant d'avoir la bénédiction du "benevolent dictator for life", il m'est arrivé de soumettre des patchs qui n'ont pas été accepté et pour plusieurs raisons : l'auteur avait déjà codé la modification de son propre coté ou l'auteur a refusé l'intégration du patch. Ici, on voit la deuxième difficulté : le développeur principal, n'a de comptes a rendre a personne et il ne va pas précéder chaque patch de son cru par un rapport de bug sur sa forge.
J'ai beau avoir trainé dans le monde de l'open source quelques années, avoir quelques bonnes bases en programmation, j'ai toujours l'impression qu'il manque quelque chose d'essentiel afin se saisir complètement le mode de développement du logiciel libre. Les sources sont libres, oui très bien, mais est ce suffisant ? L'exemple de Rhythmbox nous prouve que non, Dans son billet Cyrille Borne exprime ses doutes quand a la viabilité d'un projet Open Source :

Il me semblait pourtant que l'un des intérêts de l'ouverture du code, c'était qu'en cas d'arrêt d'un développeur, un autre apparaît pour prendre la relève. Un système auquel je n'ai jamais cru, tant il est difficile dans le cas de l'écriture d'un code de repasser derrière, si bien que les gens préfèrent créer leur propre application.

Dans les commentaires de ce même billet, RunningTracker cerne très bien le problème :

il est (très) difficile de reprendre un logiciel développé par quelqu'un d'autre. C'est là où la documentation prend tout son sens. Une bonne documentation (avec schémas UML, explication des algos... etc) et un code bien commenté (ce qui est très rare...) facilitent grandement la compréhension et la reprise du code. Je pense qu'en tant que développeurs, nous devrions passer plus de temps sur ces deux aspects (même si c'est parfois rébarbatif).

Dans la communauté, personne ne pense a reprendre le développement de Rhythmbox, et on réfléchi déjà a son successeur. Je peux comprendre : s'il a déjà été compliqué de se plonger au coeur de Bluemindo qui est un projet jeune et écrit en Python, je n'imagine même pas quels efforts il est nécessaire de faire pour comprendre le fonctionnement de Rhythmbox qui est plus mature et codé en C.
La page concernant le développement de Rhythmbox ressemble plus a une mauvaise blague avec ses liens vers SVN et IRC. Avec ces deux éléments, il va être difficile d'aller très loin ...
Maintenant voila ce que je propose :
Utiliser Internet pour ce a quoi il a été construit a la base: permettre a des chercheurs de travailler ensemble. Partager les sources n'est pas suffisant, il faut aussi avoir un système collaboratif permettant d'étudier, d'analyser un projet libre. Il manque un outil qui aide a la compréhension de la programmation, parce qu'il y a un fossé qui est en train de se créer entre les programmeurs vétérans et les novices. Pour reprendre les concepts de Eric Raymond, les plans de la cathédrale doivent être rendus public et le bazaar doit être ordonné.
Il est aussi important a mes yeux d'avoir une documentation centrale, une mère de toutes les documentations, avec tous les langages, toutes les librairies, tous les outils de développement, avec en bonus des tutoriels et des exemples. En quelque sorte l'équivalent de MSDN pour le logiciel libre.
Une grande partie de la communauté reste bloquée dans le test de différentes distributions, la compilation de logiciels, et les rapports de bug. C'est bien mais j'ai envie que les choses aillent plus loin, et pour cela il faut que la marche qui sépare le simple utilisateur du réel contributeur soit plus simple a gravir.