Plugin maven sources

Comme pour l'article d'hier voici le code source de l'article [1] sur comment realiser un plugin maven, toujours dans le repo git [2]

[1] https://un-est-tout-et-tout-est-un.blogspot.com/2018/03/ready-maven-faire-un-plugin.html
[2] https://github.com/collonville-tom/tc-un-est-tout-et-tout-est-un

Liquibase sources

En juin dernier, j'avais écris un article sur Liquibase [1] avec des extraits de code, seulement depuis, j'ai lancer un repository git contenant les sources des articles. Du coup cet article n'est que la que pour signaler que le code source de cet ancien article est disponible dans le repository [2]

[1] https://un-est-tout-et-tout-est-un.blogspot.com/2018/06/sgbd-liquibase.html
[2] https://github.com/collonville-tom/tc-un-est-tout-et-tout-est-un

IA : Presentation du neurone

Un petit article rapide pour attendre les prochains articles sur OSGI et SPARK .

Ici je parlerai d'une petite (grosse) présentation sur le neurone intitulé:

Que faire avec son neurone ?

Il s'agit en fait d'un recap des 2 ou 3 articles écrits jusque ici sur l'IA et sur le neurone implémenté en mode adhoc.

Asciidoctor

Suite a l'article d'hier [1],  on peut quand même se demander :Comment augmenter même un peu l’attractivité de la présentation?

En passant à Asciidoctor [2,3]!

Quoi un autre outil! non mais tu nous arnaques la, il va falloir tout refaire!

Non non ne vous inquiétez pas! Asciidoctor est un outil qui implémente (en ruby) tout le corpus de Asciidoc avec quelques petits trucs en plus.

Du coup oui il va falloir changer d’outil mais…. pas autant que vous le croyez [4]! n’oubliez pas ce dont nous parlions dans l'article précédent [1], comment rendre plus simple, plus attractive la rédaction documentaire dans le cadre d’un projet?

Et bien à l'instar d’un maven site [5] (qui est très très basique il faut l’avouer) on va également builder notre documentation technique avec Maven tout en restant (peu ou prou) compatible avec Asciidoc et sa simplicité (syntaxiquement parlant).

Avec Maven

Bien, on a déjà parlé de Maven [6] , et effectivement surtout dans le cadre de projet Java. Pourtant, si on prend un peu le point de vue du MDE/IDM, on peut considérer la documentation comme un modèle comme un autre de notre application alors si c'est un modèle, comme de l'UML ou même du code, pourquoi ne pas le compiler? Finalement il n'est qu une façon de voir une application ou un concept.

Ici on va rejoindre cette idée et nous allons définir un contexte de build maven pour faire notre documentation.

Des parents

Comme nous l'avions vu dans notre article sur Maven, on ne va pas partir bille en tête dans la simple définition d’un pom. On va se débrouiller pour augmenter la reutilisabilité. Du coup on va faire des pom parent!

On sait que asciidoc est naturellement fait pour produire des documents on va donc d’abord définir un parent permettant de construire ce type de doc, disons sous le format pdf puis par extension, on va tirer partie de ce premier pom pour l'étendre vers la production de présentations (il va de soit que le contenu sera le même, seul la forme change)

Pour faire ces deux pom parent, je citerai que je me suis beaucoup inspiré d’un fork d’un ami  sur github [7].

Ainsi le premier pom nommé tc-asciidoctor-pdf-parent va s’appuyer sur le plugin maven dédié à asciidoctor: asciidoctor-maven-plugin [8]. Il est complété par deux plugin asciidoctor que sont asciidoctorj-pdf [9] et asciidoctorj-diagram [10, 11] permettant de générer du pdf et de gérer des diagrammes au sein du document (comme UML, Graphviz, etc…) Pour en connaître un peu plus je vous invite à consulter le source du fichier sous github ici [12].

Le second pom nommé tc-asciidoctor-html-parent propose d'étendre le premier en spécialisant la génération documentaire au profit d’une interface html supportant la présentation. De façon à rendre celle ci plus dynamique, le pom va intégrer dynamiquement lors du build, une librairie Javascript revealjs [13] qui sera downloader via le plugin maven download-maven-plugin [14]. Ensuite, le plugin asciidoctor-maven-plugin va intégrer cette librairie pour construire la présentation en html. Pour en connaître un peu plus je vous invite à consulter le source du fichier sous github ici [15].

Utilisation

Il faut maintenant réintégrer les sources précédemment utilisées et les mettre dans un projet maven héritant du dernier pom présenté (tc-asciidoctor-html-parent)

On build :

mvn clean process-resources

et cela nous donne brutalement la présentation accessible ici [16].

Déjà c’est cool notre présentation à déjà bien évolué mais on voit que la compatibilité n’est pas présente à 100%.... le cadrage n’est pas parfait... Sachant cela, chacun verra midi à sa porte et choisira son approche préférée.

Conclusion

Nous n’avons pas été très loin dans l’utilisation de Asciidoc ni de Asciidoctor son équivalent, mais sont utilisation étant simple, il ne m'a pas semblé pertinent de s’attarder sur ce genre de problématique. Par contre son utilisation et les différents de logique de build existant entre les deux outils me semblait plus intéressant à montrer (sachant que Asciidoctor étant en ruby, via l’utilisation de l’installeur Ruby et de l’application Gem il est aussi possible de l’utiliser sans une industrialisation maven qui pourtant est, il me semble pertinente)

Voilà ainsi dans l’avenir, si je réalise une présentation en association avec un article, je procéderai comme pour le code source, je le déposerai dans le dépôt github du blog. Cela permettra de rendre plus dynamique les articles.

Pour ceux voulant aller un peu plus loin, les références suivantes sont pour vous: [17,18,19]

Remerciements (j’en fais pas souvent):

Merci à David et Christophe qui ont piqué ma curiosité avec asciidoc. Moi qui venait de Latex et de son formalisme jusqu’au boutiste, j’ai découvert un compromis et un outil fort pratique qui je pense va devenir un compagnon régulier de ma veille. (Il ne me reste qu'a tester la construction et l’intégration des diagrammes, mais on verra ça a la volée)

Références

[1] https://un-est-tout-et-tout-est-un.blogspot.com/2018/11/asciidoc.html
[2] https://asciidoctor.org/docs/
[3] https://asciidoctor.org/docs/what-is-asciidoc/
[4] https://asciidoctor.org/docs/asciidoc-asciidoctor-diffs/
[5] https://maven.apache.org/plugins/maven-site-plugin/
[6] https://un-est-tout-et-tout-est-un.blogspot.com/2018/01/maven-preparons-des-parents.html
[7] https://github.com/dvaillant/coursAsciidoc
[8] https://asciidoctor.org/docs/asciidoctor-maven-plugin/
[9] https://github.com/asciidoctor/asciidoctorj-pdf
[10] https://github.com/asciidoctor/asciidoctorj-diagram/
[11] https://asciidoctor.org/docs/asciidoctor-diagram/

[12] https://github.com/collonville-tom/tc-parent/blob/master/tc-asciidoctor-pdf-parent/pom.xml

[13] https://revealjs.com/

[14] https://mvnrepository.com/artifact/com.googlecode.maven-download-plugin

[15] https://github.com/collonville-tom/tc-parent/blob/master/tc-asciidoctor-html-parent/pom.xml

[16] https://collonville-tom.github.io/tc-un-est-tout-et-tout-est-un/tc-asciidoctor-article/ascii-article.html

[17] http://www.vogella.com/tutorials/AsciiDoc/article.html
[18] https://powerman.name/asciidoc/
[19] https://riduidel.wordpress.com/2017/06/16/generer-mon-asciidoc-dans-docker/

Asciidoc

La rédaction documentaire

Quiconque vous le dira, dans l’IT, le référentiel documentaire d’un projet est toujours le vilain petit canard, un mal aimé lorsque faut le rédiger mais qui pourtant fait l'unanimité des critiques lors de son absence.

Le but de cet article n’est pas forcement de vous convaincre de son utilité et de sa nécessité et de vous réconcilier (on tentera cela dans un autre article)  avec mais juste de vous présenter un outil qui peut être pourra vous simplifier la vie: Asciidoc [1].

Asciidoc est un outil de génération de doc sous différents format à base d’un langage simple inspiré des syntaxes employés dans les Wiki. Cela le rend très facile d'access.

Alors bien sur il n’est pas le seul dans ce domaine, on pourrait parler par exemple de markdown [2], [7] ou latex [3]. Peut être le feront nous seulement j’ai souhaité parler de asciidoc car il m’à semblé être un bon compris justement entre ces deux autres outils :

• markdown étant vraiment très basique voir simpliste, Asciidoc vous donnera plus d’expressivité tout en fournissant un rendu très satisfaisant. 
• latex à l’inverse est complet et fournira toujours des résultats impeccables c’est certain pourtant, acquérir sa maîtrise demande une marche qui sera moins haute avec Asciidoc.

Installation

Asciidoc est un outil développé en Python (on se chargera d’installer python 27 préalablement donc). Pour bénéficier de sa dernière version, rien de plus simple:

• un téléchargement sur sourceforge, 
• un dezip 
• un alias dans votre bashrc (sous Debian ou Cygwin) et on est parti!

alias ascdoc="/cygdrive/c/Python27/python.exe C:/Tools/asciidoc-8.6.9/asciidoc.py"

La Veille Technologique

S’il fallait des raisons d’apprendre

La veille technologique est un processus incontournable aujourd'hui dans n'importe quel domaine et métier mais cette vérité est d'autant plus forte dans le monde de l'IT tant cet eco-système change vite et se transforme rapidement.

Les concepts changent, les processus changent, les technologies changent et tout cela en même temps et ne pas les suivre c'est s'exposer à devenir rapidement inadapté face, pour d'une part, à des besoins clients  en perpétuels évolutions mais aussi d'autre part à des exigences de performances qui doivent faire face a des enjeux de dimensionnement de plus en plus présent (comme avec l’essor du BigData et par extension du Machine Learning cette dernière décennie [1])

Ainsi ne pas faire de veille technologie, par extension, c'est s'exposer individuellement a l'inadaptation face à un marché de l'emploi qui lui aussi évolue vite. J'ai, moi même, comme j'en ai parlé dans mon article un peu auto-biographique [2], pu perdre a certains moment le fil de l'actualité du monde technologique et théorique. Ainsi selon mon évaluation (ça ne vaut que mon avis), aujourd'hui, si un individu s'endort pour quelques 2 a 4 années, alors le gap qu'il aura a combler sera pour lui équivalent a repasser une bonne année des études qu'il avait pu suivre lorsqu'il était étudiant!

Je n'imagine pas la masse de travail a faire si il s'endort plus longtemps car cela ne prend pas en compte bien d'autres phénomènes qui intervienne au delà de ne rien faire.

Un des premiers phénomènes est celui de l'oubli, après combien de temps parvenez vous encore a exploiter des connaissances que vous avez acquises quelques temps plus tôt? honnêtement? 1 mois? 3 mois ? 6 mois? 1 an? 3 ans? 5 ans? Bien sur ce qui est appris est globalement acquis, mais le temps est délétère et selon la manière que cette connaissance a été acquise, il en restera plus ou moins les bases au mieux et nécessitera des révisions.

Personnellement je pense que au delà 3 mois sans utilisation, une technologie nouvelle devra être révisé, et que pour une connaissance couramment utilisé, il faudra probablement 3 années d'inutilisations pour impliquer la nécessite d'une révision (si a ce moment la cette technologie ou connaissance est encore d'actualité!)

De plus, il existe des freins et des limites propres a l'hommes qui font qu'il est nécessaire de faire de la veille technologique régulièrement. Par exemple:

• les biais cognitifs (bais de confirmations, préjugé, culture, etc...) qui auront altérer notre lecture initiale des faits et qui dans le temps ne feront que renforcer un point de vue sur un sujet qui sera peut être complètement erroné [3]. La veille technologique permet d'apprendre a réviser son jugement et ainsi passer outre nos préjugés (nous évitant alors de passer a coté de sujet intéressant voir même important 
• le vieillissement est malheureusement un fait et comme on dit, parmi les génies, seuls ceux de moins de 40 ans ont réalisé des grandes choses et des bouleversements justifiant des changement de paradigme : il ne faut donc pas compter sur l'age pour nous aider a être plus performant. Pourtant, la veille technologique a l’intérêt, au delà du travail d'apprentissage de connaissances, d’entraîner le cerveau a réfléchir, a construire sa pensée, a imaginer, a se restructurer. 
• la confiance en soit, peut être un frein a la connaissance, et la veille technologique peut permettre de gagner en confiance et être plus capable de se mettre en avant sur des sujets.

Au delà de l'acquisition de connaissance brut, la veille est donc un indispensable, elle permet de se maintenir a jour de l'actualité mais aussi de maintenir ses sens en éveil, se maintenir prêt a relever de nouveau défi quitte a même aller sur des sujet non connus!  C'est même la peut être la partie la plus utile de la veille technologique, garder l'esprit aguerri a la réflexion et a la résolution de problématiques sans avoir peur de sortir de son cadre.

WWWWH

Maintenant que l'on s'est donné (de bonnes) raisons de faire de la veille technologique, regardons un peu du coté du WWWWWH [4] pour creuser les axes de cette démarche.

Why ?

Evidemment nous n'allons pas refaire la partir introductive de cet article mais restons pragmatique, pourquoi faire de la veille technologique? Plusieurs points de vue peuvent être aborder:

• Court terme : le besoin projet, c'est peut être ce qui est le plus pragmatique, pouvoir mettre directement en pratique ce que l'on apprend!
• A moyen terme : Assouvir de la curiosité mais aussi se maintenir a jour techniquement et aussi parce qu’il ne faut pas attendre qui que ce soit pour préparer l'avenir, sachant que ce sont probablement ces connaissances qui permettront d’accéder a certains autres types de projets
• A long terme : entretenir les connaissances, mais aussi alimenter la curiosité personnelle de façon a continuer a faire un métier qui nous passionne, un métier ayant du sens.

When ? Where ?

Inutile de dire que ce chapitre sera court! Tous le temps, Partout! Comme le disait Einstein (citation du livre d'Etienne Klein, le pays qu'habitait Albert Einstein [5]):

"L'essentiel dans l’existence d'un homme de mon espèce, réside dans ce qu'il pense et comment il pense, non dans ce qu'il fait ou souffre"

En substance, signifiant pour moi que peu importe le lieu et le temps pour quoique ce soit, l'essentiel est l'utilisation de sa pensée et la manière de la construire. Et autant cela n'engage que moi mais la veille technologique (tout apprentissage en fait) a un rôle structurant pour la pensée qui est important de développer.

What ?

La question du sujet de la veille technologique est compliqué. Il s'agit ici d'un élastique tendu au bout de lequel on trouvera d'un coté, les sujets d’intérêts et de l'autre les sujets utiles!

Toute la difficulté dans une carrière sera de réussir a reboucler cet élastique! On peut distinguer différents types de sujet:

• les sujets généraux ou transverses
• les sujets spécifiques ou ciblés

Les premiers auront généralement pour but de donner du sens a une activité de veille technologique. Ce seront donc des sujets plutôt de méthodologie, conceptuel, historiques, et ou posant un contexte. Nous sommes alors plus dans un contexte de vulgarisation.

Les second seront des ramifications des premiers en s'attachant a entrer dans l'intimité d'un aspect du domaine considérer. Il s'agira donc plutôt de sujets abordant certaines technologies, frameworks ou encore de sujets décortiquant une problématique données. Pour aborder ces points, il faudra généralement un certain bagage.

How 

La partie la plus intéressante! Comment réaliser sa veille technologique? Probablement en ne faisant pas faire n'importe quoi non plus! Il importe que ce travail d'apprentissage soit pertinent et efficace! 

Tout d'abord, passons en revu les basiques:

Il est évident qu'il faut avant toute chose identifier un sujet intéressant. On sait pertinemment que la capacité d'apprentissage sera directement conditionné par le taux d’intérêt qui sera alloué au sujet. Bien sur on nous dira:

"Parfois, certains sujets, même indispensable, ne sont pas intéressant! "

C'est vrai, parfois il faut effectuer des veilles technologiques sur des sujets peu ou pas intéressant parce que ce sont des choses déjà vu et qu'il faut alors réviser ou parce que simplement ce sont des pre-requis qui sont juste pas intéressant. Dans ce genre de situation, l’idéal est de coupler le sujet avec un autre pour lequel l’intérêt sera plus grand. Ainsi, l'utilisation du second sera un prétexte pour le premier. L’idéal est même que le second soit une technologie déjà un peu maîtrisée de façon a limiter la marche a gravir.

Une fois le sujet cerné, il importe d'identifier les bagages nécessaires pour l’appréhender. Autant commencer par le commencement! Cela mène à construire un programme pour sa veille technologique. Sans cela, le risque est de sortir du cadre du sujet que l'on souhaitait traiter, attiré par l'ensemble des sujets amont à celui ci, sans cela, le risque est de se retrouver, un mois plus tard, a finalement encore préparer la veille du sujet initial!

Apres il ne faut pas non plus être trop exigent avec soit même car parfois en vagabondant, on se découvre de nouveaux centres d'intérêts et de nouvelles choses a apprendre, c'est ca aussi la veille technologique, s'ouvrir a d'autres choses. 

Ainsi, il est bien de se planifier sa veille technologique mais pas trop afin d’être raisonnable et réaliste avec des objectifs atteignables! Cela évitera de se décourager et de perdre le rythme et finalement abandonné en pensant "je suis trop vieux pour ces conneries". 

Dans le cas ou il faut tout apprendre d'un sujet alors il sera préférable de se tourner vers des supports autres que internet de façon a avoir des sources plus englobante (on sera alors plus sur des sujet généraux comme ceux dont nous avons parlé précédemment)

Maintenant que l'on a cerner le sujet, et identifier les pré-requis, il va falloir trouver les moyens de s'informer. Bien sur la première approche est de se tourner vers internet. Effectivement, on y trouve beaucoup d'informations (peut être parfois trop) sous de nombreux formats:

• l'article les articles sont souvent un peu plus généraux et donne une vision d'ensemble de sujet spécifique
• la vidéo est un support un peu spécial, souvent pratique pour les sujets généraux car permettant de comprendre les tenant et aboutissant d'un sujet, par contre lorsqu'il s'agit d'entrer techniquement dans les sujets, cela devient plus compliqué a suivre et nécessite de jouer beaucoup avec le curseur d'avancement. Pas fan personnellement, je peux comprendre que d'autre y adhère plus facilement (que moi), question d'affinité.
• le tutorial est un article exclusivement dédie a la démonstration, très pratique pour acquérir une expérience, elle ne permet pas forcement par contre de comprendre les concepts sous-jacent contrairement aux article
• la présentation est un exercice délicat, elle doit marié un contenu intéressant et une bonne pédagogie. Elle apporte la possibilité de connaitre un point de vue spécifique peut être différent de sa propre compréhension et d’étayer le sujet avec l'interlocuteur. 
• le blog souvent très pratique car regroupant des articles ou des tutoriaux, il permettent d’acquérir une connaissance très précise sur un sujet ou d'une problématique
• la doc technique est exclusivement a réservé pour ceux qui ont déjà le bagage mais qui cherchent des détails ou qui sont dans une phase de POC
• le mooc est une formation en ligne mixant articles, tutoriaux et vidéos. Souvent a réserver a des vielles technologiques conséquente, quand on part de loin sur un sujet.

Enfin, dans les cas difficile ou trop conséquent, il faudra préférer probablement s'appuyer sur un livre de façon a avoir un support couvrant l'ensemble des problématiques dans un formalisme homogène et cohérent.

Nous n'avons encore pas vraiment parler d'outils ou de méthode (enfin si avec cette article) cependant, il me semble que la phase de construction de la connaissance est une étape intime et que si vous en êtes la c'est que vous avez déjà depuis longtemps appris a apprendre et que vous vous connaissez et savez comment optimiser cette phase d'assimilation et de compréhension.

Pour ma part, elle se réalise assez simplement:

• Identifications des sources intéressantes par une lecture rapide filtrante
• Relecture approfondi par une prise de note
• Synthèse général par quelques schéma (UML, Mindmap, ERA selon votre domaine de compétence et vos connaissances, nous verrons que cela sera utile par la suite)

Enfin suite a cela a priori, et c'est ce qui viendra en tête de tout le monde, il faut mettre en oeuvre ce qui est appris. C'est effectivement très important car au delà de nous permettre de comprendre les avantages et inconvénient d'une technologie, la mise en oeuvre permet aussi de consolider l'apprentissage en se confrontant aux lacunes de la compréhension que l'on a du sujet (prejugé, biais cognitif, etc...). 

La mise en oeuvre se réalise par un POC (Prove Of Concept).  Il va permettre de vérifier que la technologie offre bien les services qu elle annonce mais et surtout va permettre de savoir que l'on est capable de l'utiliser!

A ce stade alors on pourrait s'attendre à ce que le processus de veille soit a ce stade terminé... il n'en est rien, réaliser un POC est une chose mais le terme de la veille n'est pas cette phase. Finir correctement une veille technologique nécessite de transmettre ce qui a été appris.

Teach

Pour débuter ce paragraphe, je citerai Robert Heinlein :

"When one teaches, two learn" 

Oui, enseigner a d'autres ses connaissances c'est faire aussi de la veille technologique! 

Même si cela est fait très rarement par même ceux faisant de la veille technologique regulierement, la dernière phase d'un apprentissage quel qu'il soit est de démontrer sa capacité à restituer ce que l'on connait. Cela augmente significativement la maîtrise du sujet étudié pour les raisons suivantes:

• Mon directeur de thése citait souvent Nicolas Boileau (que je paraphraserai pas): 

"Ce que l'on conçoit bien s'énonce clairement"

• Faire une restitution des connaissances acquise impose de se confronter a la réalité de notre compréhension car en transmettant son savoir, on doit être en mesure de garantir celui-ci! Il faudra donc se pencher plus sur les détails de faire une préparation donnant du sens a l'ensemble, de la cohérence. 

• Impose, contrairement au POC ou la mise en oeuvre ne permet que de démontrer notre capacité utiliser une technologie, d'en avoir compris les tenant et aboutissant, les éléments pivots, etc...

Donc enseigner va permettre de consolider sa propre connaissance mais aussi d’être face aux choses que l'on aura oublié, a coté duquel il est possible de passer, les subtilités car heureusement, les gens auquel la restitutions s'adressent ne sont probablement pas complètement vierge de connaissances sur le sujet! C'est même du coup la l'occasion de confronter des idées et des points de vue.

Comment transmettre? A qui?

Alors du coup finalement vient la question de comment transmettre? et a qui? Il s'agit d'une question a laquelle chacun doit donner une réponse selon le contexte dans lequel il évolue et les sujets qu'il traite!

Tout d'abord le comment. De la même manière que certaines sources d'informations ont permis d’acquérir des connaissances, rien n’empêche de produire le même genre de support. Ça peut être un blog (comme moi) ou des vidéos (dans la mouvance youtube) mais il faut garder en tête l'objectif de ce travail, le support ne doit pas devenir non plus plus complexe a mettre en oeuvre que le sujet lui même! 

Apres c'est selon l'envies mais il faut garder une chose importante en tête, la veille technologique, c'est pour vous. Le succès de transmettre ses connaissances est un plus si des gens y ont appris quelque chose, ce qui compte c'est le travail de formalisation, consolidation qui a été nécessaire.

Se poser la question de à qui enseigner ses connaissances acquises lors de la veille technologique, c'est avant tout et surtout une question cherchant a positionner le profil de l'interlocuteur cible.

On peut en définir plusieurs types:

• le novice sur le sujet. Dans ce cas, la restitution de la veille technologique doit être très progressive, il s'agit de ne pas noyer l'interlocuteur. Cette approche progressive aura alors pour intérêt dans la veille technologique de démontrer la maîtrise globale et cohérente du sujet. On sera ici plutôt dans un exercice de vulgarisation.
• l'expert du sujet. Il faudra pour un public aguerri être très prudent. Bien poser les concepts du sujets et être précis dans les démonstrations. L’intérêt de ce public est d'imposer a votre discourt un certain degré de justesse dans ce qui sera présenté car la critique pourrait être cinglante en cas de grosse bévue. Par contre les échanges seront plus pertinent et enrichissant.
• l'inconnu. Ce sera l'interlocuteur le plus difficile, car faute de savoir se positionner, il faudra considérer un support de communication adapté au deux types d'interlocuteurs présentés précédemment.

Conclusion

Certains diront que la veille technologique est surement un indispensable mais qu'ils n'ont pas le temps. Effectivement, on a tous une vie en dehors du travail, cependant dans le monde de l'IT ou tout change très vite, on ne peut se satisfaire des formations d'entreprise pour se tenir a jour. De plus, la veille technologique est une activité complexe qui pour être efficace doit être mené régulièrement mais aussi avec de la méthode.

Dans cet article, a été présenté une approche (celle que je suis personnellement) permettant de mener cette veille tout en tachant de la rendre efficace au mieux. Elle consiste globalement a bien sur hiérarchiser les sujets mais aussi après en avoir pris connaissance et avoir fait une mise en oeuvre, a réaliser un travail de restitution.

Pour aller un peu plus loin, voici quelques articles et blog permettant de compléter et confronter mon point de vue [6], [7], [8]

Références

[1] Big data et Machine Learning, 2016, de Pirmin Lemberger (Auteur), Marc Batty (Auteur), Médéric Morel (Auteur), Jean-Luc Raffaëlli (Auteur)

[2] https://un-est-tout-et-tout-est-un.blogspot.com/2018/09/100-un-peu-dautobio.html

[3] http://www.psychomedia.qc.ca/memoire/2014-05-29/transformation-des-souvenirs
[4] https://un-est-tout-et-tout-est-un.blogspot.com/2017/12/qqoqccp.html
[5] Le pays qu'habitait Albert Einstein Broché – 19 octobre 2016, Etienne Klein

[6] https://www.camilleroux.com/2009/09/20/conseil-realiser-bonne-veille-technologique/

[7] https://linuxfr.org/news/methode-et-outils-pour-la-veille-technologique

[8] https://toiledefond.net/5-outils-pour-commencer-une-veille-sur-internet/

Design Pattern : Whiteboard

Pourquoi le pattern whiteboard?

Le pattern Whiteboard [1, 2] est un pattern un peu spécifique, il à la particularité d'être intimement associé à la technologie OSGI [3, 5] et comme il était question dans ce blog de parler de ce framework, nous voici donc avec une petite introduction de ce dernier via ce pattern de conception.

Au delà du prétexte de l'écriture d’un article introductif à OSGI, ce pattern pattern à bien entendu une raison d'être qui lui est propre: proposer une alternative raisonnable au pattern listener dans la conception de logiciel à base de microservice comme le permet OSGI [4].

On entrevoit donc ici les raisons de l’utilisation du pattern mais pour etre plus precis, nous regarderons avant cela les concepts de base de OSGI afin d’en comprendre les besoins et avant de détailler plus en avant le pattern whiteboard, nous regarderons pourquoi le pattern listener n’est plus satisfaisant dans certaines situations.

Techno OSGI dans les grandes lignes

La technologie OSGI ou Open Service Gateway Initiative est un framework Java pour la construction d’application à base de composants et de services. Il s’agit d’un framework ayant pour vocation initial la réalisation d’application à taille réduite où la gestion mémoire est millimétré.

Il permet techniquement de gérer simultanément des librairies java évoluant dans des versions différentes ainsi que de charger et décharger ces librairies dynamiquement sans nécessiter le redémarrage de la JVM. Par contre, pour permettre ces capacités, OSGI “impose” (mais en fait c’est un bien) un paradigme de modélisation impliquant la construction de nos application selon une architecture un peu spécifique à base de composant (les bundles) et de services.

Avec cette petite introduction, on perçoit rapidement l'intérêt de ce framework! Nous y reviendrons plus tard, nous en avons vu l’essentiel pour l’instant. Il faut surtout en retenir que OSGI nous permet de construire des applications modulaires à base de composants et de services. Dédié initialement à l’embarqué, il est sortie rapidement de son contexte d’utilisation initial et s’est alors confronté aux méthodes et techniques de construction des architectures logiciels classiques.

Pourtant avec une architecture tel que proposée par OSGI, ce pattern comporte de nombreuses limites.

En effet, dans une architecture à composant ou les dépendances entre composant ne peuvent être forte, il est nécessaire de permettre à deux objets de communiquer sans forcément qu’ils aient connaissance de l’un et de l’autre directement.

Pattern Listener et limites

Entre autre, le cas du pattern Listener est caractéristique car dans le cadre de son utilisation dans le cadre OSGI, il comporte quelques limites.

Nous avons traité le pattern listener dans un autre article [6], je n’y reviendrais pas ici. disons simplement que ce pattern est un pattern d’architecture et comportemental permettant le découplage d’un observateur et d’un observer tout en formalisant son moyen de communication via un objet de type événement. Il s’agit en fait du pattern observateur mais simplifié.

Ce pattern est souvent utilisé pour sa nature événementielle dans le cadre de la gestion des IHM. Ainsi, par exemple, lorsque utilisateur sollicite la souris de son ordinateur, le contrôleur associé va générer des événements permettant de suivre ses déplacements. L'utilisation du pattern listener est en première approche une solution intéressante pour traiter ces événements surtout lorsque les sources possibles sont multiples. Pourtant c’est là sa limite également. Car alors si ces sources produisent de multiples événements simultanément alors le système peut être soumis à un “EventStorm” [1] amenant à une utilisation élevée de la mémoire et du CPU, perdre gravement en performance et dans le pire des cas conduire à un crash.

Whiteboard pattern

Le pattern Whiteboard est une solution apportée comme alternative au pattern listener dans le cadre du framework OSGI.

Il est intimement lié à OSGI cependant comme nous verrons ce framework par la suite il me semble plus pertinent d'éviter d’entrer dans trop de détails d'implémentation lié à cette technologie. Ainsi nous nous attacherons à une présentation d’un modèle abstrait du pattern (sous la forme d’un type PIM, Plateform Independant Model dans le MDA [7])

Ce pattern propose de découpler la source des événements du listener en introduisant un objet supplémentaire entre les deux servant de registre et transformant la relation entre les deux éléments par une relation de service et de consommateur de service.

Ce qui servait donc de listener devient un composant fournissant un service qui sera enregistrer dans un registre. La source des événements aura alors la tâche de demander au registre le service adéquat afin de pouvoir lui transmettre les événements produits.




L'intérêt de l'approche en ajoutant ce registre qui finalement réalisé la réification de la relation listener/sources des événements est de permettre de contrôler cette relation et son utilisation par la source des événements.

Il va être alors possible :

• de réaliser du monitoring sur le flux d’informations voir même de le debugger
• de rendre indisponible le service du listener si celui ci est trop utilisé et implique une consommation des ressources trop importante
• d’adjoindre des droits spécifiques d’utilisations en ajoutant sur le registre une couche de sécurité et des permissions afin de ne pas le rendre disponible à n’importe quel consommateur du service venu
• injecter des propriétés spécifique pour customiser le mapping (comme par exemple pour préciser un quota en événement par seconde à traiter ou pour proposer une taille de tampon d'événements, etc…)

Exemple

Pour illustrer ces mécanismes voici dans un contexte hors OSGI ce qu proposerait une implémentation du pattern listener (observateur) et ensuite son équivalent dans la philosophie du pattern Whiteboard. On précise ici que l’on reste dans une implémentation de type PIM afin de ne pas perturber la compréhension du pattern avec les spécificités technologiques du framework OSGI

Avec Listener

package listener

class Event{
    String message

    Event(String m){
        this.message=m
    }
}

interface IObserver{
    def update(Event e)
}

interface IObserved{
    def notifyAll(Event e)
}

class TrucQuiEcoute implements IObserver{
    def update(Event e){
        println("Reception d'un message")
        println(">>"+e.message)
    }
}

class TrucQuiFait implements IObserved{
    List obs=new ArrayList<Observer>()

    def notifyAll(Event e) {
        for( Observer o in obs){
            o.update(e)
        }
    }

    def makeSomething() {
        def e = new Event("Ceci est le message")
        println("Envoie d'un message")
        this.notifyAll(e)
    }
}


def ob=new TrucQuiEcoute()
def obd=new TrucQuiFait()
obd.obs.add(ob)
obd.makeSomething()

Avec Whiteboard

package whiteboard

interface IService{
    def serve(Event e)
}

class ServiceRegister{
    Map services=new HashMap<String,IService>()
}

class Event{
    String message

    Event(String m){
        this.message=m
    }
}

class TrucQuiEcoute implements IService{
    def serve(Event e){
        println("Reception d'un message")
        println(">>"+e.message)
    }
}

class TrucQuiFait implements IService{
    ServiceRegister register;

    TrucQuiFait(ServiceRegister register)
    {
        this.register=register;
    }

    def serve(Event serviceNameEvent) {
        def e = new Event("Ceci est le message")
        println("Envoie d'un message")
        this.register.services.get(serviceNameEvent.getMessage()).serve(e)
    }
}

def reg=new ServiceRegister()
reg.services.put("TrucQuiEcoute",new TrucQuiEcoute())
reg.services.put("TrucQuiFait",new TrucQuiFait(reg))

reg.services.get("TrucQuiFait").serve(new Event("TrucQuiEcoute"))

Conclusion

Voilà nous avons fait le tour de ce pattern un peu spécial enfin, surtout un peu spécialisé, qu’est le pattern Whiteboard. Celui-ci est très associé à OSGI mais il peut se comprendre sans et surtout mieux comprendre certains mécanisme de ce framework que nous verrons dans un prochain article.

Références

[1] https://www.osgi.org/wp-content/uploads/whiteboard1.pdf
[2] https://en.wikipedia.org/wiki/Whiteboard_Pattern
[3] https://www.osgi.org/
[4] https://enroute.osgi.org/FAQ/400-patterns.html
[5] https://www.theserverside.com/news/1363820/The-Whiteboard-Pattern-for-OSGi
[6] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-observateur.html
[7] https://laine.developpez.com/tutoriels/alm/mda/generalites-approche-mda/