2011-04-06-MIX-IT-FR.md

#MIX-IT

j'y étais et croyez moi, ça vallait le détour. Une journée entière entouré de "geeks" et de passionnés, des sujets tous plus intéressants les uns que les autres (difficile de choisir), des speakers excellents, des organisateurs sympas qui connaissent leur boulot (même si ce n'est pas forcément leur métier, donc bravo), une ambiance agréable avec des gens qui ne se la joue pas.

J'ai assisté à :

• Spock ou "les tests du futur" présenté par @mathildelemee
• Grails "from scratch to production" par @aurelienmaury
• BDD : "une voie vers l'agilité" par Mauro Talevi
• Intelligence collective avec Apache Mahout par @mfiguiere
• Pimp my app par @nmartignole (Play! & HTML5)

Je vais essayer de vous faire un (très) rapide tour d'horizon de ce que j'ai retenu de cette journée (en fait, ce sont juste mes notes au propre)

##La key-note d'introduction

Le speaker était Nicolas Martignole (@nmartignole) aka "Le Touilleur Express" qui nous a expliqué que notre métier était quand même bien sympa, et que c'est aux codeurs (expérimentés ?) de prendre le pouvoir en entreprise (c'est ma traduction)

##Spock

Spock est un framework de test qui vous apprend à aimer à faire des tests (SI!), il s'appuie sur Groovy et JUnit.

###Problématique

Il existe aujourd'hui beaucoup d'outils de tests, de mock dans le monde Java. Mais le plus difficile c'est :

• écrire un bon test (+dur qu'écrire un bon code)
• maintenir ses tests (eh oui, les gars, il ne faut pas oublier ça non plus)

###Une réponse : Spock

Spock apporte la lisibilité des tests, il n'est pas qu'un outil de mock, il s'appuie sur les labels avec un mode de fonctionnement qui est le suivant :

given: /*les éléments d'entrée*/

when: /*stimulus-stimuli, le(s) élément(s) qui déclenche(nt)*/

then: /*l'élement de contrôle*/ (il y a aussi expect:)

/*même sans framework de test, on devrait mettre ça dans son code*/

Avec Spock on parle de spécifications plutôt que de tests

Avec Spock, vous pouvez faire du Stub & du Mock :

• Stub : test d'état, où l'on s'intéresse à l'état final
• Mock : test de comportement, on s'intéresse à l'enchaînement des méthodes

###Exemples de code de test

class HelloSpock extends spock.lang.Specification {
    def "length of Spock's and his friends' names"() {
        expect:
        name.size() == length

        where:
        name     | length
        "Spock"  | 5
        "Kirk"   | 4
        "Scotty" | 6
    }
}

###Data Driven Testing

def "determine dominant color"() {
  when:
  action.image = image
  action.ignoreWhite = ignoreWhite
  action.execute()

  then:
  action.dominantColor == dominantColor		

  where:
  image                   | ignoreWhite | dominantColor
  '/images/white.png'     | false       | 'ffffff'
  '/images/black.png'     | true        | '000000'
  '/images/28843_300.jpg' | true        | 'ffcc33'
  '/images/20341_300.jpg' | true        | 'cc6666'
  '/images/20692_300.jpg' | true        | 'cccccc'
  '/images/7870_300.jpg'  | true        | '993333'
}

Avouez que pour la documentation de vos tests, il n'y a plus grand chose à faire Vous pouvez l'utiliser conjointement avec Selenium pour faire du test d'IHM

Spock c'est ici : http://code.google.com/p/spock/ ne vous privez pas.

##Grails

Alors je connaissais déjà, mais ça fait du bien d'écouter un sujet où l'on comprend tout ;).

Grails est un framework pour réaliser des applications Web :

• c'est du MVC basé sur Groovy
• il est inspiré de ROR, Django, TurboGears
• c'est une "stack" complète avec hibernate, spring, un tomcat embarqué, etc. ...

###Son but

• Ajouter un niveau d'abstraction
• Réduire la complexité
• Scripter les tâches répétitives
• Améliorer la productivité
• ...

###Son fonctionnement

• Grails fonctionne par convention plutôt que par paramétrage (même si cela reste possible), mais accepter la convention c'est gagner du temps.
• Il impose une structure pour réduire les duplications, on sait tout de suite où l'on doit chercher
• c'est une plateforme complète qui fournit à la fois la méthodologie et les approches, qui utilise des briques standard (hibernate, spring, ...) le tout manipulé à partir de script Groovy.

Finalement tout est simplifié avec Groovy. La courbe d'apprentissage est très bonne, à savoir que cet apprentissage peut être progressif puisque vous pouvez même faire tourner du code pur java dans un script groovy.

Le tout avec un coût très faible en nombre de lignes.

###Scaffolding

C'est une des forces de Grails (si ce n'est LA force). En effet, Grails permet la génération du CRUD à partir des entités, mais contrairement à ROR qui est orienté "Schéma base de données", Grail est "orienté domaine".

####CéKoiCa ???

En fait vous décrivez vos classes models et Grails va se débrouiller pour vous générer toute votre base de données et les mappings à partir de ça (Eh oui, tu es nul en SQL, tu peux être bon en Web)

Il ya aussi du scaffolding dynamique (en gros rien ou peu à écrire), très pratique, pas de bug du coup (ou alors ceux sont ceux du framework ;) )

###GORM

c'est la partie qui permet de créer la base (donc de définir votre modèle par conventions), de requêter vos models, etc ...

Par exemple, relations entre livres et auteurs :

class Author {
    static hasMany = [ books : Book ]
    String name
}
class Book {
	static belongsTo = [author:Author]
	String title
}

###Les Vues

Cela fonctionne à base de templating très proche de JSP, normalement il y a tous les taglibs nécessaires pour vous faciliter la vie, mais vous pouver insérer du code Groovy (c'est mal) ou créer vos propres taglibs (c'est bien)

Le framework js embarqué par défaut est Prototype (gage de qualité)

###Grails est extensible

Il existe de nombreux plug-ins pour Grails :

• CodeNarc : qualité de code
• un plugin pour se plugger sur MongoDB et utiliser directement les finders dynamiques (GORM)
• plugin pour birt-report
• plugin pour recherche full text (basé sur Lucene)

etc. ...

###Performances, le "hic" ? oui mais ...

• 5 à 7 fois plus lent que Java (reste lent même si on compile en byte code java, Groovy c'est une surcouche qui "pilote" java)
• on peut descendre à 3 fois plus lent avec Groovy++

Après c'est un choix : Productivité vs Vitesse d'exécution

En même temps, Grails c'est "Fast enough" et ça répond à 95% des besoins.

Rien ne vous empêche d'augmenter la puissance de vos machine, c'est peu coûteux en regard du gain de productivité.

###Quand utiliser Grails ?

• Quand vous avez besoin d'un produit viable rapidement
• Pour un nouveau projet Web
• ...

Si le schéma de la base de données est très très complexe, faut un peu réfléchir ;)

####Petite info

EverBank utilise Grails pour ses services en ligne

####Mon avis

Si vous avez quelques heures (il n'y a pas besoin de plus) devant vous, testez Grails, vous comprendrez par vous même les avantages de ce framework.

http://www.grails.org/

##BDD : Behaviour Driven Development

Cette présentation n'était pas technique, plutôt conceptuelle. Elle présentait les paragdimes du "Behaviour Driven Development" qui ont clairement un impact/lien à la fois avec la méthodologie de réalisation (on parle d'agilité) et les méthodologies de spécification, codage, test, ...

Je vous livre ici ce que j'ai pu noter. Je suis persuadé que c'est un sujet sur lequel il faut prendre le temps de réfléchir. Même sans mettre en place une mécanique technique de BDD, les best practices sont à prendre.

###Un nouveau paragdime

Sur bien des projets :

• le système ne fait pas ce qui était prévu
• il manque des fonctionnalités
• le système est développé en "Silos" (méthode waterfall) (isolement) (effet tunnel)
• pendant la réalisation il n'est pas accessible/visible par le métier
• les tests d'acceptation ... comment dire ... c'est du n'importe quoi

BDD apporte un nouveau paragdime :

"la façon d’exprimer les tests était souvent plus importante que l’implémentation"

• décrire un comportement est un meilleur type de test
• avoir un langage universel est la clef
• les tests d’acceptation doivent être automatisables
• toutes les requêtes sont aussi des comportements (ndla : là je ne suis pas sûr d'avoir compris)

###Le langage

Le BDD est un paradigme basé sur la définition du comportement (description du comportement de la fonction) du point de vue des stakeholders (ceux qui ont un intérêt ds les système : métier, sécurité, qté, …).

Il est important de

• choisir la bonne frontière (par exemple pas tous les stakeholders ensembles)
• parler le langage du métier :

• il faut définir un langage spécifique pour le domaine (DSL)
• concentrez vous sur les concepts du métier
• décrire les comportements du point de vue du métier
• éviter les détails techniques

BDD s’ocuppe de la description du QUOI pas du COMMENT

###Un peu de vocabulaire/définitions

• une histoire = user story = une collections de scenarios
• chacun des scénarios étant une colection d’etapes
• les histoires décrivent des comportements, çad : la fonctionnalité attendue par le métier
• etc. ... (ndla : pas arrivé à tout prendre en note)

###Exemple d'une conversation avec le business/métier

• étant donné un seuil de 15.0
• quand une action est échangée à 5.0
• alors le trader ne doit pas être alerté

Nous avons là des étapes.

• étant donné = contexte, quand = évènement, ...
• on peut combiner les étapes
• il faut choisir les paramètres d'étapes 15.0, 5.0, ne doit pas
• il faut permettre l'évolution du langage : ex : un seuil devient un seuil de prix, stock à la place de action
• etc. ...

###BDD versus TDD

• Le BDD parle langage du métier et l’écrit en texte
• le TDD parle un langage technique et l’écrit en code
• "Best practice" : utiliser les 2

BDD permet d’automatiser les textes en mettant l’accent sur la communication TDD est un paragdime générique d’automatisation des tests, pas toujours communicatif

####Conclusion

BDD est idéal pour un projet agile.

####Outillage

• le speaker nous a parlé de http://jbehave.org/

• le fonctionnement : http://jbehave.org/reference/stable/
• 1 exemple de code :

	public class GridSteps { // Look, Ma', I'm a POJO!

	    private Game game;
	    private StringRenderer renderer;

	    @Given("a $width by $height game")
	    @Aliases(values={"a new game: $width by $height"})
	    public void theGameIsRunning(int width, int height) {
	        game = new Game(width, height);
	        renderer = new StringRenderer();
	        game.setObserver(renderer);
	    }

	    @When("I toggle the cell at ($column, $row)")
	    public void iToggleTheCellAt(int column, int row) {
	        game.toggleCellAt(column, row);
	    }

	    @Then("the grid should look like $grid")
	    @Aliases(values={"the grid should be $grid"})
	    public void theGridShouldLookLike(String grid) {
	        assertThat(renderer.asString(), equalTo(grid));
	    }

	}

J'ai trouvé ces quelques liens qui ont l'air sympas :

• JSpec : BDD pour javascript https://github.com/visionmedia/jspec ... pas l'air de "bouger" beaucoup
• GSpec : BDD pour Groovy http://groovy.codehaus.org/Using+GSpec+with+Groovy

##Apache Mahout

Mahout est un outil d'intelligence collective (une manière de classer les données et d'en sortir des agrégats).

• Les données aléatoires ne sont pas prévisibles
• En entreprise elles ne sont pas complètement aléatoires
• Et on peut y retrouver des patterns reconnaissables : des agrégats qui se dégagent
• L'intelligence collective, c'est exploiter toutes les intelligences d'un groupe, et c'est grâce à ça que l'on va pouvoir extraire et exploiter ces agrégats

###On parle aussi de "Machine Learning"

le Machine Learning est un sous ensemble de l’intelligence artificielle. Aujourd'hui, NOSQL, marchine learning et moteurs de recherche sont complémentaires.

Les principaux type d'algorithmes de marchine learning sont :

• recommandations : recommande des items à un utilisateur
• classification : classifie automatiquement des docs en apprenant à partir d’un ensemble déjà classifié
• clustering : découvre automatiquement des groupements parmi un ensemble de documents

####Exemple de cas d’usage de recommandation :

• conseiller des items aux clients d’un site d’e-commerce : augmentation du CA
• conseiller des fonctionnalités aux utilisateurs : la plupart des fonctionnalités sont méconnues
• filtrer et adapter le classement des résultats d’un moteur de recherche : en se basant sur les clics des utilisateurs similaires

####Exemple de cas d’usage de classification

• associer automatiquement des tags à des documentss : ensemble de tags définis manuellement ou depuis wikipedia par exemple

####Exemple de cas d’usage de Clustering :

• Google news (actualités) agrège les sujets tendances de manière automatique
• Trouver les sujets principaux dans un ensemble de documents
• Découvrir des usages typiques des utilisateurs (profilage des utilisateurs : consommation, horaires etc. …)

###Mahout = collection de machine learning

• la plupart disponibles en version MapReduce
• Utilisable avec de gros datasets
• Encore jeune mais en croissance rapide
• Mahout permet d’évaluer la précision

On est dans le monde du plus ou moins pertinent et il faut des phases d’étalonnage

http://mahout.apache.org/

###Exemples

####Créer un modèle et définir les similitudes des users :

//create the data model
FileDataModel dataModel = new FileDataModel(new File(recsFile));
UserSimilarity userSimilarity = new PearsonCorrelationSimilarity(dataModel);
// Optional:
userSimilarity.setPreferenceInferrer(new AveragingPreferenceInferrer(dataModel));

####Générer des recommandations :

//Get a neighborhood of users
UserNeighborhood neighborhood =
        new NearestNUserNeighborhood(neighborhoodSize, userSimilarity, dataModel);
//Create the recommender
Recommender recommender =
        new GenericUserBasedRecommender(dataModel, neighborhood, userSimilarity);
User user = dataModel.getUser(userId);
System.out.println("-----");
System.out.println("User: " + user);
//Print out the users own preferences first
TasteUtils.printPreferences(user, handler.map);
//Get the top 5 recommendations
List<RecommendedItem> recommendations =
        recommender.recommend(userId, 5);
TasteUtils.printRecs(recommendations, handler.map);

Bon, il y a quand même du boulot pour arriver à s'en servir pour les nous(moi) les ingés d'informatique de gestion, mais c'est extrêmement intéressant.

##Pimp my app

Désolé je n'ai pas pris de notes, j'étais trop concentré à écouter ce que disait Nicolas sur Play!Framework mais j'ai retenu ceci :

• Play! c'est simple (je le savais, mais quand c'est un spécialiste qui vous le démontre c'est mieus)
• Play! c'est rapide (je le savais ... bis repetita placent)
• Play! + HTML5 + JavaScript + CSS3 : c'est GRAND!

En fait (c'est mon avis), Play! arrive relativement "tout nu" pour ce qui concerne l'IHM, si ce n'est tout de même un excellent moteur de templates et embarque jQuery. L'avantage c'est qu'il n'impose rien et permet d'utiliser tout ce que l'on veut comme framework JS, de plus Play! génère sans problème du JSON, je vous laisse imaginer ... La démo parlait d'elle même.

Le développeur de Play!, Guillaume Bort, ne vient pas du monde Java mais du monde ROR, ce qui explique que Play! est fait pour le Web. Guillaume s'est inspriré des bonnes pratiques de ROR et à utilisé les briques intéressantes de Java.

###Quelques points

• pas besoin de coder les getters et setters (sauf si vous avez vraiment envie)
• des controllers le plus petit
• des models qui sont de vrais objets métiers (on enlève les services des controllers)
• ...

###Mon conseil

Si il y a une démo Play!Framework près de chez vous, allez-y, ou si vous avez quelques heures devant vous, installez le, et jouez (elle est facile #jeuxdemotàlac...)

##MIX-IT

... Vivement l'année prochaine !