You are browsing the archive for 2010 July.

EJB 3.x – Lightweight killer apps but nothing more than Adam in action

3:16 pm in Les Conférences by Katia Aresti

Cet article présente la deuxième partie de la soirée Adam Bien au ParisJUG.

Après une présentation théorique des architectures et des EJBs puis un buffet animé par les discussions sur la présentation de première partie, Adam nous a montré la puissance de la plateforme JEE 6 et les EJB 3.x en réalisant du code en direct. Dans notre article précédent, on vous a parlé des approches d’architecture opposées SOA et DDD; dans celui-ci on traite en détail de la partie théorique des EJBs accompagnée des exemples d’Adam.

Allons-y avec la théorie et la pratique des EJBs !

Adam Bien - Photo: José Paumard

Adam Bien - Photo: José Paumard

Comme on l’ a déjà évoqué précédemment, les EJBs d’aujourd’hui ne sont plus considérés comme une technologie lourde. Il sont simples, concis, et l’ancien mode de configuration par des tonnes de XML a été supplanté par les annotations en laissant au développeur la possibilité de changer la configuration par défaut avec le XML (le pattern “Convention over Configuration”).

Le conteneur des EJBs est maintenant très léger aussi, il pèse à peine 1Mo. Dans le profil Web on a  la possibilité de déployer le container avec notre application dans un war. Cela permet que tous les objets aient le même classloader, c’est qui est très pratique pour éviter des exceptions de type “class not found” dues au fait que les classes n”ont pas été chargées dans le même ClassLoader. JNDI est indépendant du serveur d’application, et on peut même faire du monitoring JMX aux EJBs.

Adam nous a dit que ses exemples sont “crappy” (En dehors de cette affirmation je pense qu’il est très modeste) et que le fait de tout mettre dans le même classloader n’est pas très élégant, mais très pratique.

EJB 3.x : légers, simples, testables

Le plus simple des EJBs :

@Stateless
public class ChampionService {
   public String sayWorldCupWinner(){}
}

Les EJBs d’aujourd’hui n’ont aucune contrainte d’héritage, on les crée à partir de simples POJOs. On revient ici à la question “interface” évoquée dans l’article précédent.  Lors du design, pensez à l’utilité réelle des interfaces.  Avec l’injection des dépendances, on peut utiliser l’implémentation d’un EJB sans passer forcément par une interface, et cet EJB sera testable avec la même simplicité.

Exemple de test avec le framework Mockito :

public class SimpleChampionServiceTest {
   @Test
   public void sayThisYearsWinner() {
      ChampionService service = mock (ChampionService.class);
      when(service.sayWorldCupWinner()).thenReturn("España");
      ServiceFacade facade = new ServiceFacade();
      facade.service = service;
      assertFalse(facade.isWinnerPaysBas());
   }
}
N.B. : Cet exemple n'a pas été développé par Adam Bien mais par Paul le poulpe,
qui réside en Allemagne  lui aussi. Merci Paul.

Singletons

JEE6 permet l’utilisation des EJBs à mode singletons. Pour cela , on annotera une classe comme @Singleton. L’annotation @Startup permet d’indiquer au conteneur de démarrer le singleton et sa méthode @PostConstruct au démarrage de l’application.

@Singleton
@Startup
public class StartMeUp {
     @PostConstruct
     public void initialization() {
     }
}

CDI – Context Dependency Injection

CDI – Injection des dépendances et contexte – comble les lacunes de l’injection de dépendances JEE5 . Entre autres limitations, avec JEE5 on n’avait pas la possibilité d’injecter un EJB dans un framework présentation non standard ou d’injecter une classe utilitaire qui n’était pas implémentée sous la forme d’EJB.

Création du HelloWorld

A l’aide des wizards de NetBeans, Adam a créé un projet de base pour ses exemples. NetBeans est livré avec un serveur Glassfish intégré et il semble plutôt bien pour réaliser des exercices d’apprentissage comme celui-ci. Il a utilisé la base de données Derby qui marche très bien aussi pour ce type d’utilisation.

Il a créé le package java.fr.jug.dechusse en l’honneur des JDuchess :D et l’EJB ParisJUGService.

@Staless
public class ParisJugService {
     public void helloParis(){
          System.out.println("Hello Paris");
     }
}

Un peu d’injection de dépendances pour appeler la méthode avec JSF 2 depuis le contrôleur :

@WebServlet(name="HelloController", urlPatterns={"/HelloController"})
public class HelloController extends HttpServlet {

    @EJB
    ParisJugService jugService;

    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();
        jugService.helloParis();
        try {
            out.println("<html>");
            out.println("<head>");
            out.println("<title>Servlet HelloController</title>");
            out.println("</head>");
            out.println("<body>");
            out.println("<h1>Servlet HelloController at " + jugService.helloParis() + "</h1>");
            out.println("</body>");
            out.println("</html>");
        } finally {
            out.close();
        }
    }

On a besoin d’un fichier nommé beans.xml dans le répertoire web WEB-INF. Cela indique que le projet est un module qui utilise les beans CDI. Le contenu du fichier est vide, mais on se servira de ce fichier pour ajouter la configuration XML qu’on ne souhaitera pas réaliser uniquement avec les annotations.

Après un tonnerre d’applaudissements de toute la salle pour ce HelloWorld :) on est passé aux sujets intéressants sur JEE6 qu’Adam avait traité lors de la partie théorique !

Interceptors

JEE6 permet le développement “lightweight” AOP (Programmation Orienté Aspects). AOP cherche à séparer ce qui est du code métier et de ce qui n’en est pas. On développe le code non fonctionnel – un aspect – et on le réutilise :  le code fonctionnel est ‘décoré’ avec la fonctionnalité de l’aspect en exécution.

Les aspects du JEE s’appellent “Interceptors”. Ils sont assez limités car ils ne sont optimisés que pour travailler avec les EJBs. Or, ils répondent aux besoins courants de la vaste majorité des applications réelles.

Dans l’exemple suivant, on configure un interceptor à partir des annotations ; on pourrait le faire aussi en XML. Chaque méthode de configuration a cependant ses avantages et ses inconvénients

  • Les annotations sont plus intrusives, mais elles permettent d’avoir le code plus documenté (on voit explicitement l’aspect) et rendent plus facile la factorisation et la maintenance. 
  • Le XML est moins intrusif et plus puissant avec des options de configuration supplémentaires, en contrepartie, il est plus difficile à maintenir, et il a quelque chose de “magique” (le code n’a aucun référence, et à terme ceci pourrait causer des soucis.

La règle générale est ici la même : pensez au vrai besoin pour trouver le meilleur compromis.

Voici l’interceptor crée par Adam :

public class CrossCutter {

    @AroundInvoke
    public Object cutMe(InvocationContext context) throws Exception{
        System.out.println("--- interceptor" + context.getMethod());
        return context.proceed();
    }

}

Voici comment utiliser l’interceptor. Il sera exécuté par toutes les méthodes de la classe :

@Stateless
@Interceptors(CrossCutter.class)
public class ParisJugService {

    public void helloParis(){
        System.out.println("Hello Paris ! ");
    }
}

Le résultat de l’appel à la méthode “helloParis” donnera la sortie suivante dans la console :

--- interceptor hello
Hello Paris !

Processus Asynchrone

JEE 6 permet facilement l’exécution de tâches en mode asynchrone. Dans l’exemple suivant développé par Adam, un EJB appelé Messenger contient une méthode annotée “Asyncronous” qui lance un message 2000 millisecondes après son invocation. La méthode répond avec un objet du type Future du JDK 6.

@Stateless
public class Messenger {

        public String message(){
            return "hello paris" + System.currentTimeMillis();
        }

        @Asynchronous
        public Future audit(String message){
            try {
               Thread.sleep(2000);
               System.out.println(" Audit: " + message);
            } catch (InterruptedException ex) {
               Logger.getLogger(Messenger.class.getName()).log(Level.SEVERE, null, ex);
            }
            return new AsyncResult("Done!");
        }
}

Dans l’EJB ParisJUGService, on injecte l’EJB Messenger pour l’utiliser.

@Stateless
[...]
public class ParisJugService {

   @EJB
   Messenger messenger;

   public void helloParis(){
        System.out.println("Hello Paris");
        messenger.audit("something " + sc.getCallerPrincipal());
   }
}

Si on appelle la méthode helloParis N fois à la suite très rapidement, le message “Hello Paris” s’affichera dans la console à chaque appel, et le message d’audit s’affichera toutes les 2000 millisecondes. Vous constaterez qu’effectivement le code s’exécute en mode asynchrone. Sans le mode asynchrone, on n’aura pas de retour de la méthode ‘helloParis’ tant que l’appel à la méthode ‘audit’ n’est pas terminé.

Persistance de données

Adam nous a aussi montré un exemple de persistance des données avec JPA. D’abord il a créé une entité persistante à l’aide de l’annotation @Entity. Il a placé les annotations @Id et @GeneratedValue pour définir la clé primaire et la génération automatique des clés. Les propriétés name et description font aussi partie des propriétés persistantes. Ceci est la configuration la plus simple d’une entité JPA.

@Entity
public class SessionEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String name;
    private String description;

    public SessionEntity() {
    }

    public SessionEntity(String name) {
        this.name = name;
    }
}

Dans l’EJB ParisJUGService, il a injecté avec l’annotation @PersistentContext l’EntityManager. L’appel à la méthode “persist” a effectivement écrit l’objet dans la base de données Derby.

@Stateless
[...]
public class ParisJugService {
    @PersistenceContext
    EntityManager em;

    public void helloParis(){
        System.out.println("Hello Paris");
        em.persist(new SessionEntity("hopefuly works"));
    }
   [...]
}

Configuration XML : il nous faut le fichier “persistence.xml” dans le classpath. Le fichier est très simple.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
                  http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="ParisJugMgrPU" transaction-type="JTA">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <jta-data-source>jdbc/sample</jta-data-source>
    <properties>
      <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
    </properties>
  </persistence-unit>
</persistence>

Événements

Avec JEE6 nous avons la possibilité de créer assez facilement des événements. Ainsi, depuis la classe ParisJugService, on injecte un objet “Event” et on lance un événement :

@Stateless
[...]
public class ParisJugService {

   @Inject
   Event<String> event;

   public void helloParis(){
        System.out.println("Hello Paris");
        event.fire("hello Paris invoked!");
   }
}

Une méthode d’un EJB est capable d’écouter (observer) cet événement :

@Stateless
public class EventReceiver {

    public void onHelloParis(@Observes String message){
        System.out.println("----------- " + message);
    }
}

REST

Pour terminer (on aurait pu rester toute la nuit), Adam nous a montré comment faire un peu de REST avec JAX-RS. D’abord, on ajoute l’annotation @Path à l’EJB ParisJUGService, puis les annotations @GET et @Produces à la méthode helloParis.

@Path("session")
@Stateless
public class ParisJugService {
    [...]

     @GET
     @Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
     public Session helloParis(){
          [...]
          return new Session(messenger.message() + " " + tl.hello() )
     }
}

L’annotation @Produces définit les formats que le client pourra utiliser pour recevoir l’objet Session : JSON, XML, etc.

L’appel à la méthode on la fait via HTTP/GET http://url/session

Conclusions

Adam nous a vraiment donné l’envie d’utiliser la plateforme JEE6. La possibilité de déployer juste un war, les interceptors, les singletons, “la disparition” des interfaces …  En bref et en revenant au titre de la conférence : grâce à la nature LIGHTWEIGHT de la plateforme, on peut réaliser des applications de grande échelle mais tout aussi bien des applications de petite taille.
Merci Adam pour tes conférences, tes conseils, tes publications et pour être venu à Paris !

Article rédigé par Katia Aresti, relecture et corrections par Claude Falguière.

DDD vs SOA – Lightweight killer apps with nothing but vanilla Java EE 6

3:15 pm in Les Conférences by Katia Aresti

Adam Bien est venu présenter sa vision de l’architecture Java EE lors de la session de Juillet du Paris JUG. Ce premier article présente la première partie de la soirée, plutôt dédiée aux concepts et à la théorie.

Adam Bien - Photo: Claude Falguière

Adam Bien - Photo: Claude Falguière

Les applications développées sous la plateforme JEE 6 sont maintenant très légères. On est loin de l’ancienne affirmation “les EJBs sont très lourds” ; celle-ci fait désormais partie du passé. Adam Bien a démontré la puissance de la plateforme et il nous a donné envie de la réapprendre, surtout avec la deuxième partie de la conférence qui a été entièrement pratique comme il nous l’avait promis. Le niveau du contenu théorique a été assez avancé. Nous vous conseillons la lecture, ou relecture rapide, de l’article précédentAdam Bien / JEE6 / Architecture – où vous est présenté Adam et dans lequel on vous plonge dans le contexte; ensuite vous pourrez repasser à cette partie plus détaillée qui s’appuie sur les concepts déjà traités.

Commençons par la théorie des architectures !

Lightweight Killer Applications

Grâce aux design patterns comme “Convention over Configuration”, l’injection de dépendances et les annotations, l’architecture des applications JEE6 est considérée LIGHTWEIGHT ! Que signifie “lightweight” ? Lightweight indique que l’architecture est rapide, simple, petite, légère, “facile”, lean (maigre) et qu’elle facilite le développement itératif et incrémental des applications d’entreprise.

Notez que le mot facile se trouve entre guillemets : Attention ! On peut mettre en péril la réussite des projets si on  sous-estime les difficultés et challenges lors du design et de l’implémentation sous JEE6. Comme on l’avait déjà évoqué dans notre article précèdent, afin de répondre aux besoins réels des applications d’entreprise, on nous propose deux approches d’architecture opposées :

  • Architecture pilotée par le Service (SOA – Service Oriented Architecture ≈ SOAP)
  • Architecture pilotée par le Domaine (DDD – Domain Driven Design ≈ REST)

Adam utilise l’acronyme SOA afin de faciliter la compréhension, mais il a aussi souhaité faire la distinction en utilisant les termes “Design Piloté par le Service” car le concept SOA a un sens encore plus large. Concept apparu après l’EAI (“Enterprise Application Integration”), le SOA essaie de répondre aux besoins d’intégration et d’architecture au sens global. Avec le SOA on regarde le système d’information d’une entreprise comme un groupe de services au lieu de un groupe d’applications comme avec son précurseur EAI. Il existe aussi une nouvelle approche, ROA (Ressource Oriented Architecture), qui nous parle d’un vision ressource.  Mais au delà des concepts, il faut du travail pour la réalisation des applications !

Les deux types architectures décrits par Adam – DDD et SOA – sont des designs que l’on peut choisir pour développer les applications, et les deux s’appuient sur le pattern ECB comme l’on va voir ci-après.  Le pattern ECB existe depuis longtemps et il est indépendant de la plateforme JEE6 (ce n’est pas un pré-requis).

ECB – Entity Control Boundary Pattern

Similaire au pattern MCV (Model View Contrôler), il n’est pas consacré qu’à la couche présentation. Il est composé de trois éléments : Entity, Control et Boundary

.

Entity Control Boundary pattern

‘Entity’ : Élément persistent et passif (il a besoin d’un contexte d’exécution pour fonctionner) qui contient non seulement les données persistantes mais également une partie de la logique métier.

‘Control’ : Élément orchestrateur qui implémente un scénario donné. Il orchestre les entités pour récréer un scénario fonctionnel particulier, mais la logique métier propre à chaque type d’entité reste encapsulée dans l’entité.

‘Boundary’ : Élément qui se trouve en périphérie du système ou sous-système et s’occupe de la communication. Certains Boundarys s’occupent de l’entrée au système depuis l’extérieur (front-end) ; les autres fournissent la sortie (back-end).

Sur ce point, se pose une question importante : Avez-vous compté le nombre de couches ? Il y en a deux. La couche “Boundary”, et la couche “Business” qui contient les éléments de contrôle et les entités.

Où est la couche DAO ? A-t-elle disparu ?

Oui, la couche DAO a disparu pour les opérations CRUD, mais elle sera encore là. Pourquoi ? La réalité est qu’on aura besoin des DAO dans la plupart des applications afin de respecter le principe DRY (Don’t Repeat Yourself) et la séparation des responsabilités. Une application classique réalise les mêmes opérations constamment. Sans un DAO dédié, les queries répétées seront arrosées par toute la couche business et cette duplication du code réduira considérablement la maintenance.

Pour bien expliquer ce point : il s’agit simplement de ne  plus jamais créer les DAO par défaut et uniquement parce que ce design pattern du catalogue J2EE le dit. Le pattern DAO n’est plus considéré la meilleure pratique à mettre en place. Aujourd’hui on va plutôt travailler en refactoring : Identifier le code dupliqué dans la couche business pour après le factoriser dans un DAO. Sans duplication de code,  mieux vaut déléguer directement à l’EntityManager depuis la couche business. Une couche DAO sans un vrai besoin augmentera l’effort de maintenance (plus de code, plus de tests) sans apporter une réelle valeur ajoutée.

Grâce aux generics, à partir du JDK 5 nous pouvons utiliser une couche DAO générale et très puissante qui fournira une API transverse aux applications. Ainsi, pour vous illustrer cela avec un peu de code :

@Stateless
@Local(CrudService.class)
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public class CrudServiceBean implements CrudService {

    @PersistenceContext
    EntityManager em;

    public  T create(T t) {
        this.em.persist(t);
        this.em.flush();
        this.em.refresh(t);
        return t;
    }

    @SuppressWarnings("unchecked")
    public  T find(ClLibraryass type,Object id) {
       return (T) this.em.find(type, id);
    }

    public void delete(Object t) {
       Object ref = this.em.getReference(t.getClass(), t);
       this.em.remove(ref);
    }

    public  T update(T t) {
        return (T)this.em.merge(t);
    }

    public List findWithNamedQuery(String namedQueryName){
        return this.em.createNamedQuery(namedQueryName).getResultList();
    }

   [...] 

}

Dans ce code on voit un Service DAO qui est implémenté par un EJB @Local et @Stateless. On injecte le contexte persistent (@PersistentContext) et EntityManager. On utilise les génériques <T> pour factoriser le code qui est commun à n’importe quelle entité. CrudService est l’interface qui sera exposé au client.

L’utilisation des interfaces

Comme on verra dans notre article suivant, l’utilisation des interfaces avec les EJBs n’est plus obligatoire. Dans ce point de la conférence, un débat a commencé : Est-il une bonne pratique le développement Interface + Implémentation ? Réaliser systématiquement une implémentation interface + classe ajoutera des fichiers à maintenir, et rendra l’application moins légère et l’API plus complexe. L’idée d’une interface est d’exposer une API et cacher l’implémentation. Par conséquent, si une classe ne changera pas d’implémentation, l’utilisation des interfaces n’apportera aucune valeur. Si l’API ne sera jamais exposé au client, non plus. Sur ce point, lors de la partie questions/réponses, deux bonnes pratiques ont été évoquées :

  • d’une part de différencier l’API externe (exposée au client) de l’API qui restera interne,
  • d’autre part d’identifier les objets avec le même comportement et une implémentation différente.

Aussi l’usage de designs patterns comme “Strategy” imposent l’utilisation des interfaces. Ensuite, avec ECB en tête, Adam est passé à l’implémentation de deux approches opposées : l’architecture pilotée par le domaine et l’architecture pilotée par le Service.

DDD vs SOA : Domaine ou Service

Comme vous pouvez constater dans l’image, les deux approches basent leur architecture sur le pattern ECB. SOa vs DDD

Afin de ne pas répéter notre article précèdent, et d’expliquer facilement le diagramme, voici un tableau récapitulatif.

Piloté par le Domaine vs Piloté par le service

DDD (Domain Driven Design) SOA (Service Driven Design)
Principal Domaine (Entity) Service (Control)
Programmation Cherche l’orientation objet pure Approche procédural
ECB – Entity PDO – Persistent Domain Objet. Contient du logique métier. Les entités ont leur état encapsulé et un comportement bien précis (true objects) Anemic Object Model – Structure de données sans comportement qui expose son état à partir des modificateurs (get/set). Ne contient aucun logique métier
ECB – Control Ne contient quasiment pas de logique métier. Très léger, parfois inexistant. Implémente toute le logique métier.
ECB – Boundary : Gateway – Expose et manage les entités (PDO). Nature Stateful (EJB @Stateful) Façade – Cache les entités derrière les services. Nature Stateless (EJB @Stateless)
Nombre de couches : 2 couches, pas besoin de DTO (Data Transfert Object) plus de 2 couches. besoin de DTO (Data Transfert Object)
La couche DAO : utilise la stratégie décrite précédemment utilise la stratégie décrite précédemment
S’intègre bien avec : REST SOAP

La vaste majorité des application J2EE / JEE existantes ont été développées avec l’approche procédural d’orientation au service. Avec les EJBs 2.x, penser à l’approche DDD n’était pas seulement une aberration, mais était quasiment impossible due à la complexité.

Conclusions

Les deux architectures opposées sont des meilleures pratiques dans des contextes particuliers. Ne soyons pas sectaires et restons ouverts aux deux approches. Dans la pratique, la plupart des projets du monde réel auront besoin d’une architecture mixte.

Adam Bien - Photo: José Paumard

Adam Bien - Photo: José Paumard

Adam a voulu nous transmettre un message aussi important que l’effet de connaître les frameworks du marché et les design patterns.

« Pensez toujours au vrai besoin, au contexte et à la valeur ajoutée »

Une architecture en 5 couches dans la pratique n’apportera aucune valeur si notre application reste monolithique.  Grâce aux nouveautés de JEE 5 et 6, on peut réaliser des applications beaucoup plus légères qui répondront au vrai besoin. Rappelons-nous qu’on n’applique pas les designs patterns pour le plaisir, mais pour répondre au besoin et pour obtenir une valeur ajoutée.

« Rester petit mais penser grand »

Lorsqu’on est confronté à la réalisation d’une architecture, il est très important de bien identifier les cas d’évolutions probables auxquels l’application sera sujette. Dans ce contexte, on ne doit cependant pas réaliser le design d’une architecture en assurant toutes les possibilités d’évolution pour anticiper tous les besoins possibles, auquel cas on risque de rester éternellement dans la phase « design » sans en réaliser le développement. En anticipant seulement les besoins les plus probables on pense grand, tout en restant petit. Une second article est dédié aux démonstrations de code de la deuxième partie de soirée.

Pratique – EJB 3.x et Adam en action

Article rédigé par Katia Aresti, relecture et corrections par Claude Falguière

Présentation Duchess France au Paris JUG Soirée Adam Bien

10:30 pm in Duchess Agit, Les Conférences by Claude Falguière

Cet article est corédigé par Claude Falguière et Ellène Dijoux

Dernière session avant une pause du JUG pour les vacances d’été, cette soirée était dédiée à Adam Bien, architecte, Java Champion, impliqué dans tout un tas de communautés de développement et vrai rockstar ! Katia vous prépare un article très complet sur ce qui a été présenté et codé.

En attendant, un retour sur un Avant JUG exceptionnel et la présentation Duchess France en introduction du JUG pour fêter nos 4 mois d’activité.

L’Avant JUG

En grande discussion sur l'USI à l'Avant JUG - Photo: David Chau  (@davidchau)

En grande discussion sur l'USI à l'Avant JUG - Photo: David Chau (@davidchau)

Ce mois ci, plus d’hommes que de femmes pour l’Avant JUG. Beaucoup d’entre nous ont ramené leurs collègues pour leur présenter les JDuchess France. Et surtout leur faire comprendre que l’Avant JUG n’est pas réservé aux femmes.

Après avoir parlé rapidement de foot (eh oui il y avait un match ce soir là), Eric Siber qui a assisté à l’Université du SI la semaine précédente nous fait un rapide topo de ses deux journées.

Il fait chaud et les boissons fraîches que l’on nous apporte sont vraiment les bienvenues.

Une petite présentation sur l’actualité des JDuchess est prévue ce soir, Laure s’occupe du petit groupe pendant que le reste de la crew est réunie à l’ISEP pour préparer leur présentation.

La présentation Duchess France

Présentation commencée de manière un peu tendue pour moi car c’était la première fois que j’utilisais le logiciel de capture vidéo et pour tout arranger à chaque fois que je passais sur le vidéo projecteur Open Office plantait. Les aléas du direct. Une fois constaté l’évidence, il ne restait plus qu’à faire la présentation en PDF.

De gauche à droit : Audrey Neveu, Claude Falguière, Katia Aresti, Ellène Dijoux - Photo: José Paumard

De gauche à droit : Audrey Neveu, Claude Falguière, Katia Aresti, Ellène Dijoux - Photo: José Paumard

Duchess France  ?

Pour commencer, sondage rapide Qui connait Duchess France ?”. La moitié de la salle lève la main, en particulier les assidus des premiers rangs, qui nous ont croisées lors de diverses conférences depuis le mois de février.

Un rapide passage sur JDuchess dans le monde. JDuchess est un réseau social féminin international et centré sur la plate-forme Java. Ce réseau est présent pour le moment dans 3 pays : Les Pays-Bas dont il est originaire, le Brésil et la France. Les trois pays ont des communautés d’une trentaine de personnes.

Les objectifs sont avant tout de rendre les compétences techniques des femmes visibles et de faciliter leur intégration dans les réseaux sociaux et les communautés techniques mixtes.

Où en est on après 3 mois ?

Pour commencer, quelques mathématiques.

L’équipe qui anime Duchess France jusque là composée de 4 personnes Ellène Dijoux, Claude Falguière, Mathilde Lemée et Laure Némée s’est agrandie de 2 personnes. Audrey Neveu et Katia Aresti nous ont rejoint. Audrey est développeur chez SFEIR, Katia est développeur expérimenté chez Sopra Group. Toutes les deux sont très motivées et ont des tas de projets en tête dans le cadre de Duchess France.

4 + 2, on est donc maintenant 6 pour l’animation de Duchess France.

Encore des nombres sur la planche suivante ! (promis après on arrête). Du chemin depuis l’annonce faite en lors du JUG Soirée Emmanuel Bernard en Mars (d’ailleurs, vous aurez noté qu’on ne fait des présentations que lorsqu’il y a des rock stars, allez savoir pourquoi).

Avant tout un grand grand merci à tous nos followers et membres qui nous font connaître dans leur entourage, retweetent, citent nos posts. Les plus nombreux sont bien évidemment les 127 followers Twitter de @duchessfr. Les groupes comportent moins de monde et c’est normal puisque ce sont les personnes les plus motivées par nos actions.

Duchess France en quelques chiffres est aussi sur le site dans la section Information

Duchess France en quelques chiffres. Cette page est aussi sur le site dans la section Information

  • Le Google Group duchessfr, le canal principal de communication entre nous. Il compte 27 personnes dont 3 hommes. Il est ouvert à toute personne intéressée par notre activité et qui veut participer ou échanger.
  • Le groupe crée sur JDuchess.org permet pour celles et ceux qui souhaitent s’y inscrire de poster sur le blog Duchess France et d’être en contact avec les groupes JDuchess à l’étranger.
  • Le groupe LinkedIn est là pour les contacts avec les autres réseaux professionnels

6 ça ne sera pas de trop pour les actions en place et prévues à la rentrée.

Les actions réalisées

Plusieurs réalisations depuis 3 mois.

La toute première action, les Avant JUG, a pris son rythme de croisière. Les Avant JUG se tiennent avant chaque JUG de 18h30 à 19h15 au Vavin. Les Avant JUG permettent de discuter de la soirée à venir, de ce qui se passe dans les communautés, d’actions à venir, d’idées, de projets pour refaire le monde.

Ellène Dijoux - Photo: José Paumard

Ellène Dijoux - Photo: José Paumard

Ils ont permis au départ aux Duchess de faire connaissance entre elles, mais ils ne sont pas réservés aux membres de Duchess, ni aux femmes. Il y a toujours eu quelques hommes et on souhaite qu’il y ait le plus possible de diversité. A ce propos, nous avons aussi rappelé que les places qui sont réservées pour les participants de l’Avant JUG le sont parce qu’ils ont fait l’effort d’arriver tôt et ça serait injuste qu’ils ne trouvent que des places au fond.

Les différents supports de communication ont été mis en place. En particulier, on a maintenant un blog http://jduchess.org/duchess-france/. C’est un relai pour nos actions et il diffuse des informations sur les conférences, en particulier les pré-articles au moment des inscriptions au JUG, et aussi des articles techniques des membres qui n’ont pas de blog personnel. Les autres sont présentés sur la page d’accueil sous forme de Planet.

On s’y perdait un peu avec 2 ou 3 conférences par semaine à Paris, alors nous avons mis en place le calendrier partagé Conférences qui recense les conférences intéressantes pour les développeurs Java en France. Ce calendrier peut être ajouté dans votre Google Agenda ou consulté en Web depuis le blog. Le truc vraiment sympa (enfin surtout pour nous parce que c’est lourd à maintenir ;-) ) c’est que vous pouvez aussi l’alimenter en envoyant une invitation au calendrier Conférences (Tout est expliqué là).

Ces actions ont en tout cas augmenté de manière visible le nombre de femmes présentes aux sessions du JUG. Il y a régulièrement une quinzaines de femmes sur un peu plus de 200 participants.

3 mois bien remplis et des vacances bien méritées, une fois qu’on aura préparé la rentrée.

Les projets pour la rentrée

Tout d’abord un gros projet, la constitution de groupes de travail pour préparer le SCJP, la certification Sun Certified Java Programmer.  C’est le projet de Katia qui nous l’a présenté plus en détail. Il y a déjà eu un post donc je n’y reviendrai pas ici. La mise en place de ces groupes commence cet été mais le vrai travail de groupe pour apprendre et préparer l’examen commencera à la rentrée et on aimerait bien avoir de l’aide des experts certifiés qui sont déjà passés par là.

Audrey Neveu et Katia Aresti - Photo: José Paumard

Audrey Neveu et Katia Aresti - Photo: José Paumard

Pour la rentrée aussi, deux conférences où Duchess France sera et se présentera.

  • Le JUG Summer Camp à La Rochelle le 10 Septembre
  • Devoxx à Antwerp en Belgique du 15 au 19 Novembre. Il y a aura un BOF JDuchess dans le cadre de “Women in IT an unconference” et ça sera aussi l’occasion pour nous de rencontrer les JDuchess des Pays-Bas et celles qui  n’ont pas encore de groupe dans leur pays.

D’ailleurs si vous participez à ces conférences, n’hésitez pas à nous contacter pour discuter ou pour nous rejoindre.

Voilà c’est fini, nous rendons le micro au conférencier  Adam Bien qui est allemand et ne parle pas français. Il a bien noté qu’il y avait un groupe de femmes, chose un peu étrange dans une conférence Java. Les Duchess ont eu l’honneur de donner leur nom (enfin plus ou moins) au package Java de l’exemple.

Il nous cite sur Twitter et dans son blog :

On remercie Adam Bien, même si son orthographe de “duchess” était un peu approximative, sa présentation était excellente. A quand un groupe JDuchess en Allemagne ? Affaire à suivre …
Et n’oubliez pas, les articles techniques sur la conférence qui arriveront en début de semaine.

Inscrivez-vous dans notre groupe de travail SCJP !

4:00 pm in Duchess Agit by Katia Aresti

Qu’est-ce que c’est SCJP ?

SCJP signifie “Sun Certified Java Programmer”. Il s’agit d’une certification pour les programmeurs(euses) Java qui souhaitent évaluer et certifier leurs compétences dans ce langage. La certification s’obtient par la réalisation d’un examen validé par Sun (Oracle). Celle-ci est accessible à tout le monde.

Quel est l’intérêt ?

La préparation et l’obtention de la certification Java est très instructive : vous permet de mieux comprendre les fondements du langage, de découvrir des fonctionnalités, d’améliorer votre code, d’apprendre les bonnes pratiques de POO etc. Il s’agit d’un véritable accélérateur pour améliorer vos connaissances et d’un vrai plus pour mettre en avant vos qualités d’experts dans votre CV.

Pourquoi un groupe de travail ?

Parce que c’est un excellent moyen pour apprendre, améliorer et décortiquer les fondements du langage Java tou(te)s ensemble de façon motivante, productive, dynamique, régulière et ludique !!

Comment fonctionne le groupe ?

Le groupe de travail est composé de personnes motivées qui souhaitent participer par e-mail et/ou de manière physique lors des réunions sur place. Deux types de participation son envisageables :

1 ) Internet : Ouvert à tout le monde. Le membre peut sur ce groupe envoyer des messages, accéder à nos fichiers, proposer des idées, apporter son expertise, envoyer des exercices, des liens intéressants, etc. Pas de vrai investissement. Places illimitées.

2 ) Sur le terrain : Les participants de ce mode travail sont rigoureux, sérieux et motivés. On demande à chaque membre de s’investir personnellement dans le groupe par la réalisation des exercices et la préparation des sujets à traiter. On leur demande également de la disponibilité pour se réunir deux fois par mois. Non sérieux s’abstenir !! Rigueur et régularité pour assister aux séances seront les maîtres mots. Dans ce mode d’inscription, les places sont très limitées (mais il en reste encore!)

L’objectif commun : devenir des vrais experts Java pour obtenir la certification. On souhaite aussi faire participer, dans la mesure du possible, les personnes déjà certifiés et aux experts pour nous soutenir et nous conseiller.

Inscription et information complémentaire

Si vous êtes d’ores et déjà intéressé(e)s, demandez dès maintenant l’inscription dans le groupe :

scjp-jduchess@googlegroups.com

Afin de répondre à toutes vos questions, je serai au Paris JUG le mardi 6 Juillet pour en discuter. Vous pouvez toutefois m’écrire un mail :

katiaaresti@gmail.com

C’est en faisant qu’on apprend (cf. philou)

Venez nombreux et nombreuses à l’AvantJUG de Juillet !

7:00 am in Duchess Agit by ElleneDijoux

Comme les mois précédents, nous organisons l’AvantJUG, la rencontre précédant le ParisJUG. Cette pré-soirée aura lieu comme toujours au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30. Vous souhaitez rencontrer les habituées de l’AvantJug ? Convaincre une de vos collègues de vous accompagner au ParisJUG ? Ou tout simplement discuter autour d’un verre alors n’hésitez pas ! Venez nous voir !

Vous souhaitez venir au ParisJug 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/20100706, les inscriptions devraient débuter à partir de 7h Jeudi 1er Juillet– 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 le 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é.