Note de lecture : The Java Developer’s Guide to Eclipse, 2nd edition, par Jim D’Anjou, Scott Fairbrother, Dan Kehn, John Kellerman & Pat McCarthy

Note : 6 ; De l’Eclipse au kilo !

Voici un pavé, du vrai, du gros, du 1000 pages ! Ce gros pavé, justement, se veut la bible du développement avec et pour Eclipse. Honnêtement, cet ouvrage semble venir d’un autre temps, celui où l’on payait les livres au kilo ! Celui-ci n’est plus tout neuf, mais il me semble que même à cette époque cette tendance s’estompait. Et plus encore chez Addison Wesley. Le livre compte 34 chapitres et je n’ai franchement pas l’envie de tous les passer en revue. Heureusement, ceux-ci sont regroupés en 6 parties, ce qui rend plus huain le survol du texte.

La première partie couvre près de 200 pages et est consacrée à l’utilisation d’Eclipse. Les 6 chapitres qui la compose noircissent beaucoup de papier pour dire en grande partie ce que l’on sait ou a déjà deviné. Il y a bien quelques informations à grapillé dans les coins, mais c’est majoritairement un gâchis de temps et d’espace.

La seconde partie est consacrée aux fondamentaux de l’extensibilité d’Eclipse. Le but ici est de comprendre les points d’extensions, les notions de base des frameworks fondamentaux (SWT, JFace) et d’être en mesure de créer un plugin. On en prends pour 130 pages et 7 chapitres, et c’est curieusement plus intéressant et plus instructif que la première partie.
La troisième partie est dédiée à l’extension du workbench, mais il s’agit surtout de rentrer en profondeur dans les frameworks. Le tarif est de 7 chapitres et 230 pages. Il est vrai qu’il y a de la matière.

La quatrième partie « extending the Eclipse IDE » se focalise sur l’intégration du plugin avec le cycle de vie de l’IDE. Il en coûte 120 pages et 5 chapitres.

La cinquième partie « sujets spéciaux » couvre tout ce qui ne rentre pas ailleurs, comme l’intégration OLE DB. On aurait pu s’en passer, mais quand on aime, on ne compte pas. Ici, c’est 7 chapitres et 130 pages.

La sixième partie mérite une mention spéciale car c’est un cahier de 9 exercices guidés qui occupe les 200 dernières pages.

image

Référence complète : The Java Developer’s Guide to Eclipse, 2nd edition – Jim D’Anjou, Scott Fairbrother, Dan Kehn, John Kellerman & Pat McCarthy – Addison Wesley 2005 – ISBN : 9 780321 305022

The Java Developer's Guide to Eclipse

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

Waiting for the Storm…

Le Storm User Group, c’est une initiative de quelques collègues autour du « big data temps réel ». Aujourd’hui, nous parlons de Storm et quelques infrastructures qui peuvent s’y connecter. Demain, il s’agira peut-être de Spark ou d’autres…

Halte là ! Je vais peut-être un peu vite ? Et d’abord, Storm, qu’est-ce que c’est ? Voilà une question à laquelle une partie de cette première rencontre va être consacrée.

Oui, Storm, qu’est-ce que c’est ?

C’est Florian Hussonois qui va répondre à cette question. Nous pourrions résumer la chose en déclarant simplement qu’il s’agit d’un Hadoop « temps réel ». Il s’agit en quelque sorte d’un middleware permettant le traitement d’évènements en mode flux.

Un (petit) peu d’historique

Storm a été développé par Nathan Marz chez BackType en 2011. La société est rachetée ensuite par Twitter qui promeut le projet et le passe en Open-Source. La première release officielle date de 2011. En Septembre 2014, le projet devient officiellement « Apache Top Level Project » alors même qu’il n’a pas encore atteint la release 1.0 !

Ecrit principalement en Clojure et en Java, ce « processeur d’évènements » est conçu pour traiter un flux de très nombreux évènements (des tuples dans la terminologie Storm), à savoir 1 millions de tuples par seconde et par noeud (1 seul coeur processeur), avec tolérance aux fautes, gestion de la scalabilité et garantie de traitement !

image

Les concepts clés

Pour bien comprendre Storm, il faut en saisir les concepts de base.

  • Le Tuple : Nous en avons parlé, il s’agit de l’unité d’information à traiter. C’est l’évènement.
  • Le Stream : c’est une séquence illimitée de tuples.
  • Le Spout : C’est un connecteur producteur de tuples. En pratiques, ce sont des composants source de données. Il en existe de nombreux types (dans le projet officiel et en dehors) pour se connecter à différentes infrastructures.
  • Le Bolt : Il s’agit du composant de traitement élémentaire. Il consomme bien entendu des tupples et peut en produire (mais pas obligatoirement). Il peut aussi se connecter à une base de données, par exemple.
  • La Topologie : il s’agit de la structure de déploiement de votre configuration Storm. Dans la pratique, il s’agit d’un graphe acyclique (DAG).
  • Groupements de streams : Si les bolts peuvent « splitter » des streams (façon CBR) ou les multicaster, ils peuvent aussi les regrouper. Il existe 7 types de regroupements.

Le parallélisme est intrinsèque à Storm. Chaque Bolt peut être instancié plusieurs fois (on les appellent « task »). Chaque tâche est prise en charge par un Executor qui correspond dans la pratique à un thread. Storm prend en charge la répartition des Executors sur des Workers (qui correspondent à une JVM). Chaque Worker devant être géré par un Supervisor. Ce dernier point est important, car les Workers peuvent tomber ! Un petit dessin vaut parfois mieux qu’un long discours…

image

Pour gérer et faire tourner l’ensemble, Storm met à notre disposition 3 briques importantes :

  • Le Supervisor : nous en avons parlé, il gère un Worker, le relançant si nécessaire, et permet de surveiller sa charge.
  • Zookeeper, qui a en charge de gérer une topologie
  • Nimbus, qui gère les masters des topologies. Il doit lui-même tourner sous supervision.

Traiter en toute quiétude

Les graphes de traitement de Storm peuvent devenir des arbres très complexes ! Toutefois Storm s’y entend pour reconnaitre si un Tuple entrant a été traité sur la totalité de son arbre. Tout d’abord chaque Tuple a son id (sur 64 bits). Nathan Marz a développé un algorithme très complexe, basé sur le XOR pour identifier si un arbre a été complètement traité. Bien entendu, chaque Bolt opère son acquittement local, c’est le « Ack ».

image

Florian passe rapidement sur Trident qui permet d’assurer une sémantique « exactement 1 » aux traitements. J’avoue que le sujet est passé trop rapidement pour moi. Peut-être une occasion de creuser le sujet ultérieurement ? Il en va de même pour la fonctionnalité DRPC.

Si vous avez raté le live et que ma prose vous laisse de marbre, voici l’enregistrement de l’intervention de Florian lui-même !

Storm et Redis chez Twitter Foot

Ce retour nous était proposé par Benjamin Houdu. Cette présentation m’intéressait d’autant plus que j’ai participé au début de ce projet. Et je dois dire que ce dont Benjamin nous a gratifié est probablement le meilleur retour d’expérience auquel j’ai pu assister !

Le projet

Comme son nom l’indique, Twitter Foot traite des flux Twitter, suivant des comptes identifiés par l’AFP (7000 comptes sur 5 ligues), pour fabriquer des timelines spécialisées et toute sortes de statistiques, comme des tendances, la détection de viralité ou de popularité.

Techniquement, les particularités de cette mise en oeuvre de Storm repose d’une part sur la connexion Twitter via la streaming API en utilisant le connecteur Hosebird, et d’autre part sur la mise en oeuvre conjointe de Redis, un base NoSQL de type clé-valeur fonctionnant en mémoire. Redis est d’ailleurs très exploité ici, car on en fait un triple usage :

  • Pour bufferiser le flux Twitter et alimenter le stream Storm. Incidemment, cela rend l’architecture plus testable, car les tests peuvent être faits simplement en peuplant Redis, sans connexion à Twitter, avec en prime la maitrise sur les données injectées !
  • Pour sauvegarder les données de référence : aussi bien la topologie que l’on va injecter dans Zookeeper que les comptes sur lesquels on a des abonnements.
  • En frontal, pour exposer les timelines résultantes et les données statistiques !

En pratique, la topologie est constituée de 3 machines abritant chacun un worker, auxquelles il faut rajouter le serveur frontal abritant le serveur Rest qui expose les services ainsi construits.

image

Et bien sûr, il y a le serveur hébergeant Redis !

Justement Redis, qu’est-ce que c’est ?

Nous l’avons dit, il s’agit d’une base NoSQL de type clé-valeur fonctionnant en mémoire. On devinera que ces choix l’orientent vers la performance, ce qui explique les autres choix techniques : elle est écrite en C et est … monothreadée ! Ce dernier choix peut paraitre curieux, mais de fait, il évite de devoir gérer les problèmes de contention. Il se justifie aussi par les excellentes performances de la base dont les requêtes sont non seulement traitées rapidement, mais aussi peu sensibles à l’augmentation de volume : la plupart des fonctions proposées ont des indices de performance en O (Log (n)) !

Parmi les fonctionnalités intéressantes de cette base, on pourra noter dans le désordre :

  • La présence d’une API de type « publish / subscribe » bien pratique entre autre pour le débug !
  • La présence de connecteurs pour un grand nombre de langages.
  • La mise à disposition de structures intelligentes : sorted sets, Z sets, etc. qui permettent non seulement de retrouver un élément, mais de sélectionner un « range » d’éléments. Une fonctionnalité qui s’avérera particulièrement précieuse dans le cas d’utilisation de Twitter Foot !
  • La présence d’un langage de script basé sur Lua qui permet d’écrire l’équivalent de procédures stockées dont l’atomicité d’opération est garantie par l’architecture monothreadée de la base !
  • L’accès en mode interactif en ligne de commande, via redis-cli pour travailler sur la base en mode non programmatique.

Storm, au coeur de Twitter Foot !

Nous n’allons pas revenir sur le descriptif général de Storm que Florian a fort bien abordé. Benjamin attire toutefois notre attention sur les changements importants survenus entre les versions 0.8.x et 0.9.x, la première dépendait fortement de Zero MQ, ce qui n’est plus le cas des versions ultérieures. Il met aussi l’accent sur l’intérêt de Storm UI d’un point de vue opérationnel, surtout pour savoir quel tâche tourne sur quel worker ! En effet, il faudra abandonner l’idée que l’on traite l’affinité des tâches sur les workers / machines, c’est Storm qui gère cela.

En fait, l’un des enseignements que tire Twitter Foot, c’est que l’administration est un volet du projet aussi important que le développement, et il faut y faire face le plus tôt possible dans le projet ! Autre difficulté, la configuration dont les changements imposent des redémarrages de topologies. C’était une contrainte trop forte pour Twitter Foot, aussi l’équipe a-t-elle traité la configuration comme un Stream traversant les Bolts !

Des fenêtres bien glissantes…

Un concept est rapidement apparu sur Twitter Foot : la nécessité de faire des statistiques sur une durée fixe, mais relative au temps présent. Ce que l’on a appelé des « fenêtres glissantes », c’est à dire entre T0 et T-n minutes (ou heures, ou jours), avec un échantillonnage représentant la résolution de ces statistiques en x minutes ! Vous pouvez aussi dire « sliding windows » pour briller dans les salons, mais ne cherchez pas sur Google, c’est un concept maison !

image

Plusieurs essais d’implémentations en ont été faites. Benjamin nous parle de deux d’entre-elles.

Tout d’abord, on peut s’appuyer sur un concept Storm : les Rolling Buffers. Ils sont plutôt complexes à mettre en oeuvre, mais ils présentent entre autre l’avantage de gérer automatiquement l’éviction des échantillons quittant la fenêtre glissante !

Autre possibilité : s’appuyer sur les ZSets de Redis. Redis permet même d’opérer des aggrégations par x minutes et donc de gérer pratiquement automatiquement l’échantillonnage ! Par contre l’éviction des vieux échantillons doit se faire programmatiquement.

Quelques mots sur la testabilité

J’ai été agréablement surpris de voir Benjamin aborder ce point finalement assez déconnecté des problématiques purement techniques de Storm (bien qu’il y ait bien sûr des corolaires techniques). Le projet a en effet mis en oeuvre tôt dans ses premières phases une approche ATDD impliquant le client et s’appuyant sur le paradigme « Given When Then » outillé avec Cucumber JVM. Cette approche a réellement permit une convergence et appréhension fine des fonctionnements attendus.

D’un point de vue technique, il a été possible de se servir de l’alimentation par Redis pour effectuer ces tests déconnecté de Twitter en injectant dans Redis des Tweets « forgés ». Autre point délicat, la nécessité de ne pas redémarrer la topologie entre chaque tests afin de garder des temps d’exécution raisonnables.

Et le monitoring ?

Nous l’avons dit, avec Storm on fait beaucoup d’administration, ce qui a quelques implications.

D’abord, plus encore qu’ailleurs, les opérations réalisées fréquemment doivent être en « push button ». Jenkins est d’une aide appréciable à ce niveau.

Le Storm Supervisor : il est indispensable, et il en faut un par machine.

L’équipe a aussi utilisé avec bénéfice Monit, un watchdog qui s’est avéré d’une grande utilité. Notre orateur est dithyrambique à ce sujet !

Du côté de Redis, c’est redis-rdb-tools qui s’est avéré indispensable. Le gros avantage est le parse des logs offline, donc sans impacter la machine de production. Dans la pratique, beaucoup d’investigations peuvent être menées à bien en différé.

Si on a réellement besoin de connaitre l’état de santé de l’instance en live, il y a … Redis Live !

Quelques mots sur le débug et les best practices

L’investigation de problèmes sur une architecture Storm peut très facilement se transformer en chemin de croix ! Il faut anticiper cela au niveau de la conception et penser les Bolts avec des responsabilités bien séparées (principe SRP de Bob Martin). En fait, Benjamin nous suggère de séparer les Bolts de contrôle des Bolts d’action !

Même chose sur Redis : bien séparer les actions d’insertion des actions de nettoyage.

Enfin, même les topologies peuvent être décomposées, une leçon qui est arrivée hélas bien tardivement sur Twitter Foot ! De plus petites topologies se testent plus facilement et sont plus robustes. Mais attention, ne pensez pas mutualiser les workers : un worker ne peut appartenir qu’à une topologie.

Autre problème bien connu, celui de l’auditabilité : comment retrouver l’origine du problème ? L’équipe Twitter Foot nous propose la technique du « Carbon dating » : injecter dans les Tuples des informations de trace des Bolts traversés !

Du côté Redis enfin, si l’aspect « sans schéma » est apparemment une liberté bienvenue, on touche vite les limites de ce manque de typage. Ici, c’est l’emploi de json-schema que vient nous recommander l’équipe.

Si vous préféreez la présentation de benjamin in extenso, ne pleurez plus, la voici !

Ce que j’en ai pensé

Je l’ai dit au début : l’orateur nous a gratifié là d’un retour d’expérience d’un niveau de qualité que j’ai rarement (jamais ?) vu !

La mise en oeuvre d’un projet avec Storm est réellement quelque chose de complexe. On perçoit cette impression rapidement, mais les dimensions de cette complexité apparaissent clairement dans cette présentation !

Mais on va plus loin ici : les voies à explorer, les points d’attention dans le projet, les outils indispensables et leur utilité, tout nous est clairement exposé. Un grand bravo !

Note de lecture : Activity in Action, par Tijs Rademakers

Note : 7 ; Un bon ouvrage au standard « in action » pour accompagner une immersion dans Activity, malgré quelques frustrations.

Activity, c’est le « spin off » de JBPM par ses créateurs. Mais, ainsi qu’il est expliqué en introduction, ce n’est pas un fork mais une réécriture complète, avec les choix de conception que l’équipe aurait voulu prendre à l’époque !

Mais revenons au livre. L’auteur est un des comiters principaux du projet, ce n’est pas non plus un auteur débutant. Tout ce présente donc sous les meilleurs auspices pour commencer. La prose est conséquente : 400 pages sur 15 chapitres distribués en 4 parties inégales. Il est temps de rentrer plus en profondeur.

Les quelques 80 pages de la première partie regroupent 4 chapitres et sont une introduction à BPMN 2.0 et Activity. On commence par une présentation générale d’activity, de son architecture et l’incontournable « hello world » précédé d’une installation basique. C’est réussi. Le chapitre suivant a pour but de nous présenter BPMN 2.0. C’est fait avec pédagogie et bien illustré, mais aussi assez superficiel et on sort de là un peu frustré. La présentation de l’outillage Activity est un peu touffue, probablement parce que cet environnement l’est aussi un peu : il manque d’homogénéité et est un peu de pièces rapportées. Espérons que cela s’améliore à l’avenir.

Avec 35 pages, le chapitre 4 est le gros morceau de cette première partie, on y débute l’implémentation de l’étude de cas, avec configuration Maven, définition de processus, implémentation de tâches en Java et tests unitaires. Honnêtement, ça fait un peu trop de chose pour être vraiment clair.

La seconde partie est consacrée à l’implémentation de processus avec Activiti, c’est donc le cœur du livre. On y compte 150 pages et 5 chapitres, ce qui le met à égalité avec la 3ème partie. Là où le chapitre 4 était un peu brouillon, le chapitre 5 reprends les choses calmement et implémente un BPM simple mais non trivial, avec une implémentation d’un script task et de différents service tasks. On va même jusqu’au déploiement. C’est bien fait et clair. Le chapitre 6 nous permet de faire des choses plus avancées (sous-processus, points de décision) et couvre aussi l’accès à JPA depuis Activity et la mise en place de listeners sur les tâches. La gestion des erreurs (en Java ou en définition de processus) est traitée avec sérieux au chapitre 7, un bon point ! C’est aussi le cas sur les options de déploiement abordées au chapitre 8, bien que je reste sur ma faim sur la façon dont l’utilisation de l’interfaçage ReST est abordé. Le chapitre 9 qui clos cette partie n’est pas mon préféré. Seul la partie OSGi m’aurait intéressée si elle avait été abordée clairement !

La troisième partie se focalise sur les aspects avancés d’Activity. Le chapitre 10 fait un peu pot-pourri entre des aspects avancés de modélisation (sous-tâches, délégation), la connexion au LDAP ou les tâches multi-instances, ça manque un peu de cohérence. Le chapitre 12 est plus « focus » car il traite d’un aspect important : l’intégration. L’utilisation d’Apache Camel et de Mule ESB font le gros de ce chapitre. C’est une bonne idée, car cela donne un exemple avec ESB et un autre avec « ESB light ». L’intégration d’un moteur de règle n’est pas nécessairement l’aspect qui m’aurait intéressé de prime abord, mais le chapitre 13 qui le traite et clair, bien écrit et même source d’inspiration. Je ne dirais pas la même chose du chapitre 14 qui traite de l’intégration avec Alfresco.

Alfresco est le principal comiter Activity et parler de cette intégration sonne comme un passage obligé, mais personnellement j’en retire peu de choses. Ca fait plutôt plaquette publicitaire. Cette partie se conclut par un passage par le monitoring de production e l’intégration avec Esper : utile, intéressant et bien fait.

La quatrième partie ne compte qu’un seul chapitre et 25 pages. L’objectif est de nous permettre de monitorer les processus en production. Concrètement on entre dans le modèle de données d’Activity et on fait un petit tour dans le Job Executor. Pas grandiose mais nécessaire.

Activity in Action fait bien le boulot, il est à la hauteur du standard « in action » de Manning. Le texte est bien écrit et les illustrations aident. Les exemples par contre sont plus problématiques : ils sont souvent non seulement complexes et volumineux, mais insuffisants tels qu’ils figurent dans le texte. Il est nécessaire d’avoir recours au code source complet.

Personnellement, mon regret est une approche très « Activity centric », où les fonctions du logiciel sont subordonnées aux hooks qu’offre le framework. Etant essentiellement conçu en ce sens, l’approche est compréhensible. Toutefois Activity possède aussi un ensemble d’API ReST permettant de l’utiliser de l’extérieur à la façon d’une appliance. Je suis d’avantage intéressé par cette architecture et je soupçonne que de nombreuses personnes le sont également. Très peu de contenu est orienté en ce sens. A mon avis, l’ouvrage aurait bénéficié d’un ou deux chapitres en ce sens, même si cela avait dû être au détriment d’autres sujets.

Malgré ces quelques frustrations, le contrat est bien rempli. Pour qui veut s’initier à Activity, voilà un excellent compagnon.

image

Référence complète : Activity in Action, Executable business processes in BPMN 2.0 – Tijs Rademakers – Manning 2012 – ISBN : 978 1 617290 12 1

Activiti in Action

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

Améliorer la société au Product Tank

Ce nouveau rendez-vous du Product Tank avait aujourd’hui un focus très clair et très particulier : des produits qui n’en sont pas … et surtout qui sont là pour améliorer la société. Nous étions accueillis à cette occasion au John Paul Lounge, un espace ouvert sur les Champs Elysées !

image

Un petit comité hélas pour un sujet pourtant si particulier et une soirée qui s’avèrera riche d’enseignements.

Open Food Facts

Pour ouvrir la soirée, Stéphane Gigandet nous parle d’Open Food Facts. Et Open Food Facts, c’est avant tout une association loi de 1901, avec uniquement des bénévoles à son bord ! D’ailleurs Stéphane ne se définit pas comme un Product Manager, mais comme un « Product Opener » ! Et ouvert, la base de données d’Open Food Facts l’est, car disponible en open data et sous license Open Database !

Le but, ou la mission devrais-je dire, qu’openfoodfacts.org s’est imposée, c’est d’améliorer la transparence sur la constitution des aliments, donc sur la qualité nutritive de ce que nous achetons, en décryptant les labels ! Et avec plusieurs milliers d’additifs en cours sur le marché, il y a du boulot. Surtout que ceux-cis s’efforcent d’être le moins compréhensibles possibles.

image

Notre orateur du jour est informaticien. Il a d’ailleurs développé les outils que propose Open Food Facts. Notamment, l’application mobile permettant la saisie et la reconnaissance des produits. En fait, il semble bien tenir le projet à bout de bras ! L’inspiration du modèle de fonctionnement vient de Wikipedia : utiliser le crowdsourcing pour aider à décrypter les produits. Aujourd’hui la communauté compte plus de 1000 contributeurs.

Au fait, pourquoi « Product Opener » ? Stéphane nous avoue qu’un tel projet ne peut être dirigé. Subordonné au bénévolat, il ne s’étend pas en fonction des besoin, mais des motivations des contributeurs. L’organisation veut cette base d’intérêt public, elle est donc librement accessible via des API JSON. Mais des projets naissent aussi au sein même d’Open Food Facts :

  • Projet de « science citoyenne ».
  • Repérage de produit contenants du lactose ou du gluten
  • Produits contenant de l’huile de Palme
  • Projet d’archéologie alimentaire, etc.

Bref, Open Food Facts, c’est bien plus que le repérage des ingrédients sur l’étiquette !

image

Aujourd’hui, l’ambition s’étend aux produits de beauté, et aux produits en dehors de la France. De grandes ambitions et un bel état d’esprit !

Open Data Gouv, avec Pierre Pezziardi

Pierre est quelqu’un qu’il est facile de croiser dans différentes communautés, par Exemple, à Agile France. Aujourd’hui, il vient nous parler d’Open Data Gouv, un projet dans lequel il est pleinement impliqué. A la base, il s’agit d’un projet de référencement des données libres. La première question qui s’est posée est : comment évaluer le succès. Par le nombre de réutilisations, par le nombre de personnes réutilisant ces données ! C’est une direction qui a induit la voie suivie par le site qui est passé d’un CMS a un réseau social, et s’est efforcé de suivre les canaux d’engagements.

Cette plateforme s’est voulue résolument en rupture avec les règles établies de l’administration, d’où la nécessité de la créer en dehors d’elle ! Car on ne peut innover dans la structure, on ne peut qu’y reproduire ses codes. Au contraire du principe de méfiance qui prévaut dans l’adminsitration, tout ici est basé sur la bienveillance avec un contrôle à postériori, car les utilisateurs peuvent publier leurs données ! Ils peuvent même reprendre les bases de l’administration pour les rendre plus exploitables ! En pratique, il y a peu de spam.

image

Le co-design est aussi un pilier important de ce travail. Il permet essentiellement deux choses :

  • Engager les personnes dans la création du produit. Celui-ci étant développé selon un cycle Lean Startup.
  • Régler le problème du « démarrage à froid » propre aux réseau sociaux : lors de l’ouverture des portes, il y a déjà beaucoup d’inscrits !

Pour autant, beaucoup d’obstacles se dressent :

  • Ouvrir les portes de l’entreprise pour y mettre l’utilisateur, voilà qui n’est pas naturel !
  • Certaines organisations ont transformé le monopole sur certaines données en rente économique … quand bien même celles-ci sont de mauvaise qualité !

Le but d’opendata.gouv et de libérer les données, inviter tout un chacun à y contribuer, bref faire jouer le crowdsourcing à l’image d’openstreetmap.org ou d’openfoodfacts.org que nous venons de voir. On ne peut avoir des référentiels larges et profonds seuls, il est indispensable de mener ce travail collectivement.

Un point réccurent du raisonnement de Pierre est la recherche des « irritants », il appelle ainsi des problèmes qui se répètent sans arrêt. Ces irritants sont l’occasion de développer de nouvelles possibilités. C’est ainsi qu’est né le Marché Publique Simplifié.

En conclusion

Nous avons eu la chance d’avoir deux interventions non seulement très vivantes, mais aussi très riches. Bien sûr, pour Pierre, on savait déjà. Cela dit ce meetup se distingue surtout par son thème éthique : faire du bien à la société, apporter une destruction créatrice.

Sur ce, je dois me sauver, une Scrumbeer (ou ce qu’il en reste) m’appelle…

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

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 : Business Process management with JBoss jBPM, par Matt Cumberlidge

Note : 3 ; Ciblant l’analyste, un ouvrage trop superficiel et d’avantage focalisé sur le processus de réalisation que sur l’outil ! Dommage.

Difficile de faire autrement que de comparer ce livre à son pendant adressant OSWorkflow ! Même type d’ouvrage, même éditeur et même taille, l’auteur du premier est même relecteur du second. Bref, deux ouvrages courant dans la même catégorie ! Mais autant j’ai été accroché par le premier, autant j’ai été déçu par celui-là. Explications.

En réalité, dès le départ, on s’aperçoit que cela va être difficile : le premier chapitre n’évoque guère jBPM en guise d’introduction. On y évoque plutôt le processus d’analyse et de modélisation. Va pour les 20 premières pages.

Le second chapitre évoque de manière plus détaillée le processus de modélisation du BPM à l’aide d’une étude de cas ici introduite. Ce livre n’étant pas réellement un ouvrage de BPM, le traitement de ce sujet est quelque peu léger, sinon naïf. Et l’on est arrivé page 52 (sur 200) et toujours pas de jBPM à l’horizon.

On en parle enfin au chapitre 3, où tout le processus d’installation et de configuration est détaillé, un peu trop à la façon « pour les nuls » à mon goût. Mais on finit quand même par aborder le sujet qui m’intéresse ici en premier lieu, c’est-à-dire jPDL (on est quand même page 74). Au final nous avons quand même droit ici à 25 pages de matière réellement pertinente.

Le chapitre 4 évoque l’interface utilisateur, c’est-à-dire les formulaires JSP que l’on peut construire directement sur la plateforme jBPM.

Le chapitre 5 revient sur le leitmotiv des auteurs : le processus de développement. Nous avons toutefois droit à 7 pages particulièrement intéressantes sur l’intégration de systèmes : juste de quoi nous mettre l’eau à la bouche, mais clairement pas assez pour nous délivrer une information pertinente et utilisable !

Le chapitre 6 « proof of concept implémentation » noie pas mal d’informations importantes sous couvert de processus de développement (encore lui), mais sont toutefois évoqués : configuration, déploiement et même monitoring et BAM avec la plateforme SeeWhy. Ce dernier volet est tout à fait intéressant, à la fois par l’évocation de SeeWhy que par le fait que l’intégration en est bien décrite.

Le dernier chapitre sur le « process improvement » n’est que du bla-bla, oubliez-le.

Bref, ce livre est une grosse déception, je n’y aie trouvé que 50 à 60 pages d’informations utiles. D’un autre coté je n’ai pas ici une couverture complète du sujet me permettant de jauger si cet outil correspond à mes besoins. Je doute que vous-même y trouviez votre bonheur.

image

Référence complète : Business Process management with JBoss jBPM, a practical Guide for Business Analysts – Matt Cumberlidge – Packt publishing 2007 – EAN: 9 781847192 36 3

Business Process Management with Jboss Jbpm

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

Note de lecture : OSWorkflow, par Diego Adrian Naya Lazo

Note : 7 ; Un tour d’horizon clair concis et efficace

Est-il possible de faire un tour d’horizon introductif d’OSWorkflow en moins de 200 pages ? De toute évidence : oui, et cela sans faire particulièrement de concessions au sujet traité. Cet opuscule est en effet découpé en 8 chapitres, chacun focalisé sur une facette précise.

Le premier chapitre, comme il se doit traite de la vue d’ensemble d’une SOA animée par un moteur d’orchestration et de la vue de cette architecture par le WfMC. 20 pages suffisent à cela.

Le second chapitre nous donne déjà toutes les clés sur les capacités d’OSWorkflow en nous présentant les éléments les plus importants de la définition d’un workflow avec OSWorkflow et comment le tester !

A partir du chapitre 3, on rentre dans des aspects plus pointus : écrire du code Java qui s’interfacera avec le moteur de Workflow ! Les choses sont exposées simplement et progressivement, on n’est jamais perdu.
Le chapitre 4 termine les aspects applicatifs généraux en évoquant l’intégration du moteur au sein d’une application.

C’est à partir du chapitre 5 que sont traités les aspects avancés. Ils ouvrent de nouvelles perspectives et sont rafraichissants sur ce point. Le chapitre 5 (justement) est un bon essai en ce sens, mais tout en donnant une bonne idée sur ce qu’est l’intégration d’un moteur de règles, il n’est guère convaincant. Et quitte à parler Open-Source, pourquoi ne pas avoir plutôt évoqué Jess ?

L’intégration de Quartz, évoquée au chapitre 6 est plus intéressante, car elle permet d’imaginer des architectures non seulement basées sur des workflows, mais également asynchrones . Là encore les exemples sont suffisamment simples et complets pour donner une bonne idée de la chose.

J’ai particulièrement apprécié le chapitre 7 et son traitement des CEP (complexe events processing) avec ESPER. C’est en fait la première fois que je vois évoqué concrètement la mise en œuvre de ce concept. Bravo !

Le chapitre 8 est un peu l’inattendu de cet ouvrage, puisqu’il ne traite rien de moins que le BAM ! L’implémentation est faite avec Pentaho BI (qui est plutôt une suite qu’un framework Open-Source), mais l’ensemble est convaincant.

Voici donc un opuscule qui remplit globalement ce que l’on attend de lui : un tour d’horizon du moteur de workflow, avec des exemples. Il vous sera incontestablement utile si vous souhaitez mettre en œuvre OSWorkflow, mais seulement au début, car il limite ses ambitions aux aspects introductifs, ce qui constitue le point faible du livre.

image

Référence complète : OSWorkflow, a guide for Java developers and architects to integrating open-source Business Process Management – Diego Adrian Naya Lazo – Packt Publusing 2007 – EAN : 978 1 847191 52 6

Osworkflow: A Guide for Java Developers and Architects to Integrating Open-Source Business Process Management

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

Note de lecture : Service Oriented Java Business Integration, par Binildas C. A.

Note : 7 ; Du concret sur l’ESB, mais un texte qui accuse aussi son âge…

Pas facile de s’y retrouver au sein du concept technico-marketing qu’est l’ESB ! Ce dont on a surtout besoin, c’est du concret. Et c’est exactement ce que l’auteur nous propose ici. Malgré son titre généraliste, le livre se focalise presqu’exclusivement sur la mise en œuvre de l’ESB open-source d’Apache, ServiceMix et de la norme JBI qu’il dessert.

En fait, les 2 premiers chapitres sont consacrés à la vue générale des problématiques d’intégration. Le premier chapitre présente les banalités habituelles sur l’ESB (mais plutôt bien présentées) et le second se focalise sur l’aspect plus technique en introduisant JBI et les « integration patterns ». Ce n’est qu’au chapitre 3 (on est déjà page 57) que ServiceMix, ou plutôt la vue globale de son architecture, est introduit.

A partir du chapitre 4, on passe en revue les différents types de binding, selon une complexité croissante. Tout d’abord un binding simple, dit conventionnel (chapitre 4), puis un binding « contract last » avec XFire (chapitre 5). Un binding plus complexe à trois niveaux est abordé au chapitre 8, mettant en œuvre des EJB, tandis que le binding de POJO est enfin abordé au chapitre 9. Puis c’est le tour de l’approche « gateway » ou « contract first » avec Axis (chapitre 10).

Les chapitres 6 et 7 font figure d’interludes. Il était difficile d’aller bien loin sans aborder les concepts de packaging et de déploiement des services ServiceMix, c’est chose faite au chapitre 6. De même, il est parfois utile de compléter la panoplie de bindings proposés par l’ESB, c’est l’objet du chapitre 7.

La problématique du transport est aussi un domaine où l’ESB permet une certaine souplesse. Le chapitre 11 montre comment accéder un Web Service au travers de JMS. Au chapitre 12, on voit comment effectuer le binding entre Java et XML (le langage natif de l’ESB) en utilisant en autre XStream. Enfin le chapitre 13 aborde le point plus complexe mais aussi plus exotique des proxys JBI.

Les derniers chapitres peuvent être vus comme des aspects avancés, donc pas forcément indispensables de prime abord. Le chapitre 14 aborde la problématique de versioning des Web Services, utile dans le cadre d’un SI « évolutif ». Le très long chapitre 15 traduit en services ServiceMix de nombreux integration patterns. L’agrégation de services est abordée au chapitre 16. Il s’agit d’un sujet plutôt avancé et c’est tant mieux car le propos n’est pas des plus clairs. On finit en ordre dispersé par un chapitre fourre-tout, avec les transactions, la sécurité le clustering et la vie des bêtes au chapitre 17. J’espère qu’il y a mieux ailleurs car ce n’est pas la joie.

Comme on le voit, c’est un tour d’horizon plutôt complet qui nous est proposé sur 400 pages. Il s’adresse clairement aux architectes. On y aborde les concepts et le code. Si le code Java est clair, il est fort dommage (et c’est mon reproche principal) que les configurations ServiceMix pourtant complexes soient aussi peu décortiquées. Leur compréhension reste ardue.

Ce type d’ouvrage est hélas sujet à l’obsolescence. Ne nous voilons pas la face, c’est bien le cas ici. ServiceMix (pour ne parler que de lui) a déjà changé de version majeure depuis un moment. Il n’a plus nécessairement la pertinence qu’il avait au moment de sa sortie…

service-oriented-java-bi

Référence complète : Service Oriented Java Business Integration – Binildas C. A. – Packt Publishing 2008 – EAN : 978 1 847194 40 4

Service-Oriented Java Business Integration

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

Google moves from MySQL to MariaDB

nosql:

Jack Clark for TheRegister quoting Google senior systems engineer, Jeremy Cole’s talk at VLDB:

“Were running primarily on [MySQL] 5.1 which is a little outdated, and so we’re moving to MariaDB 10.0 at the moment,”

I’m wondering how much of this decision is technical and how much is political. While Jack Clark’s points to the previous “disagreements” between Google and Oracle, when I say political decisions I mean more than this: access to the various bits of the code (e.g. tests, security issues), control over the future of the product, etc.

Original title and link: Google moves from MySQL to MariaDB (NoSQL database©myNoSQL)

J’avais déjà évoqué la chose précédemment, aujourd’hui le mouvement est clairement enclenché : c’est la totalité des instances MySQL qui passent sur MariaDB !

Les raisons qui conduisant à ce changement n’ont probablement pas la limpidité de la déclaration officielle. Le “vieillissant” MySQL est certainement l’un des facteurs, cela m’étonnerait que ce soit le principal. Pour ma part j’évoquerais en priorité :

  • Une dépendance à Oracle qui gêne le géant de Mountain View
  • Un manque pratiquement total de possibilité d’agir sur la base de code, les tests n’étant plus accessibles.

En contrepoint, le fait de travailler avec un petit éditeur qui a besoin d’une solide référence et qui est donc prêt à se plier au désidérata du géant de l’Internet a un intérêt évident…

Google moves from MySQL to MariaDB