C'est'y pas collector ?
Devoxx, je connaissais déjà depuis à peu près 3 ans, mais de façon indirecte. Hélas, je n’avais jamais eu la chance de me rendre à Anvers pour assister à LA conférence des développeurs Java. Quand la conférence Devoxx France a été annoncée lors du Devoxx World en fin 2011, je me suis dit que je devais y être. Il ne pourrait pas en être autrement !
Pour m’y rendre, j’avais donc 4 possibilités :
- Devenir conférencier, en proposant un (ou plusieurs) sujet(s) ;
- Obtenir une place via le site Developpez.com, pour lequel je suis rédacteur et modérateur ;
- Me faire payer ma place par ma société, si possible par le biais du DIF (Droit Individuel à la Formation) ;
- M’offrir ma place, et poser 3 jours de congés pour m’y rendre.
L’aventure commence…
L’avant CFP
Début janvier, je commence donc le forcing auprès de ma hierarchie, pour privilégier la solution #3. Visiblement, ça a l’air plutôt compliqué, mais pas impossible.
Les semaines passent, et nous voici quasiment à la mi-février, date limite pour la soumission des conférences (CFP, ou Call For Papers). Là, je me dis que je m’en voudrais de ne pas avoir tenté ma chance, je décide donc de me lancer. Bien entendu, j’avais déjà réfléchit depuis plusieurs semaines à des sujets que je pourrais présenter. J’avais plus ou moins exclu mon domaine de prédilection, à savoir ce qui touche à l’usine logicielle (intégration continue, qualité logicielle avec Sonar, etc.) car je savais bien que d’autres personnes mieux placées que moi auraient plus de chances d’être sélectionnées. De plus, que dire de vraiment intéressant sur le sujet, sachant que l’audience d’un Devoxx est une audience de qualité, avec des gens très compétants qui connaissent très bien leur affaire ?
Bref, j’opte pour un sujet qui, à mon avis, peut avoir son attrait : l’industrialisation des tests JavaScript. J’avoue que je ne suis un grand expert dans le domaine, mais j’ai suffisament de connaissances pour en parler. Le temps presse avant la fin du CFP, il faut donc soumettre l’abstract rapidement, même si le contenu n’est pas encore tout à fait clair. Connaissant l’esprit et le ton décalés de Devoxx, je choisis un titre un peu fun : Chouchoutez votre code JavaScript. J’envoie donc ma proposition dans la catégorie Tools In Action. Cette catégorie est parfaite pour moi : une durée de 30 minutes, ce qui n’est ni trop court ni trop long, et un angle démo très prononcé. De plus, l’entrée à la conférence est offerte pour les speakers des Tools In Action, ce qui ne gâche rien.
Pour le fun, je soumets une deuxième proposition, cette fois-ci sous forme de Quickie (présentation rapide de 15 minutes) : TestNG, parce que vos tests le valent bien. J’ai soumis ce Quickie pour 2 raisons essentiellement :
- Parler de TestNG, un outil trop méconnu, loin derrière le fameux JUnit, et qui ne manque pourtant pas de qualités ;
- Avoir une chance de plus d’être conférencier, au cas-où mon Tools In Action soit refusé.
Voilà, les soumissons sont closes, l’équipe de Devoxx, en charge de faire le tri parmi tous les sujets, fait déjà une première constatation : c’est un carton plein ! Pas moins de 464 soumissions ont été faites ! Waouh, c’est impressionnant. C’est aussi beaucoup de stress, car on se dit que cela réduit les chances d’être choisi…
En attendant Devoxx France
Devoxx, ça arrive à grands pas !
L’équipe de Devoxx travaille vite, et le 16 février au matin, je reçois un mail : Your DevoxxFrance 2012 presentation was approved, qui commence par ces quelques mots : We’re excited to inform you that your « Chouchoutez votre code JavaScript » Tools in Action presentation has been accepted for DevoxxFrance 2012. Ce mail a tout simplement illuminé ma journée, ma semaine. C’était inespéré, me voilà donc conférencier pour Devoxx !
Ma session Quickie sur TestNG sera également retenue, d’abord en backup, puis officiellement. Je n’imaginais pas être voir l’une de mes soumissions acceptées, mais alors les deux ! Quelle joie… mais aussi quel défi. Je me rends finalement compte que ma chance a été de taper dans les catégories moins plébiscitée par les autres personnes. En effet, du côté des conférences (de 55 minutes), il me semble que seuls 17% des soumissions ont été acceptées !
Bon, ce n’est pas tout ça, mais il faut maintenant définir concrètement le contenu de mes deux présentations. Du côté de TestNG, je sais plus ou moins de quoi je parlerais, et comme ce sera avant tout des slides, je mets leur préparation de côté.
Pour Chouchoutez votre code JavaScript, j’ai déjà une ligne directrice assez claire, mais les détails restent flous : je commencerais à travailler avec Jasmine, un framework de tests (orienté BDD) pour du code JavaScript. Puis, je passerais sur une analyse avec l’outil Sonar, et je finirais par incorporer le tout dans un serveur d’intégration continue (Jenkins dans mon cas). Mes multiples essais sur ma machine donnent de bons résultats, mais il y a hélas un manque : avec tout ceci, je n’obtiens pas la couverture du code par les tests, chose aisée lorsque l’on travaille avec du code Java.
Et puis début mars, c’est la délivrance ! Sur la mailing list de Sonar, je vois un message annonçant l’arrivée de la version 0.4 du plugin JavaScript pour Sonar, avec en particulier le support de la couverture de code par js-test-driver. Je m’intéresse donc à cette librairie, et découvre avec joie que Jasmine propose un adaptateur pour js-test-driver.
Il ne me faudra pas beaucoup de temps pour faire marcher le tout ensemble, et obtenir ce que je voulais. Je suis sauvé 
!
Je m’occupe dès lors de mon Quickie sur TestNG. Les choses sont plus faciles, mais je m’aperçois que j’ai quelques années de retard En effet, TestNG est une excellente librairie de tests pour Java, qui offre depuis 2004 des fonctionnalités avancées que JUnit ne propose pas, ou alors seulement depuis 1 an ou 2. Je pense aux tests groupes de tests, à la dépendance entre tests, aux listeners, aux tests paramétrés, etc. Mais bon, je vais faire avec, et montrer que même avec les avancées de JUnit, TestNG reste une alternative qui a tout son sens, et qui dispose toujours de beaucoup d’atouts !
L’équipe de Devoxx fournit les templates pour Open Office, Microsoft Office et Apple Keynote. Etant sur Mac, j’avais tout d’abord opté pour Open Office. Après moults échecs dans mes tentatives de faire des slides à peu près jolis, je me suis dit que j’allais les faire sur un PC avec Office, et que je les jouerais avec Open Office sur mon Mac. Pas une très grande idée. Puis, j’ai décidé d’installer la version d’évaluation d’Office pour Mac, et je dois dire que je suis très rapidement tombé sous le charme.
Les choses vont donc bon train, mais rien ne vaut une vraie répétition. J’organise donc une répétition sur mon lieu de travail pour une poignée de collègues, une semaine avant le début de Devoxx France. Compte tenu que je vais emporter mon Mac perso, je n’aurais donc aucun réseau. La veille de cette répétition, je décide donc de la jouer chez moi, tout seul, mais en coupant mon wifi ! Grand bien m’en a pris ! Maven ne semble pas avoir apprécié sa déconnexion, et c’est une riche idée que j’ai eue de le tester en mode déconnecté.
Une chose à ce propos m’a un peu interpellé : ma démonstration sur le code JavaScript commence par la création d’un squelette de projet via un archetype JavaScript (de.akquinet.javascript.archetypes:javascript-quickstart pour être précis). Or, en mode déconnecté, la commande mvn archetype:generate ne me liste qu’une cinquantaine de choix (contre 578 une fois le wifi réactivé). Il m’a été impossible de trouver une option pour que Maven (ou le plugin Archetype) télécharge de lui-même le catalogue des archetypes sur le repository officiel de Maven. J’ai dû copié le archetype-catalog.xml manuellement pour qu’il reconnaisse bien l’ensemble des archetypes, même en mode déconnecté. Si vous avez une idée du pourquoi, n’hésitez pas à m’en faire part !!
Bon, à quelques petits détails près, ma répétition est appréciée, et en plus, j’ai réussi à tenir mes timings. Ca s’annonce plutôt pas mal…
Dernier petit stress : le week-end précédant Devoxx, Nicolas Martignole de l’équipe d’organisation, demande aux speakers de bien respecter le format « officiel » des slides, à savoir 1280×720, en particulier pour les conférences filmées (à savoir toutes, sauf les Quickies). Et dire que j’avais tout préparé en 1024×768 (la faute à mon Mac qui ne permet pas l’affichage en 16:9). Donc par souci de respect du protocole, me voici à copier ma présentation du format 1024×768 vers 1280×720. J’étais assez content que ma présentation soit surtout basée sur de la démonstration, et que du coup je n’avais qu’assez peu de slides (19 quand même).
Les jours J !
Mon Tools In Action sur JavaScript a lieu le premier jour de Devoxx France, à savoir le mercredi 18 avril. Je passe en fin d’après-midi, à 17h40. Tout pourrait aller à merveille, s’il n’y avait pas un petit souci d’ordre médical : je souffrais alors d’une angine ! 39,5 la veile au soir, j’avoue que je n’étais pas en grande forme. C’est donc à grand renfort de paracétamol (un traitement plus adapté suivra le lendemain, après avoir vu ma guérisseuse) que j’assiste aux premières conférences. L’après-midi, je le passerais à peaufiner ma présentation (c’est d’ailleurs 30 minutes avant ma présentation que j’ai rajouté les petits Godzilla en bas de mes slides, pour indiquer l’avancée dans ma présentation), à discuter avec d’autres personnes, et à assister à Code Story.
Puis, vint mon tour. Chose assez étrange : je n’ai pas (ou si peu) stressé avant, pensant que je stresserais comme un fou le jour J. Finalement, rien de tout cela, j’étais juste excité – dans le bon sens du terme – d’entrer sur scène ! Et pourtant, la salle, d’une capacité de plus de 200 personnes, était quasiment pleine !
Oui, il y avait du monde !
La preuve que c'était bien moi !
Je commence ma présentation, et à peine 3 minutes après le début de celle-ci, je m’ »offre » un bel effet démo ! Après avoir créer mon projet via l’archetype Maven, je m’en vais l’importer dans Eclipse… et là, c’est le drame ! Je commence par me tromper dans le chemin exact contenant mon projet, puis je me trompe dans la fenêtre de création de projets… bref, je commençais à paniquer (intérieurement seulement). Fort heureusement, le problème finit très vite par se régler, et le reste de la démonstration se passe à merveille ! Chose inattendue : au moment où j’obtiens la couverture de mon code JavaScript par mes tests sur Sonar, l’audience applaudit Ca fait chaud au coeur tout ça ! Je termine ma présentation dans les temps, j’ai même 4 minutes de questions, assez nombreuses d’ailleurs.
Visiblement, les retours sont bons, sur Twitter !
Le soir, un diner réservé aux speakers est prévu, je comptais y aller, mais j’ai préféré renoncé, compte tenu de mon état de santé. Ce mercredi, j’ai quitté Devoxx seulement quelques minutes après ma présentation, avec une énorme satisfaction. Pour moi, la mission était accomplie !
Le jeudi sera plus calme pour moi, car c’est la seule journée où je ne présente rien.
Le vendredi, mon Quickie passe à 12:35. La salle était, cette fois-ci, presque vide. Mais c’était à prévoir, les Quickies (surtout les premiers) étant planifiés en plein durant la pause déjeuner. J’ai fait ma présentation de TestNG sans grand souci, hormis que j’ai mis exactement 15 minutes pour la faire, alors que je voulais me réserver 2 / 3 minutes pour faire quelques démonstrations sous Eclipse. Tant pis, mais ce n’est pas grave…
Vivement Devoxx World et Devoxx France 2013
Finalement, Devoxx fut une conférence de très grande qualité, et faire partie des conférenciers fût pour moi une merveilleuse aventure !
Je remercie chaleureusement l’équipe de sélection de Devoxx pour m’avoir fait confiance, et avoir sélectionné mes deux présentations. Être conférencier Devoxx, c’est une énorme fierté en ce qui me concerne, et j’espère que ce sera partie remise l’année prochaine. J’espère d’ailleurs pouvoir proposer une vraie conférence (d’une heure), et pourquoi pas avec une autre personne… Mais d’ici-là, beaucoup de choses se seront passées !
Mille mercis aussi à Claude Falguière pour ses photos de Devoxx, ce qui me permet d’avoir un sacré souvenir de ma présentation (en attendant la vidéo sur Parleys ) !
]]>Je vais très rapidement zapper la toute première keynote, d’IBM. C’est un concentré, en une petite demi-heure, de ce qu’il ne faut pas faire dans une conférence, surtout à Devoxx : commerciale, speaker plutôt mou, et à l’opposé des présentations zen (c’est-à-dire avec des slides bourrées de bullets points).
Il suffisait de lire les tweets postés pendant la présentation pour comprendre que ce n’était pas du goût de l’auditoire !
Portrait du développeur en « The Artist » par Patrick Chanezon
Le conférencier suivant a un CV déjà bien rempli : il a travaillé chez Accenture, Netscape en France, puis Sun, Google (API / GAE), et enfin VMWare (CloudFoundry) aux USA.
La première partie est consacrée à nous parler de la vie de George, à la façon « The Artist« .
George est un développeur talentueux, et très vite devient indispensable à son projet. Ses chefs se disent qu’il serait bien de le mettre comme chef de projet, puis finalement comme DSI de sa boite… Mais voilà, George aime la technique, et si son niveau de golf s’améliore, il n’arrive déjà plus à lancer Eclipse, et est très vite dépassé par toutes les nouvelles technologies.
Patrick nous explique finalement que si l’on souhaite conserver son niveau, il faudra rester proche de la technique, et toujours s’intéresser aux nouvelles technologies…
Abstraction Distractions for France par Neal Ford
Nous continuons avec une troisième keynote, elle aussi de très haut vol. Il faut dire que nous avons en face de nous Neal Ford, un architecte de ThoughtWorks, et plutôt talentueux conférencier.
Cette fois-ci, il nous parle d’abstraction et de distraction. Difficile de retranscrire ici sa prestation, je vous la recommande sur Parleys dès qu’elle sera disponible. La moitié de la salle a fini debout pour applaudir le Maitre !
TestNG, parce que vos tests le valent bien par moi-même
Je reviendrais un peu plus longuement dans un autre billet sur le Quickie que j’ai présenté.
Il s’agit ici de montrer que TestNG dispose de nombreux atouts pour remplacer JUnit comme librairie de tests unitaires…
CRaSH par Julien Viet
Julien Viet, de l’équipe d’eXo plateform, nous propose une petite démonstration de CRaSH, un shell qui permet de travailler directement avec / sur une JVM.
Le principe est très simple : une fois installé et démarré, l’outil va se connecter sur une JVM, et on pourra alors exécuter un certain nombre de commandes :
- Lister les threads qui tournent sur la JVM ;
- Utiliser CRaSH pour gérer les logs, en changeant par exemple dynamiquement le niveau des logs du serveur d’applications JBoss AS ;
- Se connecter à la dataSource pour exécuter des requêtes SQL !
Puis Julien nous explique que les commandes sont écrites en Groovy et toute modification d’une commande est prise en compte dynamiquement. Il est d’ailleurs très simple d’ajouter soit-même de nouvelles commandes.
Bref, un bel outil, très extensible, qui mérite un coup d’oeil, même s’il ne faudra pas mettre cela entre toutes les mains !
Groovy 2.0 : quoi de neuf doc ?, par Guillaume Laforge et Cédric Champeau
Guillaume et Cédric nous font un récapitulatif des nouveautés de Groovy 2.0 (mais aussi un peu de Groovy 1.8).
En effet, déjà pas mal de choses ont été introduites par la version 1.8 du langage. Par exemple, les Command chains, rendant optionnelle l’écriture des . ou ( ), lorsque l’on chaine des appels.
Ainsi, ces codes :
turn left then right
check that: margarita tastes good // named-args
given {} when {} then {}
select all unique() from name // Pour une méthode sans argument, on garde les ()
take 3 cookies
sont équivalents à ceux-ci :
turn(left).then(right)
check(that: margarita).tastes(good) // named-args
given({})when({})then({})
select(all).unique().from(name)
take(3).cookies
Groovy intègre également GPars pour faire du parallélisme, de la concurrence.
Autre nouveauté : les Closure annotation parameters, ainsi que la memoization, c’est-à-dire que Groovy va se souvenir du dernier appel d’une closure pour cacher le résultat. Par exemple :
def plus = { a, b -> sleep 1000; a + b}.memoize() // on "simule" un traitement lent avec le sleep...
assert plus(1, 2) == 3 // Le retour sera fait après 1000ms
assert plus(1, 2) == 3 // Ici, on utilise le cache, donc le retour est immédiat
assert plus(2, 2) == 4 // Le retour sera fait après 1000ms, les paramètres étant différents.
assert plus(2, 2) == 4 // Ici, retour immédiat
On peut affiner la façon dont Groovy va cacher les résultats, en limitant par exemple le nombre de valeurs à retenir (.memoizeAtLeast(x), .memoizeAtMost(42)…).
Groovy ajoute désormais un support du JSON dans Groovy (avec les JsonSlurper, JsonBuilder et JsonOutput).
De nouvelle annotation (AST transformations) sont également à l’ordre du jour, comme par exemple @Log pour injecter automatiquement un logger.
Des annotations pour le controle d’exécution sont là : @ThreadInterrupt, @TimedInterrupt.
Les amateurs de Lombok seront aussi comblés, puisque Groovy intègre des annotations pour simplifier le code : @ToString (qui génère la méthode toString() automatiquement), @TupleConstructor (qui génère un constructeur avec les propriétés de la classe) ou encore @InheritConstructors (utile sur les exceptions où les constructeurs appelent juste des super).
Concernant Groovy 2.0, nous allons voir surtout la vérification stricte, ainsi que la compilation statique.
A noter aussi que cette version offre plus de modularité : ce n’est plus seulement un gros jar, mais plusieurs modules.
Groovy 2.0 s’adapte aussi à Java 7 :
- project coin (écriture des nombres en binaire, avec des _)
- multicatchs ;
- opérateur diamand (pour écrire
Listplutôt quelist = new ArrayList<>(); List) ;list = new ArrayList (); - invokeDynamic.
Le @TypeChecked fait aussi son apparition. Cette annotation permet de vérifier beaucoup plus de chose lors de la compilation.
Par exemple :
@TypeChecked test() { // On annote la classe ou la méthode
metthhoood() // Erreur à la compilation
def name = "Guillaume"
println // Erreur ici aussi !
}
Un autre exemple :
@TypeChecked test() {
["a", "b", "c"].collect(
it.toUpperCase()
)
}
ne compilera pas, car rien ne permettra d’assurer à Groovy que le it est bien un String (la méthode collect pourrait être alterée par exemple).
Du coup, pour que le compilateur soit content, il faut caster le it comme ceci :
@TypeChecked test() {
["a", "b", "c"].collect(
String it ->
it.toUpperCase()
)
}
Dernier point apporté par Groovy 2.0, et non des moindres : la compilation statique. Celle-ci se dénote par l’annotation @CompileStatic.
Les avantages d’une compilation statique sont :
- Les performances accrues, en particulier sur des JDK avant 7, ne disposant pas du
invokeDynamic; - Evite les problèmes liés au « Monkey patching« , c’est-à-dire que le code est « immunisé » contre la modification dynamique ;
- Le bytecode généré sera bien plus petit.
Reste que la compilation statique fait perdre les fonctionnalités dynamiques de Groovy (du moins sur le code compilé statiquement). Mais là, rien de bien gênant…
Android, graphisme et performances par Romain Guy
Romain Guy est un développeur français parti chez Sun où il a d’abord travaillé sur Swing, et est désormais chez Google comme développeur Android.
Il nous donne sur cette conférence un aperçu des écueuils à éviter lorsque l’on développe sur Android, et en particulier de ce qu’il convient de faire pour avoir des applications performantes.
Bon, je dois l’admettre, je n’ai pas retenu grand chose de la présentation car je ne développe pas pour Android. Toutefois, on voit que Romain connait son sujet, et qu’il maitrise l’art de la conférence. Bref, c’était agréable à écouter…
Les CastCodeurs en direct de Devoxx France
Très bonne conclusion du Devoxx avec cet enregistrement en live des CastCodeurs.
Un récapitulatif dans la joie, la bonne humeur et la bière (merci Atlassian pour ça !)
Vous pouvez retrouver l’épisode spécial Devoxx France ici.
Conclusion
Devoxx France, c’est fini, mais qu’est-ce que c’était bien !
Des conférences de haut niveau, un public de geeks très nombreux et aussi de grande qualité, des rencontres vraiment sympas.
Le fait d’avoir aussi été choisi comme conférencier pour parler de JavaScript (dans une présentation qui a visiblement plû au delà de mes espérances), et de TestNG rend ces jours vraiment inoubliables…
Bref, encore mille bravos à toute l’équipe organisatrice !
]]>Une petite visite chez le médecin en cette matinée m’a fait raté les keynotes. Je les regarderais sur Parleys lorsqu’elles seront disponibles.
Mais en gros, on salue le succès de cette première édition, et l’année 2013 verra elle aussi son édition parisienne du Devoxx ! J’ai déjà hâte d’y être !
Spring est mort, longue vie à Spring, par Gildas Cuisinier
Lorsque JavaEE 6 est sorti, on annonçait une guerre sans pitié avec Spring, et la fin proche de ce dernier.
Cela fait déjà 2 ans que JavaEE est sorti, mais qu’en est-il aujourd’hui ?
A l’époque, avant sa version 6, JavaEE avait « menti », en partiulier sur la soit disant simplicité du framework JavaEE, ainsi que sur la testabilité des applications l’utilisant…
C’est alors que Spring est arrivé pour résoudre pas mal de problèmes.
Initialement, toute la configuration se faisant avec des fichiers XML. Il faut dire que c’était à la mode, le XML !
Puis, la complexité de cette configuration augmentant, les namespaces sont arrivés, pour mieux catégoriser sa configuration Spring. On y voyait déjà plus clair !
Un jour, Java 5 est arrivé, en introduisant les annotations dans le code Java. Ceci va impliquer une nouvelle évolution de Spring : la configuration via les annotations.
En voici un exemple :
@Component
public class Jedi {
private Arme arme;
@Autowired
public void setArme(Arme arme) {
this.arme = arme;
}
}
Seul ombre au tableau : pour se passer d’écrire de la configuration en XML, il faut écrire… du XML. En effet, il faut indiquer à Spring quel(s) package(s) doivent être scannés pour y lire les annotations :
<context:component-scan base-package="xxx"/>
Entre temps, JavaEE est arrivé, et devient « sexy » : simplicité, testabilité, légèreté. Toutefois, cela demande une migration, non seulement du code, mais aussi des serveurs d’applications, car tous ne sont pas compatibles JavaEE 6.
De son côté, Spring sort en version 3.0 (décembre 2009), disposant de sa configuration par annotations.
Malgré l’arrivée de JavaEE 6, les équipes ne souhaitent pas abandonner Spring. Gildas nous le montre avec un certain nombre de statistiques tirées de son questionnaire Spring (entre 100 et 130 personnes y ont répondu).
Aujourd’hui, Spring est toujours très présent, en particulier les version 3.x :
- 50% des sondés utilisent Spring 3.0 ;
- 23% sont déjà passés à Spring 3.1 ;
- 19% n’utilisent pas Spring ;
- 8% sont restés sur des versions 2.0 ou 2.5 de Spring.
- Trop compliqué à mettre en place. Généralement, on travaille sur une application où Spring est déjà en place, on ne regarde pas comment cela fonctionne concrètement.
- Invasif.
- Trop de XML. Maintenant, on s’oriente beaucoup plus vers les annotations, comme pour JavaEE. Cependant, cela pose un autre souci : la configuration par annotations étant dispersée dans le code, il devient plus fastidieux d’avoir une vision globale de celle-ci…
- L’aspect propriétaire. Toutefois, si SpringSource gère seul le code, mais reste ouvert aux propositions.
D’ailleurs, dans l’audience, seules 3 personnes utilisent JavaEE 6 en production, alors que la quasi totalité utilise Spring 2.5 / 3.0 en production. Très peu (pour l’heure), utilisent Spring 3.1 en production.
Les principaux reproches faits à Spring :
Gildas parle ensuite de Spring 3.1. Qu’apporte-t-il ?
Spring 3.1 finit ce que Spring 3.0 avait introduit : tout est désormais annotable, on peut faire du « NoXML » !
L’exemple cité plus haut s’écrira désormais ainsi :
@Configuration
@ComponentScan("xxx")
public class Configuration {
...
}
De nouvelles annotations arrivent, pour gérer le scheduling (@EnableScheduling) ou encore pour configurer Spring MVC (@EnableWebMvc).
Les annotations ne permettent pas tout, et il est parfois nécessaire, en plus d’annoter sa classe, d’étendre une classe de Spring (exemple : les Interceptors MVC).
D’autres points intéressants sur Spring 3.1 :
- Support d’Hibernate 4 ;
- Namespace
c:(pour simplifier les constructeurs) ; - JPA sans le
persistence.xml; - Amélioration du support REST dans Spring MVC ;
- FlashMap dans Spring MVC.
En conclusion, Spring est loin d’être mort, car l’adoption de JavaEE est encore loin d’être une réalité, et de plus, Spring dispose de tout un écosystème autour de lui : SpringData, SpringMobile, SpringSocial, SpringBatch, etc.
Après la pause déjeuner, je vais zapper les conférences, et aller voir un peu ce qui se fait du côté de Code Story…
Code Story
Le principe : 4 développeurs (David Gageot, Jean-Laurent de Morlhon, Sébastien et Eric le Merdy) se chargent du développement d’une application se connectant à Github pour créer un historique de projet.
Ensuite, cette application va s’interfacer avec Jenkins, Sonar, Trello, etc. pour pouvoir ajouter des événements dans la vie du projet (build cassé, règle de qualité non respectée, etc.).
Au final, l’application devrait pouvoir attribuer des badges aux développeurs du projet surveillé : le meilleur casseur de build, le commiteur le plus prolifique, etc.
Tout se fait bien entendu en live, en partant de zéro.
Chaque itération dure environ 1 heure, avec 2 sessions de 25 minutes de développement.
Au début, un petit stand-up meeting pour expliquer ce qui va être fait dans l’itération, et à la fin, une rétrospective pour expliquer les accomplissements, ainsi que les difficultés rencontrées.
Concrètement, l’équipe se divise en 2 binômes :
- Le premier binôme est au front : il code face à l’audience, et explique à voix haute ce qu’il fait.
- Le second binôme travaille plus en retrait, et on ne voit pas concrètement ce sur quoi il travaille (mais on finit par le savoir lors de la rétrospective de fin d’itération).
Deux vidéo-projecteurs nous permettent de suivre leur travail en direct. Le premier diffuse l’écran du premier binôme (en général pour montrer soit IntelliJ, soit une console shell, soit le navigateur web), le second montre le « serveur », avec Jenkins ou Sonar qui analysent en permanence le travail commité sur GitHub.
Lorsque j’y suis allé, le projet n’en était encore qu’à ses débuts, et l’équipe mettait en place le déploiement automatisé, et commençait à écrire ses premières pages web.
Mais il était intéressant de voir 4 développeurs plutôt talentueux (dont 3 ex-collègues à moi ) travailler en direct live, dans des conditions proches de la réalité (avec des dead-lines très courtes).
D’ailleurs, à en voir les retours, ce Code Story a été très apprécié. Plusieurs fois j’ai voulu y retourner, mais à chaque fois, j’ai été obligé de rester en dehors de la salle, tant elle était perpétuellement remplie !
A noter que lorsque j’y suis passé, l’équipe avait déjà eu recours à pas mal d’outils ou de librairies :
- Github (version entreprise) pour stocker le code ;
- Infinitest pour laisser l’IDE exécuter en permance les tests unitaires ;
- Zombie.js un framework JavaScript pour tester l’interface web ;
- Mocha un autre framework de tests JavaScript ;
- Jersey, une librairie Java pour faire du REST ;
- Fest-assert, une extension à JUnit (ou TestNG) pour écrire des assertions de manière plus fluide (fluent) ;
- Guava l’incontournable librairie de Google pour ajouter tant de choses manquantes à Java !
- Growl un outil de notification pour Mac, affichant une notification à chaque fois que l’application vient à builder ;
- Jenkins pour l’intégration continue ;
- Sonar pour l’analyse qualité ;
- IntelliJ, l’IDE Java de référence ;
- Trello comme mur à post-its virtuel, permettant de planifier les tâches des itérations ;
- Mustache.js un framework JavaScript de templating.
L’équipe a mis en place le build incassable : on ne committe que si ça compile bien chez soi. Du coup, Jenkins devient moins utile. D’ailleurs, à ce propos, il faut noter que David Gageot est partisan de l’intégration continue sans serveur !
Grawl est également mis en place pour offrir un maximum de réactivité : dès qu’un commit est réalisé sur le repository Git, Grawl nous indique qu’un build Jenkins démarre… puis quelques secondes plus tard il nous indique que le build est terminé, avec succès bien sûr !
Une librairie qui a atiré mon attention, c’est Mustache.js, qui permet de faire du templating en JavaScript.
Voici un exemple tout simple :
<script type="x-template" id="commit-template">
{{#commit}}
<div class="commit">{{author}}</div>
{{/commit}}
</script>
Mustache.to_html($("commit-template").html, json);
Bref, une très jolie expérience que ce Code Story ! Dommage que je n’ai pu assister à des sessions vers la fin, pour voir le projet presque abouti.
Toujours est il que le code est à retrouver sur GitHub.
BigData et Hadoop par Pablio Lopez
Pablo Lopez nous parle d’une expérience vraiment très intéressante. Il travaille pour une grande société de vente de produits en ligne (il ne le citera pas, mais il s’agit d’une société à l’image ferroviaire vendant différentes prestations de voyages).
Celle-ci gère environ 1,000,000 de visiteurs uniques par jour, et environ 1/5 de ces visiteurs réalisent une commande.
Ce sont ainsi au total environ 65,000,000 commandes par an, avec un pic, autour de mi-octobre, de 350,000 ventes pour une seule journée !
L’ambition : être le leader mondial dans son activité dans les 3 ans. Rien que ça, pour, ce qui était il y a encore 10 ans à peine, une startup…
Côté technique, nous avons 500 serveurs de production, gérant environ 80 applications, chaque serveur disposant de 5 JVM. L’utilisateur navigue sur 13 niveaux de load balancing. Joli !
Au final, chaque serveur va générer 7 Go de logs quotidiennement ! Il est donc difficile de gérer un tel volume !
Ce qu’il faut, c’est :
- Centraliser les logs ;
- Sécuriser les fichiers de logs, les sauvegarder ;
- Analyser : pouvoir récupérer les informations selon des catégories (paiement, recherche, etc.) ;
- Informer les bonnes personnes avec les bonnes informations ;
- Archiver, pouvoir comparer les logs d’une journée sur l’autre, d’une semaine sur l’autre, d’un mois sur l’autre, etc.
- Et tout cela en temps réel s’il vous plait !
- MongoDB une base de données NoSQL ;
- Play pour afficher des statistiques, des rapports ;
- Hadoop
- Flume
- Elasticité du modèle, pour le faire évoluer facilement ;
- Facilement interrogeable, avec du JSON ;
- Maturité de l’API de requêtage ;
- Scalabilité.
- Analyse quotidienne des logs, pour le SLA (« Service Level Agreement« , autrement dit un document définissant le niveau de qualité attendu) ;
- Corrélation des logs. Si un utilisateur a eu un problème, il faut savoir identifier les serveurs par lesquels il est passé (on rappelle qu’un utilisateur peut passer par 13 niveaux de load-balancing !) ;
- Comparer différentes versions du site, voir si la nouvelle version ne contient pas des liens cassés par exemple.
- L’équipe soit avoir de nouveaux uses cases : par ex. savoir où passe le robot Google, détecter les utilisations frauduleuses de CB, faire des ratio recherches / achats ;
- Agrandir encore la plateforme, remettre à jour les machines ;
- Avoir de l’analyse de logs à la demande, sans avoir à développer et déployer de nouveaux map / reduce. Utiliser Hive ? Cascading ?
- Quel avenir pour les produits utilisés ? L’équipe souhaite contribuer à Flume. Quelques craintes également sur la versatilité d’Hadoop.
Etant un site de e-commerce, on doit avoir une disponibilité de 99,995%, ainsi qu’un temps de réponse sous la seconde (voire même sous les 200 ms). Et là dessus, il n’y a pas de négociation possible !
La base de données étant le « Single point of failure » (goulot d’étranglement), il ne faut surtout pas la surcharger !
Quelles solutions ?
Pour arriver à leurs fins, l’équipe de Pablo va avoir recours à :
Les outils doivent tenir la charge, être scalables, avoir une excellente tolérance à la panne.
Première chose : centraliser les logs, et le plus vite possible. Pour cela, ils font appel à SyslogAppender, un appender de log4j, qui peut transmettre les logs via UDP. De l’autre côté, syslog-ng est utilisé pour écouter ces packets UDP.
Flume est utilisé pour pouvoir copier les logs sur des systèmes de fichiers distribués (hdfs).
Second point : sécuriser les fichiers.
HDFS (Hadoop Distributed File System) est utilisé ici. Chaque log est copié 3 fois, sur des disques « classiques ». Cette duplication rend ainsi obsolète des système de type RAID.
hdfs travaille mal avec des « petits » fichiers (moins de 64Mo). Pour résoudre ce problème on regroupe plusieurs « petits » fichiers un seul (fichier de type .har).
Il faut maintenant analyser les logs, par « tranche » de 64M (sur le principe du principe map / reduce).
Les rapports d’analyse sont stockés sur du MongoDB :
Play! est utilisé pour représenter les rapports d’analyse. Play! est choisi pour sa facilité de mise en oeuvre, son intégration de JSON et MongoDB, etc.
Dernière problématique : le temps réel !
Premier souci : Hadoop ne sait pas faire de map / reduce sur des fichiers non fermés (or ici, tout est en streaming). Flume va résoudre ce problème en fermant les fichiers à chaque minute.
Hélas, le temps de traitement du map / reduce est alors d’environ 45 minutes ! Beaucoup trop long !
La première correction sera de modifier le cluster. Ensuite, les JVM gérées par Hadoop sont tunées, en particulier pour la gestion mémoire.
L’interaction avec Flume est également améliorée. On arrive maintenant à 6 minutes. C’est déjà mieux, mais le temps doit encore être réduit !
On optimise l’utilisation de Java : suppression de librairies tierces, optimisation de la sérialisation des objets, etc.
Au final, on arrive à 45 secondes pour traiter 1 minute de logs.
Quelle est l’utilisation quotidienne de ce système ?
Concernant l’avenir :
Dernier détail : l’investissement s’est fait essentiellement au niveau des machines (~ 70K€).
Le projet, quant à lui, est passé des premières discussions à la machine à café à la production en l’espace d’environ 7 à 8 mois.
Voilà un joli projet, qui montre une utilisation concrète d’Hadoop, MongoDB, Flume et Play! pour un traitement massif des logs.
Start Slide Show with PicLens Lite]]>Ca y est. Après plusieurs mois de préparation et d’attente, la conférence Devoxx a enfin lieu !
Parlons de lieu justement. Devoxx France prend place à l’hôtel Mariott, dans le 14e arrondissement de Paris.
Le lieu est donc plutôt bien choisi, et la conférence va s’étaler sur 2 niveaux :
- Au rez-de-chaussée, il y a 3 salles (Seine A, Seine B et Seine C), qui seront réunies en une seule lors des keynotes. C’est également à ce niveau-là que sont regroupés tous les stands des sponsors : Valtech, Xebia, Zenexity, Ippon, Google, etc. Enfin, c’est ici qu’ont lieu les buffets. Parce que ça creuse tout ça !
- Au niveau -1, 2 salles sont utilisées (Ella Fitzgerald et Miles Davis qui sera occasionnellement divisée en 3). Il y a aussi un open-space, très sympa pour les discussions un peu à l’écart, et une petite salle qui héberge 2 jours durant le Code Story.
Bref, au niveau des lieux, c’était un sans faute, même si au moment du buffet du midi, on se marchait un peu dessus…
On regrettera quelques petits soucis au niveau service, comme par exemple la manque de diversité au repas du midi (quelques salades, 2 ou 3 types de sandwiches, c’est tout), l’absence d’eau tout l’après-midi (c’est un peu abusé là je trouve), et des vestiaires qui ferment trop tôt (en particulier pour les gens qui ont des valises).
Ok, on chipote…
A part ça, au niveau de l’organisation, et du staff, pour moi, c’est zéro faute. Toujours présents, très réactifs en cas de soucis, aucune queue pour récupérer son badge. Bref, un seul mot : BRAVO.
Voyons maintenant un peu les sessions du jour… programme qui sera assez léger en ce qui me concerne.
Ce premier jour est destiné aux universités (des sessions techniques d’environ 3 heures), des démonstrations d’outils.
Tout le monde n’est pas encore là (certains participants ne vennant que les 2 deniers jours), mais nous sommes déjà autour de 800 personnes. Pas mal du tout !!
Les 5 mercenaires du DevOps, par Henri Gomez, Arnaud Héritier, Gildas Cuisinier, Pierre-Antoine Grégoire, Dimitri Baeli
Il existe aujourd’hui dans beaucoup de sociétés un véritable mur entre les équipes de développement et les opérationnels, c’est-à-dire les « gardiens » de la production.
Il arrive fréquemment que les livrables soient donnés aux opérationnels par les développeurs sans que ces derniers ne connaissent l’environnement de production.
De même, les « Ops » ne connaissent que trop peu ce qu’ils vont mettre en production.
Il en résulte généralement que lorsqu’un problème arrive en production, c’est à qui se débarrassera du problème, et surtout d’en nier la responsabilité (« Ton livrable est pourri« , « Mais tu n’as pas respecté l’étape 42 de la page 37 du document de mise en production« , etc.)!
Bref, nos 5 compères nous expliquent ce que sont les DevOps, mi-développeur mi-opérateur, et vont tenter de nous montrer ce que cela donne en live, grâce à une application qu’ils ont développé (une application de partage temporaire de fichiers).
Pour évaluer un peu leur audience, nos 5 mercenaires décident de faire les 12 tests de Joel : Joel Spolsky a édicté un test de 12 questions pour évaluer la qualité de l’environnement de travail d’un développeur.
Ces 12 questions, les voici :
- Disposez-vous d’un gestionnaire de source (type SVN, Git, etc.) ?
- Pouvez-vous construire vos livrables en une seule étape ?
- Construisez-vous l’application quotidiennement ?
- Avez-vous un gestionnaire de défauts ?
- Corrigez-vous les bugs de votre application avant d’écrire du nouveau code ?
- Avez-vous un planning à jour ? Autrement dit, avez-vous une visibilité d’au moins 15 jours dans votre travail ?
- Avez-vous des spécifications ?
- Les développeurs sont-ils dans un environnement de travail calme ?
- Disposez-vous des meilleurs outils, compte tenu de votre budget ?
- Avez-vous des testeurs (autres que des développeurs) ?
- Les candidats écivent-ils du code avant leur embauche ?
- Faites-vous des tests d’utilisabilité ?
Pour Joel, si vous avez une note inférieure à 10, alors vous avez un gros problème.
Notez que ce test, toujours d’actualité, a été écrit en 2000 ! Ce test a donc 12 ans, mais hélas beaucoup de développeurs ne peuvent encore jouir d’un score parfait.
D’ailleurs, nos 5 mercenaires demandent à l’audience de se lever, puis ils énumèrent ces règles, chaque participant devant se rassoir dès que l’une des règles n’est pas respectée dans son équipe. Au bout du test, seules 3 personnes finiront debout ! C’est peu.
L’équipe a ensuite montré l’application qu’ils ont développée, en montrant les différentes étapes pour pouvoir la déployer (via différents jobs Maven dirigés par un serveur Jenkins). La suite de la conférence – que je n’ai pas vraiment pu suivre – a consisté à modifier en direct l’applications, puis de la déployer « en production ».
Une première session plutôt agréable donc, présentée par quelques personnalités…
Hackergarten
Le principe du Hackergarten est assez simple : vous réunissez quelques geeks avec leur machine (généralement un Mac 
), ainsi qu’un commiteur (voire le créateur) d’une librairie ou d’un framework assez connu.
Ensuite, vous commencez à travailler sur le projet, en corrigeant un petit bug par exemple, ou en ajoutant une nouvelle fonctionnalité.
Ici, nous avions du choix : nous pouvions travailler sur Jenkins (ou un de ses nombreux plugins), Groovy, FluentLenium, Mockito, etc. Plusieurs personnes étaient là pour nous aider : Arnaud Héritier, Mathilde Lemée, Brice Dutheil, Guillaume Laforge, etc.
C’est une expérience sympathique, mais je n’y étais sans doute pas très bien préparé, en particulier le fait de devoir télécharger pas mal de sources (et je ne parle pas des dépendances Maven ).
Au final, je n’ai pas vraiment contribué à Jenkins, mais ce n’est sans doute que partie remise !
Chouchoutez votre code JavaScript par moi-même
Ma présentation, donc forcément une très bonne présentation, vous n’en doutez-pas
Plus sérieusement, cette présentation a un but précis : montrer que l’on peut faire pour le JavaScript ce que l’on fait déjà pour son Java, à savoir le tester, l’analyser, l’intégrer. Et le tout, sans utiliser de nouveaux outils.
Vous pouvez retrouver pour cette présentation :
- La retranscription sur mon blog
- Les slides sur SlideShare
- Les sources (mes backups) sur GitHub
- La vidéo sur Parleys (à venir)
Il restait encore une dernière série de présentations, un paquet de BOF (Birds of a Feather, c’est-à-dire un petit groupe de discussion informel sur un sujet précis) puis une soirée dédiée aux speakers, mais mon état de santé ne m’a hélas pas permis de rester.
Start Slide Show with PicLens Lite]]>Le but de cette présentation est de montrer qu’il est aussi facile de tester et analyser son code JavaScript que son code Java. Les mêmes outils seront d’ailleurs utilisés, en particulier Maven, Jenkins et Sonar.
Avant toute chose, nous allons prendre underscore.js comme cobaye pour nos tests. Pour information, il s’agit d’une librairie proposant une soixantaine de fonctions JS permettant de faire de la programmation fonctionnelle.
Etape #1: Créer le projet
Mon choix, pour la première librairie de tests, c’est Jasmine. Il s’agit d’une librairie avec une communauté assez active, et disposant d’un certain nombre de supports : Java et Maven, .Net, Ruby, Node.js, etc.
Pour être plus précis, cette librairie va être surtout utilisée lorsque l’on souhaite faire du BDD (Behavior Driven Development). D’ailleurs, dans la terminologie de Jasmine, on ne parle pas de test, mais de spec.
Comme dit précédemment, Jasmine offre un support Maven. Pour ma présentation, j’opte pour la création d’un projet squelette, via un archetype Maven. Cela se fait via cette commande :
mvn archetype:generate
-DarchetypeRepository=http://searls-maven-repository.googlecode.com/svn/trunk/snapshots
-DarchetypeGroupId=com.github.searls
-DarchetypeArtifactId=jasmine-archetype
-DarchetypeVersion=1.1.0.1-SNAPSHOT
-DgroupId=fr.devoxx
-DartifactId=chouchoutez-javascript
-Dversion=0.0.1-SNAPSHOT
Une fois ceci réalisé, nous obtenons un projet (que nous allons importer dans notre IDE préféré) ayant la structure suivante :
pom.xml
` src
+ main
| ` javascript
| ` quickstart.js
` test
` javascript
` quickstartTest.js
La partie intéressante dans le pom.xml est la déclaration du plugin Jasmine qui va permettre de lancer les tests via une commande Maven :
<plugins>
<plugin>
<groupId>com.github.searls</groupId>
<artifactId>jasmine-maven-plugin</artifactId>
<version>1.0.1-beta-6</version>
<executions>
<execution>
<goals>
<goal>generateManualRunner</goal>
<goal>resources</goal>
<goal>testResources</goal>
<goal>test</goal>
<goal>preparePackage</goal>
</goals>
</execution>
</executions>
<configuration>
<jsSrcDir>src/main/javascript</jsSrcDir>
<jsTestSrcDir>src/test/javascript</jsTestSrcDir>
</configuration>
</plugin>
En lançant la commande mvn test, on voit que le test généré par défaut par l’archetype est lancé :
------------------------------------------------------- J A S M I N E T E S T S ------------------------------------------------------- [INFO] describe The quickstart object it adds two numbers [INFO] Results: 1 specs, 0 failures
Etape #2 : Ecrire des tests
Je copie mon underscore.js dans le répertoire src/main/javascript, et nous allons le tester…
Jasmine propose une écriture assez intuitive des tests, assez proche de fest-assert. En voici un premier exemple :
describe("Mon premier test", function() {
it("should be 42", function() {
var resultat = _.max([1, 2, 3, 42]);
expect(resultat).toBe(42);
};
};
Avec Jasmine, on crée une suite de tests en utilisant le mot describe, suivi de son descriptif. Ensuite, on y ajoute une série de tests (voire on imbrique de nouvelles suites), chaque test (ou plus exactement chaque spec) étant défini par le mot clé it. On écrit le code du test, puis au moment de vérifier (i.e. de réaliser les assert), on va simplement utiliser expect suivi d’un matcher (ici toBe). Plusieurs autres matchers existent (toEqual, toBeNull, toBeGreaterThan, toContain, toBeUndefined).
A nouveau, je vérifie mes tests avec la commande Maven mvn clean test.
Voici mon fichier de tests final de la librairie underscore.js :
describe("Mon premier test", function() {
it("should be 42", function() {
var max = _.max([1, 2, 42]);
expect(max).toBe(42);
});
});
describe("Test d'underscore", function() {
var myarray;
beforeEach(function() {
myarray = [1, 2, 3];
});
it("should return 42 when asked for last item", function() {
var res = _.last([1,2,3,42]);
expect(res).toBe(42);
});
it("be true", function() {
var res = _.first([1, 2, 3]);
expect(res == 1).toBeTruthy();
});
it("should be greater than 2", function() {
expect(3).toBeGreaterThan(2);
});
it("should contains 2", function() {
expect([1, 2, 3]).toContain(2);
});
it("should have size of 3", function() {
expect(myarray.length).toBe(3);
});
it("should not be 1", function() {
var res = _.max([1, 2]);
expect(res).not.toBe(1);
})
});
describe("test with spy", function() {
it("should spy on last", function() {
spyOn(_, 'last');
var res = _.last([1, 2, 3]);
expect(_.last).toHaveBeenCalled();
expect(res).toBeUndefined();
});
});
Vous remarquerez qu’à l’instar d’un @Before de JUnit, Jasmine offre la même possibilité avec beforeEach.
De plus, Jasmine offre aussi des fonctionnalités d’espionnage.
Etape #3 : Analyser son code
Pour analyser le code JavaScript, nous allons utiliser le merveilleux outil qu’est Sonar ! Il nous faut simplement y ajouter le plugin pour le support du langage JavaScript, qui se trouve ici.
Dans notre pom.xml, nous devons ajouter ces quelques lignes, pour spécifier que le projet est de langage JavaScript, et indiquer la localisation de nos sources (et celles des tests) :
<properties>
<sonar.language>js</sonar.language>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
</properties>
<build>
<sourceDirectory>src/main/javascript</sourceDirectory>
<testSourceDirectory>src/test/javascript</testSourceDirectory>
Il suffit désormais de lancer la commande mvn sonar:sonar pour réaliser l’analyse complète, puis de se rendre sur son serveur Sonar pour en lire les résultats !
Tout n’est pas encore parfait, car nous ne disposons d’aucune information propres aux tests : pourcentage de réussite, taux de couverture du code, etc.
Etape #4 : Analyse de la couverture
Le plugin JavaScript pour Sonar sait lire les résultats des tests exécutés par js-test-driver, une autre librairie de tests JavaScript, plus orientée TDD (Tests Driven Development, ou Développement piloté par les tests). Cette librairie apporte une syntaxe très proche de JUnit, en particulier concernant les assertions. En voici un exemple :
GreeterTest = TestCase("GreeterTest");
GreeterTest.prototype.testGreet = function() {
var greeter = new myapp.Greeter();
assertEquals("Hello World!", greeter.greet("World"));
};
Bon. Mais il faut tout réécrire, et perdre ce que l’on a fait avec Jasmine du coup ? Heureusement non ! Il existe en effet un adaptateur pour exécuter des tests Jasmine via js-test-driver.
Bien entendu, nous aurions pu partir dès le début avec la librairie js-test-driver, et oublier Jasmine, mais ça n’aurait pas été fun !
Donc pour faire marcher tout cela, il faut tout d’abord copier dans un répertoire lib/ les fichiers suivants :
jasmine.js(auparavant, il était chargé via le plugin Maven, que nous n’allons plus utiliser.JasmineAdapter.js, le fameux adaptateur.
Puis, je crée un fichier jsTestDriver.conf à la racine du projet qui contient la configuration pour js-test-driver :
server: http://localhost:9876 load: - "lib/jasmine.js" - "lib/JasmineAdapter.js" - "src/main/javascript/*.js" - "src/test/javascript/*.js"
Ici c’est très simple, on indique le port où tournera le serveur js-test-driver, ainsi que les librairies à charger…
Dernière étape : modifier le pom.xml. D’abord, y supprimer les références au plugin Jasmine, devenu obsolète. Ensuite, ajouter ceci pour la dépendance vers le plugin Maven de js-test-driver :
<dependencies>
<dependency>
<groupId>com.googlecode.jstd-maven-plugin</groupId>
<artifactId>jstd-maven-plugin</artifactId>
<version>1.3.2.5</version>
<scope>test</scope>
</dependency>
</dependencies>
Puis je configure le plugin comme ceci :
<build>
...
<plugins>
<plugin>
<groupId>com.googlecode.jstd-maven-plugin</groupId>
<artifactId>jstd-maven-plugin</artifactId>
<configuration>
<port>9876</port>
<browser>/Applications/Firefox.app/Contents/MacOS/firefox-bin</browser>
<tests>all</tests>
<config>jsTestDriver.conf</config>
<testOutput>target/jstestdriver</testOutput>
</configuration>
<executions>
<execution>
<id>run-tests</id>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
On notera que certaines informations du fichier jsTestDriver.conf (comme le port du serveur) sont reprises ici. On spécifie aussi le chemin vers le navigateur utilisé par js-test-driver pour exécuter ses tests (chose inutile avec Jasmine, car ce dernier ne nécessite même pas de DOM pour exécuter les tests !).
Dernier point : j’ajoute le repository où se trouve le plugin js-test-driver :
<repositories>
<repository>
<id>jstd-maven-plugin google code repo</id>
<url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>jstd-maven-plugin google code repo</id>
<url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
</pluginRepository>
</pluginRepositories>
Maintenant, pour voir si tout s’est bien passé, je vérifie que l’exécution des tests se réalise bien. J’exécute donc de nouveau la commande Maven mvn clean test :
------------------------------------------- J S T E S T D R I V E R ------------------------------------------- Firefox: Runner reset. .................. Total 18 tests (Passed: 18; Fails: 0; Errors: 0) (9,00 ms) Firefox 9.0.1 Mac OS: Run 18 tests (Passed: 18; Fails: 0; Errors 0) (9,00 ms) [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------
Bravo ! C’est presque gagné ! Il ne nous reste plus qu’à pouvoir mesurer la couverture des tests. Rien de plus simple à ce stade : il suffit d’éditer le fichier jsTestDriver.conf et d’y ajouter les 4 lignes suivantes :
plugin:
- name: "coverage"
jar: "lib/coverage-1.3.4.b.jar"
module: "com.google.jstestdriver.coverage.CoverageModule"
Je relance mvn clean package sonar:sonar, et l’analyse contient désormais les résultats des tests, mais aussi la couverture du code !
Etape #5 : Intégration continue
Lors de la présentation, j’ai manqué de temps et ai dû passé cette étape. Mais ici, rien de magique ni d’extraordinaire. En effet, comme depuis le début j’utilise des commandes Maven, les faire jouer par un serveur d’intégration continue est d’une simplicité enfantine. Je vous laisse donc le soin de jouer avec Jenkins ou tout autre serveur…
Conclusion
J’ai montré en une demi-heure environ qu’il était très simple de tester son code JavaScript, de l’analyser. Les mêmes outils sont d’ailleurs mis en oeuvre que pour le langage Java : Maven, Sonar et Jenkins.
Bref, il ne reste plus qu’à s’y mettre
Références
- Projet sur GitHub
- Slides sur Slideshare
- Abstract sur le site de DevoxxFR
- Vidéo Parleys (à venir)
]]>
Il faut venir à cette conférence, orientée Java, web, mais pas que. Il y aura du beau, du très beau monde (la preuve, j’y vais). Mais voilà, tu n’as pas ta place, ta (ton) RH n’a rien compris (ils n’ont pas Free ?) et ne veux pas t’envoyer là-bas ? Alors pourquoi ne pas essayer de gagner ton pass ?
Pour cela, tu as quatre concours qui n’attendent que toi :
- Si tu aimes faire du Java, que tu peux faire mieux que Twitter, alors lance-toi sur le Tatami ! Attention, la concurrence est déjà rude !
- Tu préfères le code JavaScript, avec du Node.JS dedans ? Alors Romain (non, pas moi), te lance un défi !
- Tu aimes les JUGs ? Va voir du côté de Nicolas de Loof, là aussi un concours t’attend…
- Tu n’as pas le temps de coder ? Tant pis. Alors il te restera la chance pour gagner un pass.
Bref, il te reste encore quelques jours pour espérer gagner un pass !
Et rendez-vous là-bas !
Start Slide Show with PicLens Lite]]>Alors parlons-en un peu (des fois que vous ne seriez pas au courant, sait-on jamais)
Mais alors, kézako ?
Devoxx, plus anciennement JavaPolis, est une conférence indépendante vieille de 10 ans, qui se tient habituellement à la fin de chaque année à Anvers, en Belgique.
Devoxx, c’est la plus grosse conférence européenne sur Java, la deuxième au monde après JavaOne (conférence « officielle » de Sun-Oracle).
Pour vous donner une idée de ce que ça représente, voici quelques chiffres qui font tourner la tête concernant l’édition de 2011:
- 5 jours de conférences, d’ateliers, de démos, d’échanges…
- 167 conférenciers,
- plus de 3200 personnes !
- sans aucun doute des hectolitres de bière (on est en Belgique quand même)
Bref, Devoxx c’est un peu le salon de l’automobile pour les développeurs Java (mais sans les hôtesses ).
L’une des annonces fracassante de l’édition 2011 a été l’arrivée de Devoxx France, fin avril 2012. Et c’est de ça dont je vais parler…
De quoi ça va causer ?
Le programme n’est pas encore finalisé (l’équipe de sélection des sujets a énormément bossé là-dessus) mais gross-modo, quatre thèmes seront abordés à Devoxx :
- Web, cloud et nosql
- Langages alternatifs pour la JVM
- Java, JavaSE et JavaEE
- Entreprises et pratiques
Bref, rends-toi sur cette page, et bientôt tu auras sous tes yeux le magnifique programme des 3 jours de la conférence…
Et moi (moi, pas toi en fait) ?
J’avais proposé deux sujets et j’ai eu l’immense honneur de les voir tous les deux sélectionnés ! Quand on sait qu’il y a eu près de 4 fois plus de soumissions que de places disponibles, ça nous met tout de suite beaucoup de pression ! Il est vrai que je n’ai pas forcément proposé dans les catégories les plus concurrentielles. Bref, mes sujets sont les suivants :
- Chouchoutez votre code JavaScript, dans les Tools in Action. Le but sera ici de montrer que l’on peut apporter autant de soin à tester et analyser son code JavaScript qu’on ne le fait déjà avec son code Java.
- TestNG, parce que vos tests le valent bien !, parmi les Quickies, où j’exposerais les avantages d’utiliser cette librairie plutôt que JUnit.
Mais… mazette, ça coûte des sous !?
Oui, c’est le prix de la liberté, de ne pas être sous le contrôle d’un grand nom de l’industrie… Il existe 3 tarifs :
- 450€ les 3 jours
- 350€ les 2 derniers jours (les conférences)
- 150€ le premier jour (les universités)
Ca peut paraitre cher (c’est pas négligeable si tu veux payer toi-même ta conférence), mais franchement, ce n’est pas du tout excessif. Il faut voir ce que cela va t’apporter : de nouvelles connaissances techniques, mais aussi humaines, de rencontrer tes idoles de toujours (la liste des speakers n’est pas encore terminée, mais il y a déjà du beau monde !). Compare cela avec une formation à 3000€ pour apprendre les bases de JSF, et tu auras compris où je veux en venir
Avec un peu de chance, tu arriveras à négocier avec ton employer de prendre cela avec ton DIF !
Et comme dans les lessives Bonux, tu as le petit cadeau qui va bien : un abonnement d’une année au site Parleys, un site regorgeant de vidéos d’anciennes conférences (dont Devoxx), de JUG, etc. pour bien apprendre plein de choses merveilleuses !
Bref, vennez nombreux à Devoxx France !!
En attendant, suivez DevoxxFR sur Twitter !
Si tu veux en savoir plus, je te laisse avec les nombreux sujets postés par Nicolas Martignole – alias le Touilleur – qui est l’un des organisateurs de la conférence…
Affiche de Devoxx France du Touilleur Express
Start Slide Show with PicLens Lite]]>- 13h30 – 14h20 : NoSQL, tour d’horizon par Claude Falguière et Grégory Paul
- 14h30 – 15h05 : Migration top chrono d’une application JEE sur le Cloud Amazon par Fréderic Sauzet et Hervé Desaunois
- 14h10 – 15h45 : Migration top chrono d’une application .NET sur le Cloud Azure par Lionel Molas et Cyril Aigoin
- 16h00 – 17h30 : Ateliers de réflexion sur le thème de la mobilité
- 17h50 – 19h50 : Coding Dojo Android, Windows Phone 7 et iPhone animés par Pascal Ognibene, Philippe Miossec et Sylvain Rousseau
Demain s’annonce donc être une journée passionnante et très instructive !
Suivez en direct mes tweets ainsi que ceux de @ValtechTechno.
]]>