Duchess France
A Duchess Community Blog for France

Le mardi 6 Juillet est le dernier Paris JUG avant la rentrée. Pour cette occasion, on compte sur la présence d’un speaker d’excellence : Adam Bien. Il va nous présenter deux architectures opposées – Lean Service Oriented Architecture (SOA) et Domain Driven Architecture – ainsi que la façon dont on les implémente sous la plateforme JEE 6 grâce aux EJB 3.

Histoire de vous mettre l’eau à la bouche, je vais vous présenter rapidement Adam Bien et les sujets qui seront traités plus en détail, argumentés, et accompagnés d’exemples pratiques et de retours d’expérience le mardi 6 juillet au Paris JUG.

Une conférence à laquelle assister absolument !!

Qui est Adam Bien ?

Adam Bien est un consultant indépendant, formateur Java, architecte du software et développeur qui  implémente des architectures Java à grande échelle au sein des entreprises allemandes.

Nommé Java Champion en Janvier 2007,  il est membre de NetBeans Dream Team, de Sun Advantage Partner, Glassfish System Integrator, du groupe d’experts Java Community Process (EJB 3.1, JPA 2.0, Java EE 6) et il est fortement impliqué dans les technologies Cloud, Grid et P2P. Actuellement, il travaille en parallèle comme architecte et développeur au sein de plusieurs projets d’architecture J2EE/Java EE 5/MDA et au sein des architectures EAI basés en composants pour Java EE et .Net.

Il est aussi connu pour ses nombreux articles et livres publiés dans le cadre Java/J2EE/J EE et l’architecture distribuée. Parmi ses livres, on peut trouver plusieurs ouvrages en allemand (“Enterprise Architekturen”, “Java EE 5 Architeckturen”, “Struts” etc. ) ainsi que son dernier livre publié en 2009 et écrit en anglais : “Real World Java EE patterns” où il explore les défis de Cloud Computing.

EJB3 légers et pouvoir des annotations

Depuis des années, les EJB ont toujours été identifiés comme une technologie trop lourde. Effectivement, jusqu’à la version EJB 2 cette réputation était justifiée. Mais depuis la version EJB 3 tout a changé et on peut affirmer à présent que les EJB sont très légers. Ils sont configurés par annotation (non par de tonnes de XML), intégrés avec JPA (Java Persistence API), scalables au sein des machines multicore et avec multiples CPU, et constituent une solution standard et portable pour les applications métiers d’entreprise.

“Convention over configuration”

Le principe du design pattern “Convention over configuration” est le suivant : Les applications se basent sur des conventions au lieu de se baser sur la configuration. Ainsi, elles chercheront à réduire le nombre de fichiers de configuration, fourniront une configuration par défaut (convention par règle de nommage) mais permettront aussi la substitution des valeurs par défaut via la configuration (à partir des fichiers ou une autre source de données).

La mise en place de ce pattern passe par l’utilisation des annotations. Les EJB 3 ont toujours besoin de la même quantité d’information pour fonctionner. Cette information étant la même dans 80% des cas, il suffit, par exemple, de placer l’annotation @Stateless sur une classe POJO (Plain Old Java Object) pour lui donner le comportement de base d’une entité de session.

Injection de dépendances

Il s’agit de retirer des objets la gestion des dépendances entre les objets et de la confier à un conteneur, le conteneur des EJBs dans ce cas.  Ainsi, pour utiliser une instance EJB, on se servira de l’annotation @EJB pour l’injecter, pour utiliser une ressource (JMS, Datasource) on utilisera l’annotation @Ressource etc.

ex : Voici un EJB qui “injecte” un autre EJB de service. Le conteneur des EJBs s’occupe de chercher l’instance du Service pour que le client puisse l’utiliser.

@Stateless
public class ClientBean implements Client {
     @EJB
     private Service service;

     public String sayHello() {
          return this.service.getMessage();
     }
}

La plateforme JEE 6 permet grâce aux EJBs d’implémenter deux approches d’architecture opposées :

• Lean Service Oriented Architecture (SOA) – Architecture légère Orientée au Service
• Domain Driven Architectue – Architecture pilotée par le Domaine

Approche 1 : Lean Service Oriented Architecture (SOA)

Dans le modèle d’architecture SOA, comme son nom l’indique, l’entité la plus importante est le Service. On peut considérer un service comme un contrat, un use case, même un story, qui exécute une ou plusieurs opérations (transactions). Le principe est de l’exposer au système d’information et d’encapsuler non seulement son implémentation mais aussi sa localisation.

Interfaces et packages

Les bases d’une implémentation avec Java/JEE sont les interfaces et les packages. La fonctionnalité d’un package est exposée via une interface (parfois par plusieurs). On définira d’abord les interfaces des services à exposer, pour ensuite créer les classes qui implémenteront leur logique métier.

Diviser les responsabilités – “divide and conquer”- facilite la réutilisabilité et améliore la maintenance du code. Ainsi, sans trop détailler :

• Une classe annotée @Stateless et @Remote servira de façade. Cet EJB fournira le contrôle d’accès aux services, ainsi que le comportement transactionnel; il implémentera l’interface à exposer.
• Une classe annotée @Stateless et @Local servira de service. Cet EJB implémentera le métier et ne sera accessible qu’à partir de la façade.

Les annotations des EJBs seront placées sur la classe d’implémentation et jamais sur l’interface; ainsi, les services exposés sont indépendants de l’API EJB et leur implémentation est complètement encapsulée.

Les objets du domaine

Si les façades implémentent la logique d’accès et les services la logique métier, il ne reste plus grand chose aux objets du domaine. Ils encapsulent un état mais n’ont  aucune logique métier. Les entités JPA sont des classes annotées @Entity qui contiennent des attributs, des accesseurs (getter/setter) et c’est tout. Ce pattern (même considéré un anti-pattern par les puristes de la POO) est connu sous le nom “Anemic Object Model” et colle parfaitement avec les besoins de SOA.

La majorité des applications d’entreprise J2EE/ J EE d’aujourd’hui sont proches de l’architecture décrite précédemment. Néanmoins, elle convient parfaitement jusqu’au moment où le comportement dépend du type des objets. L’implémentation des services utilise alors des instructions du type “instanceof” ou encore des blocs“if/else” et “case” pour s’y adapter. Ceci est la conséquence directe du  “Anemic Object Model” qui déplace le contrôle en dehors des entités au détriment des services et façades où se trouve la vrai logique métier.

Approche 2 : Domain Driven Architecture Design

L’architecture pilotée par le domaine est basée sur l’utilisation de vrais objets (true objects). Ces objets encapsulent leur état et fournissent également des  comportements, bien définis en fonction du type.

PDO

Les objets du domaine sont le socle de l’application. Ils gèrent leur état,  la persistance de leur état et implémentent la logique métier. Il arrive même dans certains cas que l’on n’ait pas besoin d’utiliser de service.

Les entités PDO (Persistent Domain Object) sont persistantes. Ainsi, chaque changement, au niveau de leur état ou de leurs relations, sera automatiquement synchronisé avec le moteur de persistance à la fin de la transaction. Ils seront exposés publiquement; cela oblige le concepteur à bien réfléchir à l’API qui sera fournie au client.

Gateways

Les PDO sont passifs et ne démarquent pas de transactions ; ils ont besoin d’un contexte d’exécution pour fonctionner.

Cela va nous poser un  problème à cause de la nature stateless des applications Java EE : après l’invocation d’une méthode transactionnelle, via un service ou un service façade, toutes les entités JPA – les PDO – sont détachées. Le client perd le contexte transactionnel; on est constamment obligé de transporter et de “merger” tout le contexte entre le client et le serveur avec les difficultés que cela implique.

Solution: Créer un “anti service façade” - un gateway. On ne cache plus les entités derrière une façade, on les expose  le plus possible aux couches supérieures telles que la couche Présentation et on permet à ces couches de les modifier directement . Cette stratégie, contradictoire avec les principes J2EE classiques sur la maintenance, semble dans certains cas plus pratique dans les projets du monde réel. Il s’agit tout simplement de se débarrasser des couches inutiles et d’exposer la couche domaine à la couche présentation. Chaque changement du domaine est directement visible depuis l’IHM.

Une gateway est implémentée par une classe annotée @Stateful et @Local – un EJB – qui manage aussi les transactions et contient l’EntityManager et le contexte persistent.

Conclusion

Ce qui est une bonne pratique chez l’un est un anti-pattern chez l’autre. Or, les deux approches opposées sont applicables, parfois complémentaires et nécessaires.

Java EE 6 et les EJBs permettent les deux types d’implémentations. Un point à  noter, l’approche SOA semble avoir une bonne affinité avec SOAP et les WebServices. Par contre, l’approche Domaine semble mieux s’accorder avec des architectures de type REST qui est focalisé sur une manipulation directe des ressources.

Des démos, du code et toutes les réponses à vos questions, directement adressées à Adam… 

dans le prochain Paris JUG !!

Inscrivez-vous !!

Les inscriptions ouvriront Jeudi 1er le matin. Soyez prêtes, ces temps-ci les place partent très vite.  Si vous voulez recevoir la notification de l’ouverture par e-mail jeudi matin pour pouvez vous abonner à la mailing list Annonces du JUG.

Groovy User Group - Les organisateurs

Cette fois ci c’est le Paris Groovy Grails User Group qui a tenu sa première réunion le 10 juin chez VMWare. Deux autres sponsors ont également participé à cette soirée, Doc4Web qui a fournit le buffet et Balsamiq.

Une quarantaine de personnes pour cette première session (le programme), avec les habitués, quelques nouvelles têtes par rapport aux user groups Java, et pas mal de filles (environ 10% ce qui est un bon score pour des conférences techniques).

Pour le lancement de ce groupe, une session de présentation : quelles seront les activités de ce groupe, qu’est ce que Groovy, les principaux concepts, pourquoi c’est cool, et un tour d’horizon des principaux projets qui gravitent autour de Groovy.

Dans les activités prévues les classiques des UG (présentations, débats, sorties restau) mais aussi une originalité : organiser des soirées de coding.

Vous pourrez suivre l’activité de ce groupe sur Meetup à l’adresse suivante http://www.meetup.com/Paris-Groovy-Grails/

Groovy

Guillaume Laforge nous a présenté les principales caractéristiques de Groovy, le langage qui nous simplifie la vie :

• Un langage dynamique
• Des Closures, des blocs de code réutilisables que l’on peut manipuler comme des variables
• Le typage optionnel
• Le support de l’expression langage ( ${mavariable} )
• les GString qui permettent d’étendre les chaînes (support de l’expression langage, chaînes sur plusieurs lignes, padding …)
• Les facilité de création d’initialisation des collections
  Une liste fruits = ['Pomme', 'Orange']
  ou une map contact = [prenom='Guillaume', nom='Laforme']
• La facilité de manipulation des documents XML (XmlParser, MarkupBuilder)
• La facilité de création  de requêtes JDBC, d’IHM Swing ou plus généralement l’utilisation de templates et de DSL via les MarkupBuilder
• Des opérateurs rigolos comme l’opérateur elvis ?: qui permet de simplifier l’écriture de l’opérateur ternaire en nom ?: 'anonyme' dans le cas où on veut juste vérifier que le nom existe ou l’opérateur ?. qui permet d’écrire un chemin de navigation dans des objets sans devoir vérifier la présence de valeur nulle à chaque étape
• La manipulation de fichiers ou de résultats de requêtes SQL aussi simple que manipuler une collection

Elvis operator

Pourquoi l’adopter ?

• Tourne dans la JVM, portable et en général déjà présente
• Intégration très complète avec Java (du code Java fonctionne dans Groovy même si ça n’est pas le but et les librairies Java sont utilisables
• Prise en main très rapide pour les développeurs Java
• Rapidité d’écriture du code

Pour avoir un peu codé en Groovy, c’est vrai que  la prise en main par un développeur Java est rapide, en particulier si on a l’habitude d’autres langages de scripting (Python dans mon cas) et de la programmation fonctionnelle.

C’est terriblement pratique pour écrire le code de test ou des scripts qui moulinent des fichiers et génèrent des rapports. Il y a bien sûr une contrepartie à cette productivité. Les manipulations de fichiers ne sont pas aussi instantanées que dans mes scripts Python et le débugging n’est pas toujours simple lorsque le typage optionnel ne produit pas le type qu’on suppose. Mais dans l’ensemble ça permet de réaliser très vite des outils dont on a besoin.

Groovy User Group - Les participants (si, si, il y a deux autres filles au fond)

L’écosystème

Groovy est utilisé dans un grand nombre d’outils de test ou de reporting. Ces activités ne sont pas critiques et la facilité d’usage de Groovy permet de mettre en pratique rapidement ses idées.

Il est également utilisé (via Grails en particulier) pour le développement d’IHM de ces outils.

Enfin un autre usage privilégié est l’utilisation de Groovy comme langage de commande, pour exprimer des règles métier ou des DSLs.

Même si Groovy peut utiliser les librairies Java, de nouvelles librairies plus dans l’esprit Groovy et plus intégrées sont également mises au point. Et pour finir, tous les outils pour faire du Groovy.

La gestion de dépendances :

• Grape (The Groovy Adaptable Packaging Engine or Groovy Advanced Packaging Engine) et la commande @grab

Des librairies complémentaires :

• Une librairie pour la manipulation de JSON lib http://json-lib.sourceforge.net/groovy.html
• Une librairie XML plus puissante XML Slurper http://groovy.codehaus.org/Reading+XML+using+Groovy’s+XmlSlurper
• HttpBuilder pour la manipulation de requêtes HTTP
• Groovy WS pour la manipulation de Web Services
• Gpars pour faciliter la programmation concurrente

Des frameworks applicatifs écrits en Groovy :

• Web : Grails
• GAE : Gaelyk
• Swing : Griffon

Des frameworks de test écrits en Groovy :

• Easyb un framework de BDD (Behavior Driven Development)
• Spock un framework Fit
• Gmock un framework de mock
• Soapui un framework de test fonctionnel

Des outils de build :

• Gant Ant en groovy
• Gradle un outil de build
• GMaven un plugin Maven
• CodeNarc analyse statique de code Groovy

La prochaine rencontre aura lieu le 20 Juillet :  http://www.meetup.com/Paris-Groovy-Grails/boards/view/viewthread?thread=9320461

Cet article est un retour d’expérience sur la mise en place d’une pagination dans un écran de recherche contenant un filtre composé de deux listes déroulantes. Hibernate fonctionne avec la majorité des SGBD. Toutefois, ceux-ci n’offrent pas tous les mêmes fonctionnalités. Le SQL natif généré par Hibernate sera différent selon les SGBD. Nous verrons en quoi cela peut poser problème.

Ce cas s’appuie sur une application utilisant Hibernate et Sybase ASE 12.5. L’écran à développer, en plus de la pagination, possède un filtre facultatif. La clause where étant dynamique, je décide d’utiliser les Criteria pour écrire ma requête.  Il y a dans le manuel Hibernate une section dédiée à la pagination. Elle vous conseille d’utiliser les méthodes setFirstResult et setMaxResults de l’interface Query en précisant qu’Hibernate sait comment traduire ceci en SQL natif adapté à votre SGBD.

J’implémente ma dao et je filtre le résultat renvoyé :

Criteria crit = session.createCriteria(Flux.class);
//ajout des restrictions – filtre utilisateur
List result = crit.setFirstResult(firstResult)
            .setMaxResults(nbRows).list();

J’écris mon test unitaire, je réalise quelques tests sur ma base de données de test, je « commit ». Voilà, c’est fini !

Quelque temps plus tard, le chef de projet souhaite faire des tests en pré-qualification sur un nombre de lignes conséquent (il est vrai que tester la pagination quand il n’y a qu’une seule page ce n’est pas très drôle). La pagination fonctionne sur les premières pages, mais impossible d’afficher la dernière page sans faire tomber l’application. Le message d’erreur suivant est très explicite :

<10 juin 2010 15 h 20 CEST> <Critical> <Health> <BEA-310003>
<Free memory in the server is 4 122 880 bytes. There is danger of OutOfMemoryError>
Exception in thread "[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.
Default (self-tuning)'" java.lang.OutOfMemoryError: Java heap space

...
The exception message is - Java heap space
java.lang.OutOfMemoryError: Java heap space

En regardant le code SQL généré par Hibernate, on remarque qu’il n’y a pas de filtre pour la pagination. Malheureusement, Sybase possède moins de fonctionnalités que d’autres SGBD et ne connaît pas les mots clef « LIMIT » ou « ROWID » et de ce fait, le setFirstResult et setMaxResults ne sont pas traduits en SQL natif. Hibernate est donc obligé de tout récupérer dans sa requête et de faire le filtre de pagination côté java. Il charge les objets en mémoire tant qu’il n’a pas les résultats souhaités pour la page demandée. Cela ne pose pas de problème pour les premières pages, mais lorsqu’on veut atteindre la dernière page, la consommation mémoire explose.

Figure 1 – Utilisation de la mémoire – schéma de JConsole

Ainsi, nous ne pouvons pas utiliser l’interface Query dans ce cas. Cette version de Sybase ne supporte pas non plus les sous requêtes ordonnées. La seule solution que nous avons trouvée est de faire la  requête en deux temps : d’abord sur les identifiants, puis récupérer les données  à partir de ceux-ci.

Cette solution peut s’implémenter de deux façons :

• Solution 1 : récupérer la liste des identifiants filtrées par Hibernate (même code qu’au début, mais en ne retournant que les identifiants) ;
• Solution 2 : obtenir la liste de tous les identifiants, puis la filtrer en utilisant la méthode subList de l’interface List.

Nous avons testé les deux solutions. En observant l’utilisation de la mémoire, la solution 2 semble plus performante.

Figure 2 – utilisation de la mémoire pour la solution 1

Figure 3 – utilisation de la mémoire pour la solution 2

Pour finir, on a une première requête écrite avec les Criteria qui permet de récupérer tous les identifiants en fonction des filtres de l’utilisateur. Puis, on crée une sous-liste pour ne garder que les id correspondant à la page demandée. On fait une dernière requête en HQL pour récupérer les objets.

Criteria crit = session.createCriteria(Flux.class);
//ajout des restrictions – filtre utilisateur

List lsId = crit.setProjection(
           Projections.property("id")).list() ;

List result = null;

if ( lsId != null &&  lsId.size()>0) {
	//si la liste d'id est vide, la requête hql plante
	Query q = getSessionFactory().getCurrentSession().getNamedQuery(
      		"getListFluxByIds").setParameterList(
	      "idList",
	      lsId.subList(firstResult,
	      lastResult));

	result = (List) q.list();
}

A retenir :

Hibernate est votre ami, mais il ne peut pas être plus fort que votre SGBD. Il est donc utile de vérifier le code SQL natif qu’il génère.

Concernant Syabse ASE 12.5, on espère que les versions futures supporteront les fonctions liées à la pagination.

Je remercie David, Ellène et Victor pour la relecture et les conseils sur WordPress.

Après une pause de 30 minutes, Octo fait une annonce pour parler de l’université du SI. C’est une conférence organisée par Octo sur Paris qui débute le 1er Juillet et dure 2 jours. 3 types de sessions sont proposés :

• des sessions destinées aux boss,
• des sessions destinées aux geeks,
• des sessions mixtes.

Ce n’était pas vraiment prévu mais ils décidèrent ensuite d’organiser un tirage au sort pour une place à la conférence. Ensuite, Holly Cummins tira au sort un nom pour gagner l’iPad que beaucoup convoite en ce moment. Après avoir félicité le gagnant (ou plus précisément le jalousé ), nous passons à la deuxième partie de la présentation.

OSGi et les entreprises

Holly commence par faire le point sur l’évolution de la programmation en faisant la correspondance avec l’évolution de l’homme.

Au commencement il y eut les bits, une série de 0 et de 1. Puis nous sommes passé aux fonctions et librairies ensuite aux objets et puis finalement OSGi. Ce dernier représente quand même une étrange évolution dans la programmation comme le montre l’étrange animal le représentant dans la dernière étape de l’évolution.

L’utilisation d’OSGi est une question de besoin. Pour un “Hello Word !” les objets sont amplement suffisants mais lorsqu’on a une usine à gaz ?
Dans une application complexe, les dépendances et l’utilisation des librairies peuvent devenir difficile à gérer. Il nous faut des applications modulaires.

La modularité dans une plateforme d’entreprise

Le gros problèmes des jars c’est qu’ils ne sont pas versionnés, il n’y a pas de scope ce sont des entités non traçables et non gérables. Autre souci, le classpath : avec nos applications de plus en plus complexes, où les jars dépendent eux mêmes de jars, on peut très vite se retrouver avec des surprises au runtime. En effet, selon les JVM la politique de chargement de classes n’est pas la même et on peut avoir très vite en fonction des environnements des ClassNotFoundException.

OSGi

Ci dessus une représentation du modèle en couche d’OSGi. Il est composé de Bundles, le Bundle est un composant OSGi qui est en fait un jar contenant des méta-données définies dans le Manifest.mf. Chaque bundle possède son propre classpath ce qui élimine les problèmes de conflits de versions que l’on peut avoir. Voici un exemple de Manifest.mf :

Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: HelloService Plug-in
 Bundle-SymbolicName: com.javaworld.sample.HelloService
 Bundle-Version: 1.0.0
 Bundle-Vendor: JAVAWORLD
 Bundle-Localization: plugin
 Export-Package: com.javaworld.sample.service
 Import-Package: org.osgi.framework;version="1.3.0"

Les services OSGi sont là pour fournir une liaison dynamique entre les bundles que l’on peut à tout moment modifier à chaud.

Et pour les applications web ?

OSGi Enterprise Expert Group (EEG) a défini une spécification pour fournir une solution aux entreprises et répondre aux besoins de ceux qui utilisent Java EE pour leurs applications.

Avantages

L’approche est vraiment différente. Et au lieu de déployer une nouvelle version de notre application et ensuite de redémarrer notre serveur d’application, on peut se limiter au déploiement de bundles (modules) à chaud.

Apache Aries

Apache Aries est le projet open source sur lequel travaille Holly Cummins. Apache Aries est un outil permettant d’exposer les modules OSGi.

Historique

Aries est un projet créé en Septembre 2009. Toujours en incubation, la version 0.1 est maintenant disponible à l’utilisation et a été intégré à Websphere.

Voici ce que contient le projet Aries :

• un conteneur Blueprint,
• JPA integration,
• JTA integration,
• JMX,
• JNDI integration,
• Application assembly
• …

Petite démonstration …

Voici l’heure de la démo qu’appréhende beaucoup Holly car le mois dernier elle ne s’était pas très bien passée.

Dans Eclipse, elle utilise Apache Aries pour montrer le fonctionnement d’OSGi :

Elle commence par créer un service, et charger dans le serveur OSGi le jar, il sera reconnu en tant que Bundle. Une fois chargé et lorsque l’on va créer l’application, on pourra lui définir l’utilisation de ce bundle. Elle injecte ensuite la classe Service créée dans une servlet. Pour ce faire elle utilise le JNDI pour récupérer le bon bundle et donc notre classe.

L’injection de dépendances

Les modules peuvent faciliter l’évolution d’une application, il semble à ce moment là simple de vouloir remplacer son service par une nouvelle version sans redémarrer son serveur. Ces bundles peuvent être visibles et gérables dans le serveur d’application qu’elle a choisi d’utiliser : Websphere.

Ce qu’elle voit dans un futur proche c’est que toutes les applications Java d’entreprises vont pouvoir déployer des bundles au lieu des applications entières.

La troisième mi temps

La présentation est finie, quelques questions suivirent. Tout le monde remballe ses affaires et direction Le Vavin pour la 3ème mi temps !
Pour un autre retour sur la soirée, vous pouvez également voir la wave d’Olivier Croisier sur son blog The Coder’s breakfast. D’ailleurs sa wave m’a beaucoup aidé pour rédiger ce résumé, un grand merci à lui.

Alors on se retrouve au mois prochain hein ?

Les textes et les photos sont Claude Falguière et d’Ellène Dijoux.

Cette soirée fut drôlement riche en évènement et en surprise … Ne dévoilons pas tout et commençons par la première partie de soirée : l’AvantJUG.

L’AvantJUG

Pas mal de Duchess sont présentes, certaines accompagnées de leur collègue, et quelques nouvelles qui assistent pour la première fois à l’AvantJUG. Nicolas Martignole auteur de l’incontournable blog Le Touilleur Express a assisté à l’AvantJUG en tant qu’observateur pour voir comment se passait notre première partie de soirée.

Dans les conversations, on pouvait entendre qu’il y a un iPad à gagner ce soir ! En plus des bières promis par les organisateurs du ParisJUG pour tout ce qui arrivaient les cheveux bleus, cela promet d’être une belle soirée . D’ailleurs en parlant de cheveux bleus, certaines d’entre nous ont profité des bombes à laques bleus amenées par Laure pour réaliser une petite séance de coiffure improvisée.

Déjà 19h ? On se prépare et en route pour l’ISEP !

Avant de commencer la soirée …

Antonio prend la parole pour faire le point sur les JUG et Oracle. Après quelques mois de silence, Oracle s’est enfin prononcé sur leurs intentions par rapport au JUG. Ils ont décidé de mettre en place 3 catégories de JUG :

• les gros JUG avec plus de 1000 membres et un cadre juridique pour qui Oracle sortira le tapis rouge avec soutien en force,
• les JUG de taille moyenne qu’Oracle soutiendra … moralement on va dire,
• et les JUG virtuels qui auront droit à une petite tape dans le dos avec un “C’est sympa ce que vous faîtes”.

Le petit souci du ParisJUG, c’est que nous sommes 200 à nous réunir chaque mois et un millier sur la mailing list mais juridiquement il est composé de trois membres ! Alors comment Oracle les considèrera ?

La présentation débute maintenant …

L’optimisation des performances : pas si effrayant que ça !

Holly Cummins commence tout d’abord par nous remercier pour l’accueil en français s’il vous plaît !

Elle poursuit ensuite par une présentation de son parcours au travers de sa couleur de cheveux.

• En 2001, les cheveux roses, elle arrive chez IBM pour travailler sur Websphere.
• En 2004, pour se rapprocher des couleurs d’IBM, elle choisit le bleu et au même moment elle commence à travailler sur les performances de la JVM.
• Actuellement, avec les cheveux tout simplement noir, elle contribue au projet open source Apache Aries.

Les performances ce n’est pas si terrible que ça ! Holly souhaite dédramatiser la situation.

Une application répondant mal, ce n’est pas seulement problématique mais aussi coûteux :

• en électricité : cela consomme beaucoup surtout quand on a des data centers comme Google,
• les employés utilisant ces applications sont moins productifs,
• une perte de business à cause de pages qui ne répondent pas assez vite voire même pas du tout.

La loi de Moore prédit que l’on aura des processeurs de plus en plus rapides mais les SI peuvent ils se permettre de changer de matériels régulièrement pour améliorer leur performance ? Le problème c’est surtout qu’on a atteint le maximum de la scalabilité verticale. On ne peut pas faire tourner les processeurs plus vite pour une question de dissipation de chaleur. Par ailleurs, à l’heure actuelle c’est l’accès aux données en mémoire qui limite les vitesses de processeurs. On fait de la scalabilité horizontale c’est à dire qu’on augmente le nombre de core. Mais cette technique impose de réaliser des tâches en parallèle et pose donc plus de problème de synchronisation.

A son arrivée chez IBM, connaissant peu de choses sur les performances, selon ses termes, elle a cherché quelques livres pour l’aider. Et malheureusement dans la monstrueuse bibliothèque d’IBM seuls deux livres traitaient de la performance !

Méthodologie

Les performances sont limitées par les ressources. Il faut donc trouver le goulet d’étranglement et régler le problème. Un exercice qui n’est pas toujours facile à appliquer en général. Voici quelques ressources à considérer : le CPU, les accès mémoire, l’espace mémoire, les accès disques …
Il faut comprendre comment la JVM fonctionne afin de trouver le problème. Il est indispensable également de se faire aider d’outils qui fourniront des mesures et permettront de détecter ce goulet d’étranglement.

Les outils de performance d’IBM

IBM fournit un certain nombre d’outils permettant de mesurer et détecter plus facilement les goulets d’étranglement. Ils sont disponibles gratuitement sur le site IBM Assistant. Mais attention ces outils fonctionnent majoritairement sur les JVM d’IBM.

Détecter les problèmes liés à la mémoire

La mémoire est une ressource critique car elle ne peut pas être dimensionnée à l’infini. Elle est d’abord limitée par la mémoire physiquement disponible. Ensuite, il est souvent nécessaire de faire un compromis entre la quantité de mémoire et le temps que prendront les phases de Garbage Collection.
Pour identifier les problèmes de mémoire, deux types d’outils sont possibles : les traces de l’activité du GC et l’inspection du contenu de la heap (un heap dump).
Activer l’option -verbose:gc sur la JVM permet de tracer les executions du Garbage Collector et d’identifier des fréquences ou des volumes anormaux. L’outil GC and Memory Visualizer permet d’exploiter ces traces et de les représenter visuellement. Cette technique permet de voir quand la mémoire est sur-utilisé et de constater une fuite mémoire mais pas de savoir par quel type d’objets.
Pour cela il est nécessaire de réaliser un heap dump.
Pour visualiser les fuites mémoire, voici deux outils qu’elle nous conseille :

• Health Center est un outil d’IBM permettant de réaliser le diagnostic et le monitoring des applications Java. Il permet de visualiser les classes utilisées, l’utilisation de la mémoire, les entrées/sorties …

• Memory Analyzer (MAT)  pour visualiser les appels aux objets et la mémoire prise par ces objets.

Dans la démo, Holly nous montre un exemple d’utilisation de ces outils. Il y a un trop grand nombre de String, ainsi qu’un très grand nombre d’entrées de Map. Le souci dans cette application est que des chaînes sont générées dynamiquement pour chaque utilisation d’un label de produit.

La mémoire native

On appelle mémoire native la mémoire utilisée par le core de la JVM pour gérer les processus natifs de la JVM (gestion des threads, gestion de la mémoire, gestion de la pile d’appel). Cette mémoire est distincte de la Heap qui est la zone dans laquelle les objets manipulés par les applications sont créés. Il arrive que les fuites se produisent dans la mémoire native parce qu’elles sont causées par des processus natifs de la JVM. Or cette mémoire n’est pas traitée par les outils dont on vient de parler. Il faut utiliser les outils de l’OS perfmon sous Windows et ps sous Linux pour surveiller la mémoire totale du process JVM pour identifier une dérive.

Détecter les problèmes liés au CPU

Tout d’abord, les problèmes de CPU sont souvent en réalité des problèmes de mémoire. Le GC cause beaucoup d’opérations sans entrées sorties et donc génère souvent de fortes consommations CPU. Les problèmes liés au CPU sont en général du code invoqué plus que nécessaire. Pour détecter ces problèmes, deux méthodes existent :

• méthode de tracing : pour savoir dans quels méthodes passent notre application et trouver la méthode nous posant problème,
• méthode de profiling : pour cela, il nous faut un outil de profiling comme Health Center par exemple.

Paradoxalement, une utilisation très basse de la CPU peut indiquer également un problème parce que dans ce cas ce sont des attentes qui dégradent les temps de réponse. Le système qui attend des entrées/sorties ne consomme pas de CPU.

Détecter les problèmes liés aux entrées/sorties

Il existe deux causes de problèmes d’entrées/sorties : les accès disque et les appels réseau.
Les accès disques peuvent ralentir le service si le disque n’arrive pas à traiter les demandes suffisamment vite. Cela peut arriver pour une application fortement consommatrice d’écriture (via les logs par exemple). Mais la gestion des swaps mémoire peut également causer une sur-utilisation des disques pour des process s’allouant de grandes quantités de mémoire.
L’autre source de dégradation par entrées/sorties est causée par les requêtes aux SGBD ou avec des services en backend.
Le problème n’est pas évident à détecter. Il faut utiliser les outils du système en conjonction avec les outils de profiling pour enquêter et trouver le problème.

Synchronization : la concurrence et la performance

Holly avoue que les problèmes d’accès concurrents ne sont pas faciles à résoudre. La nécessité de conserver la cohérence entre les actions des différents threads impose d’utiliser une forme de verrou (les synchronized) qui limitent les performances sous forte concurrence. Il faut donc les réduire au maximum.

L’évolution des processeurs ces derniers temps se fait par scalabilité horizontale et implique que l’on ne peut plus gagner en performance simplement en ayant des processeurs qui vont plus vite. Pour utiliser au mieux les multi-cores, il faut savoir paralléliser les tâches, ce qui nécessite de trouver un bon compromis entre synchronisation des données et augmentation du débit.

Fin de la première partie, nous passons au buffet.

Le buffet

Mais avant une petite photo groupée autour de Holly Cummins de tout ce qui ont eu le courage de venir les cheveux colorés. Le buffet fut sponsorisé par Octo. Pour cette soirée des représentants du BreizhJUG, NormandyJUG et le BruJUG sont présents.

Les textes et les photos sont Claude Falguière et d’Ellène Dijoux.

La fatigue, je vous dis ...

Florence Chabanois et moi même Claude Falguière étions là aussi pour le deuxième jour. La fatigue s’accumule mais on ne va pas rater plein de bonnes choses pour autant.

Un plus par rapport à la veille, on maîtrise maintenant le trajet et il n’a pas été nécessaire de se lever aussi tôt.

Le deuxième jour la keynote était consacrée à Esther Derby qui nous a parlé a parlé de confiance dans l’équipe et des moyens de l’acquérir et la conserver dans “Self-help for Self-organizing Teams”.

Un exemple simple d’action que l’on peut avoir dans un projet en n’acceptant pas certains comportements impolis à montré qu’on est tous acteurs des relations dans l’équipe.

Jeu de Rôle Scrum par Yannick Ameur

Une présentation toujours très animée et pédagogique.

Jeu de rôle SCRUM : le Product Backlog

6 participants constituent une équipe projet pour construire un château.

Les participants ont un rôle dans le projet décrit sur une carte et comme dans tout vrai projet certains joueront un rôle non contributif, voire négatif.

Et bien sûr le client ne sait pas ce qu’il veut non plus. Une fois le château construit, il veut finalement autre chose.

Le but de l’expérience est de montrer moment l’équipe arrive à répondre à la problématique malgré tous ces écueils en mode cascade et en mode Agile.

Les photos de cette session sont en fil rouge dans l’article.

Jeu de rôle SCRUM : construction du château

XP/TDD avec des technologies “legacy” par Pascal Ognibene

Claude Falguière

Pascal Ognibene qui travaille depuis longtemps dans le monde des télécoms, nous a fait un retour d’expérience sur la mise en place de TDD dans des environnements C++ ou sur des logiciels spécifiques.

C’est une bataille difficile qui doit se préparer avec soin et il faut savoir que cela coûtera cher car la mise en place demande encore beaucoup de scripting spécifique.

La difficulté vient du retard dans le portage des outils du monde Java dans le monde du C++, d’obstacles à surmonter liés à la technologie (par exemple, les éditions de liens en C++ qui peuvent ralentir considérable le rythme) , mais surtout la dette technique particulière de l’application qui fait que ses composants ne sont souvent pas testables isolément.

Jeu de rôle SCRUM : c'est l'heure de l'inauguration sous les confettis

Consensus workshop, par Thi Lan Huong LE

Florence Chabanois

L’objectif de la session était de trouver ensemble “Comment améliorer les relations entre producteurs et utilisateurs” (ou quelque chose comme ça).

La méthode a vraiment le mérite de générer beaucoup d’idées (des très bonnes) mais le consensus est difficilement atteignable quand les participants sont nombreux, en dépit des efforts de l’animatrice.

Le principe était déjà de partir de propositions individuelles, d’élargir à un groupe plus restreints de 3 personnes, puis au 30-40 participants.

• Chacun cherche 10 propositions sur sa feuille
• Fait une sélection dessus (en les triant je crois)
• Dans un groupe de 3 personnes, on se partage les idées et on doit en dégager 7.
• Chaque idée est à écrire sur une feuille A4, bien visiblement
• On ramasse 3 idées préférées de tous les groupes sur le mur (un tissu magique permettait de retenir les feuilles, sans colle, et ça tenait bien !!!)
• Le groupe entier essaie des les trier par ressemblance sur des colonnes séparées. C’est une phase très très longue et le consensus me parait vraiment peu atteignable ici.
• Un ramassage est effectué avec les 4 idées restantes de chaque groupe, si elles ne sont pas encore apparu dans le tableau.
• Le groupe essaie de les rattacher aux colonnes existantes, sinon d’en créer d’autres.
• Le groupe tente ensuite de donner des noms à chaque colonne. Par exemple : “favoriser la communication”.
• A la fin, il y a autant d’axes que de colonnes pour résoudre le problème. Les papiers en dessous sont des moyens de le faire.
• Dans le plan d’actions : il vaut mieux commencer par les solutions les plus impactantes et/ou les plus simples à mettre en oeuvre.

J’ai apprécié le souci de consensus, même si je n’ai pas le sentiment qu’il ait été atteint. Par contre, c’était réellement excellent comme exercice de brainstorming.

Jeu de rôle SCRUM : le plus beau château ... celui que le client veut

Fin de cette seconde journée

On repart bien fatiguées mais avec plein d’idées en tête.

Merci aux organisateurs d’Agile France 2010 pour leur travail

• Sébastien Douche
• Yannick Ameur
• Agata Sobik
• Pascal Pratmarty
• Thibault Bouchet
• Jonathan Scher

Nous laissons le mot de la fin au canard qui est venu assister à XP/TDD avec des technologies “legacy”.

Coin !

A suivre, en 2011 !

Les textes sont de Florence Chabanois et Claude Falguière. Les photos sont de Claude Falguière.

Florence Chabanois et moi même Claude Falguière étions à Agile France 2010 au début du mois. Avec pas mal de retard un retour à quatre mains sur Agile France 2010 et les sessions qui nous ont intéressées.

Le programme aussi a un peu souffert

Agile France 2010 “conférence agile sur les méthodes agiles” se déroulait cette année au Chalet de la Port Jaune, un très beau site près du château de Vincennes.  Plus de 300 personnes se sont déplacées, un record pour cette conférence.

Suite au changement de nom de XPDays à Agile France l’audience a un peu changé et mêle  les XP guys de longue date et des curieux venus découvrir le monde Agile et SCRUM. Cela explique probablement aussi la présence de bien plus de filles que l’année dernière.

L’ambiance était décontractée, les échanges nombreux favorisés par le buffet présent en permanence, la qualité des repas, les pauses suffisamment longues pour aller faire un tour au buffet, et des activités d’animation pendant ces pauses.

Beaucoup de contenu car les sessions se sont déroulées sur 6 salles (voir 7 par moment). De nombreux sujets sur Scrum, TDD, la gestion de configuration logicielle et toutes les techniques de l’agilité. Quelques sujets un peu plus techniques et pas mal de présentations sur la communication pour s’ouvrir l’esprit. A commencer les deux keynotes.

Coder Academy : David Gageot et Eric Lefèvre présentent les règles du jeu

Si vous voulez voir le programme vous le lirez mieux là.

La coder Academy

Agile France 2010 a introduit une compétition  en 3 manches entre développeurs lors de pauses déjeuner et avant le diner : la Coder Academy.

Le but était principalement de montrer des applications réelles de TDD sous la forme de Coder Dojo. Si le terme Coder Dojo ne vous dis rien vous pouvez vous référer à la présentation d’Emmanuel Gaillot qui était là aussi en tant que membre du jury.

Les sujets donnés au hasard étaient des Kata en 7mn soit TDD à partir de rien, soit Refactoring en TDD d’un code de son choix.

A l’exception de Christophe Thibaut et Jonathan Perret qui ont présenté un kata en Haskell, tout le monde a fait du Java, avec des variantes comme Play! ou Groovy.

Coder Academy : L'équipe Christophe Thibaut et Jonathan Perret, les plus haskell (et les plus forts aussi )

La finale s’est déroulée en figure imposée : implémenter  la liste des n premiers nombres premiers en TDD à partir de rien en Ruby en randori (chaque équipe passe à tour de rôle pour 5mn sur le même code).

Le véritable enjeu était le temps. 7mn c’est très, très court quand on est de l’autre côté du clavier, et probablement très, très long pour les gens qui nous voient peiner . Mais certains kata on été très réussis.

Si après ça vous êtes tentés vous pouvez rejoindre plusieurs des participants de cette Coder Academy au coding dojo qui est organisé tous les lundi soir  à Paris. Il y en a aussi deux autres, mais on verra ça une autre fois.

Les photos de la Coder Academy  illustrent ce post en fil rouge.

Coder Academy : L'équipe, Eric Mignot et Fabien Bezagu, les plus speeds

La keynote de Bruno Sbille

Claude Falguière et Florence Chabanois

La keynote de Bruno Sbille “PNL et Agile: les yeux, les oreilles et les sensations” nous a présenté rapidement comment utiliser les méthodes de la PNL pour améliorer notre communication dans un projet Agile.

La PNL ou Programmation Neuro Linguistique est un ensemble de méthodes déduites de l’observation de gens efficaces.

Le premier point traité par Bruno Sbille est qu’il faut savoir interagir avec les auditifs, les visuels et les tactiles/kinesthésiques sur des canaux différents sinon ils ne comprennent tout simplement pas.

Comment les reconnaître ? Les types de verbes utilisés sont un critère. Les auditifs utiliseront plutôt des descriptions verbales assez longues, les visuels des dessins, les kinesthésiques des interactions physiques et des ambiances. Les différents systèmes de représentation sont traités dans la PNL sous le terme VAKOG si vous voulez aller plus loin.

Coder Academy : L'équipe Nicolas Martignole et Olivier Catteau, les plus beaux chapeaux

La seconde partie de la keynote de Bruno Sbille a commencé par des scénettes de la vie quotidienne (qui n’a pas oublié de reboucher le dentifrice un jour). Dès qu’il y a plusieurs personnes dans une équipe elles peuvent créer un triangle dramatique et se livrer à des jeux psychologiques plus ou moins conscients. Le triangle comporte 3 rôles : le persécuteur, la victime, le sauveur, et le jeu peut commencer à 2 joueurs en configuration victime/persécuteur ou victime/sauveur.

Chaque type de rôle trouve un intérêt à le jouer, y compris la victime, qui peut d’ailleurs être la source du triangle en attirant aussi bien les persécuteurs en puissance que les sauveurs.

Ces jeux sont nuisibles pour l’humeur de l’équipe, car ils créent des conflits ou des dépendances excessives. Paradoxalement, le sauveur aussi est problématique car il peut en arriver à prendre en charge le travail de tout le monde.

Vu qu’il y a probablement quelques sauveurs par ici, je vous délivre le message : Quand sauver ?

• est ce qu’on me le demande ?
• est ce que j’ai le temps ?
• est ce que j’en ai les compétences ?
• est qu’il y aura un échange ?

et si jamais le sauveur prend la décision de sauver il faut  rendre la “victime” active en lui demandant de prendre en charge 50% du travail.

Keynote intéressante mêlant habillement le visuel, l’auditif et le kinesthésique et beaucoup de matière à réflexion sur nos agissements.

Coder Academy : L'équipe Claude Falguiere et Fabrice Bouteiller, les plus mixtes

Au delà de l’équipe, l’entreprise agile, par François Bachmann

Florence Chabanois

Les points importants : auto-organisation, auto-organisation, auto-organisation et pour que ce soit possible, il faut fournir un conteneur (C), un cadre dans lequel l’équipe puisse s’exprimer. Une équipe à qui on dicte la conduite en disant “va à droite, à gauche, tout droit” fonctionnera forcément moins bien qu’une autonome. La dissonnance (D) et les erreurs doit également être acceptée pour que la créativité soit possible. Les échanges (E) doivent abonder : plus de communication et moins de docs. C’est le CDE.

François Bachmann aborde également le problème de la gestion des ressources humaines : comment “récompenser” l’agilité, et sur quels critères? Par analogie, comment évaluer les performances d’un footballeur ? Si l’on mesure les mètres parcourus, d’une part le but final de gagner des matchs n’est pas forcément atteint, d’autre pas le footballeur risque de ne faire que cela, sans s’intéresser au reste. J’ai aussi envie de dire que le système de récompense peut être pervers dans le sens s’il faut systématiquement “payer” les pots cassés quand l’on se trompe. On risque de se renvoyer la patate chaude pendant que personne ne prend de responsabilités.

La résistance à l’agilité peut avoir plusieurs causes :

• la perte de contrôle liée à la promotion de l’auto-organisation, même si le contrôle n’était qu’une illusion
• l’équipe se considère déjà agile et il n’y a pas de problèmes, tout va bien. En fait les problèmes sont dissimulés au lieu d’être montrés au grand jour.
• certaines personnes aiment suivre des règles
• la motivation baisse
• “c’était mieux avant” (pour l’équipe, pas pour le client…)
• l’expert ne trouve plus sa place

Coder Academy : Pas toujours facile d'être juge, des discussions intenses et pendant ce temps les candidats attendent le verdict

Quelles directions à suivre :

A faire

• Former les équipiers, sur de la technique mais pas seulement. Promouvoir des façons de pensées et des approches différentes.
• Avoir un véritable projet pilole qui apporte de la valeur pour le client

A éviter

• Changer les noms et garder les mêmes rôles. Le “chef de projet” est maintenant un “scrum master” et il fait exactement la même chose qu’auparavant…
• Conduire un changement “big bang” : “A partir d’aujourd’hui, tout le monde ici est agile !”. L’adaptation doit se faire graduellement.

Et pour finir, cela sent mauvais si :

• La décision de passer à l’agilité est un ordre du management
• On veut des résultats immédiats. Il faut le temps qu’il faut, comme pour apprendre le vélo.
• Il y a un acharnement sur les termes agiles : “backlog”, “scrum”.. ces mots font peur ! Il vaut mieux se concentrer sur les idées plutôt que les étiquettes.
• Scrum est vu comme une solution magique. Scrum donne des pistes, un cadre mais il faudra forcément plus pour guérir.
• Les bonnes pratiques sont aveuglément suivies. Il faut aussi comprendre le pourquoi, voir si elles s’intègrent dans notre organisation et les faire évoluer après. François évoque à ce sujet un livre sur les 40 entreprises qui marchent, dont la plupart avaient coulés dix années après. Chaque organisation est unique et il n’y a pas de solution universelle.

Le Lean Office : améliorer la performance administrative, par Michel Baldellon

Florence Chabanois

Michel Baldellon montre par les chiffres qu’un “petit” problème peut, à force d’être répété, devenir insidieusement le coeur du travail d’une entreprise. L’exemple ressemblait à cela : considérant qu’il faut une unité de temps pour faire un rapport, et que l’imprimante en abime 1 sur 10 (on se dit que c’est tolérable).

Coder Academy : Les juges enthousiastes après le kata de Christophe Thibaut et Jonathan Perret

• 10 rapports faux => 10 unités passés à les faire
• 90 rapports bons => 90 unités passés à les faire

Pour détecter que le rapport est en erreur et le corriger, il faut 10 fois plus de temps.

Sur les 100 initiaux, voici les couts :

• 10 rapports faux : 110 (10 + 100)
• 90 rapports bons : 90

On passe au final plus de temps sur la partie boguée qui semblait minime que sur le coeur du métier.

Trois points sont soulignés !

• Management visuel. Utiliser des couleurs pour donner du sens. L’exemple cité est celui d’un bureau désordonné comparé à une étagere avec classeurs post-ités
• Identification du gaspillage. L’exemple évoqué est celui du bac rouge dans une usine, qui recueille les produits défectueux. La ligne de production est continue (“flow continu”), simplement les problèmes sont mis en valeurs et isolés pour pouvoir être traités plus tard.
• Méthode de résolution de problème. Une fois qu’une cause est identifiée, elle est affichée. A chaque fois qu’on la rencontre, on trace un trait. On voit ainsi facilement que la cause 1 est survenue 30 fois alors que la cause 2 est apparue une seule fois. On peut ainsi objectivement traiter la plus importante. Il rappelle aussi que traiter un problème tout de suite permet de ne pas avoir de documentation à écrire et à maintenir et nous épargne de la resynchronisation.

Voici d’autres points soulevés, en vrac :

• quand on veut obtenir quelque chose, plutot que simplement le demander, montrer en quoi il y gagne (ex : on ne peut pas vous payer car il manque le numéro de facture).
• certains services aiment le gaspillage, cela rend la “vie moins monotone”, cela rassure car on sait le traiter. La cause profonde d’un problème n’est pas intéressant, on connait le contournement. La démarche “Qualité totale” n’est pas universelle, et dans certains services moins que d’autres.
• notion de file unique. Avoir des files spécialisées favorise les situations où certaines sont pleines et d’autres vides. Plutôt qu’avoir des personnes dédiées, il vaut mieux des gens polyvalents. La présence de guichets simples permet aussi d’accéler le flux (exemple des caisses pour panier de moins de 10 articles dans les supermarchés).

Un article sur le Lean Office est en ligne sur le site de Michel Baldellon.

Benoit Gantaume : Introduction au processus de pensée visuelle / Sortez vos crayons

Claude Falguière

Cette série de sessions s’appuie sur la méthode Visual Thinking que Dan Roam a exposé dans son livre Back of the Napkin (site web très dynamique et la présentation des principes de la méthode dans le livre blanc est très percutante)

Coder Academy : La finale, les juges commentent le randori; avis consultatif, c'est le public qui jugera

La présentation a duré 4h (1h le matin et 3h l’après midi). D’abord quelques explications des concepts puis un atelier pour expérimenter ces concepts.

Le visual thinking est une technique d’utilisation du dessin pour résoudre des problèmes et exposer une idée.

L’idée a germé quand Dan Roam a gribouillé un dessin sur le dos d’un nappe pour expliquer une idée. Puis il a complété ses recherches avec des éléments provenant d’études sur le fonctionnement du cerveau.

Le but n’est pas de faire des jolis dessins mais des dessins qui donnent du sens et avec des moyens très simple de type papier/crayon.

La technique exposée permet d’organiser la démarche qui permet de collecter les informations, les organiser, compléter ces informations en imaginant les éléments qui manquent puis présenter le résultat obtenu.

Elle est guidée par deux axes :

• le type de questions que l’on peut poser : qui/quoi, quand, où, combien, comment, pourquoi ou les 6W (toutes ces question comportent un W en anglais)
• la façon d’aborder ces questions résumé par SQV1D qui force notre imagination a entrer en jeu pour examiner le problème sous plusieurs angles avec des oppositions.

SCRUM dans l'exercice "Compare". Avec quoi à votre avis ?

L’auteur propose en ensuite des modes de représentation adaptés à chaque type de question selon l’angle sous lequel on veut les traiter.

Le speaker Benoît Gantaume a présenté la méthode et des exemples d’utilisation. Il a animé plusieurs ateliers portant sur les différentes techniques. Le plus long en fin d’après midi sur SCRUM en images a donné quelques jolies oeuvres qui ont été mises en ligne là par Benoît Gantaume.

Je reproduit le dernier qui vient de mon équipe car il a mené à un délire collectif sur le client envoyant ses specs par dessus les creneaux de la tour qui restera un souvenir mémorable de cette session d’Agile France.

Une présentation très intéressante mais qui aurait gagné a être un peu plus rapide.

Fin de la première journée

Coder Academy : Le public, c'est pour eux qu'on était là

Journée bien remplie. Pour celles et ceux qui sont restés au repas c’est l’heure d’aller diner et d’avoir des discussions passionnantes avec les autres participants et les speakers.

Les textes sont de Florence Chabanois et Claude Falguière. Les photos sont d’Eric Lefèvre et Claude Falguière.

L’Avant JUG est de retour pour la soirée Holly Cummins du Paris JUG. Pour cette pré-soirée, nous vous proposons de nous retrouver comme toujours depuis quelques mois déjà autour d’un verre au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30. Où nous pourrons parler par exemple du thème de la soirée Optimisationde Performance, OSGi ou encore celle qui nous fait l’honneur d’animer cette soirée : Holly Cummins.

Vous souhaitez venir à cette soirée et participer à l’Avant JUG ?
1 – Dés l’ouverture des inscriptions, foncez vous inscrire à la soirée qui se trouve sur ce lien : http://parisjug.org/xwiki/bin/view/Meeting/20100608 – faîtes le vite car les places partent très vite !
2 – Une fois inscrite, prévenez nous de votre participation à l’AvantJUG en envoyant un mail à l’adresse suivante : duchessfr(at)gmail(dot)com

Vous êtes accompagnée par des collègues (H/F) ?
Dîtes leur de venir, nous serions heureuses de les accueillir.

Attention !
Suite au nombre de participants plus importants que d’habitude le mois précédent nous allons réserver des tables au Vavin alors pensez à nous prévenir au plus tard Mardi matin de votre venue et si vous viendriez accompagner ou non. Cela nous permettra de passer un bon moment en toute sérénité.

Ce mois-ci performances et OSGi sont au menu de la soirée du ParisJUG. Avec Holly Cummins notre speaker du mois, venez découvrir les deux thèmes qu’elle abordera ce soir :

Optimisation de performances

Mémoire, threads ? Tous ces concepts paraissent très mystérieux. En fait ce sont des comportements très simples dès lors qu’ils sont expliqués et aussi quand on peut les visualiser. Les outils fournis avec la Java 5 ainsi que des outils plus spécifiques permettent de visualiser les différentes zones de la mémoire, les données liées à chaque exécution du GC, le code en cours d’exécution pour chaque thread. Ces outils aident à comprendre comment une application sollicite les différentes zones de la mémoire. Certains OutOfMemory sont réfractaires aux modifications de -Xms -Xmx les paramètres qui dimensionnent la heap. C’est simplement parce que la heap ne concerne que les objets crées par l’application. D’autres zones mémoire sont utilisées pour stocker les classes, la pile d’appel. Même la heap est composée de plusieurs zones dans une JVM générationnelle.
Beaucoup de consommation CPU, l’application pause tout le temps car la JMV passe beaucoup de temps dans des GC ? L’analyse détaillée des données de GC permet de comprendre pourquoi des GC sont fréquents, quelle est la durée de vie des objets impliqués et d’avoir de premières pistes pour identifier  une consommation mémoire excessive ou s’adapter à un usage particulier.Ou alors, les réponses sont parfois lentes sans raison apparente. Ces outils aident à identifier si un thread est en train d’en bloquer un autre parce qu’ils nécessitent tous les deux l’accès à une variable protégé par un synchronized. Même si la JVM nous décharge de la gestion des allocations/dé-allocations mémoire et du multi-threading, il est utile de comprendre comment ces mécanismes marchent pour les utiliser de manière efficace en Java.

OSGi

On parle de la spécification OSGi mais savez vous de quoi il s’agit ? OSGi est une spécification ayant pour but de définir des applications modulaires, portables et dynamiques. Pour faire simple cela permet de réaliser des installations de modules à chaud sans redémarrage de la JVM. Le plus bel exemple que l’on a sans doute tous sous les yeux est Eclipse et son système de plugins par exemple qui respecte la spécification OSGi. Elle existe donc depuis un moment déjà mais revient au goût du jour pour tenter de répondre à nos problèmes de modularité sur nos applications web. Une présentation d’OSGi a été réalisée au ParisJUG en Octobre 2008 par Cyrille Leclerc et Nicolas Griso pour présenter ce que OSGi pouvait nous apporter. Depuis plus d’un an s’est écoulé, Holly Cummins va nous présenter au travers du projet open source sur lequel elle travaille Apache Aries, les enjeux d’un tel outil. Injection de dépendances, transaction et persistance : venez découvrir comment l’on peut répondre à ces problématiques avec OSGi.

Les textes sont d’Ellène Dijoux et Claude Falguière.