Ma journée à Mix It

Ce 5 avril 2011, s'est tenu le mix-it, conférence autour de java et de ses pratiques, organisée par le Lyon JUG et Kara. Celle çi était articulée de 5 thèmes : Techy, Agility, Tendy, Mixy, Gamy.
Soit 25 sessions au total. J'étais parmis les 250 personnes qui s'y sont rendu. Je vais vous faire une petite rétrospective de quelques sessions auxquelles j'ai assisté au cours de cette belle journée.

Nous étions quelques Parisiens, habitués du Paris JG, à s'être déplacé, dont certains en temps que Speaker.
Et c'est justement par Nicolas Martignole que commence la traditionnelle keynote, après une courte présentation de Objet Direct, principal sponsor de d'évènement.

Keynote

Nicolas commence par une question, « Qui est fier ce qu'il a réalisé ? ». Peu de monde, dans l'assistance lève la main. Cette question a pour but d'amener au constant suivant : le plus important, ce n'est pas le résultat mais le processus.
Il y a quelques années, on ne parlait pas de TDD, agilité, ni aucun terme tendance auquel nous sommes aujourd'hui habitués. A la place, on parlait d'architecture, d'UML, …
Nous n'avons plus la même façon de construire une application qu'autrefois (si j'ose dire) : nous livrons régulièrement par exemple. Nicolas aime assez la vision du craftmanship et nous expose 12 points du métier de développeur aujourd'hui.
1/ Pattern de l'iceberg : le client ne voit que ¼ de ce qui se passe, il est donc normal qu'il ne comprenne pas qu'une tache ait pris plus de temps que ce qu'il n'imaiginait.
2/ Comprendre ce qui va changer à la fin : Imaginons que vous naviger dans un bateau, vous préférez un point de rendez vous que vous recalculer chaque jour en fonction des contraintes ou un point de rendez vous cap 180° et on se revoit dans 10 jours ?
3/ Simplicité. Nous autre développeurs java, sommes de passionnés de technique et inventons régulièrement de nouveaux frameworks. Mais tant de complexité et elle nécessaire ?
4/ Itérer et avancer. Tout comme un musicien qui s'entraine, nous devons savoir jeter du code, le mouvement est important.
5/ Vision du jardinier, savoir pensez long terme.
6/ Mouvement permanent. Il ne faut pas attendre mais savoir bouger, en faisant de la veille par exemple.
7/ On ne dit pas de « Je fais de l'architecture » mais du « je fais du code propre ». C'est implicite dans la réalisation logicielle.
8/ Avoir le temps de se planter. C'est un avantage de l'agilité. Si au bout de 15 jours vous vous rendez compte ça passe. Mais si un cycle en V fait que vous vous en rendez compte, les conséquence auprès du client de sont pas les mêmes.
9/ Soyez sans pitié. Le code pourri ou en commentaire, il file tout droit à la poubelle.
10/ Le client est roi (mais on est pas non plus sa mère). Avec lui, on ne parle de qu'il connait : le métier, mais pas de techno. A l'inverse, ce n'est pas à lui, d'imaginer la solution technique. Lorsque vous prenez l'avion, donnez vous de conseils au pilote ?
11/ Gérer son manager. C'est en quelque sorte le ministre des affaires étrangère, c'est lui gère les relations entre l'équipe et le monde extérieur. S'il passe trop de temps à gérer l'équipe en elle même, c'est qu'il y a un soucis.
12/ Nous sommes des développeurs. Nous ne voulons pas être chef, amusez vous.

Spock, les tests du futur

Mathilde Lemée, habituée du Paris JUG mais aussi une des fondatrices des Duchess France, vient nous parler de Spock. Ce dernier, n'est pas qu'un personnage de la série Star Trek, c'est aussi framework de test venu de la galaxie Groovy.
Lorsque l'on écrit des tests, on a tendance à oublier leur partie critique : la maintenance.
Spock se veut de rendre les tests lisibles, ce qui facilite grandement de travail lorsque l'on refactore.
L'approche setup/expect/where ou given/when/then, facilitée par les labels, permet de tester une seule chose à la fois. La première syntaxe est adaptée à des cas de test simple type action/vérification du résultat. La seconde, elle est plus adaptée à des cas complexe où par exemple, je vais devoir faire appel à des éléments externes.
Il est important de différencier les mocks des stubs, ils n'ont pas les même rôles. Le stub est un bouchon stupide. Il sert simplement à tester l'état, mais n'a pas vocation à faire échouer le test. Au contraire, le mock peut faire échouer le test, car on teste son comportement.
En terme de code, la différence est assez simple : sois je vérifie si mon appel est bien effectué, soit je ne le fais pas.
Le problème posé par la sur utilisation des mocks, c'est que les tests casse au moindre refactor et consomme du temps pour les réparer.
Martin Fowler apporte plus de précisions dans son article sur le sujet.
Ce qu'apporte principal Spock aux tests, c'est une syntaxe plus souple.

def "account activation mail sent to user"(){
setup:
UserService userService = new UserService()

def emailService = Mock(EmailService) 
emailService.sendMail(_,_,_,_) >> true  
userService.emailService = emailService

User user = new User(email : "testUser@gmail")

when:
boolean success = userService.sendActivationMail(user)

then:
1*.emailService.sendMail("testUser@gmail","admin@admin.com","Your account is activated", "Congratulation now you can login")
success == true
}

Ce que l'on note :

• Nom de méthode expressif et lisible
• Configuration simple du résultat de la méthode du mock grace à >>
• Configuration simple de la vérification de l'appel du mock 1* …
• Pas d'assert sur le résultat, il est implicite

De façon globale, la syntaxe est assouplie grace aux bloc given/when/then qui permettent d'éviter l'utilisation de mots clés, ce qui au final donne une lecture plus naturelle des instructions.

Cette lisibilité est accru dans le cadre de tests avec jeu de données :

def "String param should correspond to numeric spockInfoDay"() {
    setup:
    def spockResource = new SpockResource(new CalendarDaoStatic())
    expect:
    spockResource.findCalendarByDay(day).day == dayNumeric

    where:
    day     | dayNumeric
    "1"  | 1
    "2"  | 2
    "3"  | 3
  }

N'est ce pas plus plaisant à lire ?

Intelligence collective avec Apache Mahout

Je suis allé sur ce sujet que je ne connais absolu pas, par curiosité. C'est Michael Figuière qui nous a présenté à ce framework.
L'intelligence collective est supérieure à l'intelligence du plus intelligent. Wikipedia est un exemple, il contient beaucoup plus de connaissance que quiconque.
Aujourd'hui, internet permet d'agréger tout un tas de données. Page Rank agrège par exemple l'intelligence collective des sites web. Ainsi, par de nombreux liens, le site officiel de mix-it est la première réponse à la recherche « mit it ».
Le machine learning est un concept clé de Apache Mahout. Il s'agit d'un sous ensemble de l'intelligence artificielle. Les applications en sont par exemple :

• Recommandation à d'un livre à un client en fonction de ce qu'il a déjà acheté ou de ce que les autres ont achetés en même temps.
• Classification automatique de mails en fonction de qui a déjà été classé.
• Conseil de fonctionnalité : si un utilisateur ne s'en sert pas, peut être qu'il ne la connait pas.
• Adapter filtrage en fonctionnalité du profil : quand je cherche un livre sur java, faut il favoriser l'informatique ou les livres sur l'ile ?
• Filtrage du spam
• Agreger un flux actualité en fonction des tendances.

Pour nous, dans le domaine de l'informatique de gestion, ces concepts ne nous sont pas familliés. C'est justement là qu'intervient Apache Mahout en fournissant un implémentation java des algorithmes dernières ces concepts, facilitant ainsi leur intégration dans nos applications. Un bonne partie de cette implémentation est faite en Map/Reduce. Le framework est encore jeune mais connait une croissance rapide.


Pimp my app

Pour finir en épanadiplose, je finis ma journée par la présentation de Nicolas Martignole sur Play.
Quelques éléments pour moderniser une dans un navigateur web tout en s'amusant :

• Html5/css3/jquery
• Play
• Huile de coude

Play! est développé à la base par Guillaume Bord, une personne du monde du web et de Ruby, et donc qui pas connu les joies des EJB 2. Devant la complexité du développement web en java, il a voulu réconcilier les 2 mondes en récréant ce qu'il connaissait avec Rails.
Tout d'abord, Play! n'utilise pas l'api servlet, est sans état sur le serveur. Choses banale dans d'autres technos utilisés pour faire du web. C'est justement sur Rails, Django et Grails que vient sont inspiration.
Avec Play! devient facile de développer rapidement une idée, ainsi moins de scrupules à jeter du code si l'on est pas satisfait. Un des aspect qui permette sa simplicité, c'est son absence de session coté serveur et qui va en adéquation avec les principes de REST.
C'est un framework fullstack, je fais tous avec lui : écriture de code, compilation, test et déploiement. Tous ça au sein de son environnement. Pour éviter d'être prisonnier de son serveur, on peut même packager en war et déployer sur un serveur d'application, bien que l'esprit de soit un peu perdu dans ce cas.
Nicolas nous explique que la question de se poser l'utilisation chez le client et la même que celle qui se posait il a 5 ans, à savoir si on peut utiliser Play.
Et bientôt, avec la version 1.2 on pourra piocher des dépendances avec modules Ivy.
Pour le moment, un ses points faibles c'est l'industrialisation des développements.

Un projet Play à la même structure qu'un projet Ruby :

• src : les sources aussi bien java que html
• test
• conf : la configuration telle que le routage ou les propriétés

Nous avons le droit à une live démo :

• La classe de base qui est un point d'entrée du controller.
• La page htlml, est du script groovy
• Oh mais on pas recompilé et ça marche.
• En mode dev, Play surveille les fichiers et recompile quand il faut, on laisse ainsi tourner le serveur tout en codant
• La trace d'erreur est lisible, ça fait gagner beaucoup de temps.
• Utilisation d'un cookie pour gérer l'état conversationnel avec des cookies.
• Pas de session sur le serveur

Les 2 derniers points nous pousse à avoir une architecture différente.

Niveau graphique, un inconvéniant, c'est qu'il n'y a rien, il faut retourner aux bases : grande utilisation du css et js.
Cela dit, sur ces 2 domaines en cas de problèmes ont peut toujours trouver de l'aide, venant même d'autre communautés comme php et rails.
Pas un peu de code css3, Nicolas nous montre comment embellir sa partie web en ayant par exemple un bouton full-css, de l'ombrage, ….



Cette conférence a été une belle réussite. Aussi, j'ai ouïe dire qu'elle avait été organisées en très peu de temps. Je profite donc de ce billet pour féliciter donc les responsables de celle ci et espère une prochaine édition l'année prochaine. Il est plaisant de voir que les communautés dans toutes la France se bougent pour nous monter de beaux événements à bas coût. Le prochain rendez vous sera le Breizh camp.