Les livres en anglais

Rex Black, ancien président de l'ISTQB, nous propose le seul ouvrage dédié à la préparation de la certification ISTQB « CTAL Test Manager ». Au delà, d'une simple préparation à une certification à l'aide de QCM et d'exercices pratique, ce livre est aussi une solide introduction au management des tests dans les projets actuels. Il offre aussi des pistes intéressantes de réflexion et d'amélioration pour les responsable d'activité(s) de test. Les thèmes abordés mettent l'accent sur les problématiques récurrentes rencontrées lorsque l'on doit gérer les tests : estimation des charges, définition de la stratégie, outsourcing, gestion de l'équipe le tout complété par de nombreux retours d'expérience qui font l'intérêt de ce livre.
La section « Standards and Test Process Improvement » offre un tour d'horizon des normes et méthodologies applicables au test logiciel - en complément des CMMI et ITIL - comme TMMI, TMAP, TPI, CTP, STEP. Et là je suis resté sur ma faim, car l'aspect mise en pratique est mis de côté au profit d'une description comparative de ces méthodes, sans parler des normes qui ne sont que citées. Mais ceci est justifié par le respect du niveau de connaissance attendu pour cette certification (voir le syllabus CTAL).
En résumé, ce livre m'a permis de préparer et passer sereinement la certification ISTQB « CTAL Test Manager », car le CTAL, contrairement à la certification ISTQB CTFL, dispose d'un syllabus CTAL plutôt léger pour se préparer seul à l'examen.

Le livre « Test Driven Development By Example » de Kent Beck pose les bases de l'automatisation des tests et donc des méthodes agiles.
Particulièrement simple et didacticiel, le seul faux pas en était de partir exclusivement de nouveaux projets.
Le livre « Working Effectively With Legacy Code » va plus loin, le constat étant : 80% du codage s'effectue sur du code « Legacy » (existant).
Parfois codé par des codeurs inexpérimentés, parfois détérioré simplement par les contraintes de délais imposés, le code Legacy est difficile à maintenir et les risques d'erreurs sont nombreux lors d'intervention.
Comment intervenir sur de tels projets sans détériorer l'existant ? Michael Feather propose des dizaines de méthodes, de trucs et d'astuces afin de :

• diminuer les dépendances du code ;
• mettre en place des tests unitaires sur le périmètre d'intervention ;
• améliorer petit à petit le code existant.

Ce livre s'adresse aux codeurs intermédiaires qui ont déjà une notion du TDD, et qui souhaiteraient le mettre en pratique, y compris sur des projets existants.
Il permet de rendre le code plus modulable et facilement testable.
Les exemples sont en C++, C# ou Java, certaines techniques sont dédiées à un langage (l'usage des Macros en C/C++) mais la plupart sont applicables à tous.
En résumé
Les exemples sont clairs et didactiques, c'est le complément indispensable de « Test Driven Development By Example » pour mettre en oeuvre le TDD et migrer vers de l'agilité sur des projets existants.
Un seul regret, il n'existe qu'en anglais.

Après avoir entendu plusieurs fois parler de la certification ISTQB, j'ai profité de la sortie de la version 3 du livre qui couvre le syllabus Fondation, version 2010 pour regarder ça d'un peu plus près.
Autant aller directement à l'essentiel : "Software Testing Foundations" est un très bon livre pour les débutants mais pas suffisant pour préparer la certification (aucune indication de son déroulement, aucun examen blanc.) comme le confirme annexe B.
Lors de l'introduction, l'importance des tests est abordée. Dès le premier chapitre on retrouve toutes les qualités du livre, sa facilité de lecture, ses exemples et astuces, ses commentaires dans la marge...
Une autre qualité que l'on trouvera dans la suite est le fait de bien amener les idées. Par exemple dans un premier temps on nous dit que l'on ne peut pas tout tester. Puis que si l'on ne trouve pas de bogue cela ne veut pas dire qu'il n'y en a pas. Pour conclure sur l'importance d'une méthode de test.
L'autre plus du livre est qu'il n'est pas seulement théorique et qu'il tient compte de la réalité avec des conseils pratiques comme le fait que dans un projet le temps consacré aux tests n'est pas toujours suffisant...
Puis les auteurs nous présentent l'exemple qui sera utilisé tout au long du livre.
A la fin du chapitre les auteurs nous ont expliqué leur philosophie du test et tous les termes associés (que l'on retrouve dans le glossaire à la fin du livre).
Dans le chapitre suivant, l'exemple du cycle en V est utilisé pour nous montrer l'utilisation des tests. On a droit aux tests unitaires, tests d'intégration. de manière détaillée avec leurs objectifs, leurs stratégies... Les méthodes agiles sont aussi abordées dans une moindre mesure.
Puis un chapitre entier nous parle des tests statiques avec une partie sur la revue (de code, de documentation.) et l'analyse statique.
Dans la continuité l'analyse dynamique (boite noire, boite blanche.) est traitée.
Enfin de manière sommaire (un autre livre lui est dédié) mais complète, le management des tests est traité.
Un chapitre sur les outils conclut le livre.
En annexe on trouve un exemple de plan de test avec de nombreuses astuces.

Tester est une des bases de la création d'applications robustes et efficaces. O'Reilly a publié dans sa série "Beautiful" un grand nombre de livres sur des parties différentes du process de développement. Ici, il s'agit de la partie sur les tests.
D'après ce livre, il y a 3 aspects aux tests : les testeurs, les processus et les outils.
Peut-être que le problème le plus important dans les tests est l'obtention de testeurs motivés. La première partie du livre n'a que 3 chapitres, j'imagine qu'il n'y a pas de baguette magique pour avoir une équipe de testeurs, il faut surtout que les personnes s'entendent.
La deuxième partie est la plus importante, elle a obtenu le plus d'attention dans le livre. Avec du recul, grâce à ce livre, j'ai réalisé que beaucoup d'aspects des tests n'étaient jamais abordés, et je pensais que certains codes ne pouvaient même pas être testés. J'avais naturellement tort. Par exemple, le test de code mathématique peut être effectué, un chapitre donne de bonnes pistes à suivre. D'autres chapitres parlent du fuzzing et donc d'un angle qui est surtout corrigé après la découverte d'un bug (le fuzzing permettrait de corriger le problème avant qu'il ne soit découvert), ou encore le test d'application sur réseau. En fait, l'étendue des projets qui ont participés me donnent de l'espoir et me rendent aussi honteux (parce qu'il y a beaucoup de choses que je n'avais testé, que je n'avais pas anticipé, ...).
La dernière partie s'occupe des outils utilisés pendant les tests. Il ne s'agit pas des usuels xUnit, mais bien de quelques-uns des outils qui ont commencés petits et qui ont fini comme des piliers de leurs projets parents, d'outils Open Source (valgrind, ...) ou encore d'autres.
A champ très large de projets, de personnes et de workflows sont décrits dans ce livre. S'il a beaucoup de beaux processus, il n'y a pas beaucoup de moyens de rassembler de belles personnes dans des équipes de tests. De plus, il semble que beaucoup de beaux outils étaient de petits outils qui étaient écrits pour un objectif très rapidement puis refactorés dans quelque chose bien plus puissant.
J'ai particulièrement apprécié quelques chapitres dans la deuxième partie, et surtout celui sur les tests statisques. Il est parfois très difficile de tester ces codes, et même si le chapitre ne résoud pas le problème des statistiques lui-même, il aide à la création d'un framework qui ressemble à des tests aléatoires réels.
Et je ne verrai plus les équipes de Q&A de la même manière.
Testing is one of the basis to create robust and correct code. O'Reilly has published in its "Beautiful" series a lot of books on different parts of the development process. This is the testing part.
According to this book, testing has three aspects: testers, process and tools.
Perhaps the biggest issue in testing is getting motivated testers. The first part of the book has only three chapters. I guess there is no silver bullet for getting a beautiful team of testers, it's mainly about people getting along.
The second part is the one that got the most attention in the book. In retrospective, thanks to this book, I've discovered many aspects of testing are never addressed , and I thought that some code couldn't even be tested. I was obviously very wrong. For instance, testing mathematical code can be done, a chapter gives a pretty good direction to follow. Several chapters address fuzzing and thus an aspect of testing that is mainly done after discovering a flaw (whereas fuzzing may give a shot at fixing the bug before it is discovered), or also software testing over a network. In fact the broad scope of projects that participated in this part gives me hope and shame at the same time (because there are many things I didn't test for, didn't anticipate, ...).
The last part handles tools that are used during testing. It's not about the usual xUnit, but more about some of the once-upon-a-time small tools that morphed into one of the pillars of testing in its project, or Open Source tools (valgrind, ...) or even others.
A very broad scope of projects, of people and of workflow are depicted inside this book. If there are many beautiful processes out there, there are not so many ways of getting beautiful people inside test teams. Also, it seems that many beautiful tools were mainly small project tools that were written for a simple crude purpose and that were progressively refactored into something more powerful.
I especially liked some chapters in the process part, for instance the statistical one. It's something very difficult to test, and although the chapter doesn't solve the ultimate issue of statistics, it helps creating something that looks like real random tests.
Also, I won't see Q&A the same way now.

Les DVCS (Git, Mercurial, Bazaar...) sont très à la mode ces derniers temps, pour cette raison, mais aussi car je crois au fort potentiel de Git, j'ai souhaité lire "Version Control With Git" et vous pourrez trouver ici mon avis sur cet ouvrage.
Pour commencer, il faut dire qu'actuellement une utilisation efficace de Git se fait en ligne de commande, les outils comme TortoiseGit (Intégration de Git à l'explorateur de fichier Windows) ou eGit (Plugin Git pour Eclipse) ne sont pas encore au point. Partant de ce constat, je pense qu'un bon livre permet de saisir au mieux les concepts de Git, malgré les nombreuses ressources que l'on peut trouver sur internet (forums, tutoriaux, conférences, blogs). Un livre bien écrit et centralisant le meilleur des possibilités de Git est à mon sens plus efficace dans les premiers temps d'apprentissage d'un nouvel outil (en plus un livre c'est décentralisé, pas besoin de connexion à internet ).
Donc, dans "Version Control With Git", on commence par le point de départ qui est l'installation de Git sur les plateformes Linux et Microsoft Windows, puis plusieurs chapitres expliqueront :

• les concepts généraux de Git et son histoire (son créateur est quand même Linus Torvald), la signification du terme "distribué" et les avantages de l'outil ;
• gestion des fichiers au sein d'un repository Git ;
• le fonctionnement des branches ;
• les commandes permettant d'obtenir les différences entre objets et la fusion de celles-ci le cas échéant (Egalement un chapitre spécial sur les patchs) ;
• l'accès et le travail en équipe avec des repository distants ;
• le couplage de Git avec un repository SVN existant.

J'ai trouvé dans cet ouvrage beaucoup d'exemples jouant le rôle du fil rouge pour une bonne compréhension de l'outil, les commandes fonctionnent et les résultats observés se coordonnent avec ceux du livre, c'est limpide. Tous les aspects importants de Git sont traités de façon claire, j'ai apprécié le style de l'auteur, jamais ennuyant. De plus, on trouvera beaucoup de schémas illustrants les explications théoriques, notamment sur les objets commit et leur organisation. En fait, si on souhaite commencer un projet avec Git, je pense que ce livre explique tout ce qu'il faut savoir pour bien commencer.
Je recommande donc ce livre à tous ceux qui ne connaissent pas les outils de DVCS (notamment Git), livre qui est facile à comprendre et qui aidera beaucoup à la démystification de Git.

"97 Things Every Programmer Should Know" présente 97 conseils d'auteurs talentueux et célèbres (Kirk Pepperdine, Uncle Bob Martin...) aux programmeurs de tous horizons.
97 conseils pour 97 chapitres, 2 pages pour chacun, le livre présente 2 sommaires, le premier par ordre alphabétique des titres de chapitres et un second classement par catégories (Bugs and Fixes, Build, Deployment, Desgn, Coding, Error handling, Performance, Testing...) On peut donc lire ce livre linéairement ou par thème, pratique selon son besoin au moment de la lecture.
La lecture est facile, intéressante, passionnante et abordable pour un large panel de lecteurs. Par contre, bien que s'adressant à un public technique, il ne faut pas s'attendre à trouver beaucoup d'exemples de codes (voire quasiment aucun, à part "Code in the Language of the Domain" de Dan North ou "Missing Opportunities for Polymorphism" de Kirk Pepperdine), mais plus généralement des bonnes pratiques à suivre dans le quotidien du développement d'un projet informatique.
Certains conseils se répètent, mais je dirais qu'ils sont présentés sous des angles différents, apportant une certaine ouverture sur l'appréciation d'un conseil. Bien sûr, les développeurs rodés aux bonnes pratiques penseront que les conseils prodigués enfoncent des portes ouvertes, mais applique-t-on toujours réellement ce qu'on peut apprendre en théorie ? La lecture de "97 Things Every Programmer Should Know" sera peut être l'occasion de me faire mentir !
Parfois les auteurs auront des avis contradictoires, c'est aussi la richesse de cet ouvrage, une ouverture à la réflexion et le fait qu'il faille réfléchir avant d'appliquer bêtement la bonne parole.
Mes chapitres préférés ? Ou plutôt quelques uns parmi d'autres :

• "The Boy Scout Rule" de Robert C. Martin (Uncle Bob), ou comment laisser un code meilleur après que vous l'avez trouvé ;
• "Check your code first before looking to blame others" de Allan Kelly, ou l'art de balayer devant sa porte avant celles des autres ;
• "Two heads are often better than one" de Adrian Wible, ou l'art du pair programming ;
• "Write test for people" de Gerard Mezsaros, ou comment la lecture de ce chapitre par mes prédécesseurs aurait pu m'aider sur un projet actuel pour comprendre mieux l'aspect métier.

Développeur depuis plusieurs années déjà, j'ai retrouvé dans ce livre beaucoup de choses que je pratique déjà mais j'ai également beaucoup appris à la lecture d'autres chapitres et au delà des conseils aux programmeurs on pourra aussi trouver application de certaines bonnes pratiques dans la vie quotidienne.
Pour les débutants en programmation ce livre est à posséder absolument, pour les plus expérimentés je suis sûr qu'ils y trouveront leur compte ou tout du moins se rafraichiront la mémoire avec cette passionnante lecture. À noter également que le contenu de ce livre est sous licence Creative Commons accessible sur le site officiel, ça permet de se donner une idée avant l'achat physique du livre.

L'idée est simple, le résultat assez intéressant. Prenez une grosse poignée d'experts, demandez leur des conseils, rassemblez le tout sous la forme de 97 fois 2 pages par conseil, et vous voilà avec un contenu tout autant riche que dispersé sur une large gamme de sujets.
Cet ouvrage vous apporte avant tout des sujets de réflexion, certains vous étant peut-être déjà connus : les tests, les pratiques collaboratives, les outils de développement et de productivité, l'apprentissage, le professionnalisme, les performances, la prise en compte des besoins utilisateur, etc.
Selon votre expérience dans le milieu, certains conseils vous paraîtront sans doute évidents (utilisation d'un gestionnaire de sources), d'autres pas assez développés (design d'API) pour vous servir dans l'immédiat.
Difficile dès lors de donner la même satisfaction à tout type de lecteur : les moins expérimentés auront l'occasion d'en faire un livre de chevet qui les accompagnera pendant un bon moment, les plus aguerris seront sans doute confortés dans l'idée qu'ils sont sur la bonne voie.
En ce qui me concerne, si je devais reprendre l'un des conseils, celui qui m'a le plus marqué, ce serait l'un de ceux émanant de Robert C. Martin (Uncle Bob) et intitulé "The professional Programmer".
Robert C. Martin nous y explique que le trait marquant d'un développeur professionnel est son niveau de responsabilité individuelle (par rapport à son évolution de carrière, au code qu'il écrit, au fonctionnement de l'équipe à laquelle il contribue, etc.).
Dans ce qu'il affirme, une seule chose m'a énormement surpris (la culture française ?) et m'a longtemps fait réfléchir : "your are responsible for reading and learning". Uncle Bob nous encourage à ne pas compter sur nos employeurs pour nous former et, en tirant le parallèle avec des métiers comme docteur ou juriste, nous invective sur le fait que notre employeur n'est là que pour nous payer pour faire du bon boulot.
Un peu abrupt..., néanmoins force est de constater que, même si l'employeur joue le jeux des formations, ce sont bien en général ceux qui prennent les choses en main et exploitent les différentes pratiques de veille qui ressortent du lot.
Seule déception, même si un index propose un regroupement des conseils par thème, j'ai regretté que les conseils n'aient pas été regroupés en chapitres. J'ai également eu par moment le sentiment que certains conseils se recoupaient ce qui en soit n'est pas forcement très grave, mais rappelle qu'il ne suffit pas seulement de juxtaposer les différents avis pour créer un ensemble cohérent (les conseils sont classés par ordre alphabétique, selon le titre).
Cela n'enlève pour autant rien au rapport qualité / prix du livre et au contenu que tout professionnel du développement informatique devrait lire.

SOA et Sécurité, deux termes très présents et très importants dans le développement en entreprise.
Le titre est donc très prometteur. Mais les auteurs réduisent tout de suite la portée du livre dans l'introduction.
En effet, ce livre n'explique pas l'architecture et les concepts SOA et n'expose pas toutes les notions de sécurité non plus. Le livre portant sur l'intersection de ces deux domaines, une connaissance minimale des deux sujets était nécessaire pour commencer, ce livre s'adresse donc à un public initié, mais sans pour autant expert.
Cela dit, le livre est tout de même bien ficelé et intéressant. Il est composé de trois parties.
La première consiste en un rappel des bases de la SOA et de la sécurité par WebService : SOAP, SOAP Header, WS-Security.
La seconde partie présente les concepts de sécurité : authentification, autorisation, chiffrement,. Cette section est particulièrement intéressante. Elle présente diverses pratiques (utilisateur/mot de passe, Kerberos, PKI ) tout en décrivant leurs avantages et inconvénients.
La dernière partie est légèrement plus complexe et traite réellement de la sécurité orientée service. Encore une fois, les différentes implémentations d'un service de sécurité sont présentées ainsi que les technologies utilisées dans ce but (SAML, WS-Trust, . )
A la fin de la lecture, on a acquis bon nombre d'informations, mais il subsiste toutefois une impression d'insuffisance sur le sujet. Mais encore une fois, c'est volontaire. Au vu de la complexité des sujets, seules les bases sont présentées mais une multitude de liens sont fournis pour ceux qui désirent approfondir un sujet précis.
Au niveau des exemples, une implémentation basée sur Axis est fourni en fin de chapitre. C'est sans doute le seul bémol, Axis étant un peu vieillissant. Cependant, les exemples sont suffisamment explicites pour être adaptables facilement avec n'importe quel autre framework.
Ce livre est donc plus qu'intéressant, même si le titre " Introduction to SOA Security " aurait été plus représentatif.
English version :
SOA and security, two terms very present and important in the enterprise development.
Due to this and its title, this book sounds very promising. However, the authors reduce immediately the scope of the book in the introduction.
Indeed, the book is not intended to explain the SOA architecture and concepts, neither all the security notions.
The book is about the intersection of the two subjects and so a minimal knowledge of these is necessary. The book is aimed at an initiated public, but not an expert one.
However, the book is well put together and interesting. It is composed of three parts.
The first is a reminder of the basics of SOA and WebService security : SOAP Header SOAP, WS-Security.
The second part presents the concepts of security: authentication, authorization, encryption, ... This section is particularly interesting. It introduces various practices (user / password, Kerberos, PKI), while describing their advantages and disadvantages.
The last part is a little more complex and deals with real security-oriented service. Again, the different implementations of a security service are shown together with the technologies used for this purpose (SAML, WS-Trust, ...)
At the end of the reading, we have learnt lots of information, however there is still a feeling of weakness on the subject. But once again, it's voluntary. Given the complexity of the issues, only the fundamentals are presented, but many links are provided for those who wish to deepen a specific topic.
In terms of examples, an implementation based on Axis is provided at the end of the chapter. This is probably the only regret I have : Axis is a little old. However, the examples are explicit enough to be easily adapted with any other framework.
This book is more than interesting, even if the title "Introduction to SOA Security" would have been more representative.

Le livre Cloud Application Architectures est idéal pour les lecteurs sans réelles connaissances sur le sujet, plutôt orientés infrastructure que développement. Son faible volume (moins de 200 pages) et la qualité d'écriture de Georges Reese vous invitera à découvrir les concepts et ambitions du Cloud Computing, mais également de mieux comprendre les infrastructures PaaS, IaaS, SaaS.
Georges Reese illustre la description des architectures de Cloud Computing en s'appuyant sur la solution la plus aboutie du marché (à ce jour) : Amazon Web Services (AWS). Il détaille ainsi les différentes composantes déployées par Amazon pour proposer une plateforme pour le Cloud: EC2, S3, CloudFront, SQS, RDS, EBS.
Le chapitre 3 s'attache à exposer les arguments en faveur des infrastructures de type Cloud par rapport aux anciens modèles. Des informations relatives au calcul du retour sur investissement (ROI), du TCO (Total Cost of Ownership) sont distillées et permettront au décideur de disposer d'une aide pour évaluer son projet de Cloud.
Les chapitres suivants sont consacrés aux images AMI, à la sécurité (données, réseau, corruption), au disaster recovery et à la montée en charge, l'un des intérêts principaux du Cloud. De nombreux conseils et préconisations sont fournis, afin de vous éviter de tomber dans les pièges des débutants et tirer partie de l'intégralité de AWS. De très bonne lecture, je vous invite, administrateurs, décideurs, à feuilleter cet ouvrage.

"Cloud Application Architectures" de Georges Reese est un livre d'introduction (200 pages) aux architectures Cloud. L'auteur fait comprendre au travers de l'ouvrage les enjeux de ce nouveau genre d'architectures et montre bien que ce n'est pas seulement un "buzzword" à la mode mais une réelle perspective d'avenir.
Cet ouvrage commence par une définition du Cloud et de son intérêt pour l'entreprise ainsi qu'une explication de ses différents niveaux d'abstraction (SAAS, PAAS, IAAS). Viennent ensuite quelques démonstrations, notamment financières, sur les avantages à l'adoption du Cloud, simplement en comparant son coût à court, moyen et long terme par opposition à une architecture classique. On trouvera également de nombreux exemples pratiques (en ligne de commande et API pour S3, EC2...), principalement sur la plateforme Cloud IAAS d'Amazon, mais les exemples présentés sont également valables dans la forme pour une autre plateforme comme Microsoft Azure.
L'auteur aborde également des points du Cloud sur lesquels les entreprises s'interrogeront : sécurité, fiabilité, performance, scalabilité horizontale et verticale de l'infrastructure, sauvegarde, désastre...et les explications sont encore une fois limpides.
Voilà donc un livre clair, intéressant et rapide à lire, mais précis dans l'information. L'auteur donne d'excellents conseils sur les techniques et bonnes pratiques pour la mise en place d'une architecture Cloud. C'est donc un livre que je conseille à tout le monde en première lecture pour comprendre tous les enjeux d'une architecture qui est inévitable dans notre futur quotidien. Une lecture également intéressante pour ceux qui souhaitent se lancer dans des projets nécessitant une infrastructure que le Cloud pourrait offrir à moindres frais.

Pourquoi 97 trucs ? A vrai dire, je ne sais pas et je pense qu'il faut y voir la même astuce que le célèbre slogan de Magritte que l'on trouvera dans un chapitre du livre "Ceci n'est pas une pipe" (je vous laisse découvrir), à savoir que l'essentiel n'est pas toujours dans les apparences.
Un livre court (220 pages) et qui va à l'essentiel, 2 pages et la biographie des auteurs/architectes pour chaque sujet. Pas techniquement orienté, ce livre est plutôt axé sur la communication, et les ressources projet. On trouvera des conseils sur comment choisir les composants d'un projet, la gestion des équipes, savoir convaincre et communiquer au sein d'une équipe mais aussi avec le client.
Parmi mes sujets favoris (seulement quelques uns car j'ai marqué pas mal de pages) :

• "Stand Up!" de Udi Dahan qui explique que se mettre debout permet de mieux se faire écouter, comprendre, essentiel pour un architecte.
• "Architects Must Be Hands On" de John Davies expose que l'architecte pour être reconnu, et appuyé dans ses décisions devra faire ses preuves sur le terrain et non depuis sa tour d'ivoire.
• "Fight Repetition" de Niclas Nillson, un titre pas trop difficile à comprendre, quand on rencontre plus d'une fois la même situation il faut penser à automatiser.

Certains reprocheront que les explications fournies dans cet ouvrage relèvent simplement du bon sens de l'architecte (mais un rappel ne fait pas de mal), sûrement, mais je pense qu'il est bon de mettre le focus sur des points clés qui devraient être un credo pour tous les architectes.
Bien sûr, certains sujets ne m'ont pas intéressés, souvent parce que je n'en ai pas l'utilité actuellement, certains chapitres sont même répétés ("Architects Must Be Hands On" et "Before Anything, an Architect is a Developper") mais au final je pense que ce livre est une très bonne ressource à garder à portée de main. La granularité des sujets est parfaite pour une relecture rapide ultérieure lorsque le besoin de guider ses choix se fera sentir. Facile à lire, j'ai opté pour un rythme de lecture "4 à 5" sujets par soir (en plus les titres font presque penser à des contes), mais "1 ou 2" le matin avant de commencer la journée de travail ira aussi. A mon sens, un bon achat à faire !

Quand on met ensemble une vingtaine de créateurs de langage, le résultat ne peut être qu'intéressant. C'est un bon révélateur de caractère, comme ils tendent à ouvrir leur coeur. Je pense que c'est exactement ce qui s'est produit ici.
Pas besoin de lister les langages proposés, ils font parti des langages à succès, en terme de qualité ou en terme de renommée, ce qui veut dire que certains peuvent être peu connus. Chaque chapitre est très différent des autres et, comme je l'ai dit auparavant, est très révélateur de leur auteur.
En fonction de la personne interviewée, les topics abordés sont différents. Pour certains auteurs, on a des questions sur des thèmes proches de leurs langages. Pour d'autres, les auteurs parlent de leur vision du futur de la programmation. Certains vont nous dire à quel point leur langage est superbe et que c'est une honte qu'il ne soit pas plus utilisé ou qu'il pourrait tout remplacer. D'autres encore vont vous dire que le langage leur a échappé des mains.
Il n'y a pas une seule ligne de code, c'est surtout un livre de pensées, et c'est le coeur du livre : on n'a pas de conseil sur comment écrire son code ou designer son application. On récupère les raisons fondamentales derrière un langage et leur succès. Des pistes sont données sur le futur de nos programmes, comment les langages vont évoluer et sur quoi il faut potentiellement de focaliser. Malheureusement, le chapitre que j'ai presque le plus apprécié est le dernier (sur Eiffel). C'est drôle que dans ce celui-ci, Bertrand Meyer parle des pépites qu'il a trouvé dans le dernier chapitre d'un autre ouvrage, Structured Programming (Dijkstra et al).
D'un point de vue culturel, ce livre est une mine d'or. D'un point de vue des égos, ce livre est un révélateur. Toutes choses étant égales, un grand nombre de choses peuvent être apprises en lisant ce livre sur l'approche philosophique d'un langage.
When twenty or so langage creators are put together to make a book, it can only be interesting. It's a good revealer of character, as they tend to open their heart. In fact I think that's exactly what happened in this book.
I won't make the list of the chosen langages. They are taken from the successful ones, in terms of quality as well as fame, which means that some are less known than others. Each chapter is very different, and, as I've said, very revealing.
Depending on the interviewed, the addressed topics are different. For some authors, you get questions and answers very close to their langages. For others, you have some feedback on how they see the programming field and its future evolution. Some will tell you how much their langage is great and that is a shame it is not more used or that it could replace almost everything. Other will tell you that they fill their langage slipped through their hands.
There is no single line of code, it's really a thoughts book, and this is the point of the book: you don't get advice on how you will write code or design your application. You get inner reasons for some langages and their success. You get leads for the future of your program, how langages may evolve and on what you may focus your attention. Unfortunately, the chapter I almost liked the most is the last one (on Eiffel). It's funny that in this precise chapter, Bertrand Meyer talks about the treasures he found in the last chapter of Structured Programming (Dijkstra et al).
From a cultural point of view, this book is a gold mine. For an ego point of view, this book is a revealer. All things considered, a lot of things can be learnt by reading this book on the philosophical approach of some langages.

Lors que j'ai lu le résumé de ce livre, j'ai su que je voulais le lire. Et à la fin de ma lecture, je ne suis absolument pas déçu, bien au contraire !
Au contraire des ouvrages habituels sur la programmation, celui-ci ne vous apprendra pas le moins du monde à programmer, ni même à concevoir, ni ne vous apprendra un quelconque nouveau langage. Mais il vous fera découvrir les états d'esprit, de synthèse, de conception, de ce que l'auteur a nommé les masterminds (les génies) de la programmation.
Il est difficile de critiquer ce livre sur la base de son écriture ou de sa pédagogie, qui sont tout simplement sans objet ici. En revanche, je soulignerai la qualité du choix des questions posées en interview, ainsi que l'apport global que le lecteur pourra en tirer, qui sont exceptionnels.
Je recommande en particulier ce livre à tous ceux qui conçoivent - ou qui ont l'intention de concevoir - un langage de programmation. Les conseils, prodigués par les maîtres en la matière, que cet ouvrage nous livre leur seront d'une aide incontestable. Ceci est valable également pour les étudiants pour qui ce serait un projet de cours ou de mémoire.
Ceci ne veut pas dire pour autant que je ne le conseille pas aux autres développeurs. Les discussions avec ces génies de la programmation seront bénéfiques à tous, ne serait-ce que pour comprendre les raisons d'existence des langages qu'ils utilisent au quotidien.
En bref, un livre à lire au moins une fois dans sa vie - si pas plus !

"Beautiful Architecture" est un ouvrage composé de 14 chapitres sur le sujet de l'architecture logicielle. Un vaste domaine de l'industrie logicielle qu'il est assez difficile de définir, si je devais en faire une peinture basique, ce serait l'art de définir la structure d'un système, de ses composants et des relations entre les différents éléments qui la composent.
Le livre commence ainsi sur un premier chapitre qui tente de répondre à la question de ce qu'est l'architecture, question maintes fois posée, mais sur laquelle apparemment plane toujours le doute. Un second chapitre compare 2 applications, un mauvais exemple, puis un bon (selon les auteurs) puis suivent 12 derniers chapitres couvrants des thèmes très différents (facebook, emacs, KDE...) et toujours étroitement liés à l'architecture (quoique).
Les bons points du livre

• Un contenu plutôt intéressant avec lequel on apprend parfois
• Des sujets tendances ou qui sauront toucher : facebook , MMORPG, KDE, emacs...

Les moins

• Une lecture quelque peu ennuyeuse et rébarbative (j'ai eu parfois l'impression d'un simple remplissage des pages)
• Une mise en page triste
• Quel crédit donner aux architectes mentionnés dans le livre ?
• Manque de cohésion entre les chapitres et finalement sur le livre en entier, plusieurs auteurs donc plusieurs visions différentes et pas toujours de concert
• En principe l'architecture n'est pas le code, on pourrait alors se poser la question de la présence de bout de code dans le livre
• Un bon bagage est nécessaire avant d'entamer la lecture, développeur junior passe ton chemin...

J'ai au final un avis très mitigé sur cet ouvrage, partagé entre le fait d'avoir appris à la lecture de "Beautiful Architecture" car on a quand même un bon livre pour se donner des idées et de l'information sur l'architecture logicielle, mais l'ennui à la lecture était trop présent pour en faire un "must-have". Comment utiliser ce livre ? pour ma part certains chapitres m'ont plus intéressé et j'en ai retenu de l'information immédiatement, pour d'autres j'ai repéré de l'information qui me servira peut être un jour...

Beautiful Architecture est une sorte de suite de Beautiful Code que j'ai eu l'occasion de lire par le passé. Bien plus petit, ce livre est dédié à l'architecture, même si Beautiful Code proposait aussi certains aspects sur l'architecture. La question qui restait était de savoir si le livre était aussi bon que son prédécesseur.
L'éditeur du livre l'a découpé en 5 parties. La première est très générale et courte. Le principal sujet est la raison pour laquelle il est nécessaire d'avoir une bonne architecture, avec des expériences réelles sur une bonne et une mauvaise architecture. C'est une introduction nécessaire, même si le contenu est plutôt convenu.
La seconde m'a laissé quelque peu déboussolé. Lorsqu'on connait un peu des ouvrages sur l'architecture, on apprend peu. OK, c'est un ouvrage sur l'architecture logicielle, mais de vraies architectures sont attendues, et certaines de celles présentées (comme les web services) sont plutôt évidentes, même si le chapitre sur Facebook est intéressant à ce niveau.
La partie suivante est dédiée au matériel, émulé, virtualisé ou le vrai. Cette partie était vraiment intéressante, avec beaucoup de détails sur des projets connus (Xen) ou moins connu (Guardian, bien connu il y a quelques années et très intéressant quant à sa philosophie). J'ai eu moins d'intérêt pour les deux projets Java, comme il ne s'agit pas d'une technologie que j'utilise tous les jours, mais l'approche était plaisante.
Après le matériel, deux chapitres sont dédiés à deux projets très connus et très différents : Emacs et KDE. Le chapitre est plus consacré à l'équipe et à comment l'architecture a émergé de discussions, qu'à l'architecture elle-même, et je pense que l'autre message derrière cette partie est d'apprendre à communiquer à l'intérieur d'une équipe de développement.
Enfin, la conclusion commence par une discussion sur les langages orientés objet (le type le plus utilisé actuellement) contre les langages fonctionnels, écrite par une référence dans le domaine, Bertrand Meyer. Il faut être bien concentré pour comprendre son message. Pour cette démonstration, Meyer utilise un langage orienté objet réel, Eiffel, non pas un des langages "incomplets" comme C++ ou Java. Par conséquent, certains concepts peuvent échapper au lecteur. Et le dernier chapitre discute des architectures surfaites, générant des programmes incomplets avec des exemples où des architectes en bâtiment célèbres ont créé de superbes architectures tout en perdant de vue l'objectif principal qui était le logement (et non la beauté extérieure). Comme chaque livre sur l'architecture ou la conception logicielle, il est nécessaire d'expliciter que le mieux est l'ennemi du bien.
Moins surprenant que son prédécesseur, plus court et moins impressionnant, ce livre est parfois ennuyeux. D'un point de vue culturel, il est très bon, avec des exemples de domaines différents. Certains chapitres sont trop évidents si on est déjà habitué au sujet, et cela gâche le plaisir de la lecture.
Beautiful Architecture is a kind of follow-up of Beautiful Code, which I reviewed some time ago. Far smaller, the book is aimed at architecture, although Beautiful Code also presented some aspect of architecture. The question I've asked myself whether or not it is as good as its predecessor.
The editor split the different architecture topics in 5 parts. The first is very general, and short. The main topic is why you should have a good architecture, with some real experience with good and bad architectures. It's a necessary introduction, even if the content is to be expected.
The second part left me with mixed feelings. If you're used to architectural readings, you won't learn much, in my opinion. OK, it's a book on software architecture, but actual architectures are expected, and some displayed architectures (like web services) are obvious, although Facebook's chapter is interesting in that matter.
The third part is dedicated to hardware, emulation, virtualization or real one. This was really interesting, with a lot of details on known projects (Xen) or lesser-known ones (Guardian, which I didn't hear about until the book, but which was really interesting in its philosophy). I had less interest in both Java projects, as it's not something I deal with on a regular basis, but the approach was enjoyable.
After the hardware, two chapters are dedicated to two well-known projects with really different teams, Emacs and KDE. KDE's chapter is almost more about the team and how the architecture emerged from team's discussions than architecture itself, and I think that another message behind this part is to learn to communicate inside the developer team.
Finally the conclusion starts with a discussion on object-oriented languages (the kind that is mainly used) versus functional ones, by a reference in that field, Bertrand Meyer. One has to be focused to fully understand Meyer's message. For his demonstration, he uses a real object-oriented language, Eiffel, and not one of the usual not-fully object-oriented languages like C++ or Java. So some concepts may be missing to you. And the last chapter is about overdoing an architecture and finishing with a half-baked software with examples from the buildings architecture where some famous architects overdid their work and losing sight of the buyer's needs. Like every book on architecture or software conception, it is best to explicitely state that too much is the enemy of a good program.
Less surprising than its predecessor, shorter and with less magnificence, this book is sometimes more boring. From a cultural point of view, it's a good one, with examples for very distinct fields. Some chapters are too obvious if one is familiar with the field, and this spoils a little bit the pleasure of reading.

Version française
On ne présente plus l'intérêt des tests unitaires. En effet, cette technique devient de plus en plus répandue dans le monde informatique, quel que soit le langage, et permet, lorsque ces tests sont bien faits, d'améliorer nettement la qualité du logiciel produit, tout en facilitant la maintenance du produit. Des tests unitaires bien codés permettent de détecter rapidement tout nouveau bug introduit dans le projet, et peuvent donc éviter des régressions dans le code.
La question qui reste souvent en suspens est de savoir comment produire de "bons" tests unitaires. La littérature informatique contient un nombre important de livres parlant de méthodologies (Agile, XP, Scrum), mais il manquait (en tout cas, en .NET), un livre explicitant clairement comment produire des tests unitaires de qualité. C'est l'objectif de The Art Of Unit Testing.
Le livre commence par une introduction aux tests unitaires, à NUnit, et par un ensemble de définitions. On passe ensuite assez vite à un peu de pratique avec un premier test unitaire.
La partie suivante approfondit la notion de mock et de stubs, et aborde en profondeur le Framework Rhino Mocks. Cette partie présente de plus un ensemble de bonnes pratiques liées à l'utilisation de ce Framework, ou de tout autre Framework d'isolation.
Après avoir abordé les éléments constitutifs des tests unitaires, la troisième partie présente un ensemble de bonnes pratiques pour les tests eux-mêmes, pour éviter (entre autres) que le coût de maintenance des tests ne dépasse le gain procuré par leur existence.
Enfin, la dernière partie du livre se place à un niveau au-dessus, et présente les différents points à garder à l'esprit lors de l'introduction des tests unitaires au niveau d'une organisation et plus particulièrement dans un projet déjà existant, ce qui peut représenter une bonne partie des cas lorsque l'on introduit les tests au sein d'une équipe ou d'un ensemble de projets.
Ma plus grande crainte avec ce livre était que, Roy Osherove travaillant pour TypeMock, il parle surtout des outils commerciaux de TypeMock (Isolator, Ivonna et compagnie). En fait, ces outils ne sont que très peu mentionnés dans cet ouvrage, qui se concentre sur les "standards" que sont NUnit et Rhino Mocks.
L'un dans l'autre, ce livre est probablement la meilleure introduction aux tests unitaires que j'ai jamais lue, et devrait, à mon avis, être une lecture obligatoire pour toute équipe décidant de commencer à utiliser les tests unitaires. En tout cas, personnellement, c'est le livre que j'aurais aimé avoir il y a deux ans, quand j'ai commencé à écrire des tests.
Cela dit, ce livre requiert une certaine expérience du développement avec le framework.NET pour l'apprécier correctement, je le conseillerais donc à des personnes ayant au moins 2 ou 3 projets derrière eux.
English version
It is no longer needed to discuss the need for unit tests. Indeed, this technique becomes increasingly widespread in the computer world, whatever the language, and, when those tests are well crafted, they can significantly improve the quality of software, while facilitating the maintenance of the product. Unit tests can detect any new bug introduced in the product, and can therefore avoid regressions in the code.
The question that often remains unresolved is how to produce "good" unit tests. The literature contains a large number of books discussing methods (Agile, XP, Scrum), but there was no (in any case, for. NET) book explaining clearly how to produce some quality unit tests. That is the goal of The Art Of Unit Testing .
The book begins with an introduction to NUnit, and a set of definitions. It then moves quickly enough to a bit of practice with a first unit test.
The next section develops the concept of mock and stubs, and discusses in depth the Rhino Mocks framework. This part furthermore presents a set of good practices related to the use of this Framework, or any other isolation framework.
After discussing the building blocks of unit tests, the third part presents a set of good practice for the tests themselves, to avoid (among other issues) that the maintenance cost of the tests exceeds the advantage gained by their existence.
The last part of the book is looking at a level above, and presents the different points to keep in mind when introducing unit tests in an organization and especially in an existing project, which can represent a large proportion of cases when introducing unit testing in a team or project.
My biggest apprehension with this book was that, with Roy Osherove working for TypeMock, he would speak mostly of the commercial tools develpped by TypeMock (Isolator, Ivonna and co.). In fact, these tools are only marginally mentioned in this book, which focuses on 'standards' such as NUnit and Rhino Mocks.
All in all, this book is probably the best introduction to unit tests I've ever read, and should, in my opinion, be required reading for any team or person decided to start unit tests. In any case, personally, this is the book that I would have loved to have two years ago, when I started writing tests.
That said, this book requires some development experience with the .NET framework to appreciate it properly, therefore I recommend it to people having at least 2 or 3 projects behind them.

Lorsqu'on voit le livre pour la première fois, on se retrouve avec un livre de seulement 160 pages, écrit par un spécialiste de la performance qui travaille chez Compuware. Dès le début, on nous informe que ce livre est pour les chefs de projets et les testeurs débutants ou occasionnels et qu'il ne traitera pas de technologie particulière.
Le premier chapitre explique pourquoi il faut faire un test de performance et parle de quelques métriques (KPI). Puis l'explication des mauvaises performances d'une application nous est donnée (pas de prise en compte de la performance dans le design de l'application, test de performance seulement à la fin, pas d'objectif de capacité (nombre d'utilisateurs...), sous-estimation du succès de l'application, maturité du processus de test de performance...).
Le deuxième chapitre entre dans les détails d'une campagne de test de performance. On commence par les questions à se poser en début de campagne, puis les étapes avant de commencer à faire les tests (choisir les bons outils, avoir des SLA réalistes, avoir un jeu de données suffisant et de qualité, identifier les KPI, identifier les scénarios critiques...) sont listées et expliquées une par une. Par exemple pour l'étape « choisir les bons outils », on a droit à :

• Petit historique.
• Comment et pourquoi faire un POC.
• Critères de sélection (support de la technologie utilisé (HTTP, HTTPS...), type de licence, simplicité pour la partie Scripting...).
• Des conseils (dans la vraie vie, il faut presque toujours obliger de modifier les scripts enregistrés, faire attention au prix qui peut augmenter rapidement (besoin de nombreux tirs car l'application n'est pas stable) si c'est externalisé)...

Les autres étapes sont aussi très bien expliquées avec souvent un retour d'expérience de l'auteur et des check-lists.
Le troisième chapitre est la mise en oeuvre de ce qui a été dit au chapitre 2 et est fini avec deux exemples concrets (une banque en ligne et un centre d'appel). Quoique bien détaillés, je trouve que ces deux exemples auraient mérité plus de détails.
Au chapitre 4, on nous explique comment interpréter les résultats et trouver les problèmes de performance. Malheureusement comme le livre ne traite pas de technologie, cela manque d'exemple concret.
Le chapitre 5 traite de manière succincte l'impact des différentes technologies (Ajax, Citrix, .NET...) sur les tests.
Puis en annexe on retrouve des check-lists, une liste des outils de test et des maquettes/exemples de planning.
On se retrouve avec un bon livre si l'on fait partie de la cible de celui-ci. Une centaine de pages en plus avec plus d'exemples concrets (en traitant un peu plus de technologies) lui aurait valu la note maximale.

Le livre sur les performances des applications réseau est découpé en 5 chapitres, sur un peu plus de 150 pages.
Le premier chapitre définit les raisons des tests de performance. Malheureusement, ceux-ci sont bien souvent exécutés trop tard ou mal exécutés. C'est l'objectif du livre de présenter les bonnes pratiques.
Le second chapitre est pour le moins imposant puisqu'il occupe la moitié du livre. Il s'agit du coeur du test de performance : que tester ? comment tester ? quels outils sélectionner et sur quels critères ? La présentation est claire, précise et va au but.
Les trois derniers chapitres reprennent les éléments du deuxième chapitre. Tout d'abord, il faut amener la nécessité d'effectuer ces tests de performance, et deux exemples sont donnés, avec toutes les étapes. Il s'agit par la suite d'analyser les résultats, comment récupérer la cause du manque de performance, ... Le dernier chapitre recense quelques technologies qui peuvent impacter les performances.
En définitive, un très bon livre sur les tests de performance des applications réseaux. En plus, il a été imprimé sur du papier recyclable.

Visualizing Data est un livre dont l'objectif est d'introduire au lecteur les techniques de visualisations de données. Pour cela, l'auteur se base sur 7 étapes fondamentales qui seront introduites dès le premier chapitre. A chaque introduction d'un nouveau type de données, ou d'un nouveau concept à modéliser, ces étapes seront précisées. Cela permet au lecteur de savoir à quel niveau de la méthode il se situe et donc de pouvoir se référer à la partie du premier chapitre si nécessaire. Je trouve cela plutôt judicieux.
Pour ma part, je dirais que livre se découpe en 3 parties principales: introduction de la méthode (et du langage utilisé), types de donnée/types d'affichage et enfin traitement des données en vue d'un affichage plus approprié.
La première partie présente les 7 étapes de la méthode et le langage utilisé. Il s'agit d'un dialecte Java développé par l'auteur afin de faciliter la visualisation, nommé "processing". Dès cette première partie, le principal défaut de l'ouvrage est présent : l'auteur ne va pas au bout des choses. La méthode est néanmoins présentée de manière compréhensible et claire grâce à l'utilisation d'un exemple extrêmement simple. Et il s'agit ici de l'atout principal du livre : il est riche en exemples.
La seconde partie liste simplement des exemples pour les différents types de donnée. Je pense qu'il aurait été judicieux de rajouter des exemples un peu plus "tordus" afin de montrer comment quelquechose de complexe, une fois bien analysé, peut se représenter de manière extrêment simple. Les exemples, en revanche, couvrent presque tous les domaines et donnent toutes les bases. Par contre, vous risquez d'avoir besoin de complément pour certains problèmes plus spécifiques (toujours le même défaut !).
La dernière partie aurait pu être la plus intéressante, car elle présente comment traiter les données, si elle n'avait pas été si pauvre. Encore une fois, seules les bases d'acquisition et de traitement des données sont présentées. Il faut néammoins laisser à la charge de l'auteur qu'un approfondissement de cette partie revient à écrire un livre traitant de la fouille de données!
En conclusion, je soutiens que le livre est intéressant mais ne présente en réalité qu'un ensemble d'exemples et n'approfondit pas les choses. Il aurait été vraiment intéressant d'aller plus loin, beaucoup plus loin... Ce livre se révèle une excellente acquisition, si il est couplé avec un livre traitant des fouilles et de l'acquisition des données.

Dans la préface, Mary Poppendieck annonce la couleur : l'agilité ce n'est pas qu'un truc de développeur, ce n'est pas une recette miracle à appliquer de manière normalisée sans tenir compte de la culture d'entreprise et de ses acteurs.
Pour autant, il est rappelé qu'il y a un noyau dur indispensable à la mise en oeuvre d'un environnement agile, résumé par le manifeste agile.
Voilà ce que les auteurs tentent de couvrir dans cet ouvrage, tout en pratique et regorgeant de conseils pour vous aider à mettre en place "un" processus agile adapté à votre entreprise/project.
Becoming Agile n'est pas un autre livre à classer dans la pile des livres traitant des méthodologies agiles, il s'agit d'un des rares ouvrages qui va vous accompagner dans l'adoption et la mise en place / transition vers un processus agile.
Par conséquent, ne vous attendez pas à un contenu exhaustif sur des pratiques agiles précises (TDD, intégration continue, etc.) : d'autres ouvrages en abondance le font déjà très bien.
Au programme de cet accompagnement :
- des conseils et outils pour analyser l'environnement de départ
- accompagnement à la composition du processus agile adapté, et migration sans remise en cause de l'ensemble de l'existant
Après avoir introduit la pensée agile et l'avoir projetée sur les différentes dimensions économiques et stratégiques d'une entreprise, les auteurs introduisent l'étude de cas d'un projet pilote qui nous accompagne tout au long de l'ouvrage à travers 9 étapes d'adoption d'un processus agile.
Le livre se présente certes comme théorique, crainte largement atténuée par la présence de l'étude de cas qui se lit très facilement, comme une histoire.
De plus, les auteurs n'en oublient pas d'introduire un certain nombre d'outils, en particulier un guide méthodologique complet pour évaluer votre potentiel à faire la transition vers un processus agile (pour en savoir plus : http://www.dragile.com/).
On mentionnera notamment la Tradeoff Matrix (laquelle illustre bien l'importance d'identifier et hiérarchiser les contraintes pour n'en avoir qu'une seule qui guidera l'organisation de projet), les Feature Cards (et leurs équivalents informatisés pouvant par exemple être mises en oeuvres avec des outils comme SharePoint, VersionOne, ou Rally), le Planning Poker (pour en savoir plus : http://www.planningpoker.com/, le Burndown Chart, ainsi que la Progress Matrix.
On n'oubliera bien sur pas l'équivalent "CMMI" pour les pratiques agiles : le SAMI (Sidky Agile Measurement Index), une initiative de l'un des auteurs.
Cet ouvrage traite à la fois la problématique d'un point de vue organisationnel et d'un point de vue pratique.
Ainsi tout en alimentant la réflexion sur la difficulté dans une entreprise à faire adopter les pratiques agiles (les auteurs soulignent notamment un gouffre entre la population d'Early Adopters et celle d'Early Majority), ils proposent des solutions et une méthodologie (à commencer par exemple par analyser son "potentiel" et se tester via un projet pilote).
Ce véritable Must Have, bible de l'agiliste, se lit très bien et vous accompagnera dans votre transition vers des pratiques agiles, mais bien au delà dans votre quotidien.
English version :
In the foreword, Mary Poppendieck declare trumps: agility is not only a developers thing, it's not a magical recipe to apply in a normalization manner without taking into consideration enterprise and people's culture and knowledges.
Despite that, it's reminded that a fixed core is essential to the setup of an agile environment, summarized by the agile manifesto.
That's exactly what the authors try to cover in this book, very concrete and holding a lot of recommendations to help you setup "an" agile process which fits to your enterprise/project.
Becoming Agile is not another book to be classified in the existing ones handling agile practices, it's one of the rare writings which will go with you in the adoption and setup / migration to an agile process.
As a consequence, don't expect an exhaustive content on some particular agile practices (TDD, continuous integration, etc.) : plenty existing books already handle these topics very well.
What can you find ?
- some advices and tools to analyse your current situation
- a companion guide to build your dedicated agile process, and migration without fully challenging your legacy
After having introduced the agile thinking and projected on different economic and strategic angles a company has, the authors introduce the study case of a pilot project which will help to illustrate the talk all along the book during 9 steps of agile process adoption.
Although the book appears as theoretical, this fear is widely attenuated thanks to this study case which can be read very easily, like a story.
Moreover, the authors don't forgent to introduce a few tools, in particular a complete methodological guide to evaluate your potential to do the transition to an agile process (for more information: http://www.dragile.com/).
We can also mention the Tradeoff Matrix (which illustrate well the necessity to identify and put an order on the constraints, so that only one will define the guidelines of your project organisation when you will face some hazards), the Feature Cards (and their computerized counterpart which would be manageable thanks to tools like SharePoint, VersionOne, or Rally), the Planning Poker (for more information : http://www.planningpoker.com/, the Burndown Chart, and also the Progress Matrix.
By the way, I'm not forgetting the "CMMI" like model built for agile practices: the SAMI (Sidky Agile Measurement Index), an initiative of one of the authors.
This publication handles at once the problematic from an organisational point of view and from a practical one.
Thereby, while bringing some input to the reflection on difficulites in companies to have people adopt agile practices (the authors emphasize a chasm between the Early Adopters and the Early Majority), they suggest some solutions and a methodology (which begin by an analysis of a one's "potential" and a first contact through a pilot project).
This real Must Have, agilist's bedside book, reads very well and will companion you in your migration to agile practices, but well beyond in your daily working (or not only) life.

Cet ouvrage est un véritable recueil de bonnes pratiques pour les programmeurs et toute personne souhaitant augmenter sa productivité avec les outils informatiques.
Neal Ford, architecte chez ThoughtWorks et membre du fameux http://www.nofluffjuststuff.com, nous livre toute sa boîte à outils et prodigue des précieux conseils.
L'ouvrage commence avec un ensemble de chapitres dédié à la productivité sur le poste de travail, ceci donc indépendamment de tout outil ou langage/plateforme spécifique de développement.
C'est en fait la partie que j'ai le plus apprécié, dévorant les premiers chapitres sans retenue : Windows, Linux, Mac, aucun des 3 OS majeurs n'est oublié.
Ils contiennent de nombreux conseils pleins de sens illustrés par des utilitaires permettant de les mettre en oeuvre (raccourcis, navigation, outils d'indexation et de recherche, macros, DRY et conventions, etc.), et surtout une recommandation majeure : lorsqu'on sent qu'on passe son temps à répéter une succession d'opérations ou commandes, il est temps de réfléchir à une optimisation (que cela passe par de l'automatisation ou non), encore plus si on se refuse à le faire par soi disant manque de temps !
Après le chapitre 5 qui est en quelque sorte un chapitre de transition, l'ouvrage prend une tournure beaucoup plus orientée développement avec comme principal langage sous-jacent Java (mais aussi Groovy, Ruby).
L'auteur s'intéresse notamment au TDD (Développement dirigé par les tests), aux outils de qualimétrie (couverture de code, complexité cyclomatique) et illustre de bonnes pratiques de programmation orientée objet.
Comme dans toute approche de développement Agile, l'auteur insiste sur la réduction de complexité et l'utilisation de code simple, avec une utilisation parcimonieuse de frameworks (il témoigne néanmoins de par sa propre expérience des limites d'une approche zéro framework).
Les chapitres (courts le plus souvent) s'enchaînent et introduisent à chaque fois un nouveau concept, généreusement illustré par du code, ce qui rend la lecture aisée.
On notera en particulier le chapitre 14 insistant sur la nécessité d'oser se détacher de son langage de prédilection pour faire le choix du langage approprié pour une tâche / un fragment d'application précis. En effet, il est de nos jours établi que les langages de script améliorent la productivité et peuvent être employés dans certaines parties d'une application (on pensera notamment aux DSLs) et en interaction avec des langages de plus haut niveau (comme Groovy avec Java), mais également pour réaliser rapidement de petits utilitaires comme souvent on peut en avoir besoin (migration, statistiques, etc.).
Vient ensuite un chapitre très intéressant dans lequel l'auteur nous expose un cahier des charges de l'outil parfait, en mettant notamment à l'épreuve VI, Emacs, JEdit et TextMate.
En résumé, c'est un excellent livre qui regorge de bons conseils. J'aurais pu lui mettre cinq étoiles mais je suis un peu resté sur ma faim dans la seconde partie du livre, mais cela n'enlève en rien la qualité des informations condensée dans les 200 pages du livre.
Je ne peux que vous recommander d'aller visiter le site de l'auteur ainsi que le Wiki dédié au livre.

À mon avis un ouvrage à lire absolument pour comprendre les concepts objets, avant de parcourir des ouvrages plus spécifiques du genre "Object-Oriented Design in Java" ou "Thinking in C++". Même si les exemples dans cet ouvrage sont écrits en java, les explications sont applicables a tous les langages OO (C++, C#, ...)

Ce livre donne les "clés" pour modéliser et implémenter un logiciel dans un langage Objet. Une mention spéciale pour le chapitre 6 où l'auteur fait l'analyse et la conception d'un jeu de black-jack en partant de la règle du jeu (description textuelle) pour finir aux diagrammes UML en utilisant la méthode des CRC-Cards.

Un très grand nombre de contributeurs ont écrit un chapitre pour ce livre. On observe une progression très bien réalisée dans la table des matières à partir de l'analyse de code réel jusqu'à des abstractions.
Les domaines étudiés sont très différents, d'un code de tri au design d'un langage (enfin, pour cette partie là, j'ai trouvé le chapitre un peu creux...), en passant par le débuggage, ... On en trouve pour tous les goûts.
Naturellement, écrire un code "beau" repose toujours sur les mêmes astuces en réalité. Souplesse, robustesse et rapidité en dernier lieu. Pour cela, les design patterns sont naturellement mis en avant (à la fin du livre, avant on parle d'autres choses), ainsi que les meilleurs algorithmes permettant de résoudre un problème précis.
On peut donc dire que le contenu du livre existe déjà un peu partout, mais c'est faux. Celui-ci se construit sur l'expérience de plusieurs dizaines de programmeurs de talent. On mélange dans le même ouvrage tout ce qui fait un code qu'on peut qualifier de beau. Traditionnellement, on ne parle que de l'architecture d'un côté et des bons algorithmes de l'autre. Ici, on est à la limite entre les deux. Pour aller plus loin, il faudra naturellement lire le Cormen pur l'algorithmie et un livre sur l'architecture logiciel, mais le but de ce livre n'est pas, à mon sens, de remplacer ces ouvrages, mais d'en faire la liaison.
Ce n'est donc pas un livre de référence dans un domaine, mais un recueil d'expériences et de pistes à explorer quand on est devant un problème d'écriture de code durable.

Si tout comme moi, vous ne connaissez les méthodes agiles que de nom, ce livre est pour vous. Il est très clair, agréable à lire et honnête.
Au fur et à mesure que l'on avance dans la lecture, on sent que les auteurs ont une expérience certaine des méthodes agiles. Ils proposent des moyens qu'ils ont mis en pratique, ils ne cachent pas les risques, et posent même des conditions pour que cela fonctionne.
Pratiquement, ce livre est composée de trois partie :
La première est une présentation des méthodes agiles, sous une forme très intéressante. En effet, au lieu de faire du bourrage de crâne sur des concepts théoriques, les auteurs présentent l'Extreme Programming par le biais de l'intégration d'un nouveau arrivant dans une équipe agile.
L'équipe nous est présentée petit à petit, au fur et à mesure des rencontres que ce nouvel arrivant fait. Le chef d'équipe lui présentant le rôle de chacun, tout en lui laissant la possibilité de poser des questions.
Le genre de question qu'un non initié se poserait réellement.
La seconde partie présente plus en détail les pratiques des méthodes agiles ( Programmation en binôme, Integration continue, Client sur site, .. ). Les auteurs présentent encore une fois des exemples basés sur leur expérience.
Ils présentent aussi les conditions pour que cela marche, et des alternatives si ces conditions ne sont pas réunies.
De plus, chaque pratique ne s'adresse pas à tout les membres de l'équipe, ils ciblent les rôles intéressés en début de chapitre. Et comme une pratique est souvent en relation avec d'autres, dès que c'est le cas, les auteurs proposent un renvoi vers celles-ci.
La dernière partie est un peu plus poussée, et propose les valeurs sur lesquelles se basent les méthodes agiles.
C'est pour moi, un excellent ouvrage, et en tout cas, il m'a convaincu sur les méthodes agiles, et m'a donné l'envie d'essayer.

Bien que pas assez synthétique à mon goût, "The art of Agile Development" reste un ouvrage de référence car il contient de très nombreux conseils et rappels sur les bonnes pratiques à adopter pour effectuer un développement logiciel maîtrisé, en amenant de la valeur ajoutée et en se focalisant sur les individus. Vous y retrouverez une analyse des préceptes du Agile Manifesto, croisé avec le "Manifesto for Software Craftsmanship".
Les auteurs ne se sont pas cependant limités à cette analyse et le livre porte également des conseils issus de leur expérience. Il vous aidera à mieux comprendre ce que représente "l'agilité" en termes d'ingénierie logicielle, ce qu'est XP et les analogies avec les autres approches "agiles" comme Scrum ou le Lean. Il est divisé en nombreux sous-chapitres qui contiennent, pour chaque description de la bonne pratique (presque des patterns parfois), les questions les plus fréquentes sur l'application du principe, les résultats attendus et observables, les contre-indications, ainsi que les alternatives. Très "Open-minded" donc.
Concrètement, vous serez amené à découvrir XP et ses différentes phases (Planning, Analysis, Design et Coding, Testing, Deployment), les rôles nécessaires, des recommandations pour renforcer la cohésion des équipes et l'organisation des bureaux, la maîtrise des espaces d'information, l'art d'effectuer des rétrospectives et Kaizen efficaces, les Stands-Up meetings, l'intérêt d'une forge logicielle pratique et résolument orientée vers le testing et l'intégration continue, TDD, etc.
Mon avis est ainsi particulièrement positif, et j'aurai certainement l'occasion de relire des parties de ce référentiel. Une lecture appropriée à tout développeur, mais également aux DSI qui souhaitent développer une informatique reposant sur des valeurs très fortes de participation, de confiance, de développement personnel, et de valeur ajoutée logicielle.

On parle Java dans tout le livre, mais chaque conseil est pour tous les langages. De plus, le framework a été porté pour fonctionner avec presque tous les langages. L'approche de Kent Beck est agréable et didactique. On construit vraiment au fur et à mesure, petit pas par petit pas. Le premier exemple est simple, gérer de l'argent dans différentes devises, et ce petit exemple nous mène déjà loin.
En fait, les exemples servent juste à bien nous asséner le principe de Beck, tester en construisant progressivement. Si on a compris qu'on doit toujours tout tester et qu'aucun code ne doit être buggé quand on arrête le travail, on a compris le livre. Ensuite, l'auteur nous donne des astuces, des patterns pour avancer, comme écrire des tests isolés, ne dépendant pas de toute l'architecture afin de ne pas déprimer - important... -, faire des raisonnements inductifs pour généraliser une réponse, ...
Depuis la lecture de ce livre, je me suis mis aux tests. J'avoue qu'avant, c'était la dernière de mes préoccupations. Maintenant, mon code est plus propre - on dirait une pub de lessive, là -, et surtout bardé de tests au cas où j'aurai une modification au niveau de l'architecture à faire - refactoring, et ça arrive souvent -. En même temps, je n'applique pas sa solution à 100%, c'est tout de même très difficile, ça demande du temps d'écrire le test avant d'avoir la solution qui va avec, mais on voit aussi comment on avance, c'est bien

Cet ouvrage a pour objectif de présenter l'ensemble des concepts des architectures orientées services (SOA) en se concentrant sur leurs aspects pratiques. La première constatation est que le livre est bien structuré. Après une présentation générale en quelques pages de SOA, puis ses concepts principaux il se concentre progressivement sur les différents concepts liés à ce type d'architecture. On notera également que l'auteur justifie d'une bonne maîtrise du sujet. .De nombreux exemples tirés de situations professionnelles viennent illustrer l'ensemble des pièges qu'il est possible de rencontrer à la mise en place d'une architecture SOA. L'auteur cherche ici à mettre en avant, pour chaque choix à effectuer, les différentes possibilités en mettant sur la balance les pour et les contres dans un souci constant de neutralité. L'auteur cherche ici à argumenter dans un souci constant de neutralité les avantages et les inconvénients de chaque architecture proposée.
S'il est vrai que cette neutralité nous évite de tomber dans les travers d'une solution présentée comme miracle, sans souci et capable de résoudre tous les maux, il reste cependant qu'au fil de la lecture, on finit parfois par ne plus savoir quel choix serait le plus judicieux dans une situation donnée. En ce sens, cet ouvrage ne peut être considéré comme un guide mais plutôt comme un panorama qui s'adressera essentiellement aux personnes souhaitant se familiariser avec SOA. Il accompagnera ceux qui, ayant jeté leur dévolu sur cette architecture, souhaitent avoir à l'esprit l'ensemble des pièges à éviter. Mais il ne pourra répondre aux attentent de ceux qui tentent de mettre en pratique certains aspects précis d'une architecture SOA. Le titre donné à cet ouvrage "SOA In practice » peut donc induire en erreur.
On pourra reprocher également aux chapitres 2 et 3 de s'appuyer sur l'évolution des définitions Wikipedia pour présenter les concepts de SOA. On regrettera également que, bien que l'auteur nous répète tout au long du livre que les Services Web ne sont pas l'unique moyen d'implémenter des services dans une architecture SOA, on termine l'ouvrage sans avoir une vision claire de ce à quoi peut ressembler un service non web dans SOA. Enfin, bien que l'auteur insiste tout au long du livre que les Services Web ne sont pas l'unique moyen d'implémenter des services dans une architecture SOA, on regrettera de ne pas avoir au final une vision claire de ce à quoi peut ressembler un service non web dans SOA.

Tout d'abord, je préfère les livres aux versions électroniques, c'est comme ça, c'est personnel, mais ça enlève beaucoup du charme - la version papier est plus difficle à trouver, pas dispo sur Amazon, par ex -. On est obligé d'être scotché à son ordinateur au lieu de pouvoir en profiter dans le train, ... Ensuite, c'est un catalogue de patterns, comme indiqué dans la description, donc on a le droit 23 fois à la même chose, dans le même ordre, juste le contenu qui change, c'est parfois un peu difficile à lire d'une traite, d'où le concept de catalogue !
Passé la première impression un peu limite, on se dit que c'est bien fait. 3 grandes parties pour classer les patterns les plus utilisés. En plus, on commence par un exemple concret où on utilise plusieurs de ces patterns. Enfin, on dit plutôt qu'on peut utiliser tel pattern pour faire ceci ou cela, c'est vrai que c'est pas la même chose. Mais pour celui qui n'a jamais entendu parler de pattern, c'est important de voir comment on peut les utiliser.
Chaque pattern est agrémenté d'un diagramme UML pour savoir comment ça se passe. Mais on est pas obligé de connaître l'UML, un rapide récapitulatif est aussi disponible sur cxe qui sera utilisé dans les diagrammes, ce qui fait que j'ai même compris ce qui se passait Un exemple d'implémentation est à chaque fois donné, en C++ et en SmallTalk, ça change du sempiternel Java. Y'a pas que ses programmeurs qui peuvent bénéficier des patterns... Et aussi une petite explication sur ce qu'on fait et comment, c'est bien aussi.
Avec un peu de recul, ce catalogue est bien. Il n'a pas vieilli, la preuve d'une qualité de son contenu, ces patterns sont toujours encore utilisables et à utiliser. D'autres existent aussi, les auteurs en sont bien concients, et c'est bien, ils ne considèrent pas avoir la science infuse. Donc pour conclure, c'est sans doute LA référence en terme de pattern, même si on aurait préféré une version papier.

Une sorte de suite à Refactoring de Martin Fowler, puisque tous les processus décrits ou presque utilisent des patterns décrits dans ce livre. Les différentes catégories sont aussi bien séparées l'auteur n'oblige pas à aller jusqu'aux patterns décrits dans Design Patterns, on n'en a pas toujours besoin - vive les surpopulations de singletons par exemple -. Selon ce qu'on a à faire, plusieurs solutions sont utilisables, plus ou moins loin de ces patterns.
Le code proposé est du Java, il est parfois un peu difficile de faire le lien avec d'autres langages orientés objet offrant des outils différents. En revanche, pour chaque refactoring to pattern, un petit topo sur pourquoi et comment faire est proposé. Ces petites étapes permettent de s'en sortir. L'introduction du livre est très importante, par exemple, un accent y est mis sur l'élémentarité des étapes, simples de préférence.
Comme précisé ci-dessus, ce livre fait la part belle à Fowler, le livre fait aussi partie de la collection Fowler. Ensuite est-ce que c'est pour la signature Fowler qu'il y a autant de référence au livre Refactoring ? Non, ce dernier est une base, un fondement que Refactoring to Patterns utilise pour aller plus loin, plus vite. Ce que Refactoring ne pouvait aborder par manque de place, Refactoring to Patterns l'aborde et va au bout. Sans imposer, juste en proposant.

Une référence, voilà ce qu'est devenu ce livre pour moi. Le catalogue de patterns - parce que je considère ces petites étapes comme des patterns - est dense, presque exhaustif - je suis sûr qu'on pourrait en trouver d'autres -, mais il y a les patterns les plus simples et les plus utiles. Comme le texte au dos du livre le dit, certaines étapes semblent vraiment trop simples, et c'est le cas. Tout le monde sait inliner une fonction. On a un peu plus de mal en extrayant une méthode d'une autre méthode, mais de manière générale, on serait tomber tôt ou tard sur ces patterns.
L'avantage du livre, ce n'est pas de nous redire ce qu'on sait, c'est de nous montrer une étape à laquelle on n'a pas pensé et qui résoud le problème qu'on a. Enfin, c'est pas un problème, c'est juste que le code commence à sentir mauvais. D'ailleurs, l'odeur du code, c'est une des caractéristiques de ce livre, Martin Fowler nous donne des pistes pour apprendre à reconnaître l'odeur d'un code. Ca m'a fait sourire de se dire que le code avait une odeur. Et c'est vrai que lorsqu'on regarde le code qu'on faisait quand on était plus jeune, on se rend compte qu'il pue.
Un autre point de ce livre, c'est qu'il met l'accent sur les tests, principalement unitaires. Et effectivement, pour un livre qui parle de refactoring, c'est important. Il faut bien que le code après modification ait le même effet que sans modification ! L'exemple qui est donné est aussi explicite, on utilise plusieurs méthodes au fur et à mesure de l'avancement de la procédure, c'est très intéressant de voir comment ça marche.
Enfin, le code est du Java, mais pour quelqu'un qui connait le C++, ça passe sans problème. Chaque opération est suffisemment simple pour être presque identique à son équivalent en C++. Enfin, un petit topo sur ce qui existait à l'époque sur le refactoring est donné, et même s'il est un peu dépassé, ce topo est très instructif.