Liens intéressants Journal du hacker semaine #15

Rédigé par Cascador - -

Pour la 15ème semaine de 2016, voici 5 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Entretien avec Dimitri Fontaine, développeur PostgreSQL

Rédigé par Carl Chenet - -

Jdh : Bonjour Dimitri et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Dimitri : Bonjour Carl, merci de me proposer de réaliser ensemble cette interview, cela flatte mon égo :) Je travaille aujourd'hui en tant qu'Architecte Logiciel et Expert PostgreSQL, projet auquel j'ai contribué et suis reconnu en tant que PostgreSQL Major Contributor. J'ai contribué en particulier aux notions d'Extension et d'Event Trigger pour PostgreSQL.

Mon outil de travail principal est Emacs, dont la gestion des modules complémentaires laissait à désirer il y a quelques années. J'avais alors retroussé les manches et développé el-get, encore beaucoup utilisé aujourd'hui. Ce projet bénéficie maintenant d'une équipe de mainteneurs actifs, ce dont je suis très content !

Après avoir découvert le lisp avec Emacs Lisp, je me suis naturellement intéressé à Common Lisp… et c'est aujourd'hui mon langage de programmation préféré, ou secondaire dirait James Hague. Et comme le projet pgloader avait besoin d'être revu complètement, je l'ai réécrit en Common Lisp. C'est le projet libre auquel j'accorde aujourd'hui toute mon attention, et j'ai eu beaucoup de retours d'utilisateurs ayant migrés des bases complètes vers PostgreSQL en une seule commande.

Jdh : Commençons par ta participation au projet PostgreSQL. Peux-tu nous dire comment tu en es venu à l'utiliser et nous décrire rapidement ton parcours de, j'imagine, simple contributeur à PostgreSQL Major Contributor ?

Dimitri :Dans le cadre de mes études (IUT Génie Informatique puis École d'Ingénieur, l'ISTY, dépendante de l'université de Versailles) nous avions des cours de base de données relationnelle. À l'école rien n'était installé pour les travaux pratiques et j'ai donc porté la demande auprès de notre administrateur système, et nous avons fini par installer PostgreSQL.

J'ai alors découvert un projet facile à utiliser et dont la documentation complète permet de comprendre le fonctionnement du produit dans son intégralité. Et surtout, chaque commande présentée dans la doc fonctionne exactement comme elle est présentée. C'est reposant ;)

Plus tard, j'ai créé avec des copains une petite entreprise de services en logiciel libre, très orientée Linux et dont le nom intégrait une référence relativement subtile au site d'information des libristes français le plus visité de l'époque… saurez-vous retrouver le slogan qui a inspiré le nom « Da Linux Boite », ainsi que le vrai nom de l'entreprise (toujours en activité) ?

Rapidement, le marché principal sur lequel nous intervenions avec succès étant PostgreSQL, nous avons adapté notre organisation et notre offre commerciale afin de nous concentrer sur cette technologie, ses usages et ses difficultés.

Cette expérience m'a permis de travailler ensuite en tant que DBA (DataBase Architecte plutôt qu'Administrateur, PostgreSQL permettant d'aller beaucoup plus loin que les bases de données relationnelles telles qu'elles sont habituellement envisagées). Dans ce rôle de DBA avancé, j'ai eu l'occasion de mettre au point une extension dédiée au métier d'opérateur téléphonique, comprenant un type de données avec support d'indexation spécifique.

Ce développement m'a permis de découvrir les API et outillages internes de PostgreSQL, et de commencer à lire le code de mon SGBDR préféré. Ce projet a également été l'occasion de comprendre l'étendue du support apporté sur le canal IRC #postgresql sur freenode, où j'ai été accompagné et conseillé dans mes découvertes.

Du coup en parallèle au développement de l'extension prefix et de mon apprentissage approfondit des aspects internes de PostgreSQL (le produit, le projet et la communauté), je participe beaucoup aux listes officielles où je propose mon avis sur tous les sujets qui me plaisent, c'est à dire presque tout ce qui s'y passe… en m'efforçant de toujours rester constructif et faire avancer la situation.

La suite est une histoire habituelle de l'Open Source : la communauté est accueillante, la documentation pourrait être améliorée et c'est le premier patch. Ma première contribution à PostgreSQL est facilement visible encore aujourd'hui, il suffit de comparer la page dans la version 8.3 avec celle de la version 8.4.

Le plaisir d'avoir pu contribuer à un projet aussi reconnu que PostgreSQL m'a donné la motivation nécessaire à passer à la vitesse supérieure. S'il était déjà facile de réaliser une extension incluant un type de données et son indexation spécifique, la restauration des sauvegardes de bases utilisant les extensions était… à revoir. Je m'y attelais et contribuais les commandes CREATE|DROP|ALTER EXTENSION ; cela constitue ma première contribution au code (en C) de PostgreSQL.

Pour le bénéfice des lecteurs de cette interview, je me permettrais de conseiller un projet moins ambitieux dans le cadre d'une première contribution : ce projet là a duré plus de 2 ans et demi et n'a pu aboutir que grâce à ma participation aux Developer Meeting à Ottawa. Sans la rencontre en personne avec les développeurs, les chances de succès d'une telle entreprise auraient été nulles. L'appui sérieux de mon employeur de l'époque (Hi-Media, merci Franck !) a été fondamental.

La meilleure façon de commencer à contribuer à un logiciel Open Source reste la correction de bugs. La mise au point du premier correctif peut prendre plusieurs semaines, ou plusieurs mois, car il est nécessaire de se familiariser avec le code, les APIs, les usages, l'environnement de tests, la documentation, les outils de communication de la communauté du projet (des mailing-listes pour PostgreSQL, une Pull Request consiste à envoyer un patch obtenu avec la commande diff en pièce jointe à son mail dans lequel on décrit le travail réalisé). La mise au point du correctif suivant est en général beaucoup plus rapide, compter quelques heures ou quelques jours. Et si l'on est régulier dans la correction de bugs, on est rapidement intégré et apprécié dans le projet !

Et pour terminer de répondre à la question, le projet PostgreSQL est assez bien organisé, jusque dans la reconnaissance de ses contributeurs. Après 2 ans et demi et 31 versions du patch pour la gestion intégrée des extensions, j'ai donc été reconnu PostgreSQL Major Contributor, ce qui est clairement visible sur la page de référence de la communauté.

Jdh : Peux-tu nous en dire un peu plus sur pgloader, un projet qui approche les 700 étoiles sur ton compte GitHub et qui semble avoir une histoire mouvementée (TCL, puis Python puis Common Lisp si je me réfère au README du projet) et ton rôle dans ce projet ?

Dimitri : En 2005, si je me souviens bien, nous avions un projet de migration d'INFORMIX à PostgreSQL. Il était assez facile d'extraire les données de la base source sous un format relativement proche du CSV, mais très facétieux, et l'outil de référence de chargement de CSV facétieux à l'époque était déjà pgloader, en TCL et peu maintenu.

Après avoir tenté de modifier le code TCL pour de la gestion d'encoding et de chaînes binaires, j'ai préféré reprendre le code (très simple à l'époque, il ne gérait que la reprise sur erreur autour de COPY) pour lui ajouter les options avancées de lecture du format improbable que nous avions à charger, et à l'époque Python a été mon choix.

Le format de configuration de pgloader était alors un .INI dont nous avons assez rapidement atteint les limites. J'ai voulu alors implémenter une configuration avancée avec une grammaire propre, et je me suis heurté de plein fouet à l'incompatibilité de certaines libs python entre les versions 2 et 3 du langage.

Dans la même période, pgloader montrait des faiblesses en terme de performances, et personnellement j'avais découvert Emacs Lisp et réalisé un projet conséquent dans le langage, je voulais investiguer Common Lisp.

Après avoir joué un peu avec Common Lisp sur d'autres projets annexes, convaincu par son mode de développement interactif et la modernité des outils proposés par le langage, j'ai développé un prototype du nouveau pgloader lors d'une migration de MySQL vers PostgreSQL chez un client.

Le pgloader nouveau était alors un projet en cours, et aujourd'hui nous avons de nombreux utilisateurs qui migrent leurs données en une ligne de commande, ou bien importent chaque nuit des quantités de données importantes avec reprise sur erreur automatique.

L'impact principal du choix de Common Lisp réside dans la capacité à développer une nouvelle fonctionnalité, entreprendre un refactoring avancé du code ou bien fixer un bug dans un temps record. Étant donné que pgloader est un projet que je fais vivre sur mon temps libre, pouvoir faire en 2h un soir ce qui me prenait autrefois toutes mes soirées de la semaine est un avantage indéniable !

Au niveau de mon rôle dans le projet, aujourd'hui je suis seul à m'occuper de tout. J'aimerais réussir à construire une équipe de développement et de maintenance comme j'ai pu le faire avec el-get par exemple, et je pense que pgloader est maintenant assez mûr pour cela.

Jdh : Tu me tends une perche que je vais m'empresser de saisir. Tu es également le créateur du projet el-get, qui est, sauf erreur de ma part, un outil pour installer simplement des extensions ou des scripts externes pour Emacs. Peux-tu m'en dire un peu plus sur ton utilisation d'Emacs et comment tu en es venu à écrire cet outil ?

Dimitri : À l'époque où j'ai démarré el-get, mon utilisation d'Emacs ressemblait déjà beaucoup à celle d'aujourd'hui : écriture de code et de documentation, shells interactifs avec M-x shell, emails avec gnus, IRC avec rcirc, le tout avec escreen afin de ne pas perdre la tête.

Ma configuration est en fait une personnalisation avancée de l'outil, avec par exemple des raccourcis me permettant d'adapter le visuel (taille et emplacement des fenêtres, disposition automatique pour IRC en fonction de la taille de l'écran, et plus de modifications aux fonctions de base proposées par Emacs que je ne puis m'en souvenir).

On en est au point où j'ai plus de 5000 lignes de code personnel chargé à chaque lancement d'Emacs (environ une fois par mois), et où je maintiens une configuration minimale (de 150 lignes) : je ne sais plus utiliser Emacs sans quelques changements clés.

Lorsque je commence el-get, il n'existe pas encore de solution de packaging intégrée à Emacs et il faut trouver et maintenir des scripts Emacs Lisp plus ou moins maintenus, souvent sur Emacs Wiki, et les gérer et les distribuer soi-même. L'idée de fond était de pouvoir maintenir une configuration déclarative d'une part, et un jeu de « recettes » faciles à échanger d'autre part.

Le projet a bien marché, si on utilise à nouveau la mesure des stars de GitHub on est à plus de 1200 aujourd'hui, et surtout, le projet est maintenu par une équipe et je ne fais plus grand chose : c'est le plus beau succès de l'Open Source, devenir simple utilisateur de son propre projet.

Jdh : Pour revenir à PostgreSQL et sauf erreur de ma part, tu es le président de la société Second Quadrant France, qui fournit du service autour de PostgreSQL. En tant qu'entrepreneur du Libre, je suis intéressé par ce modèle. Peux-tu nous détailler un peu l'histoire de cette société et quelles sont ses activités aujourd'hui ?

Dimitri : Apporter les valeurs du logiciel libre aux entreprises est quelque chose d'important pour moi, et créer une société de service et d'expertise PostgreSQL s'inscrit pour moi parfaitement dans cette ligne.

2ndQuadrant a été créée il y a environ 15 ans et emploie aujourd'hui un nombre très importants de contributeurs PostgreSQL. L'idée étant que le seul moyen d'apporter de l'expertise sur un logiciel libre est de participer à son développement. Il s'agit bien sûr de proposer des améliorations (correctifs, nouvelles fonctionnalités, etc) mais aussi de s'engager dans le processus de développement (revue de code, participation aux discussions de conception et de choix des fonctionnalités sur lesquelles travailler, etc.).

J'ai eu la chance de pouvoir établir 2ndQuadrant en France en créant l'entreprise avec mon associé Cédric Villemain. Aujourd'hui cependant ma situation personnelle m'a aiguillé vers un nouveau rôle, et je laisse 2ndQuadrant aux soins compétents et éclairés de Cédric.

Les activités de 2ndQuadrant sont toutes centrées autour de la notion de service et d'expertise PostgreSQL et couvrent toutes les étapes de l'utilisation de la solution de traitement de données préférée de tous ses utilisateurs : formation, conception, optimisation, gestion de la production (outils, méthodes, processus, interventions en cas d'incidents), support 24×7, accompagnement, développement à façon, etc.

Vous pouvez retrouver l'ensemble de nos services sur le site de 2ndquadrant.

Pour illustrer le modèle de 2ndQuadrant, prenons l'exemple du support : il est réalisé par des contributeurs PostgreSQL et nous nous engageons à corriger nous-mêmes les avaries logicielles rencontrées par nos clients. Nous nous y engageons car nous disposons du savoir faire requis, simplement parce que les équipes de 2ndQuadrant sont distribuées dans plus de 15 pays couvrant l'ensemble des fuseaux horaires et sont constituées de contributeurs PostgreSQL.

Cela permet en outre aux contributeurs PostgreSQL de 2ndQuadrant de mieux comprendre les besoins des utilisateurs et de les adresser de manière précise et efficace en développant les fonctionnalités les plus utiles dans chaque nouvelle version de PostgreSQL. On peut ainsi parler de cercle vertueux.

C'est le modèle le plus classique de service en logiciel libre, et pour approfondir le sujet je recommande la lecture des livrets bleus édités par le groupe Systematic. Les livrets sont disponibles en ligne aux liens suivants (format PDF disponible gratuitement) ici et .

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Classé dans : Entretien - Mots clés : aucun

Liens intéressants Journal du hacker semaine #14

Rédigé par Cascador - -

Pour la 14ème semaine de 2016, voici 5 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Ouverture du Framaboard et appel à contribution

Rédigé par Cascador - -

Quelques chiffres pour commencer concernant le Journal du hacker :

  • 238 utilisateurs inscrits
  • Plus de 4800 liens publiés
  • Plus de 1400 abonnés Twitter
  • 262 abonnés Diaspora*
  • 4 modérateurs
  • 2,3 Tonnes de cookies utilisés

Le Jdh a connu une croissance importante et la communauté qui gravite autour continue d'augmenter chaque jour.

Forte de cette communauté grandissante nous souhaitons ouvrir encore davantage le projet et notamment la liste des tâches et idées que nous avons sur le Framaboard du Jdh.

Il y a toujours quelques bugs à corriger, de bonnes idées à partager, des choses à améliorer. Vous êtes les bienvenus pour vous emparer de cet outil qui est le vôtre.

Carl Chenet qui est seul sur la partie technique a besoin d'un coup de main notamment. Pour rappel le Jdh est basé sur le projet lobste.rs codé en Ruby on Rails, HTML, Javascript et CSS.

Les grands chantiers pour 2016 sont à l'heure d'aujourd'hui :

  • Scinder la sauvegarde du Jdh en deux. D'un côté une partie confidentielle avec notamment login, mot de passe, adresse mail des utilisateurs inscrits que 2-3 modérateurs maximum possèderont dans un but de confidentialité et de sécurité. D'un autre côté une partie publique librement accessible à tous et téléchargeable contenant les infos soumises, les commentaires, les votes afin que tout à chacun puisse récupérer la valeur produite par le Jdh et la réutiliser dans la grande tradition de l'open data et de l'esprit de partage du Logiciel Libre
  • Se synchroniser avec le projet lobste.rs en amont afin de bénéficier des dernières corrections et améliorations du projet
  • Corriger des bugs

Si vous souhaitez contribuer :

  • Vous pouvez prêter main forte à Carl techniquement
  • Vous pouvez nous soumettre vos idées et suggestions
  • Vous pouvez vous inscrire sur le Framaboard pour vous occuper avec nous des tâches qui rendront le Jdh encore meilleur
  • Vous pouvez continuer à soumettre des tonnes d'infos sur le Jdh ;)

Je vous invite à m'envoyer un message si vous désirez un compte sur notre Framaboard et nous vous invitons à laisser vos suggestions et commentaires ici.

Liens intéressants Journal du hacker semaine #13

Rédigé par Cascador - -

Pour la 13ème semaine de 2016, voici 5 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Fil Rss des articles