Technique

L’exergue du livre donne le ton. We build our computer systems the way we build our cities: over time, without a plan, on top of ruins. Au début j’étais dubitatif en lisant le résumé sur l’histoire d’UNIX/Linux et sur celle des langages de programmation, mais c’était une façon d’introduire des concepts. Ensuite, le livre prend de l’ampleur. Marianne Bellotti nous fait partager son expérience concernant la modernisation des systèmes, elle a beaucoup travaillé sur ces applications que l’on nomme legacy – une appellation à double sens. Elle parait énoncer pas mal de généralités qui sont du bon sens, mais elle a raison, parfois le bon sens ne s’applique pas à l’informatique. ...

Ce livre est l’un des livres mythiques sur UNIX et le mouvement open source écrit par un de ses plus fervents défenseurs Eric S. Raymond. Dans le titre du livre figure le mot art et c’est bien sous cet angle ou plutôt sous celui de la philosophie que Raymond articule son ouvrage. Il propose de tirer la quintessence de ce qui a fait le succès d’UNIX, et de ses successeurs comme Linux, pour en extraire des règles, des principes et des bonnes pratiques qui seraient généralisables. Certains sont désormais très connus comme “Premature optimization is the root of all evil” ou le principe KISS, certains le sont un peu moins comme les principes de compacité et d’orthogonalité. Pour les illustrer, il s’appuie sur les implémentions d’UNIX et sur celles d’autres outils open source. ...

J’ai un avis mitigé sur ce livre. A la fois il est essentiel car il met l’accent sur des points fondamentaux de la gestion d’équipe – je vais y revenir – et à la fois il se révèle extrêmement resserré et pourrait presque se résumer à quelques pages. Ce dernier point est particulièrement vrai pour le dernier chapitre consacré à la reproduction et au commentaire de courts articles d’autres contributeurs – si ce n’est pas une façon de remplir des pages et de vendre du papier qui n’apporte pas grand chose mis à part la désagréable impression de s’être fait berner. Ceci étant dit, venons-en aux parties les plus intéressantes. ...

Il s’agit du livre de référence dans le domaine, celui qui a lancé et donné son nom – enfin je crois – à la discipline visant à mettre le software engineering au service de la production ou des opérations. Avant cela, il y avait les développeurs en charge de concevoir les applications et ceux que l’on appelait les administrateurs s’occupaient de les déployer et de les superviser en production. Le problème avec ce modèle est que les uns ne connaissent rien – ou presque – au travail des autres et le résultat était au mieux chaotique et au pire donnait lieu à des querelles assez animées qui se transformaient vite en guerre de tranchées. Ça semble aberrant, mais c’était le modèle et c’est cette fracture que la mouvance DevOps s’est efforcée de résorber. Difficile de différencier clairement les deux mouvances, mais je dirais – ce n’est que mon point de vue – que le DevOps peut être atteint en constituant des équipes mixtes (développeurs + administrateurs) alors que les SRE possèdent des compétences mixtes (développement et administration), et mettent l’une au service de l’autre, l’Infrastructure as Code en est le parfait exemple. ...

Il s’agit tout simplement d’un recueil d’articles du blog Joel on Software venant compléter ceux qui avaient été sélectionnés pour constituer le premier recueil au titre éponyme Joel on Software. On pourrait donc légitiment se dire que l’on y trouvera pas le meilleur, que ce sera du réchauffé – un peu comme la suite, souvent peu inspirée d’un film à succès – et d’un côté c’est vrai, il y a indéniablement de ça. Mais en même temps lorsque l’on a beaucoup apprécié le premier – et c’est mon cas – on est bien content d’avoir du rab qu’il soit réchauffé ou pas. On pourrait aussi se dire tout aussi légitimement qu’il s’agit de vielles histoires – de dinosaures – du temps des grands débuts tonitruants d’Internet, c’est vrai aussi, mais certaines n’en restent pas moins édifiantes, le recul ne les rendant que plus vraies. ...

Ce livre est écrit par un coach agile – n’arrêtez pas la lecture de cet article tout de suite, attendez de lire la suite. Il s’agit d’un ponte dans le domaine Henrick Kniberg. Comme l’indique la mention du titre From the Trenches il n’est pas question de nous abreuver de théories – et de techniques de collage de Post-It, oui ça existe – mais de nous faire vivre de l’intérieur l’organisation et la méthodologie mises en oeuvre dans le cadre d’un gros projet mené, pendant 3 ans, par la police suédoise afin de se doter d’un puissant logiciel qui devrait – on ne sait jamais avec l’informatique – leur permettre d’améliorer le coeur de leur activité – la rédaction des procès verbaux. Le sujet ne fait pas vraiment rêver, mais bon, j’adore ces histoires industrielles, je trouve qu’elles sont toujours riches d’enseignements. Pour les amateurs, je pense à ...

Comme l’indique le sous-titre A History and a Memoir il s’agit pour Brian Kernighan – le K du célèbre K&R – de rédiger un livre de souvenirs qui tient lieu à la fois d’histoire d’Unix – ou UNIX. C’est aussi à l’inverse un livre sur l’histoire d’Unix qui contient des anecdotes sur cette aventure et sur sa matrice, le Bell Labs et son fameux département 1127. Kernighan insiste d’ailleurs beaucoup tout au long du livre sur l’importance de cette structure et des personnes qui y ont été rassemblées. C’est-à-dire sur l’aspect organisationnel et collaboratif. Les membres de ce département formaient ce qui est appelé une jelled team dans le livre Peopleware et Brian Kernighan semble être du même avis que les auteurs de ce livre pour dire que ces liens ne se nouent pas de façon artificielle. ...

Le jeu de mots qui compose le titre Peopleware livre la clé de cet essai. Le software (de la conception à la mise en production de logiciels) est avant tout une affaire de personnes. Les auteurs nous apprennent dès le début du livre que parmi toutes les observations qu’ils ont menées au cours de leur carrière, les échecs des projets ne sont jamais imputables – au moins en totalité – à des problèmes techniques. Il faut donc chercher les raisons des succès et des échecs ailleurs, c’est-à-dire dans les facteurs humains puisque l’on a affaire à des travailleurs intellectuels – on ne fait pas des cheeseburgers, c’est le titre d’un chapitre. Ces conseils tournent beaucoup autour du fait de mettre les développeurs au centre du dispositif car ils ont besoin des meilleures conditions pour effectuer le meilleur travail. Et c’est un vaste champ qui s’ouvre ici puisqu’il englobe entre autres: l’organisation, les conditions de travail, le bien être au travail, la créativité, la motivation, la qualité de ce qu’ils produisent qui valorise plus que tout autre chose le travail effectué. ...

S’il n’y avait qu’un livre sur le DevOps à lire – et il faut en effet n’en lire qu’un seul, la vie est trop courte – ce serait celui-là. Enfin non ce n’est pas vrai, je dis déjà des bêtises, si on a un peu de temps et que l’on travaille dans ce domaine, il faut aussi lire Site Reliability Engineering1. Ce Devops Handbook n’est pas passionnant à lire – on ne peut pas dire que ce soit la grosse poilade –, mais ce n’est pas ce que l’on attend d’un tel livre. Si on cherche une introduction plus divertissante sur ce sujet, il faut lire son pendant en roman. Ecrit par les mêmes auteurs, il a précédé la parution de cet opus technique et a connu un succès retentissant, le désormais célèbre: The Phoenix Project2. ...

Ce livre est écrit par l’auteur du best seller qui caracole depuis 20 ans désormais – une édition anniversaire vient de sortir – en tête de toutes les listes de livres d’informatique: The Pragmatic Programmer. Il a depuis créé sa propre maison d’édition dont le nom reprend le titre de son livre: The Pragmatic Bookshelf. Pragmatic Thinking and Learning n’est pas un livre d’informatique, mais un hybride entre un livre d’informatique et un livre de développement personnel – genre que l’on nomme parfois aussi soft skills. Ce n’est donc pas un livre conventionnel et pourtant il vaut le détour car il est bourré de retour d’expériences et de réflexions intéressantes. Tout ce qui concerne le fonctionnement du cerveau est particulièrement édifiant et étayé. Les analogies entre le cerveau et l’ordinateur fonctionnent parfaitement par exemple lorsque Andrew Hunt explique que le cerveau enregistre tout, mais n’indexe que ce qui est digne d’intérêt. J’ai été particulièrement sensible à la différence entre le L mode et le R mode. Je me sers souvent du R mode, je mets en pause un sujet si je sens que je n’ai pas la solution immédiatement et que je n’ai pas l’espoir d’aboutir rapidement en y réfléchissant de façon active. Le modèle de Dreyfus est une belle référence à avoir dans son escarcelle. Il théorise une chose qui semble évidente, mais qui n’est pas souvent appliquée, qui est de ne pas interagir avec tous les membres d’une équipe de la même façon. Un expert n’a pas besoin qu’on le marque à la culotte, il faut lui laisser suffisamment de liberté pour qu’il puisse s’exprimer, être efficace et donner tout son potentiel. Enfin, comme beaucoup de livres techniques écrits par des auteurs américains , il est bourré d’humour et très agréable à lire. ...

J’ai connu ce livre en lisant l’article Top 5 Contemporary Software Engineering Books consacré aux nouveaux classiques dans le domaine du software engineering. Il tentait d’identifier parmi les publications récentes celles qui remplaceraient peut-être les Refactoring: Improving the Design of Existing Code et autres Design Patterns: Elements of Reusable Object-Oriented Software – le conditionnel est ici plus que jamais de rigueur. Je n’avais jamais entendu parler de ce livre ni de son auteur John Ousterhout professeur à Standford. Contrairement à ce que le titre pourrait laisser penser, il n’est pas question ici de design ou d’architecture, mais plutôt de codage. En ce sens il se rapproche de ses ancêtres Clean code et Code Complete comme le laissait entendre l’auteur de l’article. ...

Ce livre offre un bon panorama de l’utilisation des statistiques dans un contexte data science, mais il est loin d’être réussi. Tout d’abord je n’ai pas adhéré au plan suivi par l’auteur. Il se prête peut-être à des cours – ce livre est issu des cours dispensés par l’auteur –, mais pas à la lecture. Ensuite il mixe mathématiques et programmation et c’est justement là qu’il pèche. Si les deux disciplines sont intimement liées, il est en effet impensable de faire des statistiques avec un papier et un crayon, mais de là à expliquer comment on a codé ses propres fonctions en Python alors qu’il existe des librairies comme pandas, statsmodel, scipy, seaborn, etc. je ne comprends pas mis à part, encore une fois, pour le côté didactique. Et puis à trop vouloir coder on oublie la méthode en route, le pourquoi. Qu’est-ce qu’il faut faire dans quel ordre, le comment étant quasiment accessoire avec ce qu’y existe aujourd’hui. A mon sens, un bon livre de statistiques moderne devrait se contenter d’expliquer la démarche, le pourquoi utiliser telle ou telle technique, telle ou telle mesure, mais pas comment les mettre en oeuvre. Ça me rappelle un peu les cours où l’on nous demandait de faire des calculs de matrice ou d’intégrale à la main c’est un peu la même démarche que je trouve toujours aussi inutile. ...

The goal est un classique parmi les livres dédiés à l’optimisation de la production industrielle datant de l’époque où les termes gestion de production et recherche opérationnelles étaient encore largement employés, les années 80. Il date d’avant l’avènement du lean popularisé par Toyota. Avant de revenir au fond parlons de la forme car elle reste encore originale plus de 30 ans après. Il s’agit d’un genre particulier portant le doux nom de business novel, c’est à dire d’une oeuvre de fiction traitant d’un sujet technique dans le but d’en illustrer les principes – de les vulgariser diront les aigris. Et il est intéressant de constater que cette forme est plus que jamais d’actualité puisque le best seller du moment dans le domaine de l’IT, The Phoenix Project a adopté exactement la même forme. Je crois d’ailleurs que la filiation entre ces deux oeuvres est pleinement assumée. Dans le premier, le patron d’une usine doit la sauver de la fermeture, dans le second un homme est parachuté à la tête de l’IT et doit sauver son entreprise – rien que ça. J’ai franchi un pas de plus puisque je n’ai pas lu le roman, mais son adaptation en bande dessinée. C’est donc un business graphic novel – ce qui est encore plus rare. ...

Juste une courte note à propos de ce livre que j’ai utilisé dans le cadre de mon travail. Tout d’abord deux points positifs. Le premier est qu’il traite des sujets monitoring, alerting et reporting en général, c’est-à-dire indépendamment de l’outillage utilisé. C’est à la fois un point fort et un point faible puisqu’il pourrait être utile d’identifier des familles d’outils adaptés à chaque usage. Cette volonté de s’écarter des outils est assez rare pour être soulignée. Cette prise de recul permet d’introduire de la structure – je pense par exemple à l’organisation du monitoring en stacks qui est absolument cruciale –, des notions et des définitions générales et applicables en toutes circonstances – ou presque. Et on en vient au deuxième point fort, les définitions donc. Il est essentiel dans le cadre professionnel de s’appuyer sur des définitions précises qui permettent d’encadrer des concepts que la plupart des gens ont une fâcheuse tendance à confondre comme monitoring et alerting par exemple. ...

Si vous cherchez un livre sur l’histoire de Linux et plus généralement sur celle du mouvement open source, vous l’avez trouvé. Glyn Moody nous propose une longue page d’histoire qui part des origines aux années 2000. Tout ou presque est abordé dans ce livre: la technologie, les hommes, la philosophie et l’économie. On verra comment le travail d’un étudiant a fini par être adopté par l’ensemble des fabricants de machines professionnelles et fait aujourd’hui tourner Internet et tous les vendeurs de cloud – même Microsoft vient de sortir son propre Linux (Azure Sphere), c’est dire ! Cette véritable prouesse n’a été rendue possible que par un subtil équilibre entre des bénévoles, des militants et des entreprises. Les bénévoles sont la cheville ouvrière, ils ont toujours contribué avec enthousiasme. Les militants, dont la figure de proue est Richard Stallman, peuvent être considérés comme les gardiens du temple du monde libre. Enfin, les entreprises sont les émanations des intérêts économiques, elles ont irrigué cet écosystème avec de l’argent, mais elles ont aussi contribué d’une autre manière. Elles ont donné la caution, les garanties professionnelles nécessaires à l’adoption de ces logiciels à grande échelle au sein des entreprises. Je pense en particulier à Red Hat, mais aussi à IBM qui a fait le choix courageux d’abandonner certaines lignes de produits comme les serveurs web au profit de leur équivalent open source. En faisant ce choix ils ont envoyé un message fort, mais ont aussi très concrètement contribué à leur développement en investissant des moyens humains importants dans leur développement. Cette politique a donné le jour à un logiciel comme Apache – et à la fondation qui porte son nom – qui est devenu la référence dans le domaine. ...

Ce livre est une bible pour tout professionnel qui souhaite déployer une solution en production – c’est quand même l’objectif normalement, les POC ça va un moment et le titre de ce livre vous y incite fortement. C’est une référence reconnue puisqu’il a contribué à populariser certains patterns comme le circuit breaker et qu’il caracole en tête de toutes les listes de lecture (must read) du domaine. Il est bourré de bons conseils issus d’un énorme retour d’expérience puisque Michael T. Nygard a oeuvré dans le domaine en question, que l’on appelle désormais operations en anglais comme en français, sur des applications critiques – principalement, mais pas que, des gros sites de e-commerce. ...

Ce livre est simple et bien conçu. Il aborde les thèmes essentiels auxquels il est nécessaire de s’intéresser si l’on veut construire, déployer et opérer des applications à grande échelle. Les voici, je n’invente rien, ce sont les cinq sections du livre: Disponibilité: Comment rendre les systèmes hautement disponibles et comment s’assurer qu’ils le sont via la mise en place de mesures. Gestion des risques: Comment construire une analyse de risques et mener des actions de remédiation. Services et microservices: Prendre conscience de l’intérêt (et des travers) de ce découpage, adapter son organisation en fonction. Scaling: Comment découper les services, leur dépendances et savoir comment s’organiser pour les opérer. Cloud: Quels sont les services offerts dans le cloud, comment sont-ils organisés et opérés quels sont les avantages et les inconvénients. Lee Atchinson parvient très bien a offrir un panorama de tous ces sujets. Sans rentrer dans les détails, il donne des points essentiels, des incontournables. Il constitue donc une très bonne entrée en matière pour les néophytes, mais il peut aussi être utilisé comme une référence car il fournit des définitions simples et assez bien faites appelant le consensus. Au delà des définitions je m’en suis servi plusieurs fois comme boîte à outil par exemple pour construire une analyse de risques ou pour établir une cartographie des services avec leurs dépendances et leur criticité (notion de Tiers). Dans le cadre de ces figures imposées, il donne toute l’ossature, il n’y a plus qu’à suivre le guide. ...

Les reproches faits à ce livre sont de deux ordres. Le premier porte sur sa structure – voire son contenu – qui n’est pas conventionnelle pour un livre intitulé Data analysis. C’est vrai que l’on s’attend à suivre une méthodologie, à être guidé et il faut bien reconnaître que ce n’est pas le cas. Si vous cherchez ce type d’ouvrage, je vous conseille de vous plonger dans Practical Data Science with R qui est un excellent ouvrage tout à fait dans ce registre. Cette approche non conventionnelle n’est pas gênante et au contraire car elle aide à ouvrir la réflexion à voir autrement et surtout à réfléchir tout simplement. Il est aussi plus théorique et va au fond de choses – dit autrement il y a des maths, tout ce qui l’avance est démontré et l’auteur s’efforce de faire passer deux messages: ...

C’est le récit d’une aventure, celle de la création d’un logiciel Open Source, le plus génial de tous les temps. Un agenda révolutionnaire qui pourrait tout faire, qui serait l’outil ultime de toute personne bien organisée. Les utilisateurs pourraient partager leurs calendriers, les synchroniser sur différentes machines et tout cela sans serveur, l’indépendance et la flexibilité totale. Et ce n’est pas tout, il permettrait de gérer les e-mails, de les transformer en autre chose (des notes ou des rendez-vous), du polymorphisme à l’état pur. Il serait extensible en permettant d’ajouter des fonctionnalités sous la forme de plugins pour gérer d’autres choses comme des collections par exemple – pourquoi pas en effet. De cette façon, il pourrait répondre aux besoins des utilisateurs privés (calendrier personnel), public (les universités) et professionnels – où il supplanterait allègrement Outlook. Oups, j’oubliais un détail, il devrait fonctionner sur toutes les plate-formes de Windows aux Unix sans oublier Mac OS – et encore les plate-formes mobiles n’existaient pas sinon elles auraient été dans la cible. ...

Comme l’on pourrait s’y attendre en découvrant son titre, ce livre a pour objectif de nous faire découvrir l’utilisation de la technologie Hadoop au travers de cas concrets mis en oeuvre par des applications qui sont en production. C’est une distinction importante car il ne faut pas oublier que ces technologies sont encore très récentes et du prototype à la production il n’y a en effet qu’un pas, mais qui peut parfois être très compliqué à franchir et ceux qui y sont parvenus étaient encore considérés en 2015 comme des pionniers. ...