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.

 

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

Caches applicatifs avec Spring et ehcache

La recherche de performances applicatives passe souvent par la mise en place de caches applicatifs.

Ces caches permettent de maintenir en mémoire les données souvent requêtées par les utilisateurs mais peu mises à jour (paramétrages, villes, …).
Spring offre la mise en place d’un tel cache assez facilement par l’intégration d’un framework tel que ehcache.

Dans le fichier configuration de Spring on ajoute les lignes suivantes :

<ehcache:config failQuietly="false" />
<ehcache:annotations>
<ehcache:caching id="test" cacheName="testCache" />
<ehcache:flushing id="test" cacheNames="testCache" when="after" />
</ehcache:annotations>

Dans le fichier configuration de ehcache.xml, on retrouve la définition du cache : nombre d’objet en cache, écriture sur disque, politique d’éviction,…Le cacheName et ce que l’on va retrouver dans le fichier de configuration de ehcache,
L’id et ce que l’on va retrouver dans l’annotation,
caching l’id est utilisé pour la mise en cache,
flushing l’id est utilisé pour la libération du cache.

<cache name="testCache" maxElementsInMemory="1000"overflowToDisk="true" eternal="true" memoryStoreEvictionPolicy="LFU"/>
On ajoute les annotations suivantes dans le source Java afin de les mettre en cache après le premier appel :
@CacheFlush(modelId = "test")

public String saveObject(Object objet) {…}

 

@Cacheable(modelId = "test")

public User findObject(String idObject) {…}

Gestion des logs

Au sujet de la gestion des logs

La gestion des logs est un sujet qui est souvent sous estimé de la part des équipes de développement. Avec l’utilisation des outils de développement moderne et leur débugger intégré, les logs applicatives ont bien moins d’intérêts au moment du développement. Par contre, lorsque l’application est testée ou déployée, les logs reprennent tout leur sens.

L’apparition de framework Java tels que Log4J ou celui intégré au JDK facilite grandement la vie du développeur, mais l’écriture de logs reste toujours à la discrétion de ce dernier.

L’AOP (Programmation Orientée Aspect) apporte une réponse à cette problématique. Nous pouvons grâce à celle-ci générer des logs à chaque entrée/sortie de méthode et à chaque levée d’exception. Voici un exemple d’implémentation de gestion des logs utilisant Spring et Spring AOP :

Nous définissons tout d’abord un greffon (advice) qui implémente MethodBeforeAdvice, AfterReturningAdvice et ThrowsAdvice. Ceci nous permet de redéfinir les trois méthodes before, afterReturning et afterThrowing afin de générer les logs à chaque entrée/sortie de méthode et à chaque levée d’exception.

package com.viaxoft.ext.logging;

import java.lang.reflect.Method;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.aop.AfterReturningAdvice;
import org.springframework.aop.MethodBeforeAdvice;
import org.springframework.aop.ThrowsAdvice;

public class LoggingAdvice implements MethodBeforeAdvice, AfterReturningAdvice,
ThrowsAdvice {
private static Log logger = null;

public LoggingAdvice() {
}

public void before(Method arg0, Object[] arg1, Object arg2)
throws Throwable {
logger = LogFactory.getLog(arg2.getClass());
logger.info("Entrée dans la méthode : " + arg0.getName());
}

public void afterReturning(Object arg0, Method arg1, Object[] arg2,
Object arg3) throws Throwable {
logger = LogFactory.getLog(arg3.getClass());
logger.info("Sortie de la méthode : " + arg1.getName());
}

public void afterThrowing(Method m, Object[] args, Object target,
Throwable ex) {
logger = LogFactory.getLog(target.getClass());
logger.error("Exceptiondans la méthode : " + m.getName() + " L'exception : "
+ ex.getMessage());
}
}

Nous devons ensuite définir notre aspect sous forme de bean au sein du fichier de config Spring. Nous utilisons l’implémentation RegexpMethodPointcutAdvisor qui nous permet de matcher les méthodes sur lesquelles notre aspects doit s’appliquer grâce à une expression régulière :

<bean id="loggingAdvisor"   class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name="advice" ref="loggingAdvice" />
<property name="patterns" value=".*" />
</bean>

A noter ici que nous générons la log pour toutes les méthodes. On pourrait imaginer générer plusieurs niveau de log (DEBUG, INFO, …), en fonction de la méthode à laquelle on s’adresse ; par exemple les méthodes du layer DAO seraient en DEBUG, alors que celles de la couche service en INFO.

L’implémentation RegexpMethodPointcutAdvisor permet de définir à la fois l’aspect et la coupe au sens AOP.

Nous définissons également le greffon :

<bean id="loggingAdvice"
class="com.viaxoft.ext.logging.LoggingAdvice">
</bean>

Il ne nous reste plus ensuite qu’à tisser les aspects. Nous utilisons DefaultAdvisorAutoProxyCreator pour un tissage automatique :

<bean   class="org.springframework.aop.framework.autoproxy.
DefaultAdvisorAutoProxyCreator" />

Le résultat dans le fichier de log :

juin 06 08:54:25 INFO iaxoft.dao.impl.AddressDaoImpl before Entrée dans la méthode: saveAddress
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl before Entrée dans la méthode: openSession
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl afterReturning Sortie de la méthode : openSession
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl before Entrée dans la méthode: getTransactionManager
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl afterReturning Sortie de la méthode : getTransactionManager
juin 06 08:54:25 INFO iaxoft.dao.impl.AddressDaoImpl afterReturning Sortie de la méthode : saveAddress
Loading...
X