Cette session des HumanTalks avait lieu chez nous, chez Octo. Je me suis occupé de l'organisation, du coup j'ai pas beaucoup eu l'occasion de voir les présentations en elle-mêmes. Du coup, mon résumé sera un peu moins touffu que d'habitude (ouf! dirons certains).
De l'idée au projet
On a tous des idées de projets qu'on a envie de faire sur notre temps libre. Mais la plupart du temps, on profite d'avoir les coudées franches pour aussi partir sur de bonnes bases, et en profiter au passage pour apprendre de nouvelles technos. Finalement, on se retrouve avec une toute nouvelle stack, qu'on ne connait pas du tout, on apprends sur le tas, on découvre les outils, et deux semaines plus tard on a juste mis en place la stack technique et on n'a pas commencé le projet en lui-même.
Du coup, Jonathan Beurel vient lui nous parler des pièges à éviter dans ce cas, et comment aller droit au but de ce qu'on veut construire. Lui, sur son projet perso, il a repris les briques qu'il utilise déjà tous les jours au boulot et qu'il maitrise : Vagrant, OpenStack, Capistrano, Angular & Node. Son hébérgement, il le fait facilement avec les GitHub Pages, et il utilise au maximum l'écosystème as a service: SaaS, IaaS, PaaS.
Pour sa base de données, il a donc testé Firebase et Parse. Son retour d'expérience c'est que c'est difficile de rajouter de la logique métier avec Firebase, alors que c'est très facile avec Parse, sous forme de hooks Javascript. Malheureusement pour lui, Parse fournit un SDK simple pour Backbone mais pas pour Angular.
Pour le déploiement, il a utilisé Codeship. A chaque push sur son repo, il execute les tests, et si les tests réussissent, il execute un script de déploiement.
Au final, il a du js à tous les étages de sa stack et utilise un maximum d'outils en -aaS pour mettre en prod. Ça lui fait gagner beaucoup de temps et il utilise ce que d'autres ont déjà fait, pour lui se concentrer sur les fonctionnalités propres à son idée.
Protobuf
Pour le coup là, j'ai été occupé toute la présentation à réceptionner les pizzas, je n'ai malheureusement rien vu !
Formateur indépendant, mais où est Charlie?!
Mathieu Robin, formateur indépendant depuis peu nous parle de l'aventure que c'est de se lancer dans la formation tout seul. Pour lui il y a de grosses arnaques dans le milieu de la formation, avec un budget de 14 milliards fourni par l'État pour les formations en entreprises. D'après lui, il suffit d'attester avoir participé à une formation, et que le formateur atteste l'avoir donné, pour toucher un part du gateau. Il a donc voulu en faire parti...
Des clients l'appellent pour lui demande des formations, mais sans savoir exactement la date, la durée, le nombre de personne. En gros, il faut être prêt à partir en formation rapidement.
Pour être officiellement reconnu comme formateur, il faut un numéro de SIRET, ce qui est facile à obtenir, mais il faut aussi un numero d'agréement de formation, qu'on n'obtient qu'une fois qu'on a fait une vraie formation, payée par une société. Le soucis étant que tant qu'on n'a pas fait cette formation, la société paye le prix fort, il est donc très difficile de faire cette première formation.
Mathieu Segret, co-fondateur de l'organisme de formation HumanCoders a rajouté un mot à la fin, pour aller dans son sens. Passer formateur nécessite de naviguer dans un vrai dédale administratif. Chez HumanCoders ils ont automatisé un maximum de choses pour remplir automatiquement les papiers au format PDF, ce qui leur rends la vie plus agréable.
Meteor
Ici aussi, je n'ai pas pu assister à la présentation, trop occupé à préparer le buffet pour discuter après coup.
Conclusion
Dommage pour moi, je n'ai pu voir qu'une partie des talks, pris dans l'organisation. J'ai pu un peu discuter après coup aussi, et on a bien mangé (avec de beaux gateaux d'anniversaire des HumanTalks).
Le 19 Novembre 2014, au Théatre de Paris, avait lieu la nouvelle édition de dotJS. Un lieu magnifique, des speakers de renom et des présentations intéressantes. Je n'ai pas réussi à sortir un fil directeur général au programme, mais voici un petit résumé des différentes conférences.
C'est dans l'ordre chronologique de la journée, mais sans doute un peu en vrac dans les idées.
James Halliday aka Substack
Substack, le mec qui code même dans son sommeil (jetez un œil à sa timeline), nous a parlé de... plein de choses. Je suis pas sur de pouvoir en ressortir le propos exact, mais j'ai beaucoup apprécié le personnage et la session de questions-réponses qui a suivi son intervention.
Il a commencé à nous parler de comment réussir à avoir une application web qui puisse fonctionner complétement offline, avec le mode online qui soit simplement un bonus. Pour ça, on passe par un cache manifest, qui définit la liste des éléments qui doivent être gardés pour le mode offline. Et si on veut aller encore plus loin, on mets carrément le cache manifest dans le cache manifest, comme ça on est sur que notre appli ne se connectera pas.
Il a ensuite énoncé quelque chose de très vrai : un site offline est le meilleur moyen d'avoir un scaling infini. Zero requête vers le serveur, pas de problème de charge, il peut y avoir une infinité de personnes qui utilisent le site en même temps, cela n'influera en rien sur ses fonctionnalités.
Il a développé, comme à son habitude, un ensemble de modules pour aller dans cette direction. L'un d'eux utilise localStorage pour garder un historique des anciennes versions du site directement dans le browser. Il est ainsi possible de revenir à des versions de la veille ou de la semaine dernière à partir du moment où on les a déjà téléchargé une fois.
S'en vient ensuite la question de l'authentication quand on n'a pas de serveur distant ? En utilisant les méthodes de crypto définies dans crypto.subtle, on peut réussir à faire une grosse partie de l'authent directement dans le browser.
Il a finalement parlé d'un autre de ses modules, forkdb, qui semble fonctionner comme un database key/value, mais où chaque value contient un hash des metadata de son historique, permettant d'établir une chain of trust (à l'instar des bitcoins), permettant de rejouer l'intégralité des modifications apportées à la valeur. Cela permet de faire des bases de données décentralisées, qui tournent individuellement sur les browsers de chacun, touchant la même source de données, mais qui peuvent se réconcilier plus tard car l'ensemble des transactions est gardé en mémoire et peut être rejouée.
Au final je dois bien avouer que j'ai pas tout compris aux applications concrètes de tout ça, mais ça donnait quand même envie !
Pour finir, dans les questions-réponses dont je parlais il lui a été demandé comment il faisait pour être aussi productif. Sa réponse est sans appel :
Facile, je n'ai pas de boulot. Si vous voulez commencer à être productif, quittez votre job.
En vrac sur d'autres questions, notamment sur npm :
Npm c'est un peu comme une décharge publique. Tout le monde y mets plein de choses, des choses qui marchent, d'autres qui marchent pas, et parfois, en fouillant bien on trouve des pépites. Comme dans tout langage, il faut une énorme quantité de mauvais code pour avoir du bon code. C'est pour ça que les artistes qui font des chefs d'œuvres vivent dans des taudis en bordel. Au final ce n'est pas une question de langage, de si on mets des parenthèses et des points-virgules ou non, c'est une histoire d'écosystème de développeurs et de communauté.
Vraiment, un chouette type !
Charlie Robbins
Ensuite, Charlie Robbins, de Nodejitsu nous a parlé de npm aussi, mais d'un point de vu statistique. Il a analysé les repos npm pour faire de l'analyse statistique dessus et savoir les modules les plus utilisés comme dépendances, les versions les plus stables (ie. utilisées par le plus de packages), celles qui présentent le plus de failles de sécurités, etc.
Le gars est sans doute très fort pour faire des statistiques sur des données de type graph (et ses slides sont très jolis), mais concrétement je n'ai rien tiré réellement de cette présentation.
Justin Meyer
Justin Meyer nous a quand lui un peu éloigné du code et s'est rapproché des humains derrière les écrans. Il a effectué lui aussi quelques stats, à plus petit échelle, sur les projets sur lesquels il a travaillé durant les dernières années. Il a ensuite noté chacun des projets selon des tas de critères (sortie dans les temps, effort de dev, nombre de bugs, etc) et pour chacun il a vérifié s'ils possédaient telle ou telle carac (test unitaire, module loader, documentation, user testing, etc).
Il a ensuite mis ces informations en regard pour en déduire les éléments qui influent le plus dans la réussite d'un projet, afin de créer une checklist des choses à faire pour s'assurer un maximum de chances de réussites.
L'idée est très intéressante, mais comme son initiative vient à peine de commencer, il n'avait pas vraiment de réels chiffres à sortir sur les éléments les plus influençants. Néanmoins, en prenant quelques pincettes avec les chiffres (calculés sur un petit échantillon), on arrive quand même à isoler les éléments suivants comme ayant été des facteurs clés du succès du projet :
user testing
design documentation
shared vision and roadmap
release in less than 6 months
social events
Domenic Denicola
Domenic, nous a ensuite parlé de JSDom. Selon lui, le meilleur moyen d'apprendre comment quelque chose fonctionne est de le recoder... en Javascript. Lui et d'autres ont donc recodé le principe du Document Object Model en nodejs, de manière à pouvoir parser un arbre HTML (et le CSS/JS qui en découle) sans avoir besoin d'un browser.
Un peu dubitatif au démarrage quand à l'utilité d'un tel projet, je suis finalement resté bluffé par le niveau de maturité de JSDom et je pense que je l'utiliserai si le besoin s'en fait sentir (pour éviter d'utiliser tout une stack de browser quand juste le DOM est nécessaire).
Ils réimplémentent complétement les API natives du DOM (document, window, HTTPRequest, etc). Le cas d'usage le plus courant est pour faire du rendering complet coté serveur. On lui passe un input HTML, du JS et du CSS à coté, et on peut ensuite requêter le DOM pour obtenir les listeners, les styles, etc.
Basé sur JSDom, il existe aussi zombie.js qui permet d'aller un peu plus loin pour simuler un navigateur. On peut par exemple simuler le remplissage de formulaire. Il semble que la bibliothèque soit pas mal utilisée pour tricher sur les jeux en ligne.
Afin d'être au plus proche de la spec officielle du DOM, ils ont développé un outil qui accepte en input un fichier de spec au format webidl, et qui le transforme en un fichier de classe JSDom en Javascript. Comme ça, il est (presque) inutile de comprendre la spec pour pouvoir l'implémenter.
Angus Croll
Angus Croll nous a fait passer un très bon moment avec un talk extrèmement intéressant intitulé "Code & Literature". Pour lui, Javascript est un langage très souple qui permet de faire énormément de choses, et qui permet aussi de faire la même chose d'énormément de façons différentes. Pour éviter de trop se disperser, on a inventé des best practices, qui fonctionnent dans la majorité des cas. Mais quand on rencontre un edge case imprévu qui va nous forcer à casser ces règles, on ne sait pas forcément comment faire car on n'a jamais appris qu'une seule manière de faire.
Lui nous incite à tester, à jouer avec le code, à essayer. Javascript nous permet de faire les choses de manière impérative, object ou fonctionnelle, profitons-en. Ça ne suivra peut-être pas les guidelines et ne sera peut-être pas propre selon les standards du projet, mais ça nous fera apprendre des choses. Il n'y a qu'en essayant quelque chose d'inconnu qu'on peut apprendre.
Lui aussi est d'accord sur ce que disait Substack : il faut beaucoup de mauvais code pour avoir du bon code. C'est une phase d'apprentissage obligatoire, et il ne faut pas perdre de vue le coté fun de l'apprentissage. Et les styleguides ne sont que des indications à un moment donné pour un projet donné, elles évoluent dans le temps et dans l'espace.
Par exemple, on considérait avant les notations if (!!x), fn && fn() ou (function(){...}()) comme étant des bad smell, alors qu'aujourd'hui on les considère comme des syntaxes tout à fait valides, pour peu qu'on sache bien les utiliser. Le niveau des codeurs de JS a évolué, et ce qui était considéré comme des syntaxes ésotériques fait aujourd'hui partie intégrante du langage.
Javascript est un langage à part entière, dont il faut comprendre les subtilités. Au début on semble être en terrain connu, la syntaxe est facile, qu'on vienne de Java ou de C, on s'y retrouve. Puis on commence à plonger un peu plus et on se rends compte qu'on n'avait vu que la partie émergée de l'iceberg et que tout le "weird shit" se trouve caché en dessous. Et tout à coup, tout semble compliqué. Alors on se barde de plein de bonnes pratiques et de jshint et jscs et on se pense en sécurité. Mais on perds le fun.
Playing is learning. C'est en essayant de faire les choses différement qu'on apprends. Les développeurs autodidactes sont souvent les meilleurs, parce qu'ils ont fait des erreurs, et comprennent ce que cela implique, ce qui fonctionne et ce qui ne fonctionne pas. Ils peuvent penser à des alternatives, et continuent de s'amuser.
Mike McNeil
Mike McNeil, créateur de SailsJS, nous a parlé de machines. J'ai pas pris énormément de notes sur cette conférence, donc je la fais essentiellement de tête.
L'idée des machines est de définir les méthodes de ses modules sous forme d'objet, qui contiennent effectivement dans une clé la méthode en elle-même, mais surtout pas mal de metadata sur la méthode autour. On peut par exemple y ajouter des méthodes de preinput ou postoutput pour sanitizer le contenu ou le formatter d'une certaine manière. On peut aussi y définir les différents arguments, en indiquant des exemples, et une petite phrase de documentation.
En faisant ainsi, on se rajoute une couche supérieure d'abstraction au dessus de nos méthodes, mais on y gagne un moyen simple de faire de la documentation auto-générée et qui sera forcément à jour (pas comme des annotations sous forme de commentaire qui finissent toujours pas être désynchros).
L'idée parait intéressante, à condition que ces objets soient "compilés" finalement en JS (et hop, encore un preprocesseur de plus dans le pipe).
John-David Dalton
John-David Dalton, créateur de lodash, nous a parlé des shims et des bibliothèques et pourquoi une bibliothèque est supérieure.
Il commence par balayer tout un tas d'a-priori qu'on peut avoir sur les implémentations natives dans les browsers. Comme quoi la syntaxe est plus simple, que les perfs sont meilleures, qu'il n'y a pas besoin de compilation spéciale ou que les implémentations sont stables. Tout ceci n'est pas vrai et il donne quelques exemples sur plusieurs browsers.
Ensuite, il s'attaque aux shims (qui consistent à définir manuellement des méthodes pour combler les trous des browsers, mais de laisser l'implémentation native si elle existe). Les shims sont une bonne solution, mais qui n'est pas parfaite selon lui. Notamment, on subit les régressions de performance qui peuvent apparaitre entre les versions des navigateurs. Mais surtout, on risque de casser des implémentations si on remplace un prototype natif par notre propre version, lors des futures versions où ce prototype sera implémenté.
Pour lui, la meilleure solution est d'utiliser une bibliothèque, qui elle s'assure d'être compatible entre tous les navigateurs. Lodash implémente la même API qu'underscore, mais avec un axe particulier sur la performance. Pour avoir regardé le code source des deux librairies, celui d'underscore est parfaitement lisible et clair et on aurait tous pu l'écrire. Celui de lodash est bien plus complexe car même s'il expose la même API les rouages internes passent par des optimisations bien plus importantes.
En plus de ça, lodash offre du sucre syntaxique pour les appels les plus courants des méthodes et permet de chainer et de fusionner les itérations map, filter et take. Si vous souhaitez par exemple prendre les 10 premiers éléments de votre liste qui matchent tel critère après être passé par telle transformation alors lodash s'arretera dès qu'il aura trouvé les 10 élements. Avec underscore ou une autre implémentation classique, on aurait du itérer trois fois sur le même set (une pour la transfo, une pour le filter et une pour n'en prendre que 10).
Soledad Penades
Démos de web audio, en jouant sur les pitchs et la fréquence. J'avoue que j'ai pas énormément de souvenirs de cette présentation.
Joe McCann
Joe McCann nous parle d'optimisations de V8, le moteur qui fait tourner node. Pour lui, il y a deux types d'ingénieurs; ceux qui se demandent "comment ça marche ?" et ceux qui se demandent "qu'est-ce que je peux construire avec ça ?". Lui se situe dans la première catégorie et a plongé dans les rouages de V8 pour nous remonter quelques astuces d'optim de perf.
V8 est extremement intelligent et va s'occuper de faire la majorité des optimisations tout seul. Néanmoins, il y a moyen de l'aider en le mettant sur la bonne piste.
Déjà, définir des fonctions qui acceptent toujours le même nombre d'arguments, et toujours de même type va lui permettre d'optimiser la mémoire allouée. Quand on défini des objets, il est plus intéressants de définir l'objet, avec toutes ses clés (même null ou undefined) plutot que de définir un objet vide et d'ajouter ensuite les clés à la main. Ensuite, il faut favoriser les tableaux d'élements de même type (éviter de mixer des int, string et objets par exemple), ce qui parait assez évident. Dans le même ordre d'idée, V8 parvient plus facilement à optimiser les fonctions nommées que les fonctions anonymes, même si elles sont directement invoquées.
Mais surtout, là où l'optimisation devient plus obscure c'est sur la taille (en caractères) d'une fonction. En effet, par défaut, si une méthode fait moins de 600 caractères (commentaires inclus) V8 va la garder en mémoire directement plutot que d'avoir un pointeur vers sa définition. Joe nous a fait quelques démos en grossissant artificiellement la taille d'une méthode en ajoutant simplement des commentaires et en la jouant des millions de fois. La différence entre les deux était flagrante (de 1 à 10s).
Cette limite de 600 chars est paramétrable en passant un flag à V8 à l'initialisation (--max_inlined_source_size). Et il est aussi possible de changer cette limite on the fly directement dans une appli node (par exemple sur une route donnée), en utilisant la syntaxe (étrange) %SetFlags() qui permet de passer l'instruction directement à la couche C depuis le js.
Paul O'Shannessy
Paul nous a parlé de React. React est le V du trigramme MVC et vient de chez Facebook. Initialement, il s'appellait XHP, un enfant illégitime entre PHP et XML.
Le principe de React est d'avoir des composants d'UI réutilisables et qui sont uniquement responsables de l'affichage de leur data. La donnée arrive forcément d'en haut. Le composant recoit sa nouvelle donnée, mets à jour son affichage.
Honnêtement, plus j'entends parler de React et plus j'ai envie d'essayer. Ça me semble une manière tellement élégante d'isoler ses composants UI tout en leur gardant une logique simple. Le composant n'est pas responsable de la donnée, ce n'est pas lui qui en garde une copie, il est juste notifié de son changement et se doit de se mettre à jour en fonction.
Mon résumé de React ne lui fait hommage, mais on mettra ça sur le compte de la fatigue à la fin de l'écriture de ce CR.
Julien Lecompte et Yehuda Katz
Je n'ai pas parlé des interventions de Julien Lecompte et Yehuda Katz car je n'ai pas pris de notes à ce moment (fatigue, manque de batterie de laptop ? je ne me souviens plus de la raison).
Julien nous a parlé du YUI framework, de son histoire et de ce qu'il est devenu. Yehuda nous a parlé de la difficulté de maintenir des projets open-source et de les faire monter de version majeure sans s'aliéner toute la communauté (transparence, rétro-compatibilité, eat your own dogfood, open-source rapidement). Même s'il ne l'a pas nommé, tout ce qu'il indiquait était l'exact opposé de ce qu'Angular est en train de faire pour sa v2.
Conclusion
Beaucoup de sujets ont été abordés durant cette journée, sans qu'il ne soit possible de donner une ligne claire. Autant à dotScale il était évident que le gros sujet était Docker tellement toutes les présentations en parlaient, autant là tout le monde parlait de choses différentes : du backend, du frontend, des browsers, des serveurs, des outils de builds, des processus, etc.
Je retiendrai particulièrement les interventions de Substack et Angus Croll comme étant les deux moments forts de la journée. Je noterai cependant la totale absence d'Angular dans cet événement. Seul Yehuda en a parlé sans le citer, comme quoi, Angular et Javascript restent deux mondes différents.
Vendredi après-midi avait lieu la première conférence dotCSS. Comme d'habitude pour les dot conferences, le lieu était magique. Cette fois-ci, au théatre des variétés, sur les grands boulevards.
La demi-journée a été riche en informations autour de CSS, depuis sa création, jusque son futur, les choses bizarres qu'on peut faire avec, les outils qui tournent autour et son intégration au sein d'une équipe aux compétences diverses.
Le talk d'ouverture était de Daniel Glazman, co-chairman du W3C. Il a rappellé qu'il était "juste" co-chairman, et pas co-boss. Que ce n'était pas lui qui prenait les décisions finales quand à l'orientation du web, mais qu'il avait plus un rôle d'huile entre les différentes pièces, un facilitateur de débats (souvent houleux).
Le W3C est un consortium de représentant de sociétés privées et des grands acteurs du web, de fabricants de navigateurs, de sites à fort traffic, de fabricant de hardware, etc. Ils se mettent d'accord pour donner un axe de travail pour l'amélioration des technos du web (CSS entre autres). Mais chaque membre a son propre planning, ses propres objectifs et le rôle du W3C est de réussir à trouver un compromis qui conviennent à tout le monde. Et parfois, ces consensus donnent quelque chose d'hybride qui ne convient réellement à personne.
Retrospectivement, on peut dire que plusieurs erreurs ont été faites lors de la création de CSS selon ce principe. Par exemple la fusion des marges, le principe du box-model, ou la complexité à réussir à centrer verticalement du texte. Pour leur défense, il faut bien avouer que CSS était initialement prévu pour donner un peu de style à des rapports académiques, à du texte pur et dur, pas à faire des mises en pages complexes dépendantes de la résolution d'écran, de la vitesse de la bande passante et de la densité de pixels comme on lui demande aujourd'hui.
Glazou a terminé par nous présenter, non sans trolls, les prochaines shiny features de CSS. Les tant attendues variables arrivent enfin ! Sauf que c'est pas exactement des variables, ce sont des Custom Inherited Properties qui ne sont donc pas globales, mais qui cascadent depuis un élément parent vers ses descendants.
Pour aligner du texte verticalement, on a le fantastique flexbox qui permet de faire les mises en pages les plus folles au prix d'une syntaxe complexe avec X propriétés différentes pouvant prendre Y valeurs possibles.
Et puis, il y a le nouveau sélecteur :matches() qui est plus du sucre syntaxique et qui permet de simplifier l'écriture de certains sélecteurs (par exemple :matches(section, article) :matches(h1, h2) plutôt que d'écrire section h1, section h2, article h1, article h2.
Dans le même ordre d'idées, des améliorations à :nth-child() sont dans le pipe, pour pouvoir préciser un sélecteur afin de ne compter que certains éléments.
On parle aussi d'une syntaxe proposée pour pouvoir sélectionner un élément autre que celui qui se trouve en bout de chaine d'un sélecteur. Aujourd'hui on peut écrire div p pour sélectionner tous les paragraphes dans des divs, mais on ne peut pas écrire de sélecteur pour sélectionner tous les divs qui contiennent des paragraphes.
Mais les modifications sans doute les plus importantes à mon sens seraient de pouvoir avoir accès au moteur de parsing CSS, en read-only, depuis Javascript. Ne plus être obligé de reparser les règles CSS à la main pour calculer la taille d'une font en pixels ou la valeur d'une couleur à un point x au milieu d'un linear-gradient. Puisque le parser CSS a déjà fait ce travail, il serait bon qu'on puisse y accéder directement.
Une très bonne intro, aussi bien tournée vers le passé que le futur, pour commencer ces conférences dotCSS !
Bridging the gap between developers and designers
Le second speaker faisait parti de ces nombreux speakers français qui ont fait l'effort de présenter en anglais pour l'auditoire en grande partie non-francophone. Kaelig travaille aujourd'hui au NY Times après avoir bossé au Guardian.
Sa présentation n'était pas réellement technique, mais portait plus sur la manière de faire en sorte que les développeurs front et les designers travaillent mieux ensemble. Il est indispensable pour lui que cela passe par un partage d'un langue commune. Que quand un designer indique que le header doit être "gris clair", il n'y ai pas d'ambiguité sur quel gris il faut utiliser.
Pour cela, ils utilisent une feuille recensant toutes les couleurs utilisées dans leur site, en donnant un nom à chacun (du type neutral-1, corporate-color, etc) et la valeur hexadécimale qui va avec. En faisant ainsi, designers et développeurs parlent bien toujours des mêmes couleurs et se sont créés un dictionnaire de mots partagés. Le nom de la couleur que les designers emploient à l'oral pour discuter entre eux est aussi le nom de la variable dans les fichiers CSS. La communication entre les deux mondes est alors grandement simplifiée.
Ils appliquent le même principe pour les fonts, en créant une matrice des différentes combinaisons de font/size utilisées, en les réferencant par leur fonction comme par exemple heading-3 ou maintext-2. Ici aussi, le vocabulaire des designers a été uniformisé, et les mêmes termes sont utilisés dans les feuilles de styles, ce qui aide en plus à développer directement en peer programming designer/developer dans le browser.
Pour les breakpoints RWD, même histoire, ils ont arreté de mettre des valeurs en em dans leurs media-queries car cela n'évoque rien à la lecture. A la place, ils ont créé des mixins qui peuvent être facilement comprises à la lecture et ont abstrait les détails en dessous. Par exemple, mq(from:tablet), mq(from:phone, to:tablet), mq(until:tablet).
Niveau grille, même combat, création de helpers pour pouvoir rapidement définir "je veux trois colonnes, mais en desktop en avoir 7". Le code SCSS directement lisible exprime bien cette intention, on a des helpers pour définir des règles différentes pour phone et desktop, et on exprime avec d'autres helpers le nombre de colonnes qu'on souhaite. Toute la complexité de largeur de colonnes, largeur des marges, breakpoints est cachée dans ces mixins (qui sont le territoire des devs), alors que l'intention est exposée un niveau plus haut (territoire partagé dev/designer).
Le fait de partager la même langue pour parler de la même chose aide à la cohésion de l'équipe et à l'appropriation du projet. Il est plus facile de modeler le code pour qu'il suive les idées du designer que de remodeler le designer pour qu'il parle comme du code. En partageant tout cela entre les deux territoires, on augmente l'appropriation du code par les designers et l'appropriation du design par les devs.
D'après lui, dans un projet web, il vaut mieux avoir une connaissance générale de tous les métiers qui vont prendre part au projet, plutôt que d'être expert uniquement de la partie qui nous concerne. Dans cette optique, il nous a donné 10 conseils pour ne pas perdre de vue l'essentiel. Plusieurs de ses conseils se recoupaient, je vais donc les synthétiser.
Tout d'abord, l'option la plus simple est souvent la meilleure. Plus on va vite, moins ça coûte cher au client. Le meilleur code est l'absence de code, plus on écrit de code, plus on écrit de PPOF (Potential Point of Failure). En réduisant la complexité d'une solution, on la rends plus légère et donc plus facile à comprendre, à apprendre à quelqu'un, à maintenir et à débugguer. Une solution simple aura moins tendance à casser, et nécessite moins d'overhead du codeur pour la comprendre. "Le mieux est l'ennemi du bien", il vaut mieux avoir quelque chose de good enough aujourd'hui, que quelque chose de parfait demain.
Ensuite, il ne faut pas oublier l'objectif. Le code n'est qu'un outil pour atteindre cet objectif. Il est nécessaire de comprendre ce qui coûte et ce qui apporte de la valeur au client, afin de ne pas lui faire perdre d'argent. Pour cela, il est nécessaire d'aller voir les autres personnes, d'autres métiers qui travaillent sur le même projet. Le travail d'un intégrateur web n'est pas de reproduire des PSDs, enfermé dans sa bulle avec son casque sur les oreilles. Il lui faut aller voir les autres, et faire ce qui est bon pour le produit final.
Finalement, il ne faut pas être trop attaché à son code. Le code est jetable et s'il est modulable il est facile d'en jeter un morceau en gardant le reste. Les demandes du projet vont changer régulièrement, il faut être prêt à accepter le changement, à jeter du code, à en écrire du nouveau. Dans le même ordre d'idée il est inutile de prévoir à l'avance tout les cas particuliers, car ils n'arriveront peut-être jamais, peut-être la fonctionnalité va-t'elle changer en cours de route.
Keep Calm and Write Sass
Hugo Giraudel nous a ensuite parlé de Sass, avec une liste de bonnes pratiques et de choses à ne pas faire. Il a aussi abordé un peu le tooling autour de Sass.
Sass est un preprocesseur CSS, qui apporte des briques habituellement trouvées dans les langages de prog : variable, conditions, boucles, fonctions, etc. C'est assez facile de vouloir en faire trop avec Sass, juste parce qu'on peut le faire. Mais ça ne sert à rien, et il faut rester KYSSS (Keep Your Sass Simple and Straightforward).
Il ne faut pas oublier que Sass permet de se positionner une couche au dessus de CSS, et qu'il permet donc d'exposer des méthodes pour générer du CSS. Il faut que ces méthodes soient peu nombreuses, avec une API publique simple. Ici, les bonnes pratiques du Clean Code habituelles s'appliquent : des noms explicites, des comportements devinables, pas des tas d'arguments différents pour gérer plusieurs cas de figures différents, etc.
Sass incite aussi au nesting de sélecteurs à outrance. C'est très facile à faire en Sass, mais ça donne des feuilles de styles finales avec des sélecteurs bien trop précis et bien trop difficiles à overrider. Il faut limiter au maximum le niveau de nesting.
Finalement, il a évoqué plusieurs outils comme scss-lint qui est un linter de fichiers Sass, sassdoc qui permet de générer une documentation HTML avec des exemples à partir de fichiers source Sass et enfin True qui permet de faire des tests unitaires sur les retours des fonctions Sass.
Et la dernière conférence à laquelle j'ai pu prendre des notes avant que la batterie de mon laptop et les neurones de mon cerveau ne lachent fut celle d'Estelle Weyl.
Estelle nous a montré quelques astuces tout droit tirées des coins les plus reculés du monde du CSS. Tout d'abord, grâce à counter-increment, il est possible de garder un compteur en CSS. Par exemple la page actuelle de sa présentation était indiquée grâce à ce système, et elle nous a montré comment afficher le nombre d'erreurs d'un formulaire rien qu'avec du css.
Elle nous aussi rappellé qu'il existait un grand nombre de pseudo-selecteurs dans la même veine que :valid et :invalid mais qu'ils ne sont pas encore correctement implémentés partout (notamment :default et :placeholder-shown).
On a ensuite fait un petit rappel des spécificités des sélecteurs (récapitulé sous forme de poisson sur Specifishity, et appris que les sélecteurs >, +, ~ et :not() n'ont aucune spécificité. Donc div p a le même poids que p + p et img pèse aussi lourd que :not(img). Il est bon de le rappeller.
Elle a ensuite parlé de l'horreur absolue qu'est !important dans du CSS, qui permet d'overrider toutes les autres règles et qui est lui-même impossible à overrider. Mais elle a aussi donné une astuce pour réussir à overrider un !important... astuce que je ne donnerai pas ici, vous pourriez avoir envie de l'utiliser ! :)
Pour finir, elle nous a montré un moyen de faire du browser sniffing directement depuis le navigateur, pour peu que celui-ci supporte @supports (recursive joke inside). En testant des propriétés prefixées -webkit ou -moz on peut comme ça appliquer certaines règles uniquement à un moteur de rendu ou un autre. Pas sur que ce soit une brillante idée, mais ça peut dépanner.
Fin des talks
Les trois derniers talks étaient de Nicolas Gallagher qui nous a parlé de comment ils ont modularisé leur UI chez Twitter, en utilisant des Web Components. Ce qu'il mettait en avant faisait echo à pas mal de choses dites précedemment : aligner les developpeurs et les designers sur un langage commun, masquer la complexité en dessous et laisser une API publique simple et qui exprime bien l'intention.
Bert Bos, co-créateur de CSS nous a parlé des challenges que posent les différents règles de typographie des différents pays du monde pour le CSS. Différents types de guillemets selon les langues, espaces avant la ponctuation ou non, italique qui s'applique ou non à la ponctuation, etc. C'était plus une lettre ouverte pour sensibiliser à ces questions.
Et finalement Ana Tudor nous a complétement bluffé en nous faisant faire des cos et sin pour dessiner des tracés chromatiques à coup de boucles en Sass.
Conclusion
Toutes ces conférences l'ont très bien rappellé : le langage CSS est riche, et il est possible de faire des choses formidables avec, mais il est aussi complexe à comprendre et demande de s'y plonger avec sérieux. Nous devons mettre en œuvre pour CSS toutes les bonnes pratiques que nous utilisons déjà pour les autres langages : modularisation, clean code, API publiques, tests unitaires.
Cela est d'autant plus important que le CSS est la partie partagée entre les développeurs et les designers, et celle-ci se doit d'être la plus claire et robuste possible pour la cohésion du projet au sein des équipes et sa maintenabilité sur la durée.
J'ai testé le meetup Vim pour la première fois. Ca faisait quelques fois que je voyais passer ça mais j'avais jamais eu l'occasion d'y faire un tour. Au final j'ai passé une soirée très sympa, même si ce n'était pas du tout le type de meetup auquel je m'attendais.
J'ai plus l'habitude d'aller dans des meetups où plusieurs speakers présentent devant une assemblée. Là, on était en tout petit commité (7 personnes), dans une salle équipée d'ordinateurs et d'un vidéo projecteur pour partager nos écrans.
L'idée initiale était que chacun puisse présenter les plugins ou astuces qu'il utilise. Au final, on a très vite dérivé, on a discuté, on s'est expliqué des choses et on s'est lancé des défis à la Vimgolf.
J'ai pas pu rester jusqu'au bout, pour l'apéro entre vimeurs ensuite, mais la soirée était bien sympa. Les prochains meetups semblent s'organiser pour prendre la forme de petits exercices à la Vimgolf, à faire à plusieurs pour s'entrainer et s'entraider. J'y retournerai sans doute à l'occasion, et vous devriez en faire de même si vous débutez sur vim.
Pour ce NodeJS Paris S02E02, nous avons eu le droit aux joli amphis de l'école 42, avec ses poufs multicolores (et inconfortables). Pas de dossier, donc pas très pratique de prendre des notes.
Comme d'hab, on rappelle le but du meetup (on parle de javascript en général, et de node en particulier). Présentation du site web, de comment proposer des talks, etc, etc.
Puis se sont enchainés plein de sponsors, beaucoup trop. Si encore il y en avait eu un ou deux, j'aurais pu écrire quelques mots sur chacun mais là il y en avait bien trop. Le meetup commençait officiellement à 19h, mais je pense que le premier orateur n'a pas du prendre la parole avant 20h au moins.
En vrac, Marceau Innovation (qui n'a pas beaucoup innové pour trouvé son nom) qui aide des français à partir s'installer à la Silicon Valley. Captain Dash (qui ont un très joli logo), qui font de la dataviz à partir des données des clients. Puis Digital & You dont je n'ai rien compris au pitch. Et puis je crois qu'il y avait encore d'autres sponsors ensuite mais franchement j'ai arreté de suivre.
On a quand même ensuite pu commencer les choses sérieuses, et tant mieux car le programme était très intéressant : Cassandra, Testing Asynchronously, Breaz.io et Freelance Academy.
Cassandra
Présentation de Duy Hai Doan, évangéliste chez Datastax, l'éditeur de Cassandra. Je ne connaissais pas grand chose à Cassandra mis à part que c'était une DB NoSQL. Je vais donc essayer de récapituler ce que j'en ai compris, parce que ça avait l'air bien !
Donc Cassandra, ou C* pour les intimes, a été créé chez Facebook avant d'être open-sourcée en 2008. C'est une base dont le point fort est la scalabilité linéaire : il suffit de rajouter des nœuds pour scaler. Ils visent un uptime de 100%, même pendant les upgrades. Elle est actuellement utilisée par Netflix et possède un principe de multidatacenter out of the box, avec des facilités pour déployer sur Amazon.
Autre avantage mis en avant : la simplicité opérationnelle. Il n'y a qu'un seul processus Java et un fichier de config.
On a eu ensuite droit à un exemple de fonctionnement. Imaginons que Cassandra tourne avec un cluster de X nœuds (8 étant le nombre utilisé dans l'exemple), alors chaque donnée est enregistrée sur un des X nœuds, grâce à un hash qui permet de toujours pointer vers le même nœud pour la même donnée. Si jamais notre charge augmente, on a juste besoin d'ajouter des nouveaux nœuds et les nouvelles données seront réparties sur plus de nœuds.
Pour assurer un bonne tolérance aux pannes des nœuds, la donnée de chaque nœud est répliquée sur les deux nœuds voisins. Ainsi, si un nœud tombe, sa donnée n'est pas perdue et peut être récupérée depuis les deux nœuds voisins. Pour assurer un maximum de cohérence, à chaque requete un nœud est dédié à une tâche de coordinateur, pour indiquer sur quel nœud la donnée peut être trouvée.
Il est possible de définir pour cela trois niveaux de cohérence : ONE, QUORUM ou ALL. Ces règles s'appliquent autant pour la lecture que pour l'écriture.
En mode ONE, on envoie l'écriture de la donnée aux trois nœuds qui peuvent la stocker et dès que l'un des trois l'a enregistré, on rends la main. Les deux autres nœuds l'enregistreront aussi, mais plus tard, et c'est le plus rapide qui rends la main.
En mode QUORUM, on attends qu'une majorité stricte ai validé l'enregistrement avant de rendre la main.
Et en ALL, on attends bien sur que tous les nœuds aient enregistré la donnée.
En lecture en ONE, on va aller lire sur le nœud le moins chargé au moment de la lecture (chaque nœud garde en local une table de statistique de temps de connexion aux autres nœuds, et celui qui a la latence la plus basse sera choisi en priorité).
En lecture QUORUM, on va lire depuis un des nœuds aléatoirement, mais les deux autres nœuds vont nous donner un hash de la donnée. Si les hashs concordent, on rends la main. Sinon le coordinateur var récupérer la bonne donnée sur le nœud qui l'a mise à jour le plus récemment, et va mettre à jour les deux autres nœuds.
Le langage de requête est très proche du SQL en terme de syntaxe, mais ce n'est pas du SQL, c'est du CQL. La primary key de chaque donnée sera son hash, ou clé de partition.
Oui mais tout ça c'est bien beau, mais c'est quoi le rapport avec NodeJS ? Ben juste qu'il existe un driver nodejs pour Cassandra.
Ce qui est couteux en Cassandra c'est l'ouverture des connexions à la base, du coup le driver va maintenir des pools de connections ouvertes sur chaque nœud (2 par nœud). Le driver est optimisé pour paralleliser les requêtes pour en lancer plusieurs sans avoir à attendre le retour de chacun.
Il est possible d'identifier un ensemble de requêtes par un unique streamID, et pouvoir ainsi récupérer toutes les réponses en même temps, de manière à faire de grosses économies en terme de latence. J'avoue que j'ai un peu moins bien suivi cette partie.
Le driver est au courant de la topologie du cluster (nombre de nœud, latence, etc). Des events sont lancés quand un nœud tombe ou revient à la vie. Il a des fonctionnalités de load-balancing entre plusieurs data-center par défaut. Il s'assure aussi que les connections vers les nœuds ne timeout pas. Si une connection part vers un nœud mais que celui-ci est tombé, alors plutot que de renvoyer une erreur le driver va réutiliser la même connection pour renvoyer la même requête vers un autre nœud porteur de la même donnée. La requête sera certes plus lente, mais elle ne sera jamais tombée en timeout.
Coté code, ça signifie créer un Cassandra.Client en lui donnant l'ip ou l'adresse de quelques nœuds du cluster, et il se chargera de découvrir tous les autres et dresser la topologie complète du cluster. On lui envoie ensuite nos requêtes en CQL, et on obtient un callback quand les données sont revenues. Comme souvent, pour économiser les temps de traitement, on donne notre requête sous forme de string avec des placeholders pour qu'elle soit optimisée derrière au moment de la jouer.
Vu qu'on est en node, le driver est aussi capable de streamer les résultats renvoyés. En interne il utilise un principe proche du cookie, pour se souvenir de sa place dans le stream et rejouer à partir de ce point. Dans les faits cela permet de continuer un stream même quand le nœud émetteur est tombé, on peut simplement continuer la même requête sur un autre nœud. Grâce au cookie, on reprends le flux au même endroit. Par contre, si on écrit plus vite dans les données qu'on est en train de les lire, le cookie ne nous permettra pas de voir tout.
Cassandra fournissant plus de types de donnée que ne le permet Javascript, le driver fourni aussi des helpers pour passer ces types complexes en Javascript.
Après ce long exposé très intéressant, on a eu le droit à quelques questions/réponses. Quelques limitations du driver actuel ont été soulevés comme par exemple le fait que les opérations comme des count ou des sommes sur la data ne peuvent pas être faite directement dans Cassandra. Il faut récupérer la donnée et effectuer cette opération dans le driver. Les prochaines versions du driver devraient corriger ce soucis.
Async is hard, test it harder
Après ça, Florent Jaby est venu nous parler de tests en NodeJS, et plus particulièrement de tests de code asynchrone.
Le sujet des tests en Javascript est assez bien documenté, mais quand on en vient à tester de l'asynchrone, il y a tout à coup beaucoup moins de littérature disponible.
Bon, on commence rapidement par rappeller les fondamentaux de pourquoi on teste : boucle de feedback plus rapide, non-regression et design émergent. Un bon test est isolable et reproductible.
Sauf que derrière tout ces beaux principes on a quelques soucis en Node. Il est difficile de savoir quand un test se termine vu que tout est asynchrone. Est-ce que mes requêtes sont pending ou est-ce qu'elles vont bientot arriver ? Est-ce que tout ce que j'ai lancé est bien revenu ? Est-ce que je termine mon test ou j'attends plus longtemps ?
Et puis surtout, on a un problème de stacktrace avec l'event loop de node. A chaque itération on est dans un contexte différent, du coup les mécanismes classiques de try/catch ne fonctionnent pas. On a plusieurs approches pour contourner ce problème.
On peut par exemple déclarer manuellement la fin du test comme le fait Tape ou NodeUnit. On appelle une méthode .end() pour signifier qu'on a assez attendu et qu'il est temps de terminer le test. Mocha propose aussi une méthode done à appeller quand le test est censé être terminé.
Une autre méthode est de planifier les assertions. On prévient qu'il va y avoir x assertions, et on les mets directement dans les callbacks. Du coup, le test s'arrete automatiquement dès que les x assertions sont sorties.
On peut aussi passer par des domaines, pour wrapper nos appels. On peut faire des try/catch dessus et donc attraper les exceptions et balancer un done quand ça arrive pour marquer la fin du test. Ca marche bien, ça nous donne les bons rapports d'erreurs sur les bons tests, mais c'est pas très lisible.
Un moyen un peu meta de rendre tout ça plus lisible est de modifier la méthode it pour qu'elle wrappe son contenu dans un trycatch/domain. Ca nous fait revenir à une syntaxe plus lisible.
La fin du talk était plus sur les outils annexes aux tests comme jshint ou istanbul. JSHint n'est plus à présenter et permet d'appliquer des règles configurables de standard de code à appliquer et de vérifier les erreurs de syntaxes et les pitfalls communs de Javascript.
Istanbul de son coté est un outil de couverture de code qui va nous sortir de beaux rapport indiquant les lignes de code qui sont parcourues quand on lance nos tests. On peut comme ça voir les parties du code qui ne sont pas testés. Ca permet de voir ce qu'il reste à tester, ou même parfois à identifier du code mort. Il calcule aussi la complexité cyclomatique du code, qui donne une estimation de la difficulté à le maintenir (globalement s'il n'est pas modulaire, avec des méthodes de 100+ lignes et des if imbriqués, c'est mauvais signe).
Finalement, Florent termine par un conseil à ceux qui testent des streams. Ne perdez pas de temps à tout tester, les streams sont très bien testés en interne dans NodeJs, inutile de le faire. Il n'est nécessaire que de tester la méthode pipe, ce qui rentre et ce qui sort. On mets tout dans un buffer et on test à la fin.
Breaz.io / Developers in tech
Je vous renvoie à mon compte-rendu des HumanTalks précédent, Jean-loup y a donné à peu près le même talk.
Freelance Academy
Et pour finir, Etienne Folio nous a parlé de la société de coaching de freelance qu'il vient de monter. Il est lui même passé freelance plus tôt dans l'année et peut se targuer d'avoir un TJM à 4 chiffres, tout en ne travaillant que 6 mois par an.
Il a monté Freelance Academy avec la promesse d'aider les développeurs qui veulent se lancer en freelance mais qui ont peur du légal, de l'administratif, de la compta, de trouver des clients, etc. Il propose un stage de coaching de quelques semaines, suivi d'une année complète de formations (quelques jours par mois). Tout ça gratuitement. Il s'engage même à payer la différence de revenu entre le freelance et le salariat pour ceux qui se lancent, assurant à chacun un revenu au moins égal à celui qu'il avait en CDI.
On a été plusieurs à se demander où était l'arnaque. En fait, c'est tout simplement que si jamais le nouveau freelance gagne plus que son ancien salaire, il repaye la différence à Freelance Academy. Il est assuré de toucher autant en un an que ce qu'il gagnait avant, mais l'excédent n'est pas pour lui pendant un an. Ensuite, libre à lui de continuer son activité de freelance avec son nouveau TJM.
L'idée est intéressante, et le freelance, bien fait, peut être très agréable. Néanmoins, le coté "je te donne un cadeau et oh, tu l'a accepté maintenant tu m'est redevable" me rebute dans son histoire. Mais pour en avoir discuté avec lui ensuite, il vise essentiellement les développeurs qui ont peur de se lancer, qui disent vouloir faire du freelance depuis des années mais qui n'ont jamais laché la facilité du CDI. Avec l'assurance du salaire qu'il propose, il espère pouvoir leur donner confiance.
En tout cas, ça m'a fait me rendre compte que je faisais du freelance n'importe comment quand j'en faisais :)
