Note de lecture : A Little Riak Book 2.0, par Eric Redmond & John Daily

Note : 2 ; Un livre à décoder plutôt qu’à lire !

Edité à compte d’auteur par un (gros) contributeur Riak, ce livre est assurément petit car il dépasse à peine la centaine de pages. Il n’a pas non plus d’ISBN ce qui est hélas un premier indice sur sa qualité éditoriale. Autant le dire tout de suite : elle est médiocre.

Je m’attendais à un petit tutorial pour mettre le pied à l’étrier. Si c’est effectivement la cible de ce texte, l’objectif est quand à lui bien raté. La prose fait de nombreux raccourcis qui nous font rater une bonne compréhension. Ainsi l’articulation entre bucket et bucket-type reste-t-elle nébuleuse. L’auteur semble parler de clés hiérarchiques mais … finalement non. Quand aux « rings » on en est encore à se demander comment cela fonctionne. L’ouvrage n’est pas dénué d’illustration ou d’extraits de code ou de configuration, mais c’est plutôt du matériel brut ne soulignant pas ce qu’il y a à voir. Bref : encore raté.

Le chapitre 1 est une courte introduction. Il liste les fonctionnalité de Riak 1 et met en évidence les nouveautés de Riak 2 avec des concepts qui ne sont pas expliqués, donc incompréhensibles. On est bien avancés. Le chapitre 2 aborde les concepts : ce devrait être le chapitre le plus intéressant. Mais là aussi les auteurs parviennent à introduire de la confusion. Il reste toutefois le chapitre le plus instructif.

Lire la suite

Publicités

A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.

Lao Tseu

Lao Tseu

Note de lecture : Designing for Growth, par Jeanne Liedtka & Tim Ogilvie

Note 6 ; Bon sur le framework et le mindset design thinking. Mais le propos se perd parfois un peu en route.

Il y a finalement assez peu de littérature sur le Design Thinking. J’ai profité du MOOC avec le Pr Liedtka pour me plonger parallèlement dans cette lecture. C’est un beau livre, à l’impression bi chromique et comptant environ 200 pages auxquelles il faut ajouter les annexes. Découpé en 5 sections, il suit la logique des 4 questions qui structurent l’approche des auteurs..

Le texte s’ouvre sur une partie introductive de 2 chapitres totalisant 40 pages. Les 20 pages du premier chapitre tentent de répondre à la question « pourquoi le design ». Ce sont avec des histoires et des témoignages que des réponses sont apportées. C’est bien vu, même si cela n’apporte qu’une réponse partielle à la question. Le second chapitre de cette introduction est la « big picture » du framework : 4 questions et 10 outils. Aussi émaillé de témoignages, même s’ils sont moins percutants, le chapitre permet de s’approprier la logique de la démarche, mais pas l’essence.

La seconde partie du livre est consacré à la première question : « what is ? » sur 55 pages et 4 chapitres. Cette partie s’ouvre sur un chapitre consacré à la visualisation. Il manque cruellement de contenu concret, on reste dans la déclaration d’intention et les bénéfices attendu. Difficile d’y décerner une matière concrète avec laquelle rentrer chez soi ! Le chapitre 4 est tout l’inverse : s’il est succinct, il décrit parfaitement l’approche et le tout est brillamment illustré. Le value chain analysis est expédié à toute vitesse et c’est le « mind mapping » qui conclut cette partie. Ce mind-mapping n’est pas à confondre avec les cartes heuristiques. Il s’agirait plutôt de safaris pour partager et brain-stormer.

Lire la suite

Note de lecture : Kotlin in Action, par Dmitry Jemerov & Svetlana Isakova

Note : 5 ; Fait le boulot.

Kotlin est un langage de la JVM que je classe dans la catégorie des « better Java », aux côtés de Ceylon (qui hélas n’a pas encore d’ouvrage). Le parti-pris du langage est celui d’une très bonne intégration avec Java (le langage), la manière dont chaque concept se traduit et peut être utilisé de ce côté est un fil rouge du livre. Ce n’est pas celui qui m’intéresse le plus, mais c’est une fonctionnalité forte (et limitante) du langage, donc… L’autre parti-pris est de s’adosser à une version déjà ancienne de la JVM : Java 6, mais ce dernier point n’a pas d’influence sur le texte.

Il y a fort peu à dire de ce texte, ni en bien ni en mal. Il est plutôt sans surprise. Le texte est raisonnablement clair et les extraits de code font le boulot. D’un autre côté, pas de « waouh effect ». Avec 310 pages sur 11 chapitres regroupés en deux parties, on reste également dans le standard, bien que dans la partie haute.

La première partie « introducing Kotlin » compte 6 chapitres et couvre 170 pages. Le premier d’entre-eux se contente d’une quinzaine d’entre-elles. Il a pour but de faire le tour des caractéristiques principales du langage et de son positionnement. C’est bien écrit, mais on n’est en réalité pas tellement avancé. Par contraste, le chapitre 2 « Kotlin basics » et ses un peu plus de 25 pages font un bon boulot pour couvrir les bases du langage : déclaration de classes et de méthodes, les propriétés (et leurs petites particularités) ainsi que des structures de contrôle : boucles, switches, énumérations, etc. On couvre bien les base et c’est bien écrit.

Lire la suite

Note de lecture : Agile Testing, par Lisa Crispin & Janet Gregory

Note : 3 ; Un complément indispensable aux projets agiles, mais bien lourd à digérer !

Les ouvrages traitant des projets en mode agile évoquent le plus souvent les tests d’acceptation d’une manière un peu globale en évoquant d’une part qu’il faut les faire et d’autre part qu’il est pertinent de commencer par les écrire afin de travailler en mode « ATDD ». C’est bien mais un peu succinct.

Ce livre prend une toute autre optique : prenez un testeur, un vrai, avec beaucoup d’expérience dans des contextes classiques. Plongez-le (ou « la » en l’occurrence ici, ici) au sein d’une équipe agile, avec pour mission d’adapter ses pratiques à l’esprit et à la façon de travailler de cette équipe. Tirer de ce travail de nouvelles pratiques et de nouveaux savoir-faire est l’objet de cet ouvrage !

Si l’idée est bonne, avec un texte ciblé vers le testeur, j’y trouve beaucoup de redondances avec ce que l’on connaît ou est déjà écrit ailleurs dans la littérature agile. Toute la première partie est consacrée à ces généralités. Bref, mauvaise pioche pour les 35 premières pages.

Lire la suite