Note de lecture : Practical Apache Struts2, par Ian Roughley

Note : 4 ; Raisonnable, mais c’est bien tout.

Ce livre cible, sans surprise, le développeur Java d désirant s’initier à Struts 2. Il ne nécessite pas vraiment de connaissances préalable du développement d’application Web en java, car on est en gros pris en main dès les tâches les plus simples. Voyons ce que le livre à a nous proposer. Tout d’abord, il est de taille moyenne, avec 326 pages découpées en 10 chapitres, un départ raisonnable, avec un découpage raisonnable.

Le premier chapitre est clairement superflu, il traite de généralités sur le Web 2.0, les principes comme « convention over configuration », l’injection de dépendances, etc. Passons vite !

Le second chapitre est destiné à nous mettre le pied à l’étrier. La moitié du chapitre est consacré … à Maven 2, tandis que le reste évoque les différents fichiers de configuration nécessaires pour commencer le projet. Mais c’est un peu confus.

Le 3ème chapitre est plus théorique, et finalement un peu intéressant : il décrit la cinématique de Stuts 2 et son architecture.

Le 4ème chapitre (on est déjà à la page 70) marque le réel début du livre avec la description de l’architecture d’une application Struts 2. Voulant tout décrire, l’auteur s’égare hélas parfois un peu sur MySQL, le développement agile ou Hibernate. En fait l’objectif est de permettre d’appréhender la globalité de la construction de l’application, pas seulement Struts 2.

Au chapitre 5, on aborde tout ce qui concerne la manipulation de données : modèle, actions, updates, templates, etc. C’est un gros chapitre avec 55 pages.

Les chapitres 6 et 7 abordent des aspects plus avancés de struts : Les workflows (chapitre 6) et la sécurité (chapitre 7).

Le chapitre 8 revient sur un problème récurrent : l’implémentation de recherches et l’affichage paginé de liste de résultats. Pas grand chose à en dire non plus.

Le chapitre 9 fait état de sujets plus originaux : l’intégration de flux RSS, l’intégration illustré par une intégration Google Maps (et donc du geocoding) et l’appel de Web Services.

Il était incontournable qu’Ajax soit mentionné. C’est chose faite au dernier chapitre. Le toolkit Dojo est intégré à cet effet. Mais curieusement, un exemple d’intégration avec GWT est également montré (mais en 5 pages seulement). Pourquoi faire cela ? Mystère…

Bref, le bouquin fait le boulot. Il n’y a pas de quoi s’extasier non plus. Ce texte ne fera pas de vous un gourou de Struts 2. Pour ma part, j’aurais aimé un texte condense en 200 à 250 pages.

image

Référence complète : Practical Apache Struts2, Web 2.0 projects – Ian Roughley – Apress 2007 – ISBN : 978 1 59059 903 7

Practical Apache Struts2 Web 2.0 Projects

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

En finir avec les estimations ?

Poker, Fibonacci et stock

Aujourd’hui j’aimerais parler d’estimations. D’estimations agiles, bien sûr. Elles n’ont rien à voir avec les estimations classiques. Ou du moins, pourrait-on le croire. Voyons cela !

L’un des points marquants souvent évoqué est que l’estimation n’est pas faite par une seule personne, mais par l’ensemble des membres de l’équipe, afin de bénéficier de la sagesse de la foule. En fait, l’estimation collective est utilisée depuis longtemps dans les approches classiques et est connue sous le nom de wideband Delphi. Il est vrai toutefois que la technique est sous-utilisée, beaucoup de chefs de projets préférant « optimiser » le temps nécessaire aux estimations ou ignorant simplement cette technique !

L’autre élément majeur est l’utilisation d’estimations relatives, décorellé d’une estimation en charge. Une approche déjà utilisée dans le Function Point Analysis. Ici l’approche agile se distingue par l’utilisation d’une échelle de précision adaptative qui a donné lieu aux fameux jeux de carte du planning poker

image

Il reste 2 points à soulever : un point de divergence et un point de convergence avec les approches classiques.

Tout d’abord la divergence. Les approches type Cocomo et FPA tentent d’estimer en comparant les sous-éléments techniques des briques à réaliser. Les briques elle-même étant plutôt de taille importante, d’où la nécessité d’opérer une subdivision. Les approches agiles travaillent aussi par comparaison, mais elles s’évertuent à subdiviser l’élément fonctionnel. Il n’est alors plus nécessaire de décomposer celui-ci en sous-éléments techniques. Bien sûr l’approche agile s’appuie sur le postulat que la solution qui sera retenue va être proche de celle utilisée pour la fonctionnalité référents. Mais cela ne va pas aussi loin que dans le cas d’une décomposition technique qui vérrouille complètement les postulats techniques !

Maintenant la convergence. Il y a bel et bien quelque chose que l’approche classique et l’approche agile appréhendent à l’identique : toutes deux s’efforcent d’évaluer une charge ou une complexité (mais est-ce si différent ?) d’un ensemble de choses à réaliser.

Finalement, la logique de l’estimation agile telle que nous la connaissons ne diffère guère de l’estimation classique : on nous demande de réaliser des pans de fonctionnalités pour lesquelles on nous demande d’estimer si c’est gros ou si c’est petit… Une question qui devrait nous donner à réfléchir concernant une approche où l’on prétend maximiser la valeur ! On dirait plutôt que nous voilà cernés dans une discussion pour optimiser la main d’oeuvre, ce n’est certes pas la même chose. Il est vrai que les prétentions « d’hyperproductivité » de Scrum vantées par Jeff Sutherland n’aident pas tellement à changer le focus du discours…

Ce qui ne va pas dans cette approche

Il y a un certain paradoxe à travailler en itérations « time-boxée » afin d’optimiser la valeur produite à chaque itération, et estimer la taille des fonctionnalités à délivrer.

D’un côté, le découpage temporel de la planification contraint le temps afin de permettre la mesurer de valeur par unité de temps. Mais de l’autre côté, la manière dont nous appréhendons les tâches nous conduit à focaliser la discussion sur la charge et le plus souvent à trouver des options pour la réaliser à l’économie. L’estimation agile ne nous invite pas à :

  • Rechercher la partie réellement porteuse de valeur dans une fonctionnalité présentée.
  • Découper une fonctionnalité en ensemble élémentaires d’apprentissages et d’hypothèses.
  • Rechercher comment obtenir du feedback le plus rapidement possible sur l’hypothèse la plus importante.

La logique estimative ne nous aide pas tellement dans notre quête de la maximisation de valeur. Mais cela ne s’arrête pas là. Elle est aussi un handicap sur plusieurs sujets :

  • En associant (comme Scrum le fait) l’estimation et l’engagement.
  • En donnant prédominance à la logique de coût et en autorisant de fait celle-ci à devenir un vecteur de priorité.
  • En nous enfermant dans une logique de périmètre (et les fermetures de choix associés).
  • En permettant une logique des « gros morceaux » qui reporte une partie des responsabilités sur l’équipe de développement.

Enumérés ainsi, ces sujets paraissent certainement un peu mystérieux. Ils ne vont pas le rester longtemps, il est temps de nous y attaquer !

Estimation et engagement

Je me suis longtemps battu contre l’idée qu’une estimation n’était pas un engagement. Dans les projets classiques, j’ai beaucoup illustré ce propos avec le cône d’incertitude [1], bien que cette représentation folklorique ait été ensuite un peu secouée par Laurent Bossavit [2].

image

Cette représentation met l’accent sur un facteur important : l’interval de confiance est plus large quand on a peu d’éléments sur le sujet, il se resserre ensuite progressivement en même temps que notre capacité d’extrapoler sur ce sujet s’améliore. Bien sûr, cet effet est beaucoup plus marqué pour les projets classiques et plus spécifiquement pour les projets non itératifs.

Je pensais m’être débarrassé de l’interprêtation « estimation = engagement » avec les projets agiles. Apparemment, pas tout à fait. Car si l’on commence un planning meeting scrum par des estimations, il se termine le plus souvent par une bonne vielle règle de trois qui nous donne l’engagement de l’équipe en fonction de sa vélocité. La traduction française de « commitment » qui peut donner engagement ou implication n’aide pas tellement quand on prend le premier choix. Par ailleurs, les derniers textes sur Scrum ont pris conscience de ce travers et préfèrent parler d’engagement (ou implication) sur l’objectif.

Bref, l’estimation est bien l’outil de choix pour enchainer l’équipe au banc de rame. Il faut dépoter de la fonctionnalité, la valeur de cette charge (ou de cette complexité, peu importe) n’est pas le sujet. On est bien dans une logique à l’ancienne !

Quand c’est pas cher, c’est prioritaire !

Prioriser n’est pas un acte facile. Du moins en principe. C’est la ligne d’arrivé d’un processus intégrant des dimensions telles que stratégie d’entreprise, opportunités marché ou développement client. Il n’est pas rare que ces tableaux de bord soient flous voir inexistant. Pourtant il faut prioriser.

C’est souvent dans ces situations qu’intervient le « si je n’ai pas d’estimation, je ne peux pas prioriser ». Ce n’est pas illogique de chercher à prioriser en terme de ROI simplifié (valeur/coût). Mais ça l’est d’éliminer le terme valeur ou de normaliser en prétendant que « tout a la même valeur », signe que quelqu’un ne fait pas son travail…

A partir de là, le travail de priorisation devient une pantalonnade allant de « on va commencer par ça, c’est pas cher » au marchandage du type « je ne comprend pas pourquoi c’est si cher… ».

image

Là encore, on aboutit hélas parfois à des interactions qui ne sont pas vraiment différentes de ce que l’on faisait avant…

Une affaire de périmètre

L’estimation, qu’elle soit en charge ou en complexité, nécessite que l’on arrête un certain nombre de postulats. Ce faisant, on arrête très tôt dans notre processus de conception les options que nous aurons choisi. Du moins, on ne les fixent pas s’il s’agit d’estimations, mais si l’on parle d’engagement…

C’est bien dommage. Car l’adaptabilité devrait être un trait dominant des projets agiles ! En réalisation, cela passe par des pratiques telles que les options réelles [3] ou le « set-based design » [4], [5] et [6]. Ce n’est pas strictement impossible de changer son fusil d’épaule en cours de route, mais les discussions gravitant autour des estimations de taille rendent cela bien plus difficile…

Au-delà des estimations que l’on fait pour l’itération, il y a celles concernant la totalité du projet. Car le plus souvent il faut en passer par là. A moins que le projet fasse l’objet d’un financement récurrent ou qu’il soit en autonomie de financement (ce qui revient à peu près au même), les décideurs ont besoin de savoir quelles sommes devront être engagées sur le projet. C’est normal. Là encore, l’outil ad-hoc est l’estimation. Mais il y a quand même deux façons d’appréhender cela.

On peut faire ça à l’ancienne : on prend le backlog, on met des chiffres en face de chaque élément de backlog et c’est notre feuille de route. Bravo : notre enfermement dans des postulats vient d’atteindre un nouveau niveau. Nous voici prisonniers dans notre périmètre de réalisation.

image

Oh bien sûr on nous proposera « d’accueillir le changement » car on est dans un projet agile. Mais dès que le vent tournera, on verra resurgir le chiffrage initial. Dans ces conditions autant contrôler les changements à l’ancienne, via un « change control board ». De toute manière, de tout ceci émanent des effluves pas vraiment neuves. Et utiliser des cartes de planning poker pour cela n’y change rien !

L’autre méthode consiste à utiliser le chiffrage initial pour dimensionner une enveloppe de financement … puis oublier ce chiffrage pour concevoir et réaliser le produit de manière réellement émergente, en exploitant à chaque itération les connaissances acquises.

Découper, ça c’est votre affaire

Si les approches agiles et Scrum en particulier [7] promeuvent le découpage fin des fonctionnalités, elles ne mettent pas réellement en place de contraintes en ce sens, si ce n’est la taille des itérations ! Mon propos n’est donc qu’une fonctionnalité ne doive pas dépasser une itération (j’ai hélas vu des équipes mettre jusqu’à 3 itérations pour produire une « story » !), non ce découpage doit être fin, bien plus fin.

image

Mais ça ne vient pas tout seul.

En fait, sans la motivation appropriée, il est bien plus aisé au product owner de garder les fonctionnalités à grosse maille, souvent en arguant « qu’il faut tout, de toute façon ! ». Si c’est plus facile de découper pour l’équipe de réalisation, qu’ils le fassent ! Dans le registre lâche, j’ai même entendu parler de « détail d’implémentation » !

Je ne vais pas débattre ici des vertus du découpage des fonctionnalités pour les projets agiles. Mais la logique d’estimation de taille, si elle ne nuit pas ici, n’est pas non plus d’une grande aide.

Ma véritable estimation agile

Assez ronchonné sur les pratiques d’estimation ! Si mes récriminations doivent servir à quelque chose, c’est à comprendre ce que je veux obtenir d’une véritable pratique d’estimation « new style » !

  • Pouvoir me focaliser sur la valeur lorsque l’on évalue la priorité des fonctionnalités. Et pour cela, il ne faut pas que la question de la taille vienne brouiller les cartes !
  • Ne plus considérer le périmètre d’une application comme un ensemble de fonctionnalités à négocier, mais comme un (voir plusieurs objectifs) auxquels je subordonne des hypothèses qui sont autant d’options sur lesquelles je n’ai pas besoin de trancher à l’avance.
  • Et au passage revisiter la notion d’engagement, abandonner les réestimations de reste à faire…

Ouvrons le bal !

Size-boxing

Nous avons évoqué précédemment la technique de priorisation par le ROI. Un grand classique : V/C ; Ainsi à valeur égale, la fonctionnalité la moins couteuse est la plus valable. Sauf que nous avons aussi souligné le travers consistant à sortir la valeur de l’équation. C’est un travers que je comprend aisément : ce n’est pas facile à appréhender la valeur, sauf dans certains contextes précis, et guère plus facile à mesurer quand ce n’est pas directement ou pas uniquement rattaché à une valeur faciale. Nous reviendrons sur cette question de la valeur un peu plus tard.

La solution la plus simple pour éviter le travers est de sortir « C » de l’équation. Il ne reste donc plus que la valeur qui du coup ne peut plus être ignorée. Un seul moyen : standardiser la taille, ou tout au moins travailler avec des tailles de fonctionnalités à réaliser assez semblables ! L’estimation de taille n’est d’ailleurs pas porteuse de valeur en elle-même [8], elle ne sert qu’à nous donner une idée de notre capacité afin de mettre notre processus sous contrôle.

image

Ainsi, de même que nous planifions avec une contrainte de temps (notre itération), mous devrions estimer avec une contrainte de taille. Nos interactions deviennent alors :

  • Comment découper la fonctionnalité souhaité pour la faire tenir dans ma contrainte de taille ?
  • Comment m’organiser en équipe afin d’accommoder cette contrainte de taille ?
  • Quelles décisions de structuration et d’architecture dois-je prendre pour rendre cela possible ?

Subordonner le périmètre au « pourquoi »

Réfléchir à la question du périmètre produit en terme de liste de fonctionnalités et de ce qu’on y ajoute et/ou retranche n’est pas agile. Cela m’oblige à penser en terme de stock et m’en encombrer l’esprit. J’avais évoqué ce point lorsque j’avais parlé du backlog. A ce processus mental qui m’ancre dans mes anciennes idées, je préfère travailler à partir d’objectifs, évaluer et tester mes options relatives à ceux-cis, et itérer. Mais pour ce faire, nous devons nous libérer du mode de pensée qui lie ensemble le budget et la liste des fonctionnalités. Désolé Scrum, mais le « backlog estimé » en est justement l’illustration !

La valeur métier, c’est quoi ?

On le dit et on le repète : l’agile est fait pour se focaliser sur la valeur métier. C’est fort bien dit et en en a plein la bouche, mais c’est quand même rudement abstrait, surtout quand on ne peut pas directement lier le produit ou le projet avec une dimension financière.

Je sors un peu du cadre de mon propos, mais je ne pouvais pas non plus complètement éluder la question.

La valeur ce n’est pas (seulement) des considérations de ROI, il s’agit plutôt d’un cocktail qui intègre plusieurs ingrédients pour former un modèle de valeur [9]. Prenons celui-ci, par exemple :

image

Il s’agit en fait plutôt d’un métamodèle. Il vous invite à construire votre propre modèle, basé sur 3 dimensions :

  • La finalité : elle n’est pas nécessairement purement financière. Il peut s’agir de donner une visibilité ou une image à l’entreprise, de se donner une avance technologique ou de tester un nouveau marché.
  • Les considérations, qui sont les facteurs intrinsèques ou extrinsèques difficilement quantifiables mais influençant vos décisions.
  • Les coûts et bénéfices du projet.

Chaque modèle de valeur est unique, il combine et priorise les éléments construits sur ces 3 axes.

Pour y arriver

Finalement, c’est probablement l’élément le plus facile, car nous avons déjà amené une bonne partie des éléments de réponse.

Tout d’abord, ne plus se servir du budget pour contraindre notre périmètre, mais partir du pourquoi et subordonner le périmètre à ce pourquoi à l’aide d’outils comme l’impact mapping [10].

image

Changer de logique d’estimation : plutôt que d’estimer la taille d’une fonctionnalité de périmètre donné, ré-orientons nos discussions pour estimer le périmètre des fonctionnalités afin de les faire tenir dans une taille donné, en gardant l’objectif dans notre ligne de mire ! C’est là un changement de paradigme fondamental, et il nécessite une façon de faire différente. L’occasion pour moi de développer cela un jour prochain, j’espère !

Changer de logique de processus. Kanban nous apprend à penser différemment: plutôt que de réfléchir en terme de stock, il nous conduit à penser en terme de « slot » de demandes disponibles qu’il suffit d’alimenter par ce qui est le plus prioritaire. Mais Kanban n’est pas une réponse suffisante quand on parle produit, car il focalise sur des questions de « capacité » et de SLA et non sur un objectif et la valeur, des aspects sur lesquels il est agnostique.

Doit-on arrêter d’estimer, comme peut le laisser croire (ou le laisser interpréter) le mouvement « no estimates » ?

Alors l’estimation, c’est mal ?

La réponse (aux deux questions précédentes) est : non ! Nous avons toujours quelque chose à estimer, mais il faut tourner cette estimation dans la bonne direction pour obtenir le résultat que nous voulons. Il faut estimer pour :

  • Individualiser les hypothèses et les relier à notre modèle de valeur.
  • Générer des idées et des options, fonctionnelles ou techniques.
  • Etre en mesure d’avancer par petits pas pour obtenir du feedback rapidement et mettre notre processus de développement sous contrôle.
  • Générer des interactions entre les acteurs du projet.

Nos estimations ne doivent pas nous conduire à :

  • Se débarrasser du problème sur l’équipe de réalisation.
  • Nous conduire à des marchandages entre les acteurs du projet
  • Nous enfermer dans une réincarnation du cahier des charges que l’on ne peut plier qu’à force de négociations.

La route est longue…

Références

[1] : Software Estimation, Demystifying the Black Art – Steve McConnell – Microsoft press 2006 – ISBN: 0-7356-0535-1 ; p. 37

[2] : The Leprechauns of Software Engineering – Laurent Bossavit – Leanpub 2013 ; p. 13

[3] : Commitment – Olav Maassen, Chris Matts & Chris Geary – Hathaway te Brake Publications 2013 – ISBN : 978-90-820569-0-7

[4] : Leading Lean Software Development – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series – ISBN: 978 0 321 62070 5 ; p. 87

[5] : Lean Software Development, An agile toolkit – Mary Poppendieck & Tom Poppendieck – Addison Wesley / ASD series 2003 – ISBN: 0-321-15078-3 ; p. 38

[6] : Implementing Lean Software Development, From concept to cash – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series 2006 – ISBN : 0-321-43738-1 ; p. 160

[7] : Agile Project Management with Scrum – Ken Schwaber – Microsoft Press 2004- ISBN: 0-7356-1993-X ; p. 196

[8] : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149 ; p. 99

[9] : Stand Back and Deliver, Accelerating business agility – Pollyanna Pixton, Niel Nickolaisen, Todd Little & Kent McDonald – Addison Wesley 2009 – ISBN : 978 0 321 57288 2 ; p. 98

[10] : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0

Autres Ressources

Note de lecture : L’EAI par la pratique, par François Rivard et Thomas Plantain

Note : 4 ; Noyé !

J’ai éprouvé de l’intérêt et des regrets à la lecture de ce livre. De l’intérêt tou d’abord : des livres sur l’EAI, il n’y en a finallement pas des masses et ils volent souvent un peu trop haut, évoquant les flux d’échanges B2B et autres intégrations de systèmes. Mais ils évoquent rarement la mise en œuvre pratique : ce n’est pas le cas de celui-ci.

Ici, on est de plein pied dans la réalisation de flux EAI, en l’occurrence avec Vitria. Pour illustrer cela, on dispose d’une étude de cas dont je dois dire qu’elle a juste la bonne complexité, ni trop ni trop peu. Et pour structurer cette mise en œuvre, les auteurs nous proposent une démarche étagée en 4 niveaux :

  • Conception : On modélise le processus métier les tableaux de bord désirés d’un coté et l’architecture technique (y compris les besoins en terme de connecteurs applicatifs de l’autre).
  • Mise en œuvre : Déploiement des configurations EAI et référentiel d’intégration.
  • Réalisation : il s’agit là de l’implémentation des processus métier avec le produit, de la réalisation des tableaux de bord, des échanges B2B et autres mappings.
  • Exploitation : On évoque ici le suivi d’exploitation fonctionnel et technique.

La partie « mise en œuvre » évoque également dans 2 chapitres qui leurs sont dédiés, l’utilisation de Tibco Rendez-vous et de WebMethod.

Alors, pourquoi ai-je noté si sèchement ? Eh bien, hélas, cette belle approche est malheureusement mise à mal par le traitement trop « outil » du sujet. Plutôt que de faire apparaître les traits essentiels, nous sommes noyés sous une avalanche de détails (souvent peu utiles) de réalisation, de copies d’écrans, etc. qui masquent complètement le fond. On ne sait même plus où on en est dans l’approche évoquée ci-desus. Bref, les auteurs auraient dû tailler dans le lard, alléger les détails et réduire le volume du texte des 400 pages qu’il accuse à 250 pages environ.

Dommage !

image

Référence complète : L’EAI par la pratique – François Rivard et Thomas Plantain – Eyrolles 2003 – ISBN : 2-212-11199-1

L'eai Par La Pratique

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

Note de lecture : Lucene in Action, par Otis Gospodnetic & Erik Hatcher

Note : 6 ; Fait le boulot comme attendu, contrat rempli.

Lucene est le grand classique, pratiquement l’unique moteur d’indexation et de recherche full texte en open source, du moins dans le monde Java. Il était normal qu’un volume de la sérié « in action » de chez Manning lui fut consacré. Voyons en pratique ce qu’il en ressort.

Tout d’abord le texte compte pratiquement 400 pages découpées en 10 chapitres. Cela me semble au premier abord plutôt volumineux et constitue des chapitres qui seront en moyenne plus long que ce que j’apprécie en général. Au moins, on va pouvoir les passer en revue.

Le premier chapitre comme il est coutumier dans cette série présente la problématique de la recherche plein texte, la réponse de Lucene et ses alternatives. Le tout est bouclé en 27 pages et c’est une entrée en matières plutôt sympathique.

On rentre très vite dans le dur avec le chapitre 2 consacré à l’indexation. Long de 40 pages il évoque la fabrication d’index et ses différentes variantes : ajout ou mise à jour de documents, indexation en mémoire, verrouillage de l’index pendant l’opération, multithreading, etc.. Chaque fois la chose est illustrée par un fragment de code assez clair et focalisé. On notera également l’approche progressive des auteurs, car on n’évoque pas à ce stade l’intégration de cette indexation dans une application !

Justement, l’intégration dans une application, c’est l’objet du chapitre 3. Long de 32 pages, celui-ci aborde les différentes options de recherche depuis une application. C’est toutefois un peu plus dense et fouillis que le chapitre précédent, entre autre quand on aborde le système de scoring de Lucene qui aurait certainement plutôt mérité son propre chapitre.

Si ces 3 premiers chapitres constituent les briques de base de Lucene, le chapitre 4 consacré aux analyses, donc à la constitution de termes à partir de l’indexation est d’un abord plus ardu. 45 pages lui sont consacrées. L’abord n’est pas simple, le sujet étant présenté de manière un peu trop touffue encore. Là aussi un découpage en deux chapitres en présentant les aspects de base d’abord puis les aspects plus complexes (synonymie, distance, analyse des langues asiatiques, etc…) aurait été bienvenu.

Le chapitre 5 traite des techniques de recherche avancées. Bien que les 45 pages de cette partie en fasse aussi un chapitre conséquent, celle-ci est plus abordable car les thèmes sont abordés successivement : tri, span queries, filtrages, sécurisation, utilisation d’index multiples, recherches parallèles, vecteurs de ternes.

Mettre en œuvre des recherches customisées est le thème du chapitre 6 qui occupe 27 pages. On y apprend à mettre en œuvre une heuristique particulière de recherche avec le « hit collector » mais aussi à y tester les performances.

Le chapitre 7 dédié au parsing de différents types de documents débute la seconde partie de l’ouvrage. Sur 43 pages on y aborde le traitements de formats de documents tels que le XML/HTML, le Word ou le PDF. Bien sûr les exemples mettent en œuvre des librairies tierces pour prendre en charge ces formats de manière native (PDFBox, TextMining.org, JTidy) ce qui est aussi une occasion d’aborder ces librairies.

Les 34 pages du chapitre 8 « Tools and extensions » sont un peu le grand fourre-tout de ce volume. Beaucoup d’outils tiers ou de la sandbox sont abordés, c’est la bonne nouvelle. Néanmoins, ces outils sont présentés de manière superficielle, mais cela suffit peut-être. En effet, ce genre de choses bouge très vite, je ne suis pas certain que ces outils soient toujours pertinents aujourd’hui. Il faudrait comparer cela à la seconde édition du livre parue depuis.

Le chapitre 9 présente les différents portages de Lucene. 12 pages seulement sont consacrés au sujet. Je pense aussi qu’il n’est pas utile de s’étendre sur le sujet, les mentionner et en faire une présentation succincte est déjà bien !

Avec 62 pages, le chapitre 10 présentant des cas d’étude est le plus long du livre. Il est le fruit des contributions d’acteurs de projets tiers mettant en œuvre Lucene. Du coup le niveau d’information varie beaucoup d’un projet à l’autre. Il est très bas niveau pour jGuru, tandis que SearchBox reste au niveau de l’architecture., plus fonctionnel sur XtraMind, etc…Disons que c’est la minute culturelle du livre. Mais c’est fort intéressant !

Le livre remplit bien le contrat de la série « in action ». Il est aussi sans surprise, ni bonnes ni mauvaises. Mais on a au moins la sensation que les auteurs n’ont pas cherché à faire du remplissage. Sans être indispensable pour aborder Lucene, il apportera sans nul doute des éclairages dans sa mise en œuvre. Cette édition n’est plus sur les rayons car une seconde édition est sortie depuis, mais vous n’auriez pas perdu votre argent.

image

Référence complète : Lucene in Action – Otis Gospodnetic & Erik Hatcher – Manning 2005 – ISBN : 9781932394283

Lucene in Action

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

Note de lecture : Langage C++ seconde édition, par Nino Silverio

Note : 4 ; Ni bon ni mauvais, juste alimentaire… et dépassé !

Encore un bouquin pour ceux qui veulent passer au C++ ! Celui-ci accuse 20 ans et se présente sous la forme d’un texte de 350 pages découpé en … 4 chapitres. Nous avons donc une belle moyenne de près de 90 pages par chapitre. Ca se présente mal. Voyons ce qu’il en est « en vrai ».

Le premier chapitre n’en est pas un. C’est plutôt un avant-propos qui nous souhaite la bienvenue sur 3 pages.

Le second chapitre est déjà plus conséquent avec ses 90 pages. Il aborde C++ en tant que « C avancé ». Et c’est vrai que l’on y parle pas beaucoup de C++ ! On y montre beaucoup d’éléments du langage C avec quelques spécificités du C++ comme les références les nouveaux types de cast ou des fonctions de la librairie standard C++. Mais de classes, point (par exemple). J’ai bien aimé les courts exemples pour illustrer les concepts.

Le troisième chapitre couvre 110 pages et aborde justement les classes. D’abord les éléments de base, puis très rapidement les templates. C’est même un peu déroutant. La surcharge d’opérateur et la sérialisation pour les streams déboulent un peu n’importe comment là-dedans. J’allais dire que j’étais content de ne pas avoir débuté avec cet ouvrage, mais en fait j’ai commencé avec le Stroustrup. Ce n’est pas prouvé que ce soit tellement mieux… Ca se poursuit avec la constance, les namespaces, etc… Tout cela est terriblement confus et à mon avis relatif à ce découpage pas très raisonnable en chapitres d’une centaine de pages.

Le 4ème chapitre traite de la programmation orientée objet en C++. C’est le dernier chapitre, on en prend pour 140 pages : on va s’amuser ! On commence par parler d’héritage, de classe et de polymorphisme (encore cette confusion entre orienté-objet et polymorphisme…). On parle aussi de visibilité. Bien sûr on en a déjà parlé dans le volume (pardon, le chapitre) précédent, mais là on a les éléments pour en comprendre l’utilité. Les exemples ne sont pas bluffant. L’utilisation d’une classe « Generique » comme illustration d’une classe de base abstraite est à mon avis un gros ratage. Les exemples sont aussi trop longs et trop complexe. L’héritage multiple est assimilé à de l’héritage « en diamant » de quoi donner des arguments aux détracteurs !

Le bouquin fait certainement le boulot, on a vu pire à cet égard. Mais il n’est pas engageant et on ne l’abordera pas pour le plaisir. Les exemples sont souvent complexes, obscurcissant le focus qui devrait être sur le langage pour comprendre l’algorithmique (cf. les arbres binaires). Le langage a bien évolué depuis, sans même parler de la norme C++ 11, c’est donc fort logiquement qu’on le jugera maintenant obsolète.

Référence complète : Langage C++ seconde édition, passage du C au C++ et programmation orientée objet – Nino Silverio – Eyrolles 1993 – ISBN : 978212088588

Langage C++, passage du C au C++ et programmation orientée objet

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