Soyons sérieux.

Il semble important d’apprendre aux développeurs quelques techniques pour parler avec le client. Cet enseignement vient de ce que j’ai vu lors de ma formation Domain Driven Design chez Zenika : l’importance d’un langage unique, ce que l’on appelle « Ubiquitous Language« . Je ne parle pas des règles de politesses, mais bien de l’importance de définir une sémantique claire entre l’équipe de réalisation d’une part, et l’équipe de maîtrise d’œuvre d’autre part.

L’Ubiquitous Language dans l’approche Domain Driven Design, est un langage défini autour du modèle du domaine, utilisé par toutes les équipes pour communiquer autour du logiciel réalisé. En l’absence d’UL, il y a un risque important que le travail des développeurs ne correspondent pas à la demande du client. Il s’avère que les développeurs ne font pas toujours l’effort d’apprendre les termes et la langue de travail du domaine. D’un autre côté, certains experts du domaine se rendent inaccessible en ne faisant aucuns efforts de vulgarisation ou d’explications.

Je me souviens de cette charmante personne dans mon ancienne société qui venait nous parler des CDS (Credit defaut swap). On y comprenait rien. Pourtant la définition est très simple :

A credit default swap (CDS) is a swap contract in which the buyer of the CDS makes a series of payments to the seller and, in exchange, receives a payoff if a credit instrument (typically a bond or loan) undergoes a ‘Credit Event’ (often described as a default) defined as events such as restructuring, bankruptcy or even downgrade of credit rating (less common).

C’est super simple non ? Allez vous me faîtes un petit modèle simple sur cette base et on se revoit demain….

Ce qui est intéressant avec les CDS, c’est qu’ils sont à la source de la faillite de l’assureur AIG en 2008. La banque Lehman Brothers était le premier acteur sur ce marché. Les CDS sont des contrats de protections financières entre les acheteurs et les vendeurs, mis en place pour couvrir les risques de crédit. Lorsque vous achetez une maison, votre assurance santé couvre le risque de défaillance de paiement en offrant une couverture en cas de soucis de santé. Les CDS sont des contrats qui protègent le vendeur en cas d’événements de crédits graves comme la faillite d’une banque, une crise monétaire ou autre. C’est plus clair ?

Lorsque le langage n’est pas clair, votre projet informatique prend un sérieux risque de ne pas concrétiser vos attentes. Il est donc primordial de trouver des personnes de la maîtrise d’ouvrage ou de la maîtrise d’œuvre en mesure de parler avec les développeurs. Dès lors que les mots ne sont pas clairs, il y a un risque de dérapage.

Le développeur doit apprendre une langue métier

Crédit photo: Shawn Econo
Parlons un peu de vous, messieurs les développeurs. Quel nom allez-vous donner à votre Class Java, à vos méthodes et vos objets ? Quels mots allez-vous utiliser dans vos schémas d’architecture ? C’est là qu’il devient important d’utiliser l’UL (Ubiquitous Language).

Lorsque les mots ne sont pas clairs, les développeurs entre eux ne peuvent pas se comprendre. Que voulez-vous dire exactement par « Adapteur » ici sur ce schéma ? Il s’agit d’un convertisseur de flux financier ? D’un adapteur réseau ? D’un mot qui ne veut rien dire ?

Il est cependant important de dire qu’il y aura un décalage entre le code écrit et la langue des clients, de l’équipe métier. Trouver le bon nom d’une classe pourra demander plusieurs itérations. Travailler même avec des développeurs d’un autre pays demandera un effort de vulgarisation et de documentation plus important que prévu.

Comment s’en sortir alors ?
Revenez sur votre modèle. Je ne parle pas forcément UML ici. Je parle simplement de ce schéma qui décrit votre logiciel. En fait, il ne doit contenir que des mots validés par le métier. Si quelque part je vois « ESB » alors je dis : « danger !!! ». Un ESB ne veut rien dire pour quelqu’un qui n’est pas développeur.

Imaginez les cartes routières. Pensez-vous que celles-ci seraient exploitables si elles utilisaient le format de l’armée ? Ou celui des géomètres ? Non !
Il y a eu un effort de transcription et de simplification pour que vous, le client lambda, soyez en mesure de comprendre et de vous y retrouver.

Crédit photo : Andrea_r

Le langage dépasse les schémas. Ce sera surtout cet ensemble de mots que vos développeurs utiliseront chaque jour. Lorsqu’un développeur dira « événement financier avec risque » ou « emprunts », chacun aura une vision claire.

Lorsque je dis « moteur de génération de rapports financiers » il n’y a pas d’ambiguïté sur le fond. Parler de « moteur transactionnel de génération de rapports BIRT » à un financier n’a pas de sens. De même, parler de « plateforme d’externalisation des documents légaux financiers par voie électronique » ne parlera pas à un développeur. Soyez créatif, inventez-vous un vocabulaire et une langue de travail.

En cas de doutes sur la signification d’un terme, il faut faire appel à l’expert du domaine. C’est la personne qui représente le client, et qui a assez d’autorité pour trancher. Ne prenez pas de décisions sans en parler avec lui.

Conclusion
L’Ubiquitous Language de la pratique du Domain Driven Design demande aux développeurs et aux architectes d’améliorer leur communication avec le client. Pour cela, les architectes doivent travailler avec les clients du projet afin de capturer les mots, de définir les notions et le sens de chaque élément. Essayez de reprendre vos schémas fonctionnels, et assurez-vous qu’il n’y ait pas trop d’abréviations. Je déteste cela. Je trouve que c’est un moyen trop facile de jargoniser son projet. Pensez à celui qui arrive dans le projet. Ce n’est pas à lui de vous comprendre, c’est à vous de vous faire comprendre. Soyez humble, abandonnez cette chaise de juge arbitre de Tennis, d’où vous jetez les acronymes sur la population du développeur.

Quant à toi mon cher développeur, tu ne t’en sortiras pas comme cela. Si je te vois encore parler de transaction sérialisée en SGBDR, de 2-phases-commit, de repository de datas ou de je ne sais quelle perle de geek à ton client, tu vas entendre parler de moi. C’est à toi d’apprendre à parler Klingons, pas à eux.

Sur ce, je vous laisse, j’ai mal aux doigts après avoir tapé cet article, j’ai les bouts des doigts carrés… bizarre.

Cette conférence essentiellement francophone, est aussi le point de rendez-vous de nos voisins Suisses, Belges et Canadien comme l’an passé. Avec 280 personnes l’an passé, chaque session fut bien remplie. Les sponsors sont invités à se faire connaître pour aider l’équipe Agile France qui fait un travail remarquable.

Le site Agile France vous donnera tous les détails nécessaires : http://conf.agile-france.org/

Voici les articles publiés sur le Touilleur Express l’an dernier, afin de vous donner un avant-goût de ce qui vous attend :
XP Day France 2009 – journée 1 publié le 2009-05-27 00:22:41
XP Day France 2009 – jour 2 publié le 2009-05-27 20:03:05
XP Day France 2009, Scrum est-il dangereux ? publié le 2009-05-29 21:50:38
XP Day France 2009 – jour 2, Dans la peau du Challenger et Business Value Game publié le 2009-05-31 13:57:32

Alexis Agahi lance le Paris Scala User Group. L’objectif de ce user group est de regrouper les fans de Scala qui travaillent en Ile-de-France. L’adresse du site officiel : http://groups.google.com/group/paris-scala-user-group.
La première rencontre aura lieu à l’occasion de la soirée Scala du Paris Java User Group en avril.

Communiqué de presse – Jeudi 11 mars 2010

Lancement du Birt User Group FR

Le Birt User Group FR naît!

Pour la première fois un User Group consacré à BIRT est créé en France.
Le Birt User Group France est le groupe des utilisateurs BIRT Français ayant pour objectif de réunir la communauté afin d’échanger des retours d’expérience, des idées et de discuter des nouveautés de cet outil de reporting Open-Source.

Ce groupe sera l’occasion de créer une véritable synergie autour de la technologie BIRT dans un esprit de partage des connaissances. Le fonctionnement est simple, les membres pourront librement échanger sur ce sujet en s’exprimant directement sur ce groupe.

Afin de faciliter les interactions entre membres, des rencontres sur Paris seront organisées tous les deux mois sous la forme d’ateliers de discussion sur des thématiques pré-définies ou de discussions libres.

Les membres planifieront eux-même les rencontres et leurs contenus. Par exemple, selon les besoins et demandes identifiés lors des précédents échanges, des conférences pourrons être programmées.

Par ailleurs, tous les événements spécifiques à BIRT seront annoncés afin de permettre aux membres de se tenir informés des nouveautés et ainsi fédérer la communauté BIRT grandissante.

Le premier rendez-vous aura lieu mercredi 07 avril sur Paris à 19h.

Il sera animé par Paul Clenahan, membre actif du projet Eclipse BIRT, qui nous donnera une vision interne de cet outil devenu en quelques années la solution de reporting Open-Source de référence.

Les inscriptions à l’événement sont, d’ores et déjà, ouvertes sur http://birt-user-group-france.eventbrite.com.

Toute inscription au BIRT User Group France se fera directement sur le Google Groupe : http://groups.google.fr/group/birt-user-group-france.

Pour plus d’informations, contactez Birt User Group France : birt-user-group-france@googlegroups.com.

Après un premier article qui vous a fait pas mal réagir, je vais vous parler des Traits et des Collections. J’ajoute un peu plus de programmation fonctionnelle dans cet épisode.

Les Traits
Les Traits en Scala sont un nouveau concept qui demande un peu de temps à un développeur Java du Canal Historique comme moi. Regardons les limitations des interfaces en Java : une classe peut implémenter un certain nombre d’interfaces. Or une interface ne nous permet pas de définir du code commun justement pour l’ensemble des classes qui implémentent celle-ci. Au lieu de cela, il faut mettre en place des stratégies et des patterns pour regrouper des ensembles fonctionnels. Bref nous nous en sortons, avec un peu de gymnastique. A ce propos, lorsque je vois l’utilisation des annotations en Java sur certains projets, j’ai le sentiment de voir des cas d’usages similaires aux Traits en Scala, que nous avons comblé avec des annotations.

Les Traits en Scala sont empilables, ce qui permet d’ajouter de multiples caractéristiques définies dans différents Traits. Contrairement à une interface Java, les Traits peuvent implémenter des méthodes. Il ne sera alors pas nécessaire de les redéfinir dans les classes qui étendent ces Traits.

J’aime l’idée qu’une Interface est un espace de nom qui permet de regrouper par caractéristiques des objets (Serializable, Comparable). Cela me fait penser que les Traits sont similaires à des adjectifs que l’on ajoute à un objet. . Attention, il ne s’agit pas d’héritage multiple comme en C++, mais de la possibilité d’étendre des interfaces, en définissant un ordre. La notion de Trait est inspiré des Mix-In du langage Ruby.

Les Traits sont donc comme des interfaces avec une implémentation partielle, et ils permettent d’empiler dans un certain ordre un ensemble de fonctionnalités à une Class. Nous verrons avec les Collections que c’est très pratique.

Prenons par exemple un panier sur un site Web. Ce panier est capable d’accumuler des articles. Nous allons voir comment il est possible d’enrichir les possibilités de notre objet initial en y ajoutant des traits, sans cependant faire de l’héritage multiple.

Je commence par définir une classe abstraite pour définir la notion de Scanner de prix. Un Scanner est capable d’additionner le prix de chaque article qui passe, et ensuite de vous donner le total à payer

abstract class PriceScanner {
    def scanArticle(x: Double)
    def getTotalPrice(): Double
}

Définissons ensuite un simple Scanner

class ClassicPriceScanner extends PriceScanner {
  private var total:Double = 0.0

  def scanArticle(x: Double) = { total+=x }

  def getTotalPrice() = { total }
}

Je vais vous montrer qu’il est possible d’empiler les Traits pour ajouter de manière sélective quelques opérations. Nous allons définir un Trait pour calculer la TVA lorsqu’un article est scanné, et un Trait pour convertir en US Dollar le prix final :

// Scala
// Compute the price with Value Added Taxes
trait FrenchTaxIncluded extends PriceScanner {
  // Add the French V.A.T.
  abstract override def scanArticle(x: Double) { super.scanArticle(x * 0.196 + x)}
}

Notez que le Trait étend la classe de base

/**
 * Convert to US Dollar the total amount.
 */
trait InUSDollar extends PriceScanner {
  abstract override def getTotalPrice() = { super.getTotalPrice()*1.3556  }
}

Les Traits sont réellement des caractéristiques que nous allons ajouter à la création de nos instances, au lieu de devoir les ajouter à la définition de notre classe. C’est maintenant que cela devient intéressant. Dans l’exemple ci-dessous j’ai déclaré 3 scanners différents. Chacun de ces Scanners dispose de plus ou moins de fonctionnalités selon les Traits. Notez aussi l’usage du mot clé « with » qui permet de donner l’ordre dans lequel les Traits seront ajoutés à la classe initiale :

object Test {

  def main(args: Array[String]) = {
    val myPanier = new ClassicPriceScanner()  with FrenchTaxIncluded
    myPanier.scanArticle(100.0)

    val myUSDPanier : ClassicPriceScanner = new ClassicPriceScanner() with InUSDollar
    myUSDPanier.scanArticle(100.0)

    val myUSDPanierAndVAT : ClassicPriceScanner = new ClassicPriceScanner() with InUSDollar with FrenchTaxIncluded
    myUSDPanierAndVAT.scanArticle(100.0)

    println("Total in EUR: "+myPanier.getTotalPrice())
    println("Total in USD: "+myUSDPanier.getTotalPrice())
    println("Total in USD with VAT: "+myUSDPanierAndVAT.getTotalPrice())

  }
}

L’exécution de ce programme donne alors le résultat suivant :

Total in EUR: 119.6
Total in USD: 135.56
Total in USD with VAT: 162.12975999999998

Notez que ces tests ne sont pas très élégants. Pourquoi ne pas utiliser dès maintenant la librairie Specs de Scala Tools afin d’écrire des tests orientés développements ? La pratique du Behavior-Driven Development dont je pourrai parler dans un autre article, consiste à décrire sous forme de spécifications exécutables le résultat attendu.
Télécharger specs-1.4.3.jar et ajoutez-le dans votre Classpath pour pouvoir lancer cette spécification :

package org.letouilleur.tutorial.test

/**
 * BDD Specification for Traits article.
 * @author Nicolas Martignole
 */

import org.specs._

object PriceScannerSpec extends Specification {
  "ClassicPriceScanner with 2 articles at 100.0 EUR each " should {
    "return a total of 200.0 " in {
      val cp = new ClassicPriceScanner()
      cp.scanArticle(100.0)
      cp.scanArticle(100.0)
      cp.getTotalPrice() mustEqual 200.0
    }
  }

  "ClassicPriceScanner with 2 articles at 100.0 EUR each decorated with the FrenchTaxIncluded Trait" should {
    "return a total of 238.2 EUR" in {
      val cp = new ClassicPriceScanner() with FrenchTaxIncluded
      cp.scanArticle(100.0)
      cp.scanArticle(100.0)
      cp.getTotalPrice() mustEqual 239.2
    }
  }
}

Lorsque l’on exécute cette spécification, voici le résultat :

Specification "PriceScannerSpec"
  ClassicPriceScanner with 2 articles at 100.0 EUR each  should
  + return a total of 200.0 

  Total for SUT "ClassicPriceScanner with 2 articles at 100.0 EUR each ":
  Finished in 0 second, 0 ms
  1 example, 1 expectation, 0 failure, 0 error

  ClassicPriceScanner with 2 articles at 100.0 EUR each decorated with the FrenchTaxIncluded Trait should
  + return a total of 238.2 EUR

  Total for SUT "ClassicPriceScanner with 2 articles at 100.0 EUR each decorated with the FrenchTaxIncluded Trait":
  Finished in 0 second, 0 ms
  1 example, 1 expectation, 0 failure, 0 error

Total for specification "PriceScannerSpec":
Finished in 0 second, 44 ms
2 examples, 2 expectations, 0 failure, 0 error

Sympa non ? Au passage vous noterez que Scala est particulièrement à l’aise dans le domaine des DSL.

Je m’arrête là pour les Traits. Je sais que les Aficionados de Scala vont largement commenter mes petits tests, qui ne doivent pas casser 2 pattes à un canard. Je débute les gars, donc cool, respirez un coup et pensez aux lecteurs qui n’y connaissent rien. Soyez pédagogue.

Les Collections
Deuxième sujet aujourd’hui dont je veux vous parler : les Collections. Nous ouvrons la boîte de la programmation fonctionnelle dans cette partie. Je ne vais pas vous expliquer ce qu’est une Map ou un Set. En Scala nous retrouvons des objets List, Set et Map. Il existe 2 familles de collections : les objets immuables et les objets non immuables. Scala encourage l’utilisation d’objets immuables, ce qui rend service lorsque nous ferrons de la programmation concurrentielle la prochaine fois. En effet, un objet qui ne peut pas être modifié, n’a pas besoin d’être synchronisé.

Les Collections en Scala sont disponibles en plusieurs versions. Prenons les Lists par exemple, Scala 2.8 propose :
- scala.collection.immutable.List
- scala.collection.mutable.LinkedList
(notez qu’il n’existe pas de scala.collection.mutable.List)
- scala.collection.jcl.LinkedList

Le 3ème type jcl est un wrapper de la Class java.util.LinkedList.

Une Map est simple à écrire, c’est même plus concis que la version Java :

   val aMap = Map("Nicolas"->180,"Pierre"->172,"Jacques"->181)

   println(aMap.size)

// affiche 3

Nous pouvons commencer à utiliser quelques spécificités de Scala pour créer une deuxième Map de type String,String où la taille de chaque personne est convertie en mètre, et ensuite transformé en chaine de caractère :

object MapSample {
 def main(args: Array[String]) = {
    val aMap = Map("Nicolas"->180,"Pierre"->172,"Jacques"->181)

   println(aMap.size)

   val convertedInMeter = aMap map {kv => (kv._1,kv._2*0.01+"m")}
   println("People size in meter : "+convertedInMeter)

  }
}

L’exécution du code ci-dessus donne :

3
People size in meter : ArrayBuffer((Nicolas,1.8 m), (Pierre,1.72 m), (Jacques,1.81 m))

Nous pouvons aussi par exemple filtrer les clés ou les valeurs de la map, afin de créer une deuxième map ne contenant que les personnes qui font 1.80 mètre ou plus :

   // Personne qui font plus de 180cm
   val tallPeople = aMap filter {kv =>  kv._2 > 180 }
   println("People taller than 180cm "+tallPeople)

  // Execution -> seul Jacques dépasse les 180 cm
  People taller than 180cm Map(Jacques -> 181)

Il existe un grand nombre de fonctions que l’on peut utiliser sur les collections :
– def drop (n: Int) : Collection[A] permet de retirer les n premiers éléments d’une itération, ou retourne vide sinon
– def dropWhile( p : (A) => Boolean) : Collection[A] permet de supprimer d’une collection ses éléments tant que la condition de test retourne true.
– def exists(p: (A) => Boolean) : Iterable[A] permet de vérifier qu’un prédicat p se vérifie sur l’un des éléments de la collection
– def filter(p: (A) => Boolean) : Iterable[A] permet de filtrer la collection comme vu dans l’exemple ci-dessus
– def find(p: (A) => Boolean) : Option[A] permet de trouver le premier élément dans l’iterable qui satisfait le prédicat p
– def findIndexOf(p: (A) => Boolean) : Int permet de trouver le premier emplacement de l’élément qui satisfait le prédicat p, sinon retourne -1
– def forAll(p: (A) => Boolean) : Boolean permet d’appliquer un prédicat p à chacun des éléments de l’iterable et retournera true si le prédicat a retourné true pour chacun des éléments. C’est très pratique pour itérer une collection et effectuer un traitement à la volée.
– def indexOf [ B > A](elem : B) : Int retourne la position du premier élément qui correspond à l’objet spécifié
– def partition(p : (A) => Boolean) : (Iterable[A], Iterable[A]) permet de découper cette Iterable en 2 Iterables selon le prédicat spécifié
– def sameElements [B >: A](that : Iterable[B]) : Boolean permet de vérifier si un autre Iterable contient les éléments du premier Iterable
– def take(n : Int) : Collection[A] permet de prendre uniquement les n premiers éléments d’un Iterable, ou sinon retourne l’objet lui-même s’il est trop petit
– def takeWhile(p : (A) => Boolean) : Iterable[A] enfin permet de parcourir l’Iterable et d’accumuler dans une nouvelle Iterable les éléments tant que le prédicat est vrai.

Il y a d’autres méthodes pour les Set et pour les Maps. Nous constatons qu’il existe un ensemble de fonctions prêtes à l’emploi.

Folding et Reducing
L’opérateur foldLeft permet de parcourir une List et de retourner soit une collection plus petite, soit parfois une seule valeur. Prenons le cas le plus simple (mais pas le plus représentatif) : vous souhaitez calculer la somme d’une liste d’entier. Je créé une liste de 1 à 10 puis j’applique la fonction foldLeft :

object FoldingSample {
  def main(args: Array[String]) = {
    val shortList = 1 to 10 toList

    val result=shortList.foldLeft(0)((b,a) => b+a )
    println(result)  // will output 55

  }
}

foldLeft comme foldRight est ce que l’on appelle une « curried function ». Cette fonction prend 2 paramères (z et f) dans 2 ensembles de parenthèses. Ici z vaut 0 et f est une fonction d’addition. La définition Scala de la fonction est la suivante :

def foldLeft[B](z: B)(f: (B, A) => B): B

z est de type B, n’importe quel type. f est une fonction qui prend B et A et retourne une valeur de type B. A sera en fait chacun des éléments de la collection sur laquelle nous appliquons la fonction foldLeft. Donc ici nous prenons un objet de type B, en l’occurrence 0 qui est un Int, nous effectuons l’addition de la valeur courante de la liste avec la valeur précédemment stockée, et nous retournons l’ensemble

Ici pour le premier élément de la liste, la fonction additionne 0 et 1, ce qui donne 1. Ensuite nous évaluons le deuxième élément de la liste qui est 2. Nous ajoutons l’ancien résultat 1 à 2, ce qui donne 3. Nous avançons au 3ème élément de la liste qui est 3. Nous évaluons la fonction avec l’ancienne valeur de 3, et cela donne 6. Peut-être que le détail vous aidera à comprendre ce qui se passe:
(0+1)=1
(1+2)=3
(3+3)=6
(6+4)=10
(10+5)=15
(15+6)=21
(21+7)=28
(28+8)=36
(36+9)=45
(45+10)=55

Cela vous semble peut-être un peu abstrait, mais c’est très pratique. Voici quelques exemples d’utilisation de cette fonction :

// Moyenne de la série
val shortList = 1 to 10 toList
def average(list: List[Int]): Double = list.foldLeft(0.0)(_+_) / list.foldLeft(0.0)((r,c) => r+1)
println(average(shortList)) // affiche 5.5

// Produit : notez que l'on doit partir de 1 et pas de 0
def product(list: List[Int]): Int = list.foldLeft(1)(_*_)
println(product(shortList)) // affiche 3628800

Conclusion
Scala propose donc des nouveautés et des concepts avancés comme les Traits, qui permettent d’introduire une programmation orientée fonctionnelle sans soucis. Nous n’avons pas parlé d’une dizaine de sujets, et je m’excuse auprès des 7 lecteurs qui maitrisent Scala et qui lisent le blog. Ecrire ces articles demande beaucoup de travail, entre 4 et 6 heures à chaque fois. Nous parlerons un peu de la concurrence et de la beauté de Scala dès lors qu’il s’agit de programmation multi-thread.

Sur le thème des ChuckNorris facts, Emmanuel a envoyé à l’équipe du Paris JUG son propre pitch pour la soirée d’hier soir. S’en est suivi plusieurs Emmanuel’s facts sur la liste de diffusion du Paris JUG, ce qui était très sympa pour donner un style fun pour une très bonne soirée.

Encore 210 personnes ce soir, sans problèmes. Quelques nouveaux sponsors pour le Paris JUG, comme Ippon Technologies qui devient sponsor Gold par exemple. Le buffet de ce soir est offert par la société DRiMS. Ils ont organisé un tirage au sort entre les 2 présentations afin de faire gagner quelques cadeaux aux juggeurs, ainsi que leur aide pour le buffet. Drims intervient dans différents secteurs sur les pôles MOA, MOE et le décisionnel. Nous sommes toujours content d’avoir de l’aide ponctuellement pour les Buffets, ce qui permet de recevoir 200 personnes et d’animer la soirée.

JDuchess
La soirée débute avec l’arrivée sur scène des JDuchess France. A l’initiative de Mathilde Lemée (Indépendante/blog Java-Freelance.fr) et d’Ellène Dijoux (Xebia France) qui avaient rencontré lors de Devoxx 2009 les JDuchess hollandaises, elles se sont regroupées avec Laure Némée (Leetchi[Updated]) et Claude Falguière (Valtech).

L’objectif du groupe JDuchess France est de proposer un groupe de rencontre aux femmes dans la communauté Java. Mesdames, que vous soyez développeur, architecte, ou autre, vous pouvez venir aux soirées du Paris JUG et être assurée d’être accueillie par une communauté sympa. Mathilde explique que le groupe JDuchess compte 158 membres dans le monde. Pour rappel, il y a 15 user groups en France, plus de 440 dans le monde. Et l’initiative de proposer un site communautaire, et des événements pour les femmes est une très bonne idée.

L’équipe de JDuchess a organisé un Avant-JUG au restaurant le Vavin à 18h30 auxquelles 10 femmes ont participé. C’est aussi la possibilité de parler Java, de parler du métier entre elles, d’assurer une meilleure représentativité de Java auprès des femmes, qui motive le groupe.

Enfin c’est encore un succès pour la communauté et pour les Users Groups. Donc si vous êtes une femme intéressée par Java, et que vous êtes sur Paris, n’hésitez pas à vous inscrire sur le site communautaire de JDuchess. Il y a 8 membres pour l’instant, j’espère que cet article fera venir du monde dans le groupe.

Hibernate Search

Emmanuel Bernard prend ensuite la parole pour nous présenter Hibernate Search. Il travaille chez JBoss RedHat à Paris après un parcours aux USA pendant quelques temps. Emmanuel est un membre de l’équipe de développement d’Hibernate. Il intervient souvent dans différentes conférences, et nous sommes très content qu’il participe régulièrement au Paris JUG. Je pense qu’il a trouvé rapidement sa place depuis septembre dans la communauté parisienne. C’est aussi l’un des auteurs du Podcast sur Java « Les CastCodeurs« , donc le prochain sujet sera sur Oracle et SUN avec la participation d’Alexis Moussine-Pouchkine.

Emmanuel a présenté Hibernate Search ce soir. J’avais vu cette présentation à Jazoon, je vous invite à relire ce que j’écrivais à l’époque. J’ai revu et réécouté celle-ci avec plaisir, Emmanuel ayant ajouté quelques points intéressants.

Sur la présentation, je pense que la partie code a satisfait ceux qui regrettent parfois le niveau trop général des présentations du JUG. Ce soir nous avons vraiment mis le nez dans le moteur. Pendant une heure, tout le monde a découvert la notion de recherche, l’indexation, la construction et l’interrogation des indexes Lucene.

J’aurai aimé un peu plus tard entendre Emmanuel sur le positionnement d’Hibernate Search par rapport au Cloud et JPA. Sur Google App Engine pour mon projet-toujours-pas-terminé « Geek Date » j’avais utilisé Compass. Cela me permet d’indexer les événements à la création et de proposer une zone de recherche full-text multi-critère sur la page d’accueil.

Et le Buffet !
Une soirée JUG c’est 2 conférences et bien entendu, le Buffet. Au sondage pour l’anniversaire du Paris JUG, vous aviez été 70 personnes à répondre, et la place du buffet est très importante pour vous. Charles pourra vous détailler les chiffres, mais voici 2 indicateurs intéressants :

C’est un moment où chacun se rencontre, les discussions s’ouvrent, et où nous sommes content de nous voir.

Si je vous parle du buffet c’est pour vous faire passer une information. Ce soir encore, quelqu’un m’a dit qu’il cherchait un nouveau boulot. Fraichement arrivé à Paris, il lit régulièrement les différents blogs. Il m’a confié qu’il a envoyé son CV aux différents sponsors du Paris JUG car pour lui, ces boîtes représentent les entreprises où il souhaite travailler. C’est-ti pas beau comme histoire ?
Moi je dis +25 points de Bisounours pour le Paris JUG qui contribue à un meilleur monde.

Travailler sur l’écriture d’une API

Emmanuel Bernard présente ensuite un sujet intéressant, et pas forcément évident au premier abord : quelles sont les difficultés et les particularités à prendre en compte lorsque l’on écrit une API ?

Il nous fait partager son expérience tirée du travail en tant que Spec Lead sur la JSR-303 (Bean Validation) et de ses années sur Hibernate Search. L’objectif est de présenter la notion d’API, les difficultés rencontrées, et de nous faire partager son boulot. Ce fut très intéressant, pour une présentation qu’il donnait pour la première fois.

Ecrire une API est un travail de longue haleine. Il y a toujours des personnes mécontentes, et apporter un changement à posteriori est difficile. Lorsqu’il explique ceci, nous prenons tout de suite conscience qu’il s’agit d’un travail à part entière, bien distinct de l’écriture de sa bonne grosse appli de gestion (BGAG). La difficulté de figer à un instant T un ensemble de méthodes et d’objets force celui qui écrit à travailler 5 fois plus qu’un projet classique. C’est donc non pas le volume, mais la qualité du code que l’on recherche ici.

Emmanuel explique que le temps passé est important aussi car une API est destinée… à des êtres humains. Elle doit donc être orientée utilisabilité. Le développement TDD ne suffit pas à assurer une qualité et une cohérence. Il semble que l’itératif soit obligatoire pour réussir.

Ecrire une API vous force à monter en compétences. La notion de DSL apparaît rapidement dans la présentation d’Emmanuel. Il s’agit bien d’utiliser l’expressivité de Java pour décrire comment faire quelque chose. D’ailleurs, la gymnastique sur les Annotations dans Hibernate Search en a surpris plus d’un.

J’ai demandé à Emmanuel s’il avait regardé Scala plus tard dans la soirée. En effet, il parle à la fin de sa présentation de l’avantage des classes Abstraites par rapport aux interfaces. C’est justement la notion de Trait que l’on trouve dans Scala. Le temps de terminer mon deuxième article, vous verrez cela d’ici à la fin de cette semaine.

Pour revenir en arrière, écrire une API est un exercice sportif. Il parle de chuter plusieurs fois pour progresser, comme en Snow board. Il faut mettre en place une stratégie pour proposer à l’utilisateur de nouvelles fonctions, tout en gérant le cas où vous n’êtes pas certain de vous… ce qui arrive souvent. Il faut donc prévenir le développeur que vous êtes susceptible de modifier certaines fonctions.

En fait, c’est l’inverse du @deprecated utilisé pour indiquer qu’une méthode ne doit plus être utilisée dans votre code. Emmanuel tu devrais proposer une annotation comme @candidate, @proposed ou @ChuckNorris.

Crédit photo : Rolf Hiker

Emmanuel présente ensuite quelques exemples de patterns utilisés lors de l’écriture d’API. La partie sur l’utilisation des annotations a certainement comblé le geek le plus obscurantiste de la salle. Il a cependant évité l’effet jantes-alliages tuning avec « regardez mes belles annotations« . Les explications sur le changement des APIs de Mapping étaient vraiment intéressantes. On retient que l’écriture d’API reste un sport de haut niveau, où la maîtrise de Java est vraiment importante.

Emmanuel termine sa présentation en donnant quelques bonnes pratiques. Tout d’abord, si vous écrivez une API sur un projet, il est indispensable de la faire vivre sur des exemples d’intégration. Les tests unitaires ne suffisent pas.

Lors des choix des verbes et des noms de méthodes ou d’objets, travaillez à plusieurs sur vos choix de mots. Car une fois ceux-ci à l’intérieur de l’API, il est difficile de changer. Je pense que sans le savoir, Emmanuel parle de Domain Driven Design. Dans cette pratique, nous travaillons sur la définition de l’Ubiquitous Language. C’est un exercice qui permet de créer une langue commune entre les gens du métier et les développeurs. Dans le cadre du travail sur une API, il faudrait lister les verbes, les noms, dessiner une MindMap de ce que fait l’API. Cela permettrait de s’assurer que les mots sont correctement choisis.

Emmanuel encourage l’utilisation de DSL interne afin de rendre plus facile l’utilisation de l’API. A propos de DSL externe, le plus connu que vous avez tous utilisé sans le savoir est… le langage SQL. Il nous montre l’enchainement de verbes d’actions et d’adjectifs pour la définition de la configuration dans Hibernate Search. Je crois qu’il s’agit du pattern Builder si je ne dis pas de bêtises. Plus facile à mettre en oeuvre avec Groovy que Java.

Une astuce aussi pour l’API est de penser « comportement par défaut ». Ne demandez pas à vos utilisateurs de déclarer trop de paramètres qui ne changent pas ou peu. Il montre un exemple avec Hibernate Search où l’API s’arrange pour se configurer avec un comportement par défaut, afin d’alléger la quantité de code. Cela rend l’API plus Agile.

Conclusion et 3ème mi-temps
Emmanuel a bien animé la soirée. Les 2 sujets étaient intéressants. C’est un bon speaker qui fait passer son message, sans fioritures. Il a même répondu aux questions posés sur la Wave d’Olivier Croisier lorsque nous étions au restaurant. C’était vraiment sympa de sa part.

Si j’avais un truc à demander à Emmanuel, ce serait d’ajouter quelques images dans ses slides pour appuyer ses idées.

Documentez l’utilisation de votre API

Crédit photo : penguin http://www.flickr.com/photos/48600074504@N01/

Pensez au pattern Adaptor

Crédit photo : DeaPeaJay http://www.flickr.com/photos/deapeajay/2969264395/

Votre API doit être simple à utiliser

Crédit photo 1D110 http://www.flickr.com/photos/22297595@N02/

Note : les photos de cet article sont en licence Commons Creatives, trouvées sur FlickR.

James Gosling, l’un des inventeurs de Java, a dit à propos de Scala la phrase suivante :

« If I were to pick a language to use today other than Java, it would be Scala »

Plus suprenant, James Strachan qui a initié le langage Groovy en 2004, a dit aussi à propos de Scala :

« I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy. »

Le langage a été initié en 2003. Scala (pour Scalable Language) a été pensé pour la programmation multi-threads, avec un niveau de qualité assez impressionnant. J’aime ce langage car au final, ce sera toujours du bytecode dans une machine virtuelle Java.
C’est un langage orienté objet avec une teinte de programmation fonctionnelle. Créé en 2003 par Martin Odersky, Scala est supporté par l’EPFL (Ecole Polytechnique Fédérale de Lausanne). Typé statiquement, il propose par exemple une inférence de type très puissante, qui rend la programmation Java « old-school » dès lors que l’on débute en Scala.

Scala est concis
Le langage est très concis. Prenons par exemple un BVOJTP (Bon Vieil Objet Java Tout Pourri) et voyons ce que cela donne dans sa version Scala. Je prends par exemple un simple Bean « Person » avec quelques attributs.

La version Java

public class PersonInJava {
    private String firstName;
    private String lastName;
    private Date dateOfBirth;

    public PersonInJava(String firstName, String lastName, Date dateOfBirth) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.dateOfBirth = dateOfBirth;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public Date getDateOfBirth() {
        return dateOfBirth;
    }

    public void setDateOfBirth(Date dateOfBirth) {
        this.dateOfBirth = dateOfBirth;
    }
}

La version Scala :

class PersonInScala(val firstName: String, val lastName: String, val dateOfBirth: Date) 

Et oui… par défaut il n’est pas nécessaire de déclarer les getters/setters, ni de constructeur par exemple.

Inférence de types
Scala est capable de deviner les types associés à des expressions automatiquement (voir la définition del’inférence de types). Cela permet de conserver un type fort en interne, tout en allégeant le code source.

var year: Int = 2010
var anotherYear = 2010 

var helloBuddy = "Salut !" 

var builder = new StringBuilder("Bonjour")

println(builder.getClass())

La première variable est définie comme étant de type Int. Remarquez ensuite que la variable anotherYear est définie sans spécifier de type. Scala infère le type en Int automatiquement grâce à la valeur que nous avons assignée à cette variable. Ce type est définitif, il s’agit bien d’un type statique.

Si par exemple j’essaye d’affecter une String un peu plus tard à ma variable anotherYear alors Scala me signale à la compilation qu’il y a un souci :

var anotherYear=2010
anotherYear="This is a String"

(je compile le code...)

!!!
discarding 

Pour revenir un peu plus haut, la variable helloBuddy est inférée en java.lang.String automatiquement, et la variable builder en StringBuilder. Dans la pratique, pour un développeur Java il n’y a pas grand chose à faire. Il reste possible de typer ses variables, mais cela ne devient plus indispensable. Enfin la vérification à la compilation nous épargne les soucis de transtypage à la Java et certainement quelques soucis comme avec un langage dynamique.

Programmation fonctionnelle
Je ne vous donnerai qu’un aperçu car c’est un sujet vaste. En Scala il est possible de créer des fonctions à l’intérieur de fonctions, de passer des méthodes en paramètres à d’autres méthodes, bref les fonctions en Scala sont des Objets à part entière. Nous retrouvons la notion de pointeur de fonctions en quelques sortes.

La programmation fonctionnelle sera présenté en Avril au Paris JUG, ainsi que Scala d’ailleurs. Cela vous donnera l’occasion de voir un peu ce que cela peut vous apporter en tant que vieux Java-iste.

Prenons un exemple tiré du livre « Programming Scala » écrit par V.Subramaniam. Ecrivez une fonction qui effectue la somme d’une suite de nombre sur une plage passée en argument. Voici la version Java :

public int sum(int number) {
  int result = 0;
  for(int i = 1; i < = number; i++) {
         result += i;
  }
  return result;
}

Comment feriez-vous si je vous demande maintenant de faire l'addition des nombres pairs uniquement ? En Java vous feriez une copie de cette méthode, pour en créer une nouvelle, avec votre algo. En Scala, il est possible de passer une méthode en paramètre. Nous allons donc extraire la logique de la sélection des valeurs, et la définir à l'extérieur.
Des fonctions qui prennent en paramètre d'autres fonctions sont appelées "higher-order function". En Scala vous pouvez créer des fonctions à l'intérieur d'autres fonctions, les passer en paramètre et les assigner à des références.

Voici une version en Scala pour itérer sur une plage de valeur. Pour chaque valeur nous allons appeler la fonction référencée par codeBlock qui retourne un Int.

def totalResultOverRange(number: Int, codeBlock: Int => Int) : Int = {
 var result = 0
 for (i < - 1 to number) {
     result += codeBlock(i)
  }
  result
}

Donc pour effectuer la somme de valeur, nous pourrons appeler la fonction en spécifiant une fonction d'addition très simple :

// Sum up to 10
println(totalResultOverRange(11, i => i))

Le premier argument, 11, est la limite supérieure de notre série. Le second argument est une fonction anonyme qui prend en argument un type et qui le retourne sans modification. Notez qu’ici nous ne précisons pas le type Int, il sera inféré par Scala au moment voulu en examinant la signature de la méthode totalResultOverRange.

Si je vous demande maintenant d’effectuer la somme des nombres pairs uniquement dans la série, voici comment nous écrirons en Scala cet appel:

println(totalResultOverRange(11, i => if (i % 2 == 0) 1 else 0))

Si le modulo 2 du compteur courant est égal à 0, alors nous retournons 1 pour vrai, sinon 0.

Il est bien entendu possible de définir des Closures. Ici nous définissons une variable closure qui sera un pointeur vers une méthode.

def loopThrough(number: Int)(closure: Int => Unit) {
  for (i < - 1 to number) {
     closure(i)
   }
}

Voici un exemple d'utilisation :

var result = 0
val addIt = { value:Int => result += value }

Dans ces quelques lignes ci-dessus je crée une variable « addIt » qui est un bout de code pour effectuer l’accumulation de deux valeurs. Notez que la variable result n’est pas définie dans ce bloc ni comme paramètre. En fait cette variable est branchée à la variable result en dehors du bloc de code. Je pense qu’un exemple sera plus parlant pour expliquer cette subtilité :

var result = 0
val addIt = { value:Int => result += value }

loopThrough(10) { addIt }
println("Total of values from 1 to 10 is " + result)

result = 0
loopThrough(5) { addIt }
println("Total of values from 1 to 5 is " + result)

// Execution
Total of values from 1 to 10 is 55
Total of values from 1 to 5 is 15

Comprenez qu’une Closure est un bloc de code qui s’exécute dans un contexte, tout en étant capable de modifier des variables externes. Lorsque j’appelle la méthode loopThrough() en spécifiant une closure, la variable result est vue comme une variable globale. Lorsque je remet à 0 la variable, la closure le « voit » aussi et débute à nouveau l’itération de 0. Il est possible aussi de n’utiliser que des variables locales pour ne pas avoir cet effet bien entendu. C’est la vraie notion de Closure, où les variables d’une portée plus importante sont vues localement au sein de la fonction.

Conclusion de cette première partie
Scala est donc un langage fortement typé, capable de faire de l’inférence de types, avec une manipulation des fonctions très puissante, et la possibilité d’utiliser des Closures.

En Scala, tout est objet. Un nombre comme « 2″ est un objet sur lequel il est possible d’appeler une fonction. Les fonctions sont des objets, que vous passez en paramètre, afin d’exécuter des traitements fonctionnels.

Nous verrons la prochaine fois les Traits et les Collections, puis nous parlerons de programmation concurrente avec les Actors.

Je vous recommande la lecture de « Programming Scala » écrit par V.Subramaniam. Ce livre a été pensé pour des développeurs Java qui souhaitent apprendre rapidement Scala.

Je pense qu’il ne faut que quelques semaines pour être opérationnel. Il y a le risque de faire du « Java-like » avec Scala, comme nous faisions du C à la place du C++. Mais je pense cependant que vu la maturité du langage, la quantité de documentations et de livres disponibles, nous pouvons éviter de tomber dans ce piège.

Alexandre Bertails a préparé la version Scala de mon article sur le XML et Groovy. Vous verrez différentes versions d’ici quelques jours, le temps de terminer les 2 autres articles sur Scala.

Bon, je pose le crayon deux secondes, j’ai besoin de toute votre attention. Eteignez Twitter, fermez Gmail, écoutez-moi : vous allez apprendre Scala. C’est un ordre. Si vous ne voulez pas être sur le côté de la route lorsque les petits jeunes roulant en Scala Bac+5 passerons à côté de vous, bougez-vous. Achetez un livre, prenez le temps de vous former à nouveau.

Etre bon en Spring, Hibernate, GWT c’est bien. Maintenant ce qui va faire la différence, ce sera la capacité à proposer sur le marché d’autres langages pour répondre aux clients. N’oubliez pas ce que j’ai dit au début : Scala c’est du bytecode qui tourne dans une JVM. Donc pas d’excuses, vous me ferez 2 séries d’abdos, et ensuite vous filez en formation Scala.

Non mais !

Rendez-vous le mardi 23 mars 2010 à 19h00.

Salut,

Voilà je m’appelle Nicolas, je prépare une présentation sur les communautés et les tribus dans le monde informatique, plus particulièrement dans notre univers à nous, les Geeks.

Là c’est là que tu entres sur scène, car j’ai besoin de toi. Je cherche à faire un maximum de bruit afin de diffuser ce sondage à des développeurs, à des salariés de SSII, à des équipes logicielles chez des éditeurs, afin d’évaluer les attentes de chacun par rapport à l’esprit communautaire.

Je n’en dis pas plus pour ne pas vous influencer, mais je vous ferai part des résultats du sondage bien entendu.

Donc voici ce que je te demande : peux-tu exceptionnellement diffuser cet article à tes connaissances afin qu’elles y répondent ? Alors je ne parle pas de tes copines sur Facebook, mais bien de tes VRAIS amis, ces barbus avec un teeshirt Linux qui codent jusqu’au petit matin, un carton de Pizza Hut posé sur le bureau.

Je compte sur toi,

Nicolas Martignole

URL du formulaire : https://spreadsheets.google.com/viewform?hl=fr&formkey=dGstcFg2bE9WVGE4eU5vbl9wSGt4bWc6MA
—————–

Répondre en ligne directement

Tu peux aussi répondre en ligne directement ci-dessous :

Ce qui frappe aujourd’hui c’est avant tout le changement de génération dans le monde du développeur. Je pense qu’il y a eu un creux sur le nombre de développeurs en France il y a quelques années. J’ai entendu que le développement était sale, que les jeunes diplômés délaissaient la voie sacrée du Développeur pour prendre d’autres chemins. Cela donne, et moi le premier, de jeunes trentenaires dans la force de l’âge, aveuglé comme des moustiques autour d’un lampadaire, d’un néon où il y aurait marqué « Chef de Projet ». Passé les quelques mois, combien d’entre vous découvrent la dur réalité de cette tâche ? Gérer un projet c’est facile. Gérer des hommes, ça c’est amusant.

La difficulté du jeune manager, et qui veut piloter une équipe, c’est avant vous, les 25-35 ans, que l’on appelle « Génération Y« . Or je me demande si les méthodes de gestion et de management ont évolué aussi vite que nous.

La génération Y est cette tranche d’âge de 25-35 ans, qui débarque dans le monde du travail, bien déterminé à faire sa place. Basé sur la méritocratie, cette génération ne respecte ses pères que lorsque ceux-ci sont légitimes. Que ce soit avec un charisme, de l’expérience, ou une réelle capacité à mener des personnes, il n’est pas rare de voir quelques oiseaux capable de gérer correctement une équipe.
Et puis il y a les autres…

Alors disons qu’il y a ceux qui se sont pris un coup de foudre. Un matin je me réveille et je décide de grimper dans la chaîne alimentaire de l’entreprise. Les motivations les plus diverses font que les gens veulent devenir « chef de… ». C’est parfois pour masquer un lourd handicap et une réelle incompétence technique. C’est parfois pour payer le crédit du Citronault Picasso. C’est parfois une fuite en avant… Mais sont-ils heureux pour autant ?

Le management de premier niveau, les premiers « chefs », sont parait-il les responsables du Stress de premier niveau (source). A quand en effet, non pas un Bonus indexé sur votre capacité à délivrer un logiciel, mais un bonus social voté par votre équipe selon votre performance de manager ? Mince alors. Après tout, délivrer un logiciel, c’est ce pour quoi vous êtes payé. Ensuite, être capable de gérer des personnes, de les aider sans les stresser, c’est sacrément plus dur que de faire mumuse avec Microsoft Project non ? A quand une nouvelle application dans Microsoft Office pour suivre le stress de vos collaborateurs ?

L’Esprit d’équipe… Si chaque équipe avait un budget illimité, bien entendu que la vie serait plus facile. Mais pourtant il existe un bon nombre de moyens simples pour transformer une équipe qui dort en une équipe qui s’amuse, qui se marre et qui avance.

Prenez les méthodes Agiles. Il y a ceux qui hésitent à changer et qui veulent d’abord comprendre si l’Agilité est faite pour eux. Et il y a les autres, qui changent de méthode, et qui ensuite comprennent qu’il fallait changer pour avancer. C’est l’exemple type où il faut se jeter dans le grand bain, boire une bonne tasse, et ensuite seulement commencer à avancer et à reconstruire quelque chose. Mettre en place une nouvelle méthode c’est bien. Mais si vous n’avez pas d’Esprit d’équipe, c’est dangereux.

J’avais parlé il y a longtemps de la difficulté à créer une équipe de développement. Il est important de mélanger les types de développeurs. Dans la réalité il faut composer avec un existant, avec un capital humain. Allez je le dis… il faut gérer le « Legacy Humain« . Mais cela n’empêche pas d’apprendre quelques techniques pour qu’une équipe marche.

Trouver de bons développeurs c’est d’abord la cooptation. Donnez 3000 EUR si l’un de vos gars trouve la perle rare, et que celle-ci passe le cap de la période d’essai. Ce n’est que 5 semaines d’annonces sur un site de recherche d’emploi… Une paille.

Le développeur est un animal grégaire, qui migre de sociétés en sociétés tous les 3 ans en moyenne. Des personnes avec 10 ans d’expérience en Java ont au moins fait 2 voir 3 sociétés. Elles ont rencontré du monde. Et elles ont des amis. Une sorte de FaceBook, mais en vrai. Et ce qui devient intéressant, c’est aussi leur capacité à vous proposer de bons profils. Un peu comme une équipe où chacun connaît ses points forts et ses faiblesses, les +10 ans se baladent avec un réseau de connaissance assez important.
C’est un réseau qui dort. Si vous n’êtes pas inscrit sur Viadeo ou LinkedIn, je ne peux rien pour vous. Comme un bon petit jardinier, vous devez cultiver votre réseau d’amis. N’acceptez pas non plus le tout venant. Ces réseaux professionnels ne sont pas des réseaux de « copains » comme FaceBook ou « Copains d’avant ». Avoir 13450 amis c’est stupide. En avoir aucun, c’est dommage.

Là où je voulais en venir au départ, c’était de vous parler d’Esprit d’équipe car je prépare un sujet de conférence sur les Communautés, comme catalyseur pour l’Entreprise. Comment les groupes d’utilisateurs dynamisent le marché ? Comment un esprit communautaire peut-il se créer entre les consultants d’une entreprise ? Comment les développeurs Java d’un éditeur de 650 personnes peuvent-ils créer une communauté ?

Esprit es-tu là ?

Es-tu quelqu’un ou non ?