Retour sur Blend Web Mix 2015

Retour sur Blend Web Mix 2015

Blend Web Mix, c'est la conférence Lyonnaise du Web. C'est une chance d'assister à des des conférences enrichissantes et motivantes, de rencontrer des gens intéressants, le tout dans le cadre toujours très agréable de la cité internationale. Cette année encore, l'édition a été riche en enseignements. Retour sur les conférences auxquelles j'ai assisté, et ce que j'ai pu en retirer.

Ces deux jours commencent avec la pleinière d'introduction, histoire de se mettre dans l'ambiance. Quelques mots de l'organisateur sur l'édition précédente, et on voit débarquer une bande de zombies. Si si pour de vrai, Walking Dead en direct de l'amphi.

Passé l'effet de surprise, quelques mots sur l'organisation des 2 jours, le plan des salles afin de se retrouver dans l'auditorium, et c'est parti.

JS: Stack Overdose

@naholyr Jour 1 - 10h30

J'ai voulu aller voir cette conférence car son sujet est au centre de pas mal de discussions dans notre milieu en ce moment. Faire du dev front, est-ce devenu trop complexe en termes d'outils, de méthode, de veille? Est-ce que c'était pas mieux avant?

Personnellement je suis plutôt pour l'outillage intelligent qui répond au besoin qu'on a spécifiquement, plutôt que de faire un déni d'outil en bloc, ou de suivre la tendance à fond et d'être un early adopter de tout.

Ce que j'ai pu retenir
  • Est-ce qu'on a vraiment plus d'outils qu'avant?
    Probablement un peu plus, mais si on regarde bien, on a aussi pas mal de remplacement d'outils qu'on utilisait avant. Par exemple, mettre en prod ses fichiers en ftp à la main, puis tester les pages versus une procédure d'intégration continue. Etait-ce vraiment mieux avant? La concaténation et la minimification manuelle vs automatique, était-ce vraiment mieux avant?
  • Est-ce qu'on a de la complexité en plus?
    Des librairies, des frameworks, des packages managers, des tasks runners, des transformateurs, on en peut plus!
    On amène effectivement de la complexité, surtout au début du projet. Avant on pouvait inclure un JS, et se mettre au travail dedans en 5mn. Aujourd'hui, on configure un gestionnaire de dépendance, on descend des frameworks, on configure un builder, un transpiler... Mais une fois que c'est fait par contre, on a tendance à en gagner du temps.
    //Et il ne faut pas oublier de mettre dans la balance que la complexité des projets auxquels on fait face a augmenté elle aussi. La taille de nos équipes peut être aussi. S'outiller correctement, n'est-ce pas un investissement finalement? On investit du temps au début pour gagner du temps de production, ainsi que de maintenance.
  • Il est temps de faire le tri. Mais comment?
    • Ralentir, prendre du recul. On est pas obligé de se jeter sur le nouvel outil qui sort tous les 15 jours. On peut le mettre de côté pour plus tard. Si jamais il nous est demandé d'avoir la compétence, on peut l'acquérir, même plus tard.
    • Il faut apprendre des concepts, pas des outils. Par exemple, au moment ou angular est sorti, il introduit un nouveau paradigme: le binding. Si un nouveau framework sort avec le même paradigme, pas besoin de sauter dessus. Quand React est sorti, il introduit le virtual DOM et le one flow direction, c'est nouveau. Riotjs par contre, c'est le même concept. Si on le maîtrise une fois pas besoin de se jeter sur tous les frameworks qui s'appuient dessus. RxJs et BaconJs = même concept -> l'observable.
    • On peut s'appuyer sur des métriques, pour avoir une aide au tri. Ces métriques pourront me dire si je dois consacrer du temps au nouveau framework, si il va me rendre service, par rapport à sa complexité, si il va vraiment améliorer mon quotidien... etc //Je vous recommande les slides sur l'aide au tri avec les formules de métriques, c'est un point de vue intéressant.
    • //Et encore une fois, pour maîtriser sa stack, rien de tel que de lui faire répondre à des besoins réels. Si vous faites des sites tout simple en one page et que vous êtes seul à travailler dessus, vous n'avez peut être effectivement pas besoin d'investir un temps trop conséquent dans une stack qui sera trop lourde pour vous. C'est aussi valide au delà du JS, pour les CSS vs SASS-LESS-COMPASS-POSTCSS par exemple, ou même les fondements backends où là aussi les frameworks sont légion.

Stratégies d’adaptation mobile : ergonomie, UX et performance en milieu périlleux

@WalterStephanie - @theystolemynick Jour 1 - 11h30

J'avoue, pour cette conférence, j'ai autant voulu y aller pour le sujet (tous les sites qu'on sort chez NOE sont multi support), que pour voir Stéphanie et Jean-Pierre "en vrai" :) . C'est encore une fois l'occasion d'avoir des points de vue d'experts sur un sujet précis. Bon ok cette phrase est valable pour toutes les conférences de ces deux jours en fait. Là en l'occurence, on a en parallèle le point de vue du design, et de la performance et je trouvais cette promesse intéressante.

Ce que j'ai pu retenir

On parle de stratégies d'adaptation mobiles, 3 nous ont été présentées:

  • Le site mobile dédié.
    • On fait un deuxième développement. Ce deuxième développement peut être plus rapide à faire que de refondre le site principal totalement. On a un contrôle total de l'expérience que l'on propose à l'utilisateur, elle sera résolument adapté au mobile.
    • Attention cependant à la continuité de l'expérience entre le site desktop et le site mobile. L'utilisateur s'attend à retrouver ses contenus et ses fonctionnalités. Sur du plus long terme, on va devoir coder chaque fonctionnalité en double, c'est donc peut être plus rapide à coder au début mais la maintenance va être plus difficile.
    • Et les tablettes dans tout ça? On leur propose quoi?
  • Le responsive retrofitting.
    • On essaye de faire rentrer le contenu d'un site desktop sur mobile -> ça risque de déborder
    • On peut arriver à un résultat relativement rapidement mais ça va être lourd. Ca ne sera pas du tout optimisé pour le mobile car pas conçu pour à la base.
  • Le mobile first. Point clé: On enrichit le contenu et l'expérience utilisateur en fonction de la place et des capacités du device
    • On prend vraiment en compte les capacités des appareils, on est dans l'expérience multi support avec un site unique.
    • Conséquence, ça nécessite un développement plus costaud, voire même une refonte totale, c'est plus difficile techniquement, et plus coûteux.

La deuxième partie de la conférence fut axée sur le mobile first justement, et comment se donner les meilleures chance que cette stratégie porte ses fruits

  • Il y a pas mal de travail à faire en amont déjà.
    • On va prioriser le contenu, les informations qu'on veut afficher. On va travailler sur le dénominateur commun.
    • On va se mettre d'accord aussi. Est-ce que tous le monde à les mêmes objectifs? (Contenu, performance, compatibilité, temps d'attente.
    • On prévoit un inventaire d'interface pour identifier les éléments qui vont poser des soucis de responsive (tableaux, menus, vidéos etc)
  • On optimise les temps de chargement, ainsi que le poids des assets à télécharger. Ca se mesure et ça se montre. On peut lazy laoder les images, les pubs, les polices.
  • On prend en compte les capacités du device
    • Attention notamment aux interactions hover, car sur touch on aura pas accès à la fonctionnalité.
    • On ne fait pas qu'enlever des fonctionnalités dans le mobile, on a aussi des capacités en plus, comme le multi touch, la géolocalisation, l'accès à la caméra, au micro, le offline, les pushs... Et tout ça peut nous permettre d'enrichir l'expérience mobile aussi.

PHP 7 arrive

@julienPauli Jour 1 - 13h30

Et oui PHP7 arrive en novembre 2015. On y est quoi. Et du coup je voulais savoir via cette conférence, ce que ça va impliquer pour NOE interactive, sachant qu'on s'appuie sur un framework PHP objet interne. Et-ce qu'il va y avoir des soucis de compatibilité? Il parait que c'est une version résolument orienté performance, et-ce que c'est vrai?

Ce que j'ai pu retenir
  • On est sur un cycle de version où l'on sort une version majeure tous les 5 ans. Comme toute version majeure, il y a du refactoring, et des changements dans l'API. Des choses peuvent casser, mais en tout cas on ne touche pas aux arguments des fonctions.
  • Aujourd'hui il faudrait idéalement être en PHP 5.6 en prod. Si on est en v5.3, 5.4 ou 5.5, il faut migrer.
  • Il va être possible de try catcher les Fatal errors comme des exceptions. Si je met un try catch, et qu'une fatal se produit, je peux la capter, si je le fais pas, on aura le comportement classique comme d'habitude.//C'est bon ça!
    Plus de précisions sur le sujet: Les exceptions du moteur (donc les erreurs) ne vont pas hériter directement des exceptions utilisateurs (les exceptions habituelles). Elles implémentent l'interface throwable. Donc Exception étend aussi throwable (qui est l'interface mère). Error est donc une soeur de Exception. Il faut faire un catch(throwable $e){} pour toute les chopper. On ne peut pas faire hériter throwable. (slides 17 à 23).
  • On aura de nouveaux opérateurs, comme le '??', qui va raccourcir le ternaire. //Je l'utilise beaucoup le ternaire et c'est vrai que ça sera plus pratique ce '??'. Exemple slide 15.
  • Autre nouvel opérateur: le spaceship, ou combined comparison: <=> On l'utilise avec 2 valeurs: $a<=>$b Et ça retourne -1 si $a est inférieure à $b, 0 si les deux variables sont égales, et 1 si $a est supérieure à $b. //Je ne vois pas forcément de cas d'utilisation dans notre codebase actuelle mais c'est toujours intéressant d'être au fait d'un opérateur.
  • On va pouvoir déclarer le type de retour d'une fonction. Et si ce type n'est pas respecté, ça fera une fatal. Si la val est transtypable, PHP va le transtyper, sinon fatal.

Voilà pour les nouveautés, voyons maintenant les choses qui peuvent casser al compatibilité avec les anciennes versions. J'ai surtout pris des notes sur les potentiels impacts que ça pourrrait avoir sur le framework PHP de NOE.

  • La manière dont les variables dynamiques sont interprétées a changé. (Slide 43)
  • Plusieurs choses vont être supprimées: call_user_method et call_user_method_array vont disparaître, plus de tags ASP <%, plus de &new par référence,plus de $HTTP_RAW_POST_DATA.
  • Dans les php.ini, les commentaires doivent être des ; et pas des #
  • Removed support for scoped calls to non static methods (Slide 48)
  • Plus de constructeurs à l'ancienne (cad une fonction avec le même nom que la classe).
  • func_get_args retourne l'état du paramètre au moment ou il est retourné, pas celui passé au début

Le mot de la fin: PHP7 sera au moins 2 fois plus rapide! Il utilisera 2 fois moins de CPU et plus de deux fois moins de mémoire. Et Bim! (pose le micro). Il sera disponible courant novembre 2015.

Une conférence intéressante. On voit qu'il y a pas mal de nouveautés à apprendre, et des cas de figure à vérifier dans nos bases de code existante afin de régler des soucis de compatibilité.

Comment scaler une team technique dans une startup en hyper-croissance

@florianjourda Jour 1 - 14h30

J'ai vraiment hésité entre cette conférence et celle de l'architecture modulaire à la BBC par Thomas Parisot. Vu qu'en tant que lead dev, je touche un peu du doigt des concepts de management, je me suis dit que ça serait intéressant d'avoir d'entendre des choses à ce sujet là aussi pour changer un peu des conférences tech.

Florian Jourda revient de 10 ans passés aux Etats Unis, où il a travaillé chez Box, une société de stockage de fichiers dans le cloud, dès leur tout début. Il nous raconte son expérience du passage 7 à 1300 employés, l'état d'esprit qui règne chez Box, et les bonnes pratiques à mettre en oeuvre.

Ce que j'ai pu retenir de l'état d'esprit
  • Il faut avoir un mindest d'abondance, pas de rareté. En France on a plutôt une culture féodale, aux US, une culture de colonisation, où il vaut mieux s'associer pour réussir. On parle aussi de culture de coopétition (coopération + compétition).
  • Avoir/Etre un project manager, c'est la pire manière de scaler. Il vaux mieux empowerer. En effet, si le manager doit tout micro manager, on avance pas. Il faut un manager au service de l'équipe et non l'inverse.
  • Un CEO ne créé pas un produit, mais une organisation qui va créer un produit.
  • Un leader est quelqu'un qui se rend inutile le plus vite possible, pas un héros. Il faut apprendre à déléguer, mentorer.
Ce que j'ai pu retenir des bonnes pratiques
  • Pour aller plus vite, le parallélisme n'est pas forcément la bonne solution. Pour accélérer, il vaut mieux accélérer une tache que paralléliser. Par exemple, si on a 3 développeurs et 3 projets différents. Si on fait du parallèle strict, c'est difficile de faire des codes reviews. Si une personne part, on a plus de ressource sur un projet, c'est un Single Point of Failure (SPoF). Il faut se focaliser sur finir les projets, pas les commencer
  • Il faut passer du temps à écrire les choses: ex faire un design doc. Voilà les objectifs, les contraintes. C'est un document que tout le monde peut voir. Bon pour être sur de sur quoi on parle. Super pour faire monter les gens en compétence (ex les juniors) Pour prendre une décision, on documente le but, les choix qu'on avait, le contexte etc.
  • Meta travail, améliorer continuellement l'équipe grâce aux meetings de rétrospective -> le meeting le plus important et de loin!
    Il faut tenir un document de suivi de projet -> tout ce qui se passe bien, ou pas bien. Anonyme, public. Très utile pour la retrospective justement.
  • Faire du relationnel plus souvent. Ne pas couver les problèmes humains jusqu'à ce qu'ils explosent.
    Etape 1, on exprime le problème, Etape 2, on va le résoudre, Etape 3, c'est même toi qui va le résoudre.
    C'est TON bateau. C'est TA responsabilité, peu importe ton niveau si tu vois un problème de faire en sorte que ton bateau n'en souffre plus.
    Empowering de l'équipe, faire monter les gens en compétence.
  • Ne pas avoir peur d'embaucher des gens meilleurs que soi, "As hire As, Bs hire Cs". Ils vont tirer vers le haut.
    Le recrutement devient un vrai process à ce niveau, il faut matérialiser les étapes, les questions les tests. Permet à plusieurs personnes différentes de s'en occuper. Permet d'avoir une grille d'évaluation commune et moins subjective.
  • Faire des Performance revue, tous les 3 mois car 1 an c'est trop long. Quel impact tu as eu sur ces 3 derniers mois par rapport à ton niveau dans l'entreprise? Si on est en dessous -> aider de manière bienveillante à remonter. Si ça remarche pas -> c'est là qu'on prend des décisions de sanction.
    Un bon feedback -> timely, factual, actionnable
    Pour passer au niveau au dessus, il faut attendre que les personnes délivrent régulièrement au niveau au dessus. Sinon il vont monter, et pas être au niveau finalement, et échouer au niveau au dessus.
    Pour accompagner un changement de culture, il faut beaucoup de communication et de suivi.

Je ne regrette pas d'être resté à cette conférence qui était super. Pour moi c'était même la plus intéressante des 2 jours. J'ai bien fait de rester!

Deep-dive dans ES6

@porteneuve Jour 1 - 16h00

Ha l'ES6. Sujet en vogue. On en voit partout, on en entend partout, et vu que je me sentait un peu en retard de veille sur le sujet je me suis dis que c'était l'occasion de se faire expliquer de vive voix ce que ça apportait.

Ce que j'ai pu retenir
  • Aujourd'hui les navigateurs ne supportent pas tous la syntaxe, mais c'est pas grave, car à partir du moment où l'on dispose d'un runtime ES5 (en gros tous les navigateurs à partir de IE8), on peut utiliser Babel pour convertir l'ES6 en ES5 de manière automatique.
  • Pourquoi donc l'utiliser? Plus facile, Plus puissant, Plus fiable, Plus performant. //Forcément vu comme ça ^^.
  • On a une nouvelle syntaxe pour faire des classes. C'est seulement du sucre syntaxique, pour que ça soit plus joli à l'oeil et plus simple à appréhender quand on vient d'autres langages. En effet, derrière, les fonctionnalités existaient déjà (via prototype).
  • On a des objets littéraux. On est plus obligé de faire des var params={ id:id, nom:nom };, on peut faire var params = { id, nom };. C'est pareil.//Ha oui ça sera plus propre et plus rapide dans pas mal de cas.
  • On a des fonctions de déstructuration. (Slide #destructuring)
  • Rest et Spread, on prend une var qu'on éclate en tableau, ou inversement.//Effectivement ça réduit pas mal le code, ça peut être pratique.
  • On va pouvoir mettre des valeurs par défaut dans les arguments de fonction.//Yesss
  • On va pouvoir faire des template strings.//Sympa ça aussi. On fait des templates strings en utilisante le back tick `. Ca supporte l'interpolation et le multiligne.
  • On va pouvoir faire des fonctions fléchées. C'est commune une fonction anonyme, mais ces fonctions ne redéfinissent pas le this comme les fonctions classiques. Elles utilisent celles de la closure. C'est valables pour les mots clés this, arguments, super, new.target. On ne peut pas la binder.//Et là encore on est sur une syntaxe plus concise qui nécessite moins de code à écrire.
  • De nouvelles manières d'instancier des variables: let & const. Une constante est un variable qu'on affecte une et une seule fois. Mais ce n'est pas un freeze. On peut quand mm travailler avec. Const is the new var car a part les compteurs généralement on affecte une valeur à une var une fois puis on ne la change plus de la closure. Avec let, la variable a sa propre closure. Cas de figure utile, si on fait un for avec un setTimeout le compteur i aura bien la bonne valeur dans la fonction appelée par le SetTimeout comparé à une var.
  • Enorme avantage d'ES6 -> les MODULES. On peut définir des modules, les exporter, en importer des bouts. Tout fichier est un module, tout est donc privé au fichier, on ne pollue pas le scope global. C'est vers ces modules ES6 qu'on va. Pour les utiliser aujourd'hui, on peut utiliser System JS, un outil transitoire. C'est un module loader qui te permet de faire cohabiter tous les types de module (global, amd, common js,...).
  • ES6 c'est aussi top pour l'asynchrone. On va pouvoir faire des promesses. Réduit les cas de figure du callback hell. On pourra aussi écrire des fonctions asynchrones. async : permet d'avoir comme un traitement bloquant (genre dans une boucle while), mais peut rendre la main au niveau CPU donc c'est super pour les performances.

Pas évident cette conférence quand tu découvres ES6, mais effectivement très intéressant. J'ai l'impression qu'ES6 apporte pas mal de clarté. On a moins de code, plus de déclarations explicites, moins de cas de figure alambiqués (callback hell), plus d'organisation (modules) plus de perf. Je vais m'y pencher plus sérieusement. Mais par où commencer? J'aurais peut être des réponses dans la conf ES6 par le code.

Concevez rapidement vos applications mobiles grâce au développement hybride

@steffy_29 Jour 1 - 17h30

On utilise Ionic pour nos développements mobiles chez NOE. J'allais donc à cette conférence en connaissant de quoi il s'agissait, mais en espérant en apprendre d'avantage vu son classement intermédiaire, et curieux d'voir le point de vue de l'auteur.

Ce que j'ai pu retenir
  • Ionic c'est 3 couches
    • L'interface, qui s'appuie sur Ionic framework
    • La logique métier, qui s'appuie sur Angular
    • La couche plateforme, qui s'appuie sur Cordova
  • Ionic embarque sa propre interface de commande, mais si on aime pas, on peut essayer Ionic lab
  • Angular s'appuie fortement sur Angular, donc quid d'Angular2? Ils ont annoncé Ionic 2 qui sera compatible Angular 2.

C'est tout? Bon c'était une conférence relativement courte (25mn) donc c'est vrai que le format ne permettait pas de rentrer profondément dans les détails, mais je dois dire que j'ai été plutôt déçu de cette conférence. On était plus dans la présentation de Ionic que dans son utilisation, et forcément quand tu sais déjà ce que c'est, tu ne ressort pas avec grand chose de plus.

Si vous ne connaissez pas Ionic, je le recommande fortement par contre, et vous trouverez surement des choses utiles dans les slides.

Amélioration progressive de la théorie à la pratique

@goulvench Jour 2 - 09h30
Ce que j'ai pu retenir
  • La base c'est le HTML. Il faut commencer par cette base, respecter cette base, et faire en sorte qu'elle fonctionne sans dépendre de JavaScript. On ajoute ensuite des améliorations pour ceux qui peuvent les gérer.
  • Ne soyez pas une dépendance, votre code non plus. Votre code doit participer à l'amélioration mais pas être indispensable.
  • Ajax include third part scripts. On attend que la page complète soit affichée pour réintroduire les third parts.
  • Quelques exemples:
    • Vous voulez faire un autocomplete? Pensez aux attributs lists et datalist
    • Vous voulez styler des inputs radios ou checkbox? On peut faire des trucs chouettes sans js input[type=radio] + label
    • On peut filtrer une liste avec le selecteur ~ (Slide 20)
    • On peut faire un carousel en pur CSS avec labels + radios (Slide 22)
    • Pour réaliser un ajout au panier: bien utiliser un formulaire, si on a du JS, on peut intercepter le form submit, envoyer les données en ajax, faire une animation etc. Mais si on a pas de JS, vu que c'est un formulaire, ça marchera quand même.
  • Les 4 commandements:
    • Ne pas imposer de dépendances (ex webfonts, charger de manière progressive).
    • Commencer par la couche HTML, avoir un HTML le plus propre possible.
    • Rajouter les events JS par dessus pour améliorer l'expérience.
    • Donner des retours visuels.

Flexrox

@goetter Jour 2 - 10h00

Une conférence donnée par Raphaël Goetter en personne, ça ne se rate pas, d'autant plus sur un sujet qui nous touche directement. Derrière flexbox se cachent pas mal de concepts. C'est l'occasion de faire le tour de la question.

Ce que j'ai pu retenir
  • Flexbox en fait c'est 4 concepts: la distribution (horizontale ou verticale), l'ordonnancement, l'alignement, et la flexibilité.
  • Selon CanIUse on est à 97% de compatibilité. Non supporté par <IE10.
  • La distribution, c'est la gestion dont les éléments sont distribués dans leur parent. C'est géré par flex-direction, par défaut l'axe principal est horizontal. On peut inverser l'ordre (row=defaut, row-reverse, column, column-reverse).
  • Avec flex-wrap:(wrap|wrap-reverse), on peut contrôler si les éléments débordent de leur conteneur ou non.
  • On peut changer l'ordre d'un élément avec order. Si c'est 1, il sera après les autres, si c'est -1 il sera avant (Slide 30)
  • Pour l'alignement, on peut contrôler l'alignement sur l'axe principal via justify-content:(flex-start|flex-end|center|space-between|space-around) (de la distribution), et/ou l'axe secondaire via align-items:(flex-start|flex-end|center|stretch).
  • Pour la flexibilité, on peut dire aux éléments qu'ils peuvent se réduire ou s'agrandir selon l'espace disponible grâce à flex-grow:(0|1), si c'est 1 tu peux t'agrandir. Et flex-shrink:(0|1), si c'est 1 tu peux te rétrécir. Avec flex-basis, on peut définir une taille par défaut avant que l'élément ne soit distribué. Et en fait ces 3 propriétés sont regroupées sous flex: flex-grox flex-shrink flex-basis. Donc si vous voyez quelque chose comme flex: 1 1 200px, ça veut dire qu'on autorise l'élément à s'agrandir si on a assez de place, à se rétrécir, et que par défaut il fait 200px.
  • Suivant la distribution dictée par flex-direction, flex-basis sera la hauteur si on est dans une distribution verticale, et la largeur si on est dans une distribution horizontale.
  • Pour utiliser Flexbox en prod on a besoin de pas mal de préfixes. Ca vaut le coup d'utiliser un autoprefixer.
  • Ressources utiles à checker en cas de bug: Solved by Flexbox de Philip Walton

Merci à Raphaël Goetter d'avoir démystifié un sujet complexe de manière aussi claire. C'est vrai qu'une fois qu'on a compris les 4 concepts on a fait un grand pas.

Découvrir ES6 par le code

@Swiip Jour 2 - 11h30

Après la théorie de la conférence de Christophe Porteneuve, celle-ci me paraissait être un bon complément pour mettre le sujet en contexte.

On reprend tout de même quelques concepts:

  • let respecte les blocks comme les autres langages. C'est même pire, car un let dans un if ne fonctionne pas en dehors du if.
  • const veut dire que cette variable ne sera jamais réaffectée.
  • Les templates string avec le backtick: on peut faire des string multi lignes, on peut aussi faire des interpolations avec des ${}.
Ce que j'ai pu retenir de la mise en pratique
  • On commence par virer les var, que l'on remplace par des let ou des const
  • Classes et arrow functions. On peut utiliser le mot clé classe et se rapprocher de la syntaxe des autres langages. Le this de l'arrow function n'est pas redéfini, donc on peut utiliser celui de la classe.
  • Dans une classe, on peut virer les mots clés function pour les méthodes.
  • On place cette classe dans un fichier et on crée un module. On spécifie ce qu'on importe ou exporte des autres fichiers avec import et export.
  • Les modules ES6 ne marchent pas encore aujourd'hui: 2 stratégies -> common JS avec webpack et browserify, ou Système JS.
  • Résoudre le callback hell par les promesses chainées

J'ai beaucoup aimé la transformation du code en live ainsi que le look du fichier final qui est effectivement plus sympa que ce qu'il était au début. Je commence à aimer ES6 de plus en plus.

Chroniques d'un voyageur vers l'Est

@mageekguy Jour 2 - 12h00

Je dois dire qu'entre le titre ou la description de cette conférence, on ne savait pas trop de quoi ça allait parler à part que ça allait traiter de programmation objet, et que c'était présenté par Frédéric Hardy, le créateur d'Atoum. Suspens donc.

Ce que j'ai pu retenir
  • Merci Alan Kay pour le paradigme de la programmation Orientée Objet
  • Le vrai concept de l'Orienté Objet, ce n'est pas l'objet justement, mais le message.
  • Exemple de biologie cellulaire. Les cellules ne se connaissent pas, ne savent même pas que les autres existent. Une cellule dit, j'ai besoin d'oxygène, un autre capte le message, et y réagis. On voit bien que c'est le message la clé de tout, et que ça fonctionne sans que cette cellule ne connaisse les autres pour leur demander - ce qu'on fait encore trop souvent en PHP.
  • L'encapsulation, c'est le niveau maximum d'abstraction que l'on peut obtenir.
  • Le concept: le flot d’un programme orienté objet peut aller dans quatre directions. Ce qu'on veut c'est aller au max vers l'est (Slide avec la boussole).
  • Il y a plusieurs niveaux d'abstraction:
    • 1 je sais ce que je veux et je sais ce que tu fais.
    • 2 Je sais ce que je veux et je sais que tu le fais
    • 3 Je sais ce que je veux, et je te fais confiance pr faire ta part.
  • Pour avoir un haut niveau d'abstraction, il faut se mettre d'accord sur le message
  • Comment? Avec les interfaces. Notion de contrat, c'est le nerf de la guerre.
  • L'appelant est libre, c'est l'inversion de contrôle (IEC en anglais). On maximise le niveau d'abstraction

Assez complexe comme sujet, et même comme état d'esprit mais quand on commence à sentir les résultats c'est assez bluffant. Ca doit demander pas mal de pratique avant de tirer pleinement avantage de ces concepts.

Du 1er utilisateur au 10 000 000ème sans sueur froide. Et au-delàààà !!!

@adagues Jour 2 - 13h30

J'ai assez peu de connaissance en administration de systèmes, du coup je suis allé à cette conférence avec curiosité. C'est vrai ça comment ils marchent les sites mondiaux? Comment on fait pour scaler une architecture?

Ce que j'ai pu retenir
  • Phase 1: le scale up, c'est à dire le scale machine, on achète plus gros, plus de place, plus puissant. C'est le plus simple, mais aussi le plus cher. De plus on a toujours qu'un seul point d'entrée, une seule machine. On est sur du Single Point of Failure. Si on a une crise sur une stack comme ça, c'est déjà foutu.
  • Phase 2, séparer le serveur de code et de base de données. Ca va nous permettre d'utiliser des paternes de duplication MYSQL.
  • SQL vs nosql, analyser la pattern pour choisir le bon équilibre. Par exemple Nosql si jamais on parle de Go de bases
  • Phase 3, Gérer le FailOver, et coder StateLess. Avoir un load Balancer
  • Phase 4, Il faut du scaling vertical bien sur, mais surtout horizontal.
  • C'est déjà largement suffisant pour atteindre 100K utilisateurs. Après on passe un cap encore, c'est un autre niveau.

C'est intéressant de voir comment ça se passe le scaling. A partir de 100K utilisateurs ça devient assez vertigineux comme architecture.

"ça marchait pourtant en dev" : Du développement à la production

@ezameku Jour 2 - 14h30

Etant en pleine réflexion sur l'industrialisation de nos process de production chez NOE, cette conférence tombait bien dans le sujet.

Ce que j'ai pu retenir
  • Il faut exploiter tout le potentiel du versionning. Pour la sécurité - on ne perd pas le code. Pour l'historique des modifications - comprendre comment on en est arrivé là, voire même remonter les versions dans le temps. Faire un commit par fonctionnalité.
  • Ca permet aussi de déclencher des tests automatiques par trigger sur une branche précise (genre test ou perprod).
  • Il faut faire des tests et faire en sorte que chaque commit passe via les tests. Ces tests peuvent être unitaires ou fonctionnels, mais il faut absolument en avoir.
  • Se mettre d'accord sur un standard de DEV.
  • La mise en production est règlementée (Slide 13). Il faut créer un vrai processus de release.

Intéressant, surtout quand on se pose des questions, d'avoir un point de vue et un retour d'expérience pareil. Ca nous conforte dans la direction.

Pimp my frontend !

@LWiesel Jour 2 - 15h00

Une structure et un process sur un sujet qui nous touche directement. Là encore, des choses à piocher pour améliorer nos process de dev front. Laurent nous présente ça en prenant une base de code douteuse, et en la transformant petit à petit en quelque chose de plus correct, plus lisible, plus maintenable.

Ce que j'ai pu retenir
  • Il est possible d'avoir une approche incrémentale. Commencer par modulariser le CSS
  • Améliorer la réutilisabilité du code en utilisant notamment des variables.
  • Si on a des variables globales, les utiliser via des variables locales dans les fichiers, ne pas les utiliser directement, améliore la visibilité/maintenance/réutilisabilité.
  • Se mettre d'accord sur une nomenclature de nommage - ex BEM.
  • Adopter le design atomique.
    • 1) Quarks = Elements HTML purs
    • 2) Atomes Composants stand-alone = Assemblages de quarks
    • 3) Molecules - Composants de composants
  • L'atomic ce n'est pas que pour le CSS, mais aussi le HTML et le JS -> web components (ça arrive!)

Ca m'a donné envie de repenser la manière dont on structure nos CSS chez NOE, adopter une nomenclature précise, éclater encore plus les fichiers.

Replay sur la refonte front-end de 6play.fr

@kenny_dee Jour 2 - 16h00

Le fait d'évoquer un workflow front sur un projet d'une grosse envergure a attisé ma curiosité, mais à part ça je ne savais pas trop de quoi on allait vraiment parler.

Ce que j'ai pu retenir

C'était une conférence un peu différente car c'était une présentation de retour d'expérience de l'équipe technique d'M6, et non pas un sujet technique plus large. Du coup c'était très intéressant mais au final il y a moins de point à extraire et à mettre en application chez soi. (A moins d'être un peu dans le même cas de figure qu'eux.)

  • Flash: technologie en voie de disparition car difficile de trouver des ressources ou des gens qui veulent travailler avec. Gros handicap de ne pas être compatible avec les devices IOS.
  • Nouvel objectif: Un site qui ressemble à une appli, qui est rapide, et qui ne néglige pas le S.E.O. On s'oriente vers une Single Page App.
  • Abandon d'angular car pas très performant et surtout pas top pour le S.E.O.
  • La solution? L'isomorphisme, où la capacité de rendre le même code côté client ou côté serveur. Du coup pourquoi c'est mieux? Le premier rendu est effectué par le serveur, on est donc bon pour la performance et le S.E.O.
  • React tout seul n'est pas suffisant, il manque des problématiques de routeur, d'organisation. Ils ont donc aussi adopté la librairie fluxible.
  • Ils ont adopté une méthodologie Scrum somme toute assez classique dans l'ensemble.
  • Quand on a une équipe back et une équipe front, on peut faire en sorte de se passer de l'équipe back en préparant des faux retours d'API: des mocks. En plus c'est pratique pour faire des tests.
  • Le process qualité a été intransigeant. (Slide 32). Un PR par fonctionnalité, avec une code review où toute l'équipe doit donner son accord pour que le merge ai lieu. Il y a des tests automatisés systématiques (unitaires - fonctionnels - perf), des déploiements automatiques d'espaces de recette sur des branches spécifiques. Une sacrée organisation tout ça.
  • Quelques rappels sur la perf de chargement: concaténation, minimification et versionnage des assets. Compression des images. Utilisation de sprites.
  • Quelques rappels sur la perf de d'affichage: simplifier le DOM, debouncer, éviter au maximum les actions de paint / layout, en utilisant notamment l'accélération matérielle (transform, translate, will-change).
  • La méthode F.L.I.P de Paul Lewis est efficace pour les animations. (Slide 47)
  • Ils monitorent tout! (Slide 54), et loggent un paquet de choses aussi.
  • Mot de la fin: on a tous quelque chose à partager.

Une sacrée organisation, avec une intransigeance sur la qualité. Un workflow qui met tout en oeuvre pour sortir un produit de top qualité. En contrepartie, c'est forcément beaucoup de temps investi dans la qualité, on a pas un résultat pareil sans, mais du coup tout le monde ne pourra peut être pas se permettre d'investir autant. L'idée c'est de s'en rapprocher le plus possible avec ses moyens. Une de mes conférence préférées pour l'aperçu qu'elle a procuré sur les méthodes de travail d'une grande entreprise face à ses enjeux.

Voilà pour ce récapitulatif du Blend Web Mix 2015. Et vous? Qu'en avez vous pensé? Qu'elles ont été vos conférences préférées? Vous y allez l'année prochaine?

2 Responses to Retour sur Blend Web Mix 2015

  1. Bel article, quel courage d'avoir retranscrit le contenu de chaque conférence ;)

    • Merci bien :)
      Ha ha c'est loin d'être tout le contenu de chaque conférence, c'est surtout les points qui m'ont semblé intéressant. C'est donc assez orienté comme compte rendu en fait. Une autre personne aura surement eu une autre lecture. En tout cas les vidéos sont en ligne sur la chaine youtube de l'événement. Un autre bon moyen de se replonger dans les conférences pour en extraire d'autres informations à garder: https://www.youtube.com/channel/UCVA4ZOoyUyLB_LS6flBjhRg

Leave a Reply

Your email address will not be published. Required fields are marked *

Other Useful Resources

Form Cloning jQuery Plugin illustration

Building dynamic forms is a task that a lot of web developers will have to do at some point. By dynamic I mean forms that change based on what the user inputs.

A basic example of dynamic forms, are those that allow the user to add the same group of information several times. For example, an attendance form, where you can add several persons, a booking form where you can add several tickets, a membership with several users, a media page with several pictures or videos and so on, the possibilities are countless.

In order to facilitate the development of such forms, I created a little plugin, that allows you to dynamically clone a specific set of information that will be repeated. So if you ever searched a way of cloning forms, fieldsets or groups of input, this could really be helpful.

Read more
A guide to Ajax Interactions with jQuery illustration

The fantastic jQuery library revolutionized the way javascript is being written around the globe. It's been globally acclaimed and adopted, resulting in an award for best open source project in the end of 2009.

In this article, we are going to see how we can use the power of this library to create your own Ajax request effortlessly, to make pages communicate in a user friendly way. Thank you jQuery team, the days of javascript darkness are over!

Read more
jQuery FancyBox plugin illustration

The FancyBox is one of the plugin that I like the most. It's so easy to use and renders really nicely, especially with images. It's a Mac like zooming tool that you can customize quite well and really looks amazing. Source and © Janis Skarnelis

Read more
@Jerek0 Ha ha sympa JM. C’éta comment ?26 May / 09:20