DEVOXX France 2018 : le débrief

devoxx

Les présentations se sont enchaînées lors du DEVOXX France 2018.

Nous avons participé au Devoxx France 2018 qui s’est déroulé du 18 au 20 avril 2018. Dans cet article, nous allons vous présenter quelques conférences intéressantes que nous avons pu suivre. Ces retours sont basés sur notre compréhension personnelle, chacun est accompagné de la présentation YouTube. Libre à vous de les regarder pour vous forger votre propre opinion !

 

Cloud Native Spring, chapitre deux youtube

Josh Long twitter

Josh nous a donné un très bon aperçu des possibilités offertes par Spring Cloud. Il a commencé par évoquer le fait qu’il existe deux problèmes principaux lorsqu’on veut s’attaquer aux microservices. Le premier est le temps; il existe beaucoup d’outils différents il faut donc prendre le temps de bien les choisir, ce que nous n’avons pas forcément. Le deuxième est la communication entre les microservices.

Josh nous a ensuite réalisé une démonstration de deux microservices complètement réactifs communicants entre eux. Il nous a monté les streams réactifs, le driver réactif pour MongoDB et Spring Actuator pour les métriques.

Il évoque également les possibilités qui s’offrent à nous avec Spring Cloud, à savoir l’utilisation de service registry avec Netflix Eureka, de rate limiter avec Redis, de circuit breaker avec Hystrix, de messaging avec Kafka. Spring peut également fournir un serveur de configuration qui centralise toutes les propriétés de nos applications et permet notamment l’utilisation de feature flags.

 

Reactive Spring youtube

Juergen Hoeller twitter et Josh Long twitter

Cette présentation était pour ainsi dire un résumé de la précédente, « Cloud Native Spring, Chapitre deux ». La différence était que sa durée était de seulement 45 minutes, contre 3 heures pour l’autre. Vous pouvez regarder une des deux vidéos en fonction de votre temps disponible, celle de 3 heures étant évidemment plus poussée dans les explications.

 

Migrer à Spring Boot 2 lorsque l’on a une « vraie » application youtube

Julien Dubois twitter

Julien nous a présenté les problématiques rencontrées par JHipster lorsqu’ils ont migré de Spring Boot 1 vers la version 2.

  • Il a fallu dans un premier temps migrer les librairies tierces afin quelles soient compatibles avec la dernière version de Spring.
  • Une migration des fichiers properties a également été nécessaire, car certaines propriétés ont été renommées.
  • Le format JSON de retour de Spring Actuator a été modifié, il a donc fallu adapter les outils qui l’utilisait.
  • Spring Data a subi quelques changements d’API et utilise maintenant les Optionals.

En plus de ces modifications plus ou moins coûteuses en refactoring, de nouveaux outils sont apparus et ont été pris en compte dans leur migration. Il s’agit de Spring Webflux qui permet une programmation réactive, Spring Security supportant également la programmation réactive ainsi qu’OAuth 2. Micrometer, pour de la gestion de monitoring, a aussi été mis à disposition.

Spring Cloud quant à lui n’a pas pour l’instant eu d’impact. Toutefois, sa version supportant Spring Boot 2 n’est pas encore sortie officiellement.

Dans l’ensemble, le coût de refactoring a été assez cher et plus encore il a fallu tester de nouveau toute l’application.

 

Glowroot, le petit APM qui vous veut du bien youtube

Henri Gomez twitter

Henri nous a présenté l’Application Performance Management (APM) Java Glowroot. Contrairement à la plupart des APM, celui-ci est open source et gratuit. Son overhead est inférieur à 100 µs et sa consommation mémoire minime.

Glowroot a deux modes de fonctionnement. Le mode autonome en spécifiant seulement le chemin du jar au lancement du serveur, ou le mode centralisé qui nécessite une base Cassandra et permet de monitorer une ferme d’applications.

Il comporte l’ensemble des fonctionnalités attendues d’un APM comme l’affichage des slow traces. Il fonctionne avec tout protocole, frameworks et serveurs d’application.

 

Java dans Docker : Bonnes pratiques youtube

Charles Sabourdin twitter et Jean-Christophe Sirot twitter

Charles et Jean-Christophe nous ont parlé d’un ensemble de bonnes pratiques pour utiliser des applications Java avec Docker. La présentation était axée sur la gestion de la mémoire.

Le paramètre « memory » peut être utilisé au démarrage d’un conteneur Docker afin de spécifier le montant maximum de RAM qu’il peut utiliser. Il est conseillé de l’utiliser, ainsi que le paramètre « memory-swappiness » afin de désactiver le swap qui diminuerait grandement les performances.

Côté Java, la gestion de ressources dans un conteneur a été amélioré en Java 9 et backporté en Java 8u131. Toutefois, il est nécessaire d’utiliser les flags UnlockExperimentalVMOptions et UseCGroupMemoryLimitForHeap. En Java 10, la fonctionnalité est stable et activé par défaut.

Tous ces principes s’appliquent également pour la gestion de ressources CPU.

 

Container security tips for developers youtube

Justin Cormack twitter

Justin nous a donné un ensemble de conseils de sécurité pour l’utilisation des conteneurs avec Docker.

Docker est plutôt bien sécurisé par défaut, il y a toutefois un ensemble de bonnes pratiques à suivre pour éviter tout désagrément. Il est recommandé de toujours utiliser des images officielles. Il faut privilégier par exemple les images Java officielles plutôt que celles réalisées par une personne lambda. Les images officielles sont régulièrement mises à jour pour patcher des vulnérabilités, donc il faut également veiller à mettre à jour nos images qui se basent dessus.

Il est conseillé de signer nos images afin d’être sûr que le cluster de production récupère bien une image reconnue qui a été buildée par notre serveur d’intégration continue. Il est également possible et utile de scanner régulièrement les images utilisées afin d’y trouver des vulnérabilités connues et pouvoir les corriger.

Enfin, il faut éviter de commiter les secrets de nos applications sur GIT ainsi qu’utiliser les variables d’environnement et privilégier plutôt l’utilisation de Vault ou des systèmes intégrés à Docker et Kubernetes pour gérer identifiants et mots de passe.

 

Les 12 factors Kubernetes youtube

Etienne Coutaud twitter

Etienne nous a présenté sa version des Twelve-Factor App appliqués à Kubernetes.

Les bonnes pratiques à suivre pour déployer des applications dans un cluster Kubernetes sont les suivantes :

  • Il faut garder en tête qu’un Pod signifie un ou plusieurs conteneurs.
  • Utiliser les labels à profusion. Cela permettra de gérer plus facilement un cluster qui comporte des dizaines, voire des centaines de pods. Chaque commande Kubernetes peut être exécutée en précisant un namespace ou un label et ainsi cibler son impact.
  • Les fichiers de configuration YAML de Kubernetes doivent être traités comme du code et versionnés. De plus, la commande apply pourra être utilisée sur un ensemble de fichier et Kubernetes se chargera d’appliquer uniquement ce qui a été modifié.
  • Les services permettent d’exposer des pods et de gérer du load balancing.
  • Utiliser les ConfigMaps et Secrets pour gérer les identifiants de nos applications. Ils seront ensuite injectés et accessibles depuis nos pods.
  • Utiliser les requests et limits pour gérer les ressources de notre cluster.
  • Les pods doivent être déployés via un fichier de Deployment et non pas directement en tant que pod. Dans le cas contraire, aucun ReplicaSet ne sera créé, leur cycle de vie de ne sera pas correctement géré et ils ne pourront pas être redémarrés automatiquement en cas de problème par exemple.
  • Utiliser les paramètres LivenessProbe et ReadinessProbe. Le premier permet à Kubernetes de savoir lorsqu’un pod a bien été démarré et le second de savoir lorsqu’il est réellement prêt à être utilisé (après une connexion à une base de données par exemple).
  • Ne pas utiliser la version « latest » pour les images. Privilégier plutôt l’id de commit GIT par exemple. Cela permettra de savoir plus facilement quelles fonctionnalités et corrections sont disponibles en production.
  • Les pods sont stateless et éphémères. Il faut donc y penser lors du développement de l’application. S’il est nécessaire de garder une session par exemple, il faudra utiliser un pod explicitement déclaré statefull et contenant une base Redis.
  • Les volumes doivent être montés sur des stockages distribués. Vu que nos pods sont stateless, toute donnée sera perdue à leur redémarrage. Il faut donc configurer le pod pour qu’il ait accès à des volumes mis à disposition généralement par notre fournisseur Cloud.
  • Les microservices déployés doivent suivre les Twelve-Factor App.

 

Docker, Kubernetes et Istio, c’est utile pour mon monolithe ? youtube

David Gageot twitter

David nous a présenté une transformation de l’application classique « Pet Store » en microservices.

Il a commencé par la création d’une image Docker pour l’application afin de pouvoir la déployer dans un cluster Kubernetes. La configuration pour ce déploiement se présente sur la forme de fichiers YAML.

La première étape de la migration consiste à intégrer un conteneur Nginx et un conteneur contenant l’application dans un même pod Kubernetes. Le conteneur Nginx est embarqué en mode « sidecar » et permet d’intercepter les requêtes du Pet Store afin de les compresser, ainsi que faire de la réécriture d’URL.

La deuxième étape consiste à ajouter un autre sidecar, Envoy. Il s’agit d’un proxy qui va être rajouté automatiquement par le service mesh nommé Istio. Ce dernier ajoute un grand nombre de fonctionnalités à Kubernetes. Il va permettre notamment de chiffrer les communications entre chaque microservice grâce à Istio Auth. Cet ajout de proxy en sidecar de chaque pod va également permettre à Istio Mixer d’agréger des métriques et les envoyer à Prometheus et Grafana afin d’avoir un dashboard d’analyse de notre cluster.

Istio a un grand nombre d’autres fonctions. Il est possible de l’utiliser pour gérer des déploiements en blue/green, timeouts, retries, health checks, mirroring, circuit breaker, rate limits, telemetry, reporting, traces distribuées avec Zipkin, etc.

Avec toutes ces fonctions, il est possible de migrer graduellement une application legacy vers des microservices.

 

Troubleshooting & Debugging Production Microservices in Kubernetes youtube

Ray Tsang twitter et Baruch Sadogursky twitter

Ray et Baruch nous ont présenté des pistes afin de débugger des microservices en production sous Kubernetes.

Côté best practices pour faciliter l’analyser, il est conseillé de ne pas utiliser la version « latest » pour les images, mais plutôt l’id du commit GIT par exemple. Partant d’une application ne suivant pas ce conseil, ils ont dans un premier temps comparé les hashs des images Dockers avec la version précédente, ainsi que le hash du jar embarqué dans le conteneur afin de pouvoir connaître la version réelle de l’application qui tourne en production.

Les logs des pods sont redirigés sur la sortie standard. Comme il peut avoir un grand nombre de pods répliqués sur plusieurs serveurs, il existe des outils comme stern ou ktail qui permettent d’agréger les logs de tous les pods d’un même ReplicaSet. Dans le meilleur des cas, nous pouvons utiliser par exemple une stack ELK qui va permettre de centraliser tous les logs sur Kibana.

Une fois le pod défaillant ciblé, il est possible de le sortir du cluster afin de l’analyser plus en détails. Il est possible de tracer précisément la requête effectuée avec l’aide de Zipkin.

Enfin, l’utilisation du Google Cloud Engine (GKE), pour gérer notre cluster Kubernetes, permet d’avoir accès à ensemble d’outils facilitant le debugging. Nous pouvons noter par exemple le debugger de GKE qui permet d’ajouter à la volée des logs dans le code s’exécutant en production grâce à de la bytecode instrumentation.

 

Du mutualisme à l’Open Source youtube

Alexandre Delègue twitter Mathieu Ancelin twitter et François Desmier twitter

Alexandre, Mathieu et François nous ont parlé de la transformation de leur entreprise, la MAIF, ainsi que du développement de certains outils open sources.

La MAIF est une société d’assurance qui s’est rendu compte que sans évoluer, elle était vouée à disparaître. En effet, nous pouvons imaginer que d’ici quelques années le besoin d’assurance sera moins nécessaire, notamment grâce (ou à cause, selon le point de vue) aux voitures autonomes qui vont se démocratiser. Dans tous les cas le modèle actuel va évoluer et l’entreprise se doit également d’évoluer. Une diversification est nécessaire.

Dans cette optique, la MAIF a sorti déjà deux outils open sources : Otoroshi et Izanami.

Otoroshi est un outil permettant de gérer API management, circuit breaker, load balancing, throttling, quotas et métriques. Il dispose également d’une interface d’administration REST et web.

Izanami est un outil permettant de gérer feature flipping, configuration partagée et tests A/B.

D’autres outils sont en préparation et l’ensemble de ce qui a été développé permet une gestion facilitée des architectures microservices.

 

Using Kubernetes for Continuous Integration and Continuous Delivery youtube

Carlos Sanchez twitter

Carlos nous a présenté un workflow d’intégration continue et déploiement continu via l’utilisation de Jenkins X, qui s’appuie sur Kubernetes. Le workflow peut s’effectuer de la manière suivante : un push puis une pull request sont effectués sur GitHub, un build Jenkins est automatiquement déclenché, s’il passe correctement le merge de la pull request est fait, enfin d’un clic de bouton l’application est déployée dans l’environnement choisi.

Jenkins X se compose également d’un grand ensemble de plugins et permet d’automatiser certaines tâches liées au déploiement d’une nouvelle version comme la génération automatique de changelog.

 

Maitriser sa gestion de l’identité avec Keycloak youtube

Lilian Benoit twitter Thomas Recloux twitter et Sebastien Blanc twitter

Lilian, Thomas et Sébastien nous ont présenté Keycloak et ses possibilités en profondeur. Il s’agit d’une solution open source permettant de faciliter la gestion de l’authentification et de l’identité de nos applications. Il supporte les protocoles OpenID Connect 1.0, OAuth 2.0 et SAML 2.0.

Le principe d’OAuth 2 est de récupérer un authorization code, puis un access token, puis utiliser ce dernier pour s’authentifier.

OpenID Connect permet d’allier OAuth 2 et JWT. Ce dernier consiste en un header, un payload et une signature. Le payload peut être utilisé pour passer n’importe quel type d’information (non compromettante) utile à notre application. En comparaison avec OAuth 2, OpenID Connect est un protocole d’authentification et d’autorisation complet.

Une bonne pratique dans la gestion des tokens est de faire des access token à durée de vie courte (quelques minutes). Un refresh token, avec durée de vie beaucoup plus longue, permet ensuite de récupérer un nouvel access token valide. Ceci permettra par exemple qu’au bout de quelques minutes, les droits éventuellement mis à jour d’un utilisateur soient pris en compte à la régénération d’un access token.

Le SAML 2.0, beaucoup plus ancien pour sa part, car défini en 2005, permet notamment l’échange d’information d’authentification entre partis. Il permet une gestion du SSO et il n’est pas uniquement utilisable en HTTP, car il s’agit simplement d’un format XML.

Pour ce qui est de Keycloak lui-même, il se compose de Realms et de Clients. Un client sera une application et le realm sera l’entité regroupant nos différentes applications qui ont un certain lien entre elles, comme la nécessité d’utiliser du SSO.

La customisation est très poussée sur tout ce qui touche à l’authentification. A titre d’exemple, les fonctionnalités pouvant être activées sont : rester connecté, mot de passe oublié, enregistrement, captcha, vérification d’email, protection brute force, politique de mot de passe, double authentification, etc.

En plus d’une bonne intégration à Spring Boot et Spring Security, un ensemble d’adaptateurs sont fournis, ainsi qu’un proxy fonctionnant en mode « sidecar », sur le même principe qu’Istio dans un cluster Kubernetes.

Keycloak est ainsi une solution complète fournissant toutes les fonctionnalités nécessaires pour la gestion de l’authentification et des droits de nos applications.

 

Chaos Engineering, principes et mise en application youtube

Benjamin Gakic twitter

Benjamin nous a présenté le Chaos Engineering, initié par Netflix, et sa mise en application chez OUI.sncf.

Dans une situation chaotique, habituellement nous agissons d’abord, puis observons et enfin seulement répondons au problème. Le but va être d’éviter de se retrouver dans ce genre de situation en la provoquant nous-même et la résolvant. Le chaos engineering est non déterministe et s’effectue en production. Il s’agit de faire de l’expérimentation sur un système distribué afin de renforcer notre confiance dans la capacité du système à résister à des conditions turbulentes.

D’après de récents sondages, la sécurité devient maintenant moins prioritaire pour les entreprises que le downtime de leur application. Les indisponibilités sont de plus en plus médiatisées et font de la mauvaise publicité. Deux exemples récents sont OVH et GitLab qui ont chacun eu un épisode de downtime important très médiatisé.

Pour faire du Chaos Engineering, plusieurs outils sont à notre disposition, le premier étant Chaos Monkey. Pour simuler des pannes, cet outil va mettre hors service des instances de production de manière aléatoire. Les autres outils disponibles sont notamment Latency Monkey, Fill Disk Monkey, Process Killer Monkey, Properties Monkey, etc. Chacun va tenter de « casser » nos applications d’une manière différente afin de cibler des vulnérabilités dans notre architecture et pouvoir les corriger avant qu’elles ne se produisent réellement.

En plus de mettre ces outils en place, d’abord en pré-production, OUI.sncf met en place des journées « Game day » dont le but est également de trouver des vulnérabilités. Des équipes d’opérateurs se chargent de « casser » l’environnement de différentes façons et des équipes de développeurs doivent ensuite arriver à les détecter, diagnostiquer puis les résoudre le plus rapidement possible.

 

Lighthouse: mesurer et améliorer votre performance web youtube

Sara Harkousse twitter et Philippe Antoine twitter

Sara et Philippe nous ont présenté Lighthouse. Celui se présente sous la forme d’un module NodeJS, ou bien directement intégré dans les DevTools de Google Chrome.

Lighthouse permet d’analyser une page web et fourni un ensemble d’indicateurs sur celle-ci, avec un score sur 100 pour chacun. Les indicateurs sont les suivants :

  • Performances
  • Progressive Web App
  • Best practices
  • Accessibility
  • SEO

Pour chaque amélioration possible, une todo list est proposée avec des conseils sur les mesures à mettre en place ou ce qu’il faudrait ajouter/modifier sur notre site.

Parmi les aides proposées, on peut noter par exemple un scan automatique des librairies utilisées (fourni via Snyk). Pour le reste, les DevTools permettent également d’améliorer performances et accessibilité.

 

Réconciliez vous avec le JS grâce à Flow youtube

Trung Nguyen twitter

Trung nous a fait un tour rapide des fonctionnalités proposées par Flow. Il s’agit d’un vérificateur de type statique, développé et largement utilisé par Facebook.

Une fois le module NPM installé, Flow pourra analyser les fichiers de notre projet annotés avec // @flow. Il nous présentera un ensemble de warnings et d’erreurs permettant de détecter des bugs avant le runtime. Pour cela, Flow fait du type checking en essayant d’inférer les types.

Flow apporte également un ensemble de syntaxes supplémentaires au JavaScript afin de définir nous-même les types utilisés.

 

Accélerez vos tests end-to-end avec Cypress youtube

Rodolphe Bung twitter

Rodolphe nous a présenté un outil de test end-to-end nommé Cypress. Contrairement à Selenium, il est exécuté directement dans le navigateur et permet par conséquent une meilleure gestion des applications single page.

Cypress est centré sur l’expérience développeur. Son installation et son API sont simples. Il propose en plus des fonctionnalités très utiles telles que le live reload, le mocking, la mise à disposition automatique de vidéos des tests effectués, des tests de régression visuelle et des tests unitaires de composants React et Vue.js. Des plugins sont également disponibles.

Le seul reproche qui pourrait lui être fait actuellement est qu’il ne soit pas multi-navigateur. Il fonctionne uniquement sur Google Chrome, mais le développement sur d’autres navigateurs est en cours.

 

GraphQL vs Traditional Rest API youtube

Vladimir Dejanovic twitter

Vladimir nous a présenté le langage de requête pour APIs nommé GraphQL. Cette spécification a été décrite par Facebook en 2012 puis publiée en 2015. Comme il s’agit d’une spécification, chaque implémentation peut différer et ne pas forcément implémenter toutes les fonctions possibles.

Une API REST classique est basée sur une architecture client-serveur, est stateless, est cacheable, a une interface uniforme entre le client et le serveur.

Une API GraphQL possède également ces fonctionnalités et aura en plus notamment un schéma disponible. Ce schéma définira toutes les opérations possibles sur l’API; les query (de la lecture de données) et les mutations (de la modification de données). L’avantage d’avoir ce schema est de pouvoir savoir exactement ce qui est disponible et d’ainsi d’avoir une documentation.

Les clients appelant une API GraphQL choisissent quels objets et quels champs récupérer. Contrairement à REST, le client peut donc utiliser l’API comme il le souhaite en fonction de ses besoins, sans avoir forcément à appeler plusieurs endpoints pour récupérer des sous objets. Comme le client a plus de liberté, il existe des mécanismes de protection pour éviter qu’une requête soit beaucoup trop lourde à exécuter, à savoir des timeouts, des niveaux maximum de profondeur pour récupérer des objets enfants, des niveaux maximum de complexité et du throttling.

Certaines implémentations peuvent aussi fournir un système de souscription pour que le client soit alerté lorsqu’une donnée est modifiée.

 

DEVOXX France 2017 : le débrief

devoxx

Les présentations se sont enchaînées lors du DEVOXX France 2017.

Nous avons participé au Devoxx France 2017 qui s’est déroulé du 5 au 7 avril 2017. Dans cet article, nous allons vous présenter quelques conférences intéressantes que nous avons pu suivre. Ces retours sont basés sur notre compréhension personnelle, chacun est accompagné de la présentation YouTube. Libre à vous de les regarder pour vous forger votre propre opinion !

 

PRÉPAREZ-VOUS A LA MODULARITÉ SELON JAVA 9 youtube

Alexis Hassler twitter ET Remi Forax

Cette université de 3h portait sur le projet Jigsaw de Java 9. Il est censé régler les problèmes de dépendances et classpath (en le remplaçant par un module path), les problèmes de librairies présentes dans différentes versions dans le classpath… Cela a permis un découpage du JDK pour pouvoir le distribuer sans forcément tout inclure, juste le nécessaire. Pour les librairies externes aussi, par exemple si on veut juste la partie injection de dépendances de Spring, cela pourra être un jar de quelques kilos au lieu de quelques mégas aujourd’hui.

La config des modules de nos applications va passer par la définition de fichiers « module descriptor » qui vont spécifier notamment quels packages exposer aux autres modules et quels modules importer. Dorénavant, les classes publiques ne le seront plus pour toute l’application, mais uniquement pour le module. Avec ceci, Java 9 va passer également pas mal d’API en deprecated. A partir de maintenant et des prochaines versions, il va avoir du ménage et des deprecated seront supprimés, il faut s’attendre à pas mal de breaking changes potentiellement.

Une bonne partie de la conférence était ensuite de migrer une appli en Java 8 vers Java 9 en la découpant en modules. A noter qu’un bypass de cette utilisation par module sera possible pour inclure d’anciens jar par le biais d’un classpath dédié, de façon à pouvoir toujours utiliser d’anciennes librairies qui ne migreraient pas sous ce style d’architecture.

 

TENSORFLOW ET L’APPRENTISSAGE PROFOND, SANS LES ÉQUATIONS DIFFÉRENTIELLES youtube

Martin Görner twitter

Le but de cette université était de présenter le framework Tensorflow, rendu opensource par Google. Il s’agit d’un framework qui permet de manipuler des réseaux de neurones « simplement » (ou en tout cas plus simplement que ce que cela pouvait l’être jusqu’à maintenant). La conférence a été illustrée par deux exemples qui ont permis de présenter pas mal de fonctionnalités et fonctions mathématiques intégrées au framework.

Le premier exemple était la reconnaissance de chiffres. Il y avait un jeu de données de plus de 60 000 chiffres écrits de façon manuscrite que le réseau devait reconnaître au mieux. Nous allons écrire quelques principes qui ont été décrits, mais pour l’explication assez complexe il faudra regarder la rediffusion de la conférence ! Malgré le fait que le conférencier a bien vulgarisé les principes, cela reste assez dur à retranscrire.

Il a évoqué les matrices multidimensionnelles, les fonctions Softmax, Sigmoid et RELU (Rectified Lineara Unit), la cross entropy, l’algorithme d’optimisation gradient descent, la fonction de régularisation Dropout… Les réseaux convolutionnels ont aussi été évoqués, ainsi que les réseaux récursifs. Ces derniers sont très puissants et permettent de mettre en relations des couches de réseaux de neurones afin d’analyser plus finement les données. A la moitié de la conférence, nous sommes arrivés à un taux de reconnaissance des chiffres de plus de 96%, avec seulement une trentaine de lignes de code.

Le deuxième exemple était de faire intégrer l’ensemble des oeuvres de Shakespeare à un réseau récursif, afin de générer de nouveaux textes. L’oeuvre qui a été générée en live était assez impressionnante, avec des actes, des personnages inventés, des dialogues… En regardant de plus près l’ensemble du texte n’avait pas vraiment de sens, mais on arrive à un résultat assez cohérent sur la structure, l’agencement des mots, etc. Le même principe avait d’ailleurs été appliqué aux oeuvres de Rembrandt, suite à quoi un réseau neuronal avait produit une peinture totalement inédite de cet artiste, respectant l’époque, sa manière de peindre, … On en vient à se demander si on peut considérer cette oeuvre comme un original de Rembrandt ou non.

Ces systèmes sont également utilisés de nos jours pour Google Traduction, la reconnaissance d’images, bientôt la médecine pour détecter des cancers… et bien d’autres domaines.

 

JAVA 8, C’EST BIEN. JAVASLANG, C’EST MIEUX youtube

Mathieu ANCELIN twitter

Cette conférence avait pour but de présenter la librairie Javaslang et son avantage par rapport aux API standards de Java 8. Cela a été fait sous la forme d’une démo de refactoring d’une application.

La librairie présente des fonctionnalités utilisées telles que des List.of ou HashMap.of pour instancier facilement des collections avec des données. On peut noter aussi un type Either<Trowable, Objet> qui permet à une fonction de retourner soit son résultat attendu soit l’erreur qui s’est produite. Il y a également des fonctionnalités pour faciliter l’utilisation des streams, qui permettent, entre autres, de se passer des collectors. A noter que toute collection de Javaslang peut être transformée en collection classique avec une méthode .toJavaList().

 

JAVA 9 MODULO LES MODULES youtube

Jean-Michel Doudoux twitter

Cette présentation consistait à lister les nouveautés de Java 9, sans parler du projet Jigsaw et ses modules. On va avoir :

  • Des try with ressources plus concis.
  • Les opérateurs diamants seront possibles sur les classes anonymes.
  • Les interfaces pourront avoir des méthodes privées.
  • Des factory seront disponibles pour créer des collections immuables.
  • De nouvelles méthodes seront disponibles sur les streams, comme les takeWhile et dropWhile, ou encore les Stream.ofNullable.
  • L’organisation des fichiers du JDK va changer, le JRE et le JDK ne seront plus séparés comme avant.
  • L’utilisation de java en ligne de commande supportera les options standards GNU.
  • Les jar pourront contenir plusieurs releases d’une même librairie.
  • L’outil jshell sera disponible pour avoir une console Java et exécuter des bouts de code.
  • Certains outils du JDK seront retirés, comme le rt.jar et tools.jar.
  • Les numéros de version du JDK auront un nouveau format, de type MAJOR.MINOR.SECURITY.PATCH, par exemple 9.2.3.1.
  • Les objets String prendront moins de place en mémoire.
  • L’outil jdeprscan permettra de scanner nos projets pour savoir si on utilise des API deprecated.
  • L’API StackWalker pour une meilleure lecture des stacks d’erreurs, mieux filtrées et plus claires.

 

LE STREAMING D’API : POURQUOI ET COMMENT TRANSFORMER VOS APIs STATIQUES EN DONNÉES EN TEMPS RÉEL ? youtube

Audrey Neveu twitter

Cette présentation consistait à présenter les différentes méthodes disponibles pour faire des API utilisables en streaming :

  • Long polling : à bannir car il bloque le client et la communication n’est que dans un sens. Une nouvelle connexion est créée à chaque fois, on a aucune idée de si une requête est nécessaire, si les données sont changées ou pas.
  • Webhooks : l’utilisateur renseigne au service l’URL qu’il doit appeler. Cela est assez contraignant, compliqué à debugger et ne fonctionne pas sur smartphone.
  • Websockets : la communication est bidirectionnelle et réalisée en binaire. Le client redémarre la connexion si elle est perdue. Un point négatif est la méthode de connexion un peu particulière qui peut nécessiter de devoir reconfigurer les firewalls. Cette méthode est généralement plus utilisée pour les chats et jeux vidéos.
  • Server Sent Event (SSE) : les performances sont meilleures mais la communication est unidirectionnelle (le serveur push les données au client). Cela fonctionne par le protocole HTTP standard. Pas de support par IE ni Edge mais des polyfills existent.

La présentation s’est terminée par l’utilisation d’une api SSE connectée au cours du Bitcoin et à un drone sur scène afin de le faire décoller ou atterrir en fonction de ce cours.

SPRING FRAMEWORK 5.0 youtube

Stéphane Nicoll twitter

La présentation a fait un petit overview de la nouvelle version de Spring à venir. La RC est disponible et la finale sortira légèrement avant Java 9.

Les performances de démarrage ont été grandement améliorées. Certains cas montrent un démarrage en 100ms au lieu de 6s, cela grâce à une meilleure gestion du contexte. Avant les classes étaient scannées au démarrage pour analyser toutes les annotations, maintenant cela est fait à la compilation en gardant un fichier mapping. Java 9 sera bien sûr supporté, ainsi que le protocole HTTP 2 et le langage Kotlin. Le framework pourra fonctionner avec une programmation Reactive de bout en bout. Il sera ainsi possible d’appeler une API qui streamera directement le contenu de la base en un flux infini (ou pas) de données, et non plus attendre que toutes les données soient transmises d’un coup. Des types Flux et Mono ont été ajoutés pour cela.

Les API pourront également être utilisées en mode fonctionnel et non plus forcément par annotations.

 

10 MÉTHODES POUR RENDRE HEUREUX LES DÉVELOPPEURS, LA 7EME VA VOUS ÉTONNER ! youtube

Cyril Lakech twitter ET Romain Linsolas twitter

Un développeur de chez Axa et un de la Société Générale nous ont parlé de leur vision pour rendre les développeurs heureux en entreprise. Il faut pour eux :

  • Investir dès le recrutement, ne pas mentir au candidat, parler de code avec lui pour savoir si les pratiques de l’entreprise correspondent à ce qu’il attend… Pourquoi pas l’intégrer une demi journée à l’équipe, parler de la culture, la vision, etc.
  • Proposer une perspective de carrière pour que les développeurs restent plusieurs années. Ne pas être toujours dans le rush, prévoir du temps pour qu’ils puissent apprendre, découvrir de nouvelles choses.
  • L’environnement est important. L’Open Space est déconseillé, ou il faut en tout cas mettre à disposition des bureaux flexibles (endroits pour s’isoler), des espaces de détente, des bureaux adaptés aux envies de chacun (debout ou assis). Un bon matériel et de bons logiciel sont aussi importants pour ne pas être frustré, permettre le télétravail.
  • Organiser son travail, découper en petites équipes, feature teams, devops.
  • Software Craftsmanship : bien concevoir le logiciel, penser à la valeur ajoutée de chaque évolution, faire des codes review, du pair programming.
  • Avoir une ouverture technologique.
  • Faire plaisir aux développeurs ce n’est pas que le café gratuit, les pizzas, les nerfs, le baby-foot… Tout ceci est juste un plus et il ne faut pas perdre de vue le reste. Les autres sociétés proposent la même chose et les autres éléments de cette liste vont aussi être déterminants.
  • S’organiser en communauté, pouvoir trouver de l’aide dans les équipes et se rendre utile en aidant les autres.
  • Contribuer à l’open source. Cela permettra de continuer l’apprentissage, de recevoir des critiques constructives et de s’améliorer.
  • Participer aux événements, Devoxx, Meetups, BBL, hackatons (1 à 3 jours), conférences interne, sponsoring d’événements… Toujours dans un but d’apprentissage, d’ouverture d’esprit.
  • Valoriser les développeurs pour qu’ils puissent apprendre tout le temps.

 

SOYEZ HOLOGRAPHIQUE ! youtube

Michel Rousseau twitter

Présentation des HoloLens par Microsoft. Très beau produit, unique en son genre qui permet une projection (et non un affichage) d’hologrammes sur des « lunettes ». L’orientation du produit est plus professionnelle pour l’instant et permet par exemple à un mécanicien d’avoir les plans d’une voiture sous les yeux en permanence, de faire des appels Skype… L’avantage ici est vraiment d’avoir des hologrammes qui se superposent au réel et qui enrichissent le quotidien. Le « casque » capte son environnement grâce à la même technologie qui avait été utilisé dans Kinect et il est complètement indépendant (environ 2h30 d’autonomie), il intègre CPU, GPU, RAM, DD, …

Il est cependant très cher : 3299€ pour l’édition de dev, 5499€ pour l’édition commerciale.

La conférence s’est finie avec la présentation d’un nouveau concept en cours de recherche par Microsoft. Il s’agit « simplement » de pouvoir afficher l’hologramme d’une autre personne, dans la pièce où vous êtes. Ils ont appelés ça l’Holoportation et cela ressemble très fortement à ce qui est montré dans les films Star Wars… C’est encore en développement et cela nécessite notamment une dizaine de Kinect dans toute la pièce pour fonctionner !

 

UNE APPLICATION QUI VOIT, ENTEND ET RÉPOND youtube

Christophe Jollivet twitter ET Mickael Debonnaire twitter

Cette présentation montrait comment construire simplement une application utilisant les dernières avancées en terme d’intelligence artificielle. Pour cela quatre services nous ont été présentés :

  • Beta face pour faire de la reconnaissance d’image, et de visages plus précisément.
  • Speech recognition afin de transformer en texte ce que dit l’utilisateur à voix haute.
  • Api.ai pour reconnaître ce texte et faire des actions en fonction de ce que demande l’utilisateur.
  • Les APIs standards des OS pour générer de la voix et répondre à l’utilisateur.

 

PATTERN MATCHING EN JAVA (10 ?) youtube

Remi Forax

Cette présentation nous a donnée un aperçu de ce qui est dans les chantiers pour Java et ce qui pourrait être intégré à la version 10 ou plus. Les trois projets les plus important ont été détaillés.

  • Valhalla, apportant les Value Types et la Generic Specialization.
  • Panama, pour pouvoir manipuler plus facilement le code natif, notamment pouvoir appeler des fonctions C/C++ depuis la JVM.
  • Amber, apportant l’inférence des types. On pourra faire var name = « Julien » au lieu de String name = « Julien ». Les énumérations sont améliorées avec la possibilité de les rendre génériques. Les lambdas seront améliorées avec quelques idées qui avaient été laissées de côté. Des classes « data » qui permettraient de pouvoir juste déclarer les champs, le compilateur générera les accesseurs et constructeurs. Le Pattern Matching pourra également être de la partie.

Une bonne partie de la présentation était dédiée à ce dernier, avec une proposition de l’implémentation future possible. Il permettrait d’améliorer grandement les switch et de se passer des if-else-if-else-if à la chaine.

 

DE BRONZE A LÉGENDAIRE, COMMENT RÉUSSIR VOS IA DE BOTS youtube

Grégory Ribéron twitter

La présentation était vouée à nous expliquer comment créer des IA de bots efficaces qui peuvent atteindre le top 100 sur des sites tels que CodinGame. L’essentiel est de progresser pas à pas, bien comprendre l’énoncé, mapper correctement les mécanismes du jeu, regarder notre bot jouer, s’inspirer des autres…

Une des techniques est notamment l’utilisation d’algorithmes génétiques, qui permettent de prévoir certaines issues du jeu et ainsi corriger le comportement du bot en temps réel.

 

RECETTES, OUTILS, API ET SERVICES POUR CONSTRUIRE SON EQUIPE OU SA STARTUP youtube

Nicolas Martignole twitter

Trois maîtres mots pour le conférencier : rapidité, transparence et intensité.

On dénombre certains outils et/ou api externes pour simplifier la vie des codeurs et de l’entreprise. Cela passe par des outils de gestions de mail avec Mailjet et Mailgun.
Un point était axé sur la sécurité avec la gestion de double authentification et les réinitialisations de mot de passe par sms.
Egalement le monitoring de services avec des scénarios pour la gestion des temps de traitements avec Runscope.

Puis un gros point sur la communication interne et externe avec des outils performants de live chat pour augmenter la réactivité comme Slack et ses différents modules connectés (runscope, jenkins, etc).

 

JUnit-Docker youtube

Xavier Detant twitter ET Vincent Demeester twitter

Présentation rapide de la libraire JUnit-docker pour JUnit 5. Elle permet grâce à des annotations de lancer des conteneurs au démarrage d’une suite de tests. Plusieurs options sont disponibles, notamment pour spécifier l’image à démarrer et les ports à exposer. Le conteneur peut être redémarré pour chaque test ou réutilisé pour l’ensemble.

 

Log me Tender youtube

Olivier Croisier twitter

Discussion intéressante sur la mise en place d’une couche de service pour gérer les logs au sein d’une application. Cela permettrait de faire évoluer tout un log orienté métier avec des précisions comme les horaires de démarrage et fin, la durée, etc.. Tout ceci par la modification d’une seule méthode appelante. Cela permettrait également d’utiliser du java 8 dans le traitement de la couche de log car actuellement Log4j n’est pas migré et donc pas d’utilisation possible de lambda par exemple.

 

Retours sur Devoxx France 2016 : le jeudi

Devoxx 2016

 

Le but de cet article est de vous présenter quelques conférences intéressantes que j’ai pu suivre cette année, le jeudi 21 avril 2016, au Devoxx France, afin de vous donner envie de les consulter par vous-même. Ces retours sont basés sur ma compréhension personnelle et mes souvenirs, il se peut donc que cela ne soit pas complet ou ne reflète pas complètement la réalité ! Les liens vers les conférences sont donnés à chaque fois pour vous permettre de juger par vous-même.

 

La médecine de demain youtube

Jean-Michel Billaut twitter

Cette première keynote de Devoxx 2016 a permis d’avoir un aperçu de ce que pourra être la médecine demain. Le séquençage de nos génomes devrait devenir un standard pour arriver à une médecine de précision; les traitements seront adaptés à notre organisme et ne seront plus génériques. Cela servira à évaluer notre état de santé et détecter plus en amont cancers et autres maladies. Le séquençage de génomes est déjà possible à l’étranger, mais illégal en France et puni par la loi. La France accuse donc un retard là-dessus. Des startups anglaises, américaines et chinoises ont déjà une grosse base commune de génomes à des fins d’analyses. Une startup chinoise est d’ailleurs déjà évaluée à un milliard de dollars dans ce domaine.
D’autres technologies pourront par exemple nous permettre d’analyser nos aliments en temps réel, d’en connaître leur composition et faire le lien avec notre génome et état de santé pour savoir s’il est recommandé de manger telle ou telle chose.

 

The impact of code in society youtube

Joel Spolsky twitter

Deuxième keynote de la journée. Un des fondateurs de Stack Overflow nous a fait réfléchir sur l’impact des développeurs sur notre vie quotidienne. La décision d’un développeur peut impacter des milliers de personnes, comment celles-ci vont se réveiller le matin, comment elles vont faire du sport… Mais aussi changer l’humeur des personnes. L’exemple de Facebook était évocateur. Facebook n’affiche pas toutes les publications de tous vos amis, un algorithme se charge d’en afficher une plutôt qu’une autre. Il revient donc aux développeurs notamment de choisir que montrer à l’utilisateur. Uniquement des publications qui le rendront heureux ? Et dans ce cas cacher l’annonce d’une maladie d’un ami ? Faut-il que Facebook affiche la photo de votre ex avec son/sa nouveau/nouvelle copain/copine ? Il y a des décisions morales à prendre qui impactent plus d’un milliard de personnes. De même, qu’est-ce qui empêcherait Facebook d’influencer l’opinion des gens et de prendre un parti politique en mettant plus en avant un certain candidat et ainsi lui apporter plus de voix ?
Un autre exemple est celui de l’employé Amazon qui déplace des cartons toute la journée dans un entrepôt, en suivant les instructions données par un logiciel. Celui-ci dicte les pas et « contrôle » en quelque sorte tous les jours des centaines d’employés.
En conclusion, nous ne passons pas 5 minutes sans utiliser un logiciel qui impacte notre vie, d’une certaine manière décidée par un développeur ou une société et cela n’ira qu’en empirant.

 

L’entrepreneuriat au féminin youtube

Natacha Quester-Séméon twitter

Dernière keynote de la journée, intéressante et orientée féministe. La speakeuse nous a parlé notamment de Ada Lovelace et Margaret Hamilton, deux femmes sans qui les langages de programmation n’auraient pas été inventés et l’homme n’aurait pas marché sur la lune. Elle nous a également parlé du collectif JamaisSansElles, qui soutient les femmes un peu à la manière du mouvement solidaire international HeForShe. JamaisSansElles a été initié par le club des gentlemen et toutes les personnes adhérant à ce mouvement s’engagent à ne plus participer à une réunion ou débat public s’il n’y a pas au moins une femme participante. Elle nous a parlé ensuite de l’association qu’elle a créée, Girl Power 3.0 qui est composée d’entrepreneuses et innovatrices.
Dans l’ensemble, elle nous a parlé de la place des femmes dans le milieu informatique, de la nécessité de les intégrer dans les projets, organisations et débats.

 

Java SE 8 pour les développeurs Java EE youtube

José Paumard twitter et David Delabassee twitter

Cette session été axée sur la présentation des fonctionnalités de Java SE 8 appliquées à Java EE 7, ce qu’il est possible d’utiliser et ce qui ne l’est pas. Je vous laisse consulter la vidéo pour en savoir plus, elle est agrémentée de nombreux exemples sur notamment la nouvelle API Date, les annotations multiples, la validation de Bean, les streams, etc.

 

Analyzing Images with Google’s Cloud Vision API Speaker Deck

Sara Robinson twitter

Présentation par une Américaine fan de Harry Potter. Elle nous a présenté les possibilités des API de Google, notamment de l’analyse d’images via du machine learning. Il est possible d’envoyer des images à Google et ceux-ci vont nous retourner un ensemble de tags qui décrivent la photo (c’est donc l’inverse de la recherche Google Images). Cette API est très puissante et capable par exemple de faire la différence entre la tour Eiffel de Paris et la réplique à Las Vegas. L’API peut également détecter les visages et l’humeur des personnes. Il y a également une API de speech qui retourne à partir d’un fichier audio le transcript de celui-ci.

 

Stack Overflow behind the scenes – how it’s made youtube

Oded Coster twitter

Un développeur de Stack Overflow nous a présenté leur architecture. Il nous a exposé quelques chiffres impressionnants (à retrouver ici), comme leurs seulement 4 serveurs SQL notamment avec entre 384Go et 768Go de RAM chacun. Ils ont une stack essentiellement Microsoft, mais leur philosophie est simple, ce qu’ils ont actuellement fonctionne très bien, donc pourquoi le changer. Si un jour, dans leurs expérimentations, ils trouvent quelque chose de plus adapté et qui fonctionne mieux pour eux, alors ils migreront. Il n’y a aucun intérêt de migrer juste pour migrer. Leurs 9 serveurs Web leur permettent de faire des mises en production sans downtime, vu qu’ils sont tous en load balancing.
De la même manière, une migration vers le cloud leur coûterait plus cher et il faudrait refaire complètement leur architecture, donc ils n’ont pas souhaité migrer et on gardé leur propre architecture.

 

Retours sur Java 8 youtube

Jean-Michel Doudoux twitter

La présentation était un petit tour des nouveautés de Java 8, avec des bonnes pratiques recommandées par le présentateur.
Par exemple, il est inutile de mettre des Optional de partout, cela ne fait qu’introduire de la complexité. Les Optional peuvent être évidemment utiles, mais cela ne sert à rien de les utiliser à tout prix.
Autre exemple, inutile de vouloir mettre des lambdas à tout bout de champ. Il faut plutôt essayer de faire uniquement des lambdas d’une seule instruction, sinon le débug peut devenir trop complexe. Dans l’ensemble, il faut faire en sorte de garder des instructions lisibles, quitte à sortir les 5 lignes de code d’une lambda dans une méthode à part.
Il faut également faire très attention à la possibilité de lancer des streams en parallèle. Même si le faire est très simple, dans la plupart des cas cela peut ralentir les traitements plutôt que les accélérer… Il ne faut pas hésiter à faire des tests de performance pour s’assurer que l’utilisation du parallel() est bénéfique.
D’autres points sont également abordés dans la conférence, je vous invite à regarder la rediffusion pour en savoir plus.

 

High-Performance Hibernate youtube

Vlad Mihalcea twitter

Présentation très intéressante et assez complexe sur l’utilisation d’Hibernate et comment en tirer un maximum de performances.
Il a parlé des différentes étapes d’une requête (temps d’acquisition de la connexion, logique d’accès aux données, temps de soumission, temps d’exécution, temps de récupération et temps d’inactivité avant release de la connexion) et ce qui peut être fait pour accélérer les traitements. Il a notamment évoqué l’utilisation des batchs insert et update, des relations entre les entités, de cache de données, des paramètres qui ont pu changer entre les différentes versions d’Hibernate, etc.
Le présentateur a d’ailleurs un blog sur lequel il a écrit un bon nombre d’articles sur le framework et un livre sur le sujet.

 

String Concatenation de 1 à 9 youtube

Remi Forax

La présentation a été menée par un maître de conférence à l’université Paris Est Marne-la-Vallée, développeur sur l’OpenJDK et expert JCP sur 3 JSR (invokedynamic, lambda et Jigsaw).
Le but de la présentation était de savoir comment concaténer des strings de manière la plus performante possible.
Après une analyse du bytecode et du code assembleur géré par la JVM, la conclusion contre toute attente était que le plus rapide, dans son cas présenté, est l’opérateur + et non le StringBuilder. Ceci à cause du JIT qui reconnaît certains patterns de code, certaines méthodes communes et les remplace à la volée par du code assembleur optimisé au runtime. Il nous a ainsi conseillé de coder comme la majorité des gens le font pour que le code soit reconnu par le JIT et soit plus performant. Dans l’ensemble, il est donc plutôt conseillé d’utiliser l’opérateur + pour des concaténations simples et le StringBuilder en cas de boucles, tout en gardant des instructions simples dans ce dernier (pas de i++, pas de Object.toString()), sinon les optimisations ne fonctionneront pas.
Il nous a ensuite expliqué que cela sera réglé avec Java 9 grâce notamment à son travail sur la JSR invokedynamic, mais que le comportement des strings risque d’être altéré. Il nous conseille donc dès maintenant de tester les early builds du JDK9 afin de voir s’il n’y a pas de régression et ainsi les reporter.

 

Modular monoliths youtube

Simon Brown twitter

Présentation discutant des architectures monolithiques et microservices. Le speakeur propose tout au long de la conférence une architecture orientée module, organisée par fonctionnalité plutôt que par service, ou DAO ou contrôleur… Selon sa présentation, cela règle la plupart des problèmes d’architecture qui surviennent au bout d’un moment sur les projets. Il a commencé la conférence par la phrase « Monolith are big balls of mud » et fini en disant que si on ne sait pas bien organiser un gros projet, un ensemble de petits projets ne sera pas mieux et ce n’est pas la solution. Sa phrase de fin était donc « Microservices are a distributed big ball of mud ».

 

Performance: Java vous déclare sa flamme youtube

Vincent Beretti twitter et Nicolas Peters twitter

Présentation sur comment débugger plus facilement des problèmes de performances sur des applications Java, ou autre, avec les Flame graphs. Ils ont présenté les outils créés par un développeur de chez Netflix (Brendan Gregg) spécialiste des Flame graphs, afin d’en générer depuis des threads dump. Ils ont pris un cas concret pendant leur présentation et ont analysé les problèmes de performances avec ces outils.

Grails partie 5 : Les contrôleurs et les vues

Grails_logo

 

Bienvenue dans le cinquième article de notre série sur le framework Grails ! Nous allons aborder aujourd’hui les contrôleurs et les vues.

Nous partons du principe que vous avez déjà suivi les quatre articles précédents : Introduction à GrailsGrails partie 2 : création d’une application basiqueGrails partie 3 : La validation et Grails partie 4 : Les relations.

Nous allons en premier lieu analyser le contenu d’un contrôleur, puis nous verrons les éléments importants à connaitre sur les vues.

Lire plus

Grails partie 4 : Les relations

Grails_logo

 

Dans ce quatrième article sur le framework Grails, nous allons aborder les relations entre entités. Cela va nous permettre de posséder enfin un modèle de données correct et permettre à l’utilisateur, dans notre cas par exemple, de choisir à quelle course il veut participer.

Nous partons du principe que vous avez déjà suivi les trois articles précédents : Introduction à GrailsGrails partie 2 : création d’une application basique et Grails partie 3 : La validation.

Nous allons voir quatre types de relations puis les mettre en oeuvre sur notre application que nous mettons à jour depuis le deuxième article. Pour rendre notre explication plus claire, nous l’agrémenterons d’exemples très parlants de la documentation officielle.

Lire plus

Grails partie 3 : La validation

Grails partie 2 : création d’une application basique

Grails_logo

 

Dans ce deuxième article sur le framework Grails, nous allons créer une application simple de CRUD. Vous pourrez ainsi voir à quel point il est rapide et facile de créer une telle application.

Nous partons du principe que vous avez suivi l’article précédent.

Dans cet article et dans les suivants, nous donnerons à chaque fois les deux possibilités pour réaliser une action : la version graphique et la version en ligne de commande qui vous servira principalement si vous n’utilisez pas le même IDE.

Lire plus

Introduction au framework Grails

Grails_logo

 

L’objectif de cet article et de ceux à venir est de vous présenter les avantages que peut vous apporter le framework Grails. Pourquoi, quand et comment l’utiliser ? Nous verrons cela par la suite.

 

 

Présentation de GRAILS

 

Grails est un framework web open source, de développement rapide, basé sur le langage Groovy, lui-même basé sur le langage Java.

Il utilise plusieurs principes qui permettent une haute productivité :

– Don’t Repeat Yourself (DRY) : le framework est basé sur le modèle MVC.

– Convention plutôt que configuration (Convention over configuration ou coding by convention) : Grails propose de nombreux comportements par défaut, vous n’aurez presque rien à configurer lors du développement de votre application. Par exemple, une classe dont le nom termine par « Controller » sera automatiquement considérée comme un contrôleur web.

– Architecture orientée modèle : pour réaliser une application basique, vous aurez uniquement à vous préoccuper de vos modèles. Les vues, les contrôleurs et les tests seront générés.

– Prototypage : Grails vous permet de générer vos vues, contrôleurs et tests à partir de vos modèles grâce à des méthodes de scaffolding. Vous pouvez ainsi obtenir une application de CRUD très rapidement. Vous pouvez également créer vos propres templates pour ajouter des fonctionnalités à la génération, ou simplement modifier l’apparence de votre application.

– Plugins : de nombreux plugins sont disponibles pour Grails. Ils vous permettront d’implémenter rapidement des fonctionnalités, telles que l’authentification avec le plugin Spring Security Core.

 

Historique

 

Le développement de Grails a été débuté en juillet 2005 par Graeme Rocher. Le framework était alors connu sous le nom de “Groovy on Rails”, car inspiré de “Ruby on Rails”. La première version (0.1) a été publiée le 29 mars 2006. Le même mois, il est renommé en “Grails” sous la demande du créateur de Ruby on Rails, David Heinemeier Hansson. Les principales versions suivantes sont:

 

[table id=1 /]

 

Peu après la sortie de la version 1.0, la société G2One (The Groovy Grails Company) est rachetée en novembre 2008 par SpringSource, elle-même rachetée en août 2009 par VMware.

 

Architecture

 

Grails utilise de nombreuses technologies existantes. Les principales sont :
– Le langage Groovy
– Hibernate
– Spring
– Sitemesh pour gérer la mise en page
– Le célèbre système de logging Log4J
– JUnit pour les tests unitaires

Celles-ci sont organisées comme montré ci-dessous :

architecture_grails

 

Toute application Grails est organisée en quatre parties : les domaines (les modèles), les services, les contrôleurs et les vues. Nous verrons plus en détail cette organisation par la suite avec un exemple d’application.

Les vues sont gérées par le framework SiteMesh, permettant notamment de créer des layouts, tandis que le cœur de Grails est géré par le framework Spring. La persistance des données est facilitée par GORM (Grails Object Relational Mapping). Celui-ci est basé sur Hibernate et utilise par défaut sa base de données intégrée HSQLDB, il permet de faire la relation entre les domaines et la base de données. Nous le verrons plus en détail dans un article suivant. Gant quant à lui est basé sur Ant, il sera utilisé notamment lorsque nous exécuterons une commande pour gérer Grails telle que « grails run-app ».

Pour terminer, tout objet de votre application pourra être développé soit en Java soit en Groovy. Dans les deux cas, votre objet sera compilé en bytecode et exécuté par la JVM.

 

Installation

 

Nous allons maintenant voir comment mettre en place un environnement de développement pour utiliser Grails.

Avant de commencer, il faut bien évidemment avoir installé un JDK (en version 1.6 ou supérieure), avoir configuré la variable d’environnement JAVA_HOME, pointant vers le dossier d’installation de votre JDK, et avoir ajouté le dossier bin/ du JDK à votre variable PATH.

Il existe plusieurs solutions pour utiliser le framework Grails. La première, la plus simple, consiste à télécharger l’IDE Groovy/Grails Tool Suite (GGTS). Il s’agit d’un environnement de développement basé sur Eclipse, tout comme Spring Tool Suite (STS). Il vous suffit ensuite d’extraire l’archive téléchargée, et de lancer GGTS.

Si vous possédez déjà STS, vous pouvez facilement installer le plugin Grails en suivant ces directives.

Si vous souhaitez utiliser Grails avec un autre IDE comme IntelliJ IDEANetBeans ou TextMate, nous vous laissons consulter la documentation officielle à ce propos.

 

Conclusion

 

Après cette présentation, vous pouvez déjà apercevoir les avantages que peut fournir Grails. Il utilise le langage moderne Groovy, le réputé framework Spring, de nombreux plugins, le principe de « coding by convention », le prototypage… Il s’agit d’un framework bien adapté au développement très rapide d’applications basiques, vous laissant en même temps la possibilité de réaliser des fonctionnalités bien plus avancées que du simple CRUD.

Dans les prochains articles, nous verrons plus en détail le fonctionnement du framework par un exemple d’application.

 

Sources

http://grails.org/

http://en.wikipedia.org/wiki/Grails_(framework)

http://www-igm.univ-mlv.fr/~dr/XPOSE2009/Groovy_and_Grails/grails_architecture.php

JAVA EE 7 et JSON

Nous sommes de plus en plus souvent amenés à échanger des données en JSON en remplacement de XML.

JSON est né avec AJAX et les Web Services REST dans le but d’obtenir un format d’échange simple et peu verbeux (à l’inverse du XML).

Pour plus de détails sur JSON voir l’article de Wikipedia ou pour les plus techniques le site json.org.

Mais Java ne permettait pas, jusqu’à peu, de traiter nativement des messages JSON.

La version 7.0 de Java EE intègre le support de la JSR 353 qui est l’API Java pour le JSON Processing (JSON-P) et définit l’API pour analyser, générer, transformer et requêter du JSON.

L’avantage de cette spécification est de standardiser le traitement des flux JSON en Java. Mais nous allons voir dans cet article si elle apporte suffisamment en comparaison de frameworks Java de traitement JSON tels que Gson, même pour des traitements très simples.

Nous créons un objet People qui nous permet de tester les différents cas (tableau, composition, …) :

public class People {
	
	private String name;
	private String firstName;
	private Date birthDate;
	private Address address;
	private List<PhoneNumber> phones;
	...

public class Address {
	
	private String addressStreet1;
	private String addressStreet2;
	private int addressNumber;
	private String zipcode;
	private String town;
	...

public class PhoneNumber {
	
	private String type;
	private String number;
	...

Création d’un jeu de tests :

		people = new People();
		Address address = new Address();
		address.setAddressNumber(12);
		...
		PhoneNumber mobilePhone = new PhoneNumber();
		...
		PhoneNumber workPhone = new PhoneNumber();
		...		
		people.setFirstName("Paul");
		people.setName("Dubois");
		...
		ArrayList<PhoneNumber> phones = new ArrayList<PhoneNumber>();
		phones.add(mobilePhone);
		phones.add(workPhone);
		people.setPhones(phones);
Données de test

JSON-P

JSON-P propose deux modèles de développement :

  • Le modèle objet crée un arbre qui représente les données JSON en mémoire (équivalent au DOM en XML).
  • Le modèle Streaming permet de parcourir un document JSON à partir d’évènements (début ou fin d’un objet ou d’un tableau, lecture d’une clé ou d’une valeur, …) (équivalent StAX en XML).

Les classes principale de l’API sont :

  • JsonObjectBuilder & JsonArrayBuiler : pour créer des objets ou tableaux JSON
  • JsonReader & JsonWriter : pour lire et écrire des objets JSON
  • JsonObject, … : réprésentation des types de données JSON
		JsonObjectBuilder jsonBuilder = Json.createObjectBuilder()
				.add("firstName", people.getFirstName())
				.add("name", people.getName())
				.add("birthDate", people.getBirthDate().toString())
				.add("address", Json.createObjectBuilder()
						.add("addressNumber", people.getAddress().getAddressNumber())
						.add("addressStreet1", people.getAddress().getAddressStreet1())
						.add("addressStreet2", people.getAddress().getAddressStreet2())
						.add("addressZipCode", people.getAddress().getZipcode())
						.add("town", people.getAddress().getTown())
						.build()
						);
		JsonArrayBuilder arrayBuilder = Json.createArrayBuilder();
		for (PhoneNumber phoneNumber : people.getPhones()) {
			arrayBuilder.add(Json.createObjectBuilder()
					.add("type", phoneNumber.getType())
					.add("number", phoneNumber.getNumber()));
		}
		
		jsonBuilder.add("phones", arrayBuilder);
		
		JsonObject jsonObject = jsonBuilder.build();
		
		StringWriter stWriter = new StringWriter();
		JsonWriter jsonWriter = Json.createWriter(stWriter);
		jsonWriter.writeObject(jsonObject);
		jsonWriter.close();
		
		String jsonData = stWriter.toString();
JSON-P

1 & 2 – Création du JsonObjectBuilder et ajout des propriétés simples.

5 – Ajout d’un objet Address à l’objet People

13 – Création d’un tableau pour représenter la liste de téléphone

22 – Création du JsonObject représentant notre People

25 & 29 – utilisation d’un JsonWriter pour représenter notre People sous forme de String

 

{
  "firstName": "Paul",
  "name": "Dubois",
  "birthDate": "Mon Jun 12 08:06:24 CEST 1978",
  "address": {
    "addressNumber": 12,
    "addressStreet1": "Rue de la République",
    "addressStreet2": "Immeuble des tests",
    "addressZipCode": "13001",
    "town": "Marseille"
  },
  "phones": [
    {
      "type": "mobile",
      "number": "0612345678"
    },
    {
      "type": "work",
      "number": "0412345678"
    }
  ]
}
Résultat JSON-P

 GsON

Gson est une librairie Java développée par Google pour transformer des objets Java vers leur représentation JSON et vice-versa.

Les objectifs principaux de Gson sont :

  • Fournir un mécanisme simple pour convertir un objet Java en JSON et vice-versa
  • Permettre de convertir des objets existants et non modifiables
  • Permettre d’obtenir une représentation personnalisée des objets

 

La classe principale de Gson est Gson. Elle permet de convertir très rapidement un objet Java en JSON :

		Gson gson = new Gson();
		gson.toJson(people);
Gson

Le code parle de lui-même…

{
  "name": "Dubois",
  "firstName": "Paul",
  "birthDate": "Jun 12, 1978 8:06:24 AM",
  "address": {
    "addressStreet1": "Rue de la République",
    "addressStreet2": "Immeuble des tests",
    "addressNumber": 12,
    "zipcode": "13001",
    "town": "Marseille"
  },
  "phones": [
    {
      "type": "mobile",
      "number": "0612345678"
    },
    {
      "type": "work",
      "number": "0412345678"
    }
  ]
}
Résultat Gson

Le résultat est sensiblement le même que pour JSON-P si ce n’est le formatage des dates différent.

Gson propose un mécanisme de Serializer et Deserializer personnalisé qui nous permet d’appliquer un formatage particulier à un type donné (Date par exemple) ou plus généralement une représentation particulière pour un objet.

L’exemple suivant montre la création d’un Serializer personnalisé :

public class PeopleSerialiser implements JsonSerializer<People> {
	public JsonElement serialize(People people, Type arg1,
			JsonSerializationContext arg2) {
		final JsonObject jsonObject = new JsonObject();
		jsonObject.addProperty("firstName", people.getFirstName());
		jsonObject.addProperty("name", people.getName());
		jsonObject.addProperty("birthDate", people.getBirthDate().toString());
		jsonObject.addProperty("addressNumber", people.getAddress().getAddressNumber());
		jsonObject.addProperty("addressStreet1", people.getAddress().getAddressStreet1());
		jsonObject.addProperty("addressStreet2", people.getAddress().getAddressStreet2());
		jsonObject.addProperty("addressZipCode", people.getAddress().getZipcode());
		jsonObject.addProperty("town", people.getAddress().getTown());

		final JsonArray jsonAuthorsArray = new JsonArray();
        for (final PhoneNumber phoneNumber : people.getPhones()) {
        	final JsonObject number = new JsonObject();
        	number.addProperty("type", phoneNumber.getType());
			number.addProperty("number", phoneNumber.getNumber());
            jsonAuthorsArray.add(number);
        }
        jsonObject.add("phones", jsonAuthorsArray);
		return jsonObject;
	}
}

1 & 2 : Notre Serializer implémente l’interface JsonSerializer et définit la méthode serialize qui prend notamment en paramètre un objet People pour renvoyer un JsonElement.

4 : La suite ressemble un peu à JSON-P avec la création d’un JsonObject qui est la représentation de l’objet en JSON (JsonArray pour les tableaux).

Dans cet exemple on construit une représentation de notre objet People en publiant une adresse « à plat » et non comme objet au sein de People.

		final GsonBuilder gsonBuilder = new GsonBuilder();
	    gsonBuilder.registerTypeAdapter(People.class, new PeopleSerialiser());
	    gsonBuilder.setPrettyPrinting();
	    final Gson gson = gsonBuilder.create();
	    gson.toJson(people);

Afin d’utiliser notre serializer on crée un GsonBuilder (1) auquel on passe notre serializer (2).

L’option setPrettyPrinting permet d’obtenir une représentation JSON formatée et indentée.

Puis cette fois on crée notre objet Gson grâce à la méthode create du GsonBuilder (4).

On obtient un résultat conforme à nos attentes :

{
  "firstName": "Paul",
  "name": "Dubois",
  "birthDate": "Mon Jun 12 08:06:24 CEST 1978",
  "addressNumber": 12,
  "addressStreet1": "Rue de la République",
  "addressStreet2": "Immeuble des tests",
  "addressZipCode": "13001",
  "town": "Marseille",
  "phones": [
    {
      "type": "mobile",
      "number": "0612345678"
    },
    {
      "type": "work",
      "number": "0412345678"
    }
  ]
}
Résultat Gson serializer

Conclusion

L’api JSON-P au sein de JEE7 est une vrai avancée car elle permet de traiter nativement du JSON. Mais le manque principal actuel est le binding natif d’un objet Java vers JSON.

On voit que dans le cas où on construit une API basée sur des échanges JSON et des objets métiers, l’utilisation de JSON-P sera bien trop verbeuse et on privilégiera l’utilisation de Gson (ou d’autres framework comme celui-ci) dont le coût de construction sera quasiment nul.

Dans le cas où l’on doit intégrer des messages JSON existants, la question se pose. Soit nos objets métiers n’existent pas et on va avoir tendance à utiliser Gson et le binding, soit nos objets métiers existent et la question se pose car la verbosité des deux API sera quasiment identique.

Il faudrait ensuite approfondir l’étude des deux sur des aspects tels que les performances pour faire son choix. Gson donne quelques indications à ce sujet (ici) mais un comparatif sur un même jeu de données serait intéressant.

Ce manque de binding a clairement été identifié par Oracle, notamment lors d’un sondage sur les nouveautés à apporter à JEE8. Une nouvelle JSR va être soumise d’ici peu pour intégrer une API Java JSON Binding à JEE8.

Prochains tests lors de la sortie de JEE8…

Sélection de colonnes dans Hibernate

 Liste avec seulement quelques colonnes dans Hibernate

Les outils d’ORM (Hibernate, Ibatis, …) sont aujourd’hui à maturité et ne souffrent plus des problèmes de performance des premières versions. Le code SQL généré, ainsi que la transformation en objets, ont été très largement optimisés.

Cependant selon la taille de la grappe d’objet remontée, il peut subsister des problèmes de performance, liés au nombre et à la complexité des objets à créer. Le cas d’utilisation typique sur une application de gestion est l’affichage d’une liste d’objet complexe sur un écran de recherche.

Prenons le cas par exemple d’une liste de commande (que nous simplifions volontairement) :

public Class Commande {

private Destination destination;

private Set<LigneCommande> lignes;

private Client client;

...

}
Une requête Criteria qui permet de remonter la liste des commandes ressemble à ceci :
DetachedCriteria criteria = DetachedCriteria.forClass(Commande.class,"commande")

.createAlias("commande.Destination", "destination", CriteriaSpecification.LEFT_JOIN)

.createAlias("commande.Lignes", "lignes", CriteriaSpecification.LEFT_JOIN)

.createAlias("commande.Client", "client", CriteriaSpecification.INNER_JOIN);

List<Commande> listCommande = getHibernateTemplate().findByCriteria(criteria);
Cette requête remonte donc tous les objets Commande (toutes les colonnes de la table correspondante), ainsi que les objets liés (et donc toutes les colonnes associées). Dans le cas où la grappe d’objets est importante et composée de nombreux objets, le nombre de lignes remontées devient très important et la constitution des objets très coûteuse  Rappelons que nous souhaitons simplement afficher une liste avec seulement quelques colonnes… au moins 95% des données remontées ne nous servent donc à rien.

Depuis la version 3 d’Hibernate a été introduite la notion de Projection. Celle-ci va nous permettre non seulement de remonter seulement les colonnes qui nous intéressent mais également une liste d’objets non gérés par Hibernate ; par exemple nous allons pouvoir remonter directement une liste de DTO (data transfert object) en se basant sur le même objet criteria (forClass(Commande.class, »commande »)) :

On définit le DTO :

public class DealListDto implements Serializable  {
    private static final long serialVersionUID = 1L;

    private java.lang.String id;
    private String ref;
    private Date date;
    private String nom;
    private String prenom;
    private String destNom;
    ...
}
puis les propriétés que l’on souhaite remonter, ainsi que le bean avec lequel on veut les mapper :
criteria.setProjection(Projections.projectionList()

.add(Property.forName("commande.Id"), "id")

.add(Property.forName("commande.Ref"), "ref")

.add(Property.forName("commande.Date"), "date")

.add(Property.forName("client.Nom"), "nom")

.add(Property.forName("client.Prenom"), "prenom")

.add(Property.forName("destination.nom"), "destNom")

.setResultTransformer( Transformers.aliasToBean(DealListDto.class));

List<DealListDto> listCommande = getHibernateTemplate().findByCriteria(criteria);
Nous obtenons donc une liste de DealListDto, beaucoup plus légers, que nous pouvons  faire remonter directement sur la couche client.
Loading...
X