Norsys, une réunion d'agence "Agile"

Hier soir a eu lieu la classique réunion d'agence de Norsys Région Nord dans les locaux d'Ennevelin.

La réunion avait l'originalité d'être présentée comme une réunion d'agence "Agile". Ça mérite bien un billet pour en parler.

Pour bien repréciser le sujet, il n'existe pas réellement de réunion "Agile" c'est pour cela que dans le titre du billet Agile est entre guillemet... En revanche, l'originalité de la réunion réside dans la réutilisation de certains concepts et de certaines méthodes Agiles pour organiser son déroulement.

Voici les différents points d'organisations intéressants :

• Ce sont les salariés qui ont choisi parmi un ensemble de thèmes (business, stratégie 2009, les méthodes Agiles, RH, informations sur le groupe Norsys...) ceux qui allaient être débattus pendant la réunion.
• Chaque thème devait être présenté en 10 minutes, pas plus, pas moins.
• L'utilisation du powerpoint pour présenter un thème était quasiment interdit pour favoriser d'autres modes de restitution visuels et originaux.

L'ensemble des salariés a donc été sollicité par mail en amont de la réunion pour choisir des thèmes. Lors de la réunion, pendant un premier "sprint", les thèmes retenus par mail ont été abordés et 2 thèmes ont été retenus en live pour être présenté dans un second sprint. Un pot convivial a été organisé après la réunion.



Les présentateurs ont utilisé des moyens originaux pour rendre fun la restitution des thèmes abordés (rappelons que le coté fun fait évidemment parti des méthodes Agiles) :

• interview.
• proposition de sujets par paper board/post-it.
• réutilisation du principe de "TODO", "IN PROGRESS" et "DONE" sur un tableau pour présenter l'avancement d'un thème.
• réalisation d'un "Dessinez c'est gagné" numérique "videoprojeté" (cf photo) pour trouver les sujets d'un thème.
• Diffusion d'une vidéo pour présenter un thème.
  
• réalisation d'une petite exposition dans une salle annexe pour présenter un thème.

remarques diverses :

• La réunion a rassemblé une grande majorité des salariés hier soir.
• Nos chers commerciaux n'ont pas réussi à respecter les 10 minutes pour présenter la partie business :-).
• La réunion était très vivante et participative.
• La réunion a été Fun!
• L'agence est maintenant en rupture de stock de paper board et de post-it :-).
• Les modes de restitutions des thèmes ont été très originaux.
  

Dans tous les cas, ça changeait de l'ordinaire et il fallait le souligner.

Migration Maven 2 : 3ème épisode : retour d'expériences

Il est vrai que je n'avais pas fait de 3ème épisode concernant ce sujet de migration de maven1 vers maven2.

Voici alors le 3ème épisode de la migration plutôt sous la forme d'un retour d'expérience... tintintin...

La migration a été effectuée sur 2 gros projets J2EE avec des processus de build assez complexe. L'utilisation de maven2 est effective depuis maintenant quelques mois. Voici en vrac quelques remarques par rapport à des ajustements effectués après la migration :

• delta au niveau du contenu des archives j2ee. Les archives j2EE ont tendance à prendre de l'enbonpoint (gestion des dépendances transitives, repository différents) : bien définir les exclusions et scopes.
  
• changement de comportement du build suite à l'apparition d'une nouvelle version du plugin : fixer la version de tous les plugins.
• confusion possible avec les fichiers de conf maven1 : une fois que l'utilisation maven2 est bien intégrée, faire le ménage sur les anciens fichiers de conf maven1 qui "polluent" le gestionnaire de sources.

Maven1 est en train d'être oublié par les équipes de développement, preuve que la migration est un succès.

Retouche photo en ligne : Pixlr

Dans le cadre d'un développement orienté web, si vous avez besoin de faire des petites retouches photos, je vous conseille d'utiliser Pixlr. C'est un bon compromis entre une interface simple et conviviale et un nombre de fonctionnalités déjà assez important (Pixlr prend en charge la gestion des calques par exemple).



Le tout est réalisé en Flash et propose des raccourcis clavier. On oublie même que c'est une interface "web". Il ne faut même pas s'inscrire...

Les virtuoses du photoshop seront surement déçus mais pour un outil gratuit et en ligne, c'est assez surprenant.

Voici l'adresse du site :
http://www.pixlr.com

Causes d'échec de l'Intégration continue

Dans certain cas, aux yeux d'une équipe de développement, l'intégration continue se limite à recevoir un mail quand le "build" de l'application échoue. Le problème est que l'intégration continue ne se limite pas seulement à ça...

Il ne faut pas oublier que l'intégration continue n'est pas qu'un outil mais bien un ensemble de pratiques autour de l'ingénierie logicielle. Dans un de ces articles, Martin Fowler présente les pratiques d'intégration continue sur son site.

Voici quelques causes probables d'échecs sur la mise en place d'une démarche d'intégration continue :

• un manque de connaissances de l'ensemble des pratiques d'intégration continue par l'équipe (y compris les managers).

• une mise en place d'un serveur d'intégration continue au niveau d'une équipe projet sans communiquer, informer sur les bénéfices de ce type de démarche et intégrer les principes de fonctionnement que cette mise en place entraine.

Si la volonté de mettre en place ce type de démarche ne vient pas de l'équipe , il faut alors présenter et communiquer autour de la démarche. Il ne faut pas oublier que ce type de pratique est fait pour les équipes de développements et pour leur permettre de travailler efficacement ensemble.

L'intégration continue est avant une histoire de communication. Cela doit être une culture au niveau du projet. Il faut rendre "fun" la pratique de l'intégration continue!

Supprimer les EJbs par Spring

J'ai procédé chez mon client à la réalisation d'une étude sur la suppression des EJBs Sessions sur un de leur applicatif java.

Pourquoi supprimer les EJBs Sessions?

• Pour simplifier l'architecture logicielle de l'applicatif.
• Pour simplifier la plateforme de développements.
• Pour simplifier le processus de construction de l'application.
• Pour augmenter la productivité des développeurs.
• Pour banaliser l'infrastructure serveur (pas de différenciation serveur métier et serveur présentation).
  

Qu'apportent les Ejbs Sessions au niveau de l'applicatif?

• La possibilité de séparer sur des infrastructures différentes la partie présentation et la partie métier. Cette possibilité n'est plus exploitée du fait de leur volonté de banaliser l'infrastructure serveur.

• La possibilité d'appeler la couche Ejbs ( couche "métier") depuis d'autres applications. Ce choix d'interfaçage n'a pas été retenu et il sera pris en charge par la mise en place de Web Services.

• La gestion des transactions. C'est la problématique intéressante qui reste à traiter... avec Spring évidemment...
  

L'intégration de Spring pour prendre en charge la gestion des transactions est réellement facile. Il existe 2 possibilités :

• de façon déclarative dans le fichier de conf Spring.
• Par annotation.

Après avoir testé les 2, j'ai choisi de le faire par annotations. L'inconvénient est d'être intrusif en rajoutant les annotations "@Transactional" dans le code. En revanche, cela augmente la lisibilité au niveau du code. Dans tous les cas, je crois qu'il n'y a pas de mauvaises façons de faire avec Spring mais dans tous les cas des façons "simplifiantes". Voici le lien vers la documentation de Spring qui m'a aidé concernant la gestion des transactions.

Dans le cadre du projet concerné, l'environnement de développement se base sur un simple serveur web Tomcat alors qu'en production, c'est un serveur d'application JBoss. L'applicatif à aussi la particularité d'utiliser un ensemble de datasources.

J'utilise alors un transaction manager différent selon l'environnement :

• Dans l'environnement de développement avec Tomcat, je ne pouvais pas me servir du transactionManager proposer par Spring (org.springframework.jdbc.datasource.DataSourceTransactionManager) car il ne gère qu'une seule source de données. Un article sur le site javaworld explique comment mettre en place un "ChainedTransactionManager" qui s'appuie ensuite sur le transactionManager de spring et permet de gérer plusieurs datasources. Voici un extrait de conf spring correspondante :
  

   <!-- aop pour la gestion des transactions -->
  <tx:annotation-driven transaction-manager="txManager" />
  
  <!-- recuperation des datasources en jndi -->
  <jee:jndi-lookup id="datasource1" jndi-name="jdbc/ds1" />
  <jee:jndi-lookup id="datasource2" jndi-name="jdbc/ds2" />
  <jee:jndi-lookup id="datasource3" jndi-name="jdbc/ds3" />
  <jee:jndi-lookup id="datasource4" jndi-name="jdbc/ds4" />
  
  <!-- declaration du transaction manager -->
  <bean name="txManager" id="txManager" class="com.springsource.open.db.ChainedTransactionManager">
  <property name="transactionManagers">
  <list>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource1" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource2" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource3" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource4" />
   </bean>
  </list>
  </property>
  </bean>

• Dans l'environnement de production avec Jboss, pas de soucis, j'utilise le transaction manager JTA de spring (org.springframework.transaction.jta.JtaTransactionManager). Voici l'extrait de la conf Spring correspondante :
  

   <!-- transaction manager JTA -->
  <bean name="txManager" class="org.springframework.transaction.jta.JtaTransactionManager" />
  
  
  <!-- aop pour la gestion des transactions -->
  <tx:annotation-driven transaction-manager="txManager" />