Liens intéressants Journal du hacker semaine #2

Rédigé par Cascador - -

Pour la 2ème semaine de l'année 2022, voici 10 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 :)

Liens intéressants Journal du hacker semaine #21

Rédigé par Cascador - -

Pour la 21ème semaine de l'année 2018, voici 12 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 Cédric Moreau, développeur d'outils pour les monnaies libres

Rédigé par Carl Chenet - -
Cédric Moreau, lead dev Duniter

Jdh : Bonjour Cédric 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 ?

Cédric : Bonjour Carl, et merci pour cette interview. Je m'appelle Cédric Moreau alias cgeek. Je suis un ingénieur en automatique et informatique de 29 ans, et surtout je suis développeur depuis mes 18 ans. Je vis sur Rennes avec ma compagne, et aussi j'ai un chat.

J'ai débuté ma vie post-études par 3 années de salariat en SSII, dans lesquelles j'ai commencé par maintenir puis produire des applications Java et JavaEE principalement. La 3ème année, donc 2015, fut l'occasion pour moi de travailler à 100% avec mon langage favori du moment : le JavaScript, sur Node.js.

Depuis 1 an, donc mars 2016, je suis freelance : j'ai créé ma société l'EURL Art et Zerty. Je continue de travailler pour des SSII, mais je me sens plus libre !

Mais le plus intéressant pour le Journal du hacker, c'est que je développe depuis l'été 2013 le logiciel Duniter, premier logiciel de l'histoire (un logiciel libre bien entendu) à permettre la production d'une monnaie libre décentralisée. Je suis le fondateur de ce logiciel et aussi le principal développeur. C'est mon fil rouge depuis bientôt 4 ans, et je crois bien qu'il le restera jusqu'à la fin de ma vie désormais.

Jdh : La monnaie semble prendre depuis quelques années une place grandissante dans l'informatique moderne. On pense immédiatement aux crypto-monnaies, comme le Bitcoin. Peux-tu rapidement nous préciser ce que tu entends par "monnaie libre" et ce que permet Duniter ?

Cédric : La « monnaie libre » est un concept nouveau, de la même façon qu'a pu l'être le logiciel libre dans les années 1980. Il y a d'ailleurs de grandes similitudes entre ces deux concepts car tous deux s'attachent aux libertés de l'utilisateur ; celles logicielles pour le logiciel libre et celles économiques pour la monnaie libre, et définissent quatre libertés fondamentales : les unes logicielles, les autres économiques.

Résumons ces quatre libertés pour la monnaie libre :

  • l'utilisateur est libre de choisir la monnaie
  • l'utilisateur est libre d'accéder aux ressources
  • l'utilisateur est libre d'estimer ce qui est valeur ou pas
  • l'utilisateur est libre d'échanger « dans la monnaie »

Attention : les mots ont beaucoup de sens et je dois ici les préciser. Notamment il faut bien comprendre que « libre » ne signifie pas « n'importe quoi » et que donc par exemple, dire que l'utilisateur est libre d'accéder aux ressources ne signifie pas qu'il pourrait s'approprier toutes les ressources et qu'il n'en reste plus pour les autres. La liberté se définit ici comme non-nuisance : c'est-à-dire que tout utilisateur devrait pouvoir accéder aux ressources, tout en laissant suffisamment de celle-ci en qualité et quantité pour les autres utilisateurs. Ou encore pour la liberté 1, ce n'est pas parce qu'un utilisateur choisit une monnaie que celle-ci devrait s'imposer aux autres.

De même, il ne faudrait pas tomber dans le piège logique qui consisterait à croire que la monnaie libre garantirait ces libertés, au sens où elle forcerait leur application. Il serait par exemple erroné de penser qu'adopter une monnaie libre vous permettrait immédiatement de récupérer l'or qui se trouve chez votre voisin.

Non : une monnaie est dite « libre » si elle est compatible avec ces 4 libertés, c'est-à-dire si son code monétaire ne les bafoue pas. Par exemple l'euro n'est pas une monnaie libre car elle a cours légal, elle est donc imposée. De même l'or ou le Bitcoin ne sont pas des monnaies libres puisque ce sont principalement les « mineurs » qui la produisent : les libertés 2, 3 et 4 ne sont pas respectées.

Enfin il faut bien comprendre que l'on parle ici de « monnaie libre » au sens défini par la Théorie Relative de la Monnaie (TRM), un ouvrage réalisé et publié sous licence GPLv3 par l'ingénieur Stéphane Laborde. De même que « logiciel libre » référence le sens défini par rms. Il ne faut donc pas s'offusquer que cette définition ne soit pas celle que pourraient imaginer d'autres personnes, par exemple celles qui diraient plutôt qu'une monnaie est dite « libre » si elle peut être produite par n'importe qui. C'est un point de vue possible, mais il se trouve que la définition qui nous intéresse est celle donnée par la TRM. C'est donc notre point de départ.

Que vient faire Duniter là-dedans ? Eh bien tout simplement : il permet de réaliser une monnaie libre. En termes de POO, on peut dire que Duniter implémente la monnaie libre telle que définie par la TRM.

Le logo de Duniter

Jdh : Si je comprends bien Duniter est la boîte à outil pour créer une (et pas "la") monnaie libre ? J'imagine donc que la création d'une monnaie libre est l'un de vos objectifs. Où en êtes-vous à ce niveau ?

Cédric : Oui, « une » monnaie libre. Car la monnaie libre n'est pas forcément numérique, ni même n'a besoin de Duniter pour fonctionner. Par exemple, des personnes souhaitant réaliser dès à présent une monnaie libre papier peuvent le faire.

Mais le problème du papier est que cela est coûteux à mettre en place, à la fois en temps et en ressources. Qui plus est, afin de vérifier que les billets papiers sont bien émis selon un Dividende Universel et qu'il n'existe pas des membres émettant de faux billets, il faut à un moment exercer un contrôle par l'informatique. Démarrer directement avec un système informatique est en réalité bien plus simple et accessible, surtout si l'on souhaite une monnaie avec un nombre conséquent d'utilisateurs qu'il faut par ailleurs eux-mêmes contrôler pour vérifier qu'il n'existe pas de double compte, et qui permettraient à leur auteur de produire plus de monnaie que les autres. Cette mécanique de vérification d'unicité des membres s'appelle « Toile de Confiance ».

Il faut bien comprendre : la toile de confiance est propre à Duniter, ce n'est pas une propriété d'une monnaie libre. Il se trouve que la monnaie libre implique d'avoir des individus identifiés pour la production du Dividende Universel, c'est pourquoi Duniter établit la toile de confiance. Mais bien d'autres systèmes pourraient exister.

Et donc, où en est-on ? Eh bien, après 3 ans et demi de développements, le 8 mars 2017 à 16h32, nous avons lancé la toute première monnaie propulsée par Duniter ! Nom de code : Ğ1. L'annonce officielle a été faite sur le site duniter.org.

Cette monnaie a déjà été adoptée par 73 utilisateurs, et totalise 18.220 unités à ce jour. Et comme il s'agit d'une monnaie libre, quotidiennement cette valeur augmente car tous les membres co-produisent leur part de monnaie chaque jour : ainsi ce midi vers 13h00, je vais moi-même produire 10,00 Ğ1 sur mon porte-monnaie personnel. Comme tous ceux ayant adopté cette monnaie et faisant partie de la toile de confiance.

Décollage de Ğ1, la première crypto-monnaie libre

Jdh : Quand je pense à une crypto-monnaie particulière, il me vient immédiatement à l'esprit son contexte d'utilisation, souvent initiée par ses créateurs et ses premiers utilisateurs.

Qu'en est-il pour le Ğ1 ? Quels sont les cas d'utilisation concrets que vos utilisateurs aujourd'hui en font ou devraient en faire dans un proche futur ?

Cédric : Pour le moment, nous n'en sommes qu'au tout début. La monnaie me semble encore peu utilisée économiquement, bien que l'on commence à voir fleurir les premiers paiements en Ğ1 : on peut noter par exemple le restaurant Nantais Etrillum qui accepte officiellement de servir des repas payés en Ğ1, ou encore le café aux RML9, tout comme s'organise pour ces mêmes RML9 un covoiturage en minibus dont une participation en Ğ1 est acceptée.

Les principales transactions que l'on peut voir passer en blockchain sont surtout des dons, notamment à ceux qui mettent à disposition un nœud Duniter pour faire fonctionner la monnaie, aux développeurs de Duniter et de ses clients (Sakia, Cesium, Silkaj) et plus généralement aux personnes qui s'investissent dans le développement de Ğ1. Mais je ne vérifie pas tout ce qui s'y passe, et il y a peut-être des échanges qui se réalisent sans que je puisse les mesurer !

Il faut dire aussi que nous ne possédons pas encore de place de marché mettant en lien acheteurs et vendeurs de biens et services payables en Ğ1. C'est toutefois en projet, on connaît déjà le nom de ce futur service : ğchange, développé par kimamila, l'auteur de Cesium. ğchange se présentera sous forme de site web et fonctionnera avec des pods à la Diaspora* ou Mastodon. C'est à mon avis le service essentiel qui permettra de faire un véritable bond en avant dans la valorisation et l'utilisation de Ğ1. Au niveau technos, ğchange se base actuellement sur des nœuds ElasticSearch et un front basé sur Ionic 2. Et je crois qu'à ce sujet, toute aide est la bienvenue !

Pendant ce temps, nous nous efforçons d'intégrer des nouveaux membres dans la toile Ğ1 afin qu'ils puissent eux aussi participer à cette économie naissante, et fassent grandir cette toile en certifiant les personnes qu'ils connaissent. Pour donner une idée, nous sommes 73 membres actuellement et nous avons environ 300 personnes dont l'inscription est en attente. Ce week-end du 8-9 avril, entre 3 et 4 membres devraient entrer. Il y a donc du chemin à faire sur ce point !

Jdh : Tu évoques ici Sakia, Cesium et Silkaj. Tu nous as parlé de ce que faisait Duniter mais peux-tu expliquer leurs rôles respectifs de ces autres programmes ?

Cédric : Si Duniter est le cœur du réseau Ğ1, Sakia, Cesium et Silkaj en sont les éléments périphériques permettant de s'y connecter. On parle de client. Pourquoi avoir des clients ? Tout simplement car tout utilisateur n'a pas forcément besoin d'exécuter Duniter sur sa machine, qui suppose d'être connecté en permanence, de télécharger l'intégralité de la blockchain et d'utiliser ses ressources pour vérifier son intégrité et calculer les prochains blocs. Les clients sont en fait des outils dialoguant avec le réseau Duniter (le cœur) pour y réaliser des opérations, comme envoyer et recevoir de la monnaie, rejoindre Ğ1 en tant que membre ou encore certifier ses semblables.

Logo de l’application Cesium, application web cliente pour Duniter

Sakia est le client historique, écrit en python. C'est une application de bureau installable sur la plupart des distributions Linux. Ce client permet de réaliser l'intégralité des opérations du réseau Ğ1 (transactions, toile de confiance). Il permet également une supervision réseau basique.

Cesium est le pendant web de Sakia. C'est-à-dire que cette application a les mêmes fonctions, mais cette fois-ci dans un navigateur. Elle a également la réputation d'être plus simple pour un nouveau venu non-informaticien. Et pour cause, il suffit d'une connexion Internet pour y accéder.

Silkaj est le dernier né de la tribu. C'est un client en ligne de commandes. Jusqu'à il y a peu, il ne permettait que d'explorer le réseau et afficher quelques informations techniques. Mais depuis peu, il est également capable d'effectuer des transactions : on peut donc désormais envoyer et recevoir des Ğ1 en ligne de commandes ! Ce qui peut être très pratique pour des tâches d'automatisation, comme effectuer des paiements réguliers.

Jdh : C'est super, le projet bouge dans tous les sens. Dans tes rêves les plus fous, quel serait l'usage et la place occupée par Ğ1 dans notre société ?

Cédric : Dans mes rêves les plus fous, nous sommes un million d'utilisateurs. Cela peut paraître un « petit rêve pas si fou » et peu en rapport à la population française (67 millions, donc seulement 1 utilisateur sur 67 français), mais quand on regarde le Bitcoin et son impact déjà colossal en 2014 avec une estimation à cent mille utilisateurs, faire dix fois plus, n'est-ce pas déjà prodigieux ? Imaginer qu'un million d'utilisateurs produisent chaque jour sa part de monnaie et soit donc capable de dire lui-même ce qui est valeur ou non à ses yeux à la place du banquier, imaginons que 10% d'entre eux soient des développeurs de logiciels libres, n'aurait-on pas là un formidable tremplin pour leur développement ? De même pour de nombreuses autres valeurs, et au détriment de celles que ces mêmes utilisateurs de monnaie libre ne souhaitent plus développer mais qui le faisaient par besoin ou obligation du fait du monopole des banquiers en monnaie non-libre ?

Logo de Ğ1, la première crypto-monnaie libre

Je ne sais pas quel serait précisément l'usage de la monnaie libre, puisque je ne sais pas ce que souhaitent développer les humains. Nous avons tous notre point de vue sur la question. C'est la raison même d'exister de la monnaie libre, reconnaître qu'on ne sait pas dire ce qui est « production » et ce qui ne l'est pas, étant un point de vue relatif. Je trouve les logiciels libres de grande valeur et les logiciels privateurs d'une moindre valeur. Tout le monde n'est pas d'accord avec ça. Et donc si ces humains pouvaient désormais s'adonner en partie à développer les valeurs qui leurs sont chères, vers quoi nous dirigerions-nous ? On peut en avoir une petite idée en jouant à Ğeconomicus, le jeu de simulation de la monnaie libre sur une durée de 80 ans. Je ne donnerai pas de résultats, je laisse les intéressés aller les trouver ou tout simplement aller jouer à ce jeu. Mais assurément, c'est une perspective qui me plaît et m'apaise profondément.

Et là on peut se dire qu'avec nos 73 petits utilisateurs, on en est loin. Oui mais, nous étions 59 il y a 30 jours, ce qui fait une croissance de 23% en un mois. Si une telle croissance durait ne serait-ce que 3 années, nous aurions déjà le nombre d'utilisateurs que Bitcoin a eu en 5 ans. Alors, est-on si loin de ce doux rêve ? Je ne crois pas !

Jdh : Je te remercie pour cet entretien.

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

Entretien avec Frank Rousseau, co-fondateur de Cozy Cloud

Rédigé par Carl Chenet - -

Jdh : Bonjour Frank 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 ?

Frank : Ah tout de suite une question difficile ! J'ai 33 ans, j'ai toujours aimé bidouillé des sites web et des web apps en dehors de mes études (d'informatique) et de mon boulot.

Je ne me suis mis au dev de logiciel libre sérieusement il y a 5 ans. J'ai commencé par développer un projet de réseau social distribué en Python sur mon temps libre. Ça m'a permis de monter un projet propre avec ma façon de faire. Puis j'ai +enchaîné sur le projet Cozy, cette fois à temps plein, une plateforme pour rendre le serveur personnel simple d'utilisation (basée surNode.js et codée enCoffeeScript).

A côté de ça j'ai toujours beaucoup travaillé sous Linux (Slackware, Debian et Ubuntu) et mon éditeur de prédilection est Vim.

Cozy s'est fait autour d'un projet entrepreneurial. Ce qui m'a permis d'évoluer dans le monde du Logiciel Libre à plein temps depuis maintenant 4 ans. En plus de Cozy j'ai maintenu quelques bibliothèques Node.js que nous avons extraites du projet. C'est une expérience d'autant plus intéressante que je suis passé par étapes, de développeur seul à leader technique d'une équipe de 10 personnes de haut niveau. J'ai du aussi gérer pas mal d'aspects produits et marketing pour structurer le projet et le faire connaitre. Et par dessus tout ça, j'ai vu notre communauté grandir, comme vous le comprenez c'est une sacré aventure !

Jdh : Peux-tu nous en dire un peu plus sur ce premier réseau social distribué que tu as lancé et comment ça a influencé ta vision pour arriver à l'idée de Cozy ?

Frank : Ce réseau social s'appelle Newebe. J'ai commencé à y réfléchir à l'époque de la prise de conscience générale sur le fait que Facebook, de part son architecture, stockait toutes nos conversations. Peu de temps après le réseau social Diaspora* faisait son buzz. Cela semblait être une bonne solution mais je n'étais pas satisfait de leur approche fédérative. Diaspora* permettait d'avoir plusieurs nœuds basés sur du Logiciel Libre plutôt qu'un nœud central basé sur du code propriétaire. C'était un gros progrès mais il y avait toujours un intermédiaire. Même problème avec les approches plus anciennes basées sur XMPP. Aujourd'hui, je suis moins extrême sur la question mais à l'époque je considérais que ça déplaçait le problème sans le résoudre.

Je me suis donc dit qu'il fallait une autre approche. Je suis parti de l'utilisateur en considérant que chaque nœud devait représenter son propriétaire. J'en ai déduit qu'il fallait faire une interface web adossée à une API Rest que chacun héberge chez soi. En faisant communiquer les instances d'API entre elles, on obtiendrait un réseau social complètement distribué. C'était beaucoup plus difficile que prévu à réaliser mais je suis tout de même arrivé à quelque chose qui marche. A ce moment là, Newebe ne gérait que le microblogging. Mais là j'avais envie de permettre d'ajouter d'autres applications sociales qui profiteraient des fonctionnalités de communication de Newebe pour collaborer de manière distribuée.

NB : Voici la spec que je m'étais écrite avant de commencer Newebe.

Ce réseau social n'a pas eu beaucoup de succès et je ne suis donc pas allé au bout du concept. Mais cette expérience m'a donné les prémisses de ce que nous allions faire sur Cozy. Mon expérience de Newebe m'a influencé sur bien des aspects dans Cozy mais voici les principaux qui me viennent à l'esprit :

J'avais remarqué que faire un réseau social demande non seulement de faire basculer l'utilisateur mais aussi tous ses amis. Ce qui est très compliqué avec une approche distribuée / auto-hébergée. Pour Cozy, ce constat nous a conforté dans notre choix de nous focaliser sur des usages persos plutôt que sociaux / collaboratifs. Techniquement c'est plus simple et ça ne demande pas à l'utilisateur de demander à tous ses amis de passer à l'auto-hébergement.

J'avais aussi constaté via l'approche CouchDB que le fichier n'est qu'une représentation de la donnée. Ce n'est donc pas le bon support pour représenter les données de l'utilisateur. C'est pourquoi dans Cozy nous nous sommes concentrés sur les documents JSON comme axe de représentation de la donnée.

Pour les choix de techno, mon expérience de Tornado m'a poussé vers Node. J'avais été convaincu par l'approche de serveur web asynchrone (requête non-bloquantes) de Tornado. Node suivant cette philosophie et étant très bien outillé pour le développment web, nous avons choisi de basculer sur cette techno.

L'utilisation de CouchDB dans Newebe nous a permis de démarrer vite sur Cozy car je connaissais déjà cette base de données. Mais aujourd'hui, j'ai des doutes sur la pertinence de ce choix à cause de son système de vues/requêtes un peu particulier.

Enfin, les single-page applications nous ont motivé à fortement découpler le serveur du client. C'est important car nous avons toujours vu Cozy comme un point de pivot des données de l'utilisateur. Ainsi n'importe quel type de client peut s'y connecter (mobile, CLI, appli desktop, etc.)

Au-delà de ça, avec Newebe, je me suis beaucoup intéressé au life-logging, au quantified-self et aux assistants personnels. Ces univers sont de bonnes sources d'inspiration pour donner une direction à Cozy !

NB : Un lien de réflexions liées à Newebe.

Bref tout ça pour dire que le travail fait sur Newebe m'a beaucoup aidé pour apporter les premières briques de Cozy.

Jdh : Venons-en à Cozy. Comment est né le projet ? Quelles ont été les motivations à l'origine du projet ? Quelle a été ton approche au début du projet et à quel moment as-tu commencé à sentir que cela mènerait loin ?

Frank : Fin 2011, je me retrouve brutalement au chômage avec quelques indemnités. Ça faisait un moment que je voulais monter une boîte et cette situation me le permettait. J'avais lu quelques bouquins sur le sujet et je me mettais donc en veille en commençant à penser à des idées avant de me lancer (je voulais finir avant un projet de bouquin photos auquel j'avais participé). Un soir de décembre, en lisant un post sur le Framablog à propos de la vie privée, je tombe sur un commentaire un peu particulier d'un certain Benjamin qui cherche à monter un projet d'entreprise pour proposer une solution. Un peu hésitant au départ, je me dis que ça tombe plutôt bien et que je ferais mieux de le contacter. Après s'être rencontrés, on se rend compte qu'on est totalement sur la même longueur d'ondes. Rapidement on s'y met. Il avait une vision business alors que j'arrivais avec une vision technique, ça collait bien. On a trouvé un nom au projet, on a fait les premiers protos, on a pris un nom de domaine, monté un site web, on s'est organisé et on a monté la boite.

Au final, ça nous a pris du temps pour se décider sur comment tout ça allait marcher, mais après de nombreux mois (presque un an !), nous voilà avec une société enregistrée au tribunal de commerce, un joli site web et de quoi quoi déployer nos protos de Cozy. Tout ça nous a pris pas mal de temps. Un stagiaire, Lucas, nous avait rejoint pour nous aider sur la partie Sys Admin. On ne le savait pas encore mais il allait devenir notre premier employé.

Forts de ce qu'on avait monté, on a pu convaincre Zoé, Romain et Joseph de nous rejoindre. En stage au début et ensuite, à temps plein. Avec eux ça a boosté. Notre proto était de plus en plus fonctionnel. Ça restait bancal mais c'était utilisable et on voyait bien l'intérêt de la plateforme. On a eu de l'exposition dans plusieurs endroits : LinuxFr, LeWeb, Hacker News, Mozilla WebFWD et un article dans le magazine Wired. On a vu une première communauté internationale se former. Là je pense qu'on a commencé à vraiment y croire. Notre histoire prenait forme et on voyait la plateforme progresser de jour en jour. La tuile qui m'était tombé dessus avec ma boite précédente s'est transformée en belle opportunité de faire progresser le schmilblick du lien entre cloud et vie privée.

Pour ce qui est des motivations, notre but était de permettre aux utilisateurs de service web de profiter d'une plateforme simplifiant l'usage du serveur personnel. Avec ce nouvel outil, un utilisateur récupère ses données dans une base de données, en maîtrise les accès et surtout peut y brancher ses périphériques et autres application lourdes. Ainsi on apporte aux gens un meilleur contrôle de leurs données tout en fluidifiant leur vie numérique. Les outils type "silos" sont pratiques mais comme ils sont cloisonnés, ils ne nous facilitent pas vraiment la vie. C'est le principal problème que Cozy résout.

Pour l'approche, comme tu as pu le comprendre, on a fonctionné en itération avec pour objectif d'avoir quelque chose de fonctionnel le plus tôt possible. Ça a pris du temps au début car il a fallu, entre autres, se mettre à l'admin système sérieusement, maîtriser l'écosystème Node alors qu'il était tout jeune et faire une app web "classique" pour que les gens puissent s'inscrire et demander un Cozy. Enfin il a fallu trouver et assembler diverses technos pour faire marcher le tout sans trop réinventer la roue (le déployeur d'apps Haibu et l'indexeur Whoosh notamment). En plus de ça on travaillait avec La Poste et la FING pour réaliser des prestations qui nous ramenaient des sous. Ça nous a pris pas mal de temps mais en restant sur ce mode tout en augmentant notre équipe (grâce à une belle levée de fonds), nous avons pu continuer jusqu'à aujourd'hui et obtenir une belle plateforme pleinement fonctionnelle !

Jdh : Aujourd'hui, combien êtes-vous à travailler sur Cozy ? Quels sont les axes de développement actuels ? J'ai vu passer une offre en partenariat avec OVH et j'ai trouvé intéressante l'initiative. Quelle est ta vision à moyen terme pour Cozy ?

Frank : Aujourd'hui nous sommes une petite vingtaine toutes professions confondues. En développeurs / admins, on est une petite dizaine accompagnée d'une équipe produit de 3 personnes.

Au niveau des développements, on est en train de finaliser notre client desktop et notre webmail. L'équipe est vraiment efficace et nous avons hâte de voir le résultat. On aura enfin une plateforme proposant tous les services de base, auto-hébergeables et sur laquelle tous nos périphériques peuvent se connecter.

La vision à moyen terme de Cozy est de continuer à consolider tout ça et de construire une offre commerciale sous forme de location de Cozy en ligne puis peut-être sous une forme de box à brancher chez soi. On travaille déjà avec Gandi et OVH pour qu'ils nous aident à construire cette offre. On va aussi mettre l'accent sur l'enrichissement des données duCozy via un système de connecteurs. Ce sont des petits scripts qui vont récupérer les données que vous déposez chez vos différents fournisseurs (factures, santé, banque, etc.). C'est un gros différenciateur de Cozy par rapport aux autres clouds et la communauté aime bien ce concept car elle peut +facilement participer.

On va aussi commencer à voir des grosses boites qui déploient leur compte client sur la plateforme (une app pour gérer ses contrats et intéractions). On voudrait aussi développer des fonctionnalités pair à pair au sein du Cozy. Deux chercheurs y travaillent chez nous, on a hâte de voir ce que ça donne !

Jdh : Les lecteurs du Journal du hacker sont très curieux Peux-tu nous donner quelques détails sur les technologies utilisées pour votre infrastructure afin de développer et faire tourner Cozy ?

Frank : A propos de notre infrastructure d'hébergement, il y a pas mal de choses à dire. Tellement que j'aurais été plus à l'aise que nos admins répondent à cette question à ma place. Mais en gros, ils sont deux, Nicolas et Lucas, pour faire tourner 2500 conteneurs Cozy. Un troisième vient les rejoindre (Aeris, que vous connaissez sans doute) pour les aider. Enfin, Cédric développe des outils maison pour mieux gérer notre infra, mais il a un profil développeur. Pour se synchroniser, ils bossent tous sur un mode Kanban.

Pour le matos, on utilise des gros serveurs OVH appartenant au même rack virtuel. Ça nous permet d'avoir un réseau privé pour ces machines. On les découpe ensuite en conteneurs et on met un joli proxy devant pour gérer la distribution des requêtes en fonctions du nom de domaine.

Niveau technos, l'orchestration se fait via SaltStack et nous déployons des conteneurs OpenVZ (en 2016 on voudrait migrer vers LXC). Nous avons aussi pas mal de sondes pour récupérer des données pour faire de la métrologie via une stack Elastic Search / Logstash / Kibana et une stack InfluxDB / Grafana (selon le type de données).

Pour le monitoring, c'est Shinken qui nous réveille la nuit quand survient un problème. Enfin, les backups sont gérés via une solution maison et notre intégration continue se base sur Jenkins. Pour notre outil interne, on a développé une API via Flask et nos données sont stockées dans une base MongoDB. Cet outil nous permettra bientôt de gérer nos conteneurs de manière +uniforme quelque soit le fournisseur de machines (Gandi ou OVH par exemple).

Les conteneurs Cozy font tourner des process Node.js, une base de données CouchDB (Erlang) et des sondes Beaver et collectd. Le tout tourne sur une Debian 8 minimaliste. Les tests des applications tournent sous Travis et sont consultables publiquement.

A côté de ça, on a pas mal d'images à maintenir (Raspberry Pi, Virtualbox, hébergeurs, etc.) ainsi que notre dépôt Debian, Pour couronner le tout, nous avons un conteneur pour chacun de nos outils traditionnels : site web (Metalsmith), documentation (DocPad), blog (Dotclear), wiki, etc.

Comme vous pouvez le voir nos admins sont super-productifs et savent bien jongler avec les technos ! Et en plus ils s'entendent bien avec nos développeurs. Que demande le peuple ?

Jdh : Merci Frank.

Frank : Merci au Journal du Hacker que je suis toujours avec grand plaisir !

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

Entretien avec Tarek Ziadé, engineering manager pour Mozilla Corporation et Pythoniste

Rédigé par Carl Chenet - -

Jdh : Bonjour Tarek 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 ?

Tarek : Je suis développeur depuis une quinzaine d'années et je me suis spécialisé dans le langage Python il y a un peu plus de dix ans.

Je me suis passionné pour l'open source et pour Zope en particulier et j'ai lancé un site web autour de cette techno à l'époque. Avec quelques compères du forum de Zopeur, nous avons fondé l'Afpy (Association Python Francophone).

J'ai aussi écrit trois livres sur Python dont un en Anglais.

Je bosse depuis plus de 5 ans pour Mozilla où j'anime une petite équipe qui écrit des services web.

Jdh : Tu viens d'évoquer Zope, que les anciens de la communauté Python connaissent bien. Quand et comment as-tu commencé à coder avec Python ?

Tarek : J'ai découvert Zope et Python à peu près en même temps. C'est en codant des petites fonctions dans l'admin Zope que je me suis mis à Python sérieusement, il y a plus de 10 ans.

Jdh : Et tu as apparemment pris goût à Python ! Je t'ai découvert grâce à ton excellent livre "Programmation Python - syntaxe, conception et optimisation" à l'époque. Peux-tu nous en dire un peu plus sur ce qui t'a amené à passer du statut de développeur à auteur ?

Tarek : C'est simple : je suis devenu fan de Python et j'ai eu envie de le maitriser au maximum.

Et écrire un livre est la meilleure des techniques : il faut bien maitriser chaque sujet pour pouvoir l'expliquer aux autres.

Ça a été un travail intense de 9 mois. J'y ai passé toutes mes soirées :)

Jdh : Lorsque nous nous sommes connus, tu étais très impliqué dans le développement de certains modules de la bibliothèque standard de Python, en particulier je me souviens de Distutils. Qu'en est-il aujourd'hui de ton implication dans le développement de Python ?

Tarek : J'ai beaucoup travaillé sur Disutils effectivement, car le packaging dans Python souffrait de gros problèmes et personne n'avait envie de s'y coller.

Le plus gros travail a été politique : écrire des PEP (Python Enhancement Proposals) pour faire avancer les standards en mettant tout le monde d'accord, puis un peu de code. Je me suis un peu trop impliqué pendant 2 ans sur le sujet et j'ai vécu un "burnout" le jour où mon travail sur un nouvel outil (Disutils2) qui devait être intégré à la bibliothèque standard a été retiré au dernier moment. Je l'ai mal vécu haha.

Tout ce travail a quand même porté ses fruits puisque le packaging s'améliore grandement et il y a pas mal de choses qui sont issues de mon travail. Certaines parties de Disutils2 ont été recyclées dans d'autres projets aussi.

Un conseil: ne tombez pas dans le piège de comparer le packaging de Python avec ceux très récents comme npm (node) ou cabal (haskell) ou même Debian, et de dire que "le packaging est un problème résolu depuis longtemps", Python est un papy de plus de 20 ans et tout le drame du packaging est de pouvoir difficilement faire table rase de l'existant, surtout dans un éco-système où cohabitent des communautés très différentes. Si vous parlez de packaging avec la communauté scientifique ou avec la communauté web, ce sont deux monde tellement différents qu'il est très dur de trouver des solutions universelles et respectueuses de l'existant.

Aujourd'hui je ne suis plus du tout impliqué dans le développement de Python. Ça prend trop de temps et d’énergie, que je préfère garder pour aller courir ou jouer de la trompette. Mon combat dans le code est maintenant à Mozilla :)

Jdh : La fondation Mozilla et ses projets passionnent les membres de notre communauté. Peux-tu un peu nous décrire quels sont tes projets techniques pour la fondation et ta façon de travailler chez Mozilla ? Lors de notre dernière rencontre tu vivais dans un petit village assez isolé des grands centres urbains.

Tarek : Je bosse pour Mozilla Corporation, qui est financée et dirigée à 100% par Mozilla Foundation, et qui a des salariés dans de nombreux pays. La Foundation en a aussi, distinctement de la Corporation.

Quand je suis arrivé il y a plus de 5 ans chez Mozilla, ma mission était simple : j'étais le premier développeur Python de l'équipe "Services" et mon job a consisté à porter Firefox Sync (alors en PHP) sous Python et mettre en place tout l'éco-système Python.

J'étais le seul européen de l'équipe, et je devais faire des réunions parfois à 2 heures du mat'. À l'époque Mozilla Corp. comptait autour de 350 salariés.

Tout a évolué et s'est structuré, et en 2016 on dépasse les 1000 employés avec beaucoup plus de monde en France (environ 45), et je suis maintenant "engineering manager" d'une équipe de Français dispatchés entre Rennes, Barcelone et Montpellier. Moi-même je suis dans un tout petit bled en Bourgogne (175 habitants).

On travaille en ce moment sur Kinto un service de stockage de données avec une API HTTP Json, écrite en Python avec Pyramid, Cornice et Cliquet. Je ne développe plus trop, je passe plus de temps dans des réunions et dans la gestion des projets Mozilla basés sur Kinto, et sur les échanges techniques avec les gens de mon équipe.

Bosser chez Mozilla est assez confortable en termes de moyens à notre disposition : on peut se rencontrer plusieurs fois par an pour faire des "work weeks", disposer de toutes les ressources nécessaires en ligne (serveurs virtuels etc).

Le seul regret de vivre à la campagne finalement est que ma connexion ADSL est mauvaise, ce qui est pénible pour les vidéoconférences.

Jdh : Peux-tu nous détailler un peu plus les projets sur lesquels tu as travaillé et travaille actuellement pour Mozilla ?

Tarek : En 6 ans de temps j'ai eu le temps de bosser sur beaucoup de projets à Mozilla.

Les plus intéressants :

  • Firefox Sync : J'ai réecris le serveur PHP en Python, en utilisant Gevent
  • Circus : Un gestionnaire de processus
  • Cornice : une surcouche de Pyramid pour écrire des web services
  • Loads : Un outil de load testing distribué

Et plus récemment, Kinto, un service de stockage JSON. Je ne développe quasiment pas dedans vu que j'ai changé de casquette (manager) mais je m'occupe de son intégration au sein de Mozilla pour nos différents besoins.

Kinto est maintenant utilisé par Firefox pour la mise à jour de données régulières. L'idée est de réussir à mettre à jour des informations importantes comme les révocations de certificats, sans avoir à attendre que la prochaine version de Firefox sorte.

Jdh : Firefox Sync est utilisé par le grand public et est donc un projet très visible. On a du mal à imaginer l'ampleur de l'investissement derrière. Peux-tu nous parler un peu des gens et de l'infrastructure derrière une fonctionnalité comme celle-ci ?

Tarek : La partie service web en Python est assez anecdotique, au départ j'étais tout seul à coder dessus. C'est quelques milliers de lignes tout au plus.

Le service web en Python, c'est l'arbre qui cache la forêt, 5% du temps de la requête. La difficulté de ce système est surtout liée à la base de données :

  • la maintenance de plusieurs centaines de serveurs MySQL
  • le sharding des utilisateurs sur toutes ces bases
  • la gestion des migrations des utilisateurs etc

Il y a 6 ans nous étions déployés dans des datacenters et il fallait tout gérer nous-mêmes, par exemple le remplacement des disques durs.

Aujourd'hui tout est déployé sur des services clouds comme AWS. Et c'est le cas pour Kinto : des web heads à la demande et Postgres RDS.

En terme de tests, mon équipe est fière d'avoir un coverage de 100% partout, et nous avons des batteries de tests d’intégration qui se lancent sur Travis-CI

Nous avons un environnement de staging sur lequel nous déployons les nouvelles versions, et une équipe de QA qui se charge d'effectuer la recette le tout avant de nous donner le feu vert. L'équipe de Ops utilise Puppet pour tous nos déploiements.

Jdh : Kinto et Circus ont chacun plus de 1000 étoiles Github, avec un nombre de rapports de bugs importants, ce qui en fait des projets assez populaires. Comment se partage la journée type d'un développeur Mozilla ? Y'a-t-il une répartition du travail entre ce qui est fait pour la communauté directement et pour l'infrastructure Mozilla ? Les deux sont-ils confondus en permanence ?

Tarek : C'est une excellente question. Mon job principal justement, en tant que engineering manager, est de faire converger les besoins de Mozilla avec l'envie de développer des fonctionnalités qui sont utiles à une communauté plus large.

Le principe de base est que chaque grosse fonctionnalité que l'on ajoute dans les projets doit émaner d'un besoin réel dans l'un des projets internes - sans pour autant rendre le projet spécifique à Mozilla.

La signature des données dans Kinto est un bon exemple : nous devons signer toutes les données qui sont envoyées à Firefox pour éviter au cas où notre serveur Kinto serait piraté de servir des données corrompues. Ce serait par exemple la catastrophe pour les certificats SSL.

Cette fonctionnalité a été créée sous forme de plugin optionnel en se basant sur des standards ouverts et un système de configuration complet. En d'autres termes, on peut plugger cette option sur nos serveurs à Mozilla sans l'imposer aux autres utilisateurs de Kinto, mais si une autre organisation veut plugger le système de signature, elle pourra le faire !

L'équipe passe bien sûr un peu de temps sur des fonctionnalités 100% communautaires, qui ne sont pas utilisées à Mozilla - mais ce n'est pas la priorité - même si ce n'est jamais du temps perdu.

Le travail sur les bugfixes et push requests (PR) remontés par la communauté quant à lui, est en général fait rapidement : c'est un cadeau précieux qui nous est fait et il est important de ne pas laisser traîner ce travail - ne serait-ce que par respect pour la personne qui a passé du temps dessus.

Enfin, certains projets peuvent à un certain moment être moins utilisés chez nous, et peuvent continuer à vivre. Circus par exemple est moins utilisé qu'avant, et le projet est maintenu par des gens comme Yannick Péroux qui ne bosse pas à Mozilla, c'est génial ! C'est pour moi un exemple de réussite du modèle open source.

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

Fil Rss des articles de cette catégorie