2012 est une année très Devoxx pour moi : participation au Devoxx France pour sa première édition, et première participation pour moi au “Devoxx World”, pour sa 11e édition. Et pour courronner le tout, je suis orateur les 2 fois.

Si Devoxx World se déroule sur 5 jours, je ne suis présent qu’aux 3 derniers, journées des conférences, Quickies et autres BOF. Mercredi matin, 6h. Les choses ne commencent pas bien. Une grève en Belgique (eh oui, ce n’est pas une spécificité française :) ) rend les choses plus compliquées que prévu et notre train, après avoir été retardé puis annulé, fini par partir quand même. Je passe toutefois un très bon moment dans le Thalys à parler avec David Pilato, directeur technique d’Ideo Technologies. Bref, nous arrivons finalement au Metropolis vers 11h30, ce qui nous a fait raté la Keynote. La principale annonce, c’est que la famille Devoxx s’agrandit ! En 2011, il y avait 1 Devoxx, à Anvers. 2012 a vu l’arrivée de Devoxx France en avril. 2013 sera donc l’année de la première session de Devoxx UK, qui se tiendra les 26 et 27 mars prochains, suivi par Devoxx France, qui se tiendra au même lieu et au même format (3 jours) qu’en 2012. Le mercredi 27 mars sera le dernier jour de Devoxx UK, mais aussi le premier de Devoxx France. Les organisateurs espèrent ainsi attirer à Paris des speakers américains, qui en profiteraient pour participer aux deux conférences. Espérons ainsi que les speakers de Google viendront présenter AngularJS à Devoxx France. Je reviendrais sur ce sujet plus tard…

En attendant, voyons les conférences auxquelles j’ai assisté pour ce premier jour de Devoxx…

7 things: How to make good teams great

Sven Peters, d’Atlassian, nous donne 7 conseils pour qu’une bonne équipe devienne une excellente équipe. Pour chaque conseil, il donne également une note sur 5 pour la faisabilité, ainsi qu’une autre sur l’awesomeness.

1. Flowtime : généralement, on dit que le bureau individuel est plus adapté à la performance, car on est ainsi moins sujet aux perturbations des autres personnes, qui nous dérange à tout moment. Pourtant, chez Atlassian, c’est bel et bien l’open space qui a été privilégié. Et ça marche. Il suffit d’y inclure quelques règles. Par exemple, durant les premières heures de l’après-midi, interdiction de déranger les gens. Si on a besoin d’aide sur un problème précis, alors une personne dédiée est chargée d’y répondre. Bien entendu, cette personne n’est jamais la même ! Note: 4/5 et 2/5.

2. Feed your brain : le développement informatique a cette particularité qu’il est nécessaire d’apprendre en permanence. Certes, on peut apprendre par soi-même, mais c’est quand même plus fun de le faire à plusieurs. Sven propose quelques idées à mettre en place durant ses pauses déjeuner : session de codage, histoire d’utiliser un nouveau langage, un nouveau framework, ou simplement apprendre à gérer telle ou telle situation. Le ”Brown Bag Lunch” est aussi une idée intéressante, où les gens apportent à manger pour suivre une petite session présentée par quelqu’un. D’ailleurs David Gageot se propose de le faire chez vous ! Dernière idée : pourquoi ne pas regarder une conférence sur Parleys pendant l’heure du déjeuner ? Cela permettra peut-être aussi de faire connaître Devoxx à vos collègues ! Note: 5/5 et 2/5.

3. Say “well done” : savoir qu’on fait du bon boulot, c’est bien. Que d’autres nous le disent, c’est encore mieux. Il faut savoir (ré)apprendre à féliciter les gens pour leurs réalisations, mais il faut que cela se fasse facilement (nul besoin de faire une soirée pour fêter le million de revenu, ou ce genre de chose un peu pompeux et assez froid), n’importe quand, et par n’importe qui. Note: 2/5 et 3/5.

4. Report robot : les données, on en a plein, de toutes sortes. Il faut savoir les agréger, mais aussi les analyser, en faire des rapports pertinents (tant qu’à faire dynamiques) et les rendre aussi facilement accessibles que possible. On rejoint ici les idées d’Extreme Feedback, où un écran va afficher par exemple l’état des builds dans l’usine logicielle, où encore le traffic en live de son site web. Note: 2/5 et 4/5.

5. Eat your own dog food : quoi de mieux que de tester soi-même son application pour en connaître les forces et les faiblesses ? Être soi même les alpha-testeurs, il n’y a rien de mieux. Et tant qu’à faire, autant le faire tester par tout le monde : les développeurs, les chefs, les secretaires, etc. Bien entendu, la faisabilité d’une telle approche n’est pas toujours facile, selon le type de produits sur lesquels on travaille. C’est sans doute plus facile pour Atlassian, qui développe des outils utilisés - en partie - par des développeurs. Le contexte se prête donc parfaitement ici, ce qui n’est pas toujours le cas. Note: 2/5 et 5/5.

6. Do a special day : il est évident que pour un développeur, écrire de la documentation, ce n’est pas sa tasse de thé (enfin, son mug de café dirais-je plutôt). Toutefois, on pourrait organiser des journées spéciales (ou des demi-journées, selon le thème) dédiées à une thématique donnée. Pour que cela marche, il faut bien entendu préparer le terrain, favoriser l’environnement à la tâche donnée. Pour reprendre l’idée de la journée dédiée à l’écriture de la documentation, on peut regrouper l’équipe dans une salle ou un open-space, donner des rôles de relecteurs, etc. pour améliorer l’efficacité de l’équipe. Il y a bien entendu d’autres thématiques envisageables, comme le ”Focus on one task”, ”Blitz Testing”, ”Clean up day”, etc. Note: 5/5 et 3/5.

7. Experimentation time : le fameux ”20% time”, popularisé en son temps par Google. Le principe : laisser au développeur 20% de son temps à des sujets libres, pour développer ce qu’il veut, apprendre une nouvelle technologie, etc. On peut aussi imaginer laisser ce temps pour développer des fonctionnalités dont on a envie de voir sur l’application, ce qui profite à la fois au projet et au développeur. Toutefois, c’est souvent un principe difficile à mettre en place au sein d’une société, et souvent ce temps imparti est loin d’atteindre les 20%, à cause de différents types de conflits… Note: 2-4/5 et 5/5.

Voilà quelques conseils de bon sens, et comme le dit Sven, il faut essayer! Certes des fois on échouera, mais il ne faut pas être idiot, et anticiper tant que possible ces situations. Bref, be different.

A noter que sa présentation est disponible sur SlideShare.

The Future of Software Development Process Methodology Effectiveness

Chet Haase, de Google, est un orateur formidable. Cette session (ainsi que les autres sur Android), le prouve bien. Ce double-quickie a tellement eu de succès que les organisateurs lui ont demandé de le rejouer jeudi soir, en le filmant pour qu’il soit disponible sur Parleys. Durant son talk, il nous a présenté des “nouvelles” méthodologies de développement logicielles, basées sur des existantes. Difficile de retranscrire ici l’esprit de la session, mais en gros, voici quelques idées qu’il a présenté, ce qui devrait vous donner une idée du ton de son quickie :

• MDD pour Metrics Driven Development, qui dit que plus nous avons de données, de métriques, plus la qualité est au rendez-vous.
• SELF pour Somebody ELse’s Fault, où l’important est avant tout de se dédouaner (hélas, je crains que certaines personnes dans ma boite appliquent effectivement cette méthodologie).
• EBN pour Efficiency By Necessity, l’efficacité par la nécessité. Autrement dit, plus on place de meetings dans la journée d’un développeur, moins il aura de temps pour coder, et sera donc plus efficace sur ce temps-là !
• MBH, More Billable Hours. Le titre en dit long !
• L’Agile Development devient le Fragile Development, où il faut commiter le plus vite possible pour faire remonter les problèmes le plus rapidement possible.
• Et ainsi de suite…

Bref, une très bonne session, plein d’humour, de graphiques sans queue ni tête. Excellent !

Je passerais rapidement sur la session suivante à laquelle j’ai assisté, sur Java 8 et les closures. Le sujet a déjà été abordé plusieurs fois, le contenu n’était pas inintéressant, mais au bout de 50 slides de 20 lignes chacun, j’avais une certaine indigestion. Un conseil si vous voulez faire une présentation attractive : pensez Présentation Zen !

BDD on the JVM, a state of the Union

John Smart nous présente le BDD, Behavior Driven Development, et en particulier son intégration au sein de l’écosystème Java. La première partie est un rappel de ce qu’est le BDD, dont le but principal est l’écriture dans un langage commun à toutes les parties d’un projet (développeurs, analystes, testeurs, etc.) de spéfications exécutables. L’idée étant d’écrire un scénario en partant d’un contexte (Given), d’une action (When), on s’attend à un résultat précis (Then).

La seconde partie concernait les outils, en particulier :

• JBehave
• Cucumber
• EasyB
• Thucydides
• Spock qui utilise la syntaxe Groovy pour l’écriture des tests. Il s’agit toutefois là d’un outil plutôt destiné au BDD pour les développeurs.
• Spec2, ou le BDD pour Scala.
• Jasmine, dédié au langage JavaScript.

A vrai dire, les syntaxes des solutions de BDD pour Java sont très similaires. Voyons par exemple celle de Cucumber :

1
2
3
4
5
6
7
8
9
10

Feature:
In order to increase sales of advertised articles
As a Seller
I want buyers to be able to easily find ads for articles they want to buy

Scenario: Search by keyword and location

Given Sally wants to buy a "puppy" for her son
When she looks for "puppy" in the "Pets and animals" category
Then she should obtain a list of "puppy" ads

Ces scénarios sont écrits en anglais (voire même en français) avec de vraies phrases, et donc sont accessibles aussi à des non techniciens (par exemple, les analystes business pourront eux mêmes écrire ces tests). Derrière cela, des classes JUnit seront écrites pour “traduire” le langage Cucumber en Java, pour initialiser le contexte (Given), réaliser des actions (When) et les vérifications (Then).

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

public class SearchAdsSteps {
  
  @Steps
  BuyerSteps buyer;

  @Given("^Sally wants to buy a \"([^\"]*)\" for her son$")
  public void buyingAPresent(String present) {
      buyer.open_home_page();
  }

  @When("^she looks for \"([^\"]*)\" in the \"([^\"]*)\" category$")
  public void addSearchCategoryAndKeyword(String category, String keyword) {
      buyer.choose_category_and_keyword(category, keyword);
      buyer.perform_search();
  }

  @Then("she should obtain a list of \"([^\"]*)\" ads")
  public void shouldOnlySeeAdsContainingKeyword(String keyword) {
      buyer.should_only_see_results_with_titles_containing(keyword);
  }

}

Cucumber JVM dispose donc d’annotations propres aux mots clés des features (comme @When), qui prend en argument la phrase du test lui-même, sous forme d’expression régulière. On voit également que les éléments variables de ces phrases sont directement passés en paramètre à la méthode de test.

Bref, une bonne session pour se familiariser avec le BDD, ou de connaitre un peu mieux les outils.

Retrouvez les slides sur SlideShare

Code Story

Je m’accorde ensuite une petite pause, pour discuter avec quelques personnes, visiter les stands, et assister un peu à Code Story. Les 4 compères français réédite leur performances de Devoxx France, à savoir de coder en live une application. Cette fois-ci, ils ont développé une application de “combat”, disponible ici. Le principe : on rentre 2 mots clé (nom d’un speaker, d’une session, etc.), et l’application donne le résultat du combat. Ce score dépend - je crois - des votes que les internautes avaient préalablement donné sur les sessions. Le code final est sur GitHub. Encore une fois, une très belle session, mais hélas pas aussi populaire qu’à Devoxx France. Le fait qu’ils n’aient pas eu une salle à eux, et qu’ils soient situés dans le grand hall, un peu trop bruyant, n’a sans doute pas aidé. Un manque de publicité lors de la keynote a pu aussi jouer en leur défaveur.

The Chrome Dev Tools can do THAT

Les speakers de Google présents à Devoxx sont des bons. Celui qui a présenté Chrome Dev Tools, Ilya Grigorik ne déroge pas à la règle. Ce développeur Google nous présente donc Chrome Dev Tools et ses fonctionnalités.

On commence avec du classique, rien de super impressionnant, moi qui utilise fréquemment Firebug (je n’ai hélas pas accès à Chrome à mon boulot) : édition du HTML, CSS, JavaScript, etc. Quelques fonctionnalités intéressantes sont là, comme le glisser - déposer qui permet de modifier le DOM facilement. Ilya passe ensuite sur la présentation du Network Timeline, qui nous montre où passe le temps quand on charge une page : le temps d’attente pour obtenir une ressoure, le temps de la télécharger, sa taille (compressée et totale). Chrome Dev Tools indique qui a demandé la ressource (ça peut être la page, un script, etc.). Ces données sont importantes, et permettent de mieux ordonner le chargement des ressources pour accélerer l’affichage de la page. Toutes ces informations sont également exportables sous un format HAR, ce qui permet par exemple d’attacher ces informations dans un ticket JIRA en cas de souci, d’analyser ces trames plus tard, etc.

Par la suite, Ilya nous explique que la fluidité de son site est aussi un critère extrêmement important pour l’utilisateur. Cela est particulièrement vrai dès que l’on intègre des animations (en JS ou CSS) dans sa page, et que l’utilisateur scrolle en même temps. Chrome Dev Tools dispose d’outils pour comprendre où le navigateur va passer son temps durant des animations, ce qui est très instructif, bien qu’il me semble qu’on arrive là à un niveau assez élevé d’optimisation… Ici aussi, les données sont exportables (sous format JSon) pour une analyse ultérieure.

Chrome Dev Tools a également un outil de profilage permettant de détecter des fuites mémoire, ainsi qu’un outil d’audit. Ce dernier va inspecter de très nombreux points sur votre site, permettant de gagner ci ou là quelques millisecondes. Ilya nous montre ainsi l’exemple du site de la CNN, où l’outil d’audit détecte que beaucoup d’images pourraient être allégées en utilisant un meilleur algorithme de compression. Chrome Dev Tools va même à montrer en exemple l’image ainsi compressée ! Je trouve ça excellent, et il manque juste à mon avis un bouton ”Ok, commit that to Git” :) Chrome Dev Tools est également compatible avec PageSpeed Insight qui liste différentes améliorations de performances.

Ilya nous montre ensuite l’extensibilité de Chrome Dev Tools, en détaillant le protocole utilisé par l’outil pour faire par exemple du débogage à distance. Ainsi, il devient facile de lancer un navigateur sur un téléphone Android, et de tout analyser dans un autre navigateur Chrome, installé par exemple sur son laptop. Comme Chrome expose toutes les données via un WebSocket, il est même possible d’interagir avec d’autres logiciels que Chrome. C’est ainsi qu’il est possible de débugguer une application iOS grâce à Chrome !

La présentation se termine par l’outil de benchmark grâce auquel il est possible d’analyser les performances de son site.

Au final, nous avons eu une conférence technique de haut niveau, avec des fonctionnalités vraiment épatantes de la part de Chrome, bien que certaines sont à mon avis bien trop précise pour être vraiment utile (sauf si on veut aussi débugguer Chrome lui-même :) ).

La présentation est visible en ligne.

Voilà, c’est tout (!) pour une première journée déjà très chargée, bien qu’amputée d’une grosse partie de la matinée à cause des grèves. La soirée se terminera dans le bar / restaurant à côté du Métropolis, l’Axxis, où l’on a retrouvé une partie des développeurs Play! de Belgique (peu nombreux) ainsi que des frenchies (dont Nicolas Martignole). Retour à l’hôtel vers 23h / 23h30, presque prêt à attaquer la 2e journée !