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 :
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.
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.
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 |
|
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 :
npm install -g generator-angular
, qui installera le générateur ;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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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.
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 !
]]>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).
]]>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.
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…
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…
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)
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.
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…
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 :
if
imbriqués par exemple) ;else
;String
;List<String> usernames
mais plutôt une classe plus explicite, comme par exemple Usernames
.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 ?
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)
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.
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 |
|
Ce n’est pas trop moche, mais cela reste moins lisible que quelque chose de ce genre :
1 2 3 4 5 6 |
|
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
|
|
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.
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.
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 |
|
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 |
|
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 |
|
On voit trois choses intéressantes :
polymer-element
qui prend le nom du composant (progress-bar
) ;<template>
qui va nous permettre d’ajouter le code HTML ;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 |
|
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 |
|
On voit plusieurs choses :
attributes="percentage"
;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 |
|
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 |
|
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 |
|
pour pouvoir l’appeler ensuite :
1 2 3 4 |
|
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
|
|
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 |
|
et dans ma page index.html
:
1 2 3 4 5 6 7 8 9 10 11 |
|
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…
]]>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 :
Boucles étranges, étranges boucles
.Couchbase
.Gatling
.Bitman
et l’utilisation avancée des caches.Node.js
et 24 plugins chrono
.Cucumber.js
.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.
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 :)
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.
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 :
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 |
|
Démarrer un serveur peut se faire directement en ligne de commandes, ou encore via quelques lignes de code :
1 2 3 |
|
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 !
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 :
Les moins, ou les points d’amélioration :
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.
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.
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 :
document.register()
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 !
(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:
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.
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.
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.
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 ?
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 :
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 :
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 :
Encore une belle présentation de Sven Peters.
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.
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.
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.
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.
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 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 :
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 :
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.
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.
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 !
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 :
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.
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 |
|
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 !
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 !
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 :
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.
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 :
Les moins :
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.
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…
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 !
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 |
|
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 |
|
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…
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.
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 !
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 |
|
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 |
|
A ce moment-là, les scripts sont exécutés, les images chargées et le DOM affiché.
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
|
|
Avec Chrome Tools, on peut faire afficher le shadow DOM pour cette balise vidéo, sous un “tag” #document-fragment
:
1 2 |
|
1 2 3 |
|
On peut aussi passer par des templates :
1
|
|
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.
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 |
|
Et pour l’utiliser dans une autre page :
1 2 3 |
|
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 |
|
Ces éléments sont utilisés pour détecter des modifications dans le code JavaScript.
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 |
|
Ainsi, entre le Dirty checking et le Object.observe(), le gain de performances peut être de l’ordre de 20 fois !
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…
Une excellente session où j’ai appris pas mal de choses que je ne connaissais pas !
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 !
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…
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é :
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” :
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 :
Pour finir, il nous rappelle que Scrum lui-même a ses propres valeurs :
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.
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.
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.
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
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 :
Les jeux (qui sont appelés “ateliers” auprès du management, ça passe mieux !), sont les suivants :
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.
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 :
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 :
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 :
Voilà un retour d’expérience assez classique, rien de bien nouveau sous le soleil au final.
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 :
Du côté des managers :
Rendre visible cette transformation, c’est :
Dernière question que pose Yann Poles : comment péréniser l’agilité, ancrer la transformation ?
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.
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.
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 |
|
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 |
|
En gros, il se divise ainsi :
casper
(dans mon cas, je lui demande d’être un peu pipelette, ça facilitera les choses en cas de problème).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 |
|
Cool, ça marche !
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
On relance la même commande, et cette fois-ci ça marche mieux :
1 2 3 4 5 6 7 8 |
|
Cool ! Voyons maintenant s’il est possible de lancer la commande coffee
:
1 2 |
|
Houra !
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 |
|
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.
La session se divise en deux parties :
Tout d’abord, nous expliquons pourquoi nous faisons cette présentation. Le constat est double :
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 :
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.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 |
|
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 |
|
Assez parlé des problèmes, voyons 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 |
|
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 |
|
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 :
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 |
|
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 |
|
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 |
|
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.
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.
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 :
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.
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.
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 :
div
qui représente la scène.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 |
|
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.
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.
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 :)
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 !
]]>