Posts Tagged ‘Python’

Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile

dimanche, août 14th, 2011

La bureautique est la principale utilisation de l’informatique depuis sa création. Pourtant, les outils majoritairement utilisés dans ce domaine, les logiciels de traitement de texte WYSIWYG comme LibreOffice et OpenOffice, laissent la majorité des informaticiens et des ergonomes très dubitatifs, voire totalement désespérés.

Ces logiciels ont en effet un nombre de défauts très important : ils font se concentrer sur la forme et non sur le fond, leur résultat final ne correspond souvent pas à ce qui est affiché, ils sont incompatibles entre eux, ce sont d’énormes usines à gaz inutilisables sur de vieilles machines, ils ne fonctionnent qu’en mode graphique, etc. La seule manière rationnelle, efficace et interopérable de travailler sur un ordinateur est d’utiliser de simples fichiers textes, tous les documents étant donc modifiable dans n’importe quel éditeur de texte.

Il a donc fallu penser à une manière de donner ces instructions de mise en forme au sein du fichier texte lui-même, et c’est ainsi que sont apparus les langages de balisage (markup), dont les plus connus sont HTML (inventé en 1991 par Tim Berners-Lee) et LaTeX (créé en 1985, et basé sur TeX, inventé par le grand Donald Knuth en 1977), et dont la première grande figure fut Roff, un programme Unix historique développé à partir de 1961, et dont la version GNU, Groff, est installée par défaut sur toutes les distributions Linux, puisqu’on l’utilise encore pour les pages de man des logiciels.

Pour mieux visualiser, prenons comme exemple la création d’une nouvelle section d’un document en man :

.SH Nouvelle section en man

en HTML :

<h1>Nouvelle section en HTML</h1>

et en LaTeX :

\section{Nouvelle section en LaTeX}

Ces langages représentent une nette amélioration, mais ont tous un gros problème : ils sont gênants ! On ne retrouve plus aussi facilement son contenu au milieu de toutes ces balises supplémentaires, sans parler du fait que les syntaxes complexes ouvrent la voie à de nombreuses erreurs de compilation.

C’est en 1995 que l’on trouva la solution de ce problème, avec la création du premier langage Wiki, dont le but principal était de permettre l’édition facile de pages web par tout un chacun, et dont l’utilisateur actuel le plus célèbre est l’encyclopédie libre Wikipédia. S’il y a presque autant de syntaxes différentes que de logiciels Wiki, elles ont toutes la caractéristique d’utiliser des caractères textuels simples et intuitifs pour donner les indications de formatage du texte.

Toujours le même exemple, une nouvelle section en MediaWiki :

= Nouvelle section Wiki =

et une en Setext :

Nouvelle section Setext
=======================

Mais pourquoi limiter ces langages de balisage léger à la seule génération de HTML ? Pourquoi ne pas utiliser la même syntaxe pour différentes cibles (appelées backends, targets ou writers selon les logiciels), de manière à obtenir aussi bien une page web en HTML, qu’un document en LaTeX pour l’impression, ou qu’une page de man pour un logiciel ? Ce sont les logiciels qui poursuivent ce but qui m’intéressent, ils constituent pour moi l’avenir de la bureautique informatique, et j’ai été amené à les comparer pour en choisir un dans lequel m’investir comme développeur.

Voici un tableau comparatif des meilleurs logiciels libres existants, avec comme information supplémentaire l’existence d’une cible texte brut, puisque je souhaitais me baser sur ce code pour programmer certaines de mes idées ASCII art.

Les logiciels complets MAJ

NomLangage de programmationPopularité du projeti18nCible texte brutLicence
Txt2tagsPythonmoyenne + RedNotebookOui + docOuiGNU GPLv2 ou suivante
DocutilsPythonforte + SphinxNonNonDomaine public
AsciiDocPythonmoyenneNonDump de w3m ou de LynxGNU GPLv2 ou suivante
DeplateRubyfaibleNonOuiGNU GPLv2 ou suivante
PandocHaskellforteNonOuiGNU GPLv2 ou suivante
Stx2anySed et m4faibleNonDump de w3mLicence copyleftée personnalisée
AFTPerlfaibleNonNonClarified Artistic License
LunamarkLuafaibleNonNonMIT
JeromeErlangfaibleNonNonMIT
DoxiaJavaforteNonNonApache License 2.0
XWiki RenderingJavafaibleNonOuiGNU LGPLv2.1

Exceptés Docutils et AFT (Almost Free Text), tous les logiciels semblaient au premier abord proposer une cible texte. Mais en fait c’est un peu un trompe l’œil, car deux d’entre eux, AsciiDoc et Stx2any, se contentent de dumper un navigateur web en mode texte (w3m ou Lynx) du résultat généré par leur cible HTML. Il n’y avait donc pas dans ces cas de base de code que je pouvais espérer améliorer.

J’ai mis dans le comparatif stx2any et AFT codés respectivement en m4 et en Perl, de manière à proposer un large éventail de langages de programmation, mais ces logiciels sont à la fois moins utilisés et dotés de moins de fonctionnalités que les autres. En étudiant les différents logiciels disponibles, je me suis rendu compte que, par chance pour moi, beaucoup étaient codés en Python (3 sur 11 au total, mais surtout 3 sur les 5 vraiment intéressants). Ce n’est d’ailleurs pas la première fois que je constate, en cherchant à sélectionner des logiciels libres, que ceux codés en python sont à la fois les plus nombreux et les meilleurs.

Les cinq logiciels restants sont vraiment excellents, et constituent tous un bon choix. Trois d’entre eux, Docutils, Deplate et Pandoc, ont un design évolué, avec une machine à états finis pour laquelle on peut écrire de nouveaux readers et writers de manière parfaitement propre. Cependant, malgré leurs grandes qualités, Deplate est un projet trop confidentiel (ainsi il n’est incompréhensiblement pas présent parmi les pourtant si nombreux paquets Debian), et je ne me sentais pas à la hauteur pour m’investir dans un projet comme Pandoc, totalement écrit en Haskell, qui est un langage de programmation complexe que j’aimerais beaucoup utiliser, mais où ma compétence est encore trop limitée.

Il fallait donc que j’approfondisse ma réflexion sur les logiciels en Python :

Choix en Python

NomCibles principalesCible texte brut
Txt2tagsHTML, Latex et syntaxes WikiOui
DocutilsHTML et LatexNon
AsciiDocHTML et DocBookDump
MarkdownHTMLNon
TextileHTMLNon

J’ai rajouté dans ce comparatif Markdown et Textile, puisqu’ils ont chacun une implémentation en Python, mais ne générant que du HTML, ils ne m’intéressaient pas vraiment. AsciiDoc et Txt2tags ont un peu la même architecture, avec un gros fichier principal faisant tout le travail, que l’on peut configurer, respectivement avec un fichier .conf et deux dictionnaires Python (un pour les Tags et l’autre pour les Rules), pour créer de nouvelles cibles. AsciiDoc et Txt2tags sont donc plus aisés à prendre en main et à modifier rapidement que Docutils, qui est une très belle et très bien architecturée machine à états objet, mais aussi plus difficile à appréhender.

De plus, comme je désapprouvais totalement la politique de licence domaine publique de Docutils, il ne me restait plus qu’à faire mon choix entre Txt2tags et AsciiDoc. C’est principalement l’orientation très DocBook (un format ne m’intéressant personnellement pas du tout) d’AsciiDoc, et d’autres détails, comme la localisation en de nombreuses langues de Txt2tags et sa plus grande simplicité, qui m’ont finalement fait choisir Txt2tags.

Ce choix est confirmé par une étude plus avancée des différentes syntaxes. Ainsi alors que la syntaxe reST de Docutils ne dispose que de :

*italique* et **gras**

Txt2tags est beaucoup plus riche :

//italique// **gras** __souligné__ et --barré--

Le codage visuel est bien meilleur, et le compréhension instantanée avec la syntaxe de Txt2tags, puisque les slashs donnent l’impression penchée de l’italique, les étoiles imitent la surcharge du gras, les underscores donnent l’impression de soulignement, et les moins apparaissent comme une barre. De plus, l’utilisation généralisée des caractères de balisage en doubles, permet de lever à peu de frais un maximum d’ambiguïtés syntaxiques.

Par exemple une phrase aussi simple que celle contenue dans le fichier d’exemple de Txt2tags :

We use double *, /, - and _ to represent **bold**, //italic//, --strike-- and __underline__.

et qui ne pose aucun problème :

est en fait déjà trop ambigüe en reST, puisque :

We use double *, /, - and _ to represent **bold**, *italic*, strike and underline.

donnera :

De manière générale, la syntaxe reST est souvent trop lourde. Par exemple dans le cas de l’insertion d’une image servant de lien :

.. image:: picture.png
:target: http://fgallaire.flext.net

que l’on peut comparer avec le beaucoup plus simple Txt2tags :

[[picture.png] http://fgallaire.flext.net]

On remarque bien sûr ici que la syntaxe reST offre sûrement plein d’autres options que la simple :target:, et qu’elle est donc plus puissante que celle de Txt2tags. Cependant, mon avis est que la pénalité de lourdeur est toujours présente, alors qu’elle n’est utile que dans peut-être 1% des cas.

Voici maintenant un comparatif des logiciels disponibles par syntaxe :

Classement par syntaxe

UsageTxt2tagsAsciiDocreStructuredTextMarkdown
BureautiqueTxt2tags
Pandoc
AsciiDocDocutils
Pandoc
Pandoc
Web serveurTxt2tags (Python)
txt2tags-php (PHP)
AsciiDoc (Python)Docutils (Python)Le Markdown original de John Gruber (Perl)
python-markdown (Python)
BlueCloth (Ruby)
php-markdown (PHP)
erlmarkdown (Erlang)
XWiki Rendering (Java)
Le Sundown de GitHub (C)
Web client (JavaScript)txt2tags.jsmarked
Showdown
markdown-js

Leur implémentation en Python permet à Txt2tags, reST (par Docutils) et AsciiDoc d’être utilisables à la fois comme logiciels de bureautique multiplateforme (Linux, Mac OS X, Windows et *BSD) et pour le web côté serveur. Depuis 2012, une implémentation de txt2tags en PHP est disponible, développée par Petko Yotov (le mainteneur et principal développeur de PmWiki) et sponsorisée par Eric Forgeot. Grâce aux nombreux efforts de ce dernier, il existe maintenant plusieurs implémentations de la syntaxe Txt2tags en JavaScript, avec une démo parfaitement fonctionnelle des possibilités de rendu côté client en temps réel. Et Matthew Pickering a quant à lui écrit un reader Txt2tags pour Pandoc.

En face, Markdown est représenté par une armada d’implémentations dans tous les langages utilisés sur le web côté serveur, et aussi en JavaScript côté client pour des prévisualisations efficaces sans Ajax, mais seul Pandoc, qui n’est pas si facile à compiler sur toutes les plateformes, propose autre chose qu’un rendu en HTML.

Je vais bien sûr continuer à travailler sur le logiciel Txt2tags, mais une implémentation de la syntaxe Txt2tags dans un parser Docutils, pour toucher directement toute la communauté des développeurs Python qui documentent leurs projets, et pouvoir bénéficier ensuite du sublime Sphinx, est un projet qui me motive de plus en plus.

Enfin, je suis toujours un peu nostalgique devant ce screenshot, parce que c’est en le voyant, avec en haut à gauche le fichier avec les balises, et en bas à droite celui avec le résultat texte brut, que j’ai pris conscience que Txt2tags faisait bien ce que j’espérais, et que comme en plus il était en Python, ce serait probablement le logiciel auquel j’allais contribuer !

Mise à jour du 27 mai 2013 : Ajout dans le tableau comparatif des logiciels de Lunamark en Lua et de Jerome en Erlang. Ajout dans le tableau de classement par syntaxe de txt2tags-php pour Txt2tags.
Mise à jour du 26 février 2014 : Ajout dans le tableau comparatif des logiciels de Doxia et XWiki Rendering en Java. Ajout dans le tableau de classement par syntaxe de marked, markdown-js, erlmarkdown et XWiki Rendering pour Markdown.
Mise à jour du 26 février 2016 : Ajout dans le tableau de classement par syntaxe de txt2tags.js et Pandoc pour Txt2tags et de Sundown pour Markdown. Modification dans le tableau comparatif des logiciels, Pandoc passe d’une popularité moyenne à forte, et AsciiDoc d’une popularité forte à moyenne.

Et le meilleur framework web Python est… Django !

lundi, juin 6th, 2011

On  observe depuis quelques temps un phénomène de « consolidation » au niveau de beaucoup de logiciels libres. En effet, le modèle du libre est par essence de permettre à chacun de faire se qu’il veut, et donc d’expérimenter et d’innover. Cette dynamique est encore plus sensible quand il s’agit de technologies nouvelles. Mais une fois cette phase d’expérimentation passée, il faut aussi en tirer des conclusions, et se rassembler pour atteindre une masse critique d’utilisateurs et de développeurs, une communauté, qui viabilise le projet sur la durée.

Ainsi Ruby on Rails a été dès 2004 le grand précurseur des frameworks web de nouvelle génération. Mais même dans le monde Ruby des projets concurrents sont apparus, dont le plus important fut Merb, un framework plus léger et plus modulaire. En décembre 2008, Merb et RoR ont fusionné pour donner Ruby on Rails 3, et ainsi rassembler les énergies et les talents.

La situation dans le monde Python, bien que beaucoup plus complexe, a pris le même chemin. En effet, il existait depuis longtemps un grand nombre de technologies web en Python, aussi bien des serveurs d’application comme CherryPy ou Paste, que des langages de templates comme Myghty, Python Server Pages ou Cheetah. On ne peut que constater cette incroyable diversité sur le site officiel de Python. Une blague classique était de dire que Python était un langage tellement simple que chaque développeur pouvait écrire son propre framework. Mais aucun ne proposait un ensemble cohérent et tout intégré… aucun sauf Zope 2, mais qui lui avait comme défaut principal d’être trop intégré !

Ainsi, si sa ZODB, une vraie base de données orientée objet, était en avance techniquement sur un ORM (Object-Relationnal Mapping), c’est-à-dire une simple surcouche pour donner une apparence objet à une base de données relationnelle (SQL), elle a néanmoins fait fuire la majorité des développeurs, qui avaient comme contrainte non négociable de s’interfacer avec des bases de données MySQL, PostgreSQL ou Oracle préexistantes. De plus Zope 2 est connu pour sa courbe d’apprentissage en « Z » (Z-shaped learning curve), qui vous donne d’abord l’impression de régresser et nécessite beaucoup de temps et d’efforts avant d’obtenir un premier résultat intéressant, ainsi que pour mériter le fameux qualificatif « d’usine à gaz logicielle ».

En janvier 2006, Stéphane Fermigier, président fondateur de Nuxeo, essayait d’y voir plus clair grâce à ce schéma :

Frameworks web Python

On peut identifier cinq concurrents directs, de type framework web complet : CPS, Django, TurboGears, Subway et Pylons, ainsi qu’un serveur d’application moderne orienté composant, n’attendant que de servir de base pour de nouveaux frameworks : Zope 3.

Que sont-ils tous devenus ? Il y a d’abord ceux qui sont morts, Subway, de manière classique dans le monde du libre, par désintérêt (des développeurs et/ou des utilisateurs), et CPS, de manière plus originale, en se faisant « seppuku » (d’un point de vue pythonique), en décidant de changer de base technologique, passant de Zope 2 et Python à J2EE et Java.

Restaient donc trois frameworks, Django, un ensemble complet et monolithique d’un côté, et TurboGears et Pylons de l’autre, qui essayaient quant à eux de réutiliser au maximum les nombreux projets python existants. Ainsi, Django a souvent été accusé de souffrir du syndrome NIH (Not Invented Here), voir l’intéressante conférence de Mark Ramm (principal développeur de TurboGears) sur le sujet lors du DjangoCon 2008. Il y eu donc naturellement un rapprochement entre TurboGears et Pylons, et en juin 2007 Mark Ramm annonça que le futur TurboGears 2 serait basé sur Pylons. au grand désarroi de CherryPy.

D’un autre côté apparurent plusieurs frameworks, dont Grok et repoze.bfg, prenant comme base technologique Zope 3, mais en essayant de le rendre plus facile à utiliser et à configurer, par exemple en vous préservant de trop nombreux fichiers ZCML. Et voilà qu’en novembre 2010, Pylons et repoze.bfg fusionnent pour donner naissance à un nouveau framework soutenu par le Projet Pylons et appelé Pyramid, qui se base sur le code source de repoze.bfg et son architecture à composant, Pylons ne pouvant plus évoluer à cause d’un problème de design. Enfin, en décembre, c’est TurboGears qui fusionne avec Pyramid.

Trois frameworks qui ne font donc plus qu’un, espérant qu’en additionnant toutes leurs forces ils pourront constituer un adversaire crédible à Django. Mais un survol du tutoriel rapide m’a fait froid dans le dos : du SQL à la main (c’est bien la dernière chose que je souhaitais revivre) et des décorateurs pour spécifier le langage de template pour chaque view !? Comme en plus je ne suis pas convaincu que l’architecture à composant enthousiasme grand monde, j’ai de gros doutes sur l’avenir de Pyramid.

On en est donc arrivé à un point où les concurrents de Django ont soit disparu, soit fusionné. Alors qu’il a lui continué son chemin sans trop d’embûches, en étant en particulier extrêmement stable technologiquement. Imaginez le cauchemard du développeur TurboGears, qui a d’abord appris Kid, CherryPy et SQLObject dans la version 1, puis Genshi, Paste et SQLAlchemy dans la version 2, et qui doit maintenant ouvrir son esprit à l’architecture composant de Pyramid ! Les développeurs Django n’ont eux jamais eu à vivre ce genre de choses, et ce à mon avis grâce aux excellents choix de design logiciel faits dès le départ :

  1. Le langage de template de Django est devenu un standard, utilisé par le Google App Engine et repris dans de nombreuses autres implémentations comme Jinja et le langage de template de Tornado en Python, ErlyDTL en Erlang, Twig (le langage de template de Symfony2) et H2O en PHP, Liquid en Ruby, Dotiac en Perl, Jangod en Java, NDjango en F#, ou encore djangode de node.js et le langage de template de Dojo en JavaScript. Cette réussite est principalement due à la simplicité de ce langage de template qui est « stupide », ce qui force à mettre la logique de traitement hors des templates, et n‘a pas une  syntaxe XML, ce qui le rend utilisable facilement par des humains. Enfin, en janvier 2006 c’est le créateur de Python, Guido Van Rossum en personne, qui le consacre comme son choix personnel.
  2. Beaucoup décriaient l’ORM de Django, qu’aucun autre projet n’utilisait, et conseillaient l’utilisation de SQLobject -un changement-… puis de SQLAlchemy -un deuxième changement-, juste pour faire comme les autres frameworks Python… Puis les bases de données NoSQL sont arrivées, que ni SQLobject, ni SQLAlchemy n’ont vocation de supporter (ce n’est plus du SQL !), alors que l’ORM de Django s’adapte elle à la situation grâce au projet Django-nonrel, qui sera je l’espère bientôt intégré dans la branche principale.
  3. Le choix standard du langage de template et de l’ORM a permis et encouragé l’émergence d’un écosystème de nombreuses applications, toutes compatibles entre elles, et de snippets permettant aux développeurs de ne pas sans cesse réinventer la roue logicielle. De plus ils peuvent se baser sur l’un des nombreux sites libres disponibles pour créer les leurs. À l’opposé d’un Pylons qui laissait la liberté de ces choix, et qui n’a donc jamais pu bénéficier d’une dynamique comparable, Django est devenu une plateforme de développement autonome et incroyablement riche.

Ce développement cohérent et linéaire depuis 2005 a permis la constitution d’un large communauté et rendu Django suffisamment crédible et répandu en entreprise pour que l’on puisse trouver assez facilement un travail, un emploi, un job, ou encore un autre travail ou un autre job, de développeur rémunéré à plein temps pour travailler sur une technologie libre qu’il aime (je n’ai pas dit faire du libre), ce qui est encore trop rare.

Alors bien sûr vous pouvez aussi utiliser web2py, Tornado pour faire de l’asynchrone, un des nombreux microframeworks, ou encore créer le vôtre avec WebOb, si vous êtes bons, vous ferez d’excellentes choses. Mais LE meilleur framework web Python, c’est Django !

Mise à jour du 28 juillet 2011 : J’ai rajouté trois liens dans l’article. De plus, Georges Racinet m’a gentiment contacté pour me faire part du fait qu’il est mainteneur de CPS depuis trois ans, et que si le projet a « une communauté restreinte et peu de visibilité, il n’est pas mort et il y a du dév actif dessus ».

Head et tail de liste en Python 3

samedi, avril 23rd, 2011

Bien que Python ne soit pas un langage de programmation fonctionnelle, il incorpore un certain nombre de fonctionnalités typiques de ces langages. Ainsi les fonctions anonymes lambda, la compréhension de liste, ou encore les fonctions built-in map(), filter() et reduce() (cette dernière ayant été supprimée dans Python 3).

La programmation fonctionnelle est caractérisée par une utilisation intensive des listes, et en particulier par de nombreuses opérations récursives sur ces dernières. On est donc souvent amené à vouloir récupérer le premier élément d’une liste, sa tête ou head, et l’ensemble des éléments restants, sa queue ou tail. Ce qui s’écrit donc trivialement avec la fonction f() retournant une liste :

head, tail = f()[0], f()[1:]

Le premier problème ici est le double appel de la fonction f(), que l’on peut facilement corriger grâce à l’utilisation d’une variable intermédiaire result :

result = f()
head, tail = result[0], result[1:]

Le second problème est la lourdeur syntaxique de l’ensemble, avec la variable intermédiaire et le double usage du [] (le __getitem__ des listes en Python). On aimerait bien à la place avoir une syntaxe plus adaptée, c’est-à-dire plus proche de celles utilisées par les langages de programmation fonctionnelle, comme par exemple Erlang :

[Head|Tail] = Result

Et comme toujours avec Python, le langage se bonifie grâce à une PEP (Python Enhancement Proposal), en l’occurence la PEP 3132 intitulée Extended Iterable Unpacking. Ainsi, depuis Python 3.0, on peut utiliser une nouvelle syntaxe qui reprend celle des star-args (*args) des fonctions Python :

head, *tail = result

Ceci se teste facilement dans un shell Python 3 :

>>> result = [1, 2, 3, 4]
>>> head, *tail = result
>>> head
>>> 1
>>> tail
>>> [2, 3, 4]

On a donc maintenant une syntaxe tout à fait satisfaisante, très lisible et facilitant un style de programmation fonctionnel. Ce qui est encore plus intéressant avec cette notation, c’est qu’elle ne se limite pas au couple head et tail, et peut ainsi être déclinée de bien des manières tout à fait intéressantes comme par exemple :

>>> result = [1, 2, 3, 4]
>>> head, *body, tail = result
>>> head
>>> 1
>>> body
>>> [2, 3]
>>> tail
>>> 4

Python 3 est sorti depuis plus de deux ans et, sans être révolutionnaire, il apporte de nombreuses améliorations à Python 2 qui valent le coup d’être découvertes et utilisées !

Txt2tags 2.6 est arrivé !

vendredi, novembre 5th, 2010

Le voilà enfin, après plus de deux ans d’attente, txt2tags 2.6 est arrivé !

Txt2tags est un langage de markup, c’est-à-dire qu’il utilise une syntaxe non-obstrusive pour signifier les propriétés des éléments de texte, une syntaxe wiki en plus puissante. Mais à la différence des wiki qui ne génèrent que du HTML, txt2tags permet, à partir du même fichier source, de générer pas moins de 18 formats différents (appelés target) : HTML, XHTML, SGML, DocBook (NEW), LaTeX, Lout, Man page, Creole (NEW), Wikipedia / MediaWiki, Google Code Wiki, PmWiki (NEW), DokuWiki, MoinMoin, MagicPoint, PageMaker, AsciiDoc (NEW), ASCII Art (NEW) et Plain text.

J’ai commencé à m’investir dans txt2tags car je suis convaincu que le modèle de bureautique WYSIWYG actuel, promu par des usines à gaz mastodontiques, fussent-elles libres comme LibreOffice, est une véritable impasse. Par chance, les principaux logiciels intéressants dans ce domaine (txt2tags, docutils/ReST et AsciiDoc), sont écrits en Python, mon langage de programmation de prédilection.

Si j’ai choisi txt2tags c’est parce que c’était le code le plus simple à modifier pour faire les expérimentations qui m’intéressaient. Et puis Aurélio Jargas, le principal développeur, a ouvert son développement anciennement très solitaire/centralisé grâce au site Google Code. Il m’a donné les droits de commit SVN à la seconde où je l’ai contacté. Ce très bon feeling humain s’est poursuivi et a permis une collaboration technique, puisque si j’ai eu pas mal d’idées et que je les ai implémentées fonctionnelles et non buggées, Aurélio a fait un sacré travail derrière pour que l’intégration de mes modifications fassent moins « hack ».

Mon traditionnel et important point de juriste 🙂 : txt2tags est sous licence GNU GPLv2, qui est soumise à un Copyleft fort, ce qui garantit la liberté éternelle de mon travail. Bien qu’un relativement petit projet en terme de nombre de lignes de code, la communauté autour de txt2tags est grande et mondiale, et il est donc localisé dans plus d’une dizaine de langues (chaînes de caractères dans le code ET documentation) !

Beaucoup de nouvelles fonctionnalités dans cette version 2.6, dont ma nouvelle target ASCII Art sur laquelle je reviendrai plus en détail, mon set markItUp! pour une utilisation aisée sur le web, la possibilité d’inclure des tableaux de fichiers CSV externes, et un nom de domaine txt2tags.org, pour donner plus de visibilité au site web.

Je suis très heureux et très fier de pouvoir faire cette annonce, car cela fait pas loin de deux ans que je me suis engagé dans ce projet, et que cette release permet de rendre accessible au grand public ma première contribution significative aux logiciels libres !

Smartphones Linux : le point du dev

vendredi, janvier 15th, 2010

Un petit point sur le hardware et le software disponibles pour un développeur libre qui voudrait utiliser un smartphone et développer dessus.

Il existe trois plateformes basées sur Linux (je n’écris volontairement pas GNU/Linux car si Android utilise bien le noyau Linux, il n’utilise pas pour autant les outils GNU) :

Maemo :

Maemo est censé, chez Nokia, remplacer Symbian qui est dépassé technologiquement pour les nouveaux usages mobiles. Après avoir été expérimenté (trop) longuement (depuis 2005 !) sur les tablettes N770, N800 et N810, il est enfin disponible sur un téléphone : le N900, depuis novembre 2009.

Or, si le N900 est disponible, il utilise la plateforme Maemo 5 qui va disparaitre et aucun smartphone n’est disponible sous Maemo 6. Je ne lancerai donc pas une énième fois le troll GTK (Maemo 5) vs Qt (Maemo 6) qui n’a juste pas lieu d’être : Maemo n’est pas dans la course. Et à la vitesse où va cette course, il ne parviendra peut-être jamais à y rentrer.

Je ne m’étendrai pas sur Maemo car je veux à la fois développer des applications  que je puisse  tester,  et que d’autres puissent utiliser, et il faut pour cela pouvoir se procurer un smartphone adapté, et ne pas m’investir dans une plateforme en fin de vie. De plus, le fait que Maemo utilise Xorg le rend techniquement contestable, tant la complexité et la lourdeur inhérentes à X11 sont malvenues sur un smartphone.

Android :

Du côté d’Android c’est une toute autre histoire. Des smartphones sont disponibles depuis octobre 2008 aux États-Unis et mars 2009 en France. Au niveau commercial c’est déjà une grande réussite : Android est la plateforme qui progresse le plus et s’est imposé en un an comme le principal (le seul ?) challenger de l’iPhone (voir les statistiques d’AdMob pour plus de détails).

D’un point de vue technique, Android fournit un SDK basé sur le langage de programmation Java. Cependant, il ne repose pas sur la JVM de Sun, mais sur Dalvik, une machine virtuelle à registres (comme Parrot) spécialement développée pour les contraintes hardware (mémoire faible, processeur peu puissant…) de l’embarqué. Dalvik est à ma connaissance la seule machine virtuelle à registres qui soit un succès industriel, face à la masse des machines virtuelles à pile (JVM de Sun, CLR de Microsoft…).

Mais que peut-on faire si on ne veut pas programmer en Java ? Les développeurs ont souvent un langage de programmation favori, qu’ils ont peu ou pas envie d’abandonner ; dans mon cas c’est PythonOn pense alors naturellement aux implémentations des langages écrites en Java, Jython pour Python ; mais si elles fonctionnent sur la JVM de Sun, ce n’est pas forcément le cas pas sur Dalvik ! Heureusement, Google a pensé à nous avec ASE, l’Android Scripting Environment, qui permet d’utiliser l’ensemble des API Android à partir de différents langages interprétés, et le choix est vraiment grand : Python, Lua, Perl, Ruby, JavaScript, BeanShell et même shell !!

Tous les langages ne sont pas égaux devant ASE. Les langages natifs, c’est-à-dire écrits en Java, comme Ruby basé sur JRuby, JavaScript basé sur Rhino ou encore BeanShell, peuvent théoriquement accéder directement aux API Java natives, alors que les langages « cross-compilés », comme Python (basé sur CPython) ou Lua qui sont écrits en C, ne peuvent procéder que par des appels JSON RPC. C’est cependant cette dernière méthode qui semble conseillée quel que soit le langage utilisé.

Je suis donc maintenant motivé pour me lancer dans l’aventure Android, d’autant que Google vient d’anoncer, lors d’une conférence de presse le 5 janvier, le lancement de son premier smartphone : le Nexus One fabriqué par HTC. C’est tout simplement une « bête de course » du point de vue hardware : processeur à 1 Ghz, 512 Mo de RAM et un écran 3,7″ d’une résolution de 480*800 (pour rappel l’iPhone 3GS fonctionne à 600 Mhz avec 256 Mo de RAM et un écran 3,5″ en 320*480) !!! La disponibilité du Nexus One en France est prévue pour le mois de mars.

J’hésite cependant encore avec le Motorola Milestone, qui a lui l’avantage d’être déjà disponible et de posséder un clavier physique, ce qui pourrait se révéler bien pratique pour des sessions d’administration de machines par SSH, avec le terminal en plein écran !

webOS :

Il y a un an, lors du CES de janvier 2009, Palm avait créé l’évènement avec l’annonce du Palm Pré et de son nouveau système d’exploitation : webOS. Les critiques avaient été très élogieuses et l’on a même pensé que l’on tenait là le principal concurrent de l’iPhone. En effet, webOS est le seul système alternatif  à proposer les mêmes facilités multitouch que l’iPhone (il semblerait que sur ce sujet, Palm et Apple se tiennent par la barbichette des brevets logiciels). La qualité et la simplicité de l’ergonomie étaient aussi tout à fait remarquables, et le design très « sexy ».

Le Palm Pré a été introduit au États-Unis le 6 juin, et les ventes ont été bonnes. Mais tout cela s’est un peu essouflé car Sprint, l’opérateur exclusif aux USA, est semble-t-il en perte de vitesse, et le Palm Pré n’a pas été commercialisé dans beaucoup d’autres pays : il n’est par exemple toujours pas disponible en France. Seule nouveauté depuis un an, l’introduction d’un nouveau modèle moins puissant visant l’entrée de gamme des smartphones, le Palm Pixi.

Et puis voilà à nouveau que, lors de la présentation du 7 janvier au CES, Palm fait des annonces tonitruantes ! D’abord l’arrivée de deux nouveaux modèles : le Palm Pré Plus et le Palm Pixi Plus, qui proposent de grandes améliorations matérielles. Le Palm Pré voit sa capacité de stockage et sa RAM doublées, à 16 Go et 512 Mo respectivement, tandis que le Palm Pixi n’est plus castré des possibilités Wi-Fi que l’on peut légitimement attendre d’un smartphone, fût-il d’entrée de gamme. Et ces deux modèles seront disponibles en France au début du second trimestre.

Ensuite, le programme pour développeur, qui permet de fournir ses applications via le App Catalog officiel de Palm (équivalent du célèbre App Store d’Apple) est maintenant ouvert à tous. Mais ce n’est pas tout, un programme spécial pour les développeurs Open Source existe, qui offre comme avantage d’économiser les 99$ de cotisation annuelle (en ce moment offerts à tous) et les 50$ par application soumises au App Catalog. De plus, Palm montre sa compréhension des logiciels libres, car l’on peut tout à fait commercialiser ses applications libres, et il n’y a aucune discrimination, comme pour les applications propriétaires c’est 70% du prix pour le développeur (comme sur l’App Store).

Développeur qui pourra désormais programmer de vrais jeux exploitant tout la puissance du la puce graphique, grâce à la mise à disposition d’un nouveau SDK spécialement destiné au jeux : le Plug-in Development Kit. Ce dernier est basé sur l’excellente et très utilisée librairie SDL, véritable standard des logiciels libres. Le PDK est censé être programmé en C ou en C++, mais il existe des bindings SDL pour un nombre de langage de programmation très impressionnant, et j’ai du mal à voir ce qui pourrait m’empêcher d’utiliser sous peu Pygame pour programmer des jeux en Python !

Pour ce qui est des applications plus classiques, Palm propose désormais un IDE fonctionnant dans votre navigateur web : Project Ares. On pourra saluer la cohérence technologique qui permet de faire aisément cela puisque l’ensemble du SDK Palm est construit à base  de technologies web, et espérer que cela permettra de faciliter l’accès à la programmation webOS au plus grand nombre.

Enfin, pour motiver les développeurs à se lancer et ainsi remplir son App Catalog, Palm propose le concours Hot Apps doté d’un million de dollars à partager entre les applications les plus téléchargées du 1er février au 31 mai.

Sur le front des smartphones Linux est là et bien là, en position de force, prêt à exterminer les systèmes d’exploitation privateurs de liberté Windows Mobile et BlackBerry OS et à mener le grand combat final contre l’iPhone !

Tornado !

dimanche, septembre 13th, 2009

Le 10 août 2009, Facebook, le plus largement utilisé des réseaux sociaux, a racheté pour une somme avoisinant les 50 millions de dollars FriendFeed, un site de microblogging fait par d’anciens de chez Google.

Cette information en tant que telle n’est pas si intéressante, mais elle prend beaucoup de force quand c’est Facebook, un gros producteur de technologies open source, qui rachète un site fait par d’anciens de chez Google et donc utilisant Python comme langage de programmation (oui, vous vous souvenez, le meilleur langage du Monde !!!).

Le résultat de tout cela est la libération de Tornado, un serveur d’application web asynchrone écrit en Python. Les performances anoncées semblent impressionantes, très supérieures à celles du standard actuel pour les applis python en production Apache+mod_wsgi, et donc aussi à ce que peut faire TwistedWeb, le seul autre serveur web python asynchrone.

J’ai été mis au courant par la mailing list django-developers où une annnonce à été faite par Bret Taylor, et j’ai pu trouver par la suite l’avis de Glyph Lefkowitz, le papa de Twisted, une des rares personne très compétentes dans le domaine complexe et globalement mal maitrisé de la programmation asynchrone, alors que Dustin Sallings a déjà forké Tornado de manière à ce qu’il utilise Twisted (oui, vous vous souvenez, le logiciel libre c’est trop génial, ça bouge à mille à l’heure, aucune entrave à la création !).

Un benchmark, et puis un autre, et encore un autre.

python-glpk

jeudi, août 13th, 2009

Le paquet python-glpk fournit un module qui permet d’utiliser la bibliothèque GNU de programmation linéaire GLPK tout en programmant en Python.

Le mainteneur actuel, Jan Alonzo, semblant ne plus s’en occuper, Sandro Tosi a fait une RFA (« Request for Adoption ») sur le paquet.

Python étant mon langage de programmation préféré, j’avais décidé de choisir des paquets dans ce langage pour commencer à m’investir sérieusement dans le projet Debian. De plus, j’ai été amené à utiliser GLPK lors de mon stage de Master, ce qui me donne une petite compétence supplémentaire pertinente.

J’ai donc logiquement décidé de relever le défi python-glpk !!! et j’en suis maintenant le « Owner »…il ne reste plus qu’à travailler 🙂