Soirée JUG Nantes : Java 8 -> Lambdas, Streams et Collectors (Partie 1)

Java 8, difficile de trouver mieux comme thème pour une soirée d’un JUG. JUG qui, pour rappel, veut dire Java User Group (Groupe d’utilisateurs de Java). Ces derniers temps, les JUGs se sont diversifiées jusqu’à avoir des soirées qui n’ont rien (ou peu) à voir avec Java. Ce n’est pas la faute aux JUGs, c’est vrai que les actualités IT sexy viennent souvent d’ailleurs ;)

Mais ce 4 décembre à 19h à l’EPITECH Nantes, c’était place à un sujet phare de l’écosystème Java :

La sortie imminente de Java 8 !

Avant de parler de Java 8, la soirée commence par un autre sujet :

Grails dans les tranchées

Ce quickie est animé par Dominique Jocal, Architecte Logiciel et Responsable de 2 domaines applicatifs chez CBP Solutions.

Grails dans les tranchées ? Mais avant… c’est quoi Grails ?

Grails est un framework de création d’applications web s’exécutant sur la JVM. Le langage de développement est Groovy, un Java sucré.

Il fait partie de la famille des frameworks dits productifs qui ont les caractéristiques suivantes :

• Full Stack -> Ces frameworks viennent avec toutes les briques applicatives nécessaires pour répondre aux problématiques courantes du web (communiquer avec une base de données, écrire des règles métiers, créer des pages web, gérer l’authentification, etc.).
• Simple -> tout est fait pour faciliter le travail du développeur. Un mode opératoire simple est fourni pour mettre en place les fonctionnalités récurrentes du web.
• Web Friendly -> Avec ces frameworks, vous arrêtez de vous battre avec le Web et en particulier le protocole HTTP. Vous saurez simplement exposer des services de type REST, gérer proprement les codes erreurs HTTP, etc.

Le précurseur dans ce domaine est Ruby On Rails créé en 2005 qui a fait la promotion au passage du langage Ruby.

Depuis, plusieurs frameworks sont apparus dans les autres écosystèmes :

• CakePhp pour Php.
• Django pour Python.
• Play! Framework pour Java ou Scala.
• Sails pour Javascript.
• etc.

Grails complète cette liste de frameworks qui ont pour objectif principale la simplification des applications web. C’est un produit open source qui tourne sur la JVM.

Pour ceux qui évoluent dans l’écosystème Java, pas de surprise avec Grails. Il est construit à l’aide de la boite à outils Spring Framework. Il s’agit d’ailleurs de la même compagnie derrière : Pivotal.

Grails possède son propre serveur web et il est possible de générer un package WAR pour un déploiement dans un autre serveur d’application.

Grails chez CBP

Dominique vient avec ce Quickie présenter un retour d’expérience de l’utilisation de Grails chez CBP Solutions.

C’est devant une salle pleine qu’il commence à présenter le contexte CBP Solutions.

CBP Solutions c’est :

• Des centaines d’applications IBM RPG
• 60 applications Java
• 6 applications Grails

CBP ce n’est pas du “Big Data” mais du “Big Rules” ! Dominique JOCAL

Les enjeux de CBP Solutions sont les mêmes que pour la grande majorité des entreprises : il y a plus de codes que de données :) Non j’exagère c’est vrai. Seulement tout le monde n’a pas les mêmes problématiques que Facebook ou Twitter en terme de scalabilité sur le traitement de données. Le grand défi de la plupart des entreprises est de créer facilement des applications et surtout pouvoir effectuer la maintenance du code grandissant avec le temps.

Le Domain plus de métiers, plus de responsabilité

Les applications web de gestion consistent la plupart du temps à manipuler des données. Ces données sont souvent stockées dans des bases de données relationnelles. Elles sont alors stockées dans des tables. Afin de récupérer ces données dans l’univers applicatif et pouvoir aisément les manipuler, les développeurs sont amenés à créer des classes du Domain. Par exemple, si l’application consiste à manipuler des données d’une personne, ces données seront stockées dans une table Personne et une classe Personne sera créée pour encapsuler les données d’une personne (nom, prénom, etc.).

Il y a quelques années, il était très tendance d’avoir des classes du Domain sans aucune règle métier. Cela avait du sens, il était question de construire des applications monolithiques qui répondaient à tous les besoins des entreprises. Il fallait avoir des classes de Domain les plus neutres possibles car elles devaient s’adapter à tous les contextes des différents endroits de l’applicatif. Elles étaient utilisées dans différents cas métiers.

De nos jours, la tendance est plutôt de créer de multiples applications de petites tailles. Cela donne les avantages suivants :

• Une petite application est plus facile à maintenir. Son périmètre métier est identifié, c’est plus facile de l’apprendre, de le comprendre.
• Il devient plus simple dans un SI (Système d’Information) d’identifier une brique applicative en erreur et l’origine des erreurs. En effet, les entrées/sorties d’une application de petite taille sont maitrisées et le développeur est dans des conditions idéales pour reproduire des erreurs dans son environnement de développement.
• Chaque application a son cycle de vie. Il n’est plus indispensable de re-packager l’ensemble pour une évolution qui concerne un seul module. Plus besoin de redémarrer toutes les applications pour la mise à jour d’un libellé d’une application particulière.

En construisant des applications de périmètre fonctionnel réduit, le besoin d’avoir des classes Domain les plus génériques possibles ne se posent plus. Il devient alors naturel de concentrer les besoins métiers dans ces classes.

Quel meilleur endroit pour préciser que le nom d’une personne est obligatoire que dans la classe Domain Person ?

C’est dans cette logique que Dominique explique que le classes du Domain doivent être moins anémiques. Elles vont porter les logiques métiers dont elles sont soumises.

Grails apporte un support de validation déclaratif dans les classes de Domain. Les différentes contraintes de validation des données sont déclarées directement dans ces classes. Grails fournit aussi un cadre de développement facilitant l’écriture des tests des classes du Domain.

La Pizza Team

Le principe de la Pizza Team consiste à créer des équipes de petite taille (idéalement 1 pizza suffit à nourrir l’équipe) qui sont responsables de l’ensemble de l’application (du code à la base de données).

Voici donc à quoi pourrait ressembler votre équipe :

Chez CBP Solutions, ces principes sont appliqués, à la différence qu’il y a une équipe garante de la cohérence et l’urbanisation des données.

Les différentes équipes projet qui travaillent sur des applications Grails co-conçoivent la base de données avec les garants des données du SI.

Code first au lieu de Schema first

Grails donne la possibilité de générer un schéma de base de données à partir des classes de Domain. Les développeurs ont pu montrer aux administrateurs des bases de données qu’un schéma généré par Grails est de bonne qualité.

Et l’IDE ? Oups, il en faut un pour développer ?

Les développeurs de CBP Solutions sont globalement déçus de GGTS : le Groovy/Grails Tool Suite. Il s’agit d’un Eclipse re-packagé avec des plugins pour Groovy et Grails.

Quelques mésaventures :

• Il arrive des compilations de code Groovy qui prennent beaucoup de temps pour se terminer en OutOfMemoryError.
• Des besoins fréquents de redémarrage de l’IDE et de l’application Grails
• Il est nécessaire d’avoir des PCs puissants (i7, 8GB de RAM, SSD).

Il y a des premiers retours positifs de l’IDE Intellij IDEA.

Grails -> Un développeur opérationnel tout de suite !

Chez CBP Solutions, avec Grails, un développeur a un environnement de développement opérationnel rapidement en 3 étapes depuis son IDE :

• Récupération des sources d’un dépôt Subversion.
• Rafraichissement des dépendances (grails refresh-dependencies)
• Lancement de l’application (grails run-app)

Grails vient avec un serveur embarqué, pas besoin d’installer un serveur particulier pour développer.

Grails permet simplement de séparer les configurations de production de celles de développement. Par exemple, votre application peut fonctionner en mode développement sur une base de données en mémoire comme H2 et fonctionner en production avec une base de données MariaDB.

Multi-Page vs Single-Page

Grails offre un cadre de développement avancé pour les applications Multi-Page.

Il est possible de faire du Single-Page. Vous continuer à profiter des leviers de productivités côté back-end. Pour le front-end, cherchez du côté de l’univers Javascript (Vanilla ou frameworks type AngularJS, EmberJS, etc.).

Chez CBP Solutions, les applications sont faites en Multi-Page.

Les tests c’est bien !

Les 6 applications Grails chez CBP Solutions sont toutes dans le top 10 des applications ayant la meilleure couverture de code par les tests.

CBP, la suite…

Dominique a énoncé les projets qu’il avait en tête :

• Partager les astuces dans un Blog
• Grails! Grails! Grails! CBP Solutions continue avec Grails !
• Explorer le parallélisme et mettre en place des tests de code Javascript

En définitif

Dominique a présenté son retour d’expérience au sein de CBP Solutions de l’utilisation de Grails. Il est surpris qu’il n’y ait pas un tsunami de Grails dans les entreprises qui font de l’informatique de gestion. Il est pour lui inconcevable, aujourd’hui de partir sur un assemblage maison de librairies (Spring + Hibernate + etc.). Grails propose un ensemble cohérent, productif, clés en main pour construire des applications web, autant en profiter.

Une question a été posée à Dominique : est-ce que le côté dynamique de Groovy n’était pas un problème car moins d’erreurs sont détectées à la compilation ? (je reformule avec mes mots ;)). Dominique va expliquer que ce risque est compensé par la grande couverture de code par les tests permise par Grails.

Les slides ne sont pas encore disponibles, je complèterai cet article dès leurs publications.

Et la soirée continue !

La seconde partie de la soirée sera animée par Jose Paumard avec sa session

Java 8 : Lambdas, Streams et Collectors -> le nouveau visage de l’API Collection

A suivre dans un prochain article.