Ça fait un bout de temps que je ne suis pas revenu à Paris, à Place d’Italie pour être précis, en transport qui plus est. La dernière fois, c’était en 2012, pour une conférence organisée par l’équipe du Paris JUG. Comment ça s’appelait déjà ? Ah oui, c’était pour Devoxx France 2012. Du coup, à chaque fois que je fais le déplacement, c’est pour Devoxx. Les conférences se sont étalées sur trois jours et voici un résumé du premier, c’est-à-dire le mercredi.

Note 1 : Par avance, toutes mes excuses pour les points négatifs que je vais aborder… Je vais essayer d’être objectif et d’expliquer mes remarques, d’autant que je sais que les organisateurs sont preneurs des critiques positives et/ou négatives constructives.

Note 2 : Un bug sur le blog de Developpez.com n’empêche de vous proposer du « beau » code source en illustration.

Note 3 : Je suis ouvert aux critiques et aux propositions, surtout celles des orateurs. Je peux, par exemple, ajouter/modifier/préciser des choses/points sur demande. N’hésitez pas à me contacter.

Depuis que je travaille en banlieue, j’ai oublié les désagréments du RER et du métro. Heureusement, dès qu’on franchi l’entrée du Marriott, on sent bien que c’est le niveau au-dessus. Je devrais préciser, dès qu’on passe les portes du « centre de conférence » du Marriott, car je vois chaque année des développeurs qui entrent à « l’hôtel » Marriott, pour en ressortir quelques seconde plus tard, le regard embrouillé. Car Devoxx France, c’est l’entrée à droite. A gauche, c’est juste pour dormir. A droite, c’est pour assister à un grand évènement.

Quand on entre, on a le choix entre deux files d’attente pour récupérer son badge. La première file est pleine. Elle est dédiée aux spectateurs utilisant leur DIF, ou qui sont là, plus généralement, pour la formation. Cette formule a manifestement eut du bon. Pour ma part je vais donc dans la seconde file, vide, pour ceux qui ont simplement acheté le billet sur Internet. Ça va donc très vite. Il suffit de donner son nom pour obtenir son pass noir aux couleurs de l’évènement. J’en profite pour dire bonjour aux gentils organisateurs que je croire.

Il fait bon au Marriott. Direction les vestiaires (sur la gauche). Globalement, l’hôtel et sa décoration n’ont pas changé. A l’entrée, c’est du marbre. Dedans, c’est la même moquette aux motifs psychédéliques, signature du lieu, mais avec un an de plus, qui nous accueille. Je passe devant un stand tenu par des polos rouges, des bénévoles qui assistent les visiteurs, et reçois un kit de bienvenue. Ce dernier est constitué d’un petit sac à dos aux couleurs de Devoxx France, un calepin bien pratique (j’utilise encore celui de l’édition 2012 quand je suis en déplacement car le format s’adapte à mon sac), accompagné de son stylo, et un tshirt dont les motifs en reliefs sont fluorescents dans le noir.

Edit : ma fille de trois ans adore ce tshirt quand je lui raconte une histoire dans le noir avant de dormir…

Je pose donc mes affaires au vestiaire. J’en profite pour vérifier l’heure de fermeture. L’année dernière, il y avait eu un petit « fail » sur ce point et je constate avec satisfaction que l’équipe en a tenue compte. Il est encore tôt, ce qui devrait me laisser un peu de temps en tête à tête avec le petit déjeuner offert. Le buffet propose différents petits gâteaux et viennoiseries qui sont les bienvenus. Cafés et thé font également partie de la fête. A noter que les boissons ont été disponibles en permanence durant les trois jours, et pas seulement pour les pauses.

A peine ai-je le temps d’attraper un croissant que je croise des têtes connues. Mes « amis » ont l’air, eux-aussi, très contents d’être présents. On se serre les mains, on se fait des bisous, on prend des nouvelles, puis vient la question fatidique du programme de la journée… Que vas-tu vois en premier, me demande un copain de Rennes ? Pour être franc, je n’en sais rien. J’avais prévu de me faire un planning, en sélectionnant les sessions sur le programme en ligne, sur le site de Devoxx France, mais comme toujours, j’ai eu mille choses à faire les jours précédents. En plus, je le dis franchement, je trouve que la version online n’est pas très pratique. Du coup, je suis venu les mains dans les poches en prévoyant de choisir au dernier moment en consultant les titres des présentations à l’entrée des salles. Comme je l’avais déjà expliqué ici, je me suis juste fixé de n’assister qu’à des sessions en français.

Cette année, les organisateurs avaient carrément mis des écrans plats devant chaque salle, pour indiquer le programme de la salle mais aussi des autres salles. Bon ça défilait juste un peu trop vite pour mes yeux fatigués… C’est vrai que je commence mal ma visite. Je viens les mains dans les poches, énervé et démotivé par le travail, fatigué, etc. Mais je viens aussi avec l’espoir…

Finalement, pour m’organiser, comme j’avais pris mon iPad, j’ai utilisé l’application iOS de iDA Media Foundry qui, même si elle n’était pas tout à fait à jour, m’a permis de consulter les sujets, taguer ceux qui m’intéressent, etc.

Mon programme du jour 1 (mercredi, le jour des enfants) :

• Le fantôme, le zombie et testacular, panorama des outils de tests pour application web moderne par Jean-laurent De morlhon et Pierre Gayvallet (Université) ;
• Collections de printemps par José Paumard (Université) ;
• Gradle, 30 minutes pour tout changer par Sébastien Cogneau (Tool in action) ;
• CRaSH le shell pour la plateforme Java par Julien Viet et Alain Defrance (Tool in action) ;
• SARAH une maison Intelligente pour connecter les objets par Jean-philippe Encausse (Tool in action).

Le centre de conférence se remplit progressivement, les stands des sponsors s’animent, les discussions vont bon train. A peine le temps de prendre un second café que c’est déjà l’heure de la première session.

Le fantome, le zombie et testacular, panorama des outils de tests pour application web moderne

Cette université (synopsis ici), présentée par Jean-laurent De Morlhon (@Morlhon) et Pierre Gayvallet (@wayofspark), a pour objectif de passer en revue les principaux outils de test en JavaScript.

D’abord, il faut bien distinguer les différents types de tests habituels:

• tests unitaires (tests en isolation, ultra rapide, test technique) ;
• tests d’intégration (test groupé avec d’autres parties de l’application) ;
• tests (toute l’application est testée de bout en bout, test lent forcément, surtout BDD avec des scénarios écrits en français).

Les orateurs déconseillent de faire trop de tests d’acceptante car c’est trop dur à maintenir. Il faut en faire quelques-uns mais il ne faut pas couvrir absolument tous les cas.

Ils nous parlent aussi de « browser headless ». Ce terme fait référence à un navigateur sans interface graphique. C’est en ligne de commande. Du coup, c’est plus rapide et automatisable mais c’est dur de savoir où on en est… ex. phantomJs, htmlUnit, zombie.js

Cette présentation de trois heures a été intense. Les deux compères nous ont présentés :

• PhantomJs, un outil basé sur Webkit, crée par Ariya Hidayat (@ariyahidayat) en 2010, qui fait du vrai rendering, bien qu’on ne voit pas les pages (mais on peut faire des captures d’écran) ;
• CasperJs, une sur couche de PhantomJs qui ajoute un framework de test puisque PhantomJs est juste un navigateur. Casperjs permet de faire du code de test beaucoup plus lisible, en particulier pour les changements et attente de page. Et les tests sont écrits en JavaScript. Il sait aussi faire des exports xUnit pour mettre dans Jenkins par exemple ;
• Zombie.js, qui n’est pas un vrai navigateur (il se contente d’émuler) mais qui propose une API fluide. Zombie a la particularité d’attendre que tout soit exécuté (y compris les évènements JS) avant de passer à l’étape suivante. Gros inconvénient, ça ne fonctionne pas bien sous Windows…
• QUnit, qu’on ne présente plus, et qui lance les tests dans le navigateur ;
• Sinon.js, crée par Christian Johansen ;
• Karma (pour Angular), qui s’appellait encore « Testacular » il y a quelques jours, pour lequel j’ai perdu ma concentration suite à un plantage de Evernote sur iPad, arf. ;
• Chai.js, une petite lib pour faire des assertions sympa ;
• Mocha, qui est surtout un runner de test ;
• JsCover, pour faire de la couverture ;
• Plato, pour instrumentaliser les tests ;
• Wrap up ;
• Et puis, juste pour les citer : Js test driver, Selenium (et FluentLenium sur lequel je ferai un article complet), HtmlUnit, Jasmine et Istanbul.

Les deux orateurs nous ont proposé différents cas d’étude assez intéressants. Pour cela, ils ont utilisé le site Serpodile, qui vend des cahiers d’écriture pour enfants, que JL connait bien pour l’avoir réalisé à l’attention de sa femme. Dans le cadre de la démo, c’est une version locale qui tourne sous Jetty.

Durant cette présentation, on a pu voir plusieurs formats d’écriture des tests (ou suites de tests). Je trouve que les formats de PhantomJs et de Zombie sont assez différents. Contrairement à Jean Laurent, qui trouve que le format de Zombie est plus fluide, je préfère celui de Phantom. En effet, dans les suites Phantom, on a plein de petits blocs, correspondant à autant de tests. Avec Zombie, les blocs s’encapsulent et on se retrouve vite avec un niveau d’indentation élevé. Pour moi, ça ne sert à rien d’avoir du code lisible si le code est en dehors de la page (ie. il faut scroller à droite pour le voir).

Au final une présentation très sympa, même si j’avoue avoir un peu décroché à un moment. Bon rythme. Exemples faciles a comprendre. Mais beaucoup de slides sautés à la fin, car ils n’avaient pas prévu le temps de pause au milieu.

Je vous invite aussi à chercher une démo de « what » sur le Web… Je vous invite aussi à lire trois articles sur 3T (les Tests en Trois Temps) ici.

Alors que retenir de cette présentation ? Mis à part l’existence de chaque framework et de ses particularités, je retiens surtout le principe de « browser headless » qui correspond à des navigateurs sans interface. Les habitués des tests d’IHM connaissent bien ce symptôme, surtout sous MSIE, des fenêtres qui s’ouvent en pagaille sans jamais se refermer…

ROTI : 4/5. C’était vraiment bien, mais trop court.

Repas de midi

Oui : je suis un ventre qui ne pense qu’à se remplir, justifiant ainsi la présence d’un paragraphe dédié au déjeuner… Mais ça fait partie de Devoxx et de son ambiance. D’autant que je n’ai pas que du bien à en dire. Je vous demande de m’en excuser par avance…

Pour faire simple, c’était un buffet avec des crudités, des sandwichs jambon fromage, des navettes aux crevettes et des boissons (Coca, Fanta, Evian, café, etc.). Parlons d’abord des boissons, qui étaient disponibles en permanence, car, mis à part l’eau, il n’y avait rien de « léger ». J’aurais bien aimé avoir un Coca Light par exemple. Et j’ai vraiment le sentiment de ne pas avoir été le seul dans ce cas…

Edit : J’ai discuté avec les organisateurs sur ce point, car c’est eux qui se chargent des achats des boissons directement. Ils vont en tenir compte pour l’année prochaine.

En ce qui concerne les sandwiches, je ne sais pas trop quoi dire si ce n’est que je préfère l’ambiance du Paris JUG, pour ceux qui connaissent. En effet, à la pause, quand on se réuni à l’Isep, on a le pain d’un côté et les ingrédients (jambon, fromage, rillettes, saucisson, chips, etc.) de l’autre. Chacun peut donc choisir selon ses envies, même si ça ne fait pas très « recherché »… Disons ça fait « champêtre » et c’est une ambiance sympa

A l’inverse, à Devoxx France, des petits sandwichs (des sandwich de tailles standards découpés en petits sandwich) sont déjà tous prêts. Et, mais ça n’engage que moi, je ne les trouve pas terribles. C’est vrai qu’on s’imagine autre chose en arrivant dans un hôtel de luxe comme le Marriott. Bien entendu, je ne m’attends pas à des petits fours. D’ailleurs je crois que ça ne me plairait pas forcément. Mais je crois qu’il y a un raté. Ça me fait un peu mal au coeur car je sais que les repas sont toujours facturés hyper chers, voire imposés aux organisateurs…

L’année dernière, je me souviens que c’était un peu la bousculade autour du buffet. Cette fois, j’ai l’impression que c’était plus simple, malgré les deux cents visiteurs supplémentaires. Il faut dire qu’il y avait aussi un buffet au sous-sol, ce qui permettait aux groupes des mieux se répartir.

Edit : J’ai aussi abordé le point du buffet avec les organisateurs, qui m’ont donné une bonne explication. En fait, il n’est pas possible d’avoir un buffet « champêtre », comme au Paris JUG, car les gens restent plus longtemps stationnés devant la table, pour composer leurs menus. Au contraire, quand les sandwichs sont déjà prêts, il suffit de se servir et de passer à la suite. C’est donc une question de logistique. Nous avons aussi discuté des menus et il faut savoir que le Marriott organise des repas à longueur d’année. Ils ont donc l’habitude de bien faire. De manière générale, il y a toujours à manger pour tout le monde. Quand il y a des sandwichs au jambon, il y en a aussi poulet au poulet pour ceux qui ne mangent pas de porc, pareil pour les crevettes, les oeufs, etc.

Cela dit, la pause s’impose et la coupure du midi donne l’opportunité de se remettre de ses émotions, de discuter avec ses voisins ou encore de faire le tour des stands.

Les stands

Et bien, parlons en justement, de ces sponsors installés dans le hall. Cette année, tous les slots ont trouvé preneur. C’est plutôt bon signe. Certains stands ont changé de place, certains ont disparus et d’autres sont arrivés. J’ai beaucoup aimé le stand d’IBM car il était magnifique (photo ci-dessous). En revanche, j’avais du mal à identifier ce que les commerciaux proposaient. C’est conceptuel dirons nous…

Sur d’autres stands, c’était justement les commerciaux qui ont attirés mon attention. Donc j’ai bien discuté et échangé des cartes de visites, d’autant que j’avais des partenariats à enclencher. Vous en saurez plus très prochainement.

Pour ma part, j’ai évité de parler avec les stands non francophones. Oui oui je parle anglais. Mais je n’avais pas envie, c’est tout. C’est mon truc. Du coup je ne peux pas dire s’ils proposaient des trucs biens ou non.

Par contre, j’ai trouvé l’ambiance sur les stands moins sympa que l’année dernière. Il n’y avait presque pas d’animations. Pas d’hélicoptère, par de sushis, pas de lego… Hummm… Il y avait bien des tombolas mais que du classique. J’ai bien aimé, en revanche, la chasse au trésor organisée par Soat, via une série de QR codes… Qui a trouvé le nom de « José Paumard » ?… J’ai bien aimé aussi le robot Nao, qui reprenait les tubes de l’année comme le « Gangnam Style ». Lancez une recherche sur Youtube. Le baby-foot répondait toujours présent. La bière était fraîche et le popcorn croustillant.

Collections de printemps

Cette université (synopsis ici) , présentée par José Paumard (@JosePaumard) que j’avais interviewé en avant phase de Devoxx (interview ici), revient sur les fondamentaux de l’API Collections, notamment sur les aspects multi-threads, et fait le point sur l’arrivée des Lambda dans Java 8.

Pour être franc, j’avais initialement décidé d’assister à une autre conférence mais, au dernier moment, je suis allé assister à celle de José. Et toujours pour être franc, j’avais un mauvais à-priori… Eh oui, les collections, c’est du connu. Que pouvais-je bien apprendre ou découvrir d’un sujet aussi « vieux » ? Et puis les Lambda, ce ne sont pas les articles qui manquent sur les blogs comme Developpez.com (ici ou ici) ou les talks dans les JUG. Bref, je n’étais pas un terrain conquis dès le départ, loin de là même…

Et là, bonne surprise. D’abord, il faut bien dire que José Paumard connait son affaire. C’est vraiment un bon orateur. Ce qui aurait pu passer pour une révision ennuyeuse s’est révélé être une super conférence. Même les slides, très simples, sont bien passées.

La présentation a été divisées en deux parties :

• rappels sur l’API Collection, sur les algorithmes, sur la complexité, sur le multithreding ;
• les lambdas.

Je dois bien l’avouer, la dernière fois que j’ai regardé avec précision ce qu’il y avait dans l’API Collection, ça remonte grosso modo du début des années 2000. Depuis, je me suis plus ou moins contenté de suivre le mouvement. L’API date de 1998 (lisez mes tutos sur Guava / Google Collection) et, comme le dit si bien José, on l’utilise tous sans même y faire attention. Il faut dire que les évolutions majeures ont été rares :

• 1998 : création de l’API ;
• Java 5 : génériques ;
• Java 8 : lambda.

Perso, je sais quand utiliser les Vector (heu jamais ou presque), les ArrayList (presque un mauvais automatisme), les Linked, etc. Je parle ici des listes mais la présentation a aussi abordé les Maps. J’ai tellement l’habitude d’utiliser tout ça que c’est presque un reflex. D’ailleurs c’est un reflex. Et je ne vous parle même pas des pratiques prises avec Guava, notamment pour les « static factory » (cf. « Consider static factory methods instead of constructors ») mais c’est un autre sujet.

En cours, il y a environ vingt ans, c’est loin, on avait discuté de « complexité » des algorithmes. A l’époque je n’avais rien compris… Enfin si, j’avais compris l’essentiel, ce qui sert au quotidien, et ça suffisait. Mais il faut bien dire que je fais désormais comme si ça n’existait pas et c’est un tort. En effet, si on s’intéresse aux tris des listes par exemple, sous prétexte de me contenter d’ordonner des petites listes, je me satisfais du premier algorithme venu. Mais petite liste deviendra grande. Il faut dire, aussi, qu’à force d’entendre qu’il faut utiliser la méthode « sort » en Java, on finit par oublier de se poser les bonnes questions, notamment à propos du comparateur qui sera utilisé par l’algorithme.

José insiste aussi sur un point important. Quand on parle de complexité en « O(n) », « O(n²) », « O(n log n) », etc. il faut bien comprendre qu’on parle de famille. Dans les faits, « n log n » correspond surtout à « an log n » où la valeur du multiplicateur « a » dépend de ce qu’il y a dans votre comparateur. Du coup, vous n’allez pas forcément choisir un algorithme particulier selon la valeur de « n » mais aussi selon le coût de « a ». Et en fonction des échelles, le coefficient « a » peut avoir plus d’impact que « n ».

Dans les écoles d’ingé, et plus généralement dans les écoles d’informatique, on apprend grosso modo trois types de tri :

• le « tri à bulle », de complexité constante O(n²) ;
• les « tris par insertion », dont la complexité dépend du fait que les éléments soient déjà triés ou non ;
• et puis le célèbre « Quick sort », en « n log n », en partie utilisé par Java.

Ce qu’on apprend à l’école, c’est que les tris à bulle est joli à regarder, pour s’amuser, mais que le Quick Sort est efficace. Oh la la, combien de fois ai-je entendu ça en entretien ?… Pour rappel, et pour faire simple, le Quick Sort divise récursivement ses listes pour trier des séries plus petites. Mais ce qu’on oublie de dire, c’est que le Quick Sort tombe dans le pire des cas lorsque la liste est déjà triée ou partiellement triée. Or c’est statistiquement fréquent… Le problème donc n’est pas si simple. D’ailleurs, une technique courament utilisée est de mélanger la liste avant de la trier avec un Quick Sort.

A titre personnel, je vous invite à découvrir la famille des « Tris par Interclassement Monotones » (TIM), de complexité en O(n log n) dont je vous propose un exemple ici, qui s’appuient justement sur le fait que les listes sont fréquemment partiellement triées. Le fonctionnement repose aussi sur la division en deux listes mais non plus au milieu (ou sur un pivot) comme le Quick Sort (QS), mais en fonction de si les éléments augmentent ou diminuent. On fait pareil pour la reconstruction. En général, peu de passes sont nécessaires. Par exemple, sur une liste triée, une seule passe suffit.

Durant cette conférence, on a vu aussi ce qu’il en coute de faire une recherche d’un élément bien précis dans une liste, en fonction du type de liste. On va distinguer deux cas classiques :

• recherche par index (ie. une position : premier, dernier, id=5, etc.) ;
• recherche par valeur (ie. appel à « equals »).

On ne va pas revenir sur la structure des ArrayList. Les Linked sont des listes doublement chainées. Ca veut dire qu’un élément connait son successeur mais aussi son prédécesseur. Et petite subtilité, il s’agit d’une chaine sous forme de boucle. Le 1er item connait le 2nd item (à droite) mais également le dernier item (à gauche). Ça veut dire que c’est pratique pour avoir les premiers et derniers éléments assez vite : le premier en une itération, et le dernier en deux (une pour le premier plus une pour l’élément de gauche). Pour avoir un élément à une position donnée, il faut donc parcourir la liste tant qu’on est pas arrivé à l’index souhaité. Pour l’élément « 4 » par exemple, il faudra donc cinq itérations (une pour le premier plus quatre pour les éléments de droite). Le fait d’avoir un anneau permet une petite optimisation, puisqu’on fonction de la taille de la liste et de l’index recherché, on va soit avancer à droite, soit reculer à gauche. Par exemple, pour une liste de dix éléments, si je recherche l’index « 8 », il vaut mieux partir de la fin. Globalement c’est au pire une division par deux du coût, ce qui est loin d’être négligeable.

Comme son nom l’indique, l’ArrayList, qu’on utilise tous, est conçue sur le principe d’un tableau, mais ça reste une liste. C’est relativement simple de s’y balader. Ce qui coute cher, c’est quand on atteint la taille limite de la liste. Dans ce cas, il faut créer une nouvelle liste avec une capacité double (pour simplifier) et recopier tous les éléments vers cette seconde liste. Ça prend du temps et des ressources, d’où la nécessité de bien définir la capacité initiale quand on peut. Avec les Linked, on n’a pas ce genre de désagrément.

Les Maps, quant à elles, fonctionnent sur le principe des tables de hashage. Pour faire simple, une fonction de hash associe un objet à une valeur numérique. Normalement deux objets distincts doivent donner deux hash différents, bien que ce ne soit pas toujours le cas dans la réalité. Les Maps, nous explique José, gèrent en réalité deux hash successifs. Le premier hash s’applique sur l’objet. Le second s’applique sur le résultat du premier. Pourquoi cela ? Ça peut sembler bien étrange… Tout simplement parce que les fonctions de hashage, comme je l’ai dit, peuvent fournir la même valeur pour différents objets, le nombre de places dans la table d’une Map étant limité. Il va donc y avoir des collisions. C’est inévitable, même avec peu d’éléments. Or il se trouve qu’il y a statistiquement moins de vilaines collisions lorsqu’on « double hash ». Attention, ça ne supprime pas les collisions. Ça en diminue simplement les probabilités.

Et justement, comment ça marche lorsqu’il y a une collision. Les Maps arrivent à s’y retrouver malgré tout. Ça ne servirait pas à grand-chose sinon… Et bien, les map, dans les cases, gérent simplement une liste chainée de valeurs. Quand on vous dit que toujours écrire des méthodes « hashCode » et « equals » basées sur les mêmes contrats… Et bien entendu, il ne faut jamais mettre d’objets mutables en clé de hash table.

Si vous avez été assez patient pour lire jusqu’ici, attendez la suite. Là où ça se complique, c’est quand on commence à parler de concurrence, c’est-à-dire lorsque deux threads accèdent à la même Map. Tant qu’on reste sur de la lecture pur, ça va encore. Mais dès qu’il y a de l’écriture, c’est la fête (cf. photo ci-dessous). Il faut alors faire un tour du coté de ConcurrentMap, qui possède deux implémentations : ConcurrentHashMap et ConcurrentSkipListMap. Mais je ne vais pas approfondir ça dans ce billet de blog, qui commence déjà à être long. Veuillez m’en excuser, ça pourrait faire l’objet d’un article dédié. Je vous invite, à la place, à revoir cette présentation sur Parleys dès qu’elle sera disponible.

Pour les lambda, c’est une autre affaire. Ils arriveront seulement dans Java 8 mais on commence à avoir une idée assez précise de ce que ça donnera grâce aux previews du JDK. On ne va pas s’attarder sur les discussions à propos de la syntaxe. Fallait-il une flèche simple ou un grosse flèche ?… Pour ma part, je me contenterai de dire que la flèche simple ressemble à un pointeur alors que la flèche double me fait penser à une affectation. Bref…

Pour faire simple, les Lambda, c’est grosso modo les closures implémentées en Java. L’utilisation dans le cadre des collections saute aux yeux. Je ne vais donc pas revenir dessus.

Avec l’arrivée des Lambda, une bonne partie de l’API Collection a du être réécrite. D’abord, il y a cette nouvelle syntaxe à savoir utiliser, ce qui n’est pas forcément triviale quand on n’en a pas l’habitude. On peut s’exercer avec Guava, notamment les Functions et les Predicates, qui proposent une première approche de la programmation fonctionnelle. Ensuite, il y a une sorte de mini révolution au niveau des interfaces. Celles-ci vont désormais posséder du code, avec la possibilité de proposer des implémentations par défaut.

Ce qui va être sympa, avec les lambda, c’est le « map-filter-reduce ». Le « map », c’est associer un objet à un autre. Pour faire simple, c’est une fonction de transformation. Le « filter », c’est la possibilité de filtrer les éléments d’une liste. Enfin le « reduce » prend une liste en entrée et rend une valeur unique, calculée à partir des éléments de la liste. Et bien entendu, il est possible de chainer ces différents concepts.

Par exemple, je pars d’une liste de labradors. Pour chaque chien, je prends l’âge : c’est un « map ». Pour chaque âge, je ne garde que les valeurs supérieures à 10kg (pour éliminer les chiots) : c’est le « filter ». Et enfin, pour la liste des chiens restant, je donne le poids de l’ensemble des chiens dans mon magasin : c’est le « reduce ». Cet exemple semble un peu simple mais l’essentiel y est. Là où ça va être interessant, c’est qu’on ne va développer que des fonctions simples, correspondant au « map-filter-reduce », et c’est Java qui se débrouille pour les enchainer, sachant que ce n’est pas forcément toujours simple, surtout quand on ne souhaite pas créer de variables intermédiaires.

En outre, dans un environnement multi-coeurs (qui se généralise), on sera capable (sur demande) de paralléliser les traitements. José nous indique des gains de vitesse assez significatifs, même avec les versions Beta de Java 8.

Note : Bien que Guava permette de faire de la programmation fonctionnelle « simplifiée », il ne faut pas l’utiliser pour les performances. Ce n’est pas prévu pour ça, même si dans la plupart des cas, c’est mieux que ce que font certains développeurs Et ce n’est pas prévu pour fonctionner en multi-thread.

La seconde partie de cette université a aussi été marquée par la participation de Remi Forax (qui est impliqué dans les JSR Lamnda) durant la longue séance de questions-réponses. Vous retrouverez plusieurs de ses interventions sur la plateforme Parleys.

Encore une fois, il y aurait beaucoup de choses à ajouter tant cette présentation était intéressante, même pour les vieux de la vieille. Mais ça reste un billet de blog et non un article dédié au sujet. Et puis, il faut laisser de la place pour le sujet suivant.

Alors que retenir de cette présentation ? TODO

ROTI : 5/5. J’étais venu sans y croire, en me demandant si j’allais vraiment découvrir quelque chose. Et la réponse est oui, j’ai appris (ou réappris) bien plus que je ne l’aurait cru.

Gradle, 30 minutes pour tout changer

Ce tool in action (synopsis ici) , présentée par Sébastien Cogneau (@SCogneau), nous fait découvrir comment passer d’une application Maven déjà en place à un projet géré par Gradle.

Ca fait longtemps que je voulais découvrir Gradle car j’en entend beaucoup de bien. Je suis donc novice sur le sujet mais voici ce que j’ai compris en une demi-heure de présentation. D’abord Gradle propose un DSL soit en Groovy, soit en Java. Je crois qu’on peut faire un mixte des deux (à confirmer). Gradle, pour ceux qui connaissent, c’est l’ancien GAnt qu’on utilisait autrefois.

Pour faire simple, la conf de Maven se fait dans le fichier « pom.xml » en XML. La conf de Gradle se fera, quant à elle, également dans un fichier dédié, en Grovy ou Java donc. Et il est vrai que le XML de Maven est assez verbeux. Globalement, Gradle va proposer une syntaxe « plus simples » à toutes les instructions de Maven, aussi bien dans le fichier de conf qu’en ligne de commande.

Je note que Gradle sait faire des builds incrémentaux (démo à l’appui) et que c’est simple. Gradle s’intègre aussi bien que Maven à Jenkins. Par contre, je note aussi que Gradle est en retard sur Maven dans de nombreux points. Et globalement, mais ça n’engage que moi, le format XML de Maven ne me gère pas plus que ça.

Alors que retenir de cette présentation ? Pour moi, Gradle n’est pas encore au niveau de Maven mais c’est un outil déjà très bon et qui va continuer d’attirer mon attention.

ROTI : 5/5. Le job est fait ; j’étais venu découvrir Gradle et me faire une idée. Je repars en me disant que je ne l’utiliserai probablement pas dans un futur proche mais c’est le jeu.

CRaSH le shell pour la plateforme Java

Ce tool in action (synopsis ici), présentée par Julien Viet et Alain Defrance, nous montre le fonctionnement d’un « logiciel maison » visant à étendre et monitorer une machine virtuelle Java.

L’outil fait vraiment beaucoup de choses. Je crois que le mieux est de vous laisser le découvrir sur le site officiel.

ROTI : 3/5.

SARAH une maison Intelligente pour connecter les objets

Ce tool in action (synopsis ici, slides ici), présentée par Jean-Philippe Encausse, nous initie au petit monde des objets connectés à Internet.

Passer en dernière présentation de ce premier jour, ce n’est pas une place facile, surtout après deux longues et excellentes universités. Jean-Philippe a tout de même relevé brillamment le défi en proposant une session fort animée puisqu’il a utilisé un ensemble de gadgets pour l’assister. Par exemple, il s’est servi d’un Kinect pour détecter les mouvements de ses bras et faire défiler les slides.

De plus en plus d’objets (télé, frigo, radio, robot, lapin, voiture, aspirateur, lampe, alarme, porte, etc.) sont connectés à Internet. Cela permet, en théorie, des applications nouvelles. On peut par exemple déclencher le radiateur en partant du bureau et ainsi avoir une maison chaude en arrivant. N’étant pas de la partie, je propose un cas d’école en domotique mais on peut imaginer bien d’autres choses plus innovantes.

Les progrès dans ce domaine sont nombreux et constants. Mais un problème persiste, c’est l’utilisation de protocoles propriétaires. Pour que cela marche, il faut que les « box » sachent interconnecter les appareils entre eux, sans qu’ils soient issus forcément de la même marque. Les utilisateurs n’ont pas envie de devoir tout acheter chez Samsung (par exemple) pour connecter leurs TV, frigo et smartphone…

SARAH est un projet visant à connecter les objets, box et services de la maison. Il est « simple » à configurer. Il permet d’encapsuler les objets, box, services web dans un mini plugin. Ca permet de déclencher ces plugins par la voix, geste, cron, qrcode, règles, etc. Par exemple, la Kinect détecte l’arrivée du visage d’un utilisateur dans son champ de vision et affiche automatiquement sa boite email sur l’écran du frigo…

ROTI : n.a.

Programatoo

En plus du programme classique des présentations, il y avait un certain nombre d’événements particulier lors de Dovoxx France 2013. En ce mercredi, c’est Programatoo (synopsis ici), proposé par Audrey Neveu et Geoffrey Garnotel, qui a retenu mon attention. Programatoo vise l’apprentissage de la programmation pour les enfants de 6 à 14 ans. Cette année, les bambins reviennent pour une journée complète avec déjeuner/gouté spécial.

De parole d’animateur, cette édition a été riche, mais épuisante car les enfants étaient doués et éveillés… Concrètement, il y avait cinq enfants pour deux animateurs. Ca n’a l’air de rien mais pourtant… Le matin a été relativement classique, avec les activités qu’on avait déjà présentées. Les grands ont fait du Mindstorm (surtout des animations) et les petits ont fait du Scatch (fabrique d’histoires, avec changement de décors). L’après-midi, certains ont regardé le dessin animé Wali pendant que les plus motivés ont continué leurs découvertes.

Je vous laisse découvrir les détails sur le site officiel de Programatoo.

Note : Pour des raisons évidentes, je n’utilise pas les photos des participants.

ROTI : n.a.