yo, qu’est-ce que c’est ?

Aujourd’hui, quand on fait du développement web, et donc en particulier du JavaScript, il n’est plus possible de se passer de bons outils pour développer correctement. Yeoman est l’un d’entre eux. Cet outil est en fait une composition de trois outils :

• grunt, le ”Ant” du JavaScript, c’est-à-dire un exécuteur de tâches ;
• bower le gestionnaire de dépendances ;
• yo dont on va parler ici.

Yo est ce que l’on appelle un project scaffolder, que l’on pourrait traduire en français par “échaffaudeur de projet”. Ok, on n’est pas trop aidé. L’idée derrière ce genre d’outils est de générer le squelette d’une application en fonction d’un contexte donné. Un exemple tout bête : je souhaite démarrer une application avec AngularJS. Plutôt que de passer quelques minutes / heures à configurer les bases de mon projet, je vais utiliser un générateur yo pour me faire ce travail. Une fois exécuté, je n’aurais alors plus qu’à développer mon projet, toutes les bases étant mises en place.

Installation de yo

L’utilitaire yo s’installe via npm, ce qui signifie qu’il vous faudra installer NodeJS si ce n’est déjà fait. Une fois installé, il suffit de lancer la commande npm install -g yo (l’option -g assure une installation globale au système) pour que yo soit installé. Un petit yo -v nous assurera de sa bonne installation.

Utiliser un générateur yo

Concrètement, yo va faire appel à un générateur spécifique pour générer le squelette de notre application. Si je tape simplement yo dans ma console, celui-ci va me propose quelques options (le nombre d’options va dépendre de ce qui est installé sur ma machine) :

1
2
3
4
5
6
7
8
9
10

$> yo
[?] What would you like to do? (Use arrow keys)
> Run the Generator generator (0.4.4)
  Run the Webapp generator (0.4.9)
  Run the Karma generator (0.8.1)
  Run the Mocha generator (0.1.3)
  Update your generators
  Install a generator
  Find some help
  Get me out of here!

Comme vous le voyez, les choix qui s’offrent à moi sont soit l’exécution d’un générateur, soit la mise à jour ou l’installation de nouveaux générateurs. Normalement, seuls les deux premiers générateurs (générateur de générateur yo et générateur d’applications web) sont disponibles initialement.

Admettons que nous voulons créer une application AngularJS. Nous allons donc faire appel au générateur Angular. Deux options s’offrent à nous :

1. Passer par la commande npm install -g generator-angular, qui installera le générateur ;
2. Passer par la ligne de commande de yo :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

$> yo
[?] What would you like to do?
  Run the Generator generator (0.4.4)
  Run the Karma generator (0.8.1)
  Run the Webapp generator (0.4.9)
  Run the Mocha generator (0.1.3)
  Update your generators
> Install a generator
  Find some help
  Get me out of here!


$> yo
[?] What would you like to do? Install a generator
[?] Search NPM for generators: angular
[?] Here's what I found. Install one? (Use arrow keys)
> generator-angular
  generator-angular-axiom
  generator-angular-beego
  generator-angular-bootstrap
  generator-angular-bootstrap-less
  generator-angular-browserify-express
  generator-angular-caveman2
  generator-angular-cmelion
(Move up and down to reveal more choices)

Dans les deux cas, c’est bien npm qui va s’exécuter pour installer le générateur. Pour lancer la génération, c’est la même chose : soit nous exécutons la commande yo angular (le nom du générateur, sans le generator- devant), soit nous passons par la commande yo et on se laisse guider par l’outil. Attention, yo génère les sources de l’application dans le répertoire courant, pensez donc à créer un sous-répertoire avant.

Là, en fonction du générateur, un certain nombre de questions vont nous être posées, par exemple pour savoir si nous voulons utiliser SASS ou Bootstrap :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$> yo angular

     _-----_
    |       |
    |--(o)--|   .--------------------------.
   `---------´  |    Welcome to Yeoman,    |
    ( _´U`_ )   |   ladies and gentlemen!  |
    /___A___\   '__________________________'
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

Out of the box I include Bootstrap and some AngularJS recommended modules.

[?] Would you like to use Sass (with Compass)? No
[?] Would you like to include Bootstrap? Yes
[?] Which modules would you like to include? (Press <space> to select)
>[X] angular-resource.js
 [X] angular-cookies.js
 [X] angular-sanitize.js
 [X] angular-route.js

Une fois la commande terminée, nous diposons d’un répertoire bien configuré. Il est parfois requis d’exécuter les commandes npm install (pour installer les contributions Grunt) et bower update (pour télécharger les dépendances de l’application) afin d’être tout à fait prêt, mais normalement le générateur va se charger de cette opération. Voici les principaux éléments de structure de l’application générée :

1
2
3
4
5
6
7
8
9

bower.json                     -> Déclaration des dépendences pour Bower
Gruntfile.js                   -> Définition des tâches pour Grunt
package.json                   -> Description de l'application
  +- app                       -> Répertoire des sources
  |    +- bower_components     -> Dépendences téléchargées par Bower
  |    + *                     -> Sources de l'application
  +- node_modules              -> Modules NodeJS nécessaires à l'application (essentiellement pour Grunt)
  +- test                      -> Répertoire des tests (Karma et Jasmine)
       +- *                    -> Sources des tests

Comme on peut le voir, yo fait appel à ses deux copains de yeoman pour travailler : Bower et Grunt. En tapant par exemple grunt serve, Grunt va exécuter quelques tâches et démarrer un serveur :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$> grunt serve
Running "serve" task

Running "clean:server" (clean) task

Running "bowerInstall:app" (bowerInstall) task

Running "concurrent:server" (concurrent) task

Running "copy:styles" (copy) task
Copied 1 files

Done, without errors.

Running "autoprefixer:dist" (autoprefixer) task
Prefixed file ".tmp/styles/main.css" created.

Running "connect:livereload" (connect) task
Started connect web server on 127.0.0.1:9000.

Running "watch" task
Waiting...

Grâce à la tâche livereload de Grunt, chaque modification du code va entraîner le rechargement automatique de la page :

1
2
3
4
5

Waiting...OK
>> File "app\views\main.html" changed.

... Reload app\views\main.html ...
Completed in 0.001s at Sun Jun 01 2014 11:02:17 GMT+0200 (Romance Daylight Time) - Waiting...

Comme je le disais plus haut, cela prend à peine une minute, et au final, nous disposons d’une application prête pour le développement.

Créer son propre générateur

Bien qu’il existe tout un tas de générateur, il peut arriver le besoin d’en créer un soi-même. C’est le rôle du generator-generator, qui comme son nom l’indique, génère le squelette d’un générateur. Je vais faire un peu ma faignasse, mais je vais profiter de l’excellente présentation réalisée par Thierry Lau sur ce sujet :

http://lauterry.github.io/prez-yeoman-generator/

Pour résumer, si vous devez vous lancer dans un projet, plutôt que de perdre du temps, passez vite à yo !

C’est quoi donc ?

Le hackathon, à ne pas confondre avec le hackchaton (qui doit sans doute consister à coder avec des petits chatons) est un événement destiné à créer des applications sur un laps de temps assez court, généralement un week-end. Ainsi, pendant près de 48 heures, plusieurs dizaines d’équipes vont concourir pour créer la plus belle application. Le thème est d’”inventer la DSI de demain”. Quoi ce n’est pas clair ? Ok, pour être plus précis, il s’agit de créer des applications ou des services pour aider les développeurs de la SG. Bon, je vous rassure tout de suite, le code est et restera la propriété de leurs auteurs. L’idée n’est certainement pas de faire travailler des gens à l’oeil, mais plutôt de montrer que nous sommes des développeurs sympa et modernes à la SG !

Toutes les informations sur l’événement sont ici : http://hackathonsg.bemyapp.com/

Si vous venez à ce Hackathon, n’hésitez pas à me faire un petit coucou, j’y serais le vendredi soir, où je donnerais d’ailleurs une présentation sur les web components (il s’agit de celle de Devoxx France 2014, mais améliorée).

Devoxx France 2014

Habituellement, pendant et juste après un Devoxx, je pourri gentillement mon blog avec des billets expliquant en détail les sessions que j’ai suivi, ainsi qu’un billet récapitulatif. Cette année, je vais me contenter du billet récapitulatif, et avec un mois de retard en plus ! Tout se perd…

A vrai dire, tout cela a une raison bien précise : je n’ai vu presque aucune session, car la Société Générale était sponsor cette année, et ça m’a pris un temps fou ! Commençons tout d’abord justement par ces quelques sessions.

Conférences

Créons un web component avec Polymer

Forcément, en tant que co-présentateur (avec une fois de plus Julien Jakubowski), j’étais obligé d’y assister. Le titre n’était pas très vendeur, surtout que Julien a eu l’idée géniale d’utiliser l’API Marvel, mais seulement après le CFP. On aurait ainsi pu proposer le titre Créons un <super-héro> avec Google Polymer. Ca aurait été plus vendeur, mais d’un autre côté, notre salle était pleine ! Petit bémol, la salle était plutôt petite et notre session - pourtant un Tools In Action - n’a pas été filmé. J’ai l’impression que l’équipe des organisateurs a voulu optimiser les salles du sous-sol du Marriott pour avoir plus de TiA et ainsi contenter plus de monde, mais faisant l’impasse sur la vidéo pour certaines. Pas très grave, si vous l’avez manqué, je proposerais bientôt ce sujet sous forme d’un brown bag lunch…

Des SSII aux SS3I : Sociétés au service des individus de l’ingénierie informatique

Ma première vraie conférence est une conférence donnée par deux femmes, Aude Amarrurtu et Betty Moreau, qui sont RH de surcroit ! Le message qu’elles ont voulu faire passer, c’est qu’en France, une très grosse part du développement informatique est gérée par des SSII (enfin, ESN pour ”Entreprise de Service du Numérique”). Je n’ai plus les chiffres en tête, mais le nombre de SSII en France est très important (plus de 10000, allant de 1 employés à plusieurs dizaines de milliers) et leur part de marché tournait autour de 80%. Le tableau des SSII était assez noir, mais comme toujours, il y en a toujours quelques unes qui se démarquent du lot. Une session intéressante, mais qui, j’ai l’impression, donnait plutôt envie de devenir freelance au final…

Au secours, mon code AngularJS est pourri !

Thierry Chatel, formateur sur AngularJS, nous propose une session dédiée aux bonnes pratiques lorsque l’on développe une application avec AngularJS, ainsi que les différentes choses à éviter. J’ai été déçu pour deux raisons. Déjà, Thierry manquait un peu d’énergie comme présentateur, mais surtout cela s’est borné à une énumération de bonnes ou mauvaises pratiques. C’est bien, mais il manquait vraiment du concret, des exemples de code. Je crois avoir attendu 15 minutes avant de voir la première ligne de code Angular ! C’est dommage, le sujet était forcément très intéressant et aurait mérité mieux. En tout cas, ça m’a rassuré sur ma pratique d’Angular, qui n’est pas si pourri que ça :o)

Etendre le Web avec les Web Components

Sur le CFP, j’avais fait deux propositions concernant les web components. Un Tools In Action (retenu) et une conférence. Cette dernière n’a été retenue, sans doute parce que ce sujet a été proposé aussi par Christophe Jolif d’IBM. Il nous a donc expliqué le principe des web components, ce qui était intéressant. J’ai cependant trouvé que la présentation a beaucoup (trop ?) tourné autour de l’implémentation d’IBM des web components, Delite.

Extremist Programming : l’art de s’amuser avec du code

Une présentation décaléee faite par Eric Lefevre-Ardant et Cyrille Martraire, cela ne peut pas se manquer. Et clairement, ça a été mon gros coup de coeur sur cette édition 2014 de Devoxx France. Tout comme la conférence Boucles étranges : étranges boucles (puzzlers et curiosités) d’Eric lors de Devoxx France 2013, difficile de retranscrire ici le contenu de cette session, qui essayait de nous montrer comment l’art et le développement peuvent cohabiter. Tous les ingrédients d’une excellente présentation étaient présent : présentateurs plein d’énergie et parfaitement complémentaires, des informations intéressantes, de l’humour et des cookies (très bons d’ailleurs). Je recommande sur Parleys, même si la vidéo sera sans doute un peu moins bonne que le live…

Pourquoi vous devriez essayer sérieusement les Object Calisthenics

Un Quickie très intéressant par Guillaume Duquesnay qui nous parle de la programmation avec des objects calisthéniques. Mais qu’est-ce que c’est ? Hé bien ce n’est rien de plus que de la programmation en s’infligeant des contraintes fortes qui sont les suivantes :

• un seul niveau d’indentation par méthode (pour éviter les if imbriqués par exemple) ;
• pas de else ;
• encapsuler tous les types primitifs et String ;
• un seul point par ligne ;
• pas d’abréviation (pour les noms des variables) ;
• limiter la taille des entités (petites classes par ex.) ;
• pas plus de deux variables d’instance par classe ;
• utiliser des collections “first class” (pas sûr de trouver une bonne traduction pour ça), c’est-à-dire de ne pas utiliser par exemple des List<String> usernames mais plutôt une classe plus explicite, comme par exemple Usernames.
• pas de getter / setter / properties

Bon, malheureusement j’ai dû m’eclipser avant la fin de la session, je n’ai donc pas pu entendre ce que ce type de programmation a pu apporter à l’orateur dans sa façon de développer. Mais en tout cas, j’aimerais bien m’y frotter, plus par défi intellictuel qu’autre chose. Peut-être lors d’un coding dojo ?

Sponsoring SG

Grosse nouvelle, la Société Générale (plus exactement le département ITEC de la banque d’investissement) est devenue sponsor de la conférence. Une première, puisqu’habituellement ce sont plutôt des éditeurs ou des SSII qui sont présentes sur ce genre d’événements. Si je n’ai pas initié ce sponsoring (merci aux Alexandres, ils se reconnaitront), j’ai du gérer près de 80% de la préparation de notre sponsoring. Ceci explique aussi que je suis resté les 3/4 de mon temps à proximité du stand SG.

Notre présence dans ce milieu très geek a été plutôt bien vue, même si beaucoup en était étonné. Nous avons pu montrer que nous avons effectivement un esprit geek, et que la banque - du moins la notre ;o) - sait proposer des challenges intéressants et actuels : Big Data, Continuous Delivery, développement web et mobile, Software Craftsmanship, ainsi que d’activités attrayantes comme des Coding Dojo, des Brown Bag Lunches, etc.

Nous avions également un jeu très sympathique, le Trading Challenge (le site ne sera pas forcément disponible encore très longtemps). Le principe est de jouer en bourse (avec des données réelles, bien que légèrement décalées) avec un portefeuille virtuel. A la fin de la journée, quand la bourse ferme, les comptes sont calculés, et les trois meilleurs boursicoteurs repartaient avec de jolis cadeaux : Raspberry Pi, Amazon Kindle et caméra GoPro ! Seul bémol : le dernier jour de Devoxx était le vendredi saint, et donc les marchés étaient fermés. Donc pas de jeu. Dommage ! Autre intérêt non négligeable du jeu : c’est un développement interne, une application web responsive développée avec de l’AngularJS et proposant des dashboards Kibana. Bref, une belle vitrine technologique pour la SG ! Comme quoi on ne fait plus du Cobol :o)

Bilan général

Bien que je n’ai vu que très peu de conférences - j’ai même raté l’enregistrement des Cast Codeurs pour démonter note stand - j’ai encore apprécié cette édition de Devoxx France. L’ambiance, les rencontres, le partage est toujours le point fort de cette conférence,

Le rendez-vous est donc pris pour l’année prochaine, mais cette fois-ci au Palais des Congrès ! Le Marriott - et sa magnifique moquette - va sans doute nous manquer, mais la taille critique de 1500 développeurs était atteinte et il devenait urgent de viser plus haut. C’est donc chose faite !

Si vous souhaitez un compte-rendu bien plus complet, je vous invite à lire celui réalisé par l’équipe de Developpez.com, qui est l’oeuvre de Thierry Leriche-Dessirier et auquel j’ai participé, visible ici

Peut-être que vous n’avez pas eu la chance de venir y assister. Je vous propose donc une initiation à Google Polymer et aux web components.

Les web components, qu’est-ce ?

Un site internet, c’est un ensemble de pages écrites en HTML (dans la plupart des cas du moins). Aujourd’hui, ces sites sont de plus en plus riches, de plus en plus dynamiques. Les composants qui structurent une page web sont de fait plus complexes. Paradoxalement, le langage HTML est un langage assez pauvre, puisqu’il ne dispose que d’un peu plus d’une centaine de “mots”, les balises. Résultat, il faut généralement bidouiller pour créer un vrai composant. Ainsi, avec Twitter Bootstrap, la création d’un panneau d’onglets va nécessiter d’utiliser les balises de liste (<ul> et <li>) comme cela :

1
2
3
4
5
6

<ul class="nav nav-tabs">
  <li class="active"><a href="#home" data-toggle="tab">Home</a></li>
  <li><a href="#profile" data-toggle="tab">Profile</a></li>
  <li><a href="#messages" data-toggle="tab">Messages</a></li>
  <li><a href="#settings" data-toggle="tab">Settings</a></li>
</ul>

Ce n’est pas trop moche, mais cela reste moins lisible que quelque chose de ce genre :

1
2
3
4
5
6

<tabs-pane>
  <tab title="Home" active="true">...</tab>
  <tab title="Profile">...</tab>
  <tab title="Messages">...</tab>
  <tab title="Settings">...</tab>
</tabs-pane>

Or la lisibilité est un critère très important quand on sait que l’on doit passer 80% du temps à lire du code et 20% à en écrire.

Dans le même genre, est-ce qu’il ne serait pas plus pratique d’écrire ceci pour embarquer un tweet dans une page :

1

<tweet tweetId="123456789"></tweet>

Hé bien c’est le but des web components que de proposer de créer ses propres balises HTML et de pouvoir les exporter facilement.

Le standard web component

Finalement, créer ses propres tags HTML n’est pas quelque chose de nouveau, on peut le faire grâce à différents frameworks - comme par exemple avec une directive AngularJS - voire même en pur JavaScript. Mais les web components sont en réalité un standard en cours d’élaboration par le W3C, et c’est là sa force première. Pour être plus précis, il s’agit d’un ensemble de standards, comprennant les briques nécessaires à l’élaboration d’un composant web. Je pense par exemple au shadow DOM ou encore au HTML template.

Ces standards sont toujours à l’étude, mais il existe quelques implémentations pour pouvoir jouer dès à présent avec les web components. Celui qui va nous intéresser plus particulièrement c’est celle de Google, à savoir Polymer.

Let’s start!

Assez parlé, codons ! Je vous propose de coder une balise progress-bar, basée sur celle proposée par Twitter Bootstrap. Le code HTML est le suivant :

1
2
3
4
5

<div class="progress progress-striped">
  <div class="progress-bar progress-bar-info" role="progressbar" aria-valuenow="20" aria-valuemin="0" aria-valuemax="100" style="width: 20%">
    <span class="sr-only">20% Complete</span>
  </div>
</div>

Commençons par créer une application web toute simple. On va donc s’appuyer sur yo, qui permet grâce à un générateur spécifique de nous créer une application blanche, préconfigurée pour un contexte particulier. On exécute ainsi la commande yo webapp. Une fois la structure générée, un petit npm install puis bower install nous permettent d’être prêt à coder. Pour nos besoins, j’ai un peu épuré le projet, en supprimant quelques éléments inutiles et en enlevant jQuery, qui n’est pas toujours utile.

Grâce à sa pré-configuration grâce à yo, nous disposons d’une tâche Grunt (une sorte de Apache Ant, mais pour JavaScript) serve, qui va nous permettre de modifier notre code et de voir automatiquement le navigateur se recharger pour prendre ces modifications en compte. Il nous suffit donc d’exécuter grunt serve, et c’est tout ! Notre page sera dès lors visible à l’adresse http://localhost:9000.

Première étape, il nous faut ajouter la librairie Polymer à notre projet. On va donc utiliser bower pour gérer notre dépendance, on exécute donc la commande bower install polymer --save (l’option --save permet d’ajouter la dépendance dans le fichier bower.json). Nous disposons maintenant de Polymer dans le répertoire bower_components, mais aussi de platform. Comme je l’ai expliqué, les web components se basent sur un ensemble de briques qui ne sont aujourd’hui pas toutes supportées nativement par les navigateurs. Il faut donc les émuler, via des “polyfills”. Et c’est précisément le rôle de platform.

Voilà notre HTML de base pour bien démarrer :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<!doctype html>
<html>
    <head>
        <meta charset="utf-8">
        <title>Polymer</title>
        <meta name="viewport" content="width=device-width">
        <link rel="stylesheet" href="../bower_components/bootstrap/dist/css/bootstrap.css">
        <!-- Nos dépendances pour utiliser Polymer -->
        <script src="../bower_components/platform/platform.js"></script>
        <script src="../bower_components/polymer/polymer.js"></script>
    </head>
    <body>
        <div class="container">
            <div class="header">
                <h3 class="text-muted">Google Polymer</h3>
            </div>
            <div class="footer">
                <p><span class="glyphicon glyphicon-heart"></span> Polymer</p>
            </div>
        </div>
  </body>
</html>

Commençons par créer un élément Polymer pour le composant progress-bar. A noter qu’un composant Polymer doit être composé de deux mots séparés par un - (sans doute pour éviter la confusion avec les “vrais” tags HTML) :

1
2
3
4
5
6
7
8
9

<polymer-element name="progress-bar">
    <template>
    </template>
    <script>
        var module = (function() {
        })();
        Polymer('progress-bar', module);
    </script>
</polymer-element>

On voit trois choses intéressantes :

• le tag polymer-element qui prend le nom du composant (progress-bar) ;
• le tag <template> qui va nous permettre d’ajouter le code HTML ;
• la partie script qui nous permet d’initialiser un objet module qui correspond à notre composant Polymer, ainsi que la ligne Polymer('progress-bar', module); qui permet de l’enregistrer pour l’utiliser par la suite.

On injecte alors le code HTML de la barre de progression dans le <template>, comme suit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<polymer-element name="progress-bar">
    <template>
        <div class="progress progress-striped">
            <div class="progress-bar progress-bar-info" role="progressbar" aria-valuenow="20" aria-valuemin="0" aria-valuemax="100" style="width: 20%">
                <span class="sr-only">20% Complete</span>
            </div>
        </div>
    </template>
    <script>
        var module = (function() {
        })();
        Polymer('progress-bar', module);
    </script>
</polymer-element>

C’est bien, mais il faudrait pouvoir définir le pourcentage de progression dynamiquement, dont acte :

1
2
3
4
5
6
7
8
9
10

<polymer-element name="progress-bar" attributes="percentage">
    <template>
        <div class="progress progress-striped">
            <div class="progress-bar progress-bar-info" role="progressbar" aria-valuenow="" aria-valuemin="0" aria-valuemax="100" style="width: %">
                <span class="sr-only">% Complete</span>
            </div>
        </div>
    </template>
</polymer-element>
<progress-bar percentage="42"></progress-bar>

On voit plusieurs choses :

• il faut définir les attributs passés au composant via l’attribut attributes="percentage" ;
• dans le code HTML, on peut accéder à cette information via la syntaxe “double moustaches”, “. Les habitués d’Angular ne seront pas perdus !

Changeons un peu notre composant pour donner un min, un max et une value, en laissant à la charge du composant de calculer lui-même le pourcentage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<polymer-element name="progress-bar" attributes="min,max,value">
    <template>
        <div class="progress progress-striped">
            <div class="progress-bar progress-bar-info" role="progressbar" aria-valuenow="" aria-valuemin="" aria-valuemax="" style="width: %">
                <span class="sr-only">% Complete</span>
            </div>
        </div>
    </template>
    <script>
        var module = (function() {
            return {
                get percentage() {
                    return ((this.value - this.min) / (this.max - this.min)) * 100;
                }
            }
        })();
        Polymer('progress-bar', module);
    </script>
</polymer-element>
<!-- Utilisation dans ma page du web component "progress-bar" -->
<progress-bar min="0" max="20" value="12"></progress-bar>

On voit ici aussi que les paramètres, min, max ou value sont disponibles également dans la partie <script>.

Et si on souhaite change la valeur courante ? Un web component peut être accédé de la même façon que n’importe quel autre élément du DOM, donc un simple bout de JavaScript suffit :

1
2
3
4
5
6
7

<button class="btn btn-primary" onclick="changeValue()">Change value</button>
<script>
    function changeValue() {
        var bar = document.querySelector('#progression'); // On récupère l'objet
        bar.value = +bar.min + (Math.random() * (bar.max - bar.min));
    }
</script>

Il serait sans doute plus propre de proposer des fonctions, comme par exemple updateValue:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<polymer-element name="progress-bar" attributes="min,max,value">
    ...
    <script>
        var module = (function() {
            return {
                get percentage() {
                    return ((this.value - this.min) / (this.max - this.min)) * 100;
                },
                updateValue: function(val) {
                    this.value = val;
                }
            }
        })();
        Polymer('progress-bar', module);
    </script>
</polymer-element>

pour pouvoir l’appeler ensuite :

1
2
3
4

function changeValue() {
    var bar = document.querySelector('#progression');
    bar.updateValue(+bar.min + (Math.random() * (bar.max - bar.min)));
}

Externalisation

C’est bien beau tout ça, mais comment je fournis ce web component tout beau à une autre équipe ? C’est simple. Je déplace tout le code du <polymer-element> dans un fichier séparé, par exemple progress-bar.html, puis je l’importe grâce à cette petite ligne dans mon entête de page :

1

<link rel="import" href="progress-bar.html">

Le reste de ma page initiale ne change pas, je peux du coup utiliser mon <progress-bar id="progression" min="0" max="20" value="12"></progress-bar> sans problème. A la limite, je pourrais même sortir le lien vers la librairie polymer et le mettre directement dans mon fichier HTML :

progress-bar.html :

1
2
3
4

<script src="../bower_components/polymer/polymer.js"></script>
<polymer-element name="progress-bar" attributes="min,max,value">
    ...
</polymer-element>

et dans ma page index.html :

1
2
3
4
5
6
7
8
9
10
11

<html>
    <head>
        ...
        <script src="../bower_components/platform/platform.js"></script>
        <link rel="import" href="progress-bar.html">
    </head>
    <body>
      ...
        <progress-bar id="progression" min="10" max="20" value="12"></progress-bar>
    </body>
</html>

Il est (pour l’instant) encore nécessaire d’avoir un lien vers la librairie platform dans la page principale car le import est lui-même un standard en cours de travail du W3C et n’est donc pas supporté nativement par les navigateurs. Il faut donc avoir recours au polyfill de platform pour l’instant.

Voilà un premier voyage dans le monde des web components avec Polymer. D’autres billets viendront peut-être le compléter…

Un peu d’histoire

Tout a commencé en novembre 2012, lorsque David Gageot proposa sur son blog de venir faire des ”BBL” au sein des entreprises. Les BBL, ce sont des Brown Bag Lunches, autrement dit des présentations faites par un intervenant (généralement) externe, durant la pause déjeuner. J’en avais parlé ici il y a un an environ.

Je n’ai donc pas attendu pour l’inviter à la SGCIB faire sa fameuse présentation “Du Legacy au Cloud en moins d’une heure”. Pour être tout à fait précis, c’est un autre David, Pilato cette fois-ci, qui sera le premier invité officiel des BBL à la SGCIB, le 9 janvier 2013 pour être exact. Le sujet ElasticSearch aura donc eu l’honneur d’initier une longue série…

Depuis, en une année, nous avons eu environ une vingtaine d’interventions, dont voici quelques exemples :

• Eric Lefevre-Ardant et Guillaume Tardif pour Boucles étranges, étranges boucles.
• Tugdual Grall pour Couchbase.
• Stéphane Landelle pour Gatling.
• François Sarradin pour la création d’un serveur web en Scala.
• Nicolas Martignole sur les bons conseils pour réussir une présentation technique.
• Mathilde Lemée sur Bitman et l’utilisation avancée des caches.
• Romain Maton pour une introduction à Node.js et 24 plugins chrono.
• Frédéric Menou pour devenir un Git Jedi.
• Julien Biezemans sur Cucumber.js.
• Etc.

Ce que ça nous apporte

La SGCIB est une (très) grosse société. Il y a également beaucoup de développeurs, le public est donc tout trouvé. En moyenne, on tourne à environ 20 - 25 personnes dans l’assistance, le record est tout de même de 45 personnes ! Beau succès.

En tant qu’organisateur des BBL@SGCIB, je suis satisfait de voir que le retour est très positif, et à chaque session, de nouvelles personnes souhaitent s’inscrire. Pourquoi viennent-ils ? C’est un fait, le participant aux BBL est plus intelligent, plus réactif et a le poil plus soyeux. Il se dit même qu’ils ont 23% de chances de plus de gagner au Loto ! Plus sérieusement, les BBL sont un formidable lieu d’échange, mais aussi d’ouverture. C’est l’occasion rêvée de découvrir de nouveaux langages, de nouveaux frameworks, de nouvelles pratiques.

Pour celui ou celle qui présente, c’est l’occasion de faire partager sa passion, parfois aussi de faire connaître son travail (nombreux sont ceux qui présentent un outil dont ils sont committeurs officiels). Au final, c’est du gagnant - gagnant.

Et maintenant ?

Si les BBL se sont démocratisés grâce à l’informatique, cela ne doit pas empêcher d’autres thématiques d’en profiter. Et la bonne nouvelle, c’est que la sauce commence à prendre dans le domaine des Ressources Humaines. Le site rh.brownbaglunch.fr a vu le jour en fin d’année 2013, et nous devrions atteindre la dizaine de présentateurs bientôt. Bravo et bon courage à eux !

Personnellement, j’aimerais beaucoup voir des BBL scientifiques à la SGCIB. Qui sait…

Icone par IconDrawer

Thierry Leriche Dessirier m’a proposé gentillement de m’interviewer pour promouvoir l’édition 2014 de la conférence Devoxx. J’y parle de Devoxx, bien sûr, du site Developpez.com, mais aussi de mon expérience en tant que conférencier.

Retrouvez mon interview ici. Et rendez-vous à Devoxx France en 2014.

La dernière journée à Devoxx est toujours un peu spéciale. Beaucoup moins de monde, moins de sessions aussi, on sent que la fin est là ! Pour cette dernière journée, comme habituellement pour chaque Devoxx (France ou Belgique), je termine par l’enregistrement du podcast des CastCodeurs.

J’ai commencé la journée avec Batch applications for the Java platform (JSR 352), mais entre la fatigue des deux derniers jours et les slides bien trop chargés, j’ai eu du mal à suivre. Donc si vous voulez en savoir plus, je vous invite à regarder la JSR 352 :)

Enregistrement live des CastCodeurs

Ma seule et unique session en français (la seule de la conférence d’ailleurs) : l’enregistrement live du Podcast des CastCodeurs. Une analyse toujours fine et délicate de la conférence qui est en train de s’achever. Je vous laisserais écouter cet épisode qui sera bientôt disponible sur le site. D’ailleurs, bientôt la 100e. Ce sera d’ailleurs peut-être pour Devoxx Anvers 2014, qui sait.

Avatar.js, Server-Side JavaScript on the Java Platform

Finissons ce Devoxx par la présentation de Jean-François Denise sur Avatar.js.

Il s’agit d’un framework JavaScript côté serveur qui tourne sur la JVM et est une combinaison de :

• d’une inspiration de Node pour son modèle orienté événement, son système de modules et de son API.
• utilisation du moteur JavaScript de Nashorn.
• l’API de de la plateforme Java.

Le but n’est pas de copier Node, mais plutôt d’en créer une compatible avec lui. Prendre le meilleure des deux mondes en quelque sorte. La syntaxe s’approche de celle de Node, comme par exemple :

1
2
3
4
5
6
7
8

var fs = require('fs')
fs.readdir('/Documents/images', function(err, files) {
  files.map(function(imgFile) {
      var file = new java.util.File(imgFile);
      var img = javax.imageio.ImageIO.read(file);
      ...
  })
})

Démarrer un serveur peut se faire directement en ligne de commandes, ou encore via quelques lignes de code :

1
2
3

String[] args = { "./myscript.js" };
Server server = new Server(args);
server.run(args);

Avatar.js vient aussi avec Avatar EE. Et là, je commence à me poser des questions. Il faut noter qu’Avatar.js n’est pas encore finalisé, et son API peut également être amenée à changer…

Jean-Baptiste passe ensuite à une démo d’application d’upload de photos en Avatar.js, avec l’aide d’Express, des WebSocket, de java.sql et de javax.imageio. Ah non, en fait de démo, il s’agit de slides qui montrent du code. Argh

J’avoue ne pas être vraiment emballé par ce projet, bien qu’avoir une passerelle entre Node.js et Java peut être intéressant. De plus ne pas voir une vraie démo m’a quand même déçu !

Bilan

Pour ma deuxième année à Anvers, la magie est toujours là. Cela reste l’une des meilleures conférences du monde sur le domaine du Java, avec des stars et des présentations de qualité. Je dirais quand même que j’ai préféré Devoxx 2012 à la version 2013, mais cela est peut-être aussi lié au fait que l’année dernière, il y avait en plus l’excitation de découvrir cette conférence pour de vrai.

Bref, je reviendrais à Anvers en 2014 si j’en ai la possibilité, et ce sera peut-être pour faire une conférence, qui sait.

Donc les aspects positifs :

• La qualité des présentations et des orateurs.
• Une organisation au poil, et c’est du sacré boulot !
• Les gens, les amis que l’on revoit ou que l’on se fait. Les rencontres donc.
• Les stands, il y en a pas mal, ils sont plutôt bien achalandés, et certains offrent des goodies sympas.
• A boire. On peut toujours boire, c’est toujours bien fourni, et parfois de la bière est offerte par un stand ou Atlassian.
• Le bracelet, toujours aussi pratique.
• Le système de vote à la sortie des salles (comme en 2012).
• Le film du jeudi soir (avec les popcorns), même si je ne l’ai pas tellement apprécié (”Le Cartel” ou ”The Counselor” en VO), je trouve que c’est quand même top comme idée.
• Le site Parleys qui héberge(ra) les sessions, toutes filmées (sauf, hélas, les Quickies et donc le mien)

Les moins, ou les points d’amélioration :

• La nourriture. Je ne me souviens pas d’avoir super bien mangé à Devoxx 2012, mais j’ai vraiment l’impression que cette année c’était pire. Le mercredi midi c’était juste un sandwich, rien de folichon. Le lendemain, c’était une salade assez étrange (en gros, un sacré mélange), ce qui m’a fait finir au Quick. En dehors de ça, point de salut. Quelques gâteaux ont été jetés en pature à la foule affamée vers 16h, mais franchement, il y a un très gros axe d’amélioration sur ce point-là !
• Le système de vote qui mériterait d’être mieux utilisé. En gros, il ne sert qu’à faire un “Top 3” des meilleures sessions du jour ou de la conférence entière. Il serait bien de fournir le score au speaker à la fin de la conférence, pour avoir une évaluation directe du ressenti des spectateurs.
• Contrairement à l’année passée où j’avais eu la “révélation Angular”, cette année pas de ”Kick-ass” présentations. Mais le niveau reste élevé, ne me faites pas dire ce que je ne dis pas :)

Vivement 2014 :)

Voici la deuxième journée à Devoxx version 2013. Pour commencer la journée, la Keynote de Google annonce la sortie de la version 1.0 du langage Dart. Dart est le langage créé par Google au dessus de JavaScript afin de rendre ce dernier plus utilisable, en offrant pas mal de choses des langages Java ou C# comme les classes, un vrai développement orienté objet, etc.

Il a aussi été question du projet Angular Dart, une implémentation d’Angular sur le language Dart.

Go see all the ships in the world

On parle beaucoup du Big Data. C’est souvent théorique, ou à des exemples qui ne semblent pas très parlants. Francesc Campoy Flores nous propose une session où nous devrions avoir au final une visualisation dynamique de la position et trajectoires de tous les bateaux du monde ! Cela s’annonce intéressant d’un point de vue technique, et quelque peu exotique quant au contenu.

Parlons tout d’abord des données. Nous avons 75,000 bateaux (en éliminant les petits bateaux). Il faut donc d’abord récupérer ces données. Les bateaux disposent d’un système appelé AIS (Automatic Identification System), une sorte de GPS avant l’heure pour les navires. Toutefois, ce type de protocole est peu fiable, et difficile à gérer.

Il faut donc stocker toutes ces données. Bien entendu, il fait appel au cloud de Google pour cela. Le problème qui se pose aussi est la tête des données AIS, qui ne ressemble à pas grand chose :

Il existe toutefois une librairie en C++ qui permet d’interpréter ces données. Le seul hic, c’est que le cloud de Google ne permet pas d’exécuter du C++. Il faut donc écrire un traducteur vers du CSV pour finalement restocker ces informations dans ce format plus pratique.

BigQuery est ensuite utilisé pour extraire les informations de toutes ces données. Une requête assez basique pour récupérer les positions moyennes des bateaux prend 5.8s sur 14Go de données.

Il faut maintenant servir ces données, de façon rapide et dynamique. Pour cela, Fransesc utilise l’API REST de BigQuery depuis du JavaScript. Toutefois, il inclut une application herbergée sur AppEngine entre le browser et le serveur BigQuery. En effet, on risque sinon de trop faire jouer le cache de ce dernier et du coup ne pas avoir les dernières données disponibles. Cette application va matérialiser les requêtes, ainsi qu’une gestion du cache (memcache). Cette application est développée avec le langage Go, pour ses performances.

Voilà l’architecture finale du système. Pas si simple !

Et le résultat, basée sur Google Maps API, WebGL et CanvasLayer montre tout d’abord une floppée de points sur une carte (75,000 quand même). Puis, en utilisant les données disponibles, ces points sont colorés en fonctin de leur vitesse. Ce calcul est fait par le GPU. On laisse le CPU - peu utilisé autrement - calculer l’histogramme donnant la répartition des vitesses :

Une coloration en fonction de l’orientation du bateau montre très bien les différents canaux de navigation, comme par exemple autour de l’Espagne.

Et au final :

Une présentation tout à fait intéressante pour comprendre la démarche du traitement de ces données. Seul bémol, je m’attendais à un peu de live coding ou tout du moins une démo du résultat (plutôt qu’une vidéo). Mais il est vrai que le nombre de données assez important ainsi qu’un WIFI un peu à la ramasse aurait risqué de casser un peu l’expérience.

What is in store for the future of Angular

AngularJS avait été ma claque et ma découverte de Devoxx 2012. Depuis, le framework est devenu très populaire, et plusieurs sessions ont déjà eu lieu à Devoxx 2013, toutes blindées. Igor Minar et Misko Hevery, deux des principaux membres du projet, viennent nous parler de ce qui attend Angular pour l’année 2014.

La première chose de prévue pour Angular, c’est de se baser encore plus sur les standards, en particulier les web components, qui inclut :

• Shadow DOM
• Custom elements, document.register()
• Templates
• Scoped CSS

Autre point, c’est l’utilisation du Object.observe qui permettra de meilleures performances que le dirty checking d’Angular. L’autre avantage de cette méthode est qu’elle est asynchrone.

Asynchrone DI (Dependency Injection) vs AMD (Asynchronous Module Definition).

L’introduction des zones va permettre de supprimer $apply et $digest.

• DefaultZone se comporte comme le navigateur.
• StackTraceZone permet des stacktraces plus longues.
• AngularZone applique le data-binding.
• MockZone pour faciliter les tests.

Angular va également profiter des nouveautés d’EcmaScript 6, en particulier les classes et les modules. Il sera également possible d’utiliser des annotations dans le code Angular.

Les contrats font également leur apparition dans Angular :

Bref, je laisse les présentateurs résumer à ma place :

La présentation était moins éclatante que l’année passée, mais forcément le sujet s’y prétait moins. Toutefois, cela montre qu’Angular a encore de beaux jours devant lui !

The ingredients for a perfect JavaScript Software Factory

(vous vous doutez bien que la note est ici tout à fait objective) Là, c’est mon Quickie ! J’y parle de JavaScript et d’usine logicielle, en particulier d’outils. Ma présentation est essentiellement divisée en trois parties. Compte tenu du temps imparti - à peine 15 minutes - il ne m’est pas possible d’aller pleinement dans les détails, mais l’idée est d’aborder les points principaux du sujet:

• Tout d’abord, j’insiste sur le fait qu’il faut réutiliser ce que l’on a déjà sous la main, selon le bon vieux principe du Don’t Repeat Yourself (DRY). En effet, nous sommes généralement des développeurs Java, et disposons à ce titre d’une usine logicielle déjà performante. Réutilisons donc Jenkins, SonarQube, et consorts !
• Ensuite, intéressons nous aux outils propres à JavaScript. Là, je m’arrêtre surtout sur Yeoman, c’est-à-dire Yo pour créer des squelettes d’applications, Bower pour gérer les dépendances et le packaging et enfin Grunt, un exécuteur de tâches (une sorte de Ant pour JavaScript, pour faire simple).
• La dernière partie insiste sur le fait qu’une bonne usine logicielle n’est pas qu’une questions d’outils, mais aussi de bonnes pratiques. Et en terme de bonnes pratiques, les tests sont en première place. Je montre donc qu’il existe toutes sortes de librairies de tests en JavaScript, pour faire du test unitaire, du test fonctionnel, du BDD ou encore du test front-end.

Enregistrement live de JavaPosse

Le podcast de JavaPosse est très connu et réputé. Comme chaque année, ils font un enregistrement live à Devoxx, à la manière des CastCodeurs.

Cette année, seule la moitié de l’équipe était présente, à savoir Chet Haase et Dick Wall. Du coup, la moitié des Cast Codeurs, avec Guillaume Laforge et Emmanuel Bernard est venue en renfort.

Une session agréable, avec une session avec de la bière offerte par Atlassian. Une fois de plus, merci à eux.

Continuous Delivery antipatterns

A la SGCIB, nous sommes en plein dans le Continuous Delivery. Il me paraissait donc important de recueillir quelques nouveaux avis et de bons conseils. C’est dans ce but que j’assiste à la conférence de Andrzej Grzesik.

Le problème est avant tout un problème de personnes, de process. Il faut des dashboards, pour savoir qui (a) fait quoi. Releases = risques. Il faut donc savoir les éviter (les risques, pas les releases !)

Paralléliser les releases. Mais quoi paralléliser ? A priori, tout est parallélisable. Le mieux est de voir ce qui est le plus pénible, le plus long à s’exécuter dans une release, et voir comment on peut le paralléliser.

Autre problème fréquent : des équipes indépendantes, qui ne se parlent pas (devs contre ops par exemple). Il faut restaurer un canal de discussion, de communication.

L’infrastructure manuelle. Il faut tester aussi son infrastructure. Avec Chef par exemple, il est possible de faire une sorte de TDD. Food critic ou Vagrant peuvent également être utiles.

Practical RESTful persistence

Finalement, on change de sujet, pour aller voir Shaun Smith parler de la nouvelle fonctionnalité d’EclipseLink de JPA-RS, qui intgère JAX-RS, JAXB et JPA. L’idée est ici de réaliser un binding entre des entités et du JSON entre autres via des annotations dans les entités.

Bon, j’avoue être passé à côté de cette session, je n’ai pas trop compris le pourquoi de tout ça.

Voilà, la deuxième journée s’achève avec encore de belles expériences (sauf gastronomiques !). Demain sera plus calme, avec seulement une demi-journée de travail.

Et voilà, ma deuxième expérience belge de Devoxx est entamée.

How To Do Kick-Ass Software Development

J’ai choisi cette présentation de Sven Peters d’Atlassian, car j’avais beaucoup apprécié sa présentation l’année passée sur 7 things to make a good team great. Il y présentait 7 trucs pour rendre une bonne équipe encore meilleure. C’est d’ailleurs lors de cette présentation qu’il m’est venue l’idée de mettre les Brown Bag Lunch à la SGCIB (via l’idée ”Feed you brain”), peu de temps avant que ce mouvement ne prenne de l’ampleur en France.

Sven s’est intéressé au film Kick-Ass, où une personne quelconque souhaite devenir un super-héros, juste en portant un costume. Forcément, au début il se fait dérouiller, mais persiste. Et c’est le message de Sven : se prendre des gamèles, mais toujours se relever.

Mais que souhaite t-on atteindre avec son équipe ?

• un meilleur software ;
• moins d’overhead ;
• un développement plus rapide ;
• des clients heureux ;
• des développeurs heureux.

Il y a quelques temps, la solution à tous les problèmes était l’agilité. Mais qu’en est-il en 2013 ? Le problème de toute méthodologie ou technologie c’est qu’au début c’est super, mais très vite les soucis commencent à surgir, jusqu’à s’apercevoir que cette solution ne résoud pas tous les problèmes (voir la Gartner Hype Curve).

Il faut toujours garder à l’esprit de construire la bonne chose (”Building the right thing”). Une idée est le ”Fake it til you make it”. Sven nous montre l’exemple à ne pas suivre avec le téléphone Kin de Microsoft. Censé être très adapté à la nouvelle génération, il fut un échec très retentissant, sorti de la vente à peine au bout de deux semaines, et aura fait perder plus d’un milliard de dollars à la firme !

A l’opposé, IBM a voulu tester une application de reconnaissance vocale. Plutôt que de développer un système complexe, ils ont triché en mettant une personne réelle dont le rôle était d’exécuter les tâches dictées par un cobaye. L’expérimentation n’ayant pas convaincue, il fut décidé que l’application réelle ne serait pas développée.

Passons à l’importance du feedback. Celui-ci doit répondre à trois critères :

• facile à trouver ;
• simple ;
• rapide à soumettre.

Il ne faut pas embêter directement les développeurs avec les feedbacks. Par exemple, pour l’équipe GMail, il y a 100 développeurs pour 425M utilisateurs. Imaginer que ce soit les développeurs qui traitent directement les feedbacks des utilisateurs. Le développement de l’application n’avancerait jamais. Cependant, tous doivent être conscients de ce qui ne va pas.

Chaque jour, l’équipe d’Atlassian se réunit 45 minutes pour revoir ces feedbacks et en faire quelque chose de personnel. De plus, chaque développeur passe une semaine par an au support de premier niveau, pour être en contact directement avec les problèmes des utilisateurs.

Autre point, ce qu’ils appellent le Developer on Test. Il s’agit de faire remplir le rôle de testeur aux développeurs. Pour cela, six astuces :

• Le training. Comment penser comme un testeur ?
• Faire du pairing entre un testeur et un développeur.
• Blitz Test : durant une journée, toute la compagnie - et pas seulement les développeurs et les testeurs - teste une nouvelle vesion.
• Définir des recettes de tests.
• Instaurere des sessions séparées : pendant une heure, deux équipes testent les mêmes choses, puis comparent leurs résultats.
• La chasse aux bugs : pendant une semaine, un développeur est dédié à la chasse aux bugs sur tous les éléments marqués comme Terminés.

Sven nous rappelle alors que “La qualité est la responsabilité de chacun”.

Sven passe ensuite sur le design. A Atlassian, les développeurs font aussi du design. Ils n’étaient pas forcément mauvais, mais cela avait tendance à partir dans tous les sens. Ce dont ils ont besoin, c’est de lignes directrices, de design guidances (les guidlines de design d’Atlassian).

Ils organisent également des workshops pour les développeurs.

Comme un développement complet requiert la collaboration de plusieurs départements, il est important de supprimer les frictions qui peuvent apparaitre entre eux.

Atlassian définit également des guidelines pour le développement. Ainsi, pour chaque tâche une branche est créée sur Git. Leur durée de vie est ainsi très courte (environ 2 jours). Puis, pour merger le code, ils passent par des push requests, ce qui fait que le nouveau code est revu et validé par ses pairs. Ce nouveau code n’est donc plus de la responsabilité d’un seul développeur.

Dernier point : l’automatisation. Le principe est d’échouer rapidement (Fail fast). 4 choses à retenir :

• Mettre à disposition les artifacts générés.
• Paralleliser les tests pour les accélérer.
• Avoir une stratégie de builds. Créer des couches de tests selon leur catégorie, leur intérêt.
• Toujours avoir un oeil sur les statistiques. Savoir par exemple ce qui prend du temps sur un build, pour être en mesure de l’accélérer.

Encore une belle présentation de Sven Peters.

Patterns, Shmatterns

Pourquoi cette présentation ? Tout simplement pour son orateur, Chet Haase. L’année passée, il avait aussi présenté un Quickie (The Future of Software Development Process Methodology Effectiveness) qui avait été un beau succès.

Encore une fois, la salle était comble. Chet Haase a cette fois-ci passé en revue un certain nombre de patterns et les a comparé avec ses propres patterns, ce qui en faisait quelque chose d’assez drôle.

Don’t use Git

A nouveau, Sven Peters sur la scène. Le titre de la conférence peut paraître provocateur, tant Git est utilisé partout (Atlassian a même Stash dans son catalogue, un gestionnaire de repositories Git). Mais cela est en fait une façon de promouvoir ce système de gestion de sources.

Sous le ton de l’ironie, Sven essaie de démonter les arguments qui font de Git un vrai succès. Git permet de travailler en mode déconnecté ? Mais c’est la fin du travail collaboratif ! Git rend les merges faciles et presque automatiques ? Mais le travail de merge sur SVN est une ôde à la cohésion d’équipe…

Bien entendu, tout cela n’est que prétexte pour montrer en quoi Git est supérieur aux anciens gestionnaires de sources comme SVN.

Efficient coding in IntelliJ IDEA

Nikolay Chashnikov est aux commandes pour nous montrer comment bien maitriser son IDE IntelliJ IDEA de JetBrains. Après pas mal d’essais ratés, je suis finalement passé définitivement sur cet IDE depuis un an, et clairement, je ne reviendrais pas en arrière. Mais je suis conscient de n’utiliser qu’une toute petite partie des capacités de l’outil. J’attends donc de cette session qu’elle me donne plein de bons conseils.

Hélas, je resterais sur ma faim. Une bonne première partie de la session montre surtout les capacités d’autocomplétion proposées par IntelliJ. Le reste est avant tout la découverte (ou non) d’un certain nombre de raccourcis claviers. Bref, pas grand chose à se mettre sous la dent, si ce n’est 2 ou 3 nouveaux raccourcis. C’est chez payé pour une conférence d’une heure !

Je pense que cette session peut être intéressante pour une personne utilisant Eclipse et souhaitant comprendre pourquoi IntelliJ est si puissant. Mais pour un utilisateur d’IntelliJ, même un non expert comme moi, peu d’informations à en tirer. Dommage.

Elastify your app: from SQL to NoSQL in less than one hour!

J’avais déjà assisté à cette présentation lors de Devoxx France 2013, toujours faite par Tugdual Grall et David Pilato. Je me suis dit que j’allais quand même y jeter un oeil pour mieux l’apprécier.

N’hésitez pas à relire mon résumé lors de Devoxx France 2013.

The Curious Case of JavaScript on the JVM

J’aime Java, j’aime le JavaScript. Je me dis qu’une session mélangeant les deux pourrait être intéressante. Je me décide donc d’aller voir ce qu’en dit Attila Szegedi. Il y était question de Nashorn, qui est l’implémentation d’un runtime JavaScript hautes performances sur la JVM.

En gros, on écrit du JavaScript mélangé à du Java - à moins que ce ne soit l’inverse ? A noter que Nashorn devrait être normalement inclus dans le JDK 1.8.

J’ai un peu de mal à voir l’intérêt de ce mélange, mais pourquoi pas. C’est aussi ce genre de chose qui fait la richesse de la plateforme de la JVM :)

Voilà une première journée déjà bien intéressante, j’attends avec impatience la deuxième fournée de conférences, qui s’annonce de belle qualité.

Et c’est parti mon Kiki !

LA conférence de l’année a débuté ce lundi 11 novembre, je veux bien sûr parler de Devoxx ! Pour la 4e fois d’affilée, et la 2e en ce qui concerne la version “World” en Belgique, j’y serais à partir de demain mercredi.

Mon programme n’est bien sûr pas encore défini, mais j’ai noté quelques sessions qui m’intéressent déjà.

• Je commencerais sans doute par How To Do Kick-Ass Software Development de Sven Peters. J’avais assisté à sa conférence l’année passée 7 things: How to make good teams great que j’avais beaucoup apprécié. Je ne sais pas s’il y aura beaucoup de nouveautés, mais je pense que ça vaut quand même le coup d’oeil. Il y a également UI Engineer - the missing profession par Dierk König, qui pourra être ma session de backup.
• Pour entamer les Quickies, j’opterais pour Patterns, Shmatterns, une présentation par Chet Haase qui devrait être du même niveau que sa présentation The Future of Software Development Process Methodology Effectiveness faite l’année dernière : complètement décalée et très drôle.
• Pour le Quickie suivant, ce sera peut-être encore Sven Peters avec Don’t use Git ou HTTP caching in practice.
• Pour la digestion, je me laisserais bien tenté par un Efficient coding in IntelliJ IDEA par Nikolay Chashnikov, parce qu’on ne connait pas assez son IDE. Au cas où, il y a bien une session avec un robot avec The Crazyflie Nano Quadcopter development platform par Tobias Antonsson.
• Puis, un petit Elastify your app: from SQL to NoSQL in less than one hour! par mes amis Tugdual Grall et David Pilato, qui montrent qu’il est possible d’intégrer facilement du NoSQL dans une application Legacy. Je me dis d’ailleurs qu’avec leurs bons conseils et ceux de David Gageot, on pourrait faire passer une application Legacy dans le cloud avec NoSQL en 120 minutes chrono :o)
• Pour continuer, j’hésite entre Taming Functional Web Testing (with Spock & Geb) par Luke Daley et The Curious Case of JavaScript on the JVM par Attila Szegedi.

Je ne sais pas encore comment je finirais ma première journée, mais elle aura déjà été bien remplie ! Pour le jeudi, quelques idées :

• Go see all the ships in the world par Francesc Campoy Flores qui se propose de construire une visualisation dynamique de la position et trajectoire de tous les bateaux du monde ! Un vaste programme…
• Pour la suite, j’aimerais bien assister à What is in store for the future of Angular par Igor Minar et Misko Hevery, mais je pense que ce sera l’une des sessions les plus blindées, tant AngularJS est populaire en ce moment !
• Mon premier Quickie aurait bien été Make sense of your (BIG) data! par David Pilato, mais il se trouve que je passe à la même heure que lui ! Ce sera donc The ingredients for a perfect JavaScript Software Factory par moi-même !
• Pour la suite, ce sera peut-être Spring Framework 4.0 - The Next Generation par Sam Brannen, ou l’enregistrement du PodCast JavaPosse.
• Je continuerais par du Continuous Delivery avec Continuous Delivery antipatterns par Andrzej Grzesik puis Continuous Delivery Patterns for Large Software Stacks de Hans Dockter.

Je crois bien que ma journée de jeudi s’achèvera par le film proposé par Devoxx, The Counselor, Le Cartel de Ridley Scott. Pour la dernière journée (enfin, demi-journée), mon programme :

• Je commencerais peut-être par Batch Applications for the Java Platform (JSR 352) de Scott Kurz.
• Bien évidemment, un Devoxx ne serait rien sans son enregistrement live des CastCodeurs. Ma place y est donc déjà réservée :o)
• Pour terminer cette conférence, je me laisserais bien tenté par Avatar.js, Server-Side JavaScript on the Java Platform par Jean-François Denise.

Voilà, mon programme est établi. Bien entendu, celui-ci va sans aucun doute beaucoup évoluer quand je serais sur place. On verra vendredi après-midi si j’avais bien jugé ou pas…

L’idée est simple : ils se présentent à différentes sessions et illustrent graphiquement ce qu’ils entendent, ce qu’ils comprennent. Je n’ai pas eu la chance qu’ils viennent à ma session, mais je partage quand même les très jolies planches que voici (désolé pour la 4e qui est un peu floue) :

Et c’est parti pour le second jour de la conférence Soft-Shake.

Keynote collaborative

La première keynote de la journée était une keynote “collaborative”. Chaque responsable d’un track de sessions avait la parole pendant 4 minutes pour nous exposer sa vision à moyen terme (entre 2 et 5 ans) concernant sa technologie. Par exemple, le responsable de la partie “web” nous a dit que le JavaScript sera encore plus présent qu’aujourd’hui, en particulier du côté serveur.

Keynote Programatoo

La seconde keynote parlait de ”Programatoo”, un projet lancé par Audrey Neveu (@Audrey_Neveu) et Aline Paponaud (@bootis) de SFEIR. Qu’est-ce que Programatoo ? Il s’agit d’apprendre à coder à nos enfants, n’y plus n’y moins.

Revenons 20 ans en arrière pour comprendre la génèse de cette idée. Au milieu des années 80, Aline et Audrey sont des petites filles (très sages, forcément) déjà attirées par les mystères de l’informatique et des ordinateurs. Elles veulent comprendre comment ça marche. 10 ans plus tard, leur intérêt est toujours intact, mais hélas elles se heurtent souvent à des stéréotypes (”ce n’est pas pour les filles !”) ou l’incompréhension du milieu scolaire pour ce domaine. Audrey apprend avec joie qu’il y a des cours d’informatique dans son lycée. Elle s’y inscrit, mais cela se résumera à apprendre à utiliser Word ou Excel. C’est la déception. De son côté, Aline n’a guère plus de succès. Fort heureusement, elles ne baissent pas les bras, et embrassent le métier de programmeuse.

En 2012, Aline va trouver Audrey pour proposer une idée géniale : et si on apprenait à coder à nos enfants ! C’est ainsi qu’en mars 2012 nait la première session “Programatoo”, avec les enfants des employés de SFEIR. Et c’est un succès.

Les choses ne sont pas pour autant parfaites. Elles font un constat navrant. Parmi les participants, il y avait deux adolescentes. Celles-ci sont parfaitement à l’aise avec les ordinateurs, du moins quand il s’agit d’utiliser Facebook, YouTube et autres services du genre. Mais elles sont incapables de vraiment utiliser un ordinateur, de comprendre comment cela fonctionne, ni même voir en cette machine un merveilleux outil de créativité !

On dit que la jeune génération est une génération “digitale”, qu’elle est née avec un smartphone dans les mains. Je le constate aussi, mon fils de 6 ans maitrise depuis un moment l’iPad, qui n’a plus de secret pour lui. Mais en réalité, nos enfants sont conditionnés pour ”consommer” de l’informatique. Il faut les aider à en devenir des acteurs, des vrais utilisateurs. Finalement, c’est un peu comme une carte et un GPS : aujourd’hui, l’utilisation d’un GPS est plutôt intuitive et il nous mâche tout le travail, on n’a plus qu’à suivre bêtement ses instructions. Du coup, il devient obsolète de savoir lire une carte papier classique, et pourtant cela reste la base pour savoir se positionner quelque part…

En tant qu’informaticien, il ne tient qu’à nous de changer la donne. Nous avons beaucoup d’outils, de langages destinés à l’aprentissage de la programmation, y compris destinés à de jeunes enfants. Ayant discuté ensuite avec Audrey, je vais sans doute essayer de mettre mon fils à la programmation. Bien entendu, point de Scala :) mais plutôt du Scratch qui a l’avantage d’être très visuel et ludique.

Il faut noter que le projet Programatoo n’est pas unique en son genre. Les conférences “Devoxx 4 Kids” s’organisent par-ci, par-là. Il y en avait justement une à Genève le samedi qui a suivi la conférence Soft-Shake.

Programatoo a également gagné le “Duke Choice Awards 2013” à la conférence Java One. Une très belle consécration amplement méritée. Bravo Audrey et Aline !

Speed-up your webapp

Alexis Bernard (@alexis_bernard)

Je suis ouvert d’esprit, je vais donc dans le track “Ruby” pour la première session de la journée. Alexis nous parle d’optimisation quand on veut accélérer son site web.

Première question : pourquoi le faire ? A cela, Alexis nous donne les exemples de Amazon et Yahoo! : pour le premier, diminuer le temps de réponse de 100ms, c’est un gain de revenu de l’ordre d’1%, ce qui n’est pas négligeable quand on voit leurs revenus… Pour le second, une diminution de 400ms de ce temps de réponse, et c’est 9% de traffic gagnés ! Tout le monde n’est pas Amazon ou Yahoo! mais cela reste intéressant.

La technique d’Alexis est simple : mesurer, optimiser et mesurer encore.

Donc il faut mesurer. Pour cela, Alexis nous parle de quelques outils :

• New Relic, une solution SAAS visiblement assez poussée, qui historise en plus les mesures. Pratique pour comparer dans le temps. Mais c’est une solution assez chère visiblement (de l’ordre de 150€ par mois et par serveur).
• Rack Mini Profiler, un outil Ruby, un peu dans la même idée que New Relic, mais avec moins de fonctionnalités, et pas d’historisation.
• Pingdom dont l’une des fonctionnalités est de vérifier que les recommandations standard d’optimisations des sites-web sont bien respectées.
• WebPageTest, qui a l’astuce de tester chaque requête 2 fois de suite. Cela permet ainsi de vérifier l’efficacité du système de cache des ressources.
• Chrome Dev Tools peut aussi être mis à profit pour mesurer les performances de l’application.

Une fois les mesures faites, il faut corriger les problèmes. Alexis nous dit qu’il faut toujours optimser le back-end dans un premier temps. La plupart du temps cela va se résumer à optimiser la base de données, les requêtes, les indexes, etc. Une fois ceci fait, on peut s’intéresser à l’optimisation front-end. Là aussi des outils peuvent nous aider, Chrome Dev Tools par exemple, ou imageoptim.com, pour améliorer la compression des images.

Une session intéressante, mais qui ne va pas à mon goût assez loin dans les détails. Les solutions proposées restent assez basiques au final.

Golo, le langage qui donne des super-pouvoirs

Philippe Charrière (@k33g_org)

Mais qu’est-ce que Golo, ce langage au nom rigolo ? C’est un langage créé par Julien Ponge (@jponge) qui tourne sur la JVM, avec Java 7 ou 8 (pas avant, car Golo nécessite invokedynamic pour tourner, introduit en Java 7). Ses principales forces sont sa simplicité, sa légèreté ainsi que la facilité d’étendre le langage.

Philippe nous montre quelques exemples de code, la syntaxe reste assez compréhensible pour un développeur Java. Les lambdas, qui se font toujours attendre dans Java, sont là, tout comme les structures, des objets créés dynamiquement (ObjectDynamic) ou encore la possibilité d’étendre (augment) des classes existantes pour leur ajouter des fonctionnalités.

Je vous invite à aller jeter un oeil sur le site du langage - http://golo-lang.org - pour vous rendre compte de ce qu’offre ce langage, et voir quelques exemples concrets de code. Voilà un basique Hello World :

1
2
3
4
5
6
7
8

module EchoArgs

function main = |args| {
    println("Hello World...")
    foreach arg in args {
      println("->  " + arg)
    }
}

J’ai aimé cette présentation, qui nous a donné un bon aperçu de ce qu’est Golo. Toutefois, cela reste un langage dont le but m’échappe un peu - hormis le côté “fun” d’avoir créer son propre langage !

Mobile Troll Party

Xavier Bourguignon (@xbourguignon)

Une session pour le fun. Le but ici est de troller sévèrement sur iOS et Android. Je m’attendait à un peu plus de trash, un peu plus de sujets polémiques. Le jeu des deux présentateurs n’était peut-être pas assez rodé je pense, mais d’après ce que j’ai compris, Xavier devait la faire seul jusqu’à la veille au soir où il a réussi à convaincre son partenaire de venir aussi. Malgré tout, c’était une bonne ambiance, et les trolls étaient effectivement nombreux !

5 ans, 500 releases en 50 minutes

Freddy Mallet (@FreddyMallet) et Olivier Gaudin (@gaudol)

Compte tenu du temps imparti (45 minutes), cette session a été renommée ”4 ans, 400 releases en 40 minutes” :) Cette session raconte la vie de la société SonarSource, éditeur de l’outil d’analyse de code SonarQube (connu anciennement simplement sous le nom Sonar).

Lorsque SonarSource a été créée, il y a 5 ans, c’était une petite startup lancée par trois personnes (en particulier Olivier et Freddy), sur leurs fonds propres. La société marche bien aujourd’hui, et a bien grossi (une 20aine de personnes d’ici la fin de l’anée), mais il y a eu beaucoup de problèmes, de “douleurs”. En particulier 5 :

• Les tests.
• L’architecture.
• L’infrastructure.
• L’organisation.
• Sonar on Sonar.

Un gros travail a été fait sur les tests. Les tests unitaires d’abord, mais aussi les tests d’intégration. Le fait que Sonar supporte 5 bases de données différentes, qu’il existe une soixante de plugins ne rend pas les choses simples. Toutefois, ils arrivent à tout tester de façon assez efficace.

Initialement, HibernateORM et GWT avaient été choisis. Le premier car gérer 5 bases de données et autant de spécificités n’est jamais aisé. Le second, car à l’époque cela répondait bien aux besoins de l’équipe. Mais ces choix se sont finalement avérés être des maillons faibles, et progressivement ont été remplacés.

Les développeurs ne font pas que des développements, il a fallu embaucher une personne dédiée à part entière pour gérer l’infrastructure et les releases. Mais un tel cloisonnement n’est jamais très efficace, et SonarSource a ainsi créer une équipe de “DevOps”.

Afin de ne pas être désynchroniser avec les utilisateurs de l’outil, l’équipe de SonarSource utilise SonarQube directement. Le fameux principe du ”Eat your own dog food” en somme. Ils ont ainsi une instance de “production” interne pour laquelle ils font des releases toutes les semaines. Cela implique donc d’être capable de faire des releases presque tous les jours, les développements de type “big bang” sont donc exclus.

Un dernier point abordé par Freddy et Olivier concerne le Quality Gate (un sujet qui mériterait sans doute une session à part entière). Il s’agit d’une sorte de contrat de qualité pour pouvoir faire une release. En gros, il faut respecter certaines règles, atteindre certains objectifs pour engager la release : par exemple, avoir clos tous les tickets JIRA, avoir une note SQALE de A (la meilleure), ne pas avoir de violations bloquantes ou critiques, ou même de violations non revues par l’équipe.

Bilan

Au final, ce sont deux très belles journées qui viennent de s’écouler. La qualité des présentations et le niveau des speakers sont très bons.

Les plus :

• Du beau monde. C’est toujours un plaisir de revoir des gens qu’on apprécie, et de rencontrer physiquement des personnes que l’on ne connait que par Twitter.
• De bons sujets.
• Des tracks très variés : Java, agilité, web, mobile, IA/Robotique, BigData et NoSQL, Microsoft, Ruby on Rails.
• Le repas des speakers (miam miam la fondue !)
• Genève, très jolie ville.
• Les organisateurs, très accueillants et toujours disponibles.
• Les dessins en live des sessions (voir prochain billet).

Les moins :

• La séparation des salles. Elles se trouvaient soit au 1e étage, soit au 5e. Changer de salle pouvait ainsi demander un peu de gymnastique !
• A peu de choses près, les mêmes repas le midi sur les deux jours. Un peu plus de variété aurait été appréciable. Pas de problème au niveau de la quantité toutefois.
• J’aurais bien aimé que SoftShake se tienne en hiver, Genève sous la neige doit être très agréable.

Pour résumer, Soft Shake est une très belle conférence, dans l’esprit de Devoxx ou Mix-IT. J’y retournerais avec grand plaisir !

Jacques Couvreur nous accueille pour cette session 2013 de la conférence Soft-Shake. Ce sont 2 jours de conférences, neuf tracks en parallèle, une centaine d’orateurs, et 300 participants. A noter qu’environ un tiers des présentations se fait en anglais. Une bonne petite conférence donc !

Je vais faire comme Nicolas Martignole (a.k.a. le touilleur express), à savoir que je vais donner pour chaque session mon ROTI, le Retour sur le Temps Investi, autrement dit une note de 0 à 5 qui dénote l’intérêt que j’ai eu à suivre la présentation.

Keynote

Robin Cornelius

Difficile de résumer cette keynote. C’était plus un discours de Robin Cornelius sur sa vie et celle de sa société, Switcher. Mais c’était tout de même agréable de l’écouter parler. Robin fait partie des gens passionnés par son travail, sa société, et que l’on pourrait écouter pendant des heures. Bon démarrage donc…

Votre première application iOS

Marc-Henri Primault

Présenter un langage en l’espace de 45 minutes, c’est compliqué, il y a forcément beaucoup de concepts à montrer. Je pense que Marc-Henri a bien montré les bases, mais il est vrai que la lisibilité du code dans les slides n’était pas extraordinaire. La coloration de certains mots clés en violet sur fond noir n’est jamais bien rendue par un vidéoprojecteur.

Personnellement, j’ai eu du mal à accrocher car malheureusement le format de présentation ne se prête pas très bien à un tel apprentissage, en particulier pour des personnes comme moi qui n’y connaissent pas grand chose en développement iOS. Un ”Hands On” s’y prêterait tellement mieux !

Generating tests from code, or how to test better and faster

Renault John Lecoultre (@renajohn)

Tester une application JavaScript, c’est compliqué. Il existe deux types d’analyse de code : l’analyse statique et dynamique.

La première se concentre à vérifier syntaxiquement si le code est correct. On détectera ici l’utilisation de mauvais patterns, ou du code qui peut présenter un risque fort de bug, comme par exemple l’utilisation du == au lieu du === en JavaScript. Des outils comme JSLint, JSHint ou encore SonarQube sont tout à fait adaptés pour ce type d’analyse. Mais cela a quand même des limites.

L’analyse dynamique va exécuter le code pour en vérifier certaines règles, le cas le plus courant étant l’exécution de tests (unitaires, fonctionnels, etc.).

Renault nous parle toutefois d’un troisième type d’analyse, à savoir l’analyse symbolique. Une rapide recherche sur Google me dit que ”L’analyse symbolique de données consiste en un mode d’analyse de tableaux de données statistiques arbitraires par perception cognitive de la surface expressionnelle du médium.” Bon, je crois qu’on va laisser tomber la définition et voir directement comment Renault l’illustre dans sa démonstration.

Il nous parle de l’outil Unite de sa société BugBuster. L’idée derrière cet outil est de lui fournir une fonction en entrée, et lui va essayer de trouver un jeu d’entrées (inputs) afin de pouvoir tester tous les chemins possibles dans la fonction. Prenons l’exemple suivant :

1
2
3
4
5
6
7

// params : {x: Number}
function puzzle(x){
  if(x)
    return true;
  else
    return false;
}

On le voit, pour parcourir les deux branches de cette fonction, nous devons faire en sorte d’évaluer à true la condition if, puis également à false. C’est là qu’intervient Unite. Il va analyser le code de la fonction pour nous trouver les deux valeurs d’entrée, ici x = 0 puis x = 1. Là où l’outil devient plus intéressant, c’est quand on a du code plus complexe. Prenons un nouvel exemple, avec une fonction de validation d’email (avec une expression régulière simple) :

1
2
3
4
5
6
7

// params : {email: String}
function puzzle(email){
  if(email.match(/^\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,3}$/))
    return true;
  else
    return false;
}

Unite va nous trouver deux entrées possibles : `email = "a" pour l’évaluation négative de la condition, et email = "9@B.PH" pour son évaluation positive.

Je dois dire que l’outil s’avère très intéressant, bien qu’encore à l’état de bêta. Reste la question de l’industrialisation d’un tel outil. Pour le moment, je le vois bien comme utilisation one shot pour trouver un bon ensemble de jeux de données pour tester une fonction. En tout cas, c’est un outil à suivre de près…

Backbone.js et Marionette, le développement JavaScript simplifié

Xavier Bourguignon (@xbourguignon) et Philippe Charrière (@k33g_org)

Backbone est une librairie légère pour faire du single page application (“MVC” / “MVP” côté client). Il se base sur la librarie underscore, pour le templating par exemple. Backbone dispose d’un modèle objet. Son intérêt réside également dans sa facilité d’extension.

Philippe commence à nous montrer des exemples de code avec Backbone. Mais de l’avis de Xavier, ”Backbone c’est bien, sauf la partie vue”. Et c’est vrai que je trouve le code côté vue assez verbeux. C’est pour cela qu’il introduit la librairie Marionette.js, qui joue ainsi le rôle de surcouche à BackBone pour gérer la partie Vue. Ainsi, Marionette permet de faire du vrai Single Page Application avec BackBone.

Xavier et Philippe nous offrent ainsi une vision assez claire de ce framework, en montrant ses atouts mais aussi ses limites. J’avoue que je préfère toujours AngularJS, bien que ce dernier ait un côté un peu plus “magique” que Backbone qui semble plus accessible et plus compréhensible.

Web Components, l’avenir des développeurs web

Julien Vey (@julienvey)

Les applications web sont aujourd’hui de plus en plus riches, et le langage HTML atteint vite ses limites. C’est pour cela que le concept de composants web est arrivé. Il s’agit d’un standard W3C en cours de rédaction, partiellement implémenté par les navigateurs (particulièrement Chrome).

L’idée est de créer des “éléments customs”. Imaginons le bouton “Twitter” que l’on peut ajouter sur son site, afin de permettre au visiteur du site de suivre votre compte Twitter. Si vous regardez le code de ce bouton, vous verrez un truc illisible fait de HTML et JavaScript. Ne serait-ce pas plus simple d’avoir un tag <twitter user="romaintaz"/> par exemple ? De même, un composant pour noter un article n’aurait-il pas plus de sens sous la forme <ranking note="3"/> ?

Eh bien c’est (à peu près) possible aujourd’hui !

Les templates

La première brique à connaître, ce sont les templates. Ils permettent la séparation du fond et de la forme via l’utilisation de <template> :

1
2
3
4
5

<template id="monTemplate">
  // code HTML du template.
  <img src="">
  <div class="comment"></div>
</template>

Ce template est parsé, mais pas affiché. Les balises <script/> ne sont pas exécutées, et les images ne sont pas chargées. Le code ci-dessus est donc parfaitement valide. Pour l’instancier, il suffit d’un peu de code JavaScript :

1
2
3

var t = document.querySelector('#monTemplate');
t.content.querySelector('img').src = "...";
document.body.appendChild(t.content.cloneNode(true));

A ce moment-là, les scripts sont exécutés, les images chargées et le DOM affiché.

Encapsulation

Passons à la deuxième brique : l’encapsulation. Aujourd’hui, on utiliserait des <iframe>. Mais pouah ! Avec les web components, on utilise le principe du ”shadow DOM”, c’est-à-dire du DOM masqué du reste de l’application. Exemple :

1

<video controls src="/ma/video"></video>

Avec Chrome Tools, on peut faire afficher le shadow DOM pour cette balise vidéo, sous un “tag” #document-fragment :

1
2

<div id="host">
</div>

1
2
3

var host = document.querySelector('#monTemplate');
show = host.createShadowRoot();
shadow.innerHTML = '<h2>Hello</h2>';

On peut aussi passer par des templates :

1

shadow.webkitCreateShadowRoot();

Il existe aussi le concept d’Insertion point, avec utilisation de <content></content> dans le shadow DOM. Le contenu de la balise du web component est injecté à la place du <content></content> défini dans le shadow DOM.

On peut aussi utiliser des sélecteurs pour ne récupérer qu’une partie du code HTML du composant web : <content select="h2"></content> qui récupèrera uniquement le code du h2, <content select="h1:first-child"></content> pour le premier élément de h1 ou <content select="*"></content> pour récupérer le reste.

Externalisation

Comment peut-on créer des composants web et les utiliser ailleurs ? Cela se fait grâce à la balise <element> qui permet de créer ces nouveaux éléments :

1
2
3
4
5
6
7
8

<element name="megabutton" extends="button" constructor="MegaButton">
  <template>
      ...
  </template>
  <script>
      ...
  </script>
</element>

Et pour l’utiliser dans une autre page :

1
2
3

<link rek="component" href="megabutton.html">
...
<megabutton>Clique ici</megabutton>

Ces éléments ont également un cycle de vie sur lequel il est possible d’intéragir grâce à des fonctions JavaScript : created, attributeChanged, inserted ou removed :

1
2
3
4

this.lifecycle({
  inserted: function() { ... },
  removed: function() { ... }
})

Mutation Observer

Ces éléments sont utilisés pour détecter des modifications dans le code JavaScript.

Object.observe()

Il s’agit ici du monitoring des modifications des objects JS, bien plus performante que tout autre solution existante aujourd’hui.

1
2
3
4
5
6
7
8

function observeChanges(changes) {
  changes.forEach(function(change) {
      change.name;                  // Name
      change.type;                  // Type
      change.oldValue;          // Ancienne valeur
      change.object[change.name]; // Nouvelle valeur
  });
}

Ainsi, entre le Dirty checking et le Object.observe(), le gain de performances peut être de l’ordre de 20 fois !

Etat actuel

AngularJS apporte sa philosophie, déclaratif plutôt qu’impératif. Les directives d’Angular sont un peu les customs éléments.

Le projet ”polymer.js” vise à intégrer ces nouveautés dans les navigateurs.

Il existe aussi le projet Polymer.Dart pour le langage Dart.

Le site ”Are we componentized yet?”, montre l’état actuel de l’implémentation dans Chrome. Du côté de Firefox, il existe des projets similaires Brick, X-Tag…

Mon avis

Une excellente session où j’ai appris pas mal de choses que je ne connaissais pas !

Du JavaScript propre ? Challenge Accepted!

Romain Linsolas (@romaintaz) et Julien Jakubowski (@jak78)

Présentation tout simplement parfaite, sur un sujet somptueux. Du grand art ! Comment ça, je ne suis pas objectif ?

Bon, si vous voulez en savoir plus, revenez un peu en arrière sur mon blog, j’ai déjà parlé de cette présentation faite avec Julien à Devoxx. Elle a encore plu, ça nous a fait très plaisir !

Make sense of your (Big) Data

David Pilato (@dadoonet)

David Pilato est “évangeliste” (à ne pas confondre avec Eve Angeli !) pour ElasticSearch, un outil très puissant et très sympathique pour faire de la recherche. Associé avec Kibana, David nous montre comment il est possible pratiquement en temps réel de construire un dashboard très complet sur un grand jeu de données - stockées dans des noeuds ElasticSearch. Autrement dit, comment donner du sens à ses données.

J’essaierais de faire un billet dédié, je trouve que cette session est très intéressante car la solution mise en place est fichtrement simple pour un résultat franchement étonnant !

Bon, je n’ai pas blogué à ce sujet, mais j’aurais la chance dans trois semaines, d’assister à mon quatrième Devoxx. Et pour ne pas changer les bonnes habitudes, je me retrouve une nouvelle fois orateur !

Le sujet, c’est ”The perfect ingredients for a JavaScript Software Factory”. Oui, encore du JavaScript dans une conférence pourtant orientée Java. Cela prouve bien notre ouverture d’esprit, à nous autres Javaïstes !

Bref, de quoi ça va parler ? En gros, de tout ce qu’il faut pour “industrialiser” son développement JavaScript. Un développeur Java dispose déjà de toute une panoplie d’outils et de pratiques pour développer correctement ses applications. Mais qu’en est-il pour un développeur JavaScript ? L’écosystème est-il désert ou au contraire fourmille-t-il de petites perles ?

Hélas, il s’agit d’un Quickie, ce qui veut dire que je n’aurais que 15 minutes pour aborder ce sujet tellement vaste. Je serais donc amené à surtout éfleurer ce sujet, mais cela me semble une bonne approche pour un développeur qui souhaite s’intéresser vraiment à faire du JavaScript propre !

Bref, si vous êtes à Anvers la semaine du 11 novembre, n’hésitez pas à venir jeter un oeil à ma présentation…

Super nouvelle, la présentation ”Du Javascript propre? Challenge Accepted!” a été retenue pour la conférence Soft Shake 2013 à Genève en Suisse, du 23 au 24 octobre. La présentation sera sensiblement la même que celle faite à Devoxx avec Julien Jakubowski, mais on essaiera de mettre à jour certaines parties.

Si vous venez à la conférence, venez nous voir !

Le jeudi 11 avril s’est tenue la troisième édition du Scrum Day, un événement organisé par le French Scrum User Group (ou FSUG) autour de l’agilité.

Avant d’aborder mon compte rendu, je tiens à remercier chaudement la société Zenika qui m’a permis d’assister à cette conférence. En tant que sponsor de l’événement, elle a proposé de gagner une place avec un peu jeu concours sur Twitter. Et c’est moi qui ai gagné \o/ Donc merci à eux.

Pour nous accueillir, Xavier Warzee débute avec un discours d’ouverture où il rappelle ce qu’est le FSUG, ses activités, son bilan. Il fait également venir les sponsors sur scène, pour une courte présentation. Puis il laisse la main à Robert Richman…

Keynote “Culture Hacking”

La journée commence vraiment avec la keynote de Robert Richman. Il travaille dans le département Zappos Insights de la société Zappos, l’un des leaders de la vente de chaussures sur Internet (eh oui), aujourd’hui rachetée par Amazon.

Il se définit comme un Culture Hacker, il est également l’auteur du livre Culture Blueprint. Il nous incite ainsi à comprendre comment fonctionne une culture d’entreprise, de groupe, etc. Il débute en nous racontant une petite histoire à propos du Burning Man. Il s’agit d’un rassemblement culturel et artistique qui a lieu chaque année dans le désert du Nevada, où se cotoient plusieurs dizaines de milliers de personnes. Cette rencontre pourrait s’apparenter à un chaos total, pourtant les gens s’y retrouvent avec bonne humeur, et une harmonie certaine. Le succès tient entre autres à un ensemble de règles régissant la communauté :

• Inclusion radicale : tout le monde est le bienvenu.
• Pratique du don : pas d’argent, tout se fait par des cadeaux, des prestations, des dons.
• Décommercialisation : pas de publicité, pratiquement aucune transaction financière.
• Auto-suffisance médicale.
• Expression de soi radicale, poussant ainsi les participants à s’exprimer sous des formes variées, en particulier à travers des oeuvres artistiques.
• Effort en commun, où l’on favorise le travail d’équipe.
• Responsabilité civique.
• Pas de trace : malgré le grand nombre de participants et des manifestations, l’endroit doit être rendu tel qu’à l’origine. Le respect de l’environnement est omniprésent.
• Participation.
• Culture du moment présent.

Robert Richman parle également de l’ouvrage ”Tribal leadership”, de Dave Logan, où il est montré l’importance d’avoir une liste de règles pour qu’une communauté - ou une tribu - puisse fonctionner. Il nous montre qu’à Zappos, où il travaille, il est également établi une liste de règles, définissant les valeurs communes de leur “famille” :

• Deliver WOW Through Service
• Embrace and Drive Change
• Create Fun and A Little Weirdness
• Be Adventurous, Creative, and Open-Minded
• Pursue Growth and Learning
• Build Open and Honest Relationships With Communication
• Build a Positive Team and Family Spirit
• Do More With Less
• Be Passionate and Determined
• Be Humble

L’ambiance à Zappos transparait dans l’excentricité des open spaces

Robert Richman nous pose une question. Ne pourrait-on pas considérer qu’une culture est aussi un produit ? C’est un peu pour cela qu’à Zappos, ils créent des événements pour “promouvoir” leur propre culture. Il ajoute quelque chose qui est tout à fait vrai : parfois, lors de ce genre d’événement, on est satisfait par l’information que l’on en tire, mais c’est avant tout l’expérience que l’on vit qui est fantastique (Information is OK, but experience is amazing). Quand il a dit ça, j’ai tout de suite pensé à ma propre expérience à Devoxx : j’en tire beaucoup d’informations intéressantes, mais c’est vraiment l’expérience de la conférence elle-même qui reste un souvenir fantastique.

Robert Richman nous fait maintenant une petite liste de Culture Hacks :

• How to walk into a room can shift a culture. Lorsque l’on entre dans une pièce, il faut montrer son assurance, son énergie de façon à pouvoir faire la différence, créer une synergie.
• Destroy something. Détruire est tellement plus puissant que créer, et cela apporte de l’énergie. Il faut détruire quelque chose d’inutile ou qui ne marche pas.
• Frustration is gold. La frustration n’est jamais que de l’énergie bloquée.
• Use ritual for energy. Robert Richman nous explique que des petits rituels peuvent créer de l’énergie au sein d’une équipe. Il nous explique qu’à Zappos chaque jeudi à 15h, tout le monde arrête de travailler pendant 10 minutes… pour danser ! C’est la 3PM Thursday Dance Party.

Pour finir, il nous rappelle que Scrum lui-même a ses propres valeurs :

• Focus
• Engagement
• Respect
• Courage
• Ouverture

J’ai adoté cette keynote pour son côté énergique et rafraichissant. De façon générale, les orateurs américains ont un vrai sens du show, et ce n’est pas Robert Richman qui me fera penser le contraire. J’ai aussi beaucoup aimé la façon dont il a pu nous transmettre l’ambiance qui règne chez Zappos.

Introduction au leadership tribal

Florent Lothon est coach agile pour CSC (site agiliste.fr). Il nous parle du Leadership Tribal, tiré d’un livre éponyme. Cela fait une bonne transition avec la keynote précédente.

A l’origine, il y a une étude, menée pendant 10 ans sur un panel d’environ 24,000 personnes. Cette étude s’est concentrée uniquement sur deux aspects : le langage et le comportement des personnes étudiées, considérant que les mots que l’on utilise influencent directement notre comportement. Cette étude a permis d’établir cinq stades, et donc cinq discours associés, au sein d’une tribu. Mais avant d’aller plus loin, il est nécessaire de définir ce qu’est une tribu.

Une tribu est un groupe, une organisation de 20 à 150 personnes qui se connaissent suffisament pour se saluer quand elles se croisent. Une petite entreprise est une tribu, tandis qu’une société de taille plus importante est une tribu de tribus.

Les cinq stades

1. La vie est nulle (~ 2%). Ces persones vont avoir un comportement de sabotage et un type de relation d’exclusion.
2. Ma vie est nulle (25%). Ces personnes, plutôt isolées se posent en victimes passives. Florent cite la bande dessinée Dilbert comme exemple.
3. Je suis génial (sous entendu “pas les autres”) (49%). À ce stade, on rencontre plutôt des guerriers solitaires ayant une tendance à la domination personnelle.
4. Nous sommes géniaux (mais “pas les autres”) (22%). À ce stade déjà très élevé, les membres ont une fierté tribale, et établissent des partenariats stables.
5. La vie est géniale (< 2%). Le comportement de ces personnes est un émerveillement innoncent, et forme une véritable équipe. À un tel niveau, l’énergie de la tribu rayonne au delà de leur cercle, et “contamine” les personnes alentours. Florent nous cite l’histoire de Matt, un anonyme qui a filmé ses scènes de danse au quatre coins du monde. Florent rebondit aussi sur la keynote précédente en citant Zappos comme exemple de société de niveau #5.

Les leviers d’évolution

Au delà de ce constat, la question que tout le monde se pose est de savoir comment on peut passer d’un niveau à l’autre ? Une chose importante est de savoir qu’il ne faut pas sauter des étapes. On ne pourra pas passer du stade #1 au stade #3 sans passer par le deuxième stade, car chaque stade se base sur les acquis du précédent.

1. Du Stade #1 au stade #2. Les principaux leviers à ce stade sont les suivants :
2. Il faut aller là où est l’action : participer à des réunions, des conférences, ou simplement aller déjeuner avec les gens.
3. Se convaincre que la vie peut fonctionner, même pour soi.
4. Se couper des autres personnes qui stagnent à ce stade #1.
5. Du Stade #2 au stade #3, les leviers sont :
6. La création des relations dyadiques (2 personnes).
7. Souligner les compétences et les forces des personnes.
8. Proposer des projets à court terme avec une forte probabilité de succès, et qui nécessite peu de suivi.
9. Du Stade #3 au stade #4. À ce niveau-là, les personnes ont appris à se faire confiance, mais ils ont tendance à vouloir conserver un certain nombre d’informations pour eux, pour garder une sorte de pouvoir. On pourra tenter de les élever au stade supérieur ainsi :
10. Encourager des relations triadiques (3 personnes), et dont le succès nécessite un partenariat fort.
11. Faire comprendre que le vrai pouvoir n’est pas dans les connaissances, mais dans les réseaux.
12. Forcer la transparence grâce à une communication à outrance, plutôt que de n’y avoir recours qu’au besoin, en se limitant au strict nécessaire.
13. Du Stade #4 au stade #5. Au stade #4, le niveau est déjà élevé. Pour atteindre le nirvana, le stade #5, des leviers ne suffisent plus, il faut mettre en place une stratégie. Celle-ci doit résulter de la tribu dans son ensemble, selon le contexte, et non seulement d’une personne, d’un leader. La stratégie est celle-ci :
14. Définir les valeurs fondamentales de la tribu. Ce sera la moteur de la stratégie.
15. Les résultats : que voulons-nous atteindre ?
16. Les actifs : qu’avons-nous ?
17. Les actions : qu’allons nous faire ?

Image de Florent Lothon, http://www.agiliste.fr

Florent termine la présentation par une citation tirée du livre de Dave Logan :

Alors que les leaders tribaux travaillent pour le bien du groupe, non pas pour eux même, ils sont récompensés par la loyauté, le travail acharné, l’innovation et la collaboration. La tribu produit un travail de la plus grande qualité en moins de temps. […] L’avenir de l’entreprise est le stade 5.

Juste avant de nous laisser, il nous parle du 21 days challenge, une sorte de challenge à réaliser en 3 semaines. L’idée est de regarder une petite vidéo chaque matin, qui va nous lancer une sorte de défi dont le but final est de faire de nous un meilleur leader. Il cite un exemple de défi : aller voir 3 personnes dans son entourage professionnel, et demander ce qu’ils pensent de nous, de notre réputation.

A lire, le billet sur son blog retraçant cette présentation et sa présentation sous Prezi

Transition agile dans une grande banque européenne à l’aide des Innovation Games

Catherine Boudlal et Xavier Warzee de Palo-IT nous raconte comment ils ont mis en place l’agilité d’une grande banque (non, ce n’est pas la mienne ;o)) grâce aux Innovation Games. La situation est simple lorsqu’ils arrivent chez le client : l’agilité est totalement absente, mais ils veulent la mettre en place afin de pallier à leurs problèmes récurrents sur les développements, les mises en production, etc. Hélas, cela doit se faire en peu de temps (quelques semaines tout au plus). Xavier et Catherine décident donc d’opter pour les Innovation Games afin d’engager le processus de transformation agile. Les étapes sont les suivantes :

• Collecter des informations sur la situation actuelle, sur les blocages.
• Démarrer la transformation agile.
• Faire émerger de nouvelles organisations agiles.

Les jeux (qui sont appelés “ateliers” auprès du management, ça passe mieux !), sont les suivants :

• SWOT. Le principe de SWOT est l’identification des forces, des faiblesses, des opportunités et des risques. Ils ont ainsi pu collecter des informations sur les pratiques, identifier les problèmes et processus des développements. De ces informations sortent des recommandations, telles que la mise en place de l’intégration continue et d’autres outils, de la réorganisation des équipes et des espaces de travail, la définition de KPI simples, etc.
• 20/20 vision. Le but est d’apprendre à prioriser des fonctionnalités. Ainsi, on peut définir des sortes de lois, qui établiront un chemin commun vers l’agilité (cf http://guide.agilealliance.org/subway.html).
• $100 test. Grâce à ce jeu, Xavier et Catherine ont pu mettre en place la transformation agile d’une équipe, et améliorer le fonctionnement de cette équipe en tant qu’équipe, et non plus en fonction d’individualité ou de coeur de métier.
• Graphic Gameplan. Ici, l’intérêt est de trouver les blocages, et de définir les étapes qui permettent de les résoudre.

Xavier et Catherine nous ont aussi parlé de la façon dont les participants ont réagi par rapport à cette approche “ludique” de l’agilité. À part une poignée d’irreductibles, il semble que la grande majorité des personnes présentes lors de ces “ateliers” a apprécié la démarche et a joué le jeu.

Au final, cette session était un retour intéressant, mais avec un bémol. Ils nous expliquent qu’une fois ce stade des IG terminée, ils ne sont pas restés dans la société (une autre entreprise a pris la suite). Du coup, nous n’avons pas pu savoir si cela a vraiment porté ses fruits, si l’agile a bien été adopté, et quel niveau de maturité pouvaient avoir les équipes aujourd’hui.

Transformation à grande échelle, 18 mois plus tard… (SGCIB)

J’assiste donc à un retour d’expérience sur la transformation agile à la SGCIB, société que je connais plutôt bien :) Celle-ci nous est racontée par Clémo Charnay et Myriam Roux de la SGCIB ainsi que de Céline Stauder, coach agile chez Coactiv.

Ils nous présentent donc l’histoire de la transformation agile qu’ils ont initiée à la SGCIB pendant plus d’une année dans un service gérant environ 70 applications. Tout commence par un constat : le service informatique est en perte de contrôle du SI. Les mises en production sont sans cesse décalées, la qualité n’est pas au rendez-vous, et la complexité omniprésente. Ainsi, une demande peut faire intervenir jusqu’à 7 équipes différentes !

Ils commencent par mettre en place 2 PoC :

• Le premier se fait dans un contexte favorable, où le projet démarre de rien, et où il est ainsi beaucoup plus facile d’y intégrer des notions d’agilité (TDD, intégration continue, etc.). Le succès est au rendez-vous.
• Dans la deuxième équipe, les choses sont plus compliquées, car le contexte est une application legacy - essentiellement de la maintenance ou du catalogue. Ici, le succès est plus mitigé, comme on pouvait s’y attendre.

La mise en place de l’agilité permet de passer d’un rythme de 4 releases par an à une presque tous les mois. Toutefois, si cela peut paraitre une bonne chose, elle est aussi un défaut. En effet, cela implique une plus forte charge pour les équipes, et cela implique une certaine fatigue.

Les trois présentateurs soulèvent 4 points importants à prendre en considération durant une transformation agile :

• Il faut savoir gérer les demandes du support. Le ”Production first” ne doit absolument pas devenir le ”Production only”. Il faut savoir faire la part des choses.
• Faire attention aux process de release, parfois (souvent ?) trop lours.
• Le découpage d’un projet est souvent orienté coûts plutôt que valeurs.
• Il faut savoir prendre du recul, et se demander pourquoi on fait certaines choses.

Au final, il y a une vraie prise de conscience que l’agilité est un plus. Mais il faut savoir comment la mettre en place. L’un des avantages de l’agilité, qui pourrait être vu comme un défaut par certains, est qu’elle a tendance à mettre en lumière des problèmes.

Les orateurs finissent par citer quelques problèmes rencontrés lors de cette transformation :

• L’organisation même d’ITEC, qui impose certaines limites, en particulier au niveau des budgets.
• Pas de reconnaissance ni de valorisation des profils agiles par les Ressources Humaines (peut être anxiogène pour certains).
• La mise en place de beaucoup de chantiers dont beaucoup ne sont pas terminés est un processus épuisants.

Voilà un retour d’expérience assez classique, rien de bien nouveau sous le soleil au final.

Mon DSI veut un indicateur sur l’agilité : Cadeau ou Poison ? (REX Total)

Yann Poles travaille pour Total, et nous raconte son expérience sur la mise en place de l’agilité chez eux. La DSI y est assez importante, puisqu’elle concerne un millier de personnes pour environ 200 projets par an.

En 2011, c’est le début de l’agilité chez Total, avec une vingtaine d’expériences plutôt concluantes. Toutefois, on reste dans une situation où le management laisse faire.

En 2012, suite à une réorganisation importante, de nouvelles ambitions sont présentées. Parmi elles, il y a ce chiffre de 50% de projets agiles d’ici 2017. Très bien, mais ce chiffre, que veut-il dire ? Que mesure-t-il ? Le souci est là justement : avec un tel indicateur, il n’est pas possible d’évaluer le degré de maturité de chaque équipe, leur niveau d’efficacité, de vélocité.

Chez Total aussi la transformation agile pose une question importante : comment faire ? Les équipes sont perplexes, les managers, qui ne trouvent pas leur place dans l’agilité, sont bousculés.

Les changements apportés par l’agilité vus par l’équipe :

• Travailler en équipe.
• Prendre des risques.
• S’engager.
• Être visible.
• Être autonome dans la prise de décision.
• Savoir se remettre en question.

Du côté des managers :

• Accompagner le changement.
• Déléguer, donner de l’autonomie.
• Avoir une posture de Servant Leader.

Rendre visible cette transformation, c’est :

• Être plus exposé (dans ses réussites mais aussi dans ses échecs).
• Crainte de la course au label “Agile” (que le projet ait à tout prix le tampon ”Ici on est agile” sans forcément faire de l’agilité).
• L’échelle n’est plus la même : on touche de plus grande équipe.

Dernière question que pose Yann Poles : comment péréniser l’agilité, ancrer la transformation ?

• Du côté de l’individu, il faut recourir à un accompagnement, éventuellement des formations.
• Du côté de l’équipe, il faut investir dans la communauté IT. Savoir aussi mesurer et soutenir la vélocité, la fluidité, la réactivé, le moral des équipes, la satisfaction du client.

Il termine par une citation de Gandhi :

Vous devez être le changement que vous voulez dans ce monde.

Un dernier point, en résonance à la mesure du nombre de projets qui sont agiles chez Total. Yann, ainsi qu’une partie de l’assistance, pense qu’il serait plus pertinent de mesure non pas le nombre de projets, mais d’équipes agiles.

Un nouveau retour d’expérience. Je ne sais pas si c’est exactement ce que je m’attendais à avoir en venant dans cette salle, mais c’était tout de même intéressant.

L’organisation et bilan

C’était ma première participation au Scrum Day (c’était la 3^ème édition), et je dois dire que cela m’a plu, j’ai eu toutefois une préférence sur mes sessions du matin, en particulier de l’excellente keynote de Robert Richman. J’ai vu plusieurs retour d’expérience sur des transformations agiles au sein de grandes sociétés (dont la mienne !) et j’ai quand même un peu l’impression d’entendre toujours les mêmes discours. Tant pis.

Dans l’ensemble, l’organisation s’est bien déroulée, mais j’ai quand même 2 critiques à formuler. Premièrement, les locaux (merci à IBM pour les avoir fournis) n’étaient pas toujours adaptés, car certaines salles étaient trop petites pour profiter de certaines sessions, en particulier les ateliers. J’ai ainsi dû passer mon tour pour la session L’agilité selon Starcraft 2 à 12h45. L’autre reproche c’est peut-être un manque d’accompagnement des speakers et du cadrage des sessions. Certaines ont un peu débordé, ce qui fait que le timing n’était pas toujours respecté. Cela n’enlève en rien toutefois le travail formidable des organisateurs, et de leur travail bénévole.

Je suis revenu de Devoxx France avec quelques idées en tête, dont celle de mettre du CasperJS dans des applications (merci Jean-Laurent et Pierre). Pour faciliter les choses, ma machine tourne sur du Windows (version 7 en l’occurrence), ce qui n’est pas forcément le meilleur environnement pour ce type de chose. Mais on ne va pas se décourager si vite, hein ?

Commençons petit, et essayons de faire marcher un test simple en JavaScript sur CasperJS.

Installation des outils

La première chose à faire, c’est d’installer CasperJS sur la machine Windows. Mais avant cela, il est nécessaire de disposer d’une version assez récente de PhantomJS (CasperJS utilise PhantomJS pour s’exécuter). Donc on télécharge PhantomJS et on l’installe (enfin on décompresse le ZIP). Dans mon cas, il s’agit de la version 1.9. Même chose ensuite, je dézippe le ZIP de CasperJS (v1.0.2), et je finis par ajouter dans mon PATH les chemins vers les exécutables. Voyons si ça marche bien :

1
2
3
4

D:\dev>phantomjs -v
1.9.0
D:\dev>casperjs --version
1.0.2

Les choses s’annoncent bien ! Exécutons un test maintenant. Prennons celui-ci, assez simple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

var casper = require('casper').create({
    verbose: true,
    logLevel: 'debug'
});

casper.start('https://mon-application:8080/login/', function() {
    this.echo('Log in');
    this.test.assertTitle('Sign in');
    this.test.assertNotVisible('label#error');
    this.fill('form#loginForm', {
        'j_username': 'romain.linsolas',
        'j_password': ''
    }, false);
    this.click("form#loginForm input.button");
    this.test.assertVisible('label.error'); // Une boite d'erreur doit apparaitre
    this.fill('form#loginForm', {
        'j_username': 'romain.linsolas',
        'j_password': 'abc123'
    }, false);
    this.click("form#loginForm input.button");
});

casper.then(function() {
    this.capture('test-screen.png');
    this.test.assertTitle('Hello World'); // Nous sommes loggués
    // Suite du test
});

casper.run(function() {
    this.test.renderResults(true);
});

En gros, il se divise ainsi :

• J’initialise un contexte casper (dans mon cas, je lui demande d’être un peu pipelette, ça facilitera les choses en cas de problème).
• Ensuite, je démarre un test où il va exécuter certaines tâches :
  • se connecter à une application ;
  • vérifier le titre de la page ;
  • remplir un formulaire de login sans le mot de passe ;
  • cliquer sur un lien, et vérifier qu’un message d’erreur apparait ;
  • retester en saisissant un mot de passe.
• Enfin, je vérifie que je suis bien connecté (le titre de la page a changé) et pour le fun, je fais une capture d’écran de la page telle qu’elle est à ce moment-là.

Allez zou, il est temps de tester. Le verdict va tomber très vite, il suffit d’écrire casperjs [mon fichier].js :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

D:\dev>casperjs test-casper.js
[info] [phantom] Starting...
[info] [phantom] Running suite: 3 steps
[debug] [phantom] opening url: https://mon-application:8080/login/, HTTP GET
[debug] [phantom] Navigation requested: url=https://mon-application:8080/login/, type=Other, lock=true, isMainFrame=true
[debug] [phantom] url changed to "https://mon-application:8080/login/"
[debug] [phantom] Successfully injected Casper client-side utilities
[info] [phantom] Step 2/3 https://mon-application:8080/login/ (HTTP 200)
Log in
PASS Page title is: "Sign in"
PASS Selector is not visible
[info] [remote] attempting to fetch form element from selector: 'form#loginForm'
[debug] [remote] Set "j_username" field value to romain.linsolas
[debug] [remote] Set "j_password" field value to
[debug] [phantom] Mouse event 'click' on selector: form#loginForm input.button
PASS Selector is visible
[info] [remote] attempting to fetch form element from selector: 'form#loginForm'
[debug] [remote] Set "j_username" field value to romain.linsolas
[debug] [remote] Set "j_password" field value to ******
[debug] [phantom] Mouse event 'click' on selector: form#loginForm input.button
[info] [phantom] Step 2/3: done in 718ms.
[debug] [phantom] Navigation requested: url=https://mon-application:8080/logincheck;jsessionid=808FD9D0EDD9D9C5CCAE7F11F4AE05DE, type=FormSubmitted, lock=true, isMainFrame=true
[debug] [phantom] Navigation requested: url=https://mon-application:8080/, type=FormSubmitted, lock=true, isMainFrame=true
[debug] [phantom] url changed to "https://mon-application:8080/"
[debug] [phantom] Successfully injected Casper client-side utilities
[info] [phantom] Step 3/3 https://mon-application:8080/ (HTTP 200)
[debug] [phantom] Capturing page to D:/dev/test-screen.png
[info] [phantom] Capture saved to D:/dev/.png
PASS Page title is: "Hello World"
[info] [phantom] Step 3/3: done in 1224ms.
[info] [phantom] Done 3 steps in 1226ms

Cool, ça marche !

Passons au CoffeeScript

Le JavaScript c’est bien, mais c’est un peu verbeux, surtout quand le code des tests va grandissant. Tentons maintenant de passer à CoffeeScript. CasperJS est l’ami de CoffeeScript et accepte très bien que les scripts à exécuter soient écrits avec. D’après la documentation, il est écrit qu’il suffit de lancer simplement la commande casperjs [mon fichier].coffee. Ca a l’air pas mal. Ecrivons tout d’abord le même code de test, mais cette fois-ci en CoffeeScript. Cela nous donne quelque chose comme ça :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

casper = require('casper').create(
    verbose: true
    logLevel: 'debug'
)

casper.start 'https://mon-application:8080/login/', ->
    @echo 'Log in'
    @test.assertTitle 'Sign in'
    @test.assertNotVisible 'label#error'
    @fill 'form#loginForm', {
        j_username: 'romain.linsolas'
        j_password: ''
    }, false
    @click "form#loginForm input.button"
    @test.assertVisible('label.error') ## Error box is displayed
    @fill 'form#loginForm', {
        j_username: 'romain.linsolas'
        j_password: 'abc123'
    }, false
    @click "form#loginForm input.button"

casper.then ->
    @capture 'test-screen.png'
    @test.assertTitle 'Hello World' ## Now we are logged
    ## Suite du test

casper.run ->
    @test.renderResults true

Allez, maintenant on exécute tout ça :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

D:\dev\>casperjs test-casper.coffee
[info] [phantom] Starting...
[info] [phantom] Running suite: 3 steps
[debug] [phantom] opening url: https://mon-application:8080/login/, HTTP GET
[debug] [phantom] Navigation requested: url=https://mon-application:8080/login/, type=Other, lock=true, isMainFrame=true
[debug] [phantom] url changed to "https://mon-application:8080/login/"
[debug] [phantom] Successfully injected Casper client-side utilities
[info] [phantom] Step 2/3 https://mon-application:8080/login/ (HTTP 200)
Log in
PASS Page title is: "Sign in"
PASS Selector is not visible
[info] [remote] attempting to fetch form element from selector: 'form#loginForm'
[debug] [remote] Set "j_username" field value to romain.linsolas
[debug] [remote] Set "j_password" field value to
[debug] [phantom] Mouse event 'click' on selector: form#loginForm input.button
PASS Selector is visible
[info] [remote] attempting to fetch form element from selector: 'form#loginForm'
[debug] [remote] Set "j_username" field value to romain.linsolas
[debug] [remote] Set "j_password" field value to ******
[debug] [phantom] Mouse event 'click' on selector: form#loginForm input.button
[info] [phantom] Step 2/3: done in 1099ms.
[debug] [phantom] Navigation requested: url=https://mon-application:8080/logincheck;jsessionid=0A26317CDA05D97D63D6538EE4212B07, type=FormSubmitted, lock=true, isMainFrame=true
[debug] [phantom] Navigation requested: url=https://mon-application:8080/, type=FormSubmitted, lock=true, isMainFrame=true
[debug] [phantom] url changed to "https://mon-application:8080/"
[debug] [phantom] Successfully injected Casper client-side utilities
[info] [phantom] Step 3/3 https://mon-application:8080/ (HTTP 200)
PASS Page title is: "Hello World"
[debug] [phantom] Mouse event 'click' on selector: xpath selector: //*[text()="Administration"]
[debug] [phantom] Navigation requested: url=https://mon-application:8080/domain/account/index, type=LinkClicked, lock=true, isMainFrame=true
[info] [phantom] Step 3/3: done in 1389ms.
[debug] [phantom] url changed to "https://mon-application:8080/domain/account/index"
[debug] [phantom] Successfully injected Casper client-side utilities
[info] [phantom] Done 3 steps in 1749ms

Voilà qui est génial, CasperJS gère nativement le CoffeeScript sans avoir besoin de l’installer séparément. Mais on va quand même procéder à son installation, comme ça on disposera d’un compilateur CoffeeScript.

La première étape, c’est l’installation de NodeJS. Les choses se font assez simplement, il y a un .msi à télécharger. Il me faudra juste ajouter le chemin d’installation de NodeJS dans mon PATH :

1
2
3
4

D:\dev>node -v
v0.10.3
D:\dev>npm -v
1.2.17

Maintenant, installons CoffeeScript grâce à la commande npm install -g coffee-script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

D:\dev\nodejs>npm install -g coffee-script
npm http GET https://registry.npmjs.org/coffee-script
npm http GET https://registry.npmjs.org/coffee-script
npm http GET https://registry.npmjs.org/coffee-script
npm ERR! Error: getaddrinfo ENOTFOUND
npm ERR!     at errnoException (dns.js:37:11)
npm ERR!     at Object.onanswer [as oncomplete] (dns.js:124:16)
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>
npm ERR! System Windows_NT 6.1.7601
npm ERR! command "D:\\dev\\nodejs\\\\node.exe" "D:\\dev\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "-g" "coffee-script"
npm ERR! cwd D:\dev\nodejs
npm ERR! node -v v0.10.3
npm ERR! npm -v 1.2.17
npm ERR! syscall getaddrinfo
npm ERR! code ENOTFOUND
npm ERR! errno ENOTFOUND
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     D:\dev\nodejs\npm-debug.log
npm ERR! not ok code 0

Comme les choses ne sont pas simples chez moi, je suis derrière un proxy :) Il faut donc donner les informations de connexion à npm pour se connecter à Internet. Cela se fait dans le fichier <répertoire home>\.npmrc (par exemple C:\Users\chuck.norris\.npmrc). Dans ce fichier, on définit l’adresse des proxies ainsi que le registre npm :

1
2
3

proxy = http://[user]:[mot de passe]@[url proxy]:[port]/
https-proxy = http://[user]:[mot de passe]@[url proxy]:[port]/
registry = http://registry.npmjs.org

On relance la même commande, et cette fois-ci ça marche mieux :

1
2
3
4
5
6
7
8

D:\dev\nodejs>npm install -g coffee-script
npm http GET http://registry.npmjs.org/coffee-script
npm http 200 http://registry.npmjs.org/coffee-script
npm http GET http://registry.npmjs.org/coffee-script/-/coffee-script-1.6.2.tgz
npm http 200 http://registry.npmjs.org/coffee-script/-/coffee-script-1.6.2.tgz
C:\Users\chuck.norris\AppData\Roaming\npm\cake -> C:\Users\chuck.norris\AppData\Roaming\npm\node_modules\coffee-script\bin\cake
C:\Users\chuck.norris\AppData\Roaming\npm\coffee -> C:\Users\chuck.norris\AppData\Roaming\npm\node_modules\coffee-script\bin\coffee
coffee-script@1.6.2 C:\Users\chuck.norris\AppData\Roaming\npm\node_modules\coffee-script

Cool ! Voyons maintenant s’il est possible de lancer la commande coffee :

1
2

D:\dev>coffee -v
CoffeeScript version 1.6.2

Houra !

Intégration au build

Dernière étape de ce petit tutoriel : comment allons-nous faire pour exécuter automatiquement les tests CoffeeScript, pour les intégrer par exemple dans notre build continu sur Jenkins ? On pourrait effectivement ajouter une étape dans la configuration Jenkins qui irait lancer un script, mais ce n’est pas très propre.

J’ai trouvé quelques plugins Maven, mais rien de folichon. J’ai donc décidé d’en créer un moi-même, mais il n’est pas encore stabilisé.

En attendant, je vais passer par un test JUnit, qui aura pour tâche de lister les *.js et *.coffee d’un répertoire donné. C’est une version très simple, elle ne gère que les cas standards (j’essaierais de faire les choses plus proprement dans mon plugin Maven). Elle ne supporte pas non plus les options de la commande casperjs (comme par exemple les --pre ou --post), mais c’est un premier pas et surtout, ça marche :)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

package fr.linsolas.javascript.casperjs;

import org.apache.commons.exec.CommandLine;
import org.apache.commons.exec.DefaultExecutor;
import org.apache.commons.lang.StringUtils;
import org.junit.BeforeClass;
import org.junit.Test;

import java.io.File;
import java.io.FilenameFilter;
import java.io.IOException;

import static org.fest.assertions.Assertions.assertThat;

/**
 * Run CasperJS on any *.js or *.coffee files found in a specific folder.
 * @author Romain Linsolas
 */
public class RunCasperJSTest {

    private static boolean casperFound = false;
    private static final String CASPER_JS = "casperjs.bat %s";
    private static final String TESTS_DIR = "D:\\dev\\mon-application\\src\\test\\javascript\\casperjs";

    @BeforeClass
    public static void checkEnvironment() {
        // Vérification que l'on a bien CasperJS installé.
        int res = execute(CASPER_JS, "--version");
        assertThat(res).isNotEqualTo(-1);
        casperFound = true;
    }

    @Test
    public void runJavaScriptTests() {
        File[] files = new File(TESTS_DIR).listFiles(new FilenameFilter() {
            @Override
            public boolean accept(File dir, String name) {
                return StringUtils.endsWithIgnoreCase(name, ".js");
            }
        });
        runTests(files);
    }

    @Test
    public void runCoffeeScriptTests() {
        File[] files = new File(TESTS_DIR).listFiles(new FilenameFilter() {
            @Override
            public boolean accept(File dir, String name) {
                return StringUtils.endsWithIgnoreCase(name, ".coffee");
            }
        });
        runTests(files);
    }

    private void runTests(File[] files) {
        assertThat(casperFound).isTrue();
        int ok = 0;
        int ko = 0;
        for (File f : files) {
            int res = execute(CASPER_JS, f.getAbsolutePath());
            if (res == 0) { ok++; } else { ko++; }
        }
        System.out.println("Results: " + ok + " test(s) successful, " + ko + " test(s) failed. Total of " + (ok + ko) + " test(s).");
        assertThat(ko).isEqualTo(0);
    }


    private static int execute(String command, Object... arguments) {
        DefaultExecutor exec = new DefaultExecutor();
        CommandLine line = CommandLine.parse(String.format(command, arguments));
        try {
            return exec.execute(line);
        } catch (IOException e) {
            return -1;
        }
    }

}

Logo Windows^>TM par YOOTheme, image de coeur par David Vignoni

Dernier billet sur la conférence Devoxx France 2013 (ouf !). Je vais parler de notre session, Du JavaScript propre ? Challenge Accepted!, présentée avec Julien Jakubowski d’OCTO.

Alors pour la petite histoire, il faut savoir que Julien et moi ne nous connaissions pas personnellement un mois et demi avant Devoxx ! Nous avions tous les deux proposé une conférence durant le CFP (Call For Paper) très similaire. De son côté, Julien avait proposé une version améliorée de sa présentation Le JavaScript ce n’est pas si sale qu’il avait faite au Ch’ti JUG dont il est le fondateur. De mon côté, j’avais proposé à peu près la même chose, mais dont le but était plutôt de faire un état des lieux de l’écosystème autour de JavaScript en 2013, et montrer que celui-ci est extrêmement riche, presque à l’image de celui du monde Java. Le comité de direction, ne sachant qui choisir, nous a demandé s’il était possible de mixer nos présentations. Ce qui fut fait. On est donc parti de la présentation de Julien, puis on l’a améliorée, suite à nos nombreuses discussions. Je pense également que le fait de la présenter à deux la rend plus vivante, plus intéressante.

Le contenu

La session se divise en deux parties :

• Les problèmes courants en JavaScript.
• Les solutions que l’on propose pour coder proprement en JavaScript.

Les problèmes

Tout d’abord, nous expliquons pourquoi nous faisons cette présentation. Le constat est double :

• JavaScript est partout, et les sites sont de plus en plus riches en partie grâce à lui. On ne peut donc pas l’ignorer, surtout avec l’avénement du HTML5.
• JavaScript a une mauvaise réputation. Le langage est sale, plus adapté à la bidouille sur sa page HTML que pour faire de vraies applications, difficulté de trouver un bon environnement de travail.

Bref, il y a du boulot pour redorer le blason de JavaScript. Après une petite partie ludique, où l’on montre quelques résultats étonnants de JavaScript (je vous conseille fortement de regarder cette vidéo), on passe aux vrais problèmes que l’on est susceptible de rencontrer dans ses projets :

• Pollution de l’espace de nommage. Quand on définit des fonctions dans les fichiers JavaScript sans prendre garde, il se peut qu’il y ait des collisions entre plusieurs fonctions ayant le même nom. Par exemple, si l’on définit une méthode checkForm() dans un fichier JS, rien ne dit que nous n’aurons pas une méthode au même nom dans un autre fichier. Dans pareille situation, JS ne considère que la dernière méthode définie, et cela peut poser des problèmes.
• Le scope global par défaut. Par défaut, les variables ont un scope global, et cela peut aussi entrainer des problèmes. Dans le code suivant, la variable i sera la même dans les 2 boucles, ce qui fait que nous n’applerons le logger que 10 fois et non 100 fois comme attendu :

1
2
3
4
5
6
7
8
9

function subLoop() {
  for (i = 0; i < 10; i++) {
      console.log(i);
  }
}

for (var i = 0; i < 10; i++) {
  subLoop();
}

• Tout est public par défaut. Difficile de cacher certains détails de son implémentation, le mot clé private n’existant pas en JS. Dans le code suivant, la variable censée être privée ne l’est pas du tout :

1
2
3
4
5
6
7
8
9
10
11

var counter = {
  privateValue: 0,
  increment: function() {
      counter.privateValue++;
      return counter.privateValue;
  }
}

counter.increment(); // 1
counter.privateValue = 0; // Aie
counter.increment(); // 1

• Code non testé. Tout est dit :)

Assez parlé des problèmes, voyons les solutions !

Les solutions

Première idée : on pourrait simplement déléguer le code JavaScript à son framework préféré (GWT, JSF, etc.) Nous ne souhaitons pas aller dans cette direction. Faisons du JavaScript ! Autre idée, pour au moins limiter les dégâts : utiliser Google Dart ou CoffeeScript qui permettent une écriture plus fluide, plus sécurisée du code JavaScript.

D’un point de vue architectural, donc assez haut niveau, il existe aujourd’hui une tendance à ne pas négliger : les architectures MVC/MVW/MV* côté client. Autrement dit, plutôt que d’avoir un serveur qui va s’occuper de toute la partie fonctionnelle (couches modèle, contrôleur et vue), on va déporter tout ou partie de ceci côté client. Pour se faire, on se fera aider de solutions telles que Backbone.js, Ember ou le très à la mode AngularJS. Ce type d’architecture offre d’autres avantages : comme le code est exécuté côté client, le temps de réponse est instantané, on transfère beaucoup moins d’informations entre le client et le serveur (ce qui privilégie les réseaux mobiles), et offre plus facilement un mode déconnecté à son application. Mais ce n’est pas magique, il faudra faire attention à d’autres points, en particulier l’aspect sécurité (bah oui, tout le code est sur le client, donc il lui est plus facile de le comprendre et de le contourner).

On a cité, parmi les problèmes, le fait que tout est public par défaut. Pour le résoudre, on propose d’opter pour la modularité. Cela revient un peu à simuler une classe en Java (attention, ce n’est pas exactement ça, c’est juste pour faire comprendre l’idée), en n’exposant à l’extérieur que ce que l’on souhaite (une sorte d’interface). Le code de notre compteur devient au final quelque chose comme ça :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Notre counter sera notre objet utilisé par la suite.
var counter = (function() {
  var privateValue = 0;
  var publicMethod = function() {
      privateValue++;
      return privateValue;
  };
  // On retourne un objet qui contient une méthode "increment", seul élément qui sera visible de l'extérieur.
  return {
      increment: publicMethod
  };
})();

// On passe à l'utilisation du compteur :
counter.increment();  // 1
counter.privateValue; // undefined
counter.privateValue = 0; // Cela ne pose pas de problème. JS va ajouter une propriété "privateValue" à l'objet "counter", mais elle sera différente du "privateValue" que nous utilisons dans notre implémentation. Pas de conflit du coup !
counter.increment();  // 2

Pour accroitre encore la lisibilité et la propreté de son code, on pourra créer des sortes de packages pour nos modules :

1
2
3
4
5
6
7
8
9
10
11
12

var myapp = {
  subpackage: {

      counter: (function() {
          // ...
      })()

  }
}

// Et son utilisation :
myapp.subpackage.counter.increment(); // 1

On aborde ensuite la question du chargement des librairies JS. Plutôt que d’avoir 15 fichiers JS chargés au chargement de la page (chargement séquentiel, qui plus est, ce qui ralentit d’autant le chargement), on va utiliser les principes de l’AMD (Asynchronous Modules Definition), par exemple grâce à la librairie require.js. Cela apporte en particulier deux avantages :

• Chargement asynchrone et/ou en parallèle, et donc cela ne bloque pas le chargement des pages, qui se fait normalement de façon séquentielle.
• Chargement à la demande. Certaines fonctionnalités de la page peuvent ne pas être utilisées. Alors autant ne pas charger les ressources liées. On pourra ainsi dire “quand l’utilisateur souhaite faire ceci, alors on chargera à ce moment-là les librairies X et Y”.
• Définition des dépendances. Un peu comme dans le point précédent, on pourra indiquer que la librairie X dépend de Y, et donc on chargera Y avant X.

Intéressons-nous au code en lui-même maintenant. Il existe des outils pour s’assurer que nous n’écrivons pas (trop) de bêtises dans notre code JavaScript, un peu comme le fait Checkstyle ou PMD en Java. Nous avons ainsi JsLint ou JsHint pour remplir cette tâche. On tâchera aussi d’écrire un code plus expressif, c’est-à-dire plus simple, plus lisible, plus concis. J’aime l’expression qui dit qu’il faut écrire le code comme si la personne qui va le maintenir est un psychopathe qui connait mon adresse, ça traduit bien l’intérêt d’écrire correctement son code.

Un vieux code tel que celui-ci :

1
2
3
4
5
6
7
8
9

function checkForm() {
  var beerName = document.getElementById("beer_name").value;
  if (beerName === '') {
      document.getElementById("beer_name").className += "invalid";
      document.getElementById("error_box").style.display = "block";
      return false;
  }
  return true;
}

pourra être refactoré avec jQuery de cette façon, rendant le code plus lisible, plus facile à maintenir :

1
2
3
4
5
6
7
8

$('#beerForm').submit(function() {
  if ($('#beer_name').val() === "") {
      $('#beer_name').addClass('invalid');
      $('#error_box').show();
      return false;
  }
  return true;
});

Autre chose pour simplifier l’écriture : utiliser des moteurs de templating, tels que Mustache.js ou Handlebars.js, qui permettent d’insérer des données dans du HTML de façon fluide. Ainsi, si beers est un tableau de bières (au format JSON), on pourra écrire ceci :

1
2
3
4
5
6
7
8
9
10

<ul id="beers-list">
  {{#beers}}
      <li>{{name}} - {{color}} - {{alcohol}}%</li>
  {{/beers}}
</ul>
<script type="text/javascript">
  var template = $('#beers-list');
  // Appel du moteur de rendu de Mustache
  template.html( Mustache.render(template.html(), data) );
</script>

Autre sujet important, les tests. Nous n’allons pas dans le détail, mais nous expliquons qu’il existe de nombreux outils pour cela : Jasmine, QUnit, Mocha, CapserJS, PhantomJS, Karma, etc. Je vous renvoie à l’université de Jean-Laurent de Morlhon et Pierre Gayvallet à ce sujet.

Le message est clair : tous les outils sont là pour faire des tests, du TDD, du BDD, des tests d’intégration, etc. Bref, on n’a plus d’excuses !

Dernier point abordé : l’automatisation. On peut facilement intégrer son application JavaScript dans un serveur d’intégration continue comme Jenkins ou un outil d’analyse qualité tel que Sonar. Je vous renvoie à mon Tools In Action de l’année dernière pour voir tout ça en pratique. Niveau IDE, nous recommandons IntelliJ IDEA de JetBrains (ou WebStorm) qui offre un vrai support des langages web comme le JavaScript, le HTML ou le CSS.

La présentation à Devoxx France

Voilà un retour personnel sur la présentation elle-même. Déjà, on était très content avec Julien, car la salle était pleine, ce qui fait 300 personnes à nous écouter (sans compter les millions qui nous verront sur Parleys). Si si, j’avais compté les chaises pendant que la salle était vide ! :o)

On a plutôt bien géré notre temps, on a fini un peu en avance même - environ 8 minutes avant - ce qui nous a permis de prendre près d’une dizaine de questions. Les retours que j’ai eu en direct ou sur le Net semblent montrer que la présentation a été appréciée, et c’est ce qui nous rend encore plus heureux (un exemple ici).

Une chose toutefois, que l’on fera peut-être si notre présentation est prise sur une autre conférence. Il semblerait, d’après les questions, que certaines personnes s’attendaient à avoir un peu la stack idéale pour développer en JavaScript. Tout d’abord, elle n’existe pas. Choisir un framework JavaScript va dépendre de vos besoins, mais aussi de votre maitrise du langage, et du risque que vous acceptez de courrir par rapport à la pérénnité de tel ou tel outil. Je ne conseillerais pas AngularJS ou Backbone.js sans connaitre le contexte. Partir sur une application exécutée côté clent, cela a un impact à plus ou moins long terme, et faire ce choix n’est pas anodin.

L’un des points sur lequel il faut faire attention, c’est l’intégration des outils entre eux. Il n’est pas toujours évident de faire fonctionner X avec Y. Aussi, peut-être proposerons-nous dans une version améliorée de la présentation deux ou trois stacks qui fonctionnent bien ensemble.

Références

• Les slides sur Slideshare ici ou là.
• Les slides et bientôt la vidéo sur Parleys.

L’édition française de Devoxx 2013 s’est donc achevée la semaine dernière. A nouveau, un énorme BRAVO à toute l’équipe organisatrice, aux sponsors, aux speakers, aux participants. C’était magique. Devoxx, c’est un peu le Disneyland du développeur geek. On y voit des “stars” (pas dans le mauvais sens du terme) et on s’amuse énormément.

Allez, un petit bilan personnel :

Les plus

• Les gens.
• L’organisation, toujours au poil.
• L’équipe des organisateurs, toujours gentils et disponibles.
• Les rencontres, surtout voir en vrai des personnes que l’on ne connait que via Twitter.
• Les présentations de qualité, plutôt variées et nombreuses.
• Les gens.
• Certains goodies. Personnellement, j’en ai un peu marre des t-shirts (sauf celui d’Atlassian qui est au top, et que je portais durant ma présentation) et des mugs. Certains sponsors innovent plus que d’autres en la matière : boite à Meuh d’OCTO, décapsuleurs, gants, etc.
• Les concours, bien que je n’ai rien gagné !
• Le site de Parleys qui diffuse toutes les sessions que l’on a dû rater parce que parfois c’était dur de choisir, ou que l’on discutait avec des personnes. En plus, le site a été refait en HTML 5 !
• Le diner des speakers.
• La soirée ”Meet & greet”.
• Les gens.

Les moins

• Pas assez de Hands On le mercredi. Comme je l’ai dit, j’aimerais beaucoup que Devoxx France 2014 se déroule en quatre jours : 2 jours d’universités et Labs avec une attention particulière pour les sessions où l’auditoire code vraiment, et 2 jours de conférences.
• Le Marriott devient trop petit. L’année passée, avec un peu plus de 1200 personnes, on se sentait à l’étroit. Cette année, avec 1400 et quelques participants, c’était encore plus vrai. De nombreuses personnes se sont faites recaler à l’entrée des salles de conférences pleines pour des raisons de sécurité. Cela se comprend, mais c’est rageant. Le problème est de trouver un lieu ayant une capacité d’accueil d’au moins 1500 personnes à Paris pour un budget raisonnable. Difficile à mon avis !
• La nourriture le midi. Sans être mauvaise, ce n’était quand même pas ça, et ça manquait un peu de variété. En plus, sauf erreur de ma part, il n’y avait pas de desserts le midi. A noter que cette année, contrairement à 2012, les boissons étaient toujours à disposition et ça c’est bien (petit bémol : pas de Coca light, que du Coca “normal” :o) ).
• Toujours pas de NAO à gagner :)
• Faute de place, les BOF sont toujours un peu tard le soir (certains finissent à 22h). Guère pratique quand on a déjà 2 jours de Devoxx dans les pates !

Voilà, hormis le problème du lieu qui devient trop petit, rien de méchant. Devoxx confirme qu’il s’agit d’une superbe conférence, et encore une fois, j’étais très fier d’y assister, surtout en tant que speaker ! A l’année prochaine (et en fin d’année pour la version World à Anvers) !

Aie, déjà le dernier jour de la conférence Devoxx France. Que le temps passe vite ! Cette dernière journée reste toutefois très intense, en particulier parce qu’à 10h40, c’était ma présentation ”Du JavaScript propre ? Challenge Accepted!” avec Julien Jakubowski. Je ferais un billet dédié à cette présentation.

Web oriented architecture, une transmutation des pratiques de construction des SI

J’avais raté les keynotes du jeudi, je me suis dit qu’il serait dommage d’en faire autant le vendredi. Bon, j’ai raté une partie de la première keynote, celle d’Alexis Moussine-Pouchkine, ”Normal ou décafeiné”. En gros, le message de sa keynote est que l’avenir, en particulier le Cloud, peut - et doit - se faire avec Java.

Passons à la deuxième keynote, celle de Habib Guergachi, CEO de Zenexity. Je voulais la voir car il l’avait déjà jouée l’année passée sous forme de conférence, et j’avais entendu d’excellents retours. Au delà du message, c’est vraiment le bonhomme qui impressionne. Il avait une telle énergie que cela en devenait contagieux. Rien de mieux pour bien démarrer une journée intense !

Revenons au message lui-même. Il est un peu polémique, mais je crois qu’il n’a pas complètement tort sur un certain nombre de choses.

Quand il s’agit de faire un choix important, il y a deux solutions possibles. On peut opter et pousser le changement, au risque d’innover. Certes, il y a le risque de se faire virer, mais ce sera dans la gloire :) L’autre chemin, c’est la soumission, et ne pas bousculer les choses établies. On ne risque pas de se faire virer à court terme, mais peut-être que dans 2 ans, on vous reprochera de ne pas avoir sû anticiper le changement, et vous vous ferez virer dans la honte !

Ok, c’est une vision un peu simpliste, mais y a un soupçon de vérité là-dedans quand même.

Habib, au cours de sa présentation, parle de Play. Bien entendu, il prêche pour sa paroisse, Zenexity est l’éditeur du framework. Il s’agit d’une innovation française. Pourtant, au début c’était plutôt un défaut, que ce soit pour les français (qui ne jurent que par des produits américains) ou par les américains eux-mêmes. Utiliser une technologie française c’est un peu comme voler dans un avion congolais : ça ne rassure pas vraiment ! Pourtant, Play! a été adopté par de grands noms (surtout américains), comme LinkedIn, Typesafe, etc. Dès lors, tout le monde, y compris les français, encense le framework.

On ne peut pas tout comprendre, il faut savoir se concentrer sur un problème précis, un petit bout d’une architecture entière. Et si l’on se jette à l’eau, que l’on prend le problème à bras le corps, peut-être que l’on sera la personne qui a vraiment sû comprendre et aborder ce problème, et que la solution que l’on proposera deviendra la solution que tout le mondre utilisera. Mais pour cela, il faut se lancer !

Pour résumer, la keynote de Habib Guergachi était pleine de panache, et donne à réflechir. Rien de mieux pour continuer la journée, surtout que la présentation suivante est celle de Julien Jakubowski et… moi-même. J’y reviendrais très vite.

Animez vos pages HTML5: un tour d’horizon complet des techniques d’animation en HTML5

Martin Gorner (@martingorner) de Google nous parle d’animation en HTML5. Sa présentation est visible en live sur ce site.

En CSS 3, transition permet d’animer des éléments. Le navigateur va calculer lui-même toutes les étapes intermédiaires. La propriété animation permet de faire des animations plus complexes, en définissant les propriétés CSS à appliquer à différentes étapes. Le CSS 3 dispose également de transformations géométriques 2D (rotation, agrandissement, étirement, etc.). Il y a également des transformations 3D : translateZ, rotateY, etc. A noter qu’il faut définir soi même la perspective via une propriété CSS : -webkit-perspective: 1000px;. Par défaut, la valeur par défaut est -webkit-tansform-style: flat. Ce n’est pas ce que l’on souhaite, il faut donc la mettre à preserve-3d. Attention, Internet Explorer 10 ne gère pas cette propriété (mais on peut bidouiller avec du JavaScript pour remplir cette lacune).

Les bonnes habitudes pour travailler en 3D :

• Créer un div qui représente la scène.
• Créer un objet qui supportera l’animation.
• Y affecter des images.
• Définir les propriétés d’animation.

Après avoir passé en revue l’utilisation des Canvas 2D, Martin aborde le Canvas 3D, connu aussi sous le nom de WebGL. Après quelques explications, Martin propose d’aborder la partie pratique à l’aide de la librairie Three.js, qui permet de coder dans le moteur WebGL en JavaScript : définition de la scène, création d’une “caméra”, des “lumières”. Ensuite on peut ajouter des objets (des Meshs). Enfin, on définit les actions. Voici un exemple de code avec cette librairie :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

var camera, scene, renderer;
var geometry, material, mesh;

init();
animate();

function init() {
    camera = new THREE.PerspectiveCamera( 75, window.innerWidth / window.innerHeight, 1, 10000 );
    camera.position.z = 1000;
    scene = new THREE.Scene();
    geometry = new THREE.CubeGeometry( 200, 200, 200 );
    material = new THREE.MeshBasicMaterial( { color: 0xff0000, wireframe: true } );
    mesh = new THREE.Mesh( geometry, material );
    scene.add( mesh );
    renderer = new THREE.CanvasRenderer();
    renderer.setSize( window.innerWidth, window.innerHeight );
    document.body.appendChild( renderer.domElement );
}

function animate() {
    // note: three.js includes requestAnimationFrame shim
    requestAnimationFrame( animate );
    mesh.rotation.x += 0.01;
    mesh.rotation.y += 0.02;
    renderer.render( scene, camera );
}

Three.js gère également des modèles d’objets 3D (via la spécification Collada par exemple).

Un point sur les préfixes (ici -webkit-*) : il y a une “convention”. Tant qu’une spécification n’est pas officielle, les navigateurs utilisent des préfixes. Une fois la spécification entérinée, alors le préfixe peut disparaître. On peut sinon utiliser des outils tels que prefixfree.js ou SASS qui vont s’occuper d’ajouter les préfixes pour nous.

Peut on toujours être développeur après 40 ans ?

Benjamin Marron (@bmarron) nous explique s’il est possible

Être boucher à 40 ans ? Artisan à 40 ans ? La question ne se pose pas tant elle est évidente. Pourtant, pour un développeur, la question se pose. Y a-t-il une obscolescence des développeur ? Si la personne est concernée, se forme, alors non. Mais sans ces efforts, cela risque d’arriver. Et direction chef de projet :)

Grâce à leur expérience, les développeurs expérimentés savent mieux filtrer les informations, choisir les outils ou les librairies.

Alors la question est peut-être de savoir si nous sommes usés ? Il ne faut pas rester dans sa zone de confort. Les conférences comme Devoxx permettent de se gonfler à bloc, le leitmotiv c’est ”soyez fiers d’être développeurs”

Quid du choc générationnel ? Comme travailler avec des “petits jeunes” de 20 ans ? Il faut rester humble, dire que l’on a toujours à apprendre.

Il y a aussi le problème de disponibilité, avec la vie de famille, les enfants, etc. Mais cela reste jouable, et le fait de ne pas être toujours 100% disponible pour son travail n’est pas un frein.

Le message de Benjamin Marron est que la passion doit nous faire continuer dans cette voie, et que nous avons les moyens d’y parvenir. Un sujet n’a pas été vraiment abordé, si ce n’est lors des questions du public : la reconnaissance de l’expérience par l’employeur. Il est vrai qu’en France, niveau salaire, on a tendance à stagner assez vite (disons à partir d’une dizaine d’années d’expérience), et continuer sa progression n’est pas toujours facile. Ca reste compliqué aujourd’hui, mais les choses semblent changer. Doucement en tout cas.

Winter is coming

Je finis (ou presque) ma journée avec la présentation de Didier Girard et Aurélien Pelletier de SFEIR. J’avoue que j’ai un peu du mal à savoir quoi tirer de cette présentation, tant le message n’était pas très clair. L’idée, du moins une partie de ce qui a été dit, c’est de savoir comment juger de la pertinence d’un framework, d’une librairie, et de savoir estimer son espérance de vie, dans un monde très concurrentiel.

Didier Girard décide donc d’utiliser Google Trends pour juger de la popularité d’un framework. Cet outil de Google permet de mesurer, et comparer, le nombre de fois où tel ou tel mot est recherché sur Google. Plutôt que simplement comparer deux noms de technologies via le site de Google, il décide d’y ajouter le terme tutorial, supposant que plus on recherche de tutoriels sur une technologie, plus celle-ci intéresse les gens, et sera facile à maitriser. Bien sûr, Didier Girard insiste sur le fait que cela doit aider à se faire une opinion, mais que cela ne saurait suffire. Pourtant, il n’ira guère plus loin dans sa démonstration, ce qui est un peu contradictoire au final. Dommage.

Pour résumer, on va dire que ce n’est pas forcément la présentation que j’ai préféré à Devoxx :)

Les CastCodeurs, putain 4 ans déjà

Ca devient une tradition, finir un Devoxx avec une session live des Cast Codeurs. A vrai dire, je ne vois aucune raison de ne pas y assister : récapitulatif de la conférence, bonne ambiance, bonnes blagues (quoique ?) et bières offertes par Atlassian ! Rien de mieux pour terminer en beauté une magnifique conférence. Allez écouter le podcast, bientôt disponible. En attendant, il y a les podcasts de Devoxx 2011, Devoxx France 2012, et enfin Devoxx 2012.

A l’année prochaine !