Introduction à l’économie contributive – Vidéo de Simon Lincelles (Ars Industrialis)

Le Framablog a pris l’habitude de suivre les travaux de Bernard Stiegler au sein d’Ars Industrialis. Il faut dire que ça n’est pas tous les jours qu’un philosophe affirme que « le logiciel libre peut redonner sens à nos vies » !

Nous vous proposons ci-dessous le réplication d’une vidéo de Simon Lincelles intitulée « Introduction à l’économie contributive » et co-écrit par Bernard Stiegler.

Malgré quelques inexactitudes, nous partageons l’hypothèse que le logiciel libre (et Wikipédia) représentent un espoir et un modèle pour l’avenir de notre économie.

Remarque : cette vidéo (lien direct Vimeo) est le troisième épisode d’une série initiée ici.




Cent fois sur le métier remettez vos correctifs… (Libres conseils 12/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : ga3lig, Fred, peupleLa, LAuX, Goofy, jcr83, purplepsycho, Jej, Jean-Noël AVILA, Julius22, kalupa, 4nti7rust, lamessen, okram + Cédric Corazza

Écrire des correctifs

Kai Blin

Kai Blin est un bio-informaticien qui mène des recherches sur les antibiotiques dans le cadre de ses activités quotidiennes, tant sur ordinateur qu’au labo. Il est très heureux de pouvoir diffuser le logiciel développé dans le cadre de ses activités professionnelles sous licence open source. Vivant dans la charmante ville de Tübingen, dans le sud de l’Allemagne, Kai passe une partie de ses soirées sur l’ordinateur, à programmer pour le projet Samba. Il consacre la majorité de son temps libre restant au théâtre, où il participe aussi bien à la performance scénique qu’à la construction d’accessoires et à la régie technique dans les coulisses.

Écrire des correctifs et les proposer est souvent la première interaction concrète que vous pouvez avoir avec un projet open source. C’est la première impression que vous donnez aux développeurs présents. Proposer de « bons » premiers correctifs, ou tout du moins jugés comme tels par le projet auquel vous contribuez, vous rendra la vie plus facile. Les règles précises d’écriture du correctif, de la façon de le soumettre au projet et tous les autres détails nécessaires vont sans doute varier selon les divers projets auxquels vous voulez contribuer. Mais j’ai trouvé quelques règles générales que l’on retrouve presque à chaque fois. Et c’est ce dont traite cet article.

Comment tout foirer

Le fil rouge de ce livre est « ce que j’aurais aimé savoir avant de commencer », aussi permettez-moi de commencer par l’histoire de mes premiers correctifs. J’ai été impliqué sérieusement dans l’écriture de code pour la première fois pendant le Google Summer of Code™ de 2005. Le projet Wine avait accepté que j’implémente un chiffrement NTLM basé sur des outils connexes à Samba. Wine est un projet à committer unique, ce qui signifie que seul le développeur principal, Alexandre Julliard, possède les autorisations de commit sur le dépôt principal. En 2005, Wine utilisait encore CVS comme système de gestion de versions. Quand le projet a démarré et que j’ai reçu le courriel me disant que j’étais accepté, j’ai contacté mon mentor sur IRC et me suis mis au travail.

J’alignais joyeusement les lignes de code et bientôt j’ai pu implémenter les premières fonctionnalités. J’ai produit un correctif et l’ai soumis à mon mentor pour qu’il fasse une relecture. Au temps du CVS, il fallait renseigner toutes les options de diff(1) manuellement, mais je m’étais particulièrement documenté sur la partie cvs diff -N -u > ntlm.patch. De cette façon, j’avais le fichier que je pouvais envoyer à mon mentor. En fait, c’est quelque chose que j’ai bien fait. Et c’est la première chose que vous devriez prendre en compte quand vous préparez un correctif. Le résultat classique de la commande diff est sans doute plus facile à lire pour un ordinateur, mais je n’ai jamais rencontré un humain préférant le résultat classique au résultat d’un diff unifié. Grâce à l’option -u , diff utilise les notations + + + et - - -

Par exemple, le diff qui suit est le résultat de la réécriture de « Hello, World! » en Python, version suédoise.

diff —git a/hello.py b/hello.py index 59dbef8..6334aa2 100644 --- a/hello.py +++ b/hello.py @@ -1,4 +1,4 @@ #!/usr/bin/env python # vim: set fileencoding=utf-8 -print "Hello, world!" +print "Halla, varlden!" 

La ligne qui commence par « - » est la ligne supprimée, celle qui commence par « + » est celle qui va être ajoutée. Les autres lignes permettent à l’outil de correction de faire son travail.

J’ai envoyé le diff unifié que je venais de créer à mon mentor qui m’en a fait une review(2) en me signalant beaucoup d’éléments à modifier. J’ai effectué les corrections et lui ai renvoyé un nouveau diff peu de temps après. Le cycle d’analyse du code a continué durant toute la durée du GSoC et mon correctif ne cessait de grossir. Quand la date de livraison est arrivée, je me suis retrouvé avec un correctif monstrueux dans lequel étaient inclus tous mes changements. Naturellement, j’ai eu beaucoup de mal à obtenir une review de mon correctif, sans parler de le faire accepter. Pour finir, Alexandre refusa de regarder plus avant le correctif tant que je ne l’aurais pas scindé. Les règles en usage chez Wine exigent que les correctifs soient de petites étapes logiques ajoutant une fonctionnalité. Chaque correctif doit faire quelque chose d’utile et pouvoir être compilé.

De fait, scinder un énorme correctif existant en différentes parties cohérentes individuellement et qui peuvent être compilées représente beaucoup de travail. C’était même d’autant plus de travail que je ne connaissais qu’une seule manière de le faire : écrire un petit correctif, créer le diff, le proposer à la validation, mettre à jour ma contribution locale et écrire alors le correctif suivant. Peu de temps après que j’ai commencé à envoyer mes premiers petits correctifs, Wine est entré dans une phase de gel des fonctionnalités d’un mois menant à la version 0.9.0 bêta. Je suis resté sur le correctif suivant pendant un mois avant de pouvoir continuer et j’ai finalement envoyé mon dernier correctif en novembre. Complètement frustré par cette expérience, j’ai décidé que je ne voulais plus jamais avoir à faire avec la communauté Wine.

Ma frustration perdura jusqu’à ce que des personnes qui utilisaient réellement mon code commencent à me poser des questions sur celui-ci en février 2006. Mon code était vraiment utile ! Ils voulaient également davantage de fonctionnalités. Quand Google annonça qu’il reconduirait le GSoC en 2006, mes projets pour l’été étaient clairs. Maintenant que Wine avait basculé de diff à git en décembre 2005, je savais que je ne serais pas ennuyé par des gels de fonctionnalités, puisque je pouvais finalement créer tous mes petits correctifs localement. La vie était belle.

Ce n’est que lorsque je suis tombé sur une interface de git (appelée porcelaine dans le langage git) qui émulait le comportement de Quilt que j’ai appris qu’il y avait des outils qui auraient pu rendre ma vie plus facile, même en 2005.

Comment NE PAS tout foirer

Maintenant que je vous ai raconté comment j’ai réussi à me planter avec l’envoi de correctifs, permettez-moi de poursuivre avec quelques conseils pour éviter les pièges.

Règles pour la soumission de correctifs

Mon premier conseil est de lire attentivement toutes les directives de soumission de correctifs que peut avoir le projet auquel vous voulez contribuer. Celles-ci, ainsi que les normes de style de codage, doivent être consultées avant même de commencer à coder.

Des diffs unifiés

Même si ce n’est pas explicitement indiqué dans les directives de soumission des correctifs, vous devez vraiment, vraiment envoyer le résultat d’un diff unifié. Je n’ai encore rencontré aucun projet qui préfère la sortie non unifiée du diff. Les diffs unifiés rendent la révision du correctif beaucoup plus facile. Ce n’est pas par hasard que les programmes de gestion de version modernes utilisent automatiquement ce format dans leurs commandes diff par défaut.

Utilisez un contrôle de version distribué

En ce qui concerne la gestion de versions moderne, vous devriez vraiment utiliser un système de gestion de versions distribué (DVCS) pour travailler localement sur le code. Git et Mercurial sont les choix les plus populaires de nos jours, quoique Bazaar puisse aussi très bien faire l’affaire. Même si le projet auquel vous voulez contribuer utilise toujours un système de gestion de version centralisé, être en mesure d’envoyer vos changements de manière itérative est une très bonne chose. Tous les outils de gestion de versions distribués mentionnés ci-dessus devraient être capables d’importer des changements depuis un SVN ou un CVS. Vous pourrez y aller et apprendre doucement Quilt mais, sérieusement, le futur passe par les systèmes de gestion de versions distribués.

De petits correctifs, pour faire une chose à la fois

Quand je dois examiner des correctifs, les plus ennuyeux à traiter sont ceux qui sont trop gros ou qui tentent de faire de nombreuses choses en même temps. Les correctifs qui ne font qu’une chose à la fois sont plus faciles à traiter. Au final, ils vous faciliteront la vie quand vous devrez déboguer les erreurs qu’auront manquées à la fois l’auteur et le vérificateur.

Suivez votre correctif

Après avoir proposé votre correctif, gardez un œil sur les canaux de communication du projet et sur votre correctif. Si vous n’avez eu aucun retour au bout d’une semaine, vous devriez poliment en demander un. En fonction de la façon dont le projet gère les propositions de correctif, celui-ci pourrait être noyé dans le bruit. N’espérez pas voir votre correctif retenu du premier coup. Il faut, en général, quelques essais pour s’habituer au style d’un nouveau projet. En tant que contributeur néophyte, personne ne vous en voudra pour ça, à condition d’avoir presque tout bon. Assurez-vous seulement de corriger ce que les développeurs vous ont indiqué et envoyez une seconde version du correctif.

Conclusion

Écrire de bons correctifs n’est pas difficile. Il y a deux ou trois choses à prendre en considération. Mais après en avoir écrit quelques-uns vous devriez être au point sur celles-ci. Un système moderne de contrôle de version (distribué) et le workflow (Ndt : flux de production) qui en résulte gèreront de fait la plupart des choses que j’ai mentionnées. Si vous n’avez qu’une chose à retenir, c’est ceci :

  • Utilisez un système de contrôle de version distribué pour gérer vos correctifs.
  • Écrivez vos correctifs en petites étapes indépendantes.
  • Suivez les normes de codage en vigueur.
  • Répondez rapidement aux commentaires sur vos correctifs.

Les quelques lignes directrices ci-dessus devraient vous aider à bien faire la plupart des choses, sinon toutes, quand vous soumettrez vos premiers correctifs. Bon codage.

(1) Un diff (abréviation de différence) est un fichier qui affiche le résultat d’une comparaison entre deux éléments (en général, des lignes de code). Pour en savoir plus : http://fr.wikipedia.org/wiki/Diff

(2) Review : révision minutieuse http://fr.wiktionary.org/wiki/review




Manifeste de la guérilla pour le libre accès, par Aaron Swartz #pdftribute

Il se passe quelque chose d’assez extraordinaire actuellement sur Internet suite à la tragique disparition d’Aaron Swartz : des centaines de professeurs et scientifiques du monde entier ont décidé de publier spontanément leurs travaux en Libre Accès !

Il faut dire que sa mort devient chaque jour plus controversée, les pressions judiciaires dont il était l’objet n’étant peut-être pas étrangères à son geste. Comme on peut le lire dans Wikipédia : « En juillet 2011, le militant américain pour la liberté de l’Internet Aaron Swartz fut inculpé pour avoir téléchargé et mis à disposition gratuitement un grand nombre d’articles depuis JSTOR. Il se suicide le 11 janvier 2013. En cas de condamnation, il encourait une peine d’emprisonnement pouvant atteindre 35 ans et une amende s’élevant jusqu’à 1 million de dollars. »

On peut suivre l’évolution du mouvement derrière le hashtag #pdftribute (pdf hommage) qui a déjà son site et son compte Twitter dédiés.

Dans la foulée nous avons décidé de traduire ensemble un autre article important d’Aaron Swartz (rédigé à 21 ans), en lien direct avec la motivation de tous ceux qui lui rendent ainsi un vibrant, concret et utile hommage : Guerilla Open Access Manifesto.

Ce manifeste s’achève sur cette interrogation : « Serez-vous des nôtres ? »

Remarque : L’émouvante photo ci-dessous représente Aaron Swartz a 14 ans en compagnie de Larry Lessig. On remarquera son bien joli tee-shirt 😉

Rich Gibson - CC by

Manifeste de la guérilla pour le libre accès

Guerilla Open Access Manifesto

Aaron Swartz – juillet 2008 – Internet Archive
(Traduction : Gatitac, albahtaar, Wikinade, M0tty, aKa, Jean-Fred, Goofy, Léna, greygjhart + anonymous)

L’information, c’est le pouvoir. Mais comme pour tout pouvoir, il y a ceux qui veulent le garder pour eux. Le patrimoine culturel et scientifique mondial, publié depuis plusieurs siècles dans les livres et les revues, est de plus en plus souvent numérisé puis verrouillé par une poignée d’entreprises privées. Vous voulez lire les articles présentant les plus célèbres résultats scientifiques ? Il vous faudra payer de grosses sommes à des éditeurs comme Reed Elsevier.

Et il y a ceux qui luttent pour que cela change. Le mouvement pour le libre accès s’est vaillamment battu pour s’assurer que les scientifiques ne mettent pas toutes leurs publications sous copyright et s’assurer plutôt que leurs travaux seront publiés sur Internet sous des conditions qui en permettent l’accès à tous. Mais, même dans le scénario le plus optimiste, la politique de libre accès ne concerne que les publications futures. Tout ce qui a été fait jusqu’à présent est perdu.

C’est trop cher payé. Contraindre les universitaires à débourser de l’argent pour lire le travail de leurs collègues ? Numériser des bibliothèques entières mais ne permettre qu’aux gens de chez Google de les lire ? Fournir des articles scientifiques aux chercheurs des plus grandes universités des pays riches, mais pas aux enfants des pays du Sud ? C’est scandaleux et inacceptable.

Nombreux sont ceux qui disent : « Je suis d’accord mais que peut-on y faire ? Les entreprises possèdent les droits de reproduction de ces documents, elles gagnent énormément d’argent en faisant payer l’accès, et c’est parfaitement légal, il n’y a rien que l’on puisse faire pour les en empêcher. » Mais si, on peut faire quelque chose, ce qu’on est déjà en train de faire : riposter.

Vous qui avez accès à ces ressources, étudiants, bibliothécaires, scientifiques, on vous a donné un privilège. Vous pouvez vous nourrir au banquet de la connaissance pendant que le reste du monde en est exclu. Mais vous n’êtes pas obligés — moralement, vous n’en avez même pas le droit — de conserver ce privilège pour vous seuls. Il est de votre devoir de le partager avec le monde. Et c’est ce que vous avez fait : en échangeant vos mots de passe avec vos collègues, en remplissant des formulaires de téléchargement pour vos amis.


Pendant ce temps, ceux qui ont été écartés de ce festin n’attendent pas sans rien faire. Vous vous êtes faufilés dans les brèches et avez escaladé les barrières, libérant l’information verrouillée par les éditeurs pour la partager avec vos amis.

Mais toutes ces actions se déroulent dans l’ombre, de façon souterraine. On les qualifie de « vol » ou bien de « piratage », comme si partager une abondance de connaissances était moralement équivalent à l’abordage d’un vaisseau et au meurtre de son équipage. Mais le partage n’est pas immoral, c’est un impératif moral. Seuls ceux qu’aveugle la cupidité refusent une copie à leurs amis.


Les grandes multinationales, bien sûr, sont aveuglées par la cupidité. Les lois qui les gouvernent l’exigent, leurs actionnaires se révolteraient à la moindre occasion. Et les politiciens qu’elles ont achetés les soutiennent en votant des lois qui leur donnent le pouvoir exclusif de décider qui est en droit de faire des copies.

La justice ne consiste pas à se soumettre à des lois injustes. Il est temps de sortir de l’ombre et, dans la grande tradition de la désobéissance civile, d’affirmer notre opposition à la confiscation criminelle de la culture publique.

Nous avons besoin de récolter l’information où qu’elle soit stockée, d’en faire des copies et de la partager avec le monde. Nous devons nous emparer du domaine public et l’ajouter aux archives. Nous devons acheter des bases de données secrètes et les mettre sur le Web. Nous devons télécharger des revues scientifiques et les poster sur des réseaux de partage de fichiers. Nous devons mener le combat de la guérilla pour le libre accès.

Lorsque nous serons assez nombreux de par le monde, nous n’enverrons pas seulement un puissant message d’opposition à la privatisation de la connaissance : nous ferons en sorte que cette privatisation appartienne au passé. Serez-vous des nôtres ?

Aaron Swartz

Crédit photo : Rich Gibson (Creative Commons By)




D’un projet à l’autre, franchissez les frontières (Libres conseils 11/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : ga3lig, lenod, peupleLa, LAuX, billouche, Goofy, jcr83, purplepsycho, Jej, KoS, Julius22, kalupa, tuki, lamessen, okram + Sinma

La collaboration entre projets

Henri Bergius

Henri Bergius est le fondateur de Midgard(1), un dépôt de contenu pour les logiciels libres. Il a aussi été longtemps impliqué dans la géolocalisation d’ordinateurs de bureaux sous Linux ainsi que dans les communautés Maemo et Meego. Il dirige un petit cabinet de conseil nommé Nemein, bidouille CoffeeScript et PHP et passe beaucoup de son temps à faire de la moto dans des régions reculées du continent Eurasien. Il vit dans la froide ville nordique d’Helsinki, en Finlande.

Il se peut qu’il existe un système complètement nouveau dans lequel vous pouvez être défini davantage par qui vous êtes plutôt que par ce que vous possédez, par ce que vous avez créé et partagé, parce que d’autres personnes ont ensuite construit sur cette base

– John Seely Brown, ancien directeur de Xerox PARC dans An Optimist’s Tour of the Future (Mark Stevenson, 2010)

Le monde du logiciel libre est pour l’essentiel divisé en tribus rassemblées autour de choses appelées projets. Il existe des projets majeurs tels que GNOME(2), KDE(3) ou Drupal(4) et il existe bien d’autres projets plus modestes tournant autour d’une seule application ou bibliothèque logicielle.

En fait, les qualifier de « projets » est un peu ridicule.

Selon moi, un projet est l’organisation d’un effort visant un but que l’on puisse atteindre et comprend un calendrier avec dates de début et de fin. Ainsi, GNOME 3.1 serait par exemple un projet tandis que GNOME, pris dans son ensemble, n’en est pas un. Il s’agit d’une communauté d’individus qui entretiennent et créent le corps d’un logiciel par de petits efforts variés ou des projets.

Assez de pédantisme. Le souci avec le concept de projet c’est qu’il finit par maintenir une séparation entre les personnes. Cela crée des communautés isolées souvent réticentes voire incapables de collaborer avec « la concurrence ». Mais en fin de compte, toutes ces communautés sont composées de personnes écrivant des logiciels libres. Et ce sont elles qui décident de l’utilisation possible ou non d’un logiciel dans différents environnements.

En fin de compte, nous voulons tous que le logiciel que nous avons créé soit utilisé par d’autres. Mieux encore : nous voulons que les autres joignent leurs efforts aux nôtres et créent des choses sympa à partir de ce que nous avons créé. Après tout, ceci constitue le cœur même des logiciels libres.

Alors pourquoi érigeons-nous ces murs autour de nous ? Garder une communauté isolée ne fait que favoriser une mentalité de type « nous contre eux ». Les incompatibilités des différents langages de programmation contribuent déjà fortement à notre division. Pourquoi en rajouter ?

La leçon de Midgard

Il est une chose que j’aurais voulu savoir quand j’ai démarré, dans cette période optimiste des « .com » de la fin des années 90 : c’est qu’en réalité le développement de logiciels ne gagne rien à s’isoler. Avec un peu d’efforts nous pouvons partager nos logiciels et nos idées par le biais de communautés, ce qui renforce et améliore à la fois les logiciels et les communautés.

Quand j’ai démarré ma carrière dans le logiciel libre, c’était l’époque des grands projets. Netscape ouvrait son code source, la fondation Apache prenait forme et des sociétés de capital-risque venaient de partout. Tenter de bâtir sa communauté devenait la norme. C’était le chemin assuré vers la gloire, la fortune et la réalisation de choses extraordinaires.

Alors nous avons construit nos propres infrastructures web. À ce moment-là il n’y en avait pas tant que cela, en particulier pour le tout jeune langage PHP. Le PHP n’était même pas notre premier choix. Nous l’avions seulement choisi au terme d’un long débat sur l’utilisation de Scheme(5) que notre développeur principal préférait. Mais le PHP gagnait alors en popularité, devenant le langage de programmation de la Toile. Et nous voulions construire la Toile.

Au début, les choses semblaient prometteuses. Beaucoup de développeurs rejoignaient notre communauté et commençaient à y contribuer. Il y a même eu des entreprises fondées autour de Midgard. Notre infrastructure gagnait en fonctionnalités et devenait de plus en plus liée à Midgard.

Avec le recul, c’est là que nous avons fait une erreur. Nous avons positionné Midgard pour être distinct du PHP lui-même. Quelque chose que vous installeriez séparément, et utiliseriez comme base pour y construire des sites entiers. Il fallait soit suivre notre voie, soit suivre celle de tout le monde.

Avec Midgard, vous deviez utiliser notre interface de dépôt de contenus pour tout, aussi bien pour notre gestion des utilisateurs que pour le modèle de permissions. Vous deviez utiliser notre système de modèles et stocker beaucoup de votre code dans le dépôt au lieu d’utiliser un système de fichiers.

Ceci ne passait évidemment pas très bien auprès de l’ensemble de la communauté PHP. Nos idées leur semblaient étranges, et Midgard, à ce moment-là, était même distribué en tant que gigantesque correctif à la base de code puisqu’on ne pouvait pas charger de modules avec PHP3.

Les années ont passé et la popularité de PHP a connu des hauts et des bas. Pendant ce temps, la communauté Midgard est restée relativement constante : un petit groupe soudé faisant des progrès sur le long terme mais séparé du monde plus large de PHP.

Nous nous sommes toujours demandé pourquoi il était si difficile d’interagir avec le monde PHP. Même d’autres communautés faisant des choses complètement différentes, comme l’environnement de bureau GNOME, semblaient plus faciles à approcher. Ce n’est que récemment, après des années d’isolement, que nous avons pris conscience du problème. En résumé : les infrastructures nous séparent alors que les bibliothèques nous permettent de partager notre code et nos expériences.

À propos des bibliothèques et des infrastructures

En définitive, les logiciels ont pour objectif l’automatisation, la construction d’outils que les autres peuvent utiliser pour résoudre des problèmes ou se connecter entre eux. Avec les logiciels, ces outils comportent plusieurs couches. Il existe des services de bas niveau comme les systèmes d’exploitation, puis les bibliothèques, les infrastructures, les boîtes à outils et enfin les applications elles-mêmes.

Les applications sont toujours écrites pour des usages spécifiques, donc entre elles il existe peu de possibilités de partage de code.

Les possibilités les plus séduisantes se situent au niveau des bibliothèques et infrastructures. Une infrastructure, si elle est suffisamment générique, peut généralement être utilisée pour construire différentes sortes de logiciels. Une bibliothèque, quant à elle, peut être utilisée pour apporter un élément particulier de logique ou de connectivité là où le besoin s’en fait sentir. De mon point de vue, c’est dans cette couche que le plus gros de la programmation devrait être fait, avec des applications spécifiques qui ne sont que des connexions entre diverses bibliothèques au sein d’une infrastructure qui s’occupe alors de faire tourner l’application en question.

Qu’est-ce qu’une bibliothèque et qu’est-ce qu’une infrastructure ? Les gens utilisent souvent ces termes indifféremment bien qu’il existe une règle grossière qui permet de les différencier : une bibliothèque est une ressource à laquelle votre code fait appel, alors qu’une infrastructure est une ressource qui fait appel à votre code.

Si vous voulez que votre code soit utilisé et amélioré, le meilleur moyen est de maximiser le nombre de ses utilisateurs et contributeurs potentiels. Avec le logiciel libre, cela fonctionne en s’assurant que votre code peut être adapté à de multiples situations et environnements.

En définitive, ce que vous voulez développer c’est une bibliothèque. Les bibliothèques c’est cool.

Comment faire en sorte que la collaboration fonctionne

Le plus difficile est de franchir la barrière du « eux-contre-nous ». Les développeurs de l’autre communauté sont des bidouilleurs concevant du logiciel libre, tout comme vous. Il suffit donc de franchir le pas et de commencer à leur parler.

Une fois le débat engagé, voici quelques points que j’ai trouvés importants quant à l’application effective des idées communes ou des bibliothèques au-delà des frontières du projet

  • Utilisez des licences permissives et essayez d’éviter les cessions de droits d’auteurs et autres exigences que les utilisateurs potentiels trouveraient onéreuses. Hébergez le projet en terrain neutre. Pour les projets web, Apache est un assez bon havre. Pour les projets bureautiques, Freedesktop est probablement le meilleur choix. Utilisez des technologies qui n’imposent pas trop de contraintes. Les bibliothèques doivent être de bas niveau, ou fournir des API (interfaces de programmation) D-Bus utilisables avec n’importe quel système.
  • Évitez les dépendances spécifiques à une infrastructure. KDE a, par exemple, trouvé GeoClue difficile à adopter parce qu’il utilise des paramètres spécifiques à l’interface GNOME. Rencontrez les autres. Si vous venez du projet GNOME, allez à l’aKademy et donnez-y une conférence. Si vous êtes développeur KDE, allez parler au GUADEC. Après avoir partagé une bière ou deux, la collaboration par IRC vient beaucoup plus naturellement.
  • Enfin, vous devez accepter que votre implémentation ne soit pas utilisée par tout le monde. Mais si, au moins, d’autres mettent en œuvre les mêmes idées, alors une collaboration reste possible.

Bonne chance pour abattre les frontières du projet ! Dans la plupart des cas, cela fonctionne si vos idées sont bonnes et présentées avec un esprit ouvert. Mais même si vous ne trouvez pas de terrain d’entente, tant que votre application remplit sa fonction pour vous, ça n’a pas été fait en vain. Après tout, ce qui compte c’est de proposer des logiciels et d’offrir la meilleure expérience utilisateur possible.

(1) http://midgard-project.org/

(2) gnomefr.org

(3) fr.kde.org

(4) drupalfr.org

(5) http://fr.wikipedia.org/wiki/Scheme

Crédit photo : mommy peace – (CC BY-NC-SA 2.0)




En hommage à Aaron Swartz

Une vague d’émotion sans précédente s’est emparée du Web (que j’ai l’habitude de lire) après la récente tragique disparition d’Aaron Swartz à l’âge de 26 ans. Il faut dire qu’il en avait fait des choses en une pourtant si courte période !

Nous avons décidé de lui rendre hommage en traduisant collectivement l’un des articles de son blog où il évoque son parcours et ses nombreux projets.

Cet article a été initialement écrit en 2007. Aaron avait alors à peine 20 ans…

Sage Ross - CC by-sa

Comment dégoter un boulot comme le mien

How to Get a Job Like Mine

Aaron Swartz – 18 août 2008 – Blog personnel
(Traduction : ga3lig, clementd, Amic, tth, bld, KoS, Havok Novak, a_r_n_a_u_d_b, jpcw + anonymous)

L’écrivain américain Kurt Vonnegut avait l’habitude de toujours nommer ses interventions « Comment obtenir un travail comme le mien » pour parler ensuite de ce que bon lui semblait. Je suis plutôt dans la situation inverse. On m’a informé que je pouvais parler de n’importe quel sujet qui m’intéressait et j’ai donc décidé, plutôt que de pontifier sur l’avenir d’Internet ou de la puissance de la collaboration massive, que la discussion la plus intéressante était probablement celle-ci : « Comment bénéficier d’un travail comme le mien » (NdT : ce texte a été rédigé en préparation d’une conférence donnée au congrès informatique Tathva à NIT Calicut en 2007).

Comment ai-je réussi à dégotter ce job ? Sans aucun doute, la première étape a été de faire le bon choix, c’est-à-dire les bons gènes : à la naissance, j’étais un garçon, blanc, et américain. Ma famille était relativement aisée et mon père travaillait dans l’industrie informatique. Hélas, il n’existe à ce jour aucun moyen d’influer sur ce genre de choses donc je ne vous serai probablement d’aucune utilité sur ce point.

En revanche, quand j’ai débuté, j’étais un très jeune gamin coincé dans une petite ville au milieu de la campagne. J’ai donc dû trouver quelques astuces pour m’en sortir. En espérant rendre la vie un peu moins injuste, je me suis dit que je pourrais les partager avec vous.

Étape 1 : apprendre

La première chose que j’ai faite, et qu’a priori vous avez tous déjà faite, c’était d’apprendre des choses à propos des ordinateurs, d’Internet et de la culture Internet. J’ai lu un paquet de livres, j’ai lu une quantité énorme de pages Web et j’ai essayé des trucs. J’ai commencé par rejoindre des listes de diffusion et j’ai essayé de comprendre les discussions jusqu’à ce que je me sente assez à l’aise pour me lancer et y participer à mon tour. Ensuite, j’ai regardé des sites Web et j’ai essayé de construire le mien. À la fin, j’ai appris à construire des applications Web et j’ai commencé à le faire. J’avais treize ans.

Étape 2 : expérimenter

Le premier site que j’ai réalisé s’appelait get.info. L’idée était d’avoir une encyclopédie en ligne gratuite, que chacun pourrait éditer, ou compléter, ou réorganiser à travers son navigateur. J’ai tout développé, ajouté un tas d’options sympas, testé ça sur tous les types de navigateurs et j’en étais très fier. J’ai même remporté un prix pour la meilleure application Web de cette année-là. Malheureusement, les seules personnes que je connaissais à cette époque étaient d’autres jeunes de mon école, donc je n’avais pas grand monde pour écrire des articles d’encyclopédie. (Heureusement, quelques années plus tard, ma mère m’a montré ce nouveau site appelé « Wikipédia » qui faisait la même chose.)

Le second site s’appellait my.info. L’idée était qu’au lieu d’aller à la recherche d’informations sur toutes sortes de pages Web différentes, il suffisait d’avoir un programme qui allait chercher les nouveautés dans toutes ces pages Web et qui les regrouperait à un seul endroit. Je l’ai construit et je l’ai fait marcher, mais il se trouve qu’à l’époque, je n’étais pas le seul à avoir eu ce genre d’idée. Beaucoup de gens travaillaient sur cette nouvelle technique, appelée alors « syndication ». Un groupe d’entre eux s’est mis à part et a décidé de travailler sur une spécification appelée RSS 1.0, et je les ai rejoints.

Étape 3 : échanger

C’était l’été, je n’étais pas à l’école et je n’avais pas de boulot, j’avais donc beaucoup de temps libre à disposition. Et je l’ai entièrement consacré à lire la liste de diffusion de RSS 1.0 et à faire toutes sortes de travaux bizarres et tout ce qu’il y avait d’autre à faire. Assez rapidement, on m’a demandé si je voulais devenir membre du groupe, et je me suis retrouvé être co-auteur, puis co-éditeur de la spécification RSS 1.0.

RSS 1.0 était construit au-dessus d’une technologie appelée RDF, source de débats agités sur les listes de diffusion de RSS. J’ai donc commencé à m’intéresser à RDF, j’ai rejoint les listes de diffusion autour de RDF, lu des choses, posé des questions idiotes pour lentement commencer à comprendre comment ça marchait. Assez rapidement, je devenais connu dans le petit monde du RDF et quand ils ont annoncé la création d’un nouveau groupe de travail destiné à créer la prochaine spécification RDF, j’ai décidé de m’y glisser.

Premièrement, j’ai demandé aux membres du groupe de travail si je pouvais m’y joindre. Ils m’ont répondu négativement. Mais je voulais vraiment faire partie de ce groupe de travail, alors j’ai décidé de trouver un autre moyen. J’ai lu le règlement du W3C, qui expliquait le fonctionnement d’un groupe de travail. Les règles indiquaient que, bien que se réservant le droit de rejeter toute demande d’adhésion individuelle, il suffisait que l’une des organisations faisant partie des membres officiels du W3C sollicite la participation d’un candidat pour qu’elle soit acceptée d’emblée. Ainsi, j’ai examiné en détail la liste des organisations membres du W3C, découvert celle qui me paraissait la plus accessible et lui ai demandé de m’inclure dans ce groupe de travail. Et c’est ce qu’ils ont fait !

Faire partie d’un groupe de travail impliquait des communications téléphoniques hebdomadaires avec les autres membres, un tas de discussions sur des listes de diffusion et sur IRC, de temps à autre de voyager vers d’étranges villes pour des rencontres réelles et une quantité de prises de contact avec des personnes à connaître partout.

J’étais aussi un chaud partisan de RDF, j’ai ainsi œuvré ardemment à convaincre d’autres de l’adopter. Quand j’ai découvert que le professeur Lawrence Lessig lançait une nouvelle organisation appelée Creative Commons, je lui ai transmis un courriel lui conseillant d’adopter RDF pour son projet et lui ai expliqué pourquoi. Quelques jours après, il me répondit : « Bonne idée. Pourquoi ne le ferais-tu pas pour nous ? »

Donc, j’ai fini par rejoindre les Creative Commons, qui m’ont fait m’envoler vers toutes sortes de conférences et de réunions, et je me suis retrouvé en train de rencontrer encore plus de gens. Parmi tous ces gens qui commençaient à savoir qui j’étais, j’en suis arrivé à me faire des amis dans un paquet d’endroits et de domaines différents.

Étape 4 : construire

Puis j’ai laissé tout ça de côté et je suis allé à l’université pour un an. Je suis allé a l’université de Stanford, une petite école idyllique en Californie où le soleil brille toujours, où l’herbe est toujours verte et où les jeunes sont toujours dehors à se faire bronzer. Il y a des enseignants excellents et j’ai sans aucun doute beaucoup appris, mais je n’y ai pas trouvé une atmosphère très intellectuelle étant donné que la plupart des autres jeunes se fichaient apparemment profondément de leurs études.

Mais vers la fin de l’année, j’ai reçu un courriel d’un écrivain nommé Paul Graham qui disait démarrer un nouveau projet, Y Combinator. L’idée derrière Y Combinator était de trouver un groupe de développeurs vraiment talentueux, les faire venir à Boston pour l’été, leur donner un peu d’argent et la base administrative pour lancer une société. Ils travaillent alors très, très dur pour apprendre tout ce dont ils ont besoin de savoir sur le monde des affaires, en les mettant en contact avec des investisseurs, des clients, etc. Et Paul suggéra que je m’inscrive.

Donc je l’ai fait, et après beaucoup de peine et d’efforts, je me suis retrouvé à travailler sur un petit site appelé Reddit.com. La première chose à savoir à propos de Reddit était que nous n’avions aucune idée de ce que nous étions en train de faire. Nous n’avions pas d’expérience dans les affaires, nous n’avions pratiquement pas d’expérience en création de logiciels au niveau qualité d’un produit fini. Et nous n’avions aucune idée si, ou pourquoi, ce que nous faisions fonctionnait. Chaque matin, nous nous levions et nous vérifiions que le serveur n’était pas tombé en panne et que le site ne croulait pas sous les messages indésirables, et que nos utilisateurs étaient toujours présents.

Lorsque j’ai commencé à Reddit, la croissance était lente. Le site avait été mis en ligne très tôt, quelques semaines après avoir commencé à travailler dessus, mais pendant les trois premiers mois, il a difficilement atteint trois mille visiteurs par jour, ce qui représente un minimum pour un flux RSS utilisable. Nous avons ensuite, lors d’une session marathon de codage de quelques semaines, transféré le site de Lisp à Python et j’ai écrit un article sur mon blog au sujet de cet exploit. Il a beaucoup attiré l’attention (même l’enfer ne peut déclencher autant de colère que celle d’un fan de Lisp mécontent) et encore aujourd’hui les gens que je rencontre en soirée, lorsque que je mentionne que j’ai travaillé à Reddit, disent : « Oh, le site qui a migré depuis Lisp. »

C’est à ce moment-là que le trafic a vraiment commencé à décoller. Dans les trois mois qui ont suivi, le trafic a doublé à deux reprises. Chaque matin, nous nous levions pour vérifier les statistiques et voir comment nous nous en sortions, vérifier si une nouvelle fonctionnalité que nous avions lancée nous avait attiré plus de monde, ou si le bouche à oreille continuait de faire parler de notre site, ou encore si tous nos utilisateurs nous avaient abandonnés. Et, chaque jour, le nombre de visiteurs progressait. Mais nous ne pouvions nous empêcher d’avoir l’impression que la croissance du trafic était encore plus rapide lorsque nous arrêtions de travailler sur le site.

Nous n’avions toujours pas d’idée sur la façon de gagner de l’argent. Nous avons vendu des t-shirts sur le site, mais, chaque fois, l’argent récupéré sur la vente servait à racheter encore plus de t-shirts. Nous avons signé avec un acteur majeur de la publicité en ligne pour vendre de la publicité sur notre site, mais cela n’a guère fonctionné, en tout cas pas pour nous, et il était rare que nous touchions, en réalité, plus de deux dollars par mois. Une autre idée était de commercialiser, sous licence, le savoir-faire « Reddit » pour permettre à d’autres de monter des sites sur le modèle Reddit. Mais nous n’avons trouvé personne d’intéressé pour acquérir notre licence.

Rapidement, Reddit a acquis des millions d’utilisateurs chaque mois, un chiffre qui dépasse de loin le magazine américain moyen. Je le sais, car j’ai discuté, à cette période, avec de nombreuses maisons d’édition. Ils se sont tous demandés comment le charme de Reddit pourrait opérer pour eux.

De plus, les sites d’actualités en ligne ont commencé à voir que Reddit pourrait leur envoyer un énorme trafic. Ils ont pensé, d’une certaine manière, encourager cela en ajoutant un lien « reddit this » à tous leurs articles. Pour autant que je sache, ajouter ces liens n’améliore pas vraiment votre chance de devenir populaire sur Reddit (bien que cela rende votre site plus moche), mais cela nous a offert beaucoup de publicité gratuite.

Assez rapidement, la discussion avec nos partenaires se dirigeait vers une négociation d’acquisition. L’acquisition : la chose dont nous avions toujours rêvé ! Il n’y aurait plus à s’inquiéter de faire du profit. Des entreprises externes se chargeaient de cette responsabilité en contrepartie de faire notre fortune. Nous avons tout laissé tomber pour négocier avec nos acheteurs. Et ensuite, cela est resté à l’abandon.

Nous avons négocié pendant des mois. Au début, nous débattions sur le prix. Nous préparions des « business plans » et des feuilles de calcul, puis allions au siège social pour faire des présentations et affronter des réunions et des appels téléphoniques sans fin. Finalement, ils refusèrent notre prix et nous sommes donc repartis. Plus tard, ils changèrent d’attitude, nous nous sommes serrés la main et nous étions d’accord sur la transaction pour finalement commencer à renégocier sur certains autres points cruciaux, et nous éloigner à nouveau. Nous avons dû nous retirer trois ou quatre fois avant d’obtenir un contrat acceptable. Au final, nous avons dû arrêter de travailler efficacement pendant six mois.

Je commençais à devenir malade d’avoir à consacrer autant de temps à l’argent. Nous commencions tous à être affectés par le stress et le manque de travail productif. Nous avons commencé à nous disputer et ensuite à ne plus nous parler, avant de redoubler d’efforts pour retravailler ensemble, pour retomber finalement dans nos errements. L’entreprise a failli se désintégrer avant que la transaction ne se concrétise.

Mais finalement, nous sommes allés chez nos avocats pour signer tous les documents et le lendemain matin, l’argent était sur nos comptes. C’était terminé.

Nous nous sommes tous envolés pour San Francisco et avons commencé à travailler dans les bureaux de Wired News (nous avions été rachetés par Condé Nast, une grande entreprise de publication qui possède Wired et de nombreux autres magazines).

J’étais malheureux. Je ne pouvais pas supporter San Francisco. Je ne pouvais pas supporter une vie de bureau. Je ne pouvais pas supporter Wired. J’ai pris de longues vacances de Noël. Je suis tombé malade. J’ai pensé à me suicider. J’ai fui la police. Et quand je suis revenu le lundi matin, on m’a demandé de démissionner.

Étape 5 : liberté

Les quelques premiers jours sans travail ont été bizarres. Je tournais en rond chez moi. Je profitais du soleil de San Francisco. Je lisais quelques livres. Mais rapidement, j’ai senti que j’avais besoin, à nouveau, d’un projet. J’ai commencé à écrire un livre. Je désirais collecter toutes les bonnes études dans le domaine de la psychologie pour les raconter, non pas comme des analyses, mais comme des histoires. Chaque jour, je descendais à la bibliothèque de Stanford pour y faire des recherches. (Stanford est une école réputée en psychologie.)

Mais un jour, Brewster Kahle m’a appelé. Brewster est le fondateur de The Internet Archive, une organisation formidable qui essaye de numériser tout ce qu’elle trouve pour le publier sur le Web. Il m’a dit qu’il voulait démarrer un projet dont nous avions parlé à l’époque. L’idée serait de rassembler l’information de tous les livres du monde dans un lieu unique, un wiki libre. Je me suis mis immédiatement au travail, et dans les quelques mois qui ont suivi, j’ai commencé à contacter les bibliothèques, mettre à contribution des programmeurs, cogiter avec un designer et faire plein d’autres trucs pour mettre ce site en ligne. Ce projet a fini par devenir Open Library. Il a été développé en grande partie par un talentueux programmeur indien : Anand Chitipothu.

Un autre ami, Seth Roberts, a suggéré que nous devrions trouver le moyen de réformer le système des études supérieures. Nous n’arrivions pas à nous mettre d’accord sur une solution satisfaisante, mais nous avons eu une autre bonne idée : un wiki qui explique aux étudiants à quoi ressemblent les différents métiers. Ce site va être bientôt lancé…

Ensuite, un autre ancien ami, Simon Carstensen, m’a envoyé un e-mail disant qu’il avait obtenu son diplôme universitaire et qu’il cherchait à monter une entreprise avec moi. En fait, j’avais gardé une liste d’entreprises qui pourraient être d’excellentes idées et j’ai pris la première de la liste. L’idée était de créer un site Web aussi simple à remplir qu’un champ texte. Pendant les mois suivants, nous avons travaillé d’arrache-pied à rendre les choses de plus en plus simples (et un peu plus complexes aussi). Le résultat, avec le lancement il y a quelques semaines, est le site : Jottit.com.

Je me suis aussi engagé en tant que conseiller pour deux projets du Summer of Code, les deux étant étonnamment ambitieux et avec un peu de chances, ils devraient être lancés bientôt.

J’ai décidé également alors de m’impliquer dans le journalisme. Mon premier article papier vient d’être publié.

J’ai aussi lancé quelques blogs sur la science et j’ai commencé à travailler à rédiger un article académique moi-même. Il se base sur une étude que j’avais conduite il y a quelques temps sur les rédacteurs effectifs de Wikipédia. Quelques personnes, y compris Jimmy Wales, qui est en quelque sorte le porte-parole de Wikipédia, affirmait que Wikipédia n’était pas, tout compte fait, un projet massivement collaboratif, mais était plutôt rédigé par une équipe d’à peu près 500 auteurs, qu’il connaissait pour la plupart. Il avait fait quelques analyses simples pour le mettre en évidence, mais j’ai vérifié attentivement les chiffres et j’arrive à la conclusion inverse : la grande majorité de Wikipédia a été écrite par de nouveaux rédacteurs, la plupart ne s’étant pas donné la peine de créer un compte, ajoutant quelques phrases de ci de là. Comment Wales a-t-il pu commettre une telle erreur ? Il a analysé le nombre de modifications effectuées par chaque auteur sans vérifier la nature de ces modifications. Or la grande majorité de leurs modifications sont tout à fait mineures : ils font des choses comme des corrections orthographiques ou des remises en forme. Il semble plus raisonnable de croire que ces 500 personnes se comportent plus comme des inspecteurs que comme des producteurs de contenu.

Derniers conseils

Quel est le secret ? Comment pourrais-je condenser les choses que je fais dans des phrases concises qui me correspondent le plus ? Allons-y :

  1. Soyez curieux. Élargissez vos lectures. Essayez de nouvelles choses. Je pense que ce que beaucoup de gens appellent intelligence n’est rien d’autre que de la curiosité ;
  2. Dites oui à tout. J’ai quelques difficultés à dire non, à un niveau pathologique, quels que soient les projets, les interviews ou les amis. Du coup, j’essaie beaucoup et même si ça se solde souvent par un échec, j’ai toujours fait quelque chose ;
  3. Faites comme si les autres n’avaient pas la moindre idée de ce qu’ils sont en train de faire. Une foule de gens hésite à tenter une action pour la simple raison qu’ils pensent qu’ils n’en savent pas suffisamment sur le sujet ou parce qu’ils supposent que d’autres l’ont fait avant eux. Eh bien, peu de gens ont la moindre idée de la manière de mener une action et ils sont même encore moins nombreux à expérimenter de nouvelles méthodes, donc en général si vous faites de votre mieux sur quelque chose, vous le ferez plutôt bien.

J’ai suivi cette ligne de conduite. Et voilà où j’en suis aujourd’hui, avec une douzaine de projets en tête et mon niveau de stress toujours au plus haut.

Chaque matin, je me lève et vérifie mes courriels pour savoir lequel de mes projets a implosé aujourd’hui, quelle date limite a été dépassée, quels discours je dois préparer et quels articles doivent être rédigés.

Un jour, peut-être, vous aussi serez dans la même situation. Si tel est le cas, j’espère que j’y aurai modestement contribué.

Crédit photo : Sage Ross (Creative Commons By-Sa)




Comment s’attaquer aux problèmes (Libres conseils 10/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sky, LIAR, lerouge, Goofy, peupleLa, lamessen LAuXKoS, Nys, Julius22, okram, kalupa, 4nti7rust, CoudCoud, zn01wr + Sinma

L’art de résoudre les problèmes

Thiago Madeira

Thiago Macieira est doublement diplômé. Il a une maîtrise en administration des affaires (MBA) et un diplôme d’ingénieur. Mais son implication dans le mouvement open source, depuis près de 15 ans maintenant, est antérieur à ses diplômes. Participant actif des communautés KDE, Qt et MeeGo, il a été ingénieur logiciel et responsable produit pour Qt, il a fait des conférences et il a écouté les gens. À présent, Thiago vit à Oslo en Norvège et quand il ne travaille pas sur Qt, il essaye — sans grande réussite — d’améliorer son skill à StarCraft 2.


Les problèmes forment une routine à laquelle nous sommes confrontés presque tous les jours ; nous les résolvons et c’est tellement habituel que bien souvent nous n’en avons même pas conscience. Cela peut être des situations aussi simples que chercher le meilleur chemin pour arriver à destination ou trouver la meilleure façon de tout faire tenir dans le réfrigérateur. Ce n’est que lorsque nous ne parvenons pas à les résoudre immédiatement que nous remarquons les problèmes car nous devons alors nous arrêter et y réfléchir. Notre vie professionnelle n’échappe pas à cette règle et la résolution de problèmes commence à faire partie de la description du poste à pourvoir.

La résolution de problèmes était le sujet de mon premier cours quand j’ai commencé ma formation d’ingénieur. Dans cet amphithéâtre bondé du siècle dernier, notre professeur expliquait à environ 700 étudiants de première année en quoi les ingénieurs étaient des solutionneurs de problèmes et comment nos vies professionnelles consisteraient à enchaîner les problèmes à résoudre. Certains seraient des problèmes faciles résolus en deux temps trois mouvements ; d’autres seraient tellement difficiles que nous aurions besoin d’une structure de projet et d’une équipe pour les résoudre — mais la plupart se situeraient entre ces deux extrêmes. Puis il commença à donner des exemples sur la façon dont sa propre mentalité de « solutionneur de problèmes » l’avait aidé dans sa vie professionnelle et personnelle, et nous offrit même un exemple en direct quand tout à coup le projecteur nous tomba dessus.

La faculté de résoudre des problèmes est un talent que nous pouvons affiner par la pratique et un travail de fond. La pratique est quelque chose que l’on ne peut acquérir que par l’expérience, par succession d’essais et d’erreurs (1) ; ce n’est donc pas quelque chose qu’on peut apprendre dans un livre. Se mettre en situation de résoudre des problèmes, en revanche, est quelque chose que l’on peut apprendre. Face au problème, l’expérience est comme notre boîte à outils, et les techniques de résolution le mode d’emploi des outils.

Formuler correctement la question

La question à laquelle nous essayons de répondre fournit la direction que nous allons prendre en essayant de résoudre le problème. Posez la mauvaise question et les réponses seront peu pertinentes, invalides ou juste complètement fausses. Par conséquent, poser la bonne question est essentiel. De plus, poser correctement la bonne question est important, car cela apporte des indices quant à ce que nous recherchons. La manière la plus inutile d’énoncer un problème qu’on puisse rencontrer est : « ça marche pas », c’est pourtant un grand classique. Certes, l’énoncé est juste, puisque manifestement quelque chose a planté. Néanmoins, cette façon de présenter le problème n’apporte aucun indice sur le point de départ pour rechercher des solutions.

Les systèmes de gestion de bogues imposent souvent au rapporteur du bogue de préciser les actions effectuées qui ont conduit à ce problème, la description de ce qui s’est passé (c’est-à-dire le symptôme) et une description du comportement attendu. La comparaison entre le symptôme et le comportement attendu est un bon point de départ pour poser la question fondamentale : «  pourquoi cela s’est-il produit, pourquoi cet autre comportement ne s’est-il pas produit ? ». Même si ce n’est pas la seule manière d’y arriver, appliquer cette technique à des problèmes peut certainement aider à formuler la question.

Formuler correctement le problème et la question, dans ses moindres détails, est aussi une manière de décrire davantage le problème tel qu’il s’est manifesté. En premier lieu, nous devons avoir conscience que le problème ne se trouve probablement pas où nous nous attendons à le trouver — si c’était le cas, nous l’aurions probablement déjà résolu. Présenter tous les détails du problème permet à l’assistance technique d’avoir plus d’informations pour travailler. De plus, même si c’est contre-intuitif, le fait de décrire le problème dans sa totalité conduit souvent à trouver la solution, si bien que de nombreux groupes de développement ont besoin que des développeurs se concentrent sur cette tâche, soit en discutant avec un collègue soit en s’adressant à un être innocent, tel qu’un canard en caoutchouc ou M. Patate.

De plus, il faut revenir régulièrement à la question afin de garder l’objectif dans le viseur. Lors de la résolution du problème, il convient de faire attention à ne pas se concentrer exclusivement sur l’une de ses parties en perdant de vue l’objectif global. Pour la même raison, il est nécessaire de reprendre la question de départ lorsqu’on a trouvé une solution éventuelle, pour pouvoir s’assurer qu’elle couvre bien l’intégralité du problème. Là encore, cela prouve bien la nécessité de poser la bonne question, qui décrira le problème dans son intégralité : sans la question complète, la solution pourrait être également incomplète.

Diviser pour mieux régner (2)

L’expérience que j’ai acquise en aidant des utilisateurs en ligne à résoudre leurs problèmes m’a appris que la plupart des personnes considérent leurs difficultés comme des blocs d’achoppement, monolithiques et indivisibles, qu’il faut traiter comme un tout. Vu sous cet angle, un vaste problème pose une question à laquelle il est très difficile de répondre entièrement.

À vrai dire, la grande majorité de ces problèmes peut se décomposer en plusieurs petits problèmes qu’il est donc plus facile de traiter séparément afin de déterminer s’ils sont la cause originelle du problème, sans parler de la possibilité qu’il y ait plusieurs origines au symptôme rapporté. Répéter cette opération, ne serait-ce qu’un petit nombre de fois, revient à s’attaquer à des problèmes mieux circonscrits, et amène par conséquent à des solutions plus rapides.

Cependant, plus nous sommes obligés de décomposer, plus nous devons connaître le fonctionnement interne du système que nous avons sous la main. De fait, celui qui doit résoudre un problème ne pourra le décomposer qu’aussi loin que sa connaissance du sujet le lui permettra, et c’est depuis ce point qu’il pourra ensuite traiter la question.

Pour ce qui concerne le développement logiciel, les sous-systèmes utilisés sont souvent de bons indices pour trouver comment décomposer le problème. Par exemple, si le problème implique une transmission de données par TCP/IP, deux subdivisions possibles sont l’expéditeur et le destinataire : il ne sert à rien de chercher le problème du côté du destinataire si l’expéditeur ne transmet pas les données correctement. De même, une application graphique qui n’affiche pas les données appelées dans une base de données a une division claire : ce serait une bonne idée de vérifier d’abord que l’accès à la base de données fonctionne avant d’enquêter sur la cause du mauvais affichage. Par ailleurs, on pourrait également envoyer des informations quelconques aux fonctions d’affichage et vérifier que ces données s’affichent correctement.

Même quand les regroupements ne sont pas faciles à faire, diviser le problème peut tout de même contribuer à éclairer la question. En fait, les divisions sont presque toujours utiles, car elles réduisent la quantité de code à inspecter et le niveau de complexité à gérer. Au pire, le simple fait de diviser le code en deux parties et de chercher le problème dans l’une des deux peut être utile. Cette technique, nommée bissection, est recommandée si les divisions créées à partir des sous-systèmes et des interfaces n’ont pas encore apporté de solution.

Une succession de divisions appropriées aura pour résultat final un petit exemple autonome qui expose le problème. À ce stade, l’une des trois options suivantes est habituellement la bonne : le problème peut être identifié et localisé ; le code est en fait correct et c’était ce que l’on en attendait qui était faux ; ou bien un bogue a été trouvé dans la couche de code de plus bas niveau. Un des avantages de ce procédé, c’est qu’il génère un scénario de test à joindre à un rapport de bogue, pour peu qu’un bogue soit en cause.

Conditions aux limites (3)

Une question similaire à la division du problème est celle des conditions aux limites. En mathématiques et en physique, les conditions aux limites sont l’ensemble des valeurs qui déterminent la région de validité des équations résolues. Pour le logiciel, les conditions aux limites sont l’ensemble des conditions qui doivent être satisfaites pour que le code s’exécute correctement. Habituellement, les conditions aux limites sont loin d’être simples : à la différence des mathématiques ou de la physique, les variables des systèmes logiciels sont beaucoup trop nombreuses, ce qui signifie que leurs conditions aux limites sont également légion.

Dans les systèmes logiciels, les conditions aux limites sont souvent nommées « conditions préalables », c’est-à-dire des conditions qui doivent être satisfaites avant qu’une certaine action ne soit autorisée. Vérifier que ces conditions prélalables ont été satisfaites est un bon exercice dans la recherche d’une réponse, car leur violation est clairement un problème qui doit être résolu — quand bien même ce n’est pas la cause première du problème initial. Des conditions préalables peuvent tout simplement prendre la forme d’un pointeur qui doit être valide avant qu’on puisse le déréférencer, ou d’un objet qui ne doit pas être éliminé avant de pouvoir être utilisé. Les conditions préalables complexes seront très probablement documentées en vue de l’utilisation du logiciel.

Un autre groupe intéressant de conditions aux limites se caractérise, curieusement, par ce qui n’est pas autorisé : le comportement indéfini. Ce type de conditions aux limites est très commun lorsque l’on traite des spécifications qui essaient d’être très explicites sur la manière dont le logiciel est censé se comporter. Les compilateurs et les définitions de langage en sont un bon exemple. À strictement parler, déréférencer un pointeur null est un comportement indéfini : la conséquence la plus commune en est l’enregistrement d’une exception du processeur et l’arrêt du programme, mais d’autres comportements sont aussi autorisés, y compris le fonctionnement sans faille.

Le bon outil pour le bon usage

Si les ingénieurs sont des solutionneurs de problèmes, la devise de l’ingénieur est « Utilise le bon outil pour le bon usage ». Cela peut sembler évident, étant donné qu’on ne s’attend pas à ce que quelqu’un utilise un marteau pour résoudre un problème électronique. Cependant, les cas d’utilisation du mauvais outil sont plutôt fréquents, souvent parce qu’on ignore qu’il existe un meilleur outil.

Certains de ces outils sont la base du développement logiciel, comme le compilateur et le débogueur. L’incapacité à se servir de ces outils est impardonnable : le professionnel qui se retrouve dans un environnement d’outils nouveaux ou inconnus, si par exemple il change de poste ou d’emploi, doit consacrer du temps à apprendre à les utiliser, à se familiariser avec leurs fonctionnalités et limitations. Par exemple, si un programme plante, être capable de déterminer l’endroit du plantage ainsi que les variables appelées dans cette portion du code peut aider à trouver la cause du problème et donc la solution.

D’autres outils peu connus sont plus évolués, prévus pour des emplois spécifiques, ou encore ne sont disponibles qu’à un prix ou sous des conditions que l’ingénieur ne peut réunir. Ils peuvent toutefois être incroyablement utiles pour contribuer à la résolution de problèmes. Il peut s’agir de vérificateurs de code statique ou de processus, de débogueurs de mémoire, d’enregistreurs d’événements matériels, etc. Par exemple, le matériel de développement inclut souvent un système permettant de le contrôler à l’aide d’une interface spéficique comme JTAG ou de lister toutes les instructions exécutées et l’état des processeurs. Mais cela nécessite d’avoir du matériel et des outils spécifiques, qui ne sont pas facilement accessibles et coûtent plus cher que les machines et périphériques grand public. Un autre exemple est la suite d’outils Valgrind (4), qui comprend un vérificateur de processus et des débogueurs de mémoire. L’ensemble est gratuit, facilement disponible, mais fait partie de ces outils spécifiques de haut niveau dont l’usage n’est pas enseigné à l’école.

Connaître le contenu de sa boîte à outils est un savoir précieux. L’utilisation d’un outil spécialisé pour chercher un problème va probablement donner un résultat plus rapide, qu’il soit positif — et confirme le problème — ou négatif, et oriente la recherche dans une autre direction. Par ailleurs, il est important de savoir comment utiliser ces outils, ce qui justifie le temps passé à lire la documentation, à  s’entraîner ou simplement à expérimenter ces outils avec des problèmes connus pour comprendre comment ils fonctionnent.

Conclusion

Résoudre  les problèmes est un art accessible à tous. Comme pour tous les arts, certaines personnes semblent avoir une telle facilité qu’ils semblent être nés avec cette compétence. Mais en réalité, avec assez d’expérience et de pratique, la résolution des problèmes devient une activité insconsciente.

Quand on est confronté à un problème qui n’est pas évident à résoudre, il faut s’asseoir et le considérer dans son intégralité. Quel problème avons-nous ? Pouvons-nous formuler la question à laquelle nous devons répondre ? Une fois que nous savons ce que nous cherchons, nous pouvons commencer à examiner où peut être situé le problème. Peut-on le décomposer en parties plus petites et plus maniables ? Quels sont les meilleurs outils à utiliser pour chaque partie ? Avons-nous vérifié que nous utilisions correctement les fonctionnalités et services disponibles ?

Après avoir résolu de nombreux problèmes, on commence à repérer des schémas. Il devient plus facile de détecter des indices subtils à partir des symptômes et de diriger les recherches vers le problème réel. Un correcteur de problèmes expérimenté peut même ne pas se rendre compte que cette action a lieu. C’est un signe que l’expérience et les automatismes se sont si bien mis en place qu’il n’y a plus besoin d’effort conscient pour accéder à ces compétences.

Bien sûr il, y aura toujours des problèmes qui seront difficiles à résoudre dans la vie : problèmes professionnels, existentiels, philosophiques ou même ceux qui sont causés par la pure curiosité. Là encore, c’est le défi qui nous stimule, le besoin de comprendre toujours plus et mieux. Sans cela, la vie serait trop triste.

(1) http://fr.wikipedia.org/wiki/Apprentissage#Apprentissage_par_essais_et_erreurs

(2) http://fr.wikipedia.org/wiki/Diviser_pour_régner_(informatique)

(3) http://fr.wikipedia.org/wiki/Condition_aux_limites

(4) http://fr.wikipedia.org/wiki/Valgrind

Crédit photo Luxuryluke (CC BY-NC-ND 2.0)




Geektionnerd : Sony Copyright Extension

Geektionnerd - Simon Gee Giraudot - CC by-sa

Geektionnerd - Simon Gee Giraudot - CC by-sa

Source : Sony sort un disque de Bob Dylan uniquement pour éviter le domaine public (Numerama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)




Sauvegardes et garde-fous (Libres conseils 9/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Sky, LIAR, lerouge, yann, Goofy, peupleLaKoS, Nys, Julius22, okram, 4nti7rust, zn01wr, lamessen

Des sauvegardes pour votre santé mentale

Austin Appel

Austin Appel, alias « scorche », est un professionnel de la sécurité informatique qui passe son temps à casser (il est dûment autorisé, évidemment) des choses précédemment réputées sécurisées. On le croise souvent enseignant le crochetage de serrure durant des conférences de sécurité et de hacking. Dans le monde de l’open source, il fait une foule de choses pour le projet Rockbox et a œuvré bénévolement pour le projet One Laptop Per Child (un ordinateur portable par enfant).

Les sauvegardes c’est bien. Les sauvegardes c’est super. Un administrateur compétent fait toujours des sauvegardes régulières. On apprend ça dans n’importe quel manuel traitant de l’administration des serveurs. Le problème c’est que les sauvegardes ne sont vraiment utiles qu’en cas d’absolue nécessité. Lorsque quelque chose de grave arrive au serveur ou à ses données et qu’on est forcé de se replier sur autre chose, les sauvegardes viendront à point nommé. Cependant, cela ne devrait jamais arriver, n’est-ce pas ? À n’importe quel autre moment, à quoi cela sert-il pour vous et votre environnement serveur d’avoir des sauvegardes ?

Avant d’aller plus loin, il est important de noter que ce conseil vaut pour les administrateurs serveurs des plus petits projets open source — la majorité silencieuse. Si vous maintenez des services qui vont engendrer une grande frustration, et même peut-être faire du tort s’ils sont indisponibles, vous devriez considérer ceci avec la plus grande circonspection.

Pour le reste d’entre nous qui travaillons sur d’innombrables petits projets ayant des ressources limitées, nous avons rarement deux serveurs séparés pour la production et les tests. En vérité, avec tous les services qu’un projet open source doit maintenir (système de gestion de version, services web, listes de diffusion, forums, ferme de compilation, bases de données, traceurs de bogues ou de fonctionnalités, etc.), des environnements de test séparés sont souvent de l’ordre du rêve. Malheureusement, l’approche courante de l’administration systèmes est d’avancer avec précaution et mettre les systèmes à jour uniquement en cas de nécessité absolue, afin d’éviter tout problème de dépendance, de code cassé, ou n’importe laquelle des millions de choses qui pourraient mal se dérouler. La raison pour laquelle vous êtes nerveux n’est pas que vous pourriez manquer d’expérience. Il est important de savoir que vous n’êtes pas seul dans ce cas. Que nous l’admettions ou non, beaucoup d’entre nous ont été (et sont probablement encore) dans cette situation. Il est triste que cette inaction — découlant de la peur de détruire un système fonctionnel — conduise souvent à des services en fonctionnement qui ont souvent plusieurs versions de retard, ce qui implique de nombreuses failles de sécurité potentiellement sérieuses. Cependant, soyez assuré que ce n’est pas la seule manière de jouer le jeu.

Les gens ont tendance à jouer un jeu différent selon qu’ils aient une infinité de vies ou qu’ils doivent recommencer depuis le début dès lors qu’une seule erreur a été commise. Pourquoi devrait-il en être autrement pour de l’administration systèmes ? Aborder le concept de sauvegardes avec un état d’esprit offensif peut complétement changer votre conception de l’administration systèmes. Au lieu de vivre dans la peur d’une dist-upgrade complète (ou de son équivalent pour yum, pacman, etc.), celui qui est armé de sauvegardes est libre de mettre à jour les paquets d’un serveur, confiant dans le fait que ces changements pourront être annulés si les choses tournent au vinaigre. La clé du succès réside tout entière dans l’état d’esprit. Il n’y a aucune raison d’avoir peur tant que vous avez vos données sauvegardées sous la main comme filet de sécurité lorsque vous sautez le pas. Après tout, l’administration système est une expérience d’apprentissage permanente.

Bien sûr, si vous ne validez pas vos sauvegardes, vous reposer sur elles devient un jeu très dangereux. Heureusement, les administrateurs systèmes expérimentés savent que le commandement « Garde des sauvegardes à jour » est toujours suivi par « Valide tes sauvegardes ». À nouveau, c’est un mantra que les gens aiment réciter. Ce qui, en revanche, ne tient pas de façon élégante dans un mantra entraînant est la manière de valider rapidement et simplement ses sauvegardes. La meilleure manière de dire qu’une sauvegarde est fonctionnelle est, bien sûr, de la restaurer (de préférence sur un système identique qui n’est pas en cours d’utilisation). Mais, une fois encore, en l’absence d’un tel luxe, on doit faire preuve d’un peu plus de créativité. C’est là (tout du moins pour les fichiers) que les sommes de contrôle peuvent vous aider à vérifier l’intégrité de vos fichiers sauvegardés. Dans rsync, par exemple, la méthode utilisée par défaut pour déterminer quels fichiers ont été modifiés consiste à regarder la date et l’heure de la dernière modification, ainsi que la taille du fichier. Cependant, en utilisant l’option ‘-c’, rsync utilisera une somme de contrôle MD4 de 128 bits pour déterminer si les fichiers ont changé ou non. Bien que ce ne soit pas toujours la meilleure idée à mettre en œuvre à chaque fois en toute occasion — à cause d’un temps d’exécution beaucoup plus long qu’un rsync normal et d’une utilisation accrue des accès disques — cette méthode permet de s’assurer que les fichiers sont intègres.

Le rôle d’un administrateur systèmes peut être éprouvant par moments. Il n’est cependant pas nécessaire de le rendre plus stressant que nécessaire. Avec le bon état d’esprit, certaines commandes de précaution apparemment à but unique et limité peuvent être utilisées comme des outils précieux qui vous permettent de progresser de façon agile, tout en gardant votre santé mentale intacte et la vitesse tant appréciée dans les projets open source.