Assistant(e) Marketing en Stage (H/F)

Dans le cadre de la diffusion d’un nouveau produit innovant dans le domaine de la mobilité, Génitech recherche pour son siège social un(e) Assistant(e) Marketing en stage.

Vous contribuez au développement de l’activité d’un nouveau produit innovant mobile et tactile sans contact, conçu en collaboration avec un consortium Européen de recherche, en lien avec le Responsable Projet et les autres membres du consortium. Vous participez à la réflexion stratégique, l’élaboration concrète ainsi qu’au suivi des actions marketing Européenne du produit.Dans une démarche prospective, vous mènerez des études ciblées de marché afin de cadrer et d’optimiser la communication et de proposer des adaptations produits en fonction des retours « terrains ». Vous coordonnerez ensuite les actions de communication et de dissémination afin de maximiser le taux de reconnaissance du produit auprès de la population cible.

De niveau Bac+2 à 5, vous êtes force de proposition et possédez une réelle créativité dans l’élaboration de stratégies d’actions Marketing et de dissémination d’un produit innovant ainsi que de rigueur dans la gestion de leur suivi et leur mise en place.

Bon niveau d’anglais écrit nécessaire.

Démarrage :
Avril 2013

Durée : 3 mois

Lieu du stage:
Malakoff (ligne 13 du métro)

Posted in RH, stages | Leave a comment

Quand l’Espace Personnel de Données (PIMS) est vulgarisé…

Mobile World Congress 2013

Lors du Mobile World Congress à Barcelone, Samsung a annoncé Knox.

Il s’agit d’une version d’Android personnalisée permettant de basculer très facilement entre environnements (appelé Persona)  : d’un environnement personnel à un environnement professionnel. Les deux environnements sont hermétiques en termes de données et donc de vulnérabilité potentielle pour le système d’information de l’entreprise.

Nous avons pu par exemple rencontrer un représentant de DropBox qui nous a présenté son produit DropBox for Teams adapté à Knox : on accède à des espaces de stockage et partage de fichiers qui sont différenciés selon le Persona.

On ne discutera pas ici des points forts et faibles (pas d’approche via les standards, obligation d’adapter les applications par les éditeurs etc.) du produit mais on s’attachera à souligner le nouveau paradigme popularisé.

En effet, les utilisateurs de mobiles n’ont jusqu’à présent pas à se soucier de leur rôle dans leur utilisation de leurs services mobiles (Apps, m-services connectés) et en particulier de leurs données personnelles. La frontière donnée personnelle / donnée publique s’est progressivement effacée par l’utilisation généralisée des réseaux sociaux. Certes, beaucoup s’en émeuvent, demandent le droit à l’oubli, commencent à lire les conditions générales d’utilisation des services auxquels ils sont abonnées. Mais le mal est profond pour l’entreprise : comment faire confiance dans un dispositif mobile (smartphone ou tablette) qui serait une passoire à données  où espaces public, privé et professionnel seraient perméable ? Généraliser le BYOD présente donc un risque important pour l’entreprise au coeur d’une guerre économique sans frontière.

C’est pourquoi l’initiative de Samsung avec Knox a le mérite de familiariser le grand public avec le concept de rôle, d’habilitation, de séparation des espaces de données et ceci dans un vocabulaire simple (le Persona) et une ergonomie des plus utilisables (un simple clic permet de basculer de contexte).

Samsung réussira-t-il dans son défi de popularisation des Espaces de données personnelles (PIMS pour Personal Information Management System) et des fédérations d’identité (même si elle reste réduite à deux identités) là où Apple a réussi pour le Cloud avec son service iCloud. Nous le lui souhaitons.

PS : vous trouverez plus d’informations sur nos travaux sur les PIMS dans la description du projet PIMI.

Posted in Divers | Tagged , , , | Leave a comment

Test de validation : comment envoyer et recevoir des e-mails sans disposer des boîtes mails réelles ?

Nombre d’entre vous ont probablement déjà eu à tester une application qui doit envoyer des e-mails à différentes adresses de courriels.

Les problèmes suivants se posent alors :

  • Comment exploiter un jeu de données réaliste et disposer d’adresses e-mails différentes pour tous les utilisateurs simulés durant les tests (Pour un service en ligne : des demandeurs, des gestionnaires, voir d’autres intervenants…) ?
  • Comment réaliser un test de bout en bout : envoi d’un e-mail, réception de ce mail, voir plus – par exemple : clic sur un lien reçu dans le mail et permettant d’accéder directement à une application web pour valider notre compte utilisateur, etc.

Bien sûr, on peut y parvenir en bricolant :

  1. Si on utilise une base de données et que les messages y sont stockés, on peut aller consulter les messages en base et vérifier, voir récupérer leurs contenus. Cela peut convenir pour les tests unitaires, mais dès qu’on entre en phase de validation ou de démonstration, il faut trouver une autre solution, plus proche de la réalité finale de l’application.
  2. On peut utiliser une unique adresses e-mail : notre adresse personnelle. Cela ne suffit pas toujours. En particulier, si l’application impose comme contrainte d’utiliser l’adresse e-mail comme identifiant. il est alors impératif de disposer de plusieurs adresses distinctes.
  3. On peut demander la création d’adresses de tests – étrangement, tout d’un coup, l’administrateur système commence à nous éviter quand il nous croise dans les couloirs… ;-)

Heureusement, il existe d’autres solutions – au moins une autre !

Pour ma part, j’ai testé l’utilisation d’un serveur SMTP local : Papercut http://papercut.codeplex.com/. Il  existe d’autres serveurs de ce type.

Après une installation simplissime, il suffit d’indiquer à l’application à tester que le serveur SMTP se trouve sur la machine locale (localhost). L’interface utilisateur du serveur SMTP permet alors de consulter les messages envoyés par l’application, au travers de 3 vues : “Raw View” (en-tête complet et les diverses autres parties du message), “Body View” et “HTML View”.
Mais ce n’est pas tout ! Papercut dispose d’une fonctionnalité très sympathique nommée “Forward” : on peut ainsi transférer les messages vers une autre boîte aux lettres. Pour cela, il suffit de préciser le serveur SMTP sortant à utiliser et l’adresse de destination finale.

Posted in Divers, Test | Leave a comment

Participez au projet UbiLoop

L’institut d’Études Politiques de Toulouse (IEP) et l’Institut de Recherche en Informatique de Toulouse (IRIT) organisent une vaste enquête en ligne sur l’usage des smartphones et la citoyenneté. Cette enquête s’inscrit dans le cadre du projet de recherche européen FEDER UBILOOP.

Donc si vous êtes utilisateur de smartphone et que vous souhaitez participez à la recherche sur l’utilisation des smartphones dans votre vie citoyenne, alors vous pouvez participer à l’enquête en ligne sur ce sujet (durée d’environ 15 minutes).

Cette enquête porte sur l’application UBILOOP qui permet de déclarer, en ligne sur un smartphone, différents types d’incidents urbains comme des lampadaires cassés, des nids de poules, des tags/graffitis, des nids de frelons ou tout autres incidents du même type. Une fois déclarés, ces incidents sont pris en compte par les services compétents qui seront en charge de les corriger.

Les bénéfices que vous pouvez retirer de la participation à cette enquête sont à la fois une appréciation d’un exemple de service lié à l’action citoyenne à l’aide d’un smartphone et également une opportunité de contribuer à la recherche scientifique.

Si vous souhaitez participer alors cliquez sur le lien suivant:

http://edu.surveygizmo.com/s3/1080030/Enqu-te-Ubiloop

Merci par avance pour votre contribution.

Posted in Divers | Tagged , , , , | Leave a comment

Agile Tour Toulouse 2012

Logo Agile Tour

AGILE TOUR TOULOUSE 2012

C’est avec grand plaisir que je me retrouve pour la seconde fois présent à l’Agile Tour Toulouse, à l’espace de congrès Diagora. Pour rappel, vous pouvez retrouver mon compte rendu de la précédente édition à l’adresse suivante : Agile Tour Toulouse 2011

Je ne ferai donc pas ici de redite des notions déjà présentées dans mon précédent billet.

Cette conférence qui dure toute la journée a rassemblé cette année près de 500 personnes dont environ une moitié de nouveaux venus.

En plus des conférences et ateliers habituels, une nouveauté a fait son apparition dans cette édition : les Open Talks. Pour les déçus qui n’auraient pas été sélectionnés afin d’effectuer des présentations ainsi que pour les gens qui se posent des questions particulières ou voudraient lancer des débats, de petites conversations étaient organisées toutes les 30 minutes à la demande des personnes présentes (il suffisait d’écrire le sujet sur un bout de papier).

Mon programme, cette fois-ci axé sur les ateliers et la mise en pratique ne m’a pas laissé ne serait-ce que 5 minutes de répit afin d’aller voir de quoi il retournait exactement.

Keynote

Après une présentation succinte de chacun des sponsors (Valtech avec une vidéo “Agilité et Rugby”, ekito qui a conçu le site de l’évènement, Kagilum qui organise un jeu pour une licence d’IceScrum et Ubleam, concurrent Toulousain des QRCodes), David Brocart et Thierry Cros nous ont offert quelques scènettes théâtrales afin de mettre en avant les valeurs liées à l’Agilité. Munis de déguisements plus criants de vérité les uns que les autres (spéciale dédicace pour Thierry avec son Tshirt Metallica et sa perruque de chevelu, son accoutrement de coach des années 80 et à David qui incarnait le CEO à moumoute de manière magistrale), les deux présentateurs ont mis en avant de très nombreuses notions : les niveaux logiques de Dilts-Bateson qui nous poussent à chercher la cause des problèmes au niveau directement supérieur à celui dans lequel ils se produisent, la nécessite de limiter le stock et d’attendre le feed-back avant d’agir, la théorie X et Y de Mac Gregor ainsi qu’un grand nombre de concepts liés au code : clean code, refactoring, tdd, YAGNI (You Ain’t Gonna Need It). Je vous enjoins encore à aller jeter un oeil à mon retour sur l’édition précédente afin de trouver plus de détails autour de ces sujets. Pour tout vous dire, cette keynote présageait sans que je le sache à cet instant précis de ce qu’allait être le programme de ma journée : particulièrement chargée.

Innovation Games (par Eric Rubinat)

Je me suis donc prestement dirigé vers le premier des 4 ateliers qui m’intéressaient particulièrement en ce jour : à savoir une mise en pratique des Innovations Games. Ce sujet me tient particulièrement à coeur, étant un grand amateur de jeux de société depuis mon plus jeune âge et étant déjà sensibilisé à leur apport en terme d’apprentissage. A mon grand regret, étant donné le nombre trop élevé de participants, le présentateur nous a annoncé la couleur d’entrée de jeu : pas de démonstration en live malheureusement. La séance s’en est donc tenue à une présentation des jeux “Innovation Games” (attention, le nom et les 13 jeux correspondants sont déposés depuis 2003 par Lukue Homan, leur créateur).

Les jeux quels qu’ils soient commencent à perdre la mauvaise image qui les accompagnait depuis bien longtemps (associabilité, déni des réalités…) et les gens commencent désormais à comprendre leur intérêt (développement de l’esprit de combativité, de la créativité, mise en place d’un lien de communication important).

On peut découper les jeux liés à notre domaine en trois ou quatre grandes catégories :

  • les meeting games (comme ROTI par example : Return Of Time Invest)
  • les serious games utilisés depuis bien longtemps dans des domaines tels que l’armée, la médecine etc afin de pouvoir s’entraîner et pratiquer sur des reproductions de situations réelles.
  • les jeux agiles qu’on utilise le plus souvent pour enseigner des concepts utilisés dans les différentes approches agiles.

Les serious games sont utilisés le plus souvent comme leviers du ROI Agile (Return Over Investment cela va sans dire). On s’en sert pour trouver la liste des features, les prioriser…

Il ne faut pas prendre cela à la légère en tant qu’animateur : il est nécessaire de passer beaucoup de temps à préparer de tels ateliers afin que les choses se passent au mieux.

Il faut tout d’abord définir l’objectif principal, poser la BONNE question.

Il est ensuite nécessaire de planifier : prévoir les personnes, déterminer quel jeu conviendrait.

On prépare ensuite le jeu, puis on y joue.

On agrège enfin les données, sans sous-estimer le temps nécessaire. En effet, il est nécessaire de passer beaucoup de temps sur cette partie afin de tirer le meilleur parti des jeux effectués.

Enfin, on définit et on communique le plan d’action à adopter pour la suite.

Durant la session, on peut noter plusieurs rôles :

  • l’organisateur
  • un maître de cérémonie (peut être la même personne mais pas forcément)
  • un photographe si on peut, c’est toujours plus sympa et peut permettre de voir des choses qu’on n’aurait pas vues sinon (qui a parlé d’artefacts bizarres sur les photos?).
  • un observateur, qui garde un oeil extérieur et prend des notes sur des choses qui n’auraient pas été notées sinon.

Les jeux Innovation games présentés :

  • le Speed Boat : une île représente l’objectif majeur, on identifie les aides, freins et esquifs qui peuvent surgir pour l’atteindre. Ce jeu peut être utilisé pour remotiver les rétrospectives ou pour les kick-off meetings.
  • la Product Box : on donne du matériel de papeterie aux différents participants (ciseaux, carton, papier, colle, feutres…) et on leur donne pour objectif de définir le packaging de leur produit. Cela permet de découvrir de nouvelles features pour le produit et de les prioriser fonction de leur emplacement sur la boîte. Il est plus que fortement conseillé d’avoir un observateur pour ce jeu.
  • Prune the Tree : les branches représentent des features existantes, on donne aux participants les restantes à placer sur l’arbre (sans leur permettre d’en rajouter) en considérant que plus une feature est proche de la racine plus elle est importante.
  • Buy a Feature : des billets permettent d’acheter des features et sont donnés en nombre limité. D’après l’intervenant (mais pas d’après Lukue Homan…) il ne faudrait pas donner un coût par feature. Je suis en désaccord avec cette notion. Pour moi, ce jeu sert surtout en cas d’indécision du client pour le contenu des itérations et les coûts par feature doivent représenter son coût réel en temps de développement.

L’intervenant a ensuite présenté brièvement une liste de jeux Agile, qui servent pour la formation et n’apportent pas de valeur produit, ils permettent simplement de faire passer un message :

  • Bottle-Neck Game (60 à 90 min)
  • the Real Options Space Game (90 à 120 min) : notion de décision au dernier moment
  • The Toyota Way (45 à 90 min)
  • Marble Run (20 à 30 min) : planification agile
  • Origami (10 à 20 min) : importance de la communication -> OFFSHORE
  • Swiss Army Knife (10 à 15 min)
  • Start Your Day
  • Remember the feature (dans 2j ? 2 ans ? 10 ans ?)

Les maîtres mots :

  • Préparer
  • Garder du temps pour les retours
  • En lieu et place d’une réunion

Kanban par la pratique (par Laurent Morisseau)

Ne connaissant pas du tout la méthode Kanban, je me suis ensuite rendu dans cet atelier pour en savoir plus. Le jeu (un serious game disponible sur getKanban.com) était un jeu de plateau avec 7 dés à 6 faces de 3 couleurs différentes (2 rouges pour le design, 3 bleus pour le développement et 2 oranges pour les tests). Des cartes avec des points à compléter dans chaque catégorie sont disposées dans des colonnes avec un nombre d’éléments limités. Le but est d’arriver à remplir les cartes avec les dés et à les faire avancer dans les différentes colonnes sans créer de blocages. Les dés lancés comptent double si on les affecte à la catégorie pour laquelle ils sont prévus, simple sinon.

Des impondérables viennent rythmer la partie pour corser un peu et rendre le jeu plus intéressant.

Il permet de se rendre compte de l’importance de la fluidité de la chaîne de bout en bout et de l’importance de limiter le nombre de tâches simultanées dans chacune des catégories. Le temps moyen de réalisation par tâche s’en retrouve lissé et plus prévisible.

Cependant, on constate rapidement que cette méthode de gestion permet d’accomplir certaines actions prioritaires à une cadence énormément plus élevée qu’à la normale, et semble donc potentiellement plus souple.

Pour en avoir discuté par la suite avec la personne qui nous faisait cette présentation, cette méthode est particulièrement adaptée dans les cas où l’agilité serait mal perçue, et permettrait d’effectuer une transition en douceur.

Piqué au vif, je tâcherais donc d’en savoir plus prochainement à ce sujet.

Et un carpaccio ! Un ! (par Géry Derbier)

Rencontrant parfois des problèmes de découpage de tâches avec certains clients, j’ai voulu essayer de voir si cet interlocuteur n’avait pas par hasard la solution miracle. Eh bien non !

La séance consistait à découper une problème très simple : le calcul du prix total en appliquant une ristourne fonction du montant total de la commande et en appliquant des taxes fonction de la région géographique.

La séance était constituée de 5 itérations de 8 minutes. A la fin de chaque itération, il fallait montrer une nouvelle fonctionnalité développée.

Autant dire que le timing était serré, d’autant plus que j’ai voulu, comme à mon habitude dans ce genre de cas partir sur une approche en TDD. Ceci dit notre groupe s’en est aussi bien sorti que les autres au final : les tests en plus !

Projet dont vous êtes le héros (par Antoine Vernois et Pablo Pernot)

Autant le dire tout de suite, c’était là mon gros coup de cœur de la journée. Je me suis régalé.

3 ballons étaient disposés dans la salle et notre groupe devait répondre à des questions liées à l’agilité en se rapprochant de l’un des 3 fonction des questions posées.

Les questions étaient assez ambiguës pour que des doutes se posent et que chaque réponse puisse sembler valable à certains.

Une petite discussion s’installait du coup sur les résultats. Si la majorité des personnes s’était trompée, on procédait à une épreuve subsidiaire (des petits jeux agiles).

Nous évoluions ensuite sur une carte en choisissant notre prochaine destination.

Le contexte était sympa, les questions pas mal tournées et souvent drôles, les discussions intéressantes et les jeux instructifs, un vrai régal !

Je ne saurais que vous conseiller d’aller jeter un coup d’œil sur le site du jeu

Cependant, si vous comptez assister à cet atelier lors d’un prochain atelier, évitez.

Agile Unlimited (par Alexandre Boutin)

J’avais adoré les présentations d’Alexandre Boutin l’an dernier et attendais donc avec impatience sa note de clôture. Ses slides tournaient cette fois-ci autour de l’univers de Star Trek et traitaient de l’application possible des méthodes Agiles à d’autres domaines que l’informatique. Effectivement, on peut reprendre les concepts suivants assez facilement :

  • le Management Visuel à grands coups de Post-It
  • le stand up d’équipe
  • la rétrospective
  • la Vision Partagée
  • l’Ordonnancement
  • les Boîtes de Temps (le fait de borner le temps alloué aux réunions et de filtrer les participants utiles)

Cependant, de nombreux freins se lèvent au sujet de cette adoption :

  • les REX personnels
  • la tolérance à l’erreur dans certains domaines
  • le Command & Execute
  • les problèmes de Communication
  • la Visibilité (certaines personnes n’ont pas forcément envie que ce qu’ils font comme travail soit plus transparent)
  • l’Autonomie (certains préfèrent travailler seuls)
  • le Travail Répétitif

Le point principal abordé par Alexandre et sur lequel il a le plus insisté est qu’on ne peut pas faire d’agilité si la culture de l’entreprise ne s’y prête pas. L’agilité est une histoire de culture et nécessite bien souvent un changement de culture, qui est un processus particulièrement difficile.

Ainsi s’achève mon deuxième Agile Tour Toulouse. N’hésitez surtout pas à me demander des précisions !

Posted in Agile Tour, Agiles, Conferences, Methodologies, Scrum | Tagged | 1 Comment

JBoss et le classloading

Qui n’a jamais transpiré sur des problèmes de chargement de classes lors d’un déploiement applicatif sur un serveur d’application ?
Le serveur JBoss n’étant pas différent des autres, il n’est pas rare d’avoir ce genre de problèmes que vous déployiez des EAR ou des WAR, ou que vous utilisiez la version communautaire (JBoss A.S.) ou bien la version Enterprise (JBoss Enterprise Application Platform – EAP). Evidemment, on a plus de chances de les rencontrer lorsqu’on doit déployer plusieurs EAR et/ou WAR (imbriqués ou non) au lieu d’un seul, mais quelques soient les causes, la ou les solutions ne sont en général pas faciles à identifier ni à résoudre, surtout la première fois où cela arrive.
Un scénario typique et classique étant un conflit d’utilisation de classes de logging lors de l’utilisation de versions différentes de librairies par une application et par le serveur lui-même.
Génigraph étant partenaire Red Hat sur toute la gamme middleware JBoss, c’est donc régulièrement que nous sommes confrontés à des questions sur ce sujet.

Le but de cet article n’est pas d’identifier toutes les sources possibles de conflit de classloading, mais d’expliquer les différences de fonctionnement de classloading entre JBoss EAP 5 (ou A.S. 5) par rapport à JBoss EAP 6 (ou A.S. 7).

1. Présentation rapide du concept
Un chargeur de classes (classloader) représente typiquement un ensemble de jars composant un module, un composant ou une application. Chaque classloader possède un classloader parent. De fait, les classloaders forment une hiérarchie arborescente avec le classloader de démarrage (bootstrap) à son sommet. Lorsqu’un classloader charge une classe, il peut d’abord demander à son parent de charger celle-ci. Si le parent ne réussit pas à charger la classe, ce classloader essaie alors de charger la classe. Dans ce scénario appelé « parent-first class loading », les classes communes sont toujours chargées par le classloader parent. Ceci permet à une application ou à un module de communiquer avec une autre application ou un autre module à l’intérieur de la même VM. Une alternative est de demander à un classloader de trouver lui-même une classe, puis s’il échoue de demander à son parent. Cette stratégie permet à une application d’avoir une version d’une classe différente de celle trouvée dans le classloader de son parent. Cependant, il est parfois nécessaire de modifier la séquence de chargement par défaut, ou bien d’isoler les classes à l’aide de classloaders distincts afin de résoudre des problèmes de déploiement. Le problème le plus courant étant un conflit de version d’une librairie entre celle incluse dans l’applicatif et celle du serveur. Les exceptions suivantes sont les plus courantes lors de problème de classloading avec JBoss EAP 5 : ClassCastException, IllegalAccessError, VerifyError ou LinkageError.

2. Classloading en EAP 5
Le classloading en EAP 5 est basé sur un modèle hiérarchique.

Cette approche soulève les problèmes suivants :
• Tous les JAR sont toujours chargés, utilisés ou non ;
• Conflits de version ;
• Temps de lookup et de chargement élevé ;
• Difficile d’identifier la source des problèmes.

Différentes résolutions de problèmes de classloader sont possibles avec JBoss 5 :
• Identifier les JARs coupables et les supprimer si c’est possible ;
• Isoler les classloaders. Ceci implique les changements suivants :
• Pour un WAR : commenter l’élément WarClassLoaderDeployer dans le fichier $JBOSS_HOME/server/<ma_config>/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml
• Pour un EAR : affecter la valeur true au flag isolated (dont la valeur par défaut est false) situé dans l’élément EARClassLoaderDeployer du fichier $JBOSS_HOME/server/<ma_config>/deployers/ear-deployer-jboss-beans.xml.
• Définir un fichier WEB-INF/jboss-classloading.xml qui est à déployer avec l’application et permettant de définir la stratégie à utiliser pour le chargement des classes de l’application.

3. Classloading en EAP 6
Le principe de chargement des classes pour JBoss EAP 6 / JBoss A.S. 7 est radicalement différent de JBoss 5 et est désormais basé sur le principe de modules. Ses particularités sont les suivantes :
• Chaque application déployée est un module isolé des autres ;
• Les modules applicatifs n’ont pas de visibilité des modules du serveur et vice versa ;
• Les modules doivent déclarer explicitement leurs dépendances aux autres modules.

Distinction WAR/EAR :
• Pour les WARs : un WAR est considéré comme un module simple et les classes définies dans WEB-INF/lib sont traitées de la même façon que celles sous WEB-INF/classes. Toutes les classes packagées dans le WAR seront chargées par le même chargeur de classes.
• Pour les EARs : le déploiement de fichiers .ear correspond à un déploiement multi-module, c’est-à-dire que toutes les classes à l’intérieur d’un EAR ne seront pas forcément visibles depuis les autres classes de ce même EAR, sauf si des dépendances explicites sont définies. Par défaut, le répertoire EAR/lib correspond à un module simple, et chaque WAR ou EJB est déployé en tant que module distinct. Ces WAR ou EJB ont toujours une dépendance avec le module parent ce qui leur donne accès aux classes situées dans EAR/lib, mais n’ont néanmoins pas toujours une dépendance automatique les uns par rapport aux autres. Ce comportement peut être contrôlé à l’aide du paramètre ear-subdeployments-isolated situé dans la configuration du sous-système ee (par exemple dans le fichier standalone.xml dans le cas d’une utilisation en mode standalone) :
<subsystem xmlns=”urn:jboss:domain:ee:1.0″ >
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
</subsystem>

La valeur false par défaut permet aux sous-déploiements (c’est-à-dire aux WARs et EJBs) de voir les classes appartenant aux autres sous-déploiements du même EAR.

Exemple : pour le EAR suivant :
myapp.ear
|
|— web.war
|
|— ejb1.jar
|
|— ejb2.jar
Si la valeur de ear-subdeployments-isolated est à false, alors les classes dans web.war ont accès aux classes situées dans ejb1.jar et ejb2.jar. De même, les classes dans ejb1.jar ont accès aux classes de ejb2.jar (et réciproquement).
Si la valeur de ear-subdeployments-isolated est à true, alors il n’y a pas d’ajout de dépendance de modules mise en place automatiquement : l’utilisateur doit définir manuellement les dépendances :
• soit dans le fichier de manifeste (section Class-Path). L’avantage de cette solution est la portabilité : la spécification Java EE précise que les applications portables ne devraient pas se baser sur le fait que des sous-déploiements peuvent accéder à d’autres sous-déploiements sauf si une entrée Class-Path est explicitement définie dans le fichier MANIFEST.MF.
• soit en définissant de façon explicite les dépendances aux différents modules (fichiers module.xml de chaque module en question). L’avantage de cette méthode est d’avoir une gamme d’options plus larges, ainsi que de pouvoir référencer des modules qui ne sont pas packagés dans l’application.
• soit dans un fichier jboss-deployment-structure.xml spécifique à JBoss et inclus à l’application. L’avantage de cette approche est de permettre de définir les dépendances dans un seul fichier.

Priorités de chargement de classes :
Le serveur se base sur les priorités suivantes lors du chargement des classes afin d’éviter des conflits :
• Les dépendances système chargées automatiquement (y compris les APIs Java EE)
• Les dépendances déclarées explicitement par l’utilisateur, soit dans le fichier de manifeste, soit dans le fichier jboss-deployment-structure.xml.
• Les librairies packagées avec l’application (classes sous WEB-INF/classes ou .jar sous WEB-INF/lib).
• Les dépendances inter-modules.

Posted in JBoss, JEE, JEE6, Red Hat | Leave a comment

Utiliser Ant ou Jenkins sur des tests automatiques écrits dans n’importe quel langage (autre que Java & C++).

Bonjour,

Voici un modeste retour d’expérience chez un client (appelons le “S.”) qui peut vous intéresser si votre projet comporte des tests automatiques pour lesquels il n’existe aucun framework. Cela peut arriver lorsque les tests sont écrits avec des langages exotiques ou “faits maison” comme c’est le cas chez S. :
L’exploitation des résultats de tests se faisait jusqu’à maintenant par des rapports de sortie de test au format texte, dans lesquels il fallait faire une recherche manuelle sur le mot clef “error”, un bon vieux “grep” en quelque sorte… méthode rudimentaire et efficace mais qui peut commencer à poser des problèmes pratiques lorsque le nombre de tests devient important.

Pour bénéficier de la plus-value des outils existants comme Ant ou Jenkins, il suffit de rajouter en sortie de chaque test automatique un fichier XML qui respecte le format JUnit.
Si, de plus, vos tests sont classés dans une structure hiérarchique de type “arbre”, vous pouvez réutiliser les noms des niveaux de hiérarchie en lieu et place des packages Java utilisés par JUnit dans ces fichiers XML.
Par exemple :
Ma_campagne_de_tests\mon_domaine_fonctionnel_n1\mon_test_1
Ma_campagne_de_tests\mon_domaine_fonctionnel_n1\mon_test_2
Ma_campagne_de_tests\mon_domaine_fonctionnel_n2\mon_test_1
Ma_campagne_de_tests\mon_domaine_fonctionnel_n2\mon_test_2

Une fois que ces fichiers XML sont générés, il suffit d’appeler la tâche <junitreport> dans un script Ant pour générer à partir de ces fichiers un rapport synthétique au format HTML, avec navigation entre packages et sous-packages.
Ca marche bien, mais par défaut, la tâche <junitreport> génère un rapport orienté JUnit (on ne saurait lui en vouloir), avec des libellés tels que : “Designed for use with JUnit”.
Pour corriger ce genre de détails, on peut fournir en entrée de la tâche ant un fichier .xsl adapté au contexte, en utilisant le paramètre styledir de <junitreport>. Pour tout savoir sur junitreport et styledir : http://ant.apache.org/manual/Tasks/junitreport.html

Et pour ne pas tout réecrire, on peut prendre comme modèle le fichier .xsl de Ant qu’on peut trouver ici : ...\apache-ant-1.8.4\etc\junit-frames.xsl (ou ...\apache-ant-1.8.4\etc\junit-noframes.xsl selon le cas)

Et voilà : Arrivé à ce niveau, on dispose d’une tâche Ant capable de générer un rapport de tests HTML structuré, synthétique et personnalisable, lisible par un non-informaticien et qui nous permet d’oublier notre grep initial.

Et pour jenkins alors ? Il faut réussir à écrire un script qui passe les tests et qui place les fichiers XML de sortie de ces tests dans un Workspace Jenkins, et ça suffit : Jenkins appelle ce script régulièrement, et se débrouille tout seul pour analyser chaque série de résultats, pour la comparer avec les résultats précédents, et tracer les courbes qui vont bien, comme l’évolution du nombre de tests “OK” ou de tests  “KO” dans le temps.
On dispose alors d’un historique sur les résultats des tests automatiques, ce qui permet de cibler, par exemple, quelle modification du code a entraîné une régression, pour peu qu’on passe régulièrement tous les tests.

NOTE : Je n’ai pas trouvé de documentation sur le format exact utilisé par Ant pour les fichiers XML en sortie de tests Junit : cependant, il suffit d’écrire un test Junit trivial en Java, et de le passer via la tâche <junit> d’un script Ant, on dipose alors de fichiers qu’on peut facilement utiliser comme modèles.

Posted in JUnit, Methodologies, Test | Leave a comment

Déception @Asynchrone avec Jboss AS 6

Génigraph est partenaire Red Hat, et nous sommes friand des technologies JBoss : elles sont parmi ce qui se fait de mieux sur le marché, nous en sommes convaincus :

  • Convaincus, par nos expériences,
  • Convaincus, parce que la communauté nous en fait l’écho.

Mais parfois, un simple besoin utilisateur peut engendrer de petites déceptions …

J’ai la chance de participer à un projet qui met en œuvre le fleuron de la technologie Java :
EJB 3.1, Context and Dependency Injection,  JSF2, et j’en passe, tout ça sur une plateforme JBoss AS 6.1 Final.
Bref, tout pour être heureux.

Architecte en charge l’intégration de briques technologiques dans le projet et actuellement sur la conception d’un moteur d’exécution de traitements batchs, je lorgnais déjà depuis quelques temps sur cette nouvelle annotation @Asynchronous, introduite avec EJB 3.1.

Celle-ci permet d’indiquer que l’exécution d’un service EJB doit se faire de manière asynchrone. Elle permet surtout d’obtenir en retour immédiat un Future (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html) qui donne la main sur le thread d’exécution du service.

Très intéressant dans mon cas puisque les traitements exécutés sur le moteur peuvent prendre un certain temps et que l’Utilisateur, dans sa grande sagesse, a exprimé le besoin de pouvoir arrêter l’exécution du traitement à tout instant.

Et jusqu’à présent, avec les EJB, ça n’était pas possible ! Tout le monde sait que jouer avec les threads instanciés par le serveur JEE, c’est mal. Jamais personne n’oserait killer le thread d’exécution d’un EJB, en tout cas pas sans avoir conscience des conséquences irréversibles que cela peut avoir sur l’état du serveur… Une fois un service invoquer, on avait jusqu’alors qu’à attendre qu’il aboutisse.

Enfin j’allais pouvoir killer un service EJB, le rêve. Formulé de façon plus diplomatique, enfin il était possible d’arrêter proprement un service en cours d’exécution.

Pour illustrer, voilà à quoi peut ressembler l’implémentation d’un service asynchrone :

@Stateless
public class MonService {
@Asynchronous
public Future<String> faireQuelqueChoseDeTresTresLong()  {
thread.sleep(10000000); //très très long
String result = "j'ai bien dormi";
return new AsyncResult<String>(result);
}
}

Génial, avec ça je peux donc très simplement arrêter l’exécution de mon service quand je le souhaite par un appel à cancel(boolean) sur mon Future, dont j’ai conservé au chaud la référence.

Ca devrait fonctionner, les spécifications JEE6 sont formelles, mais malheureusement, ça ne fonctionne pas. L’appel à cancel reste sans effet…

Je cherche donc dans mon moteur de recherche préféré à voir si je me suis loupé quelque part, s’il y a  une subtilité qui m’aurait échappé, si c’est un problème connu de JBoss 6, …

Et quelle n’est pas ma surprise de lire (https://community.jboss.org/thread/177433#647108):

“@Asynchronous support in AS 6.x was not fully completed. I would recommend that you use AS 7.1.x and report any issues that you encounter. AS7 has fully functional @Asynchronous feature.”

Je comprends pas… pour moi il est évident que JBoss 6 est certifié JEE6, c’est justement là-dessus que se base sa réputation : le 1er serveur JEE OpenSource certifié ! Et là j’apprends qu’une fonctionnalité telle que les EJB asynchrone, présentée comme une des grosses améliorations de JEE6, n’est pas supportée ?!

Et bien effectivement, difficile à croire mais JBoss 6 n’est pas “Full Java EE 6 Certified”, mais uniquement “Java EE 6 Web Profile Certified” et ça fait une grosse différence !

Je vous laisse lire https://community.jboss.org/thread/160813 et https://community.jboss.org/thread/162247, discussions enflammées pour mieux comprendre le pourquoi du comment. Et aussi le résultat d’une enquête sur les attentes concernant la certification de JBoss exprimées par la communauté et les utilisateurs http://blog.webagesolutions.com/archives/357

D’où ma déception : JBoss 6 n’est pas “Full Java EE 6 Certified”  …. c’est a savoir !!!

Je ne suis bien évidemment pas le seul à être surpris de l’apprendre ; Je fais quoi moi maintenant ? Je passe en version 7…?

PS : tout est parti du dernier Java Magazine de Juillet-Août 2012, avec un article très intéressant sur le threading et la concurrence en JEE6, je vous laisse apprécier : http://www.oraclejavamagazine-digital.com/javamagazine/20120708/?pg=59&pm=1&u1=friend#pg59

Posted in JEE, JEE6, Java | 1 Comment

Participez au projet PIMI

Le projet PIMI - Personal Information Management through Internet – (http://www.agence-nationale-recherche.fr/en/anr-funded-project/?tx_lwmsuivibilan_pi2%5BCODE%5D=ANR-10-VERS-0014) auquel Genigraph participe en tant que coordinateur comporte dans ses objectifs scientifiques l’étude de la  corrélation entre QoS (Quality of Service) et QoE (Quality of Experience).

C’est pourquoi l’Institut Telecom Sud Paris, partenaire du projet, a conçu le questionnaire suivant :

http://qos-research.appspot.com/

Vous êtes invités à y participer avant le 15 septembre 2012. L’ensemble de l’expérience est courte et ne devrait pas vous prendre plus de 10 minutes au total. Merci d’avance pour votre collaboration.

Le service que vous allez utiliser plante volontairement pour simuler un niveau donné de Qualité de Service. Ne vous en étonnez-pas et allez jusqu’au bout de l’expérience.

Le projet PIMI est financé par l’Agence Nationale de la Recherche dans le cadre du programme VERSO.

L’ensemble de l’expérience est courte et ne devrait pas vous prendre plus de 10-15 minutes au total.
Posted in Divers | Tagged | Leave a comment

GWT et les architectures en couche

Les problèmes présentés dans cet article ont été soulevés lors d’une assistance sur un projet GWT. Celui-ci est basé sur une architecture en couches (couche modèle Hibernate, avec Daos, services, Dtos, le tout relié par Spring).

Axes d’étude pour des simplifications Modèle/GWT

Le problème principal vient de l’utilisation d’un grand nombre de couches et de l’absence quasi totale de discussion entre ces couches. Il nous est nécessaire de réécrire systématiquement des clones de nos objets métiers sous la forme de DTOs, et d’effectuer les conversions dans les deux sens.
On a identifié 3 approches pour le problème des DTO, au final seules deux sont viables : Gilead est en fait le “nouveau” nom d’Hibernate4Gwt. Cependant, ma recherche d’informations sur Gilead m’a poussé vers une 3ème solution.

Dozer

En ce qui concerne Dozer, il est toujours nécessaire d’écrire les objets DTO, mais en plus on doit écrire un fichier xml de mapping entre les deux. La plupart des propriétés de base seraient récupérées automatiquement, mais on rajouterait encore un fichier à écrire dans la plupart des cas. Il perd donc à mon sens grandement de son utilité étant donné qu’il aurait juste remplacé les quelques lignes de codes que l’on trouve dans chacun des services (sans même préciser qu’il faudrait configurer Dozer et lui indiquer où se trouvent ses fichiers de mapping). Je crains au final qu’en l’utilisant, on se retrouve à rajouter encore une couche alors qu’on estime déjà en avoir trop.

Gilead

Les classes du modèle métier doivent étendre LightEntity (pas très grave en soi).
Les services distants RPC doivent étendre PersistentRemoteService et non plus RemoteServiceServlet (là encore, ce n’est pas très impactant).
Mettre en place la configuration de l’HibernateUtil et l’utiliser dans les services.

Cela impliquerait quand même plusieurs choses en plus des petites configurations citées ci-dessus :
- supprimer tout le module DTO.
- modifier tous les services pour qu’ils retournent directement les objets du modèle et non plus ces objets convertis en DTOs.
- Changer côté webapp tous les objets utilisés par leurs équivalents dans le modèle métier.

Le gain serait non négligeable (surtout pour les développements futurs), mais le coût semble assez élevé.

De plus, Gilead est considéré comme inactif depuis près d’un ou deux ans. Ses sources restent ouvertes, mais le développeur principal ne travaillant plus sur ce type de technos avoue s’en désintéresser. Par contre, celui-ci pointe vers le RequestFactory intégré à GWT auquel je vais jeter un oeil.

RequestFactory

Cela semble être une approche totalement différente aux appels RPC (on passe par une autre Servlet pour les appels). Le tout est alors basé sur le modèle métier et non plus sur la notion de service.
Cela forcerait à repenser la quasi totalité de l’application…
Par contre, cette approche supporte la JSR303 (bean validation), ce qui permettrait de gérer les problèmes de validation d’objets directement sur les objets métier.
Dans ce cas aussi, il est nécessaire de passer par des DTOs, mais qui sont spécifiques à l’utilisation du RequestFactory.

https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory

Il faudrait lancer un chantier de grande ampleur si on voulait tirer bénéfice de cette approche.

La problématique Google

Google vient de très récemment (appris à Devoxx) de faire basculer ses meilleurs développeurs de GWT vers DART.

http://www.bizjournals.com/atlanta/blog/atlantech/2012/04/google-said-to-move-engineering-ops.html

La communauté GWT se pose des questions sur ce mouvement. Google va répondre à cette attente … bientot mais on ne connaît pas la nature de l’annonce :

http://bit.ly/JagK0J

Conclusion

La véritable question qui se pose au final est celle de la lourdeur de l’utilisation de GWT pour ce type d’application.

GWT est parfaitement adapté à des applications où la composante IHM est très importante et demande beaucoup de flexibilité : drag & drop, IHM flexible, applications type GTalk.

Toutefois, cette technologie est assez verbeuse dans le cas de la manipulation d’un modèle métier telle que nous l’avons initié dans le projet (hibernate). Cette verbosité ne peut etre éliminée qu’en utilisant des frameworks additionnels : Gilead est le meilleure candidat, malheureusement, le développeur nous a indiqué qu’il ne maintiendrait plus ce Framework.

D’autres solutions possibles sont : Request Factory (REST : à valider), mais cela demande des investissements lourds.
La question de GWT sur le long terme se pose aussi : cf news google d’Avril.

GWT est toutefois un framework stable et efficace malgré sa lourdeur réélle.

Posted in Divers, GWT, Google, Java | Leave a comment