Introduction

Le développement d’applications pour terminaux mobiles (iPhone, iPad, Android, Blackberry, Windows Phone, Nokia Symbian, Samsung Bada…) se heurte à la fragmentation des technologies de développements: environnement iOS/Objective-C pour l’iPhone et l’iPad, SDK Java spécifique pour Android, J2ME pour Symbian, etc.

Deux approches possibles lorsque l’on débute un projet d’application ciblant plusieurs de ces plateformes sont de développer une application pour chacune d’elle, ou de développer un site Web compatible.

Dans le premier cas, l’inconvénient concerne bien évidemment le coût des développements. Dans le deuxième, on sera limité en richesse de l’application par les possibilités du Web.

Ce fut l’objet d’un précédent article sur notre blog: http://blog.octo.com/debat-web-apps-vs-natif/.

Entre ces deux approches se situe une offre assez fournie de solutions de développement multi-plateforme, proposées par des éditeurs proposant leurs propres plateformes d’exécution et leurs outils de développement.

Parmi celles-ci, nous nous sommes concentrés dans cet article sur PhoneGap et Titanium Mobile, qui sont aujourd’hui parmi les plus abouties et sont représentatives des deux principales approches de développement multi-plateforme: l’utilisation des moteurs de rendus Web pour PhoneGap, et la translation de code source vers la plateforme cible pour Titanium.

Présentation des solutions

PhoneGap

Nitobi, l’éditeur de PhoneGap, a annoncé son rachat par Adobe le 3 octobre 2011. Cela confirme l’intérêt que l’on peut avoir envers cette solution, même si ce rachat surprise apporte une certaine incertitude sur l’avenir de PhoneGap.
PhoneGap est un outil open-source, et devrait d’ailleurs rejoindre la fondation Apache.
Le principe de PhoneGap est de fournir des API JavaScript aux navigateurs Web standards, permettant d’appeler des fonctionnalités natives non disponibles autrement: accéder à l’appareil photo, à l’accéléromètre, au système de fichiers…
Cela nécessite d’embarquer le code source HTML/CSS/JS dans une application native, grâce au composant permettant d’inclure une vue Web dans une application, disponible dans chaque SDK.

Titanium

Développé par Appcelerator qui vend du support et des formations sur Titanium, c’est également une solution libre.

Le principe de Titanium est de fournir une machine virtuelle JavaScript permettant d’accéder au système natif, et ainsi de développer des applications natives mais en JavaScript. C’est la promesse d’applications plus réactives et à l’expérience utilisateur plus proche du natif que celles basées sur des pages Web, comme PhoneGap.

Points communs

L’intérêt principal de l’utilisation d’une plateforme de développement multi-plateforme comme PhoneGap et Titanium Mobile réside en 2 points:

• pouvoir déployer l’application sur les magasins (AppStore, Android Market…) afin de bénéficier de ce canal de distribution et de communication. Cela est réellement assuré par ces deux outils;
• réduire les coûts de développements en mutualisant du code. Cela est assuré par ces deux outils à condition de bien les utiliser et de limiter la part des développements spécifiques à chaque plateforme et donc de se limiter aux fonctionnalités supportées « out of the box ». On rogne donc sur l’expérience utilisateur et la richesse fonctionnelle.

Comparaison

Plateformes supportées

Notre avis:

En pratique, les développements PhoneGap nécessitent des adaptations pour chaque plateforme, dont les capacités et l’expérience utilisateurs diffèrent fortement. Etant donné l’état du marché (avec l’écrasante domination de l’iPhone, d’Android et de Blackberry), on ciblera généralement ces 3 plateformes uniquement. C’est ce que l’on a pu constater dans la plupart des cas où une entreprise ciblait initialement toutes les plateformes: l’augmentation du coût pour les supporter au fur et à mesure rendait cela impossible et finalement, au maximum, seules les 3 ou 4 principales étaient vraiment adressées.
Concernant Titanium, le support de Blackberry est encore récent et disponible uniquement sous Windows, alors que la plupart des développeurs mobiles sont sous Mac (pour l’iPhone). Cela est dommage mais on espère que ce sera bientôt résolu.
Pour cibler tous les terminaux mobiles à moindre coût, le meilleur moyen reste de réaliser un site Web simple, qui permet de diffuser de l’information mais ne permet ni de fournir des fonctionnalités avancées (appareil photo, etc.), ni de proposer une expérience utilisateur riche, ni d’être visible sur l’AppStore.

Richesse de la plateforme

Notre avis:

Titanium est indéniablement plus riche fonctionnellement et fournira une apparence plus proche du natif, ce qui est en général l’objectif des concepteurs d’applications.
PhoneGap est dans l’absolu plus limité en terme de fonctionnalités, et on doit concevoir les écrans comme des pages Web et non des écrans natifs. C’est d’ailleurs une erreur que l’on retrouve souvent sur les projets mobiles utilisant des technologies Web: il ne faut surtout pas tenter de reproduire des comportements natifs, mais plutôt viser des comportements Web performants.
Les deux plateformes sont extensibles, Titanium plus facilement que PhoneGap, mais nous déconseillons globalement d’aller dans cette direction car cela devient très coûteux à maintenir (on estime en général à 20% la part maximale de code spécifique tolérable), et nécessite en outre encore plus de compétences que de faire des applications natives spécifiques à chaque plateforme.

Plateforme de développement

Notre avis:

On remarque l’utilisation de plus en plus large de JavaScript, un langage décrié par ses côtés peu structuré et trop tolérant. Il est nécessaire, pour développer ce type d’applications, de se former profondément à JavaScript et de connaître les design patterns de structuration/modularisation du code dans ce langage, qui existent mais sont souvent mal connus des développeurs.
C’est d’ailleurs le principal objet de la formation à Titanium donnée par leur expert Kevin Whinnery, que nous avons eu la chance de suivre à l’UpdateConf 2011.
De manière globale, l’environnement de développement de Titanium est mieux intégré et plus documenté.

Productivité des développement

Notre avis:

Titanium fournit un environnement de développement « clé en main » et performant, là où PhoneGap nécessite d’installer et configurer soi-même plusieurs environnements.
La productivité est clairement côté Titanium aujourd’hui.

Gestion des déploiements

Notre avis:

L’automatisation du packaging et de la livraison des applications sur les différentes plateformes (magasins publics type AppStore ou comptes privés « in house ») est un véritable enjeu concernant la productivité des développements et le coût global d’un projet. C’est d’ailleurs pour cela qu’OCTO propose Appaloosa, qui facilite la distribution en entreprise d’applications mobiles dans des stores privés.
L’outil PhoneGap Build (compatible uniquement avec les applications PhoneGap), qui vient d’être ouvert en version finale, était une véritable nécessité.

Synthèse

Les points forts de PhoneGap sont donc aujourd’hui son support de plus de 6 plateformes, et le fait qu’il utilise au maximum les technologies standards du Web.
Ses points faibles concernent ses limitations fonctionnelles et sa moindre richesse d’IHM du fait qu’il n’utilise pas les composants natifs, ainsi que son manque d’outillage de développement.

Les points forts de Titanium sont sa richesse fonctionnelle et graphique, ainsi que la productivité de son environnement de développement.
Son point faible concerne le peu de plateformes supportées.

Conclusion

En conclusion, on a pu voir que Titanium est globalement plus productif et fournit plus de fonctionnalités que PhoneGap dans le but de développer des applications mobiles multi-plateformes. On le préfèrera en général, si l’on ne doit pas supporter plus que iOS + Android + BlackBerry.
Au-delà du choix de l’outil, notre conseil majeur restera d’utiliser les outils pour ce qu’ils savent faire, et éviter de « tordre » leur usage pour leur faire faire autre chose ou de manière différente. Cela s’approche des problématiques bien connues d’utilisation trop personnalisée de progiciels, qui rend rapidement très coûteuse la moindre évolution.

Et d’ors et déjà, le choix de la technologie de développement multi-plateformes doit aussi se faire par-rapport aux applications Web HTML5 qui apportent de plus en plus de fonctionnalités et viennent sérieusement concurrencer les approches natives et hybrides, et les solutions Web existantes comme les moteurs de rendus (BkRender, Wokup) et les nombreux frameworks Web pour mobiles (par exemple Sencha Touch.

La problématique du développement mobile multi-plateforme est loin d’être encore résolue, et nul doute que nous reviendrons encore dessus rapidement car c’est un enjeu fort pour les entreprises aujourd’hui.

Suggestion d'articles :

1. Applications natives ou web HTML5 pour mon mobile ?
2. Ce que jQuery Mobile nous apprend sur le Web Mobile
3. Le terminal mobile et usabilité ou comment réveiller le canal web et les applications desktop

En présentant les tests fonctionnels automatisés chez un client la semaine dernière, plusieurs questions ont été soulevées. La principale était celle-ci:

- Pourquoi écrire ces tests FitNesse/GreenPepper alors que j’ai déjà des tests unitaires JUnit qui couvrent la même fonctionnalité ?

La question est justifiée. Voici quelques éléments de réponse, tirés de nos échanges sur les mailing-lists OCTO…

Des tests différents pour des acteurs différents

Tout d’abord, parce que les tests unitaires et les tests fonctionnels sont écrits par des personnes différentes.

Les tests unitaires sont écrit et utilisés par les développeurs. Ils sont codés dans le même langage que l’application testée, leur exécution est rapide, ils sont régulièrement refactorés, modularisés, etc. Ils sont non négociables (!) et doivent tester l’intégralité du code applicatif.

Mais ces tests unitaires ne sont pas appréhendables par les fonctionnels (client, MOA, AMOA, etc.)

Et c’est là qu’interviennent les tests fonctionnels automatisés: ils sont écrits par les fonctionnels et sont « lisibles par un humain ».

Finalement, « s’il y a des doublons, c’est une coïncidence, en quelque sorte :) ».

Idée: On a vraiment des doublons, lorsque, sur un projet, ce sont les développeurs qui font aussi les tests fonctionnels et qu’ils sont les seuls à les lire ou les mettre à jour. Dans ce cas, il est intéressant de se poser la question de l’utilité de ces tests: il y a fort à parier qu’on pourrait se contenter de tests développeurs JUnit.

Des différences de granularité

Les tests unitaires et les tests fonctionnels sont également différents dans leur granularité: les tests unitaires sont « boite blanche » (c’est à dire qu’ils testent le code… « ils regardent sous le capot »)…

alors que les tests fonctionnels sont « boite noire » (ils testent l’application de bout en bout). Si les tests se ressemblent trop dans leur structure ou leurs assertions, c’est probablement que leur granularité est à retravailler.

Idée 1: On rencontre sur beaucoup de projet des tests « boite noire » développés avec JUnit: ce sont les tests d’intégration. Ils passent par plusieurs services, DAOs, par la base de données, etc. Ces tests sont utiles car ils permettent de tester la communication entre les couches, la configuration, etc. Mais ils sont généralement lents à exécuter. Il faut donc les utiliser avec précaution !
Deux raisons possibles à l’utilisation massive de ces tests d’intégration: ou bien le projet ne dispose pas d’outils dédiés aux tests « boite noire » (FitNesse, GreenPepper, Selenium, etc.), ou bien ceci est dû à une méconnaissance des outils de Mock et des pratiques associées. Quelle qu’en soit la cause, limiter le nombre de ces tests « d’intégration » au profit de tests plus « unitaires » permet de réduire considérablement la durée globale d’exécution des tests. Et avoir des tests rapides, cela permet de les exécuter souvent, et donc de détecter les anomalies plus tôt.

Idée 2: Séparer les tests unitaires (rapides) des tests d’intégration (lents) est une bonne pratique. Ceci peut se faire par convention de nommage des classes de test, répertoires séparés, annotations ou autre. Une fois les tests JUnit catégorisés, des outils comme Maven permettent de définir des règles du type « les tests unitaires se lancent sur le poste développeur, les tests d’intégration s’exécutent uniquement sur le serveur d’intégration continue ». Cette séparation permet d’éviter le travers (récurrent) suivant: « les tests sont trop longs, je ne les exécute pas localement et les délègue à l’intégration continue ».

Des objectifs différents et complémentaires

Enfin, et c’est le point le plus important, les tests unitaires et les tests fonctionnels automatisés poursuivent des objectifs complémentaires:

• Les tests unitaires
  • favorisent la collaboration entre les développeurs
  • améliorent la productivité des développements
  • assurent un harnais de test permettant le refactoring « sans stress »
• Les tests fonctionnels automatisés, quant à eux
  • permettent de spécifier le produit en un endroit/format unique en détaillant les subtilités qui n’apparaissent pas dans les simples User Stories, avec des données de test qui ont un sens « métier »
  • favorisent la communication entre le client et l’équipe de développement
  • représentent un harnais de test garantissant la non-régression fonctionnelle

A retenir

Nos projets intègrent plusieurs types de tests.
Parmi eux, les tests unitaires et les tests fonctionnels couvrent les mêmes fonctionnalités, il est donc normal d’avoir le sentiment qu’ils se recoupent parfois.

Cependant, ils sont écrits par des personnes différentes, avec des niveaux de granularité différents et, surtout, des objectifs complémentaires:
- Faire bien le produit, pour les uns
- Faire le bon produit, pour les autres

En revanche, c’est au niveau des tests unitaires ou d’intégration qu’il est important de commencer la chasse aux doublons ! La durée de votre build ne s’en portera que mieux!

Un grand merci à Ismaël Héry, Julien Jakubowski, Eric Pantera, Arnaud Huon, Rémy-Christophe Schermesser, Christophe Thibault, Henri Tremblay, Maria-Dolores Manzanedo, Sylvain Fagnent, Bertrand Paquet, Sylvain Mazaleyrat et Florian Marin pour ces échanges et retours d’expérience enrichissants !

Suggestion d'articles :

1. Tests par propriétés
2. Rails += Tests
3. FitNesse, Maven, Hudson : pour une intégration continue des tests d’acceptance

A moins de s’être limité à dessiner des ronds et des carrés avec Silverlight, vous avez sans doute déjà tenté d’utiliser un des templates de projets du Silverlight Toolkit permettant de faire des tests unitaires pour vos applications RIA! Plein de bonne volonté, vous vous êtes heurtés aux multiples inconvénients de cette solution :

• Framework de tests spécifique à Silverlight
• Obligation de lancer une application « conteneur » pour lancer vos tests
• Usabilité plus que discutable de cette même application
• Impossibilité d’utiliser une métrique comme la couverture de code
• et j’en passe…

N’abandonnez pas encore ! Je vous proposer ici une solution pour venir à bout de ces limitations… plus d’ excuses, vous pourrez tout tester …

la suite par ici en anglais…

Suggestion d'articles :

1. Flex vs Silverlight
2. Formation Silverlight Tour à Paris les 19,20 et 21 janvier
3. Formation Silverlight Tour à Paris – 28, 29, 30 Avril

Uniformiser vos environnements de développement – Gagner en productivité

Marre des merges galères pour cause de formateurs différents ?

Ce tip & trick est pour vous !

Comment créer ce Zip ?

Comment utiliser ce Zip ?

Que peut-on y mettre ?

Voici ce que je positionne en général dans ce Zip :

Suggestion d'articles :

1. Environnement de développement Maven/Eclipse pour GWT 1.7
2. 60 minutes pour créer un plugin Text Editor pour Eclipse

Le grand oubli dans l’industrialisation des développements est la base de données, cette chose monolithique et statique qui n’évolue pas aussi vite et aussi aisément que le code. Au même titre que l’intégration continue et les systèmes de gestion de version pour le code source, il existe des outils permettant de fluidifier et d’automatiser le travail autour du schéma physique des données. Travailler avec ces outils permet de compléter une démarche Agile en permettant une réactivité forte face aux changements.

Une première partie de cet article concernera les principes et pratiques autour de ces outils (partie « boss compliant »). La deuxième est orientée technique (partie « geek aware »).

Principes directeurs

Dans son article paru en 2003 intitulé « Evolutionary Database Design », Martin Fowler pose les principes du design évolutif de base de données. Les points clés en sont :

• La base de données évolue en même temps que le code ;
• Il faut donc tester en continu la base de données pour permettre un refactoring sans conséquence, comme on le fait avec le code source ;
• Il faut outiller les processus autour de la base de données afin d’améliorer la productivité des développements et leur industrialisation.

Les outils existants reposent sur les principes suivants :

• Un schéma doit pouvoir être détruit et recréé de manière répétable ;
• La version du schéma doit être identifiable ;
• La montée et la descente de version doivent être automatisées ;
• Les changements appliqués doivent être connus ;
• Un changement doit pouvoir être défait ou annulé ;
• Un changement précédemment appliqué ne doit pas être modifié mais un nouveau changement doit être créé.

Principes techniques

Sur le plan technique, le fonctionnement des outils de migration est simple. Ils se basent sur une table contenant la version de la base de données. La liste des scripts exécutés est conservée ainsi qu’une empreinte de chaque script afin de détecter une altération d’un script déjà exécuté.

A chaque lancement, l’outil de migration compare la version de la base et les scripts existants  et propose la mise à jour le cas échéant.

Il est également possible de « descendre de version » le schéma (fonctionnalité disponible dans quasiment tous les outils). Il s’agit de remettre la base de données dans un état cohérent. Deux cas d’usage :

• développement d’une nouvelle fonctionnalité : il est ainsi possible de créer un script et de l’exécuter plusieurs fois (montée de version, test, modification, descente, puis nouvelle montée de version). La descente de version permet ainsi de faire revenir la base de données dans l’état précédent ;
• Ré-alignement automatique du schéma avec le code quand la version de la base de données n’est plus la bonne. Ce cas intervient quand il faut corriger un bug sur la version de production ou au passage à une autre branche de développement, ou encore quand un script a été exécuté puis modifié.

Même si la descente de version est utile, elle a néanmoins deux inconvénients. Le premier est que les instructions de descente doivent être écrites à la main. Les outils les plus simples fonctionnent sur le principe où chaque script contient une partie montée de version et une partie descente (voir l’exemple plus bas avec MyBatis). Seul Liquibase est capable de générer les instructions de descente de version grâce à son DSL.

Le deuxième inconvénient est que certaines montées de version ne sont pas réversibles (suppression de table ou de données). Dans ce cas, la descente ne sera possible que jusqu’à la version incluant ce type de modification. L’alternative est de recréer le schéma de zéro, une fonctionnalité que tous les outils proposent et qui est en fin de compte très rapide.

Bonnes pratiques

Les bonnes pratiques poussées par ces outils sont :

• Scripts (SQL ou XML pour Liquibase) stockés avec le code source
• Une base de données par développeur (réaliste quand la gestion de la DB est automatisée, hors problème de coût de licence) ;
• Une base de données commune à l’équipe qui représente l’état complet et stable ;
• L’intégration continue déroule l’ensemble des scripts à chaque livraison ;
• Un script qui a déjà pu être exécuté ne doit plus être modifié. On risque sinon de désynchroniser les scripts et le schéma  La livraison d’un nouveau script est nécessaire dans ce cas. Ce script est un refactoring du précédent. La seule exception est un script buggé qui provoque la perte de la donnée. Il ne faut donc pas que ce script atteigne les autres environnements.

Les outils existants

Liquibase : puissant mais complexe

Liquibase est le plus connu des outils de migration de base de données. Il se base sur les patterns décrits dans le livre « Refactoring database ». À ce titre, il est conçu autour d’une approche théorique par pattern de refactoring.

Le noyau de Liquibase est son DSL basé sur XML qui a les avantages :

• d’être compatible avec plusieurs moteurs SQL ;
• de donner une sémantique aux opérations (on écrira un <renameColumn> plutôt qu’un alter table) ;
• de générer automatique des instructions de rollback (par exemple, un <createColumn> sera compensé par un <dropColumn>).

Liquibase est complet. Il s’intègre à Maven, Grails, Spring et Hibernate et supporte la génération de documentation ou encore la création d’un diff entre schémas.

L’inconvénient principal de Liquibase est une certaine complexité qui ne se retrouve pas dans les autres outils (XML, notion de changelog et de changeset, versionning sur id/auteur/chemin). La courbe d’apprentissage est donc plus élevée que les autres outils se basant purement sur du SQL.

Exemple de changeSet Liquibase :

<changeSet id="1" author="bob">
 <createTable tableName="department">
  <column name="id" type="int">
   <constraints primaryKey="true" nullable="false"/>
  </column>
  <column name="name" type="varchar(50)"/>
 </createTable>
</changeSet>

Les pragmatiques

D’autres outils ne vont pas aussi loin que Liquibase en termes de fonctionnalités et d’abstraction mais leur approche est pragmatique et plus simple. Ils visent avant tout à automatiser la gestion des scripts SQL. Les principaux sont MyBatis Schema Migration, DbMaintain et C5 DB Migration.

Le principe de ces outils est assez simple et consiste à lancer une série de scripts stockés dans une arborescence répartie en version. Les actions sont tracées ce qui permet de connaître l’état du schéma.

Exemple d’arborescence organisée pour DbMaintain :

scripts/01_v1.0/01_products_and_orders.sql
                02_users.sql
        02_v1.1/01_add_barcode_column.sql
                02_drop_itemcode_column.sql

Le schéma de base de données est mis à jour en exécutant :

dbmaintain.sh update chemin/vers/les/scripts

Dans le cas de MyBatis, les instructions de montée et de descente de version sont écrites dans le même script SQL. Exemple :

--// create product table
CREATE TABLE PRODUCT (ID INT, NAME VARCHAR(255));

--//@UNDO
DROP TABLE PRODUCT;

Conclusion

Les outils de migration de base de données permettent une meilleure productivité en levant certaines barrières au changement du schéma des données et ils rendent l’industrialisation accessible.

Les points clés à retenir sont :

• Les outils de migration de bases de données nous permettent de gagner en efficacité lors de la manipulation du schéma de la base de données ;
• Ces outils fiabilisent les traitements en les automatisant et en les intégrants à l’usine de développement ;
• Ces outils apportent de bonnes pratiques permettant un travail en équipe plus efficace ;
• Ces outils sont disponibles, simples à mettre en place et OpenSource.

Par extension, on peut imaginer qu’une application puisse se mettre à jour d’elle-même. En effet, il s’agirait de permettre à l’application de lancer les migrations de schémas quand elle démarre. Cette fonctionnalité réduit le temps de mise en production en supprimant l’étape de passage des scripts par les DBA. Liquibase propose déjà cette fonctionnalité.

Suggestion d'articles :

1. Outiller un audit de base de données
2. Industrialisation des développements Android
3. Une base de données purement fonctionnelle

Ce n’est pas la nouveauté de l’année mais Swing, bien que présent en entreprise, n’évolue que très peu. Le kit de développement offre nativement toujours aussi peu de composants évolués (tableaux triables…) même s’il faut avouer que certaines librairies commerciales compensent à merveille ces manques. Les APIs et le développement Swing est toujours aussi verbeux et finalement assez peu productif (de mon humble avis). Et ce n’est malheureusement pas les quelques JSR en stand by qui vont y changer quoique ce soit : Beans Binding est au statut inactif, Beans Validation, drafté en 2008 n’est toujours pas inclus dans le JDK (peut-être pour la version 7 ?) et la JSR 296 (qui définit au travers de 4 callback le cycle de vie standard d’une application) ne représente pas non plus la plus importante des améliorations qu’ait connu un framework (si si je vous jure j’aime Swing…)

Alors il est nécessaire de compenser ces manques…

A côté de cela, je suis un fan d’AOP depuis les premières versions d’AspectJ. Je trouve ce paradigme de développement d’une rare élégance et il est aujourd’hui suffisamment outillé (intégration aux IDEs, intégration à Maven…) pour pouvoir parsemer quelques aspects de ci de là.

Voilà donc quelques problématiques Swing récurrentes qu’il est possible d’outiller avec AOP.

Injection de services

L’objectif est simple : reproduire l’IOC au niveau de l’IHM et notamment dans les actions (en fait les ActionListener branchés sur les boutons). Dès lors on souhaite injecter une implémentation du service (définie par exemple comme un bean Spring) sur toute propriété qui aurait l’annotation custom @Inject.

Par exemple, injecter le service myService dans l’action suivante (on peut faire mieux mais dans cet exemple, le bean est injecté sur la base du nom et non du type) :

1
2
3
4
5
6

public class MyActionListener implements ActionListener{
	@Inject
	private MyService myService
 
	...
}

L’aspect suivant permet l’injection du Bean Spring nommé myService

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

public aspect SpringInjectAspect {
    pointcut fieldsInjection() : within(com.mypackage..*)
	    execution(public void java.awt.event.ActionListener+.actionPerformed(..));
 
    before() : fieldsInjection() {
        Class currentClass = thisJoinPoint.getThis().getClass();
        Object currentObject = thisJoinPoint.getThis();
        //to inject bean spring even in super class property
        while (!currentClass.equals(ActionListener.class)) {
             injectBean(currentClass, currentObject);
             //for te next step
             currentClass = currentClass.getSuperclass();
        }
    }
 
    private void injectBean(Class currentClass, Object currentObject) {
        Field[] fields = currentClass.getDeclaredFields();
 
        for (int i = 0; i < fields.length; i++) {
            Annotation associatedAnnotation = fields[i].getAnnotation(Inject.class);
            if (associatedAnnotation != null) {
                try {
					//get the bean by the field name
                    Object implementationObject = SpringHelper.getApplicationContext().getBean(
                            fields[i].getName());
                    try {
                        fields[i].setAccessible(true);
                        fields[i].set(currentObject, implementationObject);
                    }
                    catch (IllegalArgumentException e) {
                       ... do what you need to do
                }
                catch (NoSuchBeanDefinitionException e) {
					//log the fact the asked bean do not exist
                    throw e;
                }
            }
        }
    }
}

Outillage du Binding (notamment dans le cadre d’une utilisation avec jGoodies)

L’utilisation d’un mécanisme de binding type jGoodies peut-être intéressant mais quoiqu’il en soit, il passe souvent par l’écriture de code supplémentaire notamment dans les setter :

1
2
3
4
5

public void setBooleanValue(boolean newValue) {
  boolean oldValue = booleanValue;
  booleanValue = newValue;
  changeSupport.firePropertyChange("booleanValue", oldValue, newValue);
 }

Dans cet exemple, il est nécessaire de rajouter dans chaque setter, l’appel à la méthode fireProperyChange en précisant nouvelle et ancienne valeur et surtout le nom de la propriété (ce qui bien entendu sera source d’erreur puisque ce code sera copié-collé de setter en setter…).

Là encore AOP nous aide en permettant d’enrichir un setter « classique » (i.e. qui ne fait que mettre à jour la propriété). Ainsi le setter se définit classiquement :

1
2
3

public void setBooleanValue(boolean newValue) {
  booleanValue = newValue;
 }

et l’aspect suivant se charge du reste :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public aspect jGoodiesBindingAspect {
    pointcut propertyEnhancement() : within(com.mypackage..*)
		&& execution (public void com.jgoodies.binding.beans.Model+.set*(..))
 
    void around() : propertyEnhancement() {
        Object[] args = thisJoinPoint.getArgs();
        String propertyName = thisJoinPoint.getSignature().getName().substring(3);
 
        Object oldValue = null;
        try {
            Method propertyGetter = thisJoinPoint.getThis().getClass()
                    .getMethod("get" + propertyName);
            oldValue = propertyGetter.invoke(thisJoinPoint.getThis());
            Object newValue = args[0];
 
            proceed();
            // if no error occurs
            Method firePropertyChangeMethod = com.jgoodies.binding.beans.Model.class.getDeclaredMethod(
                    "firePropertyChange", String.class, Object.class, Object.class);
            firePropertyChangeMethod.setAccessible(true);
            propertyName = org.apache.commons.lang.StringUtils.uncapitalize(propertyName);
            firePropertyChangeMethod.invoke(thisJoinPoint.getThis(), propertyName, oldValue, newValue);
        }
        catch (NoSuchMethodException
			...do what you need to do
    }
}

Dans ce cas, le pointcut est défini sur toutes les méthodes qui commencent par set de n’importe quelle classe héritant de com.jgoodies....Model.

Habilitation sur la fonction et la donnée au niveau de l’IHM

Il s’agit là encore d’une problématique hyper classique : comment rendre « inaccessible » (comprendre non modifiable, non utilisable) des fonctions (des boutons, des menus…) d’une IHM Swing. On parle donc ici de « griser » (ie. myComponent.setEnabled(...)) les composants graphiques soumis à une habilitation.

La première étape consiste à définir une annotation permettant de définir les rôles sur un JComponent. Rien de génial là dedans. Il est possible de l’utiliser ainsi et de définir que myComboBox est accessible pour les utilisateurs ayant les rôles « consultation-level-1″ et « consultation-level-2″

1
2

@Authorize(roles={"consultation-level-1, consultation-level-2"})
private JComponent myComboBox;

L’aspect suivant prend en charge le « grisage/dégrisage » des widgets graphiques suivant le rôle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public aspect AuthorizationAspect {
    public pointcut authorized_gui() :  within(com.mypackage..*)
        && set(@Authorize * *..*.*);
 
    after() : authorized_gui() {
        String pointCutKind = thisJoinPoint.getKind();
        if (JoinPoint.FIELD_SET.equals(pointCutKind)) {
            java.lang.reflect.Field field = ((FieldSignature) thisJoinPoint.getSignature()).getField();
            try {
                field.setAccessible(true);
                Object theField = field.get(thisJoinPoint.getThis());
                if (theField instanceof JComponent) {
                    Authorize authorization = field.getAnnotation(Authorize.class);
                    String[] roles = authorization.roles();
					//ask your security context holder the role the user have
                    ((JComponent) theField).setEnabled(SecurityContextHolder.getInstance()
                            .isUserInRole(roles));
                }
            }
            catch (IllegalAccessException e) {
                throw new TechnicalException(e);
            }
        }
    }
}

La subtilité dans cet aspect réside dans le set(@Authorize * *..*.*) qui permet d’attraper l’instanciation (et non pas l’appel au constructeur) de toutes les propriétés qui ont l’annotation spécifiée.

Voilà donc quelques problématiques qu’il est possible de régler de façon assez simple, élégante et peu intrusive sur le code grâce à AOP. D’autres utilisations existent. La plus courante est certainement de gérer de façon automatique toutes les exceptions non typées – qui dans le cas d’une IHM donne typiquement lieu à l’affichage (dans une popup ou non) d’un message du type « une erreur a eu lieu, veuillez contacter votre administrateur ». D’autres utilisations encore peu répandues visent à valider certaines règles de codage propre à votre projet (via l’utilisation de declare warning et declare error).

Et vous, voyez vous d’autres problématiques qu’il serait intéressant de gérer de la sorte?

Suggestion d'articles :

1. Testabilité des IHM : commençons (déjà) par Swing!

[MAJ 17/03] Les slides de la session sont désormais disponibles à la fin de cet article.

Nous serons présent le 17 mars 2010 au salon Solutions Linux. J’aurai le plaisir d’y co-animer une session avec Benoît Lafontaine sur l’industrialisation des développements Java.

Qu’entendons nous par industrialisation ? Principalement 3 activités :

• l’intégration continue. Nous commencerons par à un retour sur l’état de l’art de cette pratique agile aujourd’hui largement démocratisée, puis nous verrons comment faire face aux nouveaux défis rencontrés : réduction du temps de build, constructions d’applications profilées par environnement, build distribué ou encore build incassable.
• le développement piloté par les tests. Depuis 4 ans, les outils de tests fonctionnels automatisés comme FitNesse s’efforcent de remettre le besoin et les maitrises d’ouvrage au coeur du développement logiciel. Nous ferons le bilan sur ces outils et balayerons les perspectives offertes par de nouvelles approches et de nouveaux types d’outils (BDD).
• mesure continue de la qualité. Nous verrons comment utiliser la mesure de la qualité comme une dynamique d’amélioration continue et comment en éviter les dérives comme le « flicage ».

Voici les slides que nous avons présenté : http://www.slideshare.net/cblavier/industrialisation-java-v10

Suggestion d'articles :

1. Mon salon … linux (1/2)
2. Mon salon … linux (2/2)
3. Performances de build Java sous Linux ?

Octo a récemment participé à la réalisation de l’application iNomineo pour iPhone (cf  OCTO Technology accompagne Generali sur l’iPhone ) :

Pourquoi avons nous mis en place une usine de développement (UDD) suite à ce projet ? A première vue, cela soulève plusieurs questions :

• La mise en place d’une UDD relève d’une problématique d’industrialisation : comment rendre plus productif un process que l’on maîtrise. Alors qu’un projet iPhone évoque plutôt l’innovation : un langage peu connu, de nouveaux outils, une nouvelle plateforme.

• Une UDD a pour vocation de simplifier le travail d’intégration entre les différents développeurs : plus ceux-ci sont nombreux, plus l’UDD se révèle payante. Or nous n’étions que 3 développeurs sur ce projet, on aurait tendance à penser que l’on peut gérer cet effort d’intégration « à la main ».

• L’UDD a également pour rôle d’automatiser l’exécution des tests, or une des particularités d’une application iPhone c’est la prédominance de l’interface graphique (réputée couteuse et compliquée à tester), de plus quels outils peut-on utiliser ?

• Pour finir, l’iPhone souffre encore de l’image du jeune étudiant faisant fortune sur l’appstore : ce type de projet véhicule pour certains une image d’amateurisme, « c’est un travail à confier à un stagiaire ».

Pourtant l’expérience nous a montré qu’une UDD et la pratique des tests unitaires apportent des solutions à des problèmes récurrents sur le projet.

De plus, la mise en place d’une UDD avec une couverture de test conséquente et les métriques associées sont un moyen d’apporter un gage de qualité et de professionnalisme à un projet iPhone.

Dans cet article, nous couvrirons les raisons concrètes qui nous ont poussé à le faire, et comment nous y sommes parvenus.

Dans un prochain article, nous verrons quelles pratiques de test mettre en place sur un projet iPhone (les outils, les méthodes, les bonnes pratiques).

Pourquoi a-t-on mis en place l’UDD sur notre projet

Ce projet a été l’occasion pour moi de m’initier au développement iPhone. Au démarrage le ticket d’entrée paraît très élevé : il faut découvrir une nouvelle plateforme (un téléphone mobile), un nouvel environnement (Mac quand on vient de PC), un nouveau langage (Objective-C), de nouveaux outils (Xcode, interface builder, instruments), les frameworks Cocoa (UIKit, CoreGraphics, CoreAnimation, etc).

Les questions d’industrialisation auxquelles on est habitué lorsque l’on vient du monde Java paraissent bien lointaines.

Mais une des particularités d’un projet iPhone, c’est que ces difficultés techniques sont mitigées par la qualité de l’environnement de développement : les outils et les frameworks bénéficient de plus de 20 ans de développements par Apple et NeXT et sont donc très matures. L’architecture des applications iPhone s’appuie largement sur des design patterns éprouvés.

L’objective-C, dont la syntaxe peut rebuter au premier abord, se révèle être un langage objet très structuré et agréable à manipuler.

Néanmoins, nous nous sommes vite aperçus que les problèmes propres au développement informatique en équipe sont toujours présents.

Il s’agit de problèmes :

• d’organisation du travail en équipe : douleurs d’intégration des sources entre les différents développeurs
• de qualité du code : douleurs lors de la recette et du refactoring
• et d’environnements : douleurs de gestion des différentes versions sur chaque poste de développement lors du déploiement sur un iPhone

Arrivé à ce stade, le risque est d’accepter la douleur : en effet, on a appris à vivre avec ces contraintes pendant les premiers temps du projet, et on hésite à investir dans ce que l’on ne ressent plus comme un frein.

A cela se rajoute le fait qu’à court terme, on a tendance à vouloir faire avancer le projet (bien plus palpitant surtout sur une plateforme « fun ») qu’industrialiser le développement (pas toujours très excitant comme perspective au premier abord).

Nous avons donc travaillé à mettre en place une usine de développement qui vise à adresser les problèmes mentionnés ci-dessus.

Nous allons aborder dans cet article une série de cas concrets, les problèmes qui en découlent, et comment les résoudre grâce à la mise en place d’une usine de développement.

I) Rationaliser le déploiement : Une version stable à la demande

Mise en situation :

Chaque développeur travaille sur le trunk du gestionnaire de source : à un instant t personne n’a de version stable sur son poste. De plus, il n’existe pas de version de référence de l’application. Ceci entraine 2 situations assez inconfortables :

• Lorsque le chef de projet ou un manager souhaite voir l’avancement des développements, le même scénario se répète : on commit tous « en vitesse » et comme on peut, on intègre à coup de commentaires dans le code et on déploie une version de démo plus ou moins stable sur son iPhone (« tout marche sauf cet écran qui marchait hier, mais là on bosse dessus »). Ou pire, on lui demande de repasser le lendemain pour nous laisser le temps de figer une version stable.

• Lors de la phase de recette, en fonction du poste à partir duquel on déploie, les bugs ne sont parfois pas les mêmes !

Douleur :

Incapacité à fournir rapidement une version stable de l’application.

Cause :

L’omni-environnement : chaque poste de développeur est à la fois l’environnement de développement, d’intégration et de recette.

Solution :

Automatiser la constitution d’une version issue directement du gestionnaire de sources. Cette version ne sera pas compilée en configuration Debug, mais en configuration Release, ce qui permettra de se rapprocher d’une situation de livraison.

La mise en place d’une usine de développement permet la distinction entre l’environnement de développement (le mac de chaque développeur), l’environnement d’intégration (un mac sur lequel tourne l’UDD) et l’environnement de recette (le poste mac ou PC, sur lequel on dépose l’application qui est transférée dans iTunes).

Pré-requis :

• Un projet Xcode sur un repository SVN (http://iphonedevelopment.blogspot.com/2009/03/version-control-is-your-friend.html)

• Un projet configuré pour pouvoir être déployé sur un iPhone (http://mobiforge.com/developing/story/deploying-iphone-apps-real-devices)

• Mise en place de Hudson (http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson)

Configuration de l’UDD :

Hudson ne prend pas en charge les projets Xcode par défaut. On va donc créer un script shell qui se chargera :

• de compiler le projet
• d’historiser un zip de l’application dans un répertoire build-history
• de déposer l’application compilée (.app) sur le bureau.

Pour cela, il faut créer un job de type « free style » dans Hudson et ajouter au build une étape « Exécuter un script shell »

Le SDK iPhone met à disposition une commande « xcodebuild » qui permet de lancer un build via ligne de commande.

Cette commande prend en paramètre le nom de la target à builder, la configuration à utiliser et le sdk pour lequel on build.

On utilisera la target par défaut en configuration « release » avec pour cible un device iphone 3.0

xcodebuild -target  “maTarget” -configuration "Release" -sdk iphoneos3.0

P.S : Assurez-vous :

- que le fichier build.sh a les droits nécessaires pour être exécuté (chmod 755 build.sh)

- d’ignorer le répertoire « build » du projet lors des commit: ‘svn propset svn:ignore build .’

Axes d’améliorations :

• En plus de déposer l’application sur le bureau, on pourrait automatiser l’installation de la nouvelle version dans iTunes.

• Il semble possible de se baser sur le versionnement du bundle de l’application, pour que iTunes distingue des versions « snapshot » (qui ne seront pas mis à jour automatiquement sur l’iPhone) et des versions « release » (qui viendront remplacer automatiquement la dernière version).

II) Qualité du code :

Erreur de compilation :

Mise en situation :

Un développeur oublie de commiter un fichier ou une ressource nécessaire au build. Ou pire, on commit un fichier qui ne compile pas. Les autres développeurs qui se synchronisent avec le gestionnaire de sources ne peuvent plus compiler et sont bloqués. Plus cette situation est détectée tôt, plus elle est facile à corriger.

Douleur :

Le coût des erreurs

Cause :

Erreur de commit

Solution :

L’UDD permet de signaler les erreurs de compilation. Nous allons faire évoluer le script afin de réaliser cette tâche et envoyer un mail aux développeurs lorsqu’un bug est détecté.

Détecter les erreurs de compilation :

On va d’abord parser le résultat de la compilation afin de vérifier si celle-ci s’est bien déroulée. On va se baser sur le message ‘BUILD SUCCEEDED’ qui apparait à la fin d’une compilation réussie.

xcodebuild -target "${TARGET_NAME}" -configuration Release -sdk iphoneos3.0 > /tmp/buildlogIphone.log

LOGRESULT=`grep 'BUILD SUCCEEDED' /tmp/buildlogIphone.log`
if [ "$LOGRESULT" == "" ]
then
exit 1
fi

Lorsque la compilation échoue, Hudson enverra automatiquement un mail aux destinataires configurés ( http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson).

Axe d’améliorations :

• Ne pas se baser sur le texte de la compilation qui est susceptible de changer, mais plutôt sur le code de résultat du build.

• Depuis la version 3.0 de Xcode, des erreurs non bloquantes apparaissent dans les logs du build par ligne de commande, ce qui rend les logs moins lisibles. Ces erreurs sont mentionnées sur les mailing lists mais sans solution immédiate, il nous reste à résoudre ce problème.

• Améliorer le contenu des mails envoyés afin de synthétiser l’information : en effet, le contenu des mails dans l’état actuel est très verbeux et assez fastidieux à exploiter. On pourrait recevoir un mail indiquant uniquement le statut du build, le nombre de leaks détectés, les tests unitaires en échec et un lien vers le détail pour chaque section (build, leaks, test). Et éventuellement mettre en place un code couleur en fonction de l’urgence du problème remonté dans le mail.

Fuites mémoire

Mise en situation :

Un développeur commit du code contenant des fuites mémoires (http://fr.wikipedia.org/wiki/Fuite_de_m%C3%A9moire). L’application devient instable et peut crasher à l’utilisation.

Douleur :

Encore le coût des erreurs

Cause :

Il est fastidieux de passer l’analyseur de code à chaque compilation, cela débouche alors sur une mauvaise pratique qui consiste à repousser le « nettoyage » du code. On voit alors parfois apparaître au sein de l’équipe des tâches techniques « suppression des leaks ». Lorsque ceux-ci sont détectés tardivement, ils deviennent couteux à corriger.

Solution :

L’UDD permet d’automatiser l’analyse statique du code. Celle-ci permet de détecter toute une série d’anomalies, allant de la fuite mémoire à la faille de sécurité. Nous allons utiliser l’outil « clang static analyzer », que l’on peut télécharger à cette adresse :

http://clang-analyzer.llvm.org/

N.B : La dernière version de Xcode intègre désormais une analyse de code basée sur le même projet mais intégrée à l’interface graphique (option « build and analyze » dans le menu build).

On récupère un fichier checker-232.tar que l’on va décompresser vers /admin/bin

Dans le dossier checker on trouve 2 exécutables :

• « scan-build » permet de lancer une analyse de code par ligne de commande
• « scan-view » permet de visualiser les détails des bugs trouvés sous forme de page html

On va créer 1 alias de scan-build dans /admin/bin ce qui nous évitera de spécifier le chemin complet vers l’exécutable.

Pour lancer une analyse de code il suffit de lancer la commande :

scan-build [BUILD_COMMAND]

Lorsque l’analyzeur détecte un bug il génère un fichier de rapport et affiche à la fin des logs un message du type :

scan-build: 2 bugs found.
scan-build: Run ‘scan-view /var/folders/Br/BrQyHE0cHHO0PuV2E4TrlU+++TI/-Tmp-/scan-build-2010-01-19-1′ to examine bug reports.

On va donc parser les logs à la recherche du texte : « Run ‘scan-view »

~/bin/scan-build xcodebuild -target "${TARGET_NAME}" -configuration Debug clean -sdk iphoneos3.0
~/bin/scan-build xcodebuild -target "${TARGET_NAME}" -configuration Debug -sdk iphoneos3.0  > /tmp/scanBuildlogIphone.log

SCANRESULT=`grep "Run 'scan-view" /tmp/scanBuildlogIphone.log`

if [ "$SCANRESULT" != "" ]
then
exit 1
fi

N.B : il est conseillé d’effectuer l’analyse de code en mode Debug. (http://clang-analyzer.llvm.org/scan-build.html)

Axes d’améliorations :

• Ici encore on pourrait se baser sur le code de retour plutôt que sur le libellé.
• Nous pourrions également optimiser le contenu des mails plutôt que de fournir les logs de l’analyse.

Tests unitaires :

Pré-Requis :

• Mise en place de tests unitaires sur iPhone (http://developer.apple.com/iphone/library/documentation/Xcode/Conceptual/iphone_development/135-Unit_Testing_Applications/unit_testing_applications.html)

Mise en situation :

Un développeur commit un fichier qui fait échouer un ou plusieurs tests unitaires.

Douleur :

Toujours le coût des erreurs

Cause :

L’exécution des tests peut devenir longue et fastidieuse (nombreux tests d’intégration), cela n’incite pas les développeurs à les passer systématiquement.

Solution :

De la même manière qu’en Java, si les tests unitaires sont exécutés automatiquement à chaque commit, on allège le travail d’intégration des différents développements. Nous allons donc automatiser l’exécution de nos tests unitaires à chaque compilation. Si l’un des tests échoue, la compilation sortira en erreur.

Pour cela, nous allons ajouter une dépendance directe entre notre target principale et notre target de test. Ainsi, à chaque compilation de l’application, notre projet sera compilé, puis nos tests seront exécutés. Si l’une ou l’autre de ces étapes échoue, le build sortira en erreur.

Ouvrez votre target principale et dans l’onglet « General » faites « + » dans la liste « Direct dependencies » et ajoutez la target de test.

L’UDD iPhone au quotidien :

Actuellement, 2 développeurs se servent de l’UDD iPhone sur une mission réalisée par Octo. Celle-ci tourne sur un 3^ème mac qui sert de machine d’intégration et de recette.

Lorsque le build casse, nous recevons un mail avec le log du build et un lien vers le rapport de l’analyse statique de code. Nous avons partagé le répertoire de log du 3^ème mac ce qui nous permet de les consulter depuis notre poste de développement.

Le mac sur lequel tourne l’UDD sert également d’environnement de recette : sur le bureau se trouve en permanence la dernière version stable de l’application (ainsi qu’un historique des build de l’application), on peut la déployer sur un iPhone via iTunes par un simple drag and drop.

Conclusion :

La simple mise en place d’une UDD ne règle pas d’elle même les problèmes : il faut des règles partagées par l’équipe, notamment concernant la politique de commit : quand et quoi commiter.

Une UDD permet par contre de mettre l’accent sur ces règles et de discipliner les pratiques de développement.

Par ailleurs, tous les problèmes évoqués peuvent être théoriquement réglés «à la main », néanmoins il s’agit de problèmes liés à la partie « pénible » du travail : lancer les tests régulièrement, archiver des versions stables, intégrer en permanence, etc. L’UDD permet de rendre cet effort transparent.

–

Lien vers le script de build complet :

BUILD.SH

Suggestion d'articles :

1. Tour d’horizon du développement iPhone
2. Choisir son ampli (et son usine de développement)…
3. Petit dej’ : « iPhone as a business platform »

Les méthodes agiles recommandent la colocalisation des acteurs (i.e. une localisation physique dans un même bureau) pour une meilleure communication, une meilleure collaboration et globalement une équipe ou un processus projet plus performants. Par exemple Ken Schwaber dans The Enterprise and Scrum :

« High-bandwidth communication is one of the core practices of Scrum… The best communication is face to face, with communications occurring through facial expression, body language, intonation, and words. »

Que disent les sciences de ce sujet aujourd’hui âprement discuté dans la communauté agile et ô combien toujours délicat à mettre en œuvre dans les faits ?

Ce principe de colocalisation fait débat dans la communauté agile, maintenant que les méthodes agiles, en passe de devenir « mainstream », sont déployées bien au-delà de « petites » équipes colocalisées.
Même dans le cas d’équipes « colocalisables » dans les faits, on mesure la distance de la coupe aux lèvres lorsque les organisations doivent faire le pas et que les obstacles se dressent, notamment :

• une remise en cause délicate des frontières organisationnelles dès lors que des acteurs de différents silos sont amenés à partager au quotidien un même espace de travail (ex : MOA/MOE/marketing/intégration/exploitation…);
• des demandes d’aide pour le moins fastidieuses vis-à-vis des tout puissants « services généraux » ;
• un impact sur l’ensemble des acteurs projet, au-delà de la population des développeurs, seule astreinte aux nouvelles disciplines comme le pair programming, TDD ou l’intégration continue.

Les multiples réticences à la mise en place d’équipe colocalisées ou le débat au sein de la communauté agile doivent nous inciter à étayer notre discours plus solidement que « c’est une bonne pratique agile qui est indispensable/facultative » ou « la colocalisation/non-colocalisation a bien/mal marché dans nos projets précédents ».

A cette fin, les très nombreuses études scientifiques dans ce domaine sont une source quasi jamais explorée dans les communautés agile et lean. Par exemple, la psychologie sociale, discipline hautement empirique ou des disciplines plus spécialisées comme le domaine du Computer Supported Collaborative Work (CSCW), ont accumulé depuis plus de 30 ans les expériences, études et publications sur l’efficacité de la communication et de la collaboration en fonction de la distribution physique des membres de l’équipe.

Un résultat classique : la courbe d’Allen

Thomas Allen, professeur au MIT et auteur de l’ouvrage de référence Managing the Flow of Technology en 1977, a étudié la probabilité de communication au sein d’une équipe en fonction de la distance.

Le profil de la « courbe d’Allen » est une décroissance exponentielle dont on peut extraire quelques points représentatifs :

• au-delà de 9 mètres, il y a moins d’une chance sur 10 pour que 2 acteurs communiquent une fois dans la semaine ;
• il y a deux fois plus d’échanges pour 2 acteurs séparés de 10 mètres que pour 2 acteurs séparés de 20 mètres.

Par exemple, 2 acteurs situés dans deux bureaux même proches (disons à 20 m) auront 2 fois moins d’échange que 2 acteurs à 10 m de distance sur un même plateau.

Et chez vous ?

• Quels sont vos 3 interlocuteurs privilégiés ? A quelle distance sont-ils de vous ?
• Dans vos équipes projet, quelles sont les distances entre des interlocuteurs proches dans la chaîne de valeur (par exemple : marketing=>MOA=>MOE=>intégration=>exploitation) ?

Oui mais l’email, l’instant messaging, la vidéo ?

Les moyens de communication modernes (email, IM, vidéo conférence) largement déployés depuis les premiers résultats de Allen ont-ils remis en cause l’importance de la distance ?

Pas vraiment… voire c’est tout le contraire qui apparait au fil des études puisque la probabilité d’interaction par ces nouveaux moyens de communication est corrélée à la distance. Ainsi, Allen dans son ouvrage récent (2008), The Organization and Architecture of Innovation :

« We do not keep separate sets of people, some of which we communicate in one medium and some by another. The more often we see someone face-to-face, the more likely it is that we will telephone the person or communicate in some other medium. »

Google, encore Google…

Une étude à grande échelle basée sur un marché de prédiction et menée dans les centres de Google, confirme les résultats classiques de Allen.

Un des auteurs de l’étude, Justin Wolfers, commente les résultats de l’étude :

« Sitting within a few feet of a workmate has a big effect. (Our data includes the exact GPS coordinates of each person’s desk, as well as their previous desks.)
Beyond this, sitting on the same floor as someone barely has any effect.
[…]
The overwhelming importance of “micro-geography” was quite striking, particularly as this is the sort of organization in which Instant Messaging and e-mail (plus blogs and wikis) might have otherwise suggested the death of distance. »

Eric Schmidt, CEO de Google, n’a pas attendu les résultats de cette étude pour souligner l’importance de la colocalisation. Pour preuve la 3ème règle (« Pack them in ») des Google Ten Golden Rules.

« The best way to make communication easy is to put team members within a few feet of each other. The result is that virtually everyone at Google shares an office. This way, when a programmer needs to confer with a colleague, there is immediate access: no telephone tag, no e-mail delay, no waiting for a reply. »

A cet égard, le modèle Google et sa confirmation par l’étude expérimentale éclaire d’autant plus nos propres contextes IT :

• Les employés Google ont a leur disposition tous les outils de communication technologiques possibles et imaginables (faisons l’hypothèse qu’ils savent les utiliser correctement) ;
• Le métier de Google ressemble de près ou de loin au métier de nos équipes projets (i.e. concevoir et construire vite et bien de nouveaux produits IT) ;

Effet de la distance sur la collaboration, le mensonge et la recherche de compromis

Les résultats évoqués jusqu’ici concernent la probabilité de communication en fonction de la distance. D’autres études en psychologie sociales se sont attachées à mesurer les effets de la distance sur la propension à collaborer, tromper son interlocuteur ou trouver efficacement des compromis.

Ainsi, dans l’étude Why Distance Matters :

« First, the data strongly indicates that the geographic distance between collaborating and previously unacquainted partners matters. The ability to persuade another and the willingness to initially cooperate decrease with distance while deception of another person increases with distance. »

Au passage, cette étude balaie aussi l’espoir parfois mis dans des outils technologiques plus « riches ». Ainsi, la qualité de la collaboration, la propension au mensonge et aux compromis, sont sensiblement les mêmes que les acteurs utilisent un simple « instant messaging » ou la vidéo conférence.

Conclusion

Les résultats cités dans ce post dépassent le cadre des méthodes agiles ou même du développement logiciel : tous les « jeux » collaboratifs, créatifs et innovants (notamment tous les types de « new product development ») retireront énormément de la co-localisation.

Les disciplines scientifiques comme la psychologie sociale peuvent nous fournir des résultats expérimentaux probants à la fois dans le débat au sein de la communauté agile mais surtout comme argument de poids dans la mise en place d’équipe colocalisées. Le lecteur intéressé par les détails des protocoles et des données expérimentales recueillies pourra se reporter aux études pointées tout au long du post.

Suggestion d'articles :

1. Devons-nous changer de paradigme pour le développement d’applications informatiques?
2. Espace détente
3. Et si nous définissions simplement le Cloud Computing !

Dans un projet d’entreprise, il est important de vérifier continuellement la non-régression du produit réalisé. Au même titre que les tests unitaires, les tests d’acceptance font partie intégrante du harnais de tests à mettre en place sur un projet. FitNesse est une des solutions à ce besoin.

FitNesse / Slim

FitNesse dormait jusqu’à Juillet 2008. Mais il suffit de voir le rythme des releases depuis cette date, pour se rendre compte qu’il s’est réveillé ! Avec une nouvelle version presque tous les mois entre Juillet 2008 et Juillet 2009, et l’arrivée de Slim, on obtient un produit qui a sensiblement changé.

Mais avec une évolution aussi soudaine, on ne peut malheureusement pas éviter les effets de bords. Notamment dans le monde des outils qui tournaient autour de la sphère FitNesse. Par exemple, je recherchais un plugin Maven pour FitNesse. Mais la plupart des liens que me renvoie mon moteur de recherche préféré, pointe sur des outils incompatibles avec les nouvelles versions de FitNesse.

Il faut creuser un peu avant de trouver les perles rares…

Intégration avec Maven

Classpath generator

Dès qu’on joue un peu avec FitNesse, on se rend vite compte que la gestion du classpath est une vraie galère ! L’écriture manuelle n’est pas une solution envisageable lorsque le projet embarque plus d’une dizaine de dépendances. Et puis après tout c’est le rôle de Maven de gérer tout ça !

C’est là qu’entre en jeu le superbe plugin Classpath generator.

Compatible avec la dernière version de FitNesse (20090818), il permet de générer automatiquement la liste des dépendances des fixtures décrites dans le pom, directement dans le wiki.

Pour savoir comment configurer le plugin et comment l’utiliser, il suffit de suivre ce lien.
Attention, la page dans laquelle vous souhaitez générer le classpath doit être de type « Suite ».

Trinidad

L’étape suivante consiste à intégrer l’exécution automatique des tests d’acceptance dans le processus de build du projet. Pour cela, il existe le plugin Maven nommé Trinidad. Nous nous concentrons ici uniquement sur l’aspect exécution des tests FitNesse dans Maven, sachant que le plugin permet de faire bien plus que ça.

Pour cela, je vous décris dans la suite comment j’ai configuré et utilisé le plugin.

Configuration du pom.xml du projet contenant les fixtures :

Ajout de la dépendance :

<project> 
  <repositories> 
    <repository> 
      <id>neuri-maven</id> 
      <url>http://maven.neuri.com/</url> 
      <snapshots> 
        <enabled>true</enabled> 
      </snapshots> 
      <releases>
        <enabled>true</enabled> 
      </releases>
    </repository> 
  </repositories> 
  <dependencies>
    <dependency> 
      <groupid>com.neuri.tdd</groupid> 
      <artifactid>fitnesserunner</artifactid> 
      <version>20090818</version> 
    </dependency>
  </dependencies>
</project>

Configuration du plugin :

<project>
  <build>
    <plugins>
      <plugin>
        <artifactid>maven-trinidad-plugin</artifactid>
        <version>20090818</version>
        <executions>
          <execution>
            <phase>test</phase> 
            <goals>
              <goal>run-tests</goal>
            </goals> 
          </execution>
        </executions>
        <configuration>
          <testengine>slim</testengine> 
          <testrepositorytype>fitnesse</testrepositorytype>
          <testrepositoryuri>C:\Programs\fitnesse</testrepositoryuri> 
          <breakbuildonfailure>true</breakbuildonfailure> 
          <suites> 
            <suite>MyProject.MyTestSuite</suite> 
          </suites> 
        </configuration>
      </plugin> 
    </plugins> 
  </build> 
  <pluginrepositories> 
    <pluginrepository> 
      <id>neuri-maven</id> 
      <url>http://maven.neuri.com/</url> 
      <snapshots> 
        <enabled>true</enabled> 
      </snapshots> 
      <releases> 
        <enabled>true</enabled> 
      </releases> 
    </pluginrepository> 
  </pluginrepositories>
</project>

Ainsi configuré, tous les tests FitNesse inclus dans la suite « MyTestSuite » seront exécutés lors du lancement de la phase test de Maven.

Le paramètre « breakBuildOnFailure » permet comme son nom l’indique de casser le build en cas d’échec sur les tests d’acceptance. Par défaut, le paramètre est à false.

Hudson

L’usine d’intégration continue est une brique logiciel essentielle dans un projet agile. Il garantit l’intégrité de l’application construite au fil de l’eau. Hudson est un des outils les plus répandus. Intégrer les tests d’acceptance dans l’usine d’intégration continue participe donc à construire un logiciel de qualité.

Par contre, on est en droit de se demander s’il est indispensable d’exécuter les tests d’acceptance à chaque fois que l’application est construite (c’est-à-dire à chaque commit d’un développeur). En effet, les tests FitNesse sont souvent longs à exécuter, et les jouer à chaque fois peut parfois nuire à la productivité de l’équipe. Un bon compromis est de lancer le build des tests d’acceptance toutes les nuits.

Voici comment j’ai configuré le job Hudson qui exécute les tests FitNesse tous les jours à minuit:

Malgré une version stable depuis Août 2009, FitNesse peut être amené à évoluer dans quelques mois. Cet article se base sur la version 20090818. Les outils présentés ont été testés sur cette version. Il n’est pas garantit qu’ils fonctionneront toujours avec les versions futures de FitNesse.

Suggestion d'articles :

1. Les tests de recette automatisés avec Fitnesse
2. Intégration continue performante (Part #1)
3. Mise en place technique de FitNesse