Publié par

Il y a 9 ans -

Temps de lecture 14 minutes

Jazoon’10 – Jour 2

Jazoon 2010

Deuxième journée de la réunion annuelle des Java-holic européens. Le programme est chargé :

Suivez le guide …

Total cost of ownership

La keynote de la seconde journée est tenue par Ken Schwaber, le co-fondateur de Scrum. Il revient sur les bénéfices à tirer de Scrum. Le message n’est pas très neuf pour la communauté des agilistes mais il est toujours bon de se rappeler pourquoi nous essayons de changer les façons de faire. Dans un style très posé, il nous expose quelques axes pour inviter les spectateurs à s’améliorer.

  • Les gens ne sont pas des ressources
  • Il est important de définir la notion de tâche « terminé » pour chaque projet (Definition of Done)

Si votre définition de Done laisse de côté des points importants comme l’écriture de tests ou l’intégration aux autres composants, l’équipe accumule rapidement une grande quantité de tâches non réellement finies. Cette dette devra être prise en compte en mettant en place des sprints dédiés à la stabilisation. Cette solution est bien souvent beaucoup plus coûteuse que de correctement définir et de respecter la definition of done au fil des développements.

Il annonce également le lancement d’une formation de 5 jours spécialement adaptée aux développeurs destinés à travailler en équipe Scrum : Professional Scrum Developper Program.

Unleash your processor(s)

Václav Pech nous fait ensuite une présentation sur différents patterns de programmation concurrente. Selon lui, pratiquement aucune application ne profite des architectures multicore et celles qui en profitent ne le font que par hasard.
Václav présente ensuite un ensemble de patterns notamment :

  • Parallel Arrays qui permet d’effectuer des opérations comme du filtrage ou du calcul sur des éléments stockés dans une collection en parallèle. Tout ce qu’il y a à faire, c’est de définir les opérations qui seront appliquées à la collection. Ceci de facon simple sans manipuler de thread, ni gérer de moniteur transactionnel.
//create a thread pool and store the collection in a Parallel Array
final ForkJoinPool pool = new ForkJoinPool(2);
final ParallelArray people = ParallelArray.createFromCopy(friends, pool);

//Create a predicate for filtering
final Ops.Predicate aWoman = new Ops.Predicate() {
   public boolean op(final Person friend) {
      return !friend.isMale();
   }
};

//Create an operation to retrieve the name from an element
final Ops.Op retrieveName = new Ops.Op() {
   public Object op(final Person friend) {
      return friend.getName();
   }
};

//Perform filtering and mapping concurrently on all elements of the collection
final ParallelArray namesOfWomen =
   people.withFilter(aWoman).withMapping(retrieveName).all();
System.out.println("namesOfWomen = " + namesOfWomen);
  • Fork and join A partir du JDK 7, une nouvelle API du package java.util.concurrency va permettre de définir des tâches et de gérer leur exécution. Le principe de base est de diviser les données à traiter en petites unités de travail et de traiter ces unités en parallèle. Les résultats obtenus en retour seront ensuite agrégés.

Václav présente ensuite d’autres patterns tels que le dataflow concurrency, les actors, les agents, le principe de Shared Mutable State et de Persistent data structures. Ces patterns seront présentés plus en détail dans un futur article dédié à la programmation concurrente.

What’s new in hibernate

Emmanuel Bernard présente les principales évolutions intégrées dans la dernière version d’Hibernate. Le but principal de la version 3.5 était d’implémenter la spécification JPA2. Il revient sur quelques fonctionnalités de la spécification. Notamment :

  • Packaging

Hibernate Annotations et Hibernate Entity Manager sont maintenant dans le même projet que Hibernate Core. Les releases sont maintenant toutes synchronisées, ce qui met fin à la complexe matrice de compatibilité. Les releases du projet d’audit et de gestion de version Envers seront également synchronisées avec le core.

  • Application de formule

Il est désormais possible d’appliquer des fonctions avant la lecture ou l’écriture dans une colonne par la base de données. Un des cas possibles peut être l’utilisation des fonctions d’encryption native d’un SGBD.


   

  • Fetch profile

Pour éviter de générer un trop grand nombre de requêtes, il est possible de charger un arbre d’entités lors du chargement par clé primaire. On paramètre alors dans le fichier de mapping la stratégie de chargement.


   
      
         
         
      
   

La stratégie sera statique et appliquée que l’on charge les entités par la méthode get, les Criteria ou le chargement implicite durant la navigation à travers une association. Une des solutions était de créer un ensemble de méthodes, du type loadCustomer, loadCustomerWithAddress, loadCustomerWithOrders, et d’utiliser une requête HQL pour dynamiquement appliquer une stratégie de chargement (en HQL : inner join fetch). Mais ceci ne permet pas de définir des stratégies dynamiques pour les chargements implicites.

Hibernate propose maintenant une manière plus simple de gérer les stratégies de chargements. On peut désormais définir dans le fichier de mapping plusieurs stratégies pour une association.


   
      ...
      
         
      
   

et définir la stratégie à utiliser pour chacune des sessions avec la méthode suivante :

Session session = ...;
session.enableFetchProfile( "clientAvecFacture" );
Client client = (Client) session.get( Client.class, clientId );

iPhone/iPad dev from Java perspective

Ognen Ivanovski, de la société Netcetera, nous présente son retour d’expérience sur les développements pour l’iPhone (et donc pour l’iPad). Étant développeur Java à la base, il nous expose les écueils auxquels risquent de se heurter les développeurs Java en arrivant sur cette plateforme, ainsi que les points importants à garder en tête pour le design.

N’espérez donc pas voir apparaitre une méthode magique pour développer en Java pour l’iPhone. Comme Ognen l’a rappelé, Apple n’autorise dans AppStore que les applications rédigées en Objective-C. Il commence par un petit rappel sur l’environnement de développement sanctifié par Apple, à savoir : XCode, Interface Builder, iPhone Simulator et Instruments (pour le profiling).

Voici, d’après lui, les facteurs clés à garder en tête lors d’un développement pour cette plateforme :

  • Le hardware est limité, en mémoire comme en CPU : Cependant la performance est cruciale. Il faut donc designer ses applications pour la vitesse et les tester sur de vrais appareils. L’émulateur fourni dans le kit de développement ne rend pas compte des performances réelles. Pensez donc à gérer votre mémoire: ici, pas de Garbage Collector. Et si par hasard le SDK ne vous fourni pas ce que vous voulez, vous pouvez toujours embarquer des librairies en C pur.
  • La résolution est différente : Là encore, un test sur un device réel ne saurait être remplacé par un test sur l’émulateur, des changements subtils peuvent impacter fortement l’effet obtenu, à cause de la taille et de la résolution de l’écran.
  • Le mode d’utilisation change : En développement web on suppose l’utilisateur assis avec clavier, souris, etc. Mais en mobile, il sera plutôt en déplacement, ou dans un canapé avec l’iPad. Ceci doit être pris en compte dans le design. L’interface multitouch, la taille des doigts, etc., tous ces paramètres doivent être exploités intelligemment.
  • Les barrières posées par Apple : Le iPhone Developer License Agreement est fluctuant et contraignant. Il existe une constante inquiétude de la censure quand on développe. La médaille de ce revers est que, si votre application passe la censure, les utilisateurs feront confiance à l’AppStore et n’auront aucune réticence à l’installer sur leur iPhone/iPad.
  • Chaque application est partie intégrante de l’appareil : D’après les retours d ‘Apple, les utilisateurs d’iPhones ne se servent que marginalement de la fonction de recherche. Ils trouvent une application qui leur récolte et présente les données d’un domaine particulier. Il faut donc penser une application comme partie intégrante du device physique et travailler au mieux son intégration.

Il enchaîne sur un rapide exposé des API disponibles, puis met en garde son auditoire sur les méfaits du hype. En effet, le positionnement marketing peut amener à se lancer dans un développement iPhone mais il faut faire les choses bien. Une application médiocre, même si elle offre une visibilité sur l’AppStore, sera mal notée par les utilisateurs et occasionnera donc une perte d’image.

Une présentation avec très peu de technique mais qui donne une bonne idée des contraintes à considérer pour ne pas perdre son temps lors d’un premier développement.

Harnessing the power of HTML5 Web Sockets to create scalable real-time applications

Peter Lubbers, de chez Kaazing Corporation, nous présente les avantages à tirer d’une communication full-duplex entre navigateurs et serveurs web. Il commence par rappeler les besoins de réactivité des pages web et les problèmes des solutions actuelles :

  • polling : Basé sur des requêtes AJAX périodiques pour récupérer les données. Le martelage du serveur par des requêtes AJAX en provenance de tous les clients connectés pose des problèmes de charge et d’occupation de la bande passante (chaque requête arrive avec ses headers HTTP). De plus cette solution ne fait que fournir du presque temps réel et scale très mal.
  • long polling : Technique des architectures Comet. Cela permet d’éviter de marteler le réseau pendant les périodes où il n’y a pas de données à fournir, mais dès que le flux est continu, la fréquence des polling augmente et revient au même que le polling classique.
  • streaming : fonctionne bien mais la conservation d’une connexion ouverte trop longtemps peut poser des problèmes avec les proxies et firewall sur la route.

Peter enchaîne sur une démonstration de Comet et de son occupation du réseau en capturant les trames réseau avec WireShark, et nous présente enfin la solution d’avenir : les WebSockets de HTML5.

Nous avions parlé il y a quelques temps des API Javascripts qui y sont liées. Un autre point mis en avant est qu’une fois établi, les communications passant par une WebSocket se passent de header HTTP (871 octet en moyenne) et sont remplacées par 2 octets qui encadrent chaque message, diminuant d’autant l’occupation de la bande passante.

Il détaille un peu l’aspect sécurité de la chose, les WebSockets sont également disponibles en version sécurisé, basé sur TLS (comme HTTPS) et s’établissent simplement par une poignée de main (Handshaking) sur HTTP. Actuellement les WebSockets du coté browser ne sont supportés que par Chrome 4.0+, et les nightly builds de WebKit. Opera et Firefox promettent de le supporter bientôt.

Il termine par la démonstration d’une application de Poker, avec WebSockets liés à un Kaazing Gateway et nous montre les trames réseau.

On peut regretter tout de même que Peter ne fasse aucun autre commentaire sur la partie serveur que d’évoquer le Kaazing WebSockets Gateway. A aucun moment la spécification Servlet 3.0, ni GlassFish, ni Jetty, ne sont évoqués.

GPars: Parallel programming concepts for the JVM in Groovy

Dans une session presque purement technique, Dierk König nous présente la librairie GPars, destinée à apporter la facilité à la gestion de la concurrence dans Groovy. Il commence par un rappel reprenant les concepts déjà exposés par Václav Pech dans sa session du matin, puis enchaîne sur une session de live coding pour démontrer la simplicité d’usage de la librairie.

Parmi les exemples codés devant nos yeux ébahis, on trouve notamment :

Il est pratiquement impossible de coucher un live-coding dans un article, mais la vidéo devrait sortir en même temps que les autres tournées dans la salle 5 de Jazoon. Vous les retrouverez dans la revue de presse, dès leur sortie.

A noter qu’un problème avec son IDE favori l’a forcé à utiliser uniquement la Groovy Console, exercice mené donc sans filet, et avec brio.

Cloud Computing with Scala and GridGain

Nikita Ivanov, de chez GridGain Technologies, vient nous exposer les travaux de sa société autour de Scala. Il commence par nous rappeler le contexte en revenant de façon synthétique sur certaines définitions :

  • Grid : 2 ordinateurs ou plus fonctionnant en parallèle sur des parties distinctes d’une tâche commune
  • Grid Computing : Grid de calcul et data Grid fonctionnant de concert
  • Cloud : Virtualisation de Data Center
  • Cloud Computing : Cloud et Grid Computing

GridGain Technologies a choisi d’adopter un langage plus simple pour exploiter leur architecture de Cloud Computing. Nikita nous explique que Groovy a été écarté à cause de ses performances, que JRuby a été écarté pour des problèmes d’intégrations et que Scala remplissait tous les critères de choix de GridGain :

  • Scalable
  • Post fonctionnel
  • Performances égales à Java
  • Statiquement typé
  • Pleinement compatible Java

Ils ont donc développé un DSL nommé ScalaR, qui permet de créer des programmes à lancer dans un Cloud GridGain en quelques lignes. S’en suit une nouvelle session de live coding, comparant l’approche traditionnelle de l’API GridGain, et l’utilisation de ScalaR. On devine assez bien quelle version a remporté la manche. DSL intéressant, dommage que le manque de temps a forcé Nikita à écourter un peu la démonstration.

How Java powers large online retail sites

Notre journée se conclut par une présentation de Robert Brazile, CTO chez ATG, qui rend hommage à l’apport des technologies Java au monde du commerce en ligne. Il revient sur la place grandissante de la vente sur internet dans l’ensemble des ventes sur le territoire américain, puis nous expose les problématiques générales des sociétés de vente :

  • haute disponibilité : les sites de vente en ligne doivent rester disponibles malgré les pics d’affluence. Les travaux sur le load balancing ont beaucoup apporté.
  • la vitesse avant tout : bien plus que le design graphique, c’est la performance d’une application qui est cruciale. Un peu trop d’attente, trop de clic à faire, et la vente est perdu.
  • la couche de présentation séparée : pour pouvoir déléguer les manipulations de présentation et de gestion des backend à des équipes séparées. Cela évite que les développeurs soient pris par des tâches « subalternes » alors qu’ils doivent réfléchir à des problèmes complexes comme la charge ou la récupération des données.
  • éviter de payer l’infrastructure nécessaire aux pics de charge pendant les creux : grâce aux avancées dans le Cloud computing, les vendeurs en ligne ont pu faire beaucoup d’économies.

Robert a multiplié les anecdotes sur les ratés de l’automatisation, comme ce moteur de recherche qui a mal réglé son moteur de suggestion :

search for : abortion => Did you mean adoption ?
(trad. : rechercher : avortement => Vous voulez dire adoption ?)

Son expérience encyclopédique du monde des systèmes d’informations pour les sites de vente en ligne lui a servi à illustrer à quel point le langage Java a permis la percée des techniques de vente en lignes modernes. Il prévoit d’ailleurs que cela continue dans les années à venir avec certains sujets qui animent déjà la communauté Java :

  • Virtualisation et Cloud Computing : pour toujours plus de scalabilité
  • Bases de données NoSQL : pour un meilleur accès aux données, chaque archi répondant à des besoins spécifiques
  • Scripting : PHP, Ruby, Groovy et autres, pour des modifications rapides sur les sites publics
  • Frameworks : Rails, Grails, Lift et autres, pour concevoir et déployer rapidement des sites vitrines à faible durée de vie
  • Parallélisme et concurence : Pour exploiter de façon efficace les architecture multi-core et le Cloud

Java est mature donc, mais certainement pas proche de la retraite.

Epilogue

Nous avons dû choisir entre les sessions Jazoon Rookie et notre avion. Vous devinez sûrement ce que nous avons décidé :). Dans l’ensemble, Jazoon est toujours une conférence très intéressante, les orateurs sont de très bon niveau et très accessibles pour discuter en dehors des présentations.

Un grand merci aux organisateurs et aux orateurs. Nous attendons avec impatience les vidéos.

Publié par

Publié par Aurélien Maury

Aurélien est passionné par les frameworks web haute productivité comme Grails, JRuby on Rails ou Play! framework. Il est également intéressé par tous les aspects de performance et d'optimisation (mais aussi par la phytothérapie, la PNL, la basse électrique, la philosophie et pleins d'autres sujets). Il est également formateur au sein de Xebia Training .

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.