Valentin Jacquemin

Critique de livre: La Religieuse de Denis Diderot

Diderot révèle au moyen de ce roman les affres du monde religieux de son époque. Ce roman suit, semble-t’il, une affaire révélée au grand public mettant aux prises une religieuse ayant voulu faire annuler ses voeux. Celle- ci en est allée jusqu’au tribunal, mais malheureusement pour elle sans succès. Le roman met en oeuvre une religieuse, du nom de Suzanne, qui est envoyée au couvent sans avoir droit au chapitre. Principalement du fait que cette Suzanne serait née d’un autre père que ses deux soeurs ainées, histoire de famille donc… Il s’ensuit que pour Suzanne c’est loin d’être la vie rêvée! Elle finit par sortir du couvent une première fois pour rapidement se retrouver dans un autre… Eh oui Suzanne n’a pas de chance dans la vie! Ce n’est qu’après un dernier transfert qu’elle se trouve dans un troisième couvent où elle sera bien traitée. La vie semble - enfin - lui sourire. Au cours de ce troisième séjour, Suzanne explique toutes ses mésaventures à la mère religieuse. Cette mère-ci est d’ores et déjà très attachée à Suzanne et prend particulièrement à cœur les épreuves de Suzanne jusqu’à dire:

Il n’y a que dans les couvents où l’hummanité puisse s’éteindre à ce point. Lorsque la haine vient à s’unir à la mauvaise humeur habituelle, on ne sait plus où les choses seront portées.

Pleine de compassion, il s’ensuit une relation vraiment spéciale entre Suzanne et cette mère religieuse… Ca en devient érotique par moment et je dois dire que ça m’a pas trop conquis! Bref, je conseille cette lecture à qui veut lire du Diderot mais qui n’a pas peur d’entrer dans l’intimité de deux femmes ayant plus qu’une amitié platonique (bien que Suzanne soit toute naïve du début à la fin).

Pour aller plus loin

Une analyse de l’oeuvre: http://membres.lycos.fr/jccau/ressourc/romem/diderot.htm

Résumé 2008

Avec un peu de retard, je voulais quand même faire un petit bilan de 2008 et poser quelques objectifs sur l’année 2009.

Le boulot

2008 a marqué mes réels débuts au sein de Logica. Après mon stage de 3 mois à Lyon, j’ai débuté ma première mission chez Merck Serono où je travaille encore actuellement. Le métier de consultant est enrichissant et offre la possibilité de progresser dans beaucoup de domaines. Très heureux de pouvoir profiter de cette opportunité, je tiens encore une fois à remercier (si elle me lit) Patricia. Merci de m’avoir donné ma chance!

Le développement

Côté technique, j’ai passé la grande majorité de 2008 à coder en PHP - PL/SQL (Oracle) - HTML/CSS - JavaScript (YUI). Sur la fin de l’année j’ai également eu le plaisir de débuter un projet à temps partiel en Java (Spring, Hibernate, Castor)… A nouveau: très satisfaisant!

Lectures

Sur mes lectures de 2008, il m’est tout bonnement impossible de ressortir qu’une oeuvre du lot. Voici un petit melting pot de mes lectures préférées sur l’année:

Ces bouquins ne quitteront pas de sitôt ma bibliothèque!

PoXd

Au niveau de ce blog, il y a eu du changement en un an avec la phase relooking dont je suis assez satisfait bien qu’il me reste encore une ou deux choses à régler. La fréquentation est également montée d’un cran, mais ça flatte juste mon égo à la limite… Ce blog existe surtout à usage perso. Evidemment s’il devient utile à d’autres, j’en suis ravi! J’ai également publié davantage de billets sur la 2ème moitié de l’année. En espérant pouvoir continuer sur ma lancée en 2009…

2009

Dans un an il y a 2 choses principales que j’aimerais pouvoir dire:

  1. “J’ai terminé la lecture de SICP et - surtout - compris tout ce que j’y ai lu.” C’est un challenge, je l’ai toujours en tête et je fais ce que je peux pour le remporter mais c’est loin d’être facile!

  2.  “Voici ma première contribution à un projet Open-Source (autre qu’un projet perso).” J’ai déjà quelques idées de ce côté-là. Celà demande un peu d’investissement mais je suis persuadé que celà en vaut largement la peine. En plus le développement me passionne alors…. 

Au-delà de ces objectifs, j’aimerais beaucoup développer mes compétences business et élargir toujours plus mes contacts. J’ai beaucoup à apprendre de ce côté-là mais je préfère mettre plus l’accent pour le moment sur mes compétences techniques.

C’est reparti pour une année, rempli de volonté et de bons objectifs, souhaitons-là autant enrichissante!

Tests unitaires JavaScript avec YUI

La méthodologie TDD, on l’a vu, propose d’écrire les tests comme première étape de code. Mais comment s’y prendre en JavaScript? Jetons un oeil à la solution proposée par les développeurs Yahoo! Ceux connaissant Java ont l’habitude des frameworks tel JUnit ou encore TestNG. Le principe est le même avec YUI Test (développé donc par Yahoo!) qui va être utilisé lors de cet article. Si maintenant nous entrons dans le coeur du sujet, imaginons que nous ayons à programmer une fonction qui vérifie que l’entrée d’un formulaire est bien un nombre. Si l’on suit la méthodologie TDD, on écrit d’abord le test de cette fonction. Cela va donner quelque chose comme ça:

var oTestCase = new YAHOO.tool.TestCase({
    name: "Test Common Fonctions",
    setUp : function () {
        this.data = [-1,1,' -1', '+1', 'a234', '034'];
    },
    tearDown : function () {
        delete this.data;
    },
    testIsNumber: function () {
        var n, notN, result;
        n = this.data[0];
        result = isNumber(n);
        YAHOO.util.Assert.isTrue(result);
    },
});

Quelques explications sont peut-être nécessaires:

Passons maintenant à la deuxième étape: l’implémentation de notre fonction isNumber:

function isNumber(chain) {
    try {
        intval(chain);
        return true;
    } catch (e) {
        return false;
    }
}

Nous avons donc notre implémentation de prête. L’exemple est ici très simple et j’espère qu’il ne déssert par la méthodologie dans le sens que ce n’est pas une perte de temps que de commencer par les tests. Un code dont on prend la peine de bien tester devient vraiment robuste et facilement maintenable. Le développeur garde également confiance en son code et si un nouveau développeur vient sur son code il peut rapidement se faire la main simplement en parcourant les tests! Bref, de nombreux avantages… Maintenant pour lancer les tests, c’est comme toujours très simple avec YUI:

YAHOO.tool.TestRunner.add(oTestCase);
var oLogger = new YAHOO.tool.TestLogger();
YAHOO.tool.TestRunner.run();

Et encore uniquement les deux dernières lignes sont nécessaires! En ajoutant la première on a l’avantage d’avoir un affichage plus précis sur une console comme celle-là:

Console YUI

Simple non? La documentation fera découvrir encore d’autres utilisations possibles de YUI Test mais encore une fois, je ne peux qu’encourager cette méthode de développement qui facilitera la vie à bien plus d’un!

Pour aller plus loin

Critique de livre: Un risque calculé de Katherine Neville

C’est histoire est sympathique et agréable. A découvrir par un dimanche pluvieux devant la cheminée… L’histoire tourne autour de Vérity Banks qui voudrait faire payer les banquiers verreux et corrompus. Elle-même travaille dans le mileu, à la sécurité plus particulièrement. Elle se lance alors dans un défi de plus grande envergure que ce qu’elle imaginait au départ et ce à cause (ou grâce) de Zlotan Tor… C’est assez bien écrit bien que ce ne soit pas l’histoire la plus captivante que j’ai lue. Si le milieu bancaire ou informatique vous intéresse, je vous le conseille. Sinon je ne pense pas trop qu’il en vaille la peine.

Les tekos sont plus proches des ordinateurs que de leurs congénères. Ils travaillent mieux la nuit, quand tous les animaux, à l’exception des rapaces, sont allés se coucher. Ils mangent peu et n’importe quoi, sans aucun souci de gastronomie. Ils ne voient jamais le jour. Ne respirent jamais de l’air frais. Ils ne s’épanouissent qu’à la lumière artificielle, dans une atmosphère climatisée. S’ils se marient, s’ils font des enfants, ils les répartissent en analogiques et en numériques. Ils peuvent se montrer arrogants, désordonnées, incontrôlables et antisociaux. Je sais tout sur les tekos, parce que je suis de la même race.

DOM et ses bonnes pratiques

J’ai terminé le visionnage d’une série de 3 vidéos concernant les bonnes pratiques sur du traitement DOM. Je voulais en garder une trace parce que ces vidéos contiennent vraiment des choses intéressantes…

Ceci n’est pas une introduction à DOM. Si cet acronyme vous est inconnu vous n’êtes pas sur le bon article, un bon point de départ: Wikipedia

Présentateur: Douglas Crockford

Gestionnaires d’événements

Il existe pas moins de 3 méthodes pour affecter une fonction à un type d’événement sur un noeud:

Pour bien faire, il faut utiliser les 3! Vive le monde du web… En plus IE possède une variable globale event contenant les données de l’événement (source, target, etc.) alors que le W3C recommande le passage d’un paramètre au gestionnaire contenant ces données…

Fuites mémoire

Toujours prendre bien garde que IE 6 utilise une stratégie minimaliste concernant la gestion de la mémoire. Cette stratégie se base sur un entier incrémenté lorsqu’une nouvelle référence à un objet se crée et décrémenté lorsque cette référence est supprimée… Le problème surgit lorsqu’une application met en oeuvre des références circulaire (explications et exemples sur cet article de Crockford). Cette gestion peut facilement occasionner des fuites mémoires et ce particulièrement lorsque les gestionnaires d’événements interviennent. IE crée une référence cyclique entre le noeud DOM sur lequel on attache un gestionnaire et le code de ce gestionnaire lui-même (dans le cas où ce code utilise le noeud - donc très souvent), c’est là qu’est le problème… Ce qui fait qu’il faudra explicitement mettre à null tous les membres d’un noeud étant une fonction avant de le retirer (ou de le remplacer, attention aussi par l’intermédiaire de innerHTML) du DOM sous peine de voir proliférer des zones mémoires occupées et qui le resteront tant que IE reste ouvert!

Tips

Pour simple rappel perso je publie ici encore quelques conseils à ne pas oublier:

Quelques indices bon à savoir pour créer une application web toujours plus performante! Note: utiliser un framework comme YUI simplifiera souvent beaucoup les choses.

Conception et développement Spring - 3ème jour

Ces 3 jours de formation ont été vraiment sympa. Ils m’ont permis de surtout en apprendre au niveau conception par rapport à l’intitulé du cours. Comme j’avais déjà parcouru le livre Spring In Action, les infos révélées en rapport à Spring lui-même ne m’ont pas été d’un grand apport. Merci donc à Logica pour cette sympathique opportunité! Le 3ème jour a été passé à implémenter la solution finale du cas d’authentification avec une intégration d’Hibernate et Struts. Je mets le code source à disposition comme simple référence. Le zip contient un versioning de chaque étape que l’on a suivi en cours. Si vous avez des questions n’hésitez pas à me contacter!

JavaFX 1.0 est sorti!

Le domaine des applications riches m’intéresse toujours plus et j’ai de la chance parce qu’en ce moment l’activité dans le domaine est chargée! Adobe prépare Flex 4 et Catalyst, Microsoft s’ouvre aussi avec Silverlight… Et aujourd’hui Sun s’y met avec son nouveau-né: JavaFX. Ca m’intéresse tellement que j’en avais ouvert un blog il y a 6 mois de cela (plus très actif pour le moment mais j’avais commencé un petit tuto sur JavaFX).

Donc aujourd’hui c’est JavaFX qui est au centre du sujet, que fait valoir Sun pour ce nouveau venu? Alors en bref:

On se trouve donc à la version 1.0 de la plateforme, logique que l’on se trouve loin (très loin) de ce qu’offre Flex par exemple en terme de composants. Mais le fait que ce soit du java n’est vraiment pas pour me déplaire, ce langage m’a toujours bien plu. Le problème c’est que sans composants à mettre en avant il va être difficile de mettre en place des applications riches en entreprise… Cependant l’un des atouts majeurs de Java est d’avoir une communauté énorme de plus composée de grands talents. On peut donc espérer voir arriver bientôt un nombre important de jolies démo. Un autre point important à relever est la richesse de Java sur lequel se base JavaFX. Le nombre de librairies venant par exemple d’Apache est bien là pour démontrer la richesse de la communauté. Toutes ces librairies sont toujours utilisables depuis JavaFX, en ce sens Java a un bon coup à jouer. Last but not least, un nombre impressionnant d’applications tournent en entreprise sur Java et ce que ce soit desktop, web ou même mobile. Un point de plus donc qui fait penser que l’adoption de JavaFX peut se faire rapidement… On verra.

Pour aller plus loin:

Test Driven Development et JavaScript

TDD est une méthodologie bien connue – devrait en tout cas – des développeurs, mais l’appliquez-vous à votre code JavaScript? Personnellement, moi non. En tout cas pas jusqu’à maintenant… Je dois dire que je n’y prêtais même pas attention, je fonçais tête baissée dans le code et ensuite hop je lançais firebug et essayais de voir ce qui n’allait pas. Pour moi, le développement JavaScript n’était pas vraiment ma tasse de thé mais il est évident qu’en procédant de cette manière, il était difficile d’espérer une autre issue Voyons donc ce que la méthodologie TDD peut apporter en terme d’efficacité et de professionalisme. Mais qu’est-ce que TDD, quels en sont les avantages, et comment l’appliquer au code JavaScript? Je vais essayer de répondre à ces questions dans cet article.

Qu’est-ce donc que TDD

TDD est une méthodologie de développement faisant la part belle aux tests unitaires. Dans la pratique cela voudra dire que les tests se feront avant le code à proprement parler. Schématisons tout ça:

Méthodologie TDD

Le processus est très simple – si l’on prend une fonctionnalité précise à implémenter:

  1. Conception: étape où l’on définit la fonctionnalité, où l’on réfléchit à l’interface et aux paramètres d’entrée et de sortie nécessaires à son fonctionnement
  2. Écriture des tests: la réponse à “comment mon code doit se comporter” – suivant ces données en entrée, je m’attend à cet état en sortie
  3. Code: implémentation de la fonctionnalité
  4. Lancement des tests sur le code: si les tests révèlent une erreur, retour à l’étape 3 et ainsi de suite jusqu’à ce que tous les tests soient réussis

Au premier abord, il peut paraître étrange d’écrire des tests sur du code que l’on a même pas commencé à écrire. Mais comme on va le voir, plusieurs avantages ressortent de cette manière de faire.

Ses avantages

Écrivez en premier lieu les tests unitaires de vos fonctionnalités et vous verrez alors – dans le désordre – que:

Sûrement que d’autres bienfaits ne sont pas sortis de mon cerveau à temps pour les lister ici mais c’est déjà pas mal! Ces avantages en valent certainement la peine encore faut-il essayer cette méthodologie! Dans le cas présent je voulais l’appliquer à du code JavaScript. Quelles sont les possibilités de ce côté-là?

YUI Test

YUI est un framework javascript développé par YAHOO! qui fournit de nombreux composants graphiques mais pas seulement. Bref, si vous ne connaissez pas je vous encourage vivement à y jeter un oeil, il facilite beaucoup les choses… Au passage, lire les sources du framework peut être une très bonne idée dans le but d’améliorer ses compétences dans ce langage. Le framework lui-même contient une batterie de tests complète pour chaque composant, rien de tel pour se former! Ce framework fournit les bases nécessaires pour se lancer de l’écriture de tests unitaires javascript. Par l’intermédiare des classes YAHOO.tool.TestCase, YAHOO.tool.TestRunner et YAHOO.tool.TestLogger tout est prêt pour se lancer! Il permet de plus de simuler des événement utilisateurs comme un clic de la souris. Last but not least, ce framework est compatible avec la majorité des browsers, donc plus (ou presque) de soucis à se faire!

Conception et développement Spring - 2ème jour

Après le 1er jour, nous avons pu voir comment séparer convenablement les couches d’une application et une première piste pour modulariser celle-ci. Modularisation grace au modèle de conception Factory Method. Durant le deuxième jour, nous avons vu comment aller plus loin avec l’introduction de l’inversion de contrôle.

Inversion de contrôle

Ces trois lettres ont été longtemps à la mode sur la toile: IoC ou Inversion of Control. Ce modèle est la base du container de Spring et bien que je connaissais déjà Spring avant cette formation, j’ai eu un véritable plaisir à suivre la méthodologie adoptée, à savoir implémenter les concepts de Spring nous-mêmes pour découvrir les avantages à l’utiliser. Lors du premier jour, l’abstraction au moyen du modèle Factory Method a permis de bien délimiter les différentes couches applicatives et de maintenir une certaine indépendance entre elles.

Avant d’arriver concrètement à l’inversion de contrôle il nous a fallu élever à un niveau encore supérieur nos factories. Une Factory Application. Suite à cette refactorisation, nous nous retrouvons avec plus qu’une seule Factory utilisée pour récupérer chaque couche applicative (cf. schéma).

L’inversion de contrôle trouve tout son sens à partir de là. Puisqu’il est possible d’avoir une seule Factory pour chaque module, pourquoi ne pas en externaliser l’implémentation et la gestion afin de développer nos applications de manière modulaire? C’est ce que Spring fait (entre autre).

Le reste de la journée a été passée à implémenter l’étude de cas en utilisant Spring et en intégrant une Datasource. L’objectif de cette retrospective n’est pas de montrer du code mais plutôt d’insister sur la conception. Je publierai plus tard un billet conernant l’utilisation de base de Spring.

OSGI

Notre prof n’a fait qu’une toute petite parenthèse sur OSGI mais c’est un élément qu’il me faut aborder et creuser à l’avenir. Encore un acronyme très à la mode actuellement. Voici un extrait de ce que nous dit Wikipedia sur le sujet:

une plate-forme de services basée sur le langage [Java][5] qui peut être gérée de manière distante. Le cœur de cette spécification est un framework (cadriciel) qui définit un modèle de gestion de cycle de vie d’une application, un référentiel (registry) de services, un environnement d’exécution et des modules. Basés sur ce framework, un grand nombre de couches (Layers) OSGI, d’API et de services ont été définis

Plutôt pas mal dans l’objectif de modularisation d’applications… A investiguer…

Ce deuxième jour nous a donc appris ce que faisait Spring en le mettant en oeuvre par nous-même pour ensuite commencer à réellement l’utiliser. L’étude de cas est utilisable en fin de journée mais uniquement en interrogeant une base de données au travers de JDBC. Le dernier jour, nous avons appris à intégrer deux frameworks ultra-connus: Hibernate et Struts.

[5]: http://fr.wikipedia.org/wiki/Java_%28langage%29 (Java (langage))

Conception et développement Spring - 1er jour

Paris m’accueille parée de bleu pour cette formation Spring que j’espérais enrichissante. Le 1er jour ne m’aura pas déçu! Le formateur nous a donné pour commencer les différents points développés durant cette formation:

  1. Paysage web actuel
  2. Fondamentaux Spring (2ème jour)
  3. Intégration de différents frameworks au moyen de Spring (2ème et 3ème jour)

Paysage actuel

Autrement dit quels frameworks sont à notre diposition actuellement pour réaliser nos applications web ((Je focalise bien sûr ici sur les solutions Java JEE))? Le bilan est une longue liste partageable en 3 couches:

L’idée ici est de montrer que le paysage est plutôt chargé et que si nous désirons utiliser plusieurs de ces frameworks (ou d’autres) il serait pratique de pouvoir facilement les emboîter. Bon c’est pas trop difficile à deviner, dans notre cas Spring sera la solution dédiée. Solution qui s’affirme plus clairement de jour en jour à (pratiquement) toute solution JEE. Voici donc la première chose à retenir: Spring est (quasi de-facto) le socle de base d’une solution JEE utilisant plusieurs frameworks de différentes couches.

Objectif: modulaire

Le formateur nous le fait comprendre rapidement: une solution non modulaire est une solution destinée à l’échec. Et attention, la modularité technique (apportée grâce au modèle MVC) n’est pas une finalité! Ce que nous désirons ici en tant que concepteur d’applications c’est d’avoir également une modularité fonctionnelle. Autrement dit la possibilité de réutiliser certains services sur plusieurs applications avec le moins de codage possible (Plug and Play). Le bienfait de raisonner de cette manière? Le code produit devient facilement réutilisable et la maintenance sera un régal comparé à ce que l’on peut trouver sur certains projets… En effet passer par exemple de Hibernate v2 à v3 nous demandera de modifier uniquement le module persistance de notre application sans impacter le restant du code. De plus, d’un côté fonctionnel, nous pourrons par exemple réutiliser un service d’authentification de manière transparente sur une autre application… Et donc de ce fait, une meilleure visibilité, une meilleure productivité et une réelle valeur ajoutée grâce aux différents services réutilisables.

Etude de cas

Durant cette formation, nous mettons en oeuvre une étude de cas chère aux français: la gestion des congés (bon au final on s’est penché uniquement sur le module d’authentification). Nous avons ainsi débuté la conception de cette étude de cas en utilisant une distribution d’Eclipse que je ne connaissais pas personnellement, topcased. Cette distribution est fourni avec une perspective UML gratuite et open-source permettant de créer tous les diagrammes UML utiles à la conception d’applications. Pour cette phase de conception je découvre encore un nouvel élément: Le cycle en Y. J’y reviendrai plus tard… Comme décrit dans ce cycle, les livrables peuvent être dispatchés sur une architecture distribuée. Sur ce point, le formateur nous a précisé quelque chose d’intéressant concernant les machines virtuelles Java et leur capacité à monter en charge. En effet, un réflex lorsqu’une application à de la peine à tourner pourrait être de rajouter des ressources physiques (RAM et/ou processeur). Il faut cependant garder à l’esprit qu’une JVM ne pourra pas dépasser un certain plafond puisque le Garbage Collector effectuera son boulot sur une quantité de mémoire toujours plus grande et prendra ainsi toujours plus de temps à le faire. Ce plafond atteint, il ne servira à rien de lui donner plus de mémoire, la seule solution alors est d’ajouter un (ou plusieurs) nouveaux serveurs. A tenir en compte lorsqu’un serveur vendu avec une licence de plusieurs milliers de francs est choisi…

Conception

L’approche lors de cette formation a été à mon avis optimale. L’idée était de découvrir Spring en débutant par mettre en place son fonctionnement de base nous-même afin d’en discerner le comportement et par la même occassion les bénéfices d’une telle architecture. Après un bref résumé du modèle MVC et de son utilité dans la conception d’applications, la première étape dans cette découverte a été de mettre en place le modèle de conception Factory Method. Nous nous sommes ainsi retrouvés avec une factory sur les couches persistance et service comme le montre le schéma ci- contre. En mettant en place ce modèle nous garantissons la possibilité de changer d’implémentation de façon centralisée. De plus, il devient possible en suivant cette architecture de reprendre la couche service, persistance et entité et de réutiliser ce module dans une autre application. Nous avons donc là une modularité fonctionnelle! On approche une solution modulaire mais comme nous le verrons prochainement on peut encore faire mieux et c’est lors du 2ème jour de cette formation qu’on l’a vu.