Posts Tagged ‘Libre’

Ruby est mourant (Python, Node.js, Go et Elixir l’ont tué)

lundi, décembre 5th, 2016

En août 2015 GitHub publiait le classement des langage de programmation les plus populaires depuis son lancement en 2008. L’article mettait l’accent sur la progression de Java, lié à l’adoption des services de GitHub par les entreprises friandes de ce langage, mais c’est bien l’évolution de la popularité de Ruby qui m’avait le plus interpellé.

Leader aux premiers jours de 2008, avec en particulier la présence immédiate de Ruby on Rails sur GitHub (GitHub est une application Ruby en Rails), Ruby est passé 2ème en 2013, puis 3ème en 2014 et enfin 4ème en 2016.

github

Suivant de près la popularité des langages sur GitHub, j’ai eu la chance de capturer hier l’improbable moment où PHP – le grand-père du web en net regain de forme depuis la sortie de PHP 7 – a dépassé l’enfant prodige pour le reléguer à la 5ème place !

classment2

Mais si Ruby est mourant, quels sont donc ses meurtriers ?

Python pour la diversité d’utilisation

Python est un peu le concurrent historique de Ruby, tant ces deux langages semblaient occuper la même « niche » de langage de programmation moderne, dynamique et orienté objet. Ce que l’on peut faire avec Python on peut le faire avec Ruby, et réciproquement, le choix entre les deux est plus une question de feeling sur la syntaxe du langage ou l’ambiance de la communauté.

Oui mais justement, que fait-on avec ces langages ? En première page du site web du langage Python on peut trouver une section « Use Python for… » qui donne une réponse à cette question dans le but de conforter les débutants dans leur choix de Python : ils ne vont pas seulement apprendre un langage de programmation puissant et facile d’utilisation, mais aussi un outil pour faire plein de choses utiles et très diverses.

python

Car si Python est bien sûr utilisé pour la programmation web et qu’il a son alter ego de Rails avec Django, il est aussi énormément utilisé dans bien d’autres domaines. Python est installé par défaut sur toutes les distributions GNU/Linux et sur macOS, il est largement utilisé en administration système, s’est imposé pour des utilisations scientifiques et pédagogiques et représente le choix le plus simple et efficace pour développer des interface graphiques, avec de nombreux bindings vraiment fonctionnels et maintenus.

Ruby et sa communauté sont en comparaison par trop web-centric. Rails, Sinatra et Jekyll sont formidables, et ils étaient même très innovants, mais de nombreux projets s’en sont inspiré, des équivalents ont été développés dans d’autres langages et ils ne peuvent plus à eux seuls justifier d’apprendre le Ruby. Ruby a percé grâce à Rails et au web, mais il n’a jamais su s’en émanciper et c’est ce qui est en train de causer sa perte.

Node.js pour le buzz

D’une manière qui a parfois pu irriter les pythonistes, Ruby a longtemps eu l’image d’un langage cool, et tout ce qui s’y rapportait de près ou de loin faisait facilement le buzz. Oui mais voilà, Node.js est passé par là, amenant au JavaScript l’ubiquité, cette exceptionnelle singularité d’être le seul langage de programmation présent à la fois côté serveur et côté client.

trend

Node.js a bénéficié d’une large et dynamique communauté préexistante de développeurs JavaScript, ce qui a permis son adoption à une vitesse incomparable à celle d’un « nouvel entrant ». Node.js a donc attaqué frontalement Ruby sur sa niche web tenue par Ruby on Rails et l’a en quelque sorte dépossédé de son buzz.

Go et Elixir pour les performances

Deux langages de programmation récents ont aussi causé beaucoup de tort à Ruby en l’attaquant sur le terrain des performances, son point faible historique. On peut ainsi développer rapidement de beaux et fonctionnels sites web avec Ruby on Rails, mais quand le succès arrive, il est alors très difficile de scaler. Le remplacement de Ruby on Rails par du Java par Twitter en 2011 en est bien sûr l’exemple le plus cinglant.

Go est un langage de programmation compilé créé par Google en 2007 et rendu disponible en 2009. Alors que l’on pensait que ce langage allait attirer les développeurs C et C++ à la recherche de plus de confort, il a en fait attiré beaucoup de développeurs de langages dynamiques à la recherche de plus de performances. Ainsi de nombreuses personnes réécrivent leur application Rails en Go et constatent des gains de performances leur permettant par exemple de passer de 30 à 2 serveurs pour l’hébergement, ce qui implique des économies de travail, de temps et d’argent colossales.

Elixir est un langage de programmation fonctionnel datant de 2012 qui utilise BEAM, la formidable machine virtuelle massivement concurrente développée pour Erlang. La particularité d’Elixir est de reprendre la sémantique d’Erlang et de la proposer aux développeurs sous la forme d’une nouvelle syntaxe… inspirée du Ruby ! Cela n’est pas très surprenant quand on sait qu’Elixir a été créé par José Valim, un des principaux développeurs de Ruby on Rails. Et ce sont bien sûr les problèmes de performance de Ruby qui ont motivé sa démarche. Elixir se positionne donc clairement comme un nouveau Ruby, mais qui scale.

Il est très probable que Go et Elixir vont continuer à devenir de plus en plus populaires dans les années qui viennent, et que Ruby va avoir beaucoup de difficultés à s’en relever. Un dernier petit exemple en passant, sur les cinq logiciels libres dont je parlais dans mon article sur la base LEGI, deux sont en Python, un en PHP, un en Go, un en Julia… et aucun en Ruby.

Open Data juridique : l’utilisation de la base LEGI

samedi, novembre 12th, 2016

Suite au rapport sur l’ouverture des données publiques que le magistrat à la Cour des comptes et développeur Debian Mohammed Adnène Trojette a remis au Premier ministre le 5 novembre 2013, la majorité des bases de données juridiques de l’administration française ont été rendues disponibles en Open Data.

Ainsi, depuis juin 2014, la base LEGI, composée de l’ensemble des codes, lois et règlements français, est mise à disposition par la DILA, la Direction de l’information légale et administrative. La base complète est fournie environ deux fois par an sous la forme d’un ficher archive compressé, auquel viennent s’ajouter des mises à jour quotidiennes.

La base LEGI est très imposante. La dernière archive complète (Freemium_legi_global_20160406-082840.tar.gz) pèse 745 Mo, et elle se décompresse dans un répertoire legi d’une taille variant entre 9 et 15 Go selon votre système de fichier.

Une fois que les données sont en Open Data, toutes les initiatives deviennent possibles. Voici les six projets que j’ai pu référencer :

NomArchéo Lexlegi.pyLegi DisplayLegit.jllegifrance-goCodes Droit.org
AuteurSeb35ChangacoSedLexeraviart (Etalab)SteeveHabett
Origine des donnéesLEGILEGILEGILEGILégifrance puis LEGILégifrance puis LEGI
ProductionDépôts GitTest des donnéesPlugin WordPressDépôts GitDépôt GitPDF et ePub
LangagePythonPythonPHPJuliaGoPerl
SGBDSQLite (Peewee)SQLiteMySQL---
LicenceWTFPLCC0GPLMITGPLPropriétaire

Le projet le plus ancien est les Codes pour Droit.org, qui a précédé l’ouverture de la base LEGI. Ce projet avait donc commencé en récupérant directement les données du site web Légifrance.

Le seul projet a avoir bénéficié d’une importante couverture médiatique -d’un gros buzz-, avec articles sur Le Monde et Le Figaro, tweets de Maître Éolas et de la secrétaire d’État chargée du numérique Axelle Lemaire, et en conséquence plus de 2 500 étoiles sur GitHub, est le Code civil que Steeve fournit sous la forme d’un dépôt Git.

Paradoxalement c’est un projet techniquement très limité :

  • seulement deux codes fournis (d’abord le Code civil, puis le Code pénal)
  • récupération des données du site web Légifrance alors que la base LEGI était disponible depuis presque un an
  • logiciel de génération des codes jamais distribué, donc propriétaire

Cependant, il a eu le grand mérite de faire connaître au grand public ce qui est sûrement l’innovation la plus importante que l’informatique peut apporter à l’étude des textes juridiques : une bonne visualisation des changements entre les versions grâce aux diff générés par un logiciel de gestion de versions comme Git.

Diff Article 34 du Code civil

Archéo Lex, un projet complet qui fournit tous les codes de la base LEGI sous la forme de dépôts Git ainsi que le logiciel utilisé pour les générer, était pourtant apparu plusieurs mois avant le Code civil de Steeve…

Enfin, la mission Etalab s’est emparée de la démarche et a fourni tous les codes et toutes les lois non codifiées sous la forme de dépôts Git ainsi que Legit.jl, le logiciel utilisé pour les générer. C’est très bien, mais je trouve que le choix du langage de programmation Julia est contestable, non pas d’un point de vue technique, mais d’un point de vue communautaire. En choisissant un langage aussi confidentiel, on se prive de toute chance de voir des contributeurs extérieurs s’y intéresser…

Concernant la qualité des données de la base LEGI, Seb35 remercie la DILA pour la très bonne qualité des métadonnées tandis que Changaco indique avoir été un peu découragé par la structure médiocre des données.

Personnellement, je pense que le manque de dynamique autour de la base LEGI, qui est pourtant l’une des plus intéressantes de l’Open Data en France, s’explique par la complexité de l’organisation des données qui la rend difficilement exploitable. Ainsi, la dernière version de la base est composée de 1 624 783 fichiers XML, répartis dans une arborescence absconse de 1 537 949 sous-répertoires. Je suis convaincu qu’il reste encore plein de choses à faire pour rendre ces riches données plus accessibles et plus exploitables.

Mise à jour du 16 novembre 2016 : Tous les codes sont présents dans la branche everything du Code civil de Steeve, et ils ont été générés à partir de la base LEGI avec le logiciel libre legifrance-go.

Arduino, la réunification

dimanche, octobre 2nd, 2016

Banzi et Musto au Maker Faire de New York

Massimo Banzi (à gauche sur la photo) et Federico Musto (à droite) viennent d’annoncer sur l’estrade du Maker Faire de New York la « réunification » du projet Arduino. Arduino LLC et Arduino srl ont de plus publié conjointement un communiqué sur leur site web respectif Arduino.cc et Arduino.org.

Il y a un an et demi, en mars 2015, la scission du projet Arduino avait été rendue publique. Une bataille juridique s’était engagée concernant la propriété et l’exploitation de la marque Arduino dans le monde, amenant à la création de la marque Genuino. La disponibilité des produits Arduino était devenue très problématique et la vision du futur plus qu’incertaine.

La situation était très préjudiciable au plus important des projets de hardware libre et je suis vraiment très heureux de relayer l’annonce d’une transaction entre les parties plutôt que de faire un cas pratique de droit des marques sur le sujet !

Les micro-frameworks Python : Flask, Bottle, Itty, Newf, djng et importd

dimanche, août 21st, 2016

Suite au succès phénoménal de Flask, qui a plus d’étoiles sur GitHub que Django, et à celui remarquable de Bottle, j’ai poursuivi ma réflexion personnelle sur les microframeworks. C’est un sujet auquel je m’étais fortement intéressé en 2009, il y a 7 ans donc, lors de la soudaine prolifération de microframeworks Python.

Sinatra, l’inspiration vint encore du Ruby

Tout comme Ruby on Rails a été dès 2004 le grand précurseur des frameworks web MVC de nouvelle génération, Sinatra a été dès 2007 le précurseur des microframeworks web. Sinatra a rendu l’écriture d’application web radicalement plus aisée grâce à sa syntaxe claire et concise :

require 'sinatra'

get '/' do
'Hello world!'
end

WSGI, la condition technique

Le standard Python WSGI (Web Server Gateway Interface) décrit dans la PEP 333 de 2003, mise à jour en 2010 par la PEP 3333, a proposé une interface simple permettant de découpler les frameworks web des serveurs web.

Et l’ajout du module wsgiref dans la bibliothèque standard de Python 2.5 en 2006 a permis a tout framework d’être utilisable sans aucune dépendance grâce au petit serveur WSGI qu’il fournit :

from wsgiref.simple_server import make_server

Qu’est-ce qu’un micro-framework ?

En admettant que l’on sache ce qu’est un framework, on doit s’interroger sur le sens de micro. Le Larousse précise :

Préfixe, du grec mikros, petit, indiquant que quelque chose est très petit.

Un micro-framework est donc un très petit framework. L’intérêt de cette démarche est réel pour le développeur car il est plus facile d’apprendre à utiliser un petit framework, qui de plus consomme moins de ressources et impose souvent moins de contraintes.

Il est communément admis que ces microframeworks sont surtout intéressants pour construire de petites applications, la quantité de fonctionnalités des frameworks full-stack justifiant de plus en plus leur usage avec l’augmentation de la taille et des besoins de l’application.

Le moins de lignes de code possible

Un microframework est donc un framework ayant une petite base de code, c’est-à-dire un petit nombre de lignes de code. Encore faut-il qu’il en ait suffisamment pour qu’un développeur ait un intérêt à l’utiliser.

Le minimum nécessaire n’est pas forcément facile à évaluer, mais on peut penser qu’un framework comme Newf, avec ses 114 lignes de code, était très nettement en dessous. Itty, quant à lui, est très proche de Bottle en termes de design et de fonctionnalités, mais d’une manière globalement plus – et donc finalement trop – minimaliste.

Dans les deux cas, cela s’est révélé insuffisant pour susciter un réel intérêt chez les développeurs d’applications web et donc pour créer une dynamique et fédérer une communauté autour de ces projets.

Tout le framework dans un seul fichier

La théorie de l’ingénierie logicielle a combattu cette pratique au nom d’une meilleure structuration, permettant une bonne séparation des fonctionnalités et donc un débogage et une réutilisation plus facile du code. Pourtant, mettre tout le code dans un seul fichier présente certains avantages, en particulier quand il s’agit de le distribuer. C’est une pratique qui a connu une nouvelle légitimation avec le succès des bibliothèques JavaScript côté client, facilement chargées dans le navigateur web d’une simple ligne :

<script src="https://cdn.net/lib.js"></script>

Bottle est distributed as a single file module alors que Flask est plus classiquement composé de plusieurs fichiers. Flask, le plus populaire des microframeworks Python en est-il donc vraiment un ?

Essayons d’y voir plus clair à l’aide de wc récursifs appliqués sur les répertoire contenant le code source des frameworks, et desquels j’ai retiré le code des tests :

Micro-frameworksFrameworks
NomNewfdjngimportdIttyBottleFlaskTornadoPyramidDjango
wc -l1503287919584 1796 46922 32722 641122 675
sloccount1142305336322 7212 72511 53511 31277 514
Fichiers Python1142112181193853
Étoiles GitHub501234543743 87822 00711 9032 05920 717
PyPI (millions)0,10,0521411223

J’ai ajouté au tableau Django, Pyramid et Tornado, les trois frameworks web Python les plus populaires, et il apparaît clairement qu’en comparaison Flask est bien un microframework, puisque s’il est 1,5 fois plus gros que Bottle, il est 3,5 fois moins gros que Tornado et Pyramid et 19 fois moins gros que Django.

Toute l’application dans un seul fichier

Lorsque l’on utilise les outils d’aide des frameworks classiques pour débuter un projet, on se retrouve devant une arborescence complexe. Par exemple avec Django, si vous évitez les bizarreries et faites les choses normalement :

$ django-admin startproject django_project
$ cd django_project
$ django-admin startapp django_app


django_project
├── django_project
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── django_app
│ ├── admin.py
│ ├── __init__.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
└── manage.py

De même avec Pyramid :

$ pcreate -s starter pyramid_project

pyramid_project
├── CHANGES.txt
├── development.ini
├── MANIFEST.in
├── production.ini
├── pyramid_project
│ ├── __init__.py
│ ├── static
│ │ ├── pyramid-16x16.png
│ │ ├── pyramid.png
│ │ ├── theme.css
│ │ └── theme.min.css
│ ├── templates
│ │ └── mytemplate.pt
│ ├── tests.py
│ └── views.py
├── README.txt
└── setup.py

Ceci est une bonne base pour un gros projet, qui sera bien structuré dès le départ, avec un bon découplage du code, et même les fichiers nécessaires à son packaging ; mais pour beaucoup de projets assez simples, c’est surtout lourd et redondant.

Tous les microframeworks ont donc comme point commun qu’ils sont conçus pour qu’une application toute entière contenue dans un seul fichier soit parfaitement fonctionnelle, et un certain nombre de frameworks qui ne prétendent pas être des microframeworks, comme Tornado, partagent la même approche.

Pas de dépendances… ou beaucoup de dépendances ?

Deux visions opposées peuvent en effet légitimement se défendre lors de la construction d’un microframework :

– pour avoir un framework léger il ne faut aucune dépendances, et se reposer exclusivement sur la bibliothèque standard de Python (Python Standard Library)
– pour avoir un framework léger il faut au contraire se reposer un maximum sur des bibliothèques existantes, fiables et populaires si possible, et se contenter d’offrir une fine couche logicielle permettant de les interfacer correctement

Newf et Itty font bien sûr partie de la première catégorie.

Bottle qui has no dependencies other than the Python Standard Library, et fournit son propre langage de template, fait donc aussi partie de la première catégorie. Mais on peut en plus lui interfacer facilement Mako, Jinja2 et Cheetah, des langages de template Python populaires, ce qui le fait alors déborder sur la deuxième catégorie.

Flask quant à lui est de la seconde catégorie, d’autant que son auteur est Armin Ronacher (mitsuhiko) qui est aussi l’auteur de ses dépendances Werkzeug et Jinja2. Mais si avoir comme dépendances une bibliothèque WSGI et un langage de template est on ne peut plus légitime pour un microframework, l’ajout de la bibliothèque d’interface de ligne de commande Click semble beaucoup plus contestable et relever plutôt du syndrome NIH (Not invented here).

Enfin, à l’initiative de djng, la seconde vision a amené à de multiples essais de microframeworks basés sur… Django, le maxi-framework du monde Python ! Et si seul importd a rencontré un certain succès parmi ces projets, je pense que cet oxymore logiciel est un concept vraiment intéressant et que son potentiel n’a probablement pas encore été totalement exploité.

Mise à jour du 10 septembre 2016 : Suite au commentaire de Stéfane Fermigier, ajout dans le tableau du comptage des lignes de code avec SLOCcount. Ajout de djng.
Mise à jour du 10 octobre 2016 : Ajout dans le tableau du nombre de téléchargements sur PyPI.

Mehdi Dogguy élu DPL pour 2016

dimanche, avril 17th, 2016

C’est Mehdi Dogguy qui vient d’être élu Debian Project Leader (DPL) pour l’année 2016, succédant ainsi au mandat de Neil McGovern, contre qui il avait perdu en 2015.

Mehdi Dogguy

Ce n’est bien sûr pas une surprise puisque Mehdi était le seul candidat, et qu’il n’y avait aucune raison valable de lui préférer « None of The Above » et ainsi de provoquer de nouvelles élections. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

Vote DPL 2016

Ce vote confirme cependant la place importante prise par la France dans le projet Debian ces dernières années, après les trois mandats de Stefano Zacchiroli et les deux mandats de Lucas Nussbaum.

Bravo à toi Mehdi, et bonne chance dans la mise en œuvre de ton programme !

Quel DPL pour 2016 ?

lundi, mars 14th, 2016

Le temps passe vite, et cela fait déjà presque un an que Neil McGovern a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait donc se porter candidat entre le 6 et le 12 mars à la suite du traditionnel appel à candidatures.

Dès le 7 mars, Neil exprimait le souhait de ne pas se représenter :

Just for avoidance of doubt, I do /not/ intend on re-standing for my post. I would encourage any candidates to put themselves forward.

Malheureusement, peu de développeurs semblent motivés par la charge de DPL comme l’exprimait Lars Wirzenius :

After some serious thinking, I’ve decided not to nominate myself in the Debian project leader elections for 2016. […] Why not run? I don’t think I want to deal with the stress. I already have more than enough stress in my life, from work.

et il n’y aura donc finalement qu’un candidat cette année :

La question de la légitimité d’un scrutin avec un seul candidat a été posée par Paul Wise, mettant en avant le fait qu’il ne s’agissait pas cette fois de renouveler sa confiance à un DPL déjà en poste comme c’était le cas de Zack en 2011.

Cependant, il est important de préciser que Mehdi avait fait un très bon résultat l’année dernière en finissant deuxième pour sa première tentative, et qu’il se positionnait ainsi comme un candidat très sérieux pour cette année.

Les presque mille développeurs Debian seront libres de voter du 3 au 16 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

[MàJ] Txt2tags en JavaScript et avec Pandoc

vendredi, février 26th, 2016

Grâce aux nombreux efforts d’Eric Forgeot, il existe maintenant txt2tags.js, une implémentation de la syntaxe de Txt2tags en JavaScript avec une démo parfaitement fonctionnelle des possibilités de rendu côté client en temps réel.

Matthew Pickering a quant à lui écrit un reader Txt2tags pour Pandoc, ce qui permet d’utiliser votre syntaxe préférée avec cet excellent logiciel.

Ces deux informations ont été ajoutées dans le tableau de classement par syntaxe de Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile.

Erlang passe sous licence Apache 2.0

mardi, octobre 6th, 2015

Le langage de programmation Erlang est passé sous licence Apache 2.0, à l’occasion de la sortie de sa version 18.0 le 24 juin dernier.

Au commencement un logiciel propriétaire, Erlang avait été libéré par Ericsson en 1998 sous Erlang Public License, une version modifiée de la licence Mozilla.

L’abandon total d’un Copyleft déjà faible me semble anecdotique dans ce changement de licence. En revanche, le passage d’un important logiciel libre d’une licence spécifique à une licence très populaire participe d’un mouvement de consolidation des licences de logiciel libre, permettant une compréhension plus claire des obligations y afférentes et donc une meilleure sécurité juridique.

Pour le choix d’une licence sans Copyleft, ou « permissive », la licence Apache 2.0 est à recommander, tout comme le fait la Free Software Foundation, car elle est plus complète que ses concurrentes, en particulier concernant les brevets.

La consolidation des licences libres est une évolution positive à mon sens, et l’exemple d’Erlang pourrait peut-être inspirer Python ou d’autres logiciels libres ayant leur propre licence…

Neil McGovern élu DPL pour 2015

mercredi, avril 15th, 2015

C’est Neil McGovern qui vient d’être élu Debian Project Leader (DPL) pour l’année 2015, succédant ainsi au double mandat de Lucas Nussbaum, contre qui il avait perdu en 2014.

Neil McGovern

Neil devance Mehdi Dogguy, qui recueille un nombre de voix très intéressant pour l’avenir, et Gergely Nagy (déjà candidat malheureux en 2004, 2012 et 2013). Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

Vote DPL 2015

Bravo à toi Neil, et bonne chance dans la mise en œuvre de ton programme !

Quel DPL pour 2015 ?

vendredi, mars 20th, 2015

Le temps passe vite, et cela fait déjà presque un an que Lucas Nussbaum a été réélu Debian Project Leader (DPL). Chaque développeur Debian pouvait donc se porter candidat entre le 4 et le 10 mars à la suite du traditionnel appel à candidatures.

Dès le 12 février, anticipant quelque peu sur le calendrier, Lucas avait exprimé le souhait de ne pas se représenter :

But I also think that switching release cycles is a good opportunity to align other changes, and starting a fresh release cycle with a fresh DPL might be a good idea. Put differently: no, I will not run for re-election.

Il y aura finalement cette année trois candidats :

Les presque mille développeurs Debian seront libres de faire leur choix du 1er au 14 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.