Note de lecture : Modular java, par Craig Walls

Note: 8 ; Vraiment un excellent tutorial, sur OSGi d’abord, puis sur Spring DM ! Bravo !

Craig Walls est déjà l’auteur de l’excellent « Spring in Action ». Je connaissais donc déjà ses talents d’auteur. Il n’a pas failli à sa réputation ici. En fait, je pense qu’il a fait encore mieux ! Le challenge de réussir ce tutorial en 200 pages, se partageant entre OSGi « brut » d’abord, puis ensuite sur Spring DM y est aussi pour beaucoup.

Dès le premier chapitre, on est séduit par la limpidité de la présentation d’OSGi et de l’intérêt d’un approche « composant runtime ». On n’en a que d’avantage l’eau à la bouche pour attaquer la première partie, celle qui présentera le développement OSGi sans Spring, soit 90 pages sur 4 chapitres.

Très intelligemment, le chapitre 2 présente la construction d’un bundle OSGi minimaliste, mais où l’on construit toute la plomberie à la main ! C’est bel et bien la meilleure façon de comprendre cette plomberie. Jouer avec la console OSGi (un outil dont la compréhension est indispensable), est le complément naturel de cette approche. C’est l’occasion d’aborder les différentes implémentations d’OSGi et principalement les deux implémentations open source : Equinox et Apache Felix. L’auteur penche pour Equinox, c’est visible.

Le troisième chapitre peut paraître curieux, car on y découvre peu de choses sur OSGi ! L’auteur nous y présente l’architecture de l’application que nous allons construire, mais surtout il introduit les outils PAX construct, une boit à outil qui va vite s’avérer indispensable pour construire et tester les bundles OSGi.

Les chapitres 4 et 5 abordent enfin la création de différents types de bundles et le développement de services. Au bout du 5ème chapitre, nous sommes devenus opérationnels pour construire des bundles OSGi qui coopèrent ensemble. Toute cette première partie constitue un tutorial remarquable.

La seconde partie va aborder l’utilisation de Spring DM afin de faciliter le développement de bundles OSGi en en masquant la complexité. 3 chapitres et 65 pages suffisent à la tâche. Le chapitre le plus important est d’ailleurs le premier de cette partie (le chapitre 6) car il explique comment la plomberie du bundle est prise en charge par le contexte Spring et l’injection de dépendances inter bundles !

C’est aux « web bundles » que ce se consacre le chapitre 7. Je l’ai trouvé personnellement assez complexe, car il a trait à beaucoup de problématiques de configuration, pour déployer des bundles sur Tomcat et sur Jetty et pour régler des problématiques de listener http et autres… Disons que c’est un mal nécessaire (ou incontournable).

Le chapitre 8 revient au développement et nous présente la création de fragments. Je pense que cela aurait pu être présenté en première partie, mais ça marche aussi ici ! Petit détail, cela ne profitera qu’à ceux qui développent avec Equinox. Dommage pour ceux qui ont choisi Apache Felix !

La dernière partie, constituée de deux chapitres, adresse le passage en production : déploiement, administration, configuration et suivi d’exploitation. Tout cela est remarquablement expliqué en peu de pages.

Ce livre ne vous donnera peut-être pas des informations complètes sur tout ce que vous pourriez savoir sur OSGi et Spring DM, ce n’est pas une bible ! Mais je pense que c’est sa qualité première, il se débarrasse du superflu pour se concentrer sur l’indispensable et nous mettre le pied à l’étrier du développement avec Spring DM. Un tutorial, un vrai. La mission est remplie à 100% ! Je conseille sans réserve ce livre qui fut une bonne surprise.

modular-java-pragprog

Référence complète : Modular java, creating flexible applications with OSGi and Spring – Craig Walls – The Pragmatic Bookshelf 2009 – ISBN: 1-934356-40-9 ; EAN: 978 1934356 40 1

Modular Java: Creating Flexible Applications with Osgi and Spring


http://www.goodreads.com/book/add_to_books_widget_frame/1934356409?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : UML pour les décideurs, par Franck Vallée

Note : 4 ; Le cycle en « Y » n’est pas mort, il bouge encore… « UML pour les vieux » aurait-il été un meilleur titre ?

UML peut-il réellement être un outil pour le décideur. Personnellement j’en doute, bien que la finalité d’une notation soit d’être un vecteur de communication. Le pari est en tout cas ambitieux, voyons s’il est réussi, et pour se faire passons en revue le contenu du livre. Celui-ci compte 270 pages découpés en 8 chapitres formant 2 parties : « UML en puissance » et « Déployer UML dans l’entreprise ». On peut en conclure que l’on va avoir des chapitres relativement gros, disons selon la tendance française plutôt que selon le mode américain.

Le premier chapitre, UML et le génie logiciel, est un tour rapide d’UML. Il compte tout de même 65 pages et fait un tour très complet de la notation UML 2. Elle replace l’utilisation de la notation dans une gestion de projet classique « phasée » séparant distinctement l’analyse de la conception. Ce dernier point était l’un des axes prépondérants de l’approche en « Y » que je dénie complètement.

Au chapitre 2, on se concentre sur les cas d’utilisation. Je n’y ai rien trouvé de neuf, à part 6 pages sur les 50 de ce chapitres dédiés au ROI à partir des cas d’utilisation.

Le chapitre 3 couvre aussi 50 pages et est dédié à l’utilisation d’UML en conception. Enfin quand je dis en conception, je devrais dire en implémentation, car on court-circuite joyeusement une vraie conception objet, pour passer directement de l’analyse à sa projection sur l’infrastructure technique. Je ne suis pas un grand supporter du phasage, mais je ne le suis pas non plus de l’approche consistant à tartiner la coloration technique sur un modèle d’analyse ! Pas convaincant !

Le chapitre 4 nous parle processus, organisation du projet et rôles. Effectivement, on y ressort le cycle en « Y ». Je croyais pourtant qu’il était mort, mais il semble qu’il bouge encore…

Le chapitre 5, le premier de la seconde partie est très court : 10 pages. Son but est de formuler les objectifs de changements avec UML. Ca c’est le titre du chapitre. Dans la pratique, je n’ai pas compris le but de ce chapitre.

Le chapitre 6 « méthodes et outils » couvre sur 40 pages la question des différents types de cycle de développement. C’est relativement intéressant (XP y est rapidement classé comme un procès pour les petits projets ne posant de toute façon as de problème). L’affinité de l’auteur pour Unified Process et MDA arrive assez rapidement.

Le chapitre 7 « changer pour UML » nous apporte une analyse assez précise en terme de coût et d’impact du passage sur UML. Enfin le chapitre 8 « aider la prise de décision » conclut sur 6 pages en disant qu’UML, c’est bien.

Je connais Franck Vallée et l’apprécie. Mais je trouve que ce livre apporte peu de choses, surtout en 2005. Les points différenciant par rapport à un ouvrage pur UML sont peu évident. En tout cas ils ne m’apparaissent pas. Le focus méthodologique qui y est décrit me replonge dans un monde ancien, sclérosé et poussiéreux avec lequel je ne veux plus rien à voir. Quand à la relation avec le titre elle est presque inexistante. Je dénombre environ 20 pages du livre qui semblent à mon avis adresser le sujet.

Pour ce qui est d’évoquer UML de manière plus large (si l’on oublie la question du « processus pour les vieux »), eh bien Franck Vallée écrit très bien, sa description d’UML est claire et pertinente. L’analyste pourra lire cette prose avec profit.

uml-decideurs

Référence complète : UML pour les décideurs – Franck Vallée – Eyrolles 2005 – ISBN : 2-212-11621-7

UML pour les décideurs


http://www.goodreads.com/book/add_to_books_widget_frame/2212116217?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Ruminations on C++, par Andrew Koenig & Barbara Moo

Note : 6 ; Amis touristes, ce livre n’est pas pour vous !

Au premier abord, l’ouvrage n’en impose pas trop, le volume semble modeste sans parler du design de la couverture façon vache qui rit. Mais rapidement, on se rend compte déjà que la finesse du papier nous avait dissimulé ses 370 pages.

Ce livre qui est plutôt un recueil, est un compilation des articles d’Andrew parus essentiellement dans JOOP (Journal of Object-Oriented Programming), mais aussi dans C++ Report et dans C++ Journal pour une petite partie d’entre eux. C’est donc dans une sélection de 98 articles publiés sur une durée de 8 ans que les auteurs ont fait leur choix. Ils sont regroupés sur 32 chapitres, pardon 33 car Andrew Koenig, en bon informaticien commence par un chapitre 0 ! Ces chapitres sont eux-mêmes rassemblés en 6 parties.

La première partie « motivations » présente assez peu de code. L’auteur y développe son crédo personnel envers C++, essentiellement en le comparant au langage C auquel il donne clarté et sécurité. Le style y est aussi plus personnel que dans les parties suivantes.

La seconde partie « classes and inheritance » est le prétexte pour revisiter les grands thèmes du C++ classique : héritage, polymorphisme et surcharge, constructeur copie, virtualité, etc… Nous avons même droit à une petite variation sur le thème du smart pointer. Il s’agit plus de l’usage du paradigme objet du C++ que d’un cours sur l’orienté objet.

La troisième partie est consacrée aux templates. En fait, il est consacré à la compréhension de la STL. Cela commence doucement par les conteneurs, puis par les itérateurs, les algorithmes et fonctions pour finalement aborder les adaptateurs. Ce n’est pas à proprement parler un tutorial STL, mais plutôt un apprentissage par la construction de ses mécanismes fondamentaux.

La quatrième partie se focalise sur les principes de conception des librairies. Honnêtement, j’ai trouvé cette partie difficile à aborder, les points fondamentaux des auteurs m’ont paru confus, ainsi que le message d’ensemble.

Si elle est courte, la cinquième partie n’est pas la moins intéressante. Intitulée « techniques » c’est en fait une boite à outil à utiliser pour débugger, tracer, gérer des clusters d’objets, etc…

La sixième partie « wrap up » conclut l’ouvrage. Elle est très courte, il y a peu à en dire.

Ce livre à recommander aux personnes fortement motivées pour approfondir leurs connaissances sur le C++. Même s’il prétend le contraire, la prose d’Andrew Koenig n’est pas du Scott Meyers. Le style est plutôt sec, parfois même un peu confus. Mais le niveau de technicité est au rendez-vous, bien qu’il faille quand même un bagage minimum assez conséquent en C++ pour tenir la distance… Le texte a été remanié afin de ne pas donner une impression trop forte de juxtaposition d’articles. C’est gagné de ce côté, même si tout n’est pas lisse. Les parties plus anciennes ont été remises au goût du jour, c’est à dire celui du pré standard 98, même si les auteurs ne cherchent pas à tout prix à dégainer les dernières nouveautés du langage. Il préfèrent se concentrer sur le « core langage ».

Quel que soit votre niveau, il serait surprenant que vous n’en retiriez pas quelque chose. A une exception près : je déconseille fortement aux débutants !

ruminations-c++

Référence complète: Ruminations on C++ – Andrew Koenig & Barbara Moo – Addison Wesley 1997 – ISBN: 0-201-42339-1

Ruminations on C++: A Decade of Programming Insight and Experience


http://www.goodreads.com/book/add_to_books_widget_frame/0201423391?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Optimiser SQL Server, par Rudi Bruchez

Note: 7 ; Pratiquement une révélation !

Utiliser efficacement une base de données telle que SQL Server 2005 nécessite d’une par une compréhension fine de son mode de fonctionnement et de ses structures de données, mais également une connaissance des outils mis à disposition. Livrés en vrac, cet ensemble est presqu’inutile car il faut être guidé au sein de cette pléthore.

Le livre de Rudi Bruchez nous livre incontestablement les clés adéquates. L’auteur est clairement très qualifié pour aborder le sujet et il aborde à la fois la base de données et ses outils en nous gratifiant de liens vitaux pour explorer les sujets plus en profondeur. Je dois dire que nous devons nous estimer satisfaits qu’un ouvrage de bonne teneur soit écrit, en français, c’est rare ! Il ne faudra pas non plus s’attendre à une lecture captivante, le style reste technique, mais abordable la plupart du temps (j’ai toutefois décollé de temps à autre, je l’avoue…).

Le contenu du livre est découpé « à la française », c’est-à-dire avec des chapitres assez gros : les 312 pages de l’ouvrage sont découpés en 9 chapitres seulement. Mais on a vu pire.

Après un premier chapitre purement introductif, le chapitre 2 aborde l’architecture de SQL Server. Ce n’est pas une montée en puissance graduelle, car ce chapitre est le plus difficile de l’ouvrage !

Au chapitre 3, on aborde l’architecture matérielle : configuration mémoire, exploitation des processeurs, virtualisation. On y découvre déjà beaucoup de pistes pour améliorer les choses ! A contrario, le chapitre 4 n’a pas grand-chose à faire ici : structuration, formes normales … ouste ! Du balai !

Les chapitres 5 et 6 sont le cœur de l’ouvrage, car ils abordent l’analyse de performance et l’optimisation et l’utilisation des index. A ne pas rater !

Le chapitre 7 traitant des verrous a un double intérêt. Tout d’abord fixer avec précision des notions sur les transactions, ensuite donner des pistes d’optimisation sur du code transactionnel. J’avoue qu’en l’état ce n’est pas sur cela que je me focalise !

Les chapitres 8 et 9 donnent des clés pour améliorer du code SQL … ce qui est intéressant quand on fait de gros traitements en SQL. Ce que j’évite !

Bref, si vous êtes dans mon cas (vous vous sentez débutants avec SQL server et voulez vous améliorer), ce livre est pour vous !

optimiser-sqlserver

Référence complète : Optimiser SQL Server : Dimensionnement, supervision, performances du moteur et du code SQL – Rudi Bruchez – Dunod 2008 – EAN : 978 2 10 051863 0

Optimiser SQL Server : Dimensionnement, supervision, performances du moteur et du code SQL


http://www.goodreads.com/book/add_to_books_widget_frame/2100518631?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

OSMM, un modèle de maturité pour l’open-source

Je publie ici ce court papier que j’avais écrit en 2005. Les reflexions qu’il soulève restent pertinentes. Le mouvement ope-source ayant pris beaucoup plus d’ampleur depuis 7 ans, il y aurait certainement des choses à modifier ou à ajouter…

Voici également le lien vers ce papier dans Issuu

Note de lecture : Mastering the Requirements Process, 2nd edition par Suzanne & james Robertson

Note : 8 ; Toujours une référence incontournable sur la gestion des exigences.

Quel meilleur moment pour faire la note de lecture de la seconde édition d’un livre, que la parution de sa troisième édition ? Je connais la réponse : n’importe quel moment tant qu’il précède la sortie de ladite troisième édition ! Toutefois c’est bien maintenant que je la livre. J’avais fait de la première édition mon « book of the year » 1999, voyons ce qu’il en est de celle-ci (la note de lecture de la troisième édition viendra bien un jour, mais plus tard).

Par rapport à la première édition, il est passé de 400 pages à 550 ! C’est une inflation importante pour moi qui apprécie la brièveté du propos, même si il est de qualité. Le grammage supérieur du papier augmente même cette impression de volume supérieur. Sur ces 150 pages supplémentaires, 80 vont au texte principal, mais 70 viennent grossir encore plus les annexes. Je trouvais déjà les annexes de la première édition conséquentes, mais nous avons désormais deux parties dans ce livre : le texte principal long de 365 pages en 15 chapitres et les annexes  au nombre de 4 qui couvrent près de 200 pages. Idéalement il aurait fallu faire deux livres mais le second ne se serait probablement pas ou peu vendu. Quoi qu’il en soit je ne rentrerais pas dans le « manuel de référence Volere » dont j’avoue qu’il ne m’intéresse guère.

J’ai toujours trouvé qu’une manufacture de qualité associée à une mise en page soignée augmentait le plaisir de la lecture. Cela se démontre ici. Outre le texte de qualité, les auteurs utilisent intelligemment et sans excès les marges pour des citations, de l’iconographie ou des références bibliographiques.

Cette seconde édition se démarque de la première par la prise en compte de l’approche agile. Tout d’abord cela se traduit par des paragraphes dédiés à trois profils de projets en introduction de chaque chapitre :

  • Les projets « rabbit » : traduisez, les projets agiles.
  • Les projets « horse » : ce sont les projets standard de l’industrie, itératifs ou « en V », s’appuyant sur une certaine dose de documentation.
  • Les projets « éléphant » : ce sont les projets lourds, impliquant généralement de grosses équipes sur de longues durée de temps et s’appuyant sur une documentation lourde.

L’approche et le point de vue des auteurs par rapport à l’agilité est particulièrement pertinent. Ils se félicitent de l’arrivée d’une approche mettant l’emphase sur le produit plutôt que sur les artefacts, et apprécient l’idée d ‘éliminer une documentation quand elle n’est pas nécessaire. Toutefois cela ne doit pas exclure de procéder avec intelligence par rapport à la compréhension du besoin, ni de réfléchir avant d’implémenter ! Voici un ouvrage qui devrait prendre place sur l’étagère du product owner et même en fait du développeur agile ! Pourtant, si les auteurs considèrent que Volere ne dit pas être suivi comme un processus prescriptif, mais plutôt comme une « check list », lire le texte et l’appliquer avec ce point de vue en tête demande pas mal de maturité.

Venons-en à la matière première : le livre, constitué de 15 chapitres couvrant 360 pages (pour le partie principale). En moyenne, les chapitres sont un petit peu plus long que ce que j’apprécie généralement. Mais la prose est agréable, donc ça va.

Passons rapidement sur le premier chapitre introductif qui balaye rapidement la problématique de la capture des exigences et ce que sont les exigences fonctionnelles et non fonctionnelles. C’est une bonne mise en bouche et le sujet est bien traité. Le second chapitre est quand à lui une introduction à Volere, le processus imaginé par les auteurs. On balaye en diagonale la « big picture », c’est en quelque sorte la table des matières de ce qui suit.

Le « project blastoff » proposé par les auteurs n’est probablement pas l’approche de démarrage de projets que je préfère. Elle ne met pas tellement l’accent sur la vision et le positionnement markéting. Mais de nombreux démarrage de projets sont simplement bâclés. En suivant ce guide qui couvre honnêtement les différentes facettes de ce démarrage, vous avez toutes les chances de faire un travail tout à fait honorable, alors…

L’une des particularité de l’approche Volere est la façon dont elle articule la capture du besoin sur les cas d’utilisation métier et les évènements métier. Le chapitre 4 est consacré à ce sujet. J’aime bien la façon dont cela est abordé ici. Un chapitre à ne pas rater car il conditionne la compréhension de nombreux autres.

James et Suzanne Robertson ne parlent pas de capturer les exigences, mais d’aller à leur pêche. C’est l’objet du chapitre 5. Il y a des techniques pour cela, les auteurs n’en évoquent pas moins de 16 (certaines mieux détaillées plus tard). Autant pour ceux qui pensent qu’aller se promener avec son calepin sous le bras est tout ce qu’il est nécessaire de savoir. En fait les techniques évoquées, brièvement mais efficacement, sont des invitations à creuser ces sujets via les références proposées. Le chapitre le plus riche du livre, sinon le meilleurs.

Le chapitre 6 complète le précédent en évoquant les scénarios. Si cela vous semble rappeler les cas d’utilisation, c’est normal. Mais ce n’est pas un mal. Le chapitre 7 complète les deux précédents en clarifiant la notion d’exigence fonctionnelle et surtout en s’appliquant à différencier le besoin de la solution.

Les exigences non fonctionnelles sont abordées au chapitre 8. Les auteurs en proposent une taxonomie. Celle-ci en vaut bien une autre. Quoi qu’il en soit le sujet est bien couvert.

Avant même que TDD ne soit à la mode, Volere évoquait la notion de « Fit criterion » pour les exigences. Le chapitre 9 expose cet aspect et explique comment ces « fit criterion » aident à préciser et lever les ambigüités des spécifications.

Le chapitre 10 aborde la question de la chose écrite. Volere propose un Template de rédaction du besoin, ainsi que le « Shell » qui conviendra mieux aux agiliste. Pas le chapitre le plus passionnât du livre, à l’exception de la partie consacrée au « Shell ».

Ecrire les exigences ne suffit pas. Elles peuvent et doivent être revues (même si elles ne sont pas écrites). Le « quality Gateway » du chapitre 11 traite cet aspect. A ne pas rater.

Le prototypage des exigences abordé au chapitre 12 n’est probablement pas le texte de référence sur le sujet. Mais au moins est-il abordé. A contrario, le chapitre 13 sur la réutilisation des exigences est le moins convainquant du livre. Je ne l’étais déjà pas beaucoup en 1999. Je le suis moins encore maintenant. Mais peut-être que je manque encore de maturité…

Le chapitre sur la revue des exigences complète le « quality Gateway » du chapitre 11, il aurait dû le prolonger dans le plan du livre.

Le livre se conclut par un chapitre 15 qui fait une sorte de « wrap up » du livre, de manière un peu désordonnée je dois dire. J’ai cependant bien aimé la référence aux rétrospectives.

Même si la note du livre baisse un peu, celui-ci reste une de mes références principales sur le sujet. La qualité du contenu et de la rédaction, la richesse de la matière en font une référence que je recommande très fortement. La prose a été modernisée à plusieurs égard. Pour celui ou celle qui désire faire de l’analyse son métier, ce sont là d’excellentes fondations, d’autant que ce livre ouvre sur de nombreuses autres références.

mastering-reqt-proc-2edt

Référence complète: Mastering the Requirements Process, 2nd edition – Suzanne Robertson & James Robertson – Addison Wesley 2006 – ISBN : 0-321-41949-9

Mastering the Requirements Process


http://www.goodreads.com/book/add_to_books_widget_frame/0321419499?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on