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

Traduction Framalang : merlin8282, Sphinx, Julius22, goofy, lerouge, lamessen, Asta, peupleLà, okram

Packager : la voie royale du logiciel libre

Thorn May

Thom May est développeur Debian et membre émérite de la fondation Apache. Il a été parmi les premiers à être engagés chez Canonical, l’entreprise mère d’Ubuntu. Il vit aujourd’hui à Londres et dirige l’unité de développement chez MacMillan Digital Science.

Introduction

Ça fait plus de dix ans que j’ai débuté dans le monde du logiciel libre. J’avais utilisé Debian pendant quelques années à l’université et décidé que je voulais donner quelque chose en retour. J’ai donc commencé un long voyage à travers les étapes permettant de devenir un « nouveau responsable Debian » sans avoir jamais vraiment contribué au logiciel libre auparavant et inquiet qu’un manque d’expérience en C pourrait se révéler être un gros problème.

Il s’avéra que cette inquiétude était largement infondée. En commençant à travailler avec des paquets que j’utilisais régulièrement, j’ai pu contribuer efficacement. En même temps que mon expérience avec la myriade d’outils et de systèmes que Debian fournit à ses mainteneurs s’accroissait, je devenais plus efficace pour gérer mon temps et j’étais capable de travailler sur un ensemble de paquets plus étendu.

M’occuper de davantage de paquets m’amena à travailler avec un ensemble plus important de systèmes de compilation, de langages de programmation et de boîtes à outils. Cela m’aida également à m’intégrer à la communauté Debian. Aussi rugueuse et dogmatique soit-elle, le fait que la communauté Debian repose sur des mainteneurs doués et expérimentés est l’une des raisons principales pour lesquelles Debian a maintenu son excellence technique sur une si longue période.

À peu près à ce moment, le projet Apache httpd approchait enfin des premières versions bêta de httpd 2.0 qui était restée des années en chantier et était sur le point de subir une mise à jour majeure. L’équipe Apache de Debian avait été plutôt inactive depuis quelques temps — les paquets de la version 1.3 étaient stables et changeaient peu — et n’avait pas prévu d’empaqueter la version 2.0. J’avais un intérêt majeur à garantir que les paquets httpd étaient bien maintenus. Je travaillais comme administrateur système en charge de nombreux serveurs web Apache, il tombait donc sous le sens que je devais relever le défi de la production de paquets pour la nouvelle version.

Avec un ami, nous avons commencé le travail sur les paquets et nous avons rapidement découvert que, alors que le code approchait le niveau de qualité d’une bêta toute fraîche, l’outillage autour de la compilation et de la personnalisation de httpd était hélas manquants, ce qui est assez représentatif de bien des projets logiciels complexes.

Au cours de la majeure partie de l’année — alors que les développeurs en amont stabilisaient leur code et qu’un nombre croissant d’utilisateurs précoces commençaient à tester et à déployer la nouvelle version — nous avons travaillé dur pour garantir que le système de compilation soit suffisamment flexible et robuste pour satisfaire aux rigoureux prérequis de la politique de Debian. Nous devions non seulement garantir que nos paquets étaient techniquement corrects, mais également nous assurer que notre relation avec les développeurs en amont nous permettait de leur faire remonter des correctifs dès que possible, de les avertir dès que des problèmes de sécurité faisaient surface et de leur transmettre les tests préliminaires des versions candidates.

Mes interactions avec Apache pendant l’empaquetage et la maintenance de httpd 2.0 m’ont amené à m’engager en amont du projet, ce qui signifiait que je pouvais directement contribuer au code. C’est, en général, la dernière étape avant de passer de l’empaquetage d’un logiciel à son développement actif à destination d’un public plus large que celui de votre distribution. À titre personnel, cette reconnaissance m’a donné la confiance pour contribuer à bien plus de projets libres puisque je savais que mon code était de qualité suffisante pour être bien accueilli.

L’évolution, du packager au développeur

Comment est-ce arrivé ? La création de paquets, dans sa forme la plus simple, permet d’assurer qu’un projet logiciel donné se conforme à la politique de la distribution ; dans mon cas, Debian. De manière générale, cela signifie configurer le logiciel au moment de la compilation afin qu’il soit installé dans les répertoires idoines spécifiés par le Filesystem Hierarchy Standard, ou FHS (NdT : Norme de la hiérarchie des systèmes de fichiers), que les dépendances aux autres paquets soient correctement spécifiées et que les logiciels fonctionnent normalement sur la distribution.

La création de paquets complexes peut nécessiter la division d’un projet en amont en de multiples paquets. Par exemple, les bibliothèques et les fichiers d’en-tête permettant à l’utilisateur de compiler le logiciel avec leur bibliothèque sont fournis dans des paquets distincts, et des fichiers dépendant de la plate-forme peuvent être fournis séparément de ceux qui en sont indépendants. S’assurer que le logiciel en amont se déploie correctement dans ces situations nécessitera souvent des changements dans le code. Ces changements sont la première étape vers un travail actif sur un projet, plutôt que le travail parfois passif de création de paquet.

Une fois que votre paquet est disponible dans la distribution, il est exposé à des millions d’utilisateurs potentiels. Ces utilisateurs vont sans aucun doute exécuter votre logiciel selon des pratiques que ni vous, en tant que packager, ni vos développeurs en amont n’aviez prévues. Sans surprise, avoir de nombreux utilisateurs implique l’arrivée de nombreux rapports de bogue. Debian, comme la plupart des distributions, encourage ses utilisateurs à lui soumettre directement les rapports de bogue plutôt qu’à chacun des projets individuels en amont. Ceci permet aux mainteneurs de trier les rapports de bogue et d’assurer que les modifications effectuées lors du processus de création de paquet ne sont pas la cause du problème rapporté. Souvent, il peut y avoir un grand nombre d’interactions entre le rapporteur du problème et le mainteneur du paquet avant que les développeurs en amont ne soient impliqués.

Au fur et à mesure que le mainteneur du paquet accroît sa connaissance du projet, il sera en mesure de résoudre directement la plupart des problèmes. Le mainteneur publiera souvent des correctifs de bogue directement dans Debian tout en les faisant remonter en amont, permettant ainsi à la fois une résolution rapide des problèmes et de nombreux tests de correctifs. Une fois qu’un correctif est validé, le mainteneur travaillera alors avec le projet amont pour s’assurer que les changements requis y ont bien lieu, de manière à ce qu’ils soient disponibles aux autres utilisateurs du logiciel.

Fournir des correctifs de bogue réussis pour des distributions telles que Debian relève souvent d’une forme complexe d’art. Debian fonctionne sur de nombreuses plates-formes, allant des gros serveurs IBM aux smartphones, et la gamme ainsi que la largeur de ces plates-formes révèlent rapidement les approximations dans le code. L’empaqueteur a, la plupart du temps, un accès plus aisé à une gamme de plates-formes plus étendue que les développeurs en amont et constitue, de ce fait, le premier point d’appel quand un problème épineux de portage apparaît. On apprend rapidement à reconnaître les symptômes d’une approximation de la taille d’un pointeur, les problèmes avec les endianness et bien d’autres problèmes ésotériques ; cette expérience permet de devenir un programmeur à la fois plus polyvalent et plus prudent.

Lorsqu’un paquet reçoit des corrections de bogues et des améliorations, il est essentiel que ces changements remontent en amont. Trop souvent, la différence entre un paquet et le logiciel définitif en amont peut s’accroître énormément, avec pour conséquence que les deux bases de code deviennent presque entièrement distinctes. Non seulement, cela alourdit la tâche de la maintenance des deux côtés, mais cela peut aussi créer une immense frustration et faire perdre beaucoup de temps en amont dans le cas où un utilisateur de votre paquet rapporte un bogue lié à l’un des changements dans la version empaquetée en amont. Il est en conséquence vital que s’établissent une relation de travail étroite avec la branche amont et une compréhension de la meilleure façon de collaborer entre les deux parties.

La collaboration entre les développeurs et le packager peut prendre bien des formes. Que ce soit trouver la bonne voie pour communiquer les rapports de bogue, s’assurer de l’utilisation du bon style de codage, du même usage du système de contrôle de version ou des interactions qui provoquent le moins de frictions possible. Tout ceci amène une bien meilleure relation avec l’amont et accroît grandement la probabilité que ceux qui y travaillent prendront le temps de vous aider quand vous en aurez besoin.

Une fois que la relation de travail entre l’amont et vous est établie, il devient facile de contribuer plus directement en amont. Ceci peut également se faire de bien des façons différentes. Les premières étapes, simples, peuvent impliquer la synchronisation de n’importe quel rapport de bogue en amont avec ceux de votre distribution, afin d’être sûr que ce double effort impacte la cause primaire et résolve des bogues. Une implication plus directe consiste à développer des fonctionnalités et à changer plus largement que ce qui serait acceptable dans le cadre d’une version empaquetée.

Conclusion

Je pense que les deux choses essentielles que j’aurais aimé connaître lorsque j’ai commencé sont le sens de la communauté que le logiciel libre fait naître et la merveilleuse voie que le packaging de logiciel libre ouvre vers le plus vaste monde du logiciel libre

La communauté est essentielle au succès du logiciel libre. Elle se présente sous différentes formes, de la multitude d’utilisateurs souhaitant investir du temps dans l’amélioration de votre logiciel, jusqu’aux pairs d’une distribution ou d’un projet logiciel, qui investissent leur temps et leur énergie à affûter vos compétences et à s’assurer que vos contributions sont aussi bonnes que possible.

La voie qui part du packaging pour aller vers le développement est l’une des plus empruntées. Elle présente une courbe d’apprentissage moins raide qu’aborder directement le développement et permet d’acquérir des compétences à un rythme moins soutenu qu’en suivant d’autres chemins.

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

Traduction Framalang : satanas_g, Sphinx, Sky, Julius22, peupleLà, lamessen, goofy

Du débutant au professionnel

Jonathan Riddell

Jonathan Riddell est développeur KDE et Kubuntu, actuellement employé par Canonical. Quand il n’est pas devant un ordinateur, il fait du canoë sur les rivières d’Écosse.

Il y avait un bogue dans le code. Un bien méchant en plus : un plantage sans enregistrement des données. C’est bien là le problème dès qu’on regarde le code, on trouve des trucs à réparer. C’est facile de s’impliquer dans le logiciel libre ; le plus dur est d’en sortir. Après le premier bogue réparé, il y en a d’autres, et de plus en plus, tous à portée de main. Les corrections de bogues mènent à l’ajout de fonctionnalités, ce qui mène à la maintenance de projet, ce qui mène à faire fonctionner une communauté.

Tout a commencé en lisant Slashdot, cette masse d’actualité geek et technique peu filtrée avec des commentaires de quiconque peut recharger assez vite pour être en haut de liste. Chaque actualité était intéressante et excitante, apportait un éclairage nouveau sur le monde de la technologie qui finissait par me fasciner. Je n’avais plus à accepter ce qui m’était donné par de grandes entreprises de logiciels, je pouvais voir là, dans la communauté du logiciel libre, le code se développer devant moi.

En tant qu’étudiant, il était possible de finir les exercices donnés par les professeurs très rapidement. Mais les exercices ne sont pas des programmes terminés. Je voulais savoir comment appliquer les compétences basiques qu’ils m’avaient données dans le monde réel en écrivant des programmes résolvant des problèmes réels pour les gens. J’ai donc recherché du code, qui n’était pas difficile à trouver, il se trouvait là, sur Internet, en fait. En regardant le code des programmes que j’utilisais de plus près, j’y ai décelé de la beauté. Non pas parce que le code était parfaitement soigné ou bien structuré, mais parce que je pouvais le comprendre avec les concepts que j’avais déjà appris. Ces classes, méthodes et variables étaient bien en place, me permettant de résoudre les problèmes pertinents. Le logiciel libre est le meilleur moyen de franchir le pas entre savoir comment finir ses exercices de cours et comprendre comment de vrais programmes sont écrits.

Tous les étudiants en informatique devraient travailler sur du logiciel libre comme sujet de leur mémoire. Sinon, vous avez de grandes chances d’y passer six mois à un an pour qu’il finisse au sous-sol d’une bibliothèque sans être jamais plus consulté. Seul le logiciel libre permet d’exceller en faisant ce qui va de soi : vouloir apprendre comment résoudre des problèmes intéressants. À la fin de mon projet, des programmeurs de la NASA utilisaient mon outil de création de diagrammes en UML (NdT : langage de modélisation unifié) et il reçut des prix au cours de réceptions somptueuses. Avec le logiciel libre, on peut résoudre de vrais problèmes pour de vrais utilisateurs.

La communauté des développeurs est remplie de personnes formidables, passionnées et dévouées à leur travail, sans espoir autre de récompense qu’un programme d’ordinateur couronné de succès. La communauté des utilisateurs est également incroyable. Il est satisfaisant de savoir qu’on a aidé quelqu’un à résoudre un problème. Et j’apprécie les messages de remerciement que je reçois.

Après avoir écrit un logiciel utile, il faut le mettre à la disposition du plus grand nombre. Le code source ne va pas fonctionner pour la plupart des gens, il doit être compilé. Avant d’être impliqué, je trouvais que le fait de compiler était une manière un peu paresseuse de contribuer au logiciel libre. Vous vous attirez la plus grande partie de la reconnaissance sans rien avoir à coder. C’est, quelque part, quelque chose d’injuste. De même, la gestion de la communauté nécessaire pour porter un projet de logiciel libre peut aussi être vue comme une façon de s’attirer la reconnaissance sans faire de code.

Les utilisateurs dépendent beaucoup des packagers (NdT : les « empaqueteurs » qui préparent et maintiennent les paquets logiciels). Il est nécessaire que leur travail soit à la fois rapide, pour satisfaire ceux qui veulent la dernière version, et fiable, pour ceux qui veulent la stabilité (autant dire tout le monde). La partie la plus délicate, c’est que cela implique de travailler avec les logiciels des autres, qui sont toujours « cassés ». Une fois que le logiciel est lâché dans la nature, commencent à emerger des problèmes qui n’étaient pas repérables sur l’ordinateur de l’auteur. Il est possible que le code ne puisse pas être compilé avec une version de compilateur différente, peut-être que la licence n’est pas claire et ne permet pas de le copier, peut-être que la gestion des versions est incohérente et qu’une mise à jour mineure est incompatible, ou encore que la taille de l’écran est différente, les environnements de bureau peuvent aussi l’affecter, quelquefois, des bibliothèques tierces nécessaires ne sont pas encore à jour. De nos jours, le logiciel doit pouvoir tourner sur différentes architectures. Les processeurs 64 bits ont occasionné pas mal de problèmes quand ils sont devenus courants. Aujourd’hui, ce sont les processeurs ARM qui déjouent les calculs des codeurs. Les packagers doivent régler tous ces problèmes pour donner aux utilisateurs quelque chose qui fonctionne de façon fiable.

Nous avons une règle chez Ubuntu selon laquelle les paquets avec des tests unitaires doivent inclure ces mêmes tests dans le processus de la création des paquets. Souvent, ils échouent et l’auteur du logiciel nous dit que les tests sont uniquement à son usage. Malheureusement, quand il s’agit de logiciel, il n’est jamais assez fiable de le tester soi-même, il doit aussi être testé par d’autres. Un test unique est rarement suffisant, il faut une approche à plusieurs niveaux. Les tests unitaires du programme original devraient être le point de départ, ensuite, le packager les teste sur son propre ordinateur, il faut ensuite que d’autres personnes les testent aussi. L’installation automatique et les tests de mise à jour peuvent être scriptés assez correctement sur les services d’informatique dans le nuage. L’envoyer dans la branche de développement d’une distribution permet d’effectuer plus de tests avant de le voir distribué en masse quelques mois après. À chaque étape, des problèmes peuvent être et seront découverts, ils devront être corrigés, puis ces correctifs eux-mêmes devront être testés. Il n’y a donc pas forcément à écrire beaucoup de code, mais il y a pas mal de travail pour passer le logiciel de 95 % à 100 % prêt. Ces 5 % sont la partie la plus difficile, un lent et délicat processus qui demande une grande attention pendant tout son cours.

Vous ne pouvez pas faire de paquets sans une bonne communication avec les développeurs en amont. Quand des bogues se produisent, il est vital de pouvoir trouver la bonne personne à laquelle parler rapidement. Il est important d’apprendre à bien les connaître comme des amis et des collègues. Les conférences sont vitales pour cela, car rencontrer quelqu’un apporte beaucoup plus de contexte à un message sur une liste de diffusion qu’une année entière de messages.

Une des faces cachées du monde du logiciel libre réside dans la communication par les canaux IRC privés utilisés par les principaux membres d’un projet. Tous les grands projets en ont. Quelque part, Linus Torvalds a un moyen de discuter avec Andrew Morton et les autres sur ce qui est bon et sur ce qui est mauvais dans Linux. Ils sont plus sociaux que techniques et, quand on en abuse, ils peuvent être très antisociaux pour la communauté en général. Mais pour les moments où on a besoin d’un canal de communication rapide sans bruit parasite, ils fonctionnent bien.

Tenir un blog est un autre moyen de communication important dans la communauté du logiciel libre. C’est notre principale méthode pour promouvoir à la fois le logiciel que nous produisons et nous-mêmes. Non pas que ce soit utilisé éhontément pour de l’auto-promotion (il est inutile de prétendre que vous sauverez des vies avec votre blog…), mais parler de votre travail sur le logiciel libre aide à construire une communauté. Cela peut même vous valoir de trouver un travail ou d’être reconnu dans la rue.

Ces histoires venant de Slashdot, à propos de développements de nouvelles technologies, ne concernent pas des personnalités éloignées que vous ne rencontrerez jamais comme dans la presse people. Elles concernent des personnes qui ont trouvé un problème et qui l’ont résolu en utilisant l’ordinateur qu’elles avaient en face d’elles. Pendant quelques années, j’ai édité le site d’informations de KDE, trouvant les personnes qui résolvaient des problèmes, créaient des idées novatrices, s’acharnaient longuement à améliorer un logiciel jusqu’à ce qu’il soit d’une qualité suffisante, et j’en parlais au monde entier. Je n’ai jamais été à court d’histoires à raconter ni de personnes à présenter à tout le monde.

Mon dernier conseil est de conserver de la diversité. Il existe une telle richesse de projets intéressants à explorer, qui vous permettent d’apprendre et de progresser. Mais une fois que vous avez atteint une position de responsabilité, il peut être tentant d’y rester. Après avoir aidé à créer une communauté pour Kubuntu, je repars temporairement vers un travail sur Bazaar, un projet très différent, orienté sur les développeurs plutôt que sur des utilisateurs novices en technologies. Je peux à nouveau apprendre comment le code devient une réalité utile, comment une communauté communique, comment la qualité est maintenue. Ce sera un défi amusant et j’ai hâte de m’y attaquer.

Il fut un temps ou débuter dans « le Libre » se résumait avant tout à coder ou plus modestement installer une distribution GNU/Linux. Aujourd’hui les choses ont bien changé et il existe de multiples autres façons d’y entrer. Framasoft est d’ailleurs là pour en témoigner 😉

Une invitation à venir nous rejoindre en somme…

Remarque : Il s’agit d’une traduction et donc les liens renvoient vers des ressources anglophones. Si vous avez des liens plus locaux à proposer, surtout ne pas hésiter.

10 façons de commencer dans l‘open source

10 ways to get started with open source

Jason Hibbets – 29 janvier 2013 – OpenSource.com
(Traduction : goofy, Tibo_R, XeO2, Steph, Alpha, Sylvie, jtanguy, aKa, Liaz, Norore + anonymes)

Par expérience, je sais qu’un grand nombre de personnes veulent découvrir et participer à l‘open source, mais ne savent pas par où commencer ; et l’idée que l’on est obligé d’écrire du code pour contribuer à un projet open source constitue une véritable barrière. J’ai donc esquissé 10 façons de commencer avec l‘open source et ce sans jamais écrire une seule ligne de code.

Je suis ouvert à toutes idées et ajouts ; il y a sans doute beaucoup plus que 10 façons de contribuer.

10 façons de commencer à utiliser l‘open source

1. Utiliser de l‘open source dans votre travail quotidien. Téléchargez et installez un navigateur web, un client de messagerie, ou une suite bureautique libres — peu importe le système que vous utilisez. C’est l’une des façons les plus simples de commencer à utiliser des logiciels libres. Je conseillerai Firefox pour la navigation internet et Thunderbird pour les emails. Utilisez LibreOffice pour votre traitement de texte, vos tableurs et vos diaporamas, vous aurez un équivalent de Microsoft Office gratuit ! J’appelle ces logiciels des applications porte d’entrée, parce qu’une fois que vous commencez à les utiliser, vous allez découvrir d’autres outils open source (et vous n’aurez pas envie de revenir en arrière !)

2. Rejoindre un projet open source. Je sais que rejoindre un projet open source peut faire peur, mais les contributeurs de tous niveaux sont les bienvenus. Les communautés open source utilisent des chefs de projets, des graphistes, des communicants, des commerciaux et beaucoup d’autres compétences dans leurs travaux. Si vous souhaitez présenter l’open source aux étudiants, voilà une très bonne façon de commencer. On ne sait jamais, s’impliquer et participer activement à un projet open source peut améliorer un CV et mener à un emploi.

3. Lire un livre à propos de l‘open source. Voici un choix de quelques titres auxquels vous pouvez jeter un coup d’oeil : Open Advice (NdT : que nous sommes en train de traduire), Coding Freedom, The Power of Open, ou l’un de nos livres numériques. (NdT : En français il y a évidemment tous les titres de la collection Framabook)

4. Apprendre à créer et nourrir des communautés de contributeurs. Parcourez le livre en ligne The Open Source Way, et partagez vos nouvelles connaissances en créant une communauté ou en en rejoignant une existante.

5. Commencer à utiliser les licences Creative Commons. Avant de créer votre nouvelle œuvre d’art, photographie, écrit ou musique, utilisez un copyleft au lieu d’un copyright. En utilisant des licences Creative Commons, vous pouvez partager votre travail avec le monde entier. Vous devrez d’abord choisir celle qui vous correspond, vous pourrez ensuite trouver intéressant de découvrir comment les Creative Commons sont utilisées dans des environnements aussi variés que les gouvernements, les entreprises ou le journalisme. (NdT : Voir aussi L’éducation utilise une licence Creative Commons défectueuse, par R. Stallman sur le Framablog)

6. Commencer l’exploration. Regardez le projet OpenROV et explorez l’océan ou un lac local. Si vous ne voulez pas être mouillé, enfilez une combinaison spatiale et regardez ce que ça fait d’explorer Mars.

7. Bricoler par soi-même et créer quelque chose. Les petites cartes Linux, comme la Raspberry Pi, font des choses incroyables. Découvrez les autres cartes électroniques de création comme les « Makey Makey » (cf cette vidéo) ou une variété de produits électroniques de « SparkFUN ». Si vous êtes dans l’impression 3D, assurez-vous de savoir comment vous pourriez utiliser Inkscape.

8. Devenir créatif. Remplacez Photoshop par GNU Image Manipulation Program (GIMP), InDesign par Scribus, ou utilisez d’autres outils comme MyPaint, Inskape, Audacity et Blender. Si cela vous intéresse, regardez notre présentation en 7 minutes des outils créatifs open source. Puis découvrez l’étendue des outils de design en 2012. Assurez-vous d’avoir pris connaissance de nos autres outils tels que Dream Studio, TuxPaint et KDEnlive pour vos besoins créatifs.

9. Apprendre la programmation. Remarquez que je n’ai pas dit « Apprendre à coder ». Différents outils sont pré-installés sur certains Raspberry Pi et sont utilisés pour apprendre aux enfants à programmer. J’aurais aimé avoir ce genre de choses quand j’ai appris la programmation au lycée.

10. Suivre un cours en ligne. Le mouvement OpenCourseWare, mené par MITOCW, est en train de changer notre mode d’apprentissage. Commencez par regarder ce Webcast sur le MIT OpenCourseWare. Il y a tellement d’événements open source dans le champ éducatif: « Moodle » et « School management software for teachers and students » sont deux de ces nombreuses ressources fantastiques. (NdT : Exemple en France la présentation du MOOC ITyPA)

Le fait est qu’il y a énormément de manières de commencer dans l‘open source. Vous souvenez-vous de la façon dont vous avez débuté ? Partagez l’histoire de votre première expérience avec l‘open source ou comment vous l’avez présentée à quelqu’un d’autre.

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

Traduction Framalang : Sphinx, peupleLà, lerouge, goofy, alpha, Sky, Julius22, lamessen, vvision, Garburst, okram

Le guichet de billetterie

La thèse de doctorat d’Alexander a servi de base à son livre Notes on the Synthesis of Form (NdT : Remarques sur la synthèse de la forme), paru en 1964. Il essayait de rationaliser le processus de conception en le définissant comme une progression depuis une série de conditions préalables jusqu’à un résultat final, grâce à une analyse des forces qui déterminent le design.

Permettez-moi de citer Richard Gabriel, dont je parlerai plus tard, quand il décrit l’époque où Alexander essayait de concevoir un guichet de billetterie en prenant appui sur ses idées mathématiques :

Alexander dit (à propos de la qualité sans nom) :

Il s’agit d’un type subtil de liberté issu de contradictions internes. (Alexander, 1979)

Cette assertion fait écho aux origines de sa recherche sur la qualité. Elle commença en 1964 alors qu’il était en train de réaliser une étude pour le San Francisco Bay Area Rapid Transit District (BART) basée sur le travail rapporté dans Notes on the Synthesis of Form (Alexander 1964), lui-même basé sur sa thèse de doctorat. L’une des idées-clés de ce livre était qu’avec une bonne conception, il doit y avoir une relation sous-jacente entre la structure du problème et la structure de la solution — les bonnes conceptions passent par la rédaction d’une analyse des besoins, l’analyse de leurs interactions sur les bases d’incompatibilités potentielles, produisant ainsi une décomposition hiérarchisée des différentes parties, et la reconstitution d’une structure dont

la hiérarchie structurelle est l’exact complémentaire de la hiérarchie fonctionnelle établie durant l’analyse du programme. (Alexander, 1964)

Alexander a analysé le système de forces mises en jeu dans la conception d’un guichet. Lui et son groupe avaient rédigé un cahier des charges en 390 points pour couvrir tous les cas de figure d’usage de l’édicule. Certaines spécifications concernaient des choses telles qu’être là pour obtenir des billets, pouvoir faire de la monnaie, pouvoir déplacer les personnes qui font la queue, réduire la durée d’attente pour obtenir des billets. Il a toutefois remarqué que certaines parties du système n’étaient pas concernées par ces spécifications et que le système lui-même pouvait s’enliser parce que ces autres forces — celles qui ne faisaient pas l’objet d’une spécification — agissaient pour arriver à leur propre équilibre au sein du système. Par exemple, si une personne s’arrêtait et qu’une autre s’arrêtait également pour parler avec la première, cela pouvait créer un embouteillage susceptible de mettre en échec les mécanismes mis au point pour maintenir une circulation fluide. Bien sûr, l’absence d’embouteillage faisait partie des spécifications. Mais il n’y avait rien que les concepteurs puissent faire pour l’empêcher par le biais d’un mécanisme adapté.

En tant que programmeur, ça doit vous rappeler quelque chose ? Vous pouvez élaborer une conception magnifique et parfaitement rigoureuse, mais qui s’effondrera quand vous la construirez effectivement parce que des éléments que vous n’aviez pas anticipés apparaitront alors. Ce n’est pas un échec de votre conception, mais de quelque chose d’autre ! Richard Gabriel poursuit :

Alexander disait ceci :

Il devint alors clair que le bon fonctionnement d’un système ne dépendait pas uniquement de la satisfaction d’une série de conditions préalables. Il s’agissait plutôt d’un système qui trouve sa cohérence en lui-même et en équilibre avec les forces internes générées par ledit système que de l’accord avec une série quelconque de conditions préalables que nous aurions arbitrairement définie. Cela m’intriguait beaucoup car l’idée qui prévalait en général à l’époque (en 1964) était que, pour l’essentiel, tout était fondé sur des objectifs. Toute mon analyse des conditions préalables tendait à converger avec le point de vue de la recherche opérationnelle qui pose qu’il faut établir des objectifs, etc. Ce qui m’ennuyait, c’est qu’une analyse correcte du guichet ne pouvait se baser uniquement sur des objectifs quelconques ; il y avait des réalités qui émergeaient du centre du système lui-même et qui, peu importe votre degré de réussite, avaient un rapport avec le fait que vous ayez créé une configuration stable au regard de ces réalités.

Et c’est le cœur du problème : comment créer une configuration stable avec les réalités qui en émergent au fur et à mesure que vous la construisez ?

La nature de l’ordre

Bien que Christopher Alexander ait eu conscience d’avoir produit quelque chose de précieux avec ses recherches et catalogues de modèles, il n’était pas complètement satisfait. D’où venaient les modèles ? Pouvait-on les créer à partir de rien ou devait-on se satisfaire de ce qu’avait produit jusque-là l’architecture traditionnelle ? D’ailleurs, les modèles étaient-ils réellement nécessaires ? Comment pouvait-on mieux définir et évaluer ou mesurer cette « Qualité sans nom » ?

Alexander passa les vingt années suivantes à tenter de répondre à ces questions. En étudiant le processus réel de création par lequel des environnements bien construits avaient vu le jour, il découvrit que certains processus sont indispensables pour créer des villes ou des édifices agréables — ou toute création humaine en fait. Il arriva aux conclusions suivantes :

• La nature crée des choses qui ont toutes une quinzaine de propriétés en commun (je vous expliquerai plus tard). Cela se produit uniquement par des processus naturels — physique et chimie de base — bien que nous ne sachions pas clairement pourquoi des procédés très différents produisent des résultats similaires ;

• On retrouve ces propriétés dans les architectures traditionnelles ou les villes qui ont simplement évolué au cours du temps. Tous les modèles décrits dans A Pattern Language peuvent être obtenus en suivant une méthode fondée sur ces propriétés ;

• Chaque propriété peut également décrire une transformation de l’espace existant ;

• La seule façon de réussir une bonne conception consiste à utiliser ces transformations, une à la fois.

Ceci a été publié en 2003 – 2004 en quatre tomes intitulés The Nature of Order (NdT : « La nature de l’ordre »).

Les quinze propriétés

Le premier tome de La nature de l’ordre traite de quinze propriétés qui apparaissent dans tous les systèmes naturels. Je les résumerai très brièvement (voir les références pour des illustrations et de plus amples explications).

• Des niveaux d’échelle. La gamme de tailles est équilibrée, sans changement brutal dans la taille d’objets adjacents. Les éléments ont une échelle fractale ;
• Des centres forts. Les différentes parties de l’espace ou de la structure sont clairement identifiables ;
• Des frontières solides. Les lignes délimitent les choses. Dans les systèmes vivants, les bords sont les environnements les plus productifs (par exemple, toutes les créatures qui vivent au bord de l’eau) ;
• Des répétitions alternées. Haut/bas, épais/fin, forme A et forme B. Les objets oscillent et alternent afin de créer un bon équilibre ;
• Un espace positif. L’espace adopte une belle forme convexe et close. Ce n’est pas de l’espace excédentaire. Pensez à la manière dont les cellules d’un diagramme de Voronoï grandissent vers l’extérieur à partir d’un ensemble de points ou à la manière dont les grains d’un épi de maïs se développent à partir de petits points jusqu’à ce qu’ils touchent les grains adjacents ;
• Une bonne forme. Les voiles d’un bateau, la coquille d’un escargot, le bec d’un oiseau. Ils parviennent à la forme optimale qui sert leur fonction, ce qui est magnifique ;
• Des symétries locales. Le monde n’est pas symétrique dans son ensemble. Cependant, les petites choses tendent à être symétriques parce que, de cette manière, c’est plus facile. Votre maison n’est pas symétrique, mais chaque fenêtre l’est ;
• Une profonde imbrication et de l’ambiguïté. Les rues sinueuses des vieilles villes. Les axones des neurones. Il est difficile de séparer la forme du fond, ou l’avant-plan de l’arrière-plan. Deux centres forts sont renforcés si un troisième est placé entre eux de manière à ce qu’il appartienne aux deux ;
• Du contraste. Vous pouvez distinguer où une chose se termine et où la suivante commence parce qu’elles ne se fondent pas l’une dans l’autre ;
• Des degrés. Les choses se confondent les unes les autres là où c’est nécessaire. Les concentrations dans des solutions, les congères ou les talus, les câbles supportant un pont. La manière dont la bande passante décroît alors que vous vous éloignez de l’antenne ;
• Des aspérités. Le monde n’est ni exempt de frottement, ni doux. Les irrégularités sont bénéfiques car elles permettent à chaque élément de s’adapter à son environnement, plutôt que d’être une copie conforme qui n’irait pas aussi bien ;
• Des échos. Les choses se répètent et se font écho. Elles sont uniques dans la précision de leur forme mais leurs contours généraux se répètent à l’infini ;
• Du vide. Parfois, vous avez un grand espace vide pour la tranquillité de la forme. Un lac, une cour, le cadre d’une image ;
• De la simplicité et du calme intrinsèque. Les choses sont aussi simples que possible, sans être simplistes ;
• De l’interdépendance. Chaque chose est dépendante de tout le reste. On ne peut pas séparer un poisson du bassin et des plantes aquatiques. On ne peut pas séparer une colonne de la base du bâtiment.

Le célèbre (et libre) langage de programmation Python est en danger en Europe pour une sombre histoire de droit des marques.

Nous avons traduit ci-dessous l’appel à soutien de Van Lindberg, président de la Python Software Foundation.

La marque Python en péril en Europe : Nous avons besoin de votre aide !

Python trademark at risk in Europe: We need your help!

Van Lindberg – 14 février 2013 – Python Software Foundation
(Traduction : Moosh, lgodard, Alpha, QuébecTroll, jtanguy, Penguin, Uflex, ProgVal, goofy, maz, Nodel, Norore + anonymes)

Vous qui travaillez dans une entreprise qui a un bureau dans un pays membre de l’Union Européenne, nous avons besoin de votre aide.

Une entreprise au Royaume-Uni essaye de faire reconnaître le terme « Python » comme marque commerciale pour tout logiciel, service ou serveur, à peu près tout ce qui a quelque chose à voir avec un ordinateur. Plus précisément, c’est l’entreprise qui a acquis le domaine python.co.uk il y a treize ans. À cette époque, nous nous souciions peu des problèmes de marque et nous n’avions pas acquis ce domaine.

Ce n’était pas un problème jusqu’à présent car le domaine python.co.uk, la plupart du temps, se contentait de transférer son trafic vers les sociétés-mères, veber.co.uk et pobox.co.uk. Malheureusement, Veber a décidé qu’ils voulaient commencer à utiliser le nom « Python » pour leurs logiciels serveurs.

Nous avons contacté les propriétaires de python.co.uk à plusieurs reprises et essayé d’en discuter avec eux. Leur seule réponse a été de déposer une demande de marque communautaire réclamant les droits exclusifs d’utiliser le terme « Python » pour des logiciels, serveurs, et services web – et ce partout en Europe.

Nous avons fait appel à un conseiller juridique au Royaume Uni et nous, la Python Software Foundation (NdT :. la Fondation Python), opposons à cette demande une demande de dépôt de marque communautaire, mais notre propre demande n’est pas suffisamment mûre. Dans cette dernière, nous exposons les droits de propriété de la marque résultants de l’utilisation de “Python” au cours de ces 20 dernières années.

D’après notre avocat londonien, les meilleures preuves que nous puissions transmettre au bureau européen des marques déposées sont les lettres d’entreprises connues « utilisant le logiciel de marque PYTHON dans divers pays de l’Union Européenne » de telle sorte que nous puissions « obtenir des témoignages indépendants de leur part, prouvant l’origine de la signification de la marque PYTHON, en relation avec le logiciel et les produits/services associés ». Nous avons aussi besoin de preuves d’utilisation de Python à travers toute l’Union Européenne.

Que pouvez-vous faire ?

1- Vous travaillez pour une entreprise qui utilise Python ? Vous êtes basés en Europe, vous y embauchez ou vous y possédez un bureau ? Pourriez-vous écrire une lettre avec l’en-tête de votre entreprise que nous pourrions réutiliser par la suite ?

Nous aurions besoin des élements suivants :

1. Une brève description de l’utilisation de Python dans votre entreprise :
2. Comment votre entreprise associe le terme Python uniquement à la PSF ;
3. Votre opinion sur le fait qu’une autre entreprise utilisant le terme Python dans ses services, logiciels et serveurs pourrait âtre source de confusion.

La lettre n’a pas besoin d’être très longue —- quelques paragraphes suffisent, mais nous apprécierions toute forme de description de votre utilisation de Python dans vos logiciels, votre hébergement internet, vos serveurs, vos VPN, dans le développement de logiciel ou de matériel ou encore dans l’utilisation de services de sauvegarde. Pour ceux qui sont intéressés par les classes descriptives légales, elles figurent au bas de ce message^[1][2].

Vous pouvez envoyer une copie PDF de votre lettre à psf-trademarks@python.org

2. Connaissez-vous ou possédez-vous quoi que ce soit qui ait été publié au sein de l’UE et qui utilise “Python” pour faire référence au langage Python? Pouvez-vous nous transmettre des numérisations, photos ou copies? Cela comprend :

• Des livres ;
• Des brochures ;
• Des programmes de conférences ou présentations ;
• Des offres d’emploi ;
• Des magazines ou autres publications ;
• Des prospectus.

Vous pouvez envoyer un scan PDF de ces documents à psf-trademarks@python.org.

3. Vous pouvez également aider à protéger la propriété intellectuelle de Python en nous soutenant financièrement.

Comme le coût d’opposition d’une marque commerciale est de l’ordre de dizaines de milliers de dollars, nous aurons besoin de trouver un moyen de financer les coûts de procédure de l’opposition.

Merci d’envisager une donation à la Python Software Foundation ou de me contacter.

C’est la première fois que la PSF doit prendre des mesures juridiques pour protéger la propriété intellectuelle de Python. S’il vous plait, aidez Python comme vous le pouvez. La menace est réelle et elle est susceptible de nuire à votre entreprise en Europe, surtout si vous êtes dans le domaine de l’hébergement et que Python fait partie de l’offre que vous proposez.

S’il vous plaît, faites-moi savoir si vous avez des questions auxquelles je peux répondre. Si vous connaissez quelqu’un qui devrait avoir l’information, libre à vous de la partager.

Thanks, Merci,

Van Lindberg, Président
van@python.org
Python Software Foundation

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

Traduction Framalang : Sphinx, peupleLà, lerouge, goofy, alpha, Julius22, SaSha_01, vvision, lamessen, Bob, lamessen, Garburst, okram

Le logiciel comme Qualité sans Nom

Federico Mena Quintero

Federico Mena Quintero est l’un des pères fondateurs du projet GNOME et fut auparavant le mainteneur de GIMP. Il travaillait aux Red Hat Advanced Development Labs durant les débuts de GNOME puis fut l’un des premiers à être recruté chez Ximian où il a principalement travaillé sur le calendrier d’Evolution. Il travaille toujours autour de GNOME pour Novell/Suse et vit au Mexique.

Lorsque j’apprenais la programmation, j’ai remarqué que je rencontrais souvent le même problème, encore et encore. J’écrivais souvent un programme qui fonctionnait relativement bien et était même bien structuré. Mais après quelques modifications et améliorations, je ne pouvais plus l’améliorer davantage. Soit sa complexité me surpassait, soit il était écrit de telle manière qu’il ne permettait pas d’évolution, comme une maison que vous ne pouvez pas agrandir à cause d’un toit pentu ou que vous ne pouvez pas étendre sur les côtés à cause des murs qui l’entourent.

À mesure que je progressais, j’ai appris à gérer cette complexité. Nous apprenons tous à le faire avec différents outils et techniques : l’abstraction, l’encapsulation, l’orientation objet, les techniques fonctionnelles, etc. Nous apprenons comment diverses techniques nous permettent d’écrire des programmes plus complexes.

Cependant, le problème d’un programme trop optimisé ou bien trop intimement enchevêtré pour être modifié a persisté. Parfois, je pensais tenir une superbe conception. Mais la modifier d’une façon quelconque l’aurait « amochée » et je ne le souhaitais pas. D’autres fois, j’avais quelque chose avec tellement de parties imbriquées que je ne pouvais plus y connecter quoi que ce soit sans que tout s’effondre sous son propre poids.

Il y a quelques années, la manie de la réécriture a débuté sans que j’y prête trop attention. Je me disais que c’était une façon de nettoyer le code, mais après ? Je sais déjà comment prendre un morceau de code et le transformer en fonction ; je sais déjà comment prendre des morceaux de code similaires et les transformer en classes dérivées. Je sais déjà écrire du code presque entièrement propre. Quel est donc le problème ?

J’ai écarté la refactorisation(1) en la considérant comme destinée aux programmeurs les moins expérimentés ; comme de jolies recettes de nettoyage de code mais rien qui ne puisse être découvert par soi-même.

La même chose s’est produite avec les canevas de conception. Je pensais qu’ils donnaient simplement des noms pompeux tels que Singleton et Strategy à des types de structures de tous les jours qu’on utiliserait naturellement dans un programme. Peut-être mon ego de programmeur était-il trop démesuré pour considérer ces travaux avec sérieux. C’est alors que quelque chose s’est produit.

Le travail de Christopher Alexander

Il y a quelques années, mon épouse et moi avons acheté une petite maison de plain-pied et nous souhaitions l’agrandir. Nous envisagions d’avoir un enfant et avions, par conséquent, besoin de plus d’espace. J’avais besoin d’un vrai bureau à domicile, pas une simple niche inoccupée dans laquelle mon bureau et mes étagères de livres tiendraient à peine. En tant que cuisiniers avides, nous avions tous les deux besoin d’une cuisine plus spacieuse et confortable que celle de notre maison. Mon épouse avait besoin d’une pièce bien à elle.

Nous ne voulions pas payer pour un architecte coûteux et aucun de nous deux n’avait la moindre connaissance en matière de construction. Comment allions-nous concevoir notre maison ?

Par moments, en naviguant sur le Web, je me rappelais que j’avais déjà vu le nom d’un auteur, le titre d’un livre ou quelque chose comme ça. Il se peut que je n’y aie pas vraiment porté attention par le passé mais, d’une manière ou d’une autre, plus je vois la même chose mentionnée, plus il est probable que je finirai par m’y intéresser suffisamment pour aller voir de quoi il s’agissait. « Oh, plusieurs personnes ont déjà mentionné ce nom ou ce livre ; je devrais peut-être y jeter un coup d’œil  »

C’est exactement ce qui s’est passé avec le nom de Christopher Alexander. J’avais lu que c’était un architecte assez spécial (de vrais bâtiments, pas de logiciels), connecté en quelque sorte au monde du logiciel par le biais de techniques orientées objet. J’ai été passionné par son travail dès que j’ai commencé à le découvrir par mes lectures.

Dans les années 1970, Christopher Alexander était un mathématicien et professeur d’architecture à l’université de Californie, Berkeley. Lui et un groupe d’architectes de la même mouvance que lui ont parcouru le monde, essayant de comprendre pourquoi il existait des endroits construits par des humains (cités, villes, parcs, immeubles, maisons) où il était très agréable de vivre, confortables, conviviaux et jolis, tandis que d’autres endroits ne l’étaient pas. Des lieux agréables étaient présents dans toutes les architectures traditionnelles du monde — européennes, africaines, asiatiques et américaines — amenant à l’idée que des facteurs communs étaient sans doute extractibles.

Alexander et son équipe ont réparti leurs découvertes au sein d’une liste de motifs architecturaux cohérents et publié trois livres : The Timeless Way of Building (NdT « L’art de la construction intemporelle » en français), où sont décrites la philosophie et la méthode nécessaires à une bonne construction ; A Pattern Language (NdT : « Un langage de schémas » en français), que je décris ci-après et The Oregon Experiment (NdT « L’expérience de L’Oregon » en français) où sont détaillés la conception et la construction d’un campus universitaire grâce à leur méthode.

Une grammaire de modèles

Un modèle (ou schéma) est un problème récurrent lors de la conception et de la construction d’objets, en lien avec les contraintes qui modèlent le problème et avec une solution connectée, quasi-récursivement à d’autres modèles-pères ou modèles-fils. Par exemple, considérons le GRADIENT D’INTIMITÉ, un modèle important dans le livre (les modèles étant en capitales dans ce livre pour en faciliter l’identification, je ferai donc de même) :

GRADIENT D’INTIMITÉ

<!-- wikipedia : patron de conception *

pour la compréhension : http://www.jacana.plus.com/pattern/P127.htm */ --> Modèles-pères, et préambule : … si vous savez à peu près où vous avez l’intention de placer les ailes du bâtiment, LES AILES DE LUMIÈRE, et combien d’étages elles auront, le NOMBRE D’ÉTAGES, et où L’ENTRÉE PRINCIPALE se trouve, alors il est temps de travailler sur la disposition approximative des zones principales de chaque niveau. Dans tout bâtiment, la relation entre les zones publiques et les zones privées est de la plus haute importance.

Énoncé du problème : à moins que les volumes d’un édifice ne soient disposés dans un ordre correspondant à leur degré d’intimité, les visites des étrangers, amis, invités, clients, famille seront toujours un peu gênantes.

Explication : je ne vais pas tout citer. Prenez, par exemple, un appartement où la seule façon d’atteindre la salle de bain est de passer d’abord par la chambre à coucher. Les visites sont toujours gênantes car vous avez l’impression de devoir d’abord ranger votre chambre si vous voulez que vos visiteurs puissent utiliser les toilettes. Ou bien considérez des bureaux dans lesquels vous ne voulez pas qu’un espace de travail calme soit à côté de la réception, car alors celui-ci ne sera pas calme du tout — vous voulez qu’il soit plus privé, à l’arrière.

Résumé de la solution : disposez les espaces de l’édifice de façon à ce qu’ils créent une suite qui commence avec l’entrée et la partie du bâtiment ouverte au public, puis conduit aux zones un peu plus privées pour finir avec les domaines les plus intimes.

Modèles-fils à consulter : ZONES COMMUNES AU CENTRE. HALL D’ENTRÉE pour les maisons ; UNE PIÈCE PROPRE À CHACUN pour les particuliers. UNE RÉCEPTION VOUS SOUHAITE LA BIENVENUE dans les bureaux avec, BUREAU SEMI-PRIVÉ à l’arrière.

Les modèles deviennent plutôt précis, ils n’imposent cependant jamais un style ou une forme déterminée au résultat. Par exemple, il existe un modèle qui s’appelle « ÉTAGÈRES OUVERTES ». Des placards profonds vous incitent à mettre les choses les unes derrière les autres, ainsi, vous ne pouvez plus voir ni attraper les objets qui sont au fond. Ils prennent aussi beaucoup de place. Les étagères dont la profondeur permet de ne mettre qu’un seul objet restent rangées et vous savez toujours, en un seul coup d’œil, où se trouve chaque chose. Les objets que vous utilisez fréquemment ne devraient pas être derrière une porte.

Vous pouvez ainsi entrevoir l’essence même des modèles de conceptions : de bonnes recettes éprouvées qui n’imposent pas de contraintes inutiles à votre implémentation

Les modèles ne demandent pas un style particulier ou des décorations superflues : le livre ne vous dit pas : « appliquez ces motifs floraux sur les rampes », mais plutôt : « les pièces d’une maison devraient être orientées de telle sorte que le soleil les éclaire harmonieusement, au moment de la journée où elles sont le plus utilisées — à l’est pour les chambres le matin, à l’ouest pour le salon l’après-midi ».

J’avais acquis un exemplaire de A Pattern Language peu avant de commencer à agrandir notre maison. Le livre fut une révélation : c’était le moyen d’aborder la conception de notre maison et nous pouvions alors la réaliser par nous-mêmes au lieu de payer très cher une solution inadaptée. Nous étions capables de faire un plan sommaire de notre maison et ensuite d’imaginer des détails plus fins au fur et à mesure de la construction. C’est le genre de livres qui, pendant que vous le lisez, parvient à confirmer les intuitions que vous éprouviez confusément — le genre de livres qui vous fait dire en permanence : « Bien sûr, c’est exactement à ça que je pensais  »

Design Patterns, le fameux livre publié par Gamma et autres, puise directement son inspiration dans les schémas architecturaux d’Alexander. Ils voulaient faire la même chose : dresser une liste de problèmes apparaissant fréquemment lorsque l’on programme et présenter de bonnes solutions qui n’imposeront pas de contraintes inutiles à votre implémentation.

Une chose dont j’ai pris conscience en lisant A Pattern Language, c’est une chose importante que l’on retrouve à la fois dans les modèles architecturaux et logiciels) : ils nous fournissent un vocabulaire pour discuter de la façon dont les objets sont construits. Il est beaucoup plus pratique de dire : « Les propriétés de cet objet ont des observateurs » plutôt que : « il est possible de lui attribuer des fonctions de rappel qui sont appelées lorsque ses propriétés changent ». Ce que je pensais être uniquement des termes pompeux ne sont, en fait, qu’une manière d’exprimer la connaissance de manière compacte.

La Qualité Sans Nom

La plus grande partie de l’explication d’Alexander sur les modèles de conception et leur philosophie se rapporte à quelque chose qu’il appelle « La qualité sans nom ». Vous connaissez des endroits qui ont cette qualité sans nom. Elle est présente dans le café où vous aimez aller lire car la lumière de l’après-midi entre avec exactement la bonne intensité. Et il y a là-bas des chaises et des tables, c’est toujours plus ou moins rempli de gens sans pour autant que vous vous sentiez oppressé. Elle est présente au coin d’un parc où un arbre ombrage un banc. Il y a peut-être un peu d’eau vive, et il importe peu qu’il pleuve ou bien que le temps soit ensoleillé, cela semble toujours être un plaisir d’y être. Pensez à une maison de hobbit où tout est à portée de main, où tout est confortable et où tout est fait élégamment.

Un objet ou un endroit possède la qualité sans nom s’il est convivial, s’il a évolué dans le temps selon sa logique propre, s’il ne recèle pas de contradiction interne, n’essaie pas d’attirer l’attention et semble réunir toutes les qualités archétypales — comme s’il avait suivi tout naturellement la voie optimale pour aboutir à sa conception. Plus important, Alexander affirme que c’est une qualité objective et non subjective, et qu’elle peut être mesurée et comparée. Bien que cela semble être une définition floue, c’est l’état le plus abouti dans lequel Alexander a pu l’amener lors de la première phase de son travail. La vraie révélation n’apparaitrait que plus tard.

En tant que développeurs, nous avons tous vu de beaux programmes à un moment donné. Ce sont peut-être les exemples de Programming Pearls, un beau livre que tout hacker devrait lire. Peut-être avez-vous vu un algorithme bien implémenté qui regorge de justesse. Vous vous souvenez peut-être d’un morceau de code très compact, très lisible, très fonctionnel et très correct. Ce logiciel possède la qualité sans nom. Il était devenu évident pour moi que je devais apprendre à écrire des logiciels qui atteignent le niveau de la qualité sans nom et que la méthode d’Alexander était le bon point de départ pour y parvenir.

(à suivre…)

(1) Refactorisation : bien que critiqué, cet anglicisme (voir http://fr.wikipedia.org/wiki/Refactorisation) semble d’un emploi courant chez les développeurs. On pourrait parler plus simplement de remaniement

Antirez est un développeur de logiciel libre… ou plutôt open source, car c’est l’expression qu’il semble privilégier.

Il nous livre ici le fruit de sa petit réflexion.

Ainsi il préfère les licences permissives à celles copyleft. Ce qui ne l’empêche pas de souhaiter voir plus de rétribution dans le domaine, parce que si l’on est obligé de payer sa facture autrement alors il y aura moins de code utile à disposition de tous.

Quelques réflexions sur le logiciel open source

A few thoughts about Open Source Software

Antirez – janvier 2013 – Blog personnel
(Traduction : FanGio, peupleLà, ehsavoie, Tibo, Sphinx, Penguin + anonymes)

Voilà plus de quinze ans que je contribue régulièrement à l‘open source, et cependant je m’arrête assez rarement pour réfléchir à ce que cela représente pour moi. C’est probablement parce que j’aime écrire du code et que c’est ainsi que je passe mon temps : écrire du code plutôt que réfléchir à ce que cela signifie… Cependant ces derniers temps, je commence à avoir des idées récurrentes sur l‘open source, ses relations avec l’industrie informatique et mon interprétation de ce qu’est le logiciel open source pour moi, en tant que développeur.

Tout d’abord, l‘open source n’est pas pour moi une manière de contribuer au mouvement du logiciel libre, mais de contribuer à l’humanité. Cela veut dire beaucoup de choses, par exemple peu m’importe ce que les autres font avec mon code ou qu’ils ne reversent pas leurs modifications. Je veux tout simplement que des personnes utilisent mon code d’une manière ou d’une autre.

En particulier, je veux que les gens s’amusent, apprennent de nouvelles chose et se « fassent de l’argent » avec mon code. Pour moi, que d’autres se fassent de l’argent avec le code que j’ai écrit n’est pas une perte mais un gain.

1. J’ai beaucoup plus d’impact sur le monde si quelqu’un peut payer ses factures en utilisant mon code ;
2. Si N personnes gagnent de l’argent avec mon code, peut-être qu’elles seront heureuses de m’en faire profiter ou plus disposées à m’engager ;
3. Je peux être moi-même l’une de ces personnes qui gagnent de l’argent avec mon code, et avec celui d’autres logiciels open source.

Pour toutes ces raisons, mon choix se porte sur la licence BSD qui est en ces termes l’incarnation parfaite de la licence « faites ce que vous voulez ».

Cependant, il est clair que tout le monde ne pense pas de même, et nombreux sont les développeurs contribuant à l‘open source qui n’aiment pas l’idée que d’autres puissent prendre le code source et créer une entreprise qui ferait un logiciel commercial sous une autre licence.

Pour moi, les règles que vous devez suivre pour utiliser une licence GPL représentent une barrière qui réduit la liberté de ce que les personnes peuvent faire avec le code source. De plus, j’ai le sentiment qu’obtenir des contributions n’est pas tellement lié à la licence : si quelque chose est utile, des personnes vont contribuer en retour d’une manière ou d’une autre, car maintenir un fork n’est pas simple. La véritable valeur se trouve là où le développement se produit. Du code non corrigé, qui n’évolue pas, ne vaut rien. Si, en tant que développeur open source, vous pouvez apporter de la valeur, des parties tierces seront encouragées à faire intégrer leurs modifications.

Cependant, je suis beaucoup plus heureux quand il y a moins de correctifs à fusionner et plus de liberté du point de vue des utilisateurs, plutôt que l’inverse, il n’y a donc pas grand chose à discuter pour moi.

De mon point de vue, ce que l‘open source ne reçoit pas suffisamment en retour, ce ne sont pas les correctifs mais plutôt l’argent. Le nouveau mouvement des startups, et les faibles coûts opérationnels de nombreuses entreprises IT viennent de l’existence même de tout ce code open source qui fonctionne bien. Les entreprises devraient essayer de partager une petite partie de l’argent qu’elles gagnent avec les personnes qui écrivent les logiciels open source qui sont un facteur clé de leur réussite, et je pense qu’une manière saine de redistribuer cet argent est d’embaucher ces développeurs pour qu’ils écrivent du logiciel open source (comme VMware l’a fait pour moi), ou de faire des dons.

Beaucoup de développeurs travaillent pendant leur temps libre par passion, seul un petit pourcentage parvient à être payé pour leur contribution à l‘open source. Une éventuelle redistribution peut permettre à plus de gens de se concentrer sur le code qu’ils écrivent par passion et qui a peut être « un impact plus important » sur l’économie que le travail qu’ils font pour obtenir leur salaire chaque mois. Et malheureusement, il est impossible de payer les factures avec des PULL REQUESTS, c’est pourquoi je pense qu’apporter de l’aide à un projet sous forme de code est une bonne chose, mais ce n’est pas suffisant.

Vous pouvez avoir un point de vue différent sur tout cela, mais ce que j’observe, c’est que le logiciel open source produit beaucoup de valeur dans l’industrie informatique actuelle, et qu’il est souvent écrit sur son temps libre ou en jonglant entre les différentes tâches pendant son temps de travail, si votre employeur est assez souple pour vous permettre de le faire.

Ce que je pense, c’est que cela est économiquement sous-optimal, beaucoup de codeurs intelligents pourraient donner une impulsion à l’économie s’ils étaient plus libres d’écrire du code qu’ils aiment et que beaucoup de gens utilisent sans doute déjà pour faire de l’argent.

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

Traduction Framalang : lamessen, Sky, Kalupa, ga3lig, Wxcafe, goofy, Astalaseven, Slystone, okram, KoS, Lycoris, peupleLa, Julius22

La Voie des tests conduit à la Lumière

Jonathan “Duke” Leto

Jonathan Leto, dit « Le Duc » est un développeur de logiciel, un mathématicien dont les travaux sont publiés, un ninja de Git et un passionné de cyclisme qui vit à Portland, en Oregon. C’est l’un des développeurs principaux de la machine virtuelle Parrot et le fondateur de Leto Labs LLC.

Lorsque j’ai commencé à m’impliquer dans le logiciel libre et open source, je n’avais aucune idée de ce que pouvaient être les tests ni de leur importance. J’avais travaillé sur des projets personnels de programmation auparavant, mais la première fois que j’ai réellement travaillé sur un projet collaboratif (c’est-à-dire en faisant un peu de commit) c’était pour Yacas, acronyme de Yet Another Computer Algebra System, (NdT : encore un autre logiciel de calcul algébrique similaire à Mathematica).

À ce stade de mon parcours, les tests ne venaient qu’après coup. Mon méta-algorithme général était : bidouiller du code > voir si ça fonctionne> écrire (éventuellement) un test simple pour démontrer que ça fonctionne. Un test difficile à écrire n’était généralement jamais écrit.

C’est le premier pas sur la voie qui mène à la Lumière grâce aux tests. Vous savez que les tests sont probablement une bonne idée, mais vous n’en avez pas vu clairement les bénéfices, alors vous vous contentez de les écrire de temps en temps.

Si je pouvais ouvrir un trou de souris dans l’espace-temps et donner à mon moi plus jeune un conseil plein de sagesse sur les tests, ce serait :

« Certains tests sont plus importants, sur le long terme, que le code qu’ils testent. »

Il y a sans doute quelques personnes qui pensent en ce moment même que je mets mon casque de protection psychique (NdT : il s’agit d’un chapeau pour se protéger contre la manipulation à distance du cerveau) quand je m’assois pour écrire du code. Comment les tests pourraient-ils être plus importants que le code qu’ils testent ? Les tests sont la preuve que votre code marche réellement ; ils vous montrent le chemin vers l’écriture d’un code propre et vous apportent aussi la souplesse qui vous permettra de modifier le code tout en sachant que les fonctionnalités seront toujours là. En effet, plus votre code source grossit, plus vos tests sont importants, car ils vous permettent de changer une partie dudit code en sachant que le reste fonctionnera.

Une autre raison essentielle qui justifie l’écriture de tests est la possibilité de spécifier que quelque chose est un souhait explicite et non une conséquence imprévue ou un oubli. Si vous avez un cahier des charges, vous pouvez utiliser des tests pour vérifier qu’il est respecté, ce qui est très important, voire indispensable dans certaines industries. Un test, c’est comme quand on raconte une histoire : l’histoire de votre conception du code et de la façon dont il devrait fonctionner. Soit le code change et évolue, soit il mute en code infectieux (1).

Très souvent, vous écrirez des tests une première fois pour ensuite remettre totalement en cause votre réalisation voire la réécrire à partir de zéro. Les tests survivent souvent au code pour lesquels ils ont été conçus à l’origine. Par exemple, un jeu de tests peut être utilisé quel que soit le nombre de fois où votre code est transformé. Les tests sont en fait l’examen de passage qui vous permettra de jeter une ancienne réalisation et de dire « cette nouvelle version a une bien meilleure structure et passe notre jeu de tests ». J’ai vu cela se produire bien des fois dans les communautés Perl et Parrot, où vous pouvez souvent me voir traîner. Les tests vous permettent de changer les choses rapidement et de savoir si quelque chose est cassé. Ils sont comme des propulseurs pour les développeurs.

Les charpentiers ont un adage qui dit quelque chose comme ça :

« Mesurer deux fois, couper une fois. »

Le code serait la coupe, le test serait la mesure.

La méthode de développement basée sur les tests fait économiser beaucoup de temps, parce qu’au lieu de vous prendre la tête à bricoler le code sans but défini, les tests précisent votre objectif.

Les tests sont aussi un très bon retour d’expérience. Chaque fois que vous faites une nouvelle passe de test, vous savez que votre code s’améliore et qu’il a une fonctionnalité de plus ou un bogue de moins.

Il est facile de se dire « je veux ajouter 50 fonctionnalités » et de passer toute la journée à bricoler le code tout en jonglant en permanence entre différents travaux. La plupart du temps, peu de choses aboutiront. La méthode de développement basée sur les tests aide à se concentrer sur la réussite d’un seul test à la fois.

Si votre code échoue devant ne serait-ce qu’un seul test, vous avez pour mission de le faire réussir. Votre cerveau se concentre alors sur quelque chose de très spécifique, et dans la plupart des cas cela produit de meilleurs résultats que passer constamment d’une tâche à une autre.

La plupart des informations relatives au développement basé sur les tests sont très spécifiques à un langage ou à une situation, mais ce n’est pas une obligation. Voilà comment aborder l’ajout d’une nouvelle fonctionnalité ou la correction d’un bogue dans n’importe quel langage :

1. Écrivez un test qui fait échouer votre code, mais qui, selon vous, sera passé quand la fonctionnalité sera implémentée ou que le bogue sera corrigé. Mode expert : pendant l’écriture du test, pensez à l’exécuter de temps en temps, même s’il n’est pas encore fini, et tentez de deviner le message d’erreur effectif que le test renverra. À force d’écrire des tests et de les faire tourner, cela devient plus facile ;
2. Bidouillez le code ;
3. Exécutez le test. S’il marche, passez au point 4, sinon retournez au point 2 ;
4. C’est fini ! Dansez le sirtaki.

Cette méthode fonctionne pour n’importe quel type de test et n’importe quel langage. Si vous ne deviez retenir qu’une seule chose de ce texte, souvenez-vous des étapes ci-dessus.

Voici maintenant quelques directives plus générales de conduite de tests qui vous serviront bien et fonctionneront dans n’importe quelle situation :

1. Comprendre la différence entre ce qu’on teste et ce qu’on utilise comme un outil pour tester autre chose ;
2. Les tests sont fragiles. Vous pouvez toujours écrire un test qui contrôle la validité d’un message d’erreur. Mais que se passera-t-il si le message d’erreur change ? Que se passera-t-il quand quelqu’un traduira votre code en catalan ? Que se passera-t-il lorsque quelqu’un exécutera votre code sur un système d’exploitation dont vous n’avez jamais entendu parler ? Plus votre test est résistant, plus il aura de valeur.

Pensez à cela quand vous écrivez des tests. Vous voulez qu’ils soient résistants, c’est-à-dire que les tests, dans la plupart des cas, ne devraient avoir à changer que quand les fonctionnalités changent. Si vous devez modifier vos tests régulièrement, sans que les fonctionnalités aient changé, c’est que vous faites une erreur quelque part.

Types de tests

Bien des personnes sont perdues quand on leur parle de tests d’intégration, tests unitaires, tests d’acceptation et autres tests à toutes les sauces. Il ne faut pas trop se soucier de ces termes. Plus vous écrirez de tests, mieux vous en distinguerez les nuances et les différences entre les tests deviendront plus apparentes. Tout le monde n’a pas la même définition de ce que sont les tests, mais c’est utile d’avoir des termes pour décrire les types de tests.

Tests unitaires contre tests d’intégration

Les tests unitaires et les tests d’intégration couvrent un large spectre. Les tests unitaires testent de petits segments de code et les tests d’intégration vérifient comment ces segments se combinent. Il revient à l’auteur du test de décider ce que comprend une unité, mais c’est le plus souvent au niveau d’une fonction ou d’une méthode, même si certains langages appellent ces choses différemment.

Pour rendre cela un peu plus concret, nous établirons une analogie sommaire en utilisant des fonctions. Imaginez que f(x) et g(x) soient deux fonctions qui représentent deux unités de code. Pour l’aspect concret, supposons qu’elles représentent deux fonctions spécifiques du code de base de votre projet libre et open source.

Un test d’intégration affirme quelque chose comme la composition de la fonction, par exemple f(g(a)) = b. Un test d’intégration consiste à tester la façon dont plusieurs choses s’intègrent ou travaillent ensemble, plutôt que la façon dont chaque partie fonctionne individuellement. Si l’algèbre n’est pas votre truc, une autre façon de comprendre est de considérer que les tests unitaires ne testent qu’une partie de la machine à la fois, tandis que les tests d’intégration s’assurent que la plupart des parties fonctionnent à l’unisson. Un bel exemple de test d’intégration est le test de conduite d’une voiture. Vous ne vérifiez pas la pression atmosphérique, ni ne mesurez le voltage des bougies d’allumage. Vous vous assurez que le véhicule fonctionne globalement.

La plupart du temps, il est préférable d’avoir les deux. Je commence souvent avec les tests unitaires puis j’ajoute les tests d’intégration au besoin puisqu’on a besoin d’éliminer d’abord les bogues les plus basiques, puis de trouver les bogues plus subtils issus d’un emboitement imparfait des morceaux, à l’opposé de pièces qui ne fonctionnent pas individuellement. Beaucoup de gens écrivent d’abord des tests d’intégration puis se plongent dans les tests unitaires. Le plus important n’est pas de savoir lequel vous écrirez en premier, mais d’écrire les deux types de tests.

Vers la Lumière

La méthode de développement basée sur les tests est un chemin, pas un aboutissement. Sachez apprécier le voyage et assurez-vous de faire une pause pour respirer les fleurs si vous êtes égaré. 

(1) Équivalent approché du terme bitrot qui en argot de codeur désigne ce fait quasi-universel : si un bout de code ne change pas mais que tout repose sur lui, il « pourrit ». Il y a alors habituellement très peu de chances pour qu’il fonctionne tant qu’aucune modification ne sera apportée pour l’adapter à de nouveaux logiciels ou nouveaux matériels.

Comic strip réalisé avec le Face-O-Matic de Nina Paley et Margot Burns

Copyheart ? 2011 by Margo Burns and Nina Paley. Copying is an act of love. Please copy!