Codeurs en Seine 2015 : la conférence pour les développeurs

Cette année, Codeurs en Seine a démarré avec une demi-heure de retard, l’alarme incendie s’étant déclenchée de manière impromptue aux alentours de 9 h !
Les 500 participants se sont donc retrouvés 20 minutes dans le froid (mais sous le soleil) avant de retourner au chaud assister à la keynote de Laure Nemée.

Dans cet article, nous vous proposons un résumé de certaines des conférences auxquelles nous avons assisté et qui nous ont marqués.

Introduction

Les organisateurs nous ont brièvement présenté le principe de la conférence : elle est gratuite depuis le début et le restera. On a également noté que la ligne éditoriale de la conférence est divisée en thèmes complémentaires qui ont été construits par les tissus associatifs de l’industrie informatique de la région :

• Web : Normandie Web Expert (nwx.fr) ;
• Agilité : Normandy Agile User Group ;
• Java : Normandy JUG.

Enfin la conférence est hébergée par le département d’informatique de l’université de Rouen qui dispose d’amphithéâtres de grande qualité.

Keynote

C’est Laure Némée, CTO de Leetchi qui a ouvert le bal autour des enjeux du poste et plus particulièrement en startup.
Laure nous a brièvement résumé les activités de Leetchi :

1. le site web grand public met en œuvre le principe de cagnotte à plusieurs ;
2. un service B2B nommé mangopay, certifié émetteur de monnaie électronique et dédié aux paiements pour les places de marché et le crowdfunding.

Leetchi est une société d’environ 40 salariés et qui a 6 ans. Elle a été rachetée par Crédit Mutuel Arkea et bénéficie dorénavant de fonds d’investissements importants.

Ce que Laure a appris sur le développement

Dans une startup, ce qui compte vraiment c’est le produit. Les choix technologiques ne doivent en aucun cas interférer avec le développement du produit. Les développeurs n’ont pas le temps de réinventer la roue. C’est pourquoi il faut adopter une attitude très conservatrice sur les technologies en regardant avec attention la perennité ou l’aspect légal sur les licences sans toutefois négliger les montées de versions.

Sur le fameux triangle good/cheap/fast, on n’a le droit qu’à deux des éléments. Chez Leetchi et selon Laure, certains choix faits en 2011 se paient encore aujourd’hui.
De fait, la tendance naturelle d’un développeur est souvent de recommencer à zéro lorsqu’il rencontre du code legacy (Laure n’a toutefois pas défini ce qu’est un code legacy – on supposera qu’il s’agit d’un code vieux). Cette attitude est dangereuse car cela veut dire nier toute l’expérience acquise durant toutes les années où ce code tournait en production. C’est pourquoi Leetchi a appris à travailler dans la continuité : pas de big bang. Par exemple lorsqu’ils ont souhaité faire évoluer le front en responsive, ils ont dû changer le moteur de templating. Leur stratégie a été de faire coexister les deux solutions pour permettre une migration au fil de l’eau.

Ce que Laure a appris sur la production

Quand on vient du monde du développement, on ne connait pas la production. Chez Leetchi, les contraintes de qualité de service sont fortes. Au début, ce sont les développeurs qui se sont occupés de la production puis une équipe d’administrateurs système a été recrutée. Ils ont évidemment mis en place du monitoring (aujourd’hui le monitoring est partout chez Leetchi : ils surveillent par exemple les dates d’expiration de leurs certificats SSL).

Pour un développeur, il est intéressant de travailler avec un administrateur car il aborde les sujets de manière complètement différente. Par exemple, lorsque le besoin d’analyse syntaxique de logs est apparu chez Leetchi, les développeurs ont d’abord réalisé un POC mais ce dernier n’a pas tenu la comparaison avec logstash, prôné par les administrateurs.

Leetchi a appris à s’améliorer sur la qualité de service avec un objectif zero downtime. Voici l’évolution de leurs mises en production :

1. mise en production avec arrêt du service ;
2. mise à jour serveur par serveur ;
3. mise en production et migration des données en continu.

La même démarche a été appliquée à la redondance de leurs services. Aujourd’hui ils souhaitent redonder leur infrastructure sur un second datacenter.

Ce que Laure a appris sur l’équipe

Quand on devient CTO alors que l’on a été unique développeur, chargée de l’avant vente et administrateur système au démarrage de la société, il faut apprendre à déléguer et à recruter.

Au démarrage, le recrutement chez Leetchi a consisté à convaincre des gens de venir travailler dans une entreprise avec une COO et une CTO. La conséquence selon Laure a été de recruter des gens plus ouverts, plus progressistes. C’est une force de l’équipe actuelle à tel point que les départs sont quasi inexistants !

Le rôle d’un CTO est de donner un cadre de travail pour que les gens avancent dans l’entreprise. Il faut apprendre à faire confiance, spécialement quand on a 10 personnes à manager. Il faut être très clair sur ce qu’elles doivent faire. Il faut également s’adapter aux habitudes de travail de chacun. Passer du faire au faire-faire, ça veut aussi dire perdre des compétences. Bref, faire le lien entre les différents sujets et les personnes.

Conclusion

Travailler en startup est une chance : la maturité de la société s’acquiert au fur et à mesure. C’est très enrichissant.

Questions

Qu’est-ce qui, selon Laure, a valu le succès de Leetchi alors que 3 challengers se sont lancés en même temps ?

C’est l’attention au produit et au retour des utilisateurs permanent. Le fait qu’il n’y ait pas eu beaucoup de turn-over a aussi bien aidé.

Comment Leetchi parvient à faire du DevOps avec succès ?

C’est précisément le rôle du CTO qui doit encourager au maximum la communication. Chez Leetchi, les administrateurs sont au Luxembourg alors que les développeurs sont à Paris. Leetchi utilise Slack depuis un an avec succès et organise des échanges physiques entre les équipes : certains administrateurs vont à Paris, certains développeurs vont au Luxembourg.

Test Driven Infrastructure avec Docker

Mario Loriedo est venu nous présenter « docker-unit », le JUnit pour Docker qu’il développe actuellement. Basé sur le projet « dockramp », l’objectif de cette bibliothèque est de vous permettre de pratiquer le Test Driven Development lorsque vous allez écrire vos Dockerfile.

1.  RED : on écrit une assertion qui échoue dans un fichier séparé.
2.  GREEN : on fait passer le test, en écrivant le code dans le fichier « Dockerfile ».
3.  REFACTOR : on réusine le code du Dockerfile.

Une première approche sans docker-unit serait de rajouter directement les assertions des tests dans le Dockerfile. Elle présente deux inconvénients :

•  Les tests ne sont pas indépendants.
•  Les tests produisent des effets de bords.

Pour comprendre ces effets de bords, il faut comprendre le fonctionnement du build Docker.
Chaque ligne d’un Dockerfile représente en réalité une couche composant l’image finale. Et chaque ligne exécute 3 étapes :

1. La création d’un conteneur temporaire (en lecture/écriture).
2. Un commit de cette couche (qui passe en lecture seule).
3. Une suppression du conteneur temporaire.

Idéalement, il faudrait pouvoir s’abstenir de la deuxième étape pour les tests. C’est ce que propose de faire « docker-unit ». L’idée étant d’injecter les assertions qu’on va décrire dans un fichier « Dockerfile_test » avant ou après l’execution d’une ligne du fichier « Dockerfile » via un matching réalisé sur le début du nom de l’étape. Si jamais une assertion échoue, le build s’arrête.

Puisqu’un exemple vaut mieux qu’un long discours :

L’idée d’appliquer à Docker des pratiques Craft qui ont fait leur preuve dans le monde du développement est très séduisante. D’une part, on sait que sans tests automatisés, le coup d’un changement augmente de manière exponentielle. D’autre part, la pratique du TDD permet de réfléchir à ce que l’on veut avant de commencer à développer. Même si l’outil est encore jeune et en mode « Proof Of Concept », Mario Loriedo travaille aujourd’hui directement avec Docker pour en assurer la pérennité. À suivre !

Domain Driven Design pour de vrai

Une conférence sans Cyrille, c’est rare ! Et si tel est le cas, c’est bien de par la qualité de ses présentations, sa réputation n’ayant pas faillie durant ce Codeurs en Seine 2015. Au programme du jour, outre les chatons (sic), le Domain Driven Design, pour de vrai.

Cyrille nous a d’abord rappelé que le DDD n’était pas forcément pour tout le monde. De son observation, rares sont les développeurs à s’y intéresser avant 7 ans d’expérience. Et pour cause, il faut une certaine appétence pour le métier soutenu par le(s) logiciel(s) que l’on développe. Cette appétence peut évidemment venir avec le temps.

D’autre part, il faut se demander s’il est utile dans votre contexte. Autrement dit si :

•  le risque du projet se trouve dans le métier au travers de sa complexité ;
•  si la valeur est dans le métier.

En d’autres termes, vous n’en tirerez pas un grand bénéfice si vous cherchez à l’appliquer sur un bon vieux logiciel de type CRUD. Il faut un minimum de richesse et de complexité ainsi que des experts métiers. En ce sens, démarrer avec des exemples concrets est un bon début (le BDD est votre meilleur ami pour débuter avec le DDD).

Au cours de sa présentation, Cyrille est parti de problèmes constatés pour introduire les patterns du DDD y répondant.

Problème nº 1 – Confusion as a Service

Dans un premier temps, il a évoqué le « Confusion as a Service ». Autrement dit, la perte de temps engendrée par les traductions systématiques entre les différentes parties prenantes, aucune ne parlant le même langage. La solution consiste à introduire un langage omniprésent (Ubiquitous Language – talk the domain language) y compris dans le code avec des termes faciles à retrouver, prononçables et sans abréviations. Pour s’assurer que votre application reflète bien le métier qu’elle supporte, il est possible d’extraire un nuage de termes (tag cloud) de votre code en enlevant la syntaxe de votre langage. Le résultat doit traduire votre métier ; si ce n’est pas le cas, votre langage n’est pas suffisamment omniprésent. Les objects calisthenics peuvent s’avérer utiles pour mener à bien votre mission.

Problème nº 2 – Code gravity

Dans un second temps, Cyrille a abordé la lourdeur du code bien plus connue sous la forme du fameux MainController qui contient plus de 6000 lignes, 40 méthodes et 35 attributs…

 « Big stuff attracts even more stuff and gets bigger »

La solution consiste à modéliser le domaine métier et à mener des refactorings basés sur la connaissance de ce dernier. Pour vérifier sa bonne mise en œuvre, faites le test suivant avec vos nouveaux venus. Donnez leur le code de votre application ; ils doivent comprendre les rudiments du métier en le parcourant. Évidemment, il existe un lien fort entre métier et technique. Cependant, ce sont bien les choix métiers qui conduisent aux modifications techniques.

Problème nº 3 – Code mess

Enfin, nous nous sommes intéressés au « code mess » qui est souvent la conséquence d’un manque de connaissance métier. Le cas classique est celui de la gestion des adresses de livraison/facturation d’un client. On se retrouve souvent avec la modélisation suivante, induite par le cas particulier où l’adresse de livraison est la même que celle de facturation.

[java]public class Client {
private final String name;
private final String address;
private final String city;
private final String zipCode;
private final String address2;
private final String city2;
private final String zipCode2;
}[/java]

Ici, la solution consiste à casser cette représentation en 3 contextes bornés (bounded context).

[java]// 1st bounded context: Customer management
public class Client {
private final String name;
}
 
// 2nd bounded context: Billing
public class Account {
private final String address;
private final String city;
private final String zipCode;
}
 
// 3rd bounded context: Delivery
public class Recipient {
private final String address;
private final String city;
private final String zipCode;
}[/java]

Plus largement, les vues conflictuelles des parties prenantes ou les synonymes (client, compte, destinataire) sont des indices suggérant des contextes séparés. De même, des groupes de champs qui ne sont jamais utilisés en même temps. En bonus, un tel découpage permet d’adapter la technique au plus fin (par exemple pour la persistance).

Conclusion

Pour conclure, « le DDD, mangez-en » (dixit Cyrille). D’autant plus qu’il ne nécessite aucune bibliothèque, aucun framework et qu’il est agnostique aux langages.
C’est un formidable moyen de découvrir/d’assouvir votre appétence pour le métier lié à votre application.

Concevoir la navigation sur mobile

Après avoir suivi une conférence technique, il est temps d’enchainer avec une conférence liée à l’expérience utilisateur. Amélie Boucher, oratrice très dynamique, ne nous a pas laissé le temps de nous ennuyer avec sa présentation à propos de la navigation sur mobile.

Concevoir la navigation sur mobile passe avant tout par comprendre ce qu’implique naviguer sur mobile. L’utilisateur de smartphone est par nature très volatile. Les problèmes de réseaux, le papillonnage ou encore les ruptures comme un coup de fil par exemple, font qu’un trop grand temps d’attente ou une navigation pénible représente un risque que l’utilisateur s’en aille. Se tromper sur mobile est bien plus impactant que se tromper sur un site web. Une bonne navigation c’est donc une navigation qui sait se faire oublier et laisse plus de disponibilités mentales pour que l’utilisateur consomme du contenu. L’idée c’est d’aller vite et bien.

Traditionnellement, en raison du peu de place disponible sur l’écran, les architectures mobiles sont plutôt de type « profonde », c’est à dire qu’elles contiennent beaucoup d’écrans de navigation pour atteindre le contenu souhaité. Pour améliorer la navigation il faut donc réussir à atténuer la perception de la profondeur et atteindre des architectures dites « plates ». Pour cela, il faut favoriser les usages clés (architectures plates) et dévaloriser les usages accessoires (architectures profondes). De plus il faut être capable de se mettre à la place d’un utilisateur lambda et tester le parcours en condition réelle.

En ce qui concerne l’onboarding d’un utilisateur, figure souvent imposée, il vaut mieux le réserver à des éléments stratégiques ou discriminants et le replacer dans le contexte d’utilisation. Il vaut mieux attendre l’engagement de l’utilisateur au lieu de sur-proposer. Amélie appelle ça le « Just In Time Education ».

Ensuite, Amélie nous a parlé du match « Menu Visible vs Menu Caché ». Comme on peut s’en douter, le choix dépendra du contexte. On utilisera un menu visible si l’on souhaite avoir un pouvoir suggestif ou que l’on a un besoin d’efficience fort, comme par exemple l’icône pour prendre une photo dans Instagram. A l’inverse, si le menu ne contient rien de stratégique, qu’il est long ou que l’utilisateur se doute que la fonctionnalité s’y trouvera, on peut utiliser un menu caché. Par contre, pour l’indiquer, il vaut mieux utiliser un pictogramme conventionnel et visible. On peut aussi utiliser un pictogramme représentant le contenu s’il est homogène et ajouter un libellé.

En ce qui concerne les gestes, rien ne sert de commencer son application en les imaginant. Il faut avant tout penser usage ! Les gestes sont très intéressants mais sont souvent difficiles à découvrir et doivent donc être doublés.

En bref, c’était une présentation rythmée et très enrichissante, pleine de do et don’t illustrés par des applications réelles. En voici la conclusion en image :

Keynote – Bidouillabilité à l’ère du Cloud

Pour démarrer l’après-midi, Tristan nous a d’abord plongés au début des années 80, lorsqu’il a commencé l’informatique. A cette époque, il travaillait sur un Apple II qui était facilement « bidouillable ». Puis, petit à petit sont apparus le minitel, le logiciel libre, le web et avec eux les communautés virtuelles, permettant une collaboration à grande échelle. On se trouvait alors dans un cercle vertueux où le libre renforce le développement de l’internet et où ce développement renforce le libre. Les exemples de cette collaboration sont nombreux, Wikipédia ou Linux en têtes de proues.

A cette époque, on avait le sentiment d’être tout puissants en ayant construit sur les bases des autres (« Nanos, gigantium humeris insidentes » – Des nains debouts sur les épaules des géants »). Surtout, on pouvait avoir une vraie maitrise de son logiciel, de sa machine et de ses données.

Puis sont arrivés les smartphones et les SaaS, devenus aujourd’hui très courants et demeurant pour la plupart gratuits. Actuellement, on se retrouve avec 3 ordinateurs: PC, Smartphone & Cloud.
Sauf que ce dernier n’existe pas ! Il s’agit nécessairement de l’ordinateur de quelqu’un d’autre avec pour conséquence principale un abandon total de maitrise.

A la question « qui utilise GMail/Google Maps », les mains ont été nombreuses à se lever (la quasi-totalité des 500 participants). Tristan nous alors amené à nous interroger sur le modèle business de ces SaaS; in fine, le client est celui qui paye pour obtenir les données que nous fournissons plus ou moins sciemment. Les grands du Web (Google, Facebook, Twitter & al.) et la centralisation des données qu’ils engendrent rendent finalement possible la surveillance de masse. Et ceci alors que l’IOT n’en est qu’à ses balbutiements…

Dès lors, que faire pour se rebiffer ?
Tristan propose 7 principes regroupés sous l’acronyme SIRCUS (Système d’Information Rendant le Contrôle aux UtilisateurS).

•  Se débarrasser de la publicité ciblée qui permet la gratuité.
•  Utiliser du matériel que l’on contrôle (rendu peu couteux et consommateur d’énergie par les économies d’échelle du mobile).
•  Utiliser du logiciel libre (auditable, transparent, adaptable).
•  Utiliser du chiffrement (Let’s Encrypt is coming…).
•  Avoir une expérience utilisateur délicieuse.
•  Avoir une interopérabilité grâce aux standards.
•  Avoir une « killer feature »; le truc que les SaaS ne pourront jamais fournir (la plus difficile de ces 7 étapes).

Évidemment, toutes ces étapes ne peuvent être mises en œuvre simultanément et rien n’empêche d’avancer petit à petit.

In fine, Tristan nous a proposé une démonstration de Cozy Cloud, une solution se proposant de répondre à la problématique évoquée lors de cette keynote d’un excellent niveau, sous forme d’électrochoc, qui n’était pas sans rappeler celle d’Eric Fillol à Devoxx France 2015.

CQRS + EventSourcing : on en entend parler, nous le codons en live !

Les frères Le Merdy (Eric et Sébastian) nous on proposés un live-coding de haute volée boosté par un usage intensif et avancé de l’IDE.

L’idée ? Prendre un code legacy et y introduire une dose d’Event Sourcing et de CQRS.
Leur terrain de jeu ? Le Kata de refactoring Trivia, une sorte de Trivial Poursuit où les joueurs répondent à des questions pour gagner des points.

La 1^re étape du refactoring consiste à faire émerger les évènements et c’est en se basant sur les logs de la sortie console qu’ils vont y parvenir.
Un évènement est un objet immuable qui contient des informations; on parle de Value Object. Le type est nommé en utilisant la forme passive.

La 2^e étape du refactoring vient introduire la notion d’Event Store, dont le rôle est de capturer et de persister les évènements.

Ensuite vient l’introduction de CQRS (Command Query Responsibility Segregation) dont le but est de séparer les méthodes qui ont des effets de bord (les Commandes, en écriture), des méthodes qui servent à la récupération de l’information (les Query, en lecture). Chacune des méthodes va implémenter une interface spécifique. Un anti-pattern classique : une méthode fait à la fois de l’écriture et de la lecture.

Enfin vient le moment où CQRS est relié à l’Event Sourcing. Maintenant que beaucoup d’évènements ont été émis, il vont servir à la mise à jour de l’état interne du système. Pour ce faire, une implémentation à base d’Event Listener permet d’écouter les évènements et de produire les effets de bord en conséquence. En résumé, le système est stimulé à l’aide de commandes, qui vont produire des évènements. Ces évènements vont eux-mêmes être écoutés et produire des effets de bord, comme par exemple la mise à jour d’une vue en lecture.

Le dernier point abordé réside dans l’un des intérêts de l’Event Sourcing : rejouer le passé. Que ce soit pour comprendre un problème ou tester de nouveaux parcours, l’Event Sourcing va nous permettre de facilement reconstituer le passé, en rejouant les évènements. En cas de fortes volumétries en revanche, on va vouloir réaliser des snapshots afin de pouvoir restaurer facilement l’état du système à un instant T. La stratégie pour prendre les snapshots sera à déterminer en fonction du contexte, mais on imagine facilement réaliser un snapshot tous les X heures, ou tous les X évènements.

En conclusion, l’Event Sourcing et CQRS c’est bon, mangez-en aussi même si cela a tout de même un coût.
Il faut donc utiliser ce type d’architecture uniquement si vous en avez réellement l’utilité sur votre projet.

OMG! Terminator sera codé en JavaScript !

Cette présentation est introduite par un avertissement assez clair : le titre a été imaginé pour se faire choisir lors du call for paper. Donc Philippe Charrière a dû inventer un fil directeur autour du titre à postériori. Autre avertissement en préambule : ce qui est présenté ne doit pas être mis en production. C’est sur son temps libre que Philippe travaille sur ses objets connectés.

Le thème de cette démonstration était de construire un robot nommé Bob, constitué d’un cerveau, d’un module d’expression, d’un module sensoriel et enfin d’un module de déplacement ; le tout en JavaScript.

1. cerveau : il s’agit d’un raspberry dans lequel on instancie un broker de messages MQTT MQTT.js. Après avoir rappelé la base du protocole MQTT, Philippe se connecte à son raspberry en ssh et démarre brain.js. Le code de ce module NodeJS écoute un topic et réagi en renvoyant un message. On envoie happy via le broker MQTT sur l’ordinateur portable et Bob affiche I'm happy en vert sur la sortie du terminal ; on envoie angry et Bob affiche I'm angry en rouge
2. mood module : il s’agit d’un arduino sur lequel on branche quelques diodes et sur lequel on installe firmata. Ce dernier est à la fois un protocole et un programme qui permet d’envoyer des messages à l’arduino. Sur le raspberry, on installe johnny five qui relaie les commandes firmata à l’arduino. La démo consiste alors à envoyer les mêmes commandes que précédemment en constatant que les diodes s’allument en fonction de l’humeur de Bob
3. sensitive module : pour ajouter des capacité sensorielles à Bob, Philippe a acheté un GrovePi qui se branche au dessus d’un arduino et sur lequel on peut ajouter des capteurs. Pour programmer tout ça, il faut installer cylon.js. Cette bibliothèque est un peu l’esperanto de l’IOT. Elle permet de dialoguer avec de nombreux protocoles
4. motion module : la démo n’ayant pas fonctionné à cause d’un problème de wifi, nous n’avons pas pu constater la mobilité de Bob assurée par un GoPiGo
5. drone : Philippe a connecté sa manette de PS3 sur le raspberry puis à l’aide d’un programme NodeJS utilisant ceylon.js, il a mappé les touches de sa manette avec les mouvements de son rolling speeder (un mini drone). La démo finale était vraiment sympa.

 

Le réseau wifi sur lequel il s’est basé pour faire communiquer les différents modules de Bob tombait assez souvent (il utilisait le point d’accès de son smartphone). Malgré ces coupures, les protocoles et les programmes reprenaient leur fonctionnement normal.

Enfin Philippe ne va pas s’arrêter là : il a eu l’occasion de tester un robot de téléprésence nommé awabot – un iPad avec des roulettes – et souhaite faire la même chose en mode maker bien sûr.

En résumé, cette présentation nous donne plus que jamais l’envie de bidouiller, hacker et expérimenter des choses dans le domaine concret des choses/things.

JGiven, enfin un outil BDD qui (re)concilie à la fois les acteurs techniques et non-techniques d’un projet

Marie-Laure et Clément commencent la présentation par une mise en situation avec un rapport cucumber. Il est assez peu lisible. Bien qu’on puisse étiqueter hiérarchiquement les scénarios la représentation est plate dans les rapports. De plus le rapport est orienté métriques alors qu’on souhaiterait qu’il soit orienté documentation métier. Enfin, même bien outillé, le refactoring des steps ne fonctionne pas.

Maintenant qu’on a vu que les rapports cucumbers ne sont pas vraiment utiles, on peut finalement se focaliser sur ce qui est vraiment important pour le BDD :

• encourager la conversation et la collaboration entre les développeurs et les experts du métier
• mettre en place une documentation vivante

Clément et Marie-Laure n’arrivaient pas à embarquer les experts du domaine dans le projet dans lequel ils travaillent. Depuis qu’ils ont mis en place jGiven, la situation est bien meilleure. Nous avons pu nous en rendre compte grâce à une démonstration approfondie des rapports de jGiven :

• une vraie navigation par tags hiérarchiques ;
• possibilité de filtrer, de trier ou de grouper par tags ;
• un moteur de recherche ;
• la possibilité d’intégrer des captures d’écran ou des pièces jointes directement dans les rapports.

La suite de la présentation fut un live-coding sur l’écriture et l’exécution de scénarios avec jGiven. Les exemples étaient de plus en plus complexes. Nous passions du scénario unique et auto suffisant à des réutilisations de steps, des tests paramétrés, des rules JUnit, des formatteurs pour garder un contrôle très fin sur les rapports générés, etc. Le tout de manière totalement fluide et avec ce qui parle le plus à un développeur : du vrai code dans un vrai IDE.

Il est à noter que Marie-Laure et Clément ont assuré même pendant la panne d’environ 5 minutes du rétro projecteur au milieu de leur session !

En conclusion, nos deux speakers sont contents de leur choix d’outil (bien qu’ils nous ont sans cesse rappelé que ce n’est pas l’outil le plus important). Ils diffusent les rapports en interne, à l’extérieur du projet et également aux nouveaux arrivants. Ils ont pu changer les mentalités en passant de spécifications Word à un travail collaboratif avec leurs experts du domaine. Tous ces arguments donnent réellement envie d’utiliser jGiven dans son propre projet.