Lausanne
Auteur : addinquy
Software Freethinker
Note de lecture : Spring Batch in Action, par A. Cogoluègnes, T. Templier, G. Gregory & O. Bazoud
Note : 7 ; Une qualité de prose qui fait honneur à la « in action » series, mais une lecture un peu lourde au total.
Mon premier contact avec ce livre a été teinté d’appréhension : il compte pas moins de 440 pages hors annexes, ce qui me semble beaucoup, je le dis sans ambage ! Puisque l’on en est aux présentations : le volume est découpé en 14 chapitres, eux mêmes regroupés en 3 parties. Il faut en plus compter une vingtaine de pages d’annexes. Cela nous donne une moyenne d’une trentaine de pages par chapitre. C’est beaucoup à mon gré, mais consistent avec le standard de la « in action » series. A propos de cette série, Manning fait beaucoup d’effort pour maintenir une ligne éditoriale de bonne qualité qui permet d’être rarement déçu avec chacun des opus. Nous verrons que ce volume fait honneur à la série.
La première partie s’intitule « background » et regroupe les deux premiers chapitres pour un total de 50 pages. Le premier d’entre eux nous fait faire le tour du propriétaire. Non seulement on y comprends l’architecture logique (finalement, Spring Batch c’est un framework-ETL Java) mais on va jusqu’à faire une mini-application de traitement (lecture, traitement et écriture) avec la configuration Spring correspondante. Impressionnant pour un premier chapitre !
Le second chapitre rentre plus avant dans les concepts sous-jacents du framework : job, métadonnées du job, step, etc… Le but de ce chapitre est de nous donner les clés pour décomposer une spécification de traitement en étapes décomposées. Bon boulot, à nouveau.
La seconde partie « core spring batch » est de loin la plus imposante du livre. Elle compte 7 chapitres et 225 pages. C’est donc un mini-livre à elle toute seule. C’est d’ailleurs à mon avis le problème le plus important du livre, mais je reviendrais là-dessus plus tard ! Le chapitre 3 qui débute cette seconde partie nous immerge dans la configuration des batches. Plus clairement : comment s’articule la configuration Spring d’une application Spring Batch. Il y a 5 niveaux d’entités hiérarchiquement emboitées à configurer (sans compter le repository de jobs) et le chapitre passe par le menu la manière de configurer tout cela avec les attributs qui vont bien. C’est un poil lourd, mais bien écrit.
Le chapitre 5 explore en profondeur la manière de lancer (et arrêter) les jobs : en ligne de commande ou en planifiant de différentes manières. Le tout est bien illustré par des diagrammes de séquence, entre autre chose.
Avec le chapitre 5, on attaque réellement le développement de traitements Spring Batch, en débutant par les composants de lecture. Le sujet est largement balayé en largeur sur 40 pages, que ce soit sur des fichiers plat, du JSON, du XML ou de l’accès aux bases de données. Rien à dire sur la manière dont le sujet est abordé, mais c’est quand même un peu long quand ce que l’on souhaiterait, c’est arriver au bout du chemin pour voir ce que cela donne !
Le chapitre 6 aborde fort logiquement le composant d’écriture. Si les aspects de base (field extraction, formatage) sont fort logiquement abordés, là aussi le sujet est abordé en largeur, avec non seulement l’écriture sur fichier, mais la production de XML, de file sets et l’écriture en base de données. Mais on aborde aussi l’écriture en flux JMS et l’envoi de mails. Là aussi je trouve que cela fait beaucoup pour une première passe, et paradoxalement, certains de ces sous-sujets sont traités un peu rapidement !
Toujours dans la même veine, le chapitre 7 nous présente les composants de traitement. Les items processors de Spring Batch recèlent nombre de richesses et il me semble difficile de faire des impasses par rapport à ce qui figure dans le texte. La lecture du chapitre me laisse cependant un léger sentiment de confusion, mais rien de bien grave. Les excellentes illustrations graphiques ou en code permettent de toute façon de se raccrocher aux branches.
Le chapitre 8 compte à peine 30 pages, mais elles recèlent une expertise qu’il serait dommage de rater. Il s’agit de la conception des reprises sur erreur avec Spring Batch. Excellent !
Cette seconde partie s’achève avec le chapitre 9 qui couvre l’aspect transactionnel des batches. Le sujet est traité de manière solide et claire en 25 pages, que ce soit sur les erreurs à ne pas commettre, sur la portée des transactions et les différents niveaux de transaction disponible (job, chunk,…). Rien à redire.
La 3ème partie du livre est consacré aux « sujets avancés » et le premier chapitre de cette partie, le chapitre 10, dédie 25 pages au contrôle d’exécution. Partage de contexte, flux alternatifs et même externalisation des définitions de job sont parmi les sujets traités.
Avec le chapitre 11, on commence à toucher du lourd, à savoir l’intégration d’entreprise. Les auteurs évoquent d’abord les styles d’intégration d’un point de vue architecture logique. Il n’est pas étonnant qu’ils fassent référence aux Enterprise Integration Patterns de Gregor Hope ! D’un point de vue pratique, la quarantaine de pages de ce chapitre s’appuie sur 2 fondations : Spring Integration d’une part et Spring MVC pour illustrer une intégration http/ReST. Il est juste dommage que les 2 approches ne soient pas mieux abordées en séquence afin de rendre la prose plus claire.
Ce livre ne rate pas le, oh combien important, sujet du monitoring. Le chapitre 12 fait du bon boulot là-dessus, que ce soit pour décrire la structure BDD supportant cela, pour décrire l’intégration JMX ou même pour éclairer l’usage de l’outillage prêt à l’emploi de Spring batch à savoir Spring Batch Admin ou JConsole.
Le chapitre 13 est vraiment un sujet avancé car il traite de scaling. Un chapitre sur lequel il est possible de faire l’impasse en première lecture.
Ce n’est pas le cas du dernier chapitre qui aborde la problématique des tests. Il le fait à 3 niveaux : tests unitaires, tests d’intégration et tests fonctionnels. Ces 3 niveau s’appuient sur JUnit est sur des helpers fournis par Spring batch. Je ne suis pas convaincu par ce qui est proposé du côté tests fonctionnels, mais les 2 autres niveaux sont OK.
Spring Batch in action est une bonne surprise. Les auteurs ont fait globalement un très bon travail à rendre le propos clair et l’apprentissage progressif. L bouquin reste hélas un gros pavé. Mais le framework est aussi beaucoup plus riche que je ne l’avais pensé au début. Pour en rendre l’abord plus digeste, je pense que les auteurs auraient dû découper la seconde partie en 2 : en traitant d’abord d’un cas d’utilisation simple n’utilisant qu’un sous-ensemble de chacun des 3 types de composants, puis une seconde itération pour les autres cas de figure. Au final, le volume du livre aurait un peu augmenté mais cela aurait permis au lecteur de faire l’impasse sur une centaine de page en première lecture !
Ce livre s’adosse à la version 2.1 de Spring batch, il est donc toujours parfaitement d’actualité, mais une révision sera certainement nécessaire quand la version 3.0 sera en GA.
Référence complète : Spring Batch in Action – Arnaud Cogoluègnes, Thierry Templier, Gary Gregory & Olivier Bazoud – Manning 2012 – ISBN : 978 1 935182 95 5
Don’t interrupt me while I’m interrupting.
Winston S. Churchill (from “The C++ Language”, by B. Stroustrup)
Web RTC
“RTC” comme “Real Time Communication” !
Cette présentation faite sur Prezi par Enrico Marocco nous expose les principe d’architecture Peer to peer du Web RTC.
Web RTC, comment en savoir plus ?
Le consortium Web RTC est soutenu par Google et Mozilla, entre autres, avec le but avoué de supporter cela dans leurs browsers respectifs. C’est également un groupe de travail à l’IETF ainsi qu’au W3C.
Voir aussi l’excellente présentation faite par Google lors du Google IO 2013 ; la vidéo de cette présentation est incluse dans les slides. La présentation faite lors du Google IO de l’année précédente mérite aussi que l’on s’y arrête.
En pratique…
Dans la pratique, il s’agit de 3 ensembles d’API :
- MediaStream API : Elle permet d’échanger vidéo et son, nottament.
- RTCPeerConnexion : qui permet de maintenir des connexions pair à pair entre machines pour échanger des streams. Cette connexion peut être obtenue avec ou sans serveur intermédiaire en fonction du protocole retenu. Hadopi aura peut-être quelque chose à dire là-dessus…
- RTCDataChannel : pour les échanges d’autres types de données, par exemple pour les jeux.
Note de lecture : C++ Programming style, par Tom Cargill
Note : 7 ; De bons conseils d’experts pour ceux qui pratiquent déjà le C++. Moins indispensable que les 2 livres de Scott Meyers.
Ce livre fait partie de la série d’ouvrages dont fait également partie “Effective C++”, qui constitue chacun des avis d’experts sur le développement en C++. Dans son volume, Tom Cargill s’attache à prodiguer des conseils sur la conception des classes en C++ : surcharge d’opérateur contre fonction membre, utilisation de l’héritage, etc… Il adresse donc des préoccupations différentes de celles de Scott Meyers. Un aspect non négligeable est la relative concision du texte qui noircit juste un peu plus de 220 pages avec une proportion de code je pense un peu supérieure à 30%. Le contenu, justement est divisé en 9 chapitre, le 10ème étant un résumé des règles établies au fil du texte.
Le premier chapitre couvre la notion d’abstraction. C’est réellement un fondamental de cet aspect de la conception, dans le principe indépendant de C++, mais illustré avec C++. Le second complète harmonieusement le propos en traitant de la consistance. Une approche intéressante qui consiste ici à s’intéresser à différentes facettes de la consistance d’une classe : contractuelle, sémantique et physique. Je mets dans le même lot de chapitres ayant d’avantage trait à la conception qu’au C++, le chapitre 3 traitant de « l’héritage inutile ». En gros, ce sont les cas où la délégation est préférable à l’héritage. Un chapitre un tout petit peu plus faible que les deux précédents.
On est d’avantage dans le C++ au chapitre 4 qui évoque les méthodes virtuelles. C’est un peu brouillon, difficile de voir où l’auteur veut en venir, Mais les conseils sont valables. J’ai préféré le chapitre 5 qui couvre la surcharge d’opérateurs, sujet délicat s’il en est.
Retour à des questions de conception au chapitre 6 qui est dédié au wrapping, en l’occurrence l’enrobage de familles de fonctions C dans des classes. Un sujet qui m’était important à l’époque et très bine traité ici.
Arrivée au choses sérieuse au chapitre 7 : l’efficacité. Un chapitre hélas un peu moins palpitant que ce que j’aurais escompté : ça tourne beaucoup autour de l’allocation dynamique, sur un cas d’étude « BigInt ». Les 35 pages de l’étude de cas qui suit ne sont pas mes préférées du livre. Un peu comme au chapitre 4, je ne vois pas trop où on veut en venir. Par contre le chapitre 9 sur l’héritage multiple est à lire absolument : il permet de bien appréhender les subtilités des différents cas de figure où l’héritage multiple peut vous entrainer.
C’est un livre moins indispensable que le Scott Meyers, mais d’une lecture agréable. Une des originalité du format de Tom Cargill est de proposer en fin de chapitre des références bibliographiques pour approfondir les sujets, et des exercices (hélas, sans les corrections). Comme je l’ai dit, le texte est concis : le lecteur non marathonien peur en venir à bout en une semaine ou deux. Si l’on peut s’estimer déçu en premier abord, je pense que ce texte permet surtout de renforcer les fondamentaux. A ce titre, c’est une très bonne lecture.
Référence complète : C++ Programming style – Tom Cargill – Addison Wesley 1992 – ISBN: 0-201-56365-7
Corrupt politicians make the other ten percent look bad.
Henry Kissinger
Scrum en 5 minutes !
On a souvent besoin d’initier des nouveaux venus n’ayant guère de connaissance de Scrum et hélas souvent peu de goût pour la lecture. C’est encore pire avec les managers …
Dès lors je ne demande que 5 minutes de leurs temps, disons peut-être 10 et je leur assène ce document : Scrum en 5 minutes !
Note de lecture : Le génie logiciel, par Ian Sommerville
Note : 8 ; Le tour du monde en 80 jours, version “méthodes” : bien écrit et qui permet d’avoir une vue d’ensemble, mais sans jamais approfondir un des aspects. Book of the year 1993 !
Le titre de l’ouvrage peut sembler pompeux… s’intituler ainsi « le génie logiciel » sous-entend que l’on a la prétention de faire le tour de la question. Il faut certes relativiser les choses (le texte original date de 1991), mais s’il y a bien un livre méritant ce nom, c’st celui-ci ! On pourrait dire que c’est une encyclopédie sur les méthodes de développement. Il aborde chacune des étapes de la réalisation du logiciel, depuis l’établissement du cahier des charges jusqu’aux tests, en exposant l’outillage méthodologique disponible à chaque étape. Voyons un peu ce qu’il a dans le ventre. Tout d’abord, le texte, c’est plus de 600 pages sur 31 chapitres en 5 parties. Il ne serait donc pas raisonnable de rentrer dans le détail de chacun des chapitres.
Ce ne sont pas un, mais deux chapitres introductifs qui précèdent la première partie. Et ils sont particulièrement avisés. Tout d’abord en présentant les différentes typologies de processus de développement (l’auteur les regroupent en 4 catégories), et ensuite en évoquant les facteurs humain : diversité des personnalités composant une équipe, dynamique de collaboration, etc… Nous ne sommes donc pas en présence d’un ouvrage abordant le développement logiciel d’un simple point de vue mécanistique. Très bien !
La première partie traite de la spécification logicielle. Ce ne sont pas moins de 7 chapitres et 170 qui sont consacrés au sujet. On commence par y aborder la définition du besoin sous l’angle du cahier des charges, cela permet de voir les composants qu’il regroupe et sert d’introduction pour les autres chapitres. Le volet modélisation accorde une place importante à l’analyse de points de vue, quelques approches complémentaires sont aussi abordées, mais ça reste un peu décevant. La spécification du besoin est passée rapidement, mais aborde quand même les besoins fonctionnels, non fonctionnels et la validation des besoins, mais il faut considérer ce chapitre 5 comme une simple introduction au sujet. Le prototypage est abordé dans une optique RAD au chapitre 6, mais je n’ai pas trouvé le propos très aiguisé. Spécification formelle et spécification algébrique sont les grands fantasmes des universitaires alors que leurs champs d’application sont anecdotiques. Bien qu’étant de bons compléments, je n’aurais pas consacré 2 chapitres au sujet, en fait 3 d’ailleurs car le chapitre 9 traitreusement intitulé « spécification basée sur les modèles » explore en fait le language Z…
La seconde partie consacrée à la conception du logiciel couvre 5 chapitres sur 110 pages. Si l’auteur voit juste sur les qualités attendues d’une bonne conception, sa vision strictement descendante du processus est erronée. La conception orientée objet, telle qu’exposée au chapitre 11 est par ailleurs en fait une approche d’analyse. L’auteur complète bien le tableau avec un volet « temps réel » logiquement focalisé sur les machines à états. C’est une bonne idée de terminer cette partie par la conception d’IHM, mais hélas ce chapitre 14 est bien peu solide. Bref, cette seconde partie est hélas bien faible.
La 3ème partie est consacrée à la programmation. Elle compte moins de 70 pages sur 4 chapitres. On commence de manière plutôt sympathique par un chapitre 15 dédié à la programmation de logiciels fiables. Il aborde quelques sujets chers au « code complete » et en est une bonne introduction. On passe ensuite à la réutilisation, un chapitre bien peu convainquant, comme l’est d’ailleurs le sujet lui-même. Les deux derniers chapitres sont dédiés à l’outillage (CASE tools et IDE), le livre a plus de 20 ans et le propos développé n’est plus d’actualité. Il n’était pas non plus excellent à l’époque. Comme dans beaucoup de traités sur le génie logiciel, cette partie est traitée de manière plutôt superficielle. Excepté le chapitre 15, on est loin d’un Code Complete ou d’un ouvrage orienté craftmanship…
La 4ème partie consacre un peu plus de 110 pages sur 6 chapitres à la validation. L’introduction au sujet est plutôt bonne, elle couvre les typologies et la compréhension illustrée de ce qu’est une stratégie de tests. Le chapitre 20 consacré à la fiabilité est assez pointu dans son propos, tout comme l’est le chapitre qui suit et lui fait écho sur la sureté de fonctionnement et la spécification de cette sureté. Le propos sur le test des défauts, quoique ancien pourrait être lu avec bénéfice par beaucoup d’équipes de développement, car il rappelle des fondamentaux. Outillage de test (circa 1990) et tests de vérification statiques ne sont pas mes sujets préférés, mais ils font partie de la culture informatique et ne sont pas mal traités.
La 5ème partie est dévolue à la gestion de projet. Ce sont 7 chapitre comptant une centaine de pages qui sont dédiées à ce sujet. Faut pas rêver, c’est du « à l’ancienne » ! On y parle organisation des équipes, planification et synchronisation des tâches (avec des Gant, et tout et tout…). Par contre le chapitre consacré à l’estimation avec le modèle COCOMO est pas mal, c’est une bonne introduction à ce model. Par contre le volet consacré à la maintenance est pratiquement sans intérêt. Le chapitre sur la gestion de configuration et la documentation sont assez ternes, tandis que si le sujet de l’assurance qualité sonne bien ses 20 ans, on y trouve quand même du propos de valeur.
Ce livre est construit à la base pour servir de support de cours. C’est en quelque sorte un tour du monde du génie logiciel en 80 jours. A ce titre, il est remarquable de complétude, bien qu’il pourrait être amélioré sur certains sujets (et il accuse aussi son âge). C’est ce que j’ai vu de mieux en la matière, et de loin ! Tel qu’il est, c’est une bonne introduction aux différents sujets et l’auteur fournit d’ailleurs des liens vers des ressources (livres ou articles) permettant de creuser chacun d’entre eux plus en profondeur. Le livre a été régulièrement réactualisé, il en est à sa 9ème édition (que je ne connais pas). Mais les avis sur ces mises à jour ultérieures semblent diverger…
Référence complète : Le génie logiciel – Ian Sommerville – Addison Wesley 1992 (V.O. : Software Engineering) – ISBN : 2-87908-033-9
When blame inevitably arises, the most senior people in the room should repeat this mantra: if a mistake happens, shame on us for making it so easy to make that mistake.
Eric Ries in The Lean Startup
MariaDB, plus fort que MySQL
On ne peut pas dire qu’Oracle se soit attiré la réputation d’une société ayant bien compris le modèle Open-Source. Parmi d’autres, MySQL en est une bonne illustration.
Ayant acquis la base Open Source par le biais de l’acquisition de Sun Microsystems, il me parait que le géant de la base de données a cherché avant tout à en faire un produit, plutôt qu’un projet open source. 3 éléments me confortent dans cette opinion :
- Oracle seul décide de la roadmap MySQL
- MySQL est positionné par l’éditeur en alternative à Microsoft SQL Server. Une stratégie perdante, car les produits ont un positionnement très différent.
- Oracle verrouille les développements (patch ou fork) en ne releasant plus les cas de tests depuis plus d’un an !
La fondation MariaDB
Dès le rachat de Sun, le créateur de MySQL Michael “Monty” Widenius a créé le projet MariaDB. Comme il l’explique son but à l’origine était de conserver la communauté historique des développeurs du noyau MySQL, noyau qui était en passe de disparaitre.
J’avoue que bien que ce fork ait maintenant plus de 3 ans, il a échappé à mon radar. Pas seulement au mien visiblement, car il semble que son existence fut jusqu’à une date récente assez discrète. Il aura fallu la création de la fondation MariaDB pour booster sa visibilité.
Aujourd’hui MariaDB offre une alternative à MySQL
- Compatible au niveau binaire
- Offrant de nouvelles fonctionnalités marquantes.
- Plus active que la base historique sur le volet des bus fixes.
MySQL semble avoir un peu perdu de vue sa nature première : non pas une base de données, mais un conteneur de moteur de bases de données. Tandis que MySQL vogue avec ses vieillissants MyISAM et Innodb, MariaDB nous propose de nouveaux engines: Aria, XTraDB (une évolution d’InnoDB), FederatedX (un engins utilisant d’autres SGBD en back-end), OQGRAPH (un moteur optimisé pour gérer les hiérarchies et les graphes) et SphinxSE.
Google à la rescousse
La communauté open source n’est pas la seule à s’inquiéter de la mainmise d’Oracle sur MySQL. Des sociétés de taille respectables pour lesquelles MySQL est une brique importante ont eu la même démarche.
L’annonce la plus marquante est sans aucun doute celle de Google annonçant un support au projet. Concrètement il s’agit d’y consacrer un développeur. Par rapport aux moyens dont dispose le géant du Web et l’importance structurelle de MySQL dans ses infrastructures, cela parait anecdotique, mais le message est là. D’après Widemius, d’autres société sont prêtes à aller dans le même sens, mais on n’a pas de noms…
Une alternative encore verte
Pour assoir une emprise sur le marché, il faut un packaging de bonne qualité. La fondation MariaDB propose des packaging prêts à l’emploi pour les plateformes Linux (Red Hat, Fedora, Debian, Ubuntu…) et Windows.
Mais point de distribution Mac ! Il faut passer par Homebrew avec compilation des sources et quelques petites manipulations … Ca ne va pas tout seul, autant le dire. Bref, ça va en rebuter quelques un. La fondation MariaDB explique que cette absence est due à leurs moyens limités.
Autre point faible : la documentation. Bon, elle existe, toutefois. Mais elle n’est pas vraiment au niveau. Pas de vrai autorail et les informations d’installations et de configurations sont assez éparses. Dans l’ensemble, les informations sont rassemblées sur le site ask monty. Bref, il y a encore à faire.
Côté bouquins, j’ai trouvé 2 titres sur MariaDB. Rien à voir avec la pléthore de livres sur MySQL.
Y aller ou pas ?
Aujourd’hui, je ne conseillerais à personne d’aller volontairement vers du MySQL, à moins que ce choix soit subordonné à un autre. Nombreux sont en effet les projets pour lesquels MySQL est sinon le choix par défaut, du moins un choix “pré-packagé”.
D’un autre côté, des distributions Linux commencent à venir avec MariaDB comme base par défaut en lieu et place de MySQL. De plus, il y a la “compatibilité binaire” revendiquée par MariaDB. Mais celle-ci doit encore se vérifier de contexte en contexte.
Côté Java, à priori MariaDB est toujours compatible avec le connecteur JDBC de MySQL. Mais il existe aussi un connecteur JDBC natif Maria DB.
La situation pour les autres langages est moins claire. Il existe bien un connecteur C dans ce qui est produit par la fondation, mais pour Python, Perl, etc… Il faut à priori utiliser les utilitaires gravitant autour de MySQL et faire des essais. Si l’on va faire un tour du côté de Stackoverflow, on voit que les choses ne sont pas si simples.
La tendance actuelle est un passage vers PostgreSQL (). Cette base est mieux qu’une alternative et est de plus en plus privilégiée à MySQL, non comme solution de replis mais en tant que solution techniquement meilleure.
Il me semble cependant qu’au vu de la roadmap déjà réalisée par MariaDB et de celle à venir, que cette alternative mérite considération, malgré les faiblesses dont il est fait mention.
