Vendredi soir avait lieu au théatre du Rond-Point une conférence de Kyan et Navo sur leur processus créatif lors de la conception de la série Bref. J'avais déjà eu la chance d'écouter cette conférence il y a quelques mois, mais la voir en live cette fois-ci m'a donné envie de partager un compte-rendu des conseils qui y étaient donnés.
Leurs conseils viennent de leur expérience dans la création d'une série courte comique, mais la trés grande majorité des conseils peuvent s'appliquer à n'importe quel acte de création, depuis l'écriture d'un roman à la fondation d'une startup.
Vous avez quelque chose à dire
Le premier conseil pour se lancer est de ne pas croire qu'on n'a rien d'intéressant à dire ou à offrir. On était une centaine dans la salle à assister à la même conférence, néanmoins si on avait du chacun écrire sur un papier notre expérience, on aurait tous raconté quelque chose de différent. Un même événement peut être raconté de manières complétement différentes et aucune n'est plus légitime qu'une autre.
Just do it.
Au delà du slogan de Nike, cet adage est l'un des plus importants pour moi. C'est bien beau d'avoir des idées, mais sans leur réalisation, l'idée ne vaut rien. J'ai rencontré beaucoup d'entrepreneurs qui étaient persuadés d'avoir l'idée du siècle et qui avaient juste besoin d'un développeur pour la réaliser.
C'est pas comme ça que ça marche. C'est extrémement simple d'avoir des idées. Tout le monde a des idées, et c'est même très probable que d'autres personnes aient exactement les mêmes idées que vous. Mais imaginer un concept ou un produit dans sa tête c'est trop facile. Tout le monde peut être un génie dans sa propre tête. C'est quand on sort son idée dans le monde réel que la véritable aventure commence.
Parce qu'une fois qu'on la sort dans le monde extérieur, qu'on la confronte à d'autres personnes, à un marché, on risque de se prendre des murs, on risque de se planter. Notre si belle idée n'est finalement peut-être pas viable. Mais sans cette étape, on ne l'aurait jamais su. Il est donc indispensable de faire des choses, de passer son idée de simple concept à une réalisation concrète.
Des gens qui ont des idées il doit y en avoir approximativement 7 milliards sur Terre. Des gens qui réalisent quelque chose à partir de ces idées, il y en a déjà beaucoup moins, et ceux qui parviennent au bout de leur réalisation sont vraiment très peu.
Faites des choses, tentez, essayez, plantez-vous. Si vous ne vous plantez pas, c'est que vous n'avez pas innové. Si vous réussissez du premier coup, c'est que votre idée n'a rien de révolutionnaire.
Dumpez
Adeptes du GTD ou de Anki, vous devez connaitre ce principe. Dumpez. Ne laissez pas votre esprit être encombré de trop de choses. Vous avez une idée, notez là dans un carnet, envoyez-vous un mail, mettez là sur Evernote. Vous ne pourrez sans doute rien en faire aujourd'hui, mais au moins vous l'avez notée et un jour viendra où vous pourrez vous en resservir.
Kyan donne l'exemple du carnet dans lequel il note le nom des acteurs qu'il a aimé voir au théatre. Navo écrit sur son blog depuis des années des tas de pensées. En quand ils ont du réaliser Bref, ils ont acceléré leur casting grâce au carnet de Kyan, et ont pu transformer des notes de blog en épisodes.
Lors de l'écriture de Bref, ils ont balancé en vrac toutes les vannes, tous les trucs drôles qu'ils avaient en tête et dans leurs carnets. Ensuite, ils les ont regroupés sous des thèmes communs, qui ont ensuite donné lieu aux épisodes. Ils appellent cette technique des "jouets et des chambres". J'utilise quelque chose de très similaire quand j'écris mes scènarios de jeu de rôle et ça permet d'avoir une matière première très facilement.
N'ayez pas peur de montrer ce que vous faites
Je vois beaucoup d'entrepreneurs qui ne veulent pas parler de leurs idées de peur de se les faire voler. Encore une fois, les idées ne valent rien sans leur réalisation. Mais surtout, en empechant l'idée se se faire connaitre ils empechent complétement leur projet d'aboutir.
Peut-être allez-vous vous faire voler votre idée. Et alors ? Des idées vous en aurez d'autres, non ? Je l'espère pour vous en tout cas. Si vous pensez que vous n'avez eu qu'une seule bonne idée de toute votre vie, laissez moi vous dire qu'il y a peu de chance que cette idée soit bonne.
Les gens qui ont des bonnes idées les ont par dizaines. Ce sont des poules aux œufs d'or. Ils pourront continuer d'en avoir, même si on leur en vole une. Alors que les voleurs sont incapables d'avoir des idées. En vous volant votre idée, le voleur vous a rendu service. Vous savez que c'est un voleur maintenant, et vous ne lui ferez plus confiance et vous ne vous ferez pas voler votre prochaine idée qui est encore mieux.
De toutes façons, vous y gagnerez plus à vous faire voler une idée et la voir grandir dans le monde réel, même si vous n'y participez pas, plutot que de ne rien produire du tout.
Encore une fois, tout le monde a des idées, mais peu de personnes sont capables de les réaliser. C'est pas grave de se faire piquer des idées, c'est pas ça qui manque. Et on ne peut pas vous voler votre capacité de réalisation, c'est ça qui compte.
J'ai beaucoup aimé le petit dialogue imagé entre Kyan et Navo sur ce sujet :
— Oh, j'ai une super idée.
— Ah ouais, c'est quoi ?
— Nan, je peux pas te le dire, tu va me la voler.
— Ah. Ben viens, je te présente quelqu'un.
— Nan, nan. Il va me voler mon idée lui aussi.
— Comme tu veux...
— C'était qui d'ailleurs ?
— Le succès.
Ayez de la chance
Ce conseil parait idiot, mais c'est l'un des conseils les plus importants pour réussir. Personne ne parvient à créer quelque chose de neuf sans avoir de la chance. Mais surtout la chance, ça se provoque.
Navo aime à raconter l'histoire de cet homme très croyant qui jour après jour, pendant des années, prie Dieu pour lui demander de le faire gagner au loto. Si bien qu'après des années Dieu lui apparait et lui dit : "Écoute, je veux bien te faire gagner au loto. Mais s'il te plait, joue."
Beaucoup de gens pensent que la chance arrive comme ça, sans raison. Qu'un jour un producteur ou un investisseur va venir frapper à votre porte alors que vous êtes chez vous en slip en train de réfléchir à votre idée et vous proposer beaucoup d'argent pour enfin la réaliser.
Non.
Ça ne marche pas comme ça. Avant de pouvoir récolter de la chance, il faut savoir semer du risque. La chance, ça se provoque. Il faut tenter des choses, se faire voir, rencontrer du monde, partager, montrer ce qu'on fait. Le talent et la créativité ne font pas tout, la chance a aussi une part énorme à jouer.
Il faut savoir accepter la chance, la respecter, et la provoquer.
Créez votre famille
Même quand vous faites quelque chose de chiant, faites-le bien. Si vous travaillez un jour avec quelqu'un et que vous faites un sale boulot, il s'en souviendra et le jour où il aura besoin de quelqu'un pour monter son projet, vous pouvez être sur que ce n'est pas vous qu'il appelera.
Encore une fois, le plus important c'est pas l'idée, c'est l'équipe qui va la réaliser. Il y a des gens avec qui on a travaillé, on a apprécié leur travail autant que leur personne, on sait qu'on les rappellera pour travailler à nouveau avec eux dans le futur. On sait qu'on peut leur faire confiance, on sait comment ils travaillent, on est dans une ambiance de bienveillance.
Vous ne savez jamais si le petit boulot que vous êtes en train de faire aujourd'hui ne vous permettra pas de faire quelque chose de bien plus grand plus tard, simplement parce qu'on se souvient de vous comme quelqu'un qui bosse bien.
Ne laissez pas l'argent vous brider
Et bizarrement quand je dis ça, je ne pense pas au manque d'argent, mais au surplus d'argent. À un moment, votre projet fonctionnera. Vous gagnerez des sous avec et se posera la question de quoi faire avec ces montants.
Vous vous souviendrez du moment où vous avez commencé, où vous avez réussi à faire beaucoup avec peu de moyens. Maintenant on vous offre un chèque avec plein de zeros pour continuer. Il pourrait être tentant de se dire "Bon, je vais faire juste 90% de ce que j'avais prévu, ce qui est déjà bien, et garder les 10% restant pour ma poche".
Non.
Il faut que vous fassiez 110% de ce que vous aviez prévu. Mettez vous en galère, allez plus loin encore. Ce n'est que le début. Vous serez riche plus tard. Là vous avez encore beaucoup à apprendre, beaucoup à prouver, il ne faut pas s'arreter maintenant. En faisant ainsi, vous vous donnerez à fond et irez encore plus loin.
Le plus mauvais conseil qu'on puisse vous donner quand vous monter votre projet viens bien souvent de vos proches. Ils voient que votre idée fonctionne et vous disent "T'es payé combien ? Fais attention à ne pas te faire avoir".
Worst advice ever.
Après ça vous allez avoir un petit démon dans un coin de votre tête qui va venir vous emmerder à chaque fois que vous aller pondre une nouvelle idée. Vous allez brider votre créativité en vous disant "Non, je mérite mieux que ça", "Ça, je le garde pour moi". On s'en fout de combien vous êtes payé, vous faites ce que vous rêvez de faire, ne laissez pas une hypothétique somme d'argent vous brider avant même d'avoir commencé.
Ils sont nombreux les groupes de rock fondés par des gamsin de 15 ans qui splittent avant même d'avoir écrit leur première chanson car ils se voient déjà en haut de l'affiche et s'engueulent pour savoir comment partager les gains de leur hit idéalisé. Ne soyez pas ces gamins. Faites.
La contrainte peut être libératrice
Parfois une contrainte, un impondérable va vous forcer à revoir vos plans. Ce que vous aviez prévu de faire ne peut pas être fait comme prévu. Vous avez alors deux choix : annuler ou trouver une solution.
Et c'est bien souvent quand on a des contraintes fortes qu'on parvient à trouver des solutions créatives que nous n'aurions autrement jamais imaginées. Et ces solutions peuvent bien souvent être aussi utilisées dans des situations normales, là où la contrainte n'existe pas, pour rendre le process encore plus agréable, rapide, utile.
Ne vous découragez pas face à une contrainte, il y a forcément une solution, et bien souvent elle vous ferez explorer quelque chose d'inédit.
Qu'est-ce qu'un gars plus fort que moi ferai ?
Quand vous avez réussi à faire ce que vous vouliez, que vous pensez en avoir fini, demandez-vous "Qu'est-ce qu'un gars plus fort que moi ferai à ma place ?". En essayant de vous mettre dans la peau de quelqu'un plus fort que vous, vous parviendrez à être plus fort que vous même.
Ça parait bizarre comme conseil, mais essayez, vous verrez.
Bien souvent, vous allez rencontrer des gens dans des métiers annexes au votre avec qui vous devez intéragir qui vont vous dire "Nope, désolé, c'est pas possible.". Bien souvent, en creusant un peu, vous comprendrez que ce n'est pas pour eux que la tache est impossible, mais parce qu'ils pensent que quelqu'un d'autre, un peu plus loin dans la chaine ne voudra pas.
Si vous commencez à entendre des choses comme "Non mais c'est même pas la peine d'essayer, ils voudront jamais", "Ça fait 15 ans que je fais ce métier, je peux te dire qu'ils ne voudront pas.". Répondez simplement "Viens, on essaye.", "Viens, on essaye" jusqu'à ce qu'il accepte effectivement d'essayer.
Et vous serez surpris du nombre de fois où finalement il n'y avait pas de réel obstacle sur la voie, juste des gens qui pensent que des gens pensent qu'il va y avoir des obstacles et donc bloquent dès le début.
Et ça n'arrive pas qu'aux autres. Faites attention à la petite voix dans votre tête qui dit "Non, ils voudront pas, c'est pas la peine que je demande" aussi.
Consensus
Quand on monte un projet à plusieurs, il est fondamental que les idées mises en place plaisent à tout le monde. Si vous devez batailler pour convaincre l'autre que votre idée est bonne, changez d'idée. N'oubliez pas que vous êtes des poules aux œufs d'or. Bien souvent il existe une autre idée qui satisfait tout le monde pile entre la votre et celle de votre associé.
Si jamais on vous impose une idée et que le projet ne fonctionne pas, vous serez tenté de dire "Ouais mais je le savais, j'en voulais pas de ça moi.". Et au contraire si c'est votre idée qui est acceptée et que le projet fonctionne, vous aller penser "Je le savais, mes idées sont vraiment meilleures". Et les rancunes et les dissenssions vont commencer à partir de là.
Trouvez une idée avec laquelle vous soyez tous d'accord, que vous puissiez tous défendre et porter. Si votre idée ne convient pas, pas de soucis, trouvez-en une autre et gardez votre idée pour un autre projet.
Attention aux détails
Octroyez-vous le pouvoir de tout maitriser, toute la chaine, jusqu'au bout. Même si vous avez fait le gros du travail, faites attention aux petits détails, tout le temps, partout.
Kyan raconte une anecdote très vraie d'un magicien américain qui vient faire un spectacle en France. Il répète son tour depuis des années, il est parfaitement au point, il s'est beaucoup investi dedans, il a même divorcé à cause de ça. Il est capable de faire téléporter une petite fille depuis un bout de la scène vers l'autre.
Et au moment de monter sur scène, le présentateur l'annonce avec :
Mesdames et messieurs, un tonnerre d'applaudissement pour Maurice et ses jumelles !
Comme quoi, il faut faire attention à tous les détails jusqu'au bout.
Conclusion
Ce sont pour moi des conseils extrémement précieux. Certains s'appliquent particulièrement à un processus créatif, mais d'autres possèdent vraiment une portée bien plus générale.
J'espère que vous aurez tiré quelque chose de cet article comme moi j'ai tiré quelque chose de ces conseils.
Meetup angular, organisé par le bon coin. J'avais un peu arreté d'aller aux meetups angular (trop peu de contenu), mais là le programme annonçait un REX sur comment mélanger React et Angular, du coup, j'étais curieux.
Le bon coin, derrière leurs airs de sites des années 80 mis en ligne dans un garage possède en fait de formidables bureaux en plein Paris. Le premier site date de 2006 et est Norvégien, puis la France a été la première filiale en 2007 avant que le système ne s'implante dans plus de 35 pays.
La technologie sous-jacente est un moteur custom codé en C nommé blocket et réutilisé par toutes les filliales (qui peuvent donc faire des mises à jour de leur moteur facilement) avec quelques petites différences culturelles pour chaque pays.
D'un seul dev au départ, ils sont maintenant 250 dans la boite avec un objectif à 350 pour la fin de l'année. Le bon coin, c'est des chiffres de consultations extraordinaires. 90 millions de pages vues par mois, essentiellement des résultats de recherche, donc sans possibilité de mise en cache.
Ils parviennent quand même à un startRender moyen de 0.7s. 6e site le plus visité de France, 700.000 nouvelles annonces chaque jour, 2 datacenters de 400 serveurs. En terme de charge, c'est du très lourd, leur conso normale correspondant aux pics de charge de ce qu'on connait habituellement.
Au dela du cœur de l'appli, il y a toutes les applications de gestion (modération, monitoring, etc) qui sont développés dans des tas de langages différents. Il y en a pour tous les gouts : PostgreSQL, Python, Ruby, Go, Shell, PHP, des apps natives, du big data, de l'hadoop, du capybara.
Ah, et la question qu'on se pose tous. Non, le compte @TopBonCoin n'est pas officiel, le bon coin ne faisant actuellement aucune publicité ou community management.
Bon, assez parlé de l'hôte, place aux talks.
React et Angular
Julien Bouquillon, alias @revolunet viens nous faire un retour d'expérience sur l'intégration de React dans Angular. Il a entendu beaucoup de bien de React et a voulu voir si ça se plugguait facilement.
Ça fait deux ans qu'il fait de l'Angular, sur du mobile et sur du desktop et le problème récurrent pour lui, ce sont les perfs. Essentiellement sur mobile d'ailleurs. Les problèmes de perf sont les mêmes sur les deux plateformes, mais les desktop étant plus puissants, il faut vraiment de grosses apps pour ressentir les ralentissement.
Vu que React mets en avant sa rapidité, il a décidé de troquer les directives d'Angular par des composants React pour voir la différence. Pour lui le reste d'Angular est très bon. On gagne en productivité et en réusabilité, le framework fournit plein de choses de base et tout ça se teste facilement. Globalement, super framework... sauf pour les perfs.
What's wrong with Angular ?
Parce que le gros problème d'Angular se trouve dans le data-binding, bête et méchant. C'est le coté magique qui nous attire au début dans le framework, mais c'est aussi le goulot de performances. Quand on inclue une variable dans un template pour qu'elle soit bindée, l'algo simpliste d'Angular va simplement ré-évaluer chaque variable à chaque événement de l'utilisateur. C'est à dire au clic, au scroll, au touch, au keypress. Voire même sur des events qui ne viennent pas du user, comme le retour d'une requete HTTP.
Et ce, même si les éléments en questions sont en dehors du viewport, ou qu'ils n'ont aucun rapport avec l'élément actuellement modifié. Bête et méchant on vous dit.
Bon, sur une appli desktop, on voit pas trop le problème, ça va super vite. Mais sur mobile, on peut commencer à percevoir la lenteur, voir à la subir. À chaque interaction, la totalité du DOM est réevalué, c'est pas rien. C'est vraiment du dirty checking.
Si on veut fournir un expérience smooth, il nous faut viser du 60 fps, ce qui corresponds à 16ms pour un refresh. 16ms pour un refresh de tout le DOM, c'est pas énorme.
Malheureusement, Angular ne nous donne pas beaucoup de points d'actions pour pouvoir influencer ou améliorer ce rendering, le processus fait plus ou moins partie intégrante du core du méchanisme.
La version 1.3 a fait de grosses améliorations à ce sujet, d'au moins 50% de gain. Elle introduit aussi le principe des bind-once, et des filters stateful, qui peuvent n'être executés qu'une seule fois pour chaque valeur passée. On peut aussi éviter de mettre des méthodes à évaluer dans les templates mais simplement des variables, utiliser la syntax track by des ng-repeat et toujours essayer de mettre ses event handler sur les éléments les plus hauts.
Malheureusement, il reste le cas des keypress. Si j'ai un input, la totalité de mon DOM est réévalué pour chaque touche que va taper mon utilisateur.
Et React ?
React de son coté fonctionne avec un système intermédiaire entre ses data et le DOM, il y intercale un concept qui lui est propre : le virtual DOM. Les modifications de data influent directement sur le vDOM (qui n'est pas rendu directement), et seulement le diff entre le DOM actuel et le vDOM sont reportés dans le DOM. Ça marche très bien, et du coup seul ce qui a changé est modifié.
React intègre aussi par défaut un système d'event delegation intelligent. Plutôt que d'ajouter des handler sur plusieurs éléments, il ajoute un handler général sur la page et renvoie l'event au bon élément cliqué. On arrete comme ça de dupliquer les handlers.
Et surtout, React est explicite. Plus de magie. Chaque composant possède sa méthode render qui va retourner du HTML. On peut comme ça tester unitairement le rendu, mais surtout chaque composant est isolé et ses données ne fuitent plus vers l'extérieur. Seul le contenu du composant est modifié, sans que cela n'induise un rechargement de la totalité du DOM de la page.
Sans compter que React s'intègre parfaitement dans l'écosystem npm et browserify.
Benchmarks
Il nous a fait une démo d'un même composant codé une fois en Angular et une fois en React pour voir la différence de perfs. C'était un tableau de 100 éléments et de 5-6 colonnes. En cochant la première colonne de chaque ligne, on pouvait "barrer" l'élément.
En React comme en Angular, le chargement initial du composant prends environ autant de temps. Pas de gain à attendre de ce coté là. Par contre, si on coche une ligne du tableau Angular, les 1000 éléments sont ré-évalués alors que si on coche celle de React, seule la ligne cliquée est modifiée.
Là où c'est pire, c'est qu'en ajoutant un champ d'input au dessus du tableau Angular, chaque keypress ré-évaluait la totalité du tableau. Et pire que tout, on a ajouté un bouton qui ne faisait rien (pas de ng-click, rien). Et bien cliquer dessus rechargeait encore tout le DOM Angular.
Je crois que toute la beauté de React peut se résumer dans la phrase suivante de Julien :
En React, un bouton qui ne fait rien, ne fait rien.
Bon, et mon React il va rentrer dans mon Angular ?
Oui. Il est tout à fait possible de mettre un composant React au beau milieu d'une appli Angular. Il va vivre sa vie en isolation, sans générer de reflow Angular, et sans se modifier quand Angular se modifie.
Par contre si on veut l'introduire dans notre cycle Angular normal, il faut le wrapper lui-même dans une directive. Par contre, à partir du code de la directive, on entre dans un mode explicit > implicit où on va définir des callbacks à notre composant qu'il sera chargé d'appeller quand il voudra communiquer son état vers l'extérieur, et on ajoutera aussi des méthodes au composant pour pouvoir lui passer de nouvelles data depuis Angular.
C'est un peu plus de plomberie, mais on est alors certain qu'il ne se mettra pas à jour sans raison, et il pourra agir en isolation complète.
Il existe un projet, ngReact qui défini justement ce type de directive, mais ils vont trop loin et ajoutent des watchers automatiques pour passer les infos d'Angular vers React et vice-versa, ce qui nous fait revenir au problème de dirty checking du départ.
Conclusion
React peut s'intégrer correctement dans Angular et vivre sa vie correctement en profitant de manière isolée de ses avantages. La plomberie reste un peu manuelle, mais permet une belle isolation. Néanmoins, la philosophie de l'un et de l'autre étant tellement différentes, je ne suis pas sur qu'on tire vraiment le meilleur des deux mondes.
KillrChat
Duy Hai Doan, tech évangéliste chez Datastax nous a parlé d'un pet project de chat à base d'Angular, Spring Boot et Cassandra. C'est cool, il est payé pour faire des meetups et présenter Cassandra, du coup avec trois technos cools comme ça il peut réutiliser le même talk :)
L'idée de faire une appli de chat vient de sa frustration de faire des ateliers pour faire découvrir Cassandra et que les élèves ne repartent qu'avec un énième "Hello World" qui ne sert pas à grand chose. Là, il a une vraie appli qui touche à toutes les couches.
Et surtout, elle peut profiter des possibilités de scaling de Cassandra. En gros, quand le nombre de user se mets à grossir, il suffit d'augmenter le nombre de nœuds sur lesquels les données sont stockées dans Cassandra. Cassandra s'occupe de répartir les nouvelles données uniformément sur chaque nœud de manière à ce qu'aucun ne soit particulièrement submergé. Pour plus d'infos sur le fonctionne de Cassandra, je vous invite à relire mon compte-rendu du meetup nodejs paris.
Le chat qu'il a développé communique avec le back-end Spring Boot en websocket, avec SockJS. Entre les deux, il suffit de mettre un broker qui sait scaler (RabbitMQ, ZeroMQ, Kafka) qui implémente un simple système de pub/sub et front et back peuvent communiquer sans soucis, même avec une forte charge.
Et Angular dans tout ça ?
Duy Hai vient surtout du monde Java, le front c'est pas forcément son domaine. Mais il a kiffé Angular, il s'y est bien retrouvé. Il a aussi apprécié le fait qu'il y ait des outils pour se plugguer facilement avec Bootstrap (car comme il le dit lui-même, si on lui laisse le design d'un site ça sera horrible, avec bootstrap au moins c'est pas trop moche).
Il a quand même très rapidement implémenté des tas de bonnes pratiques en Angular (je ne sais pas si ce sont des bonnes pratiques issues de Java ou non). Par exemple, toute sa logique est distribuéed dans des services stateless, ses controllers se chargeant simplement d'un rôle de passe-plat.
Par contre, comme beaucoup, il s'est fait avoir par les $resources. Déjà, selon qu'on utilise les ressources avec des méthodes d'instances ou des méthodes de classe, ce n'est pas la même type d'objet qui est retourné et le chaining des promises en devient d'autant plus complexe (sans parler des promises angular qui ont leurs propres quirks).
Ce qu'il regrette dans Angular c'est qu'il faille une bonne connaissance de Javascript pour comprendre réellement ce qu'il se passe sous le capot. Heureusement pour lui, il a découvert angular-from-scratch qui se propose de recoder les mécaniques principales d'Angular depuis rien pour bien assimiler petit à petit chacun des concepts.
Globalement une présentation assez chouette, un REX avec des technos sympas.
Bon, je vais la faire assez vite pour le coup. Typescript est une surcouche à Javascript, un peu comme Coffeescript, qui compile en Javascript. Le truc qu'apporte Typescript, c'est un typage fort des variables.
On peut désormais définir le type de chacun de nos arguments de fonctions et définir des interfaces de classe. Et si jamais le compilateur s'aperçoit qu'on essaie de faire rentrer des ronds dans des carrés, il nous balance une exception et il compile pas.
On peut aussi définir "facilement" des variables privées et publiques et même génerer automatiquement des getters et des setters. Ouais, ouais, comme un vrai javaiste.
Bon, à part ça y a des linters et ça génère des sourcemaps.
J'ai vraiment beaucoup de mal à voir l'intéret du truc, mais j'imagine que ça va encore plus plaire aux javaistes qui se mettent au front.
Buffet
Et comme souvent, le buffet qui suit les talks est toujours l'occasion de discuter et de rencontrer des gens très intéressants. Hésitez pas à venir taper la discut' si vous êtes dans un meetup la prochaine fois.
Quand on cherche à optimiser les performances de son site web, il y a trois éléments essentiels à faire avant toute chose. Trois méthodes très simples à mettre en place et qui apportent un retour direct et flagrant sur la vitesse de chargement.
Ces trois méthodes sont la concaténation, la compression et le cache. J'ai déjà abordé celles-ci lors d'une présentation aux HumanTalks de Septembre 2014, mais nous allons les détailler dans la suite de cet article.
Concaténation
Le principe de la concaténation est de regrouper plusieurs fichiers de même type en un seul, afin de se retrouver avec moins de fichiers finaux à télécharger. Les fichiers qui profitent le plus de ce système sont les fichiers CSS et Javascript.
La nature même du téléchargement d'assets fait que notre navigateur doit payer certains coûts, en millisecondes, à chaque nouvel élément téléchargé. Ces coûts sont de diverses natures:
TCP Slow start
TCP, le protocole de connexion qu'utilise HTTP, possède un mécanisme de slow-start qui lui permet de calculer la vitesse optimale de transmission de l'information. Pour parvenir à ce résultat, il doit effectuer plusieurs aller-retours entre le client et le serveur, en envoyant de plus en plus en plus de données, pour calculer la vitesse maximale possible d'émission/réception.
Si on envoie une multitude de petits fichiers, la transmission n'a jamais le temps d'atteindre sa vitesse optimale et doit recommencer ses aller-retours pour le prochain fichier. En groupant les fichiers en un fichier de plus grande taille, le coût de calcul n'est payé qu'une seule fois et le reste du fichier peut se télécharger à la vitesse maximum.
À noter que maintenir les connexions à votre serveur en Keep-Alive permet de réutiliser une connexion d'un asset vers le suivant et donc de ne payer le coût de calcul qu'une fois. Malheureusement, activer le Keep-Alive sur un serveur Apache risque aussi de limiter le nombre de connexions parallèle que votre serveur peut maintenir.
SSL
De la même manière, si votre serveur utilise une connexion sécurisée, il y a un échange de clés entre le client et le serveur qui s'effectue pour vérifier que les deux sont bien qui ils annoncent être. Ici encore, le coût de cet échange est payé sur chaque asset téléchargé. Mettre les fichiers en commun permet donc de ne payer le coût de cet échange qu'une seule fois.
Connexions parallèles
Finalement, il y a une dernière limite, purement du coté du navigateur cette fois-ci : le nombre de connexions parallèles. La norme HTTP indique qu'un navigateur devrait ouvrir un maximum de 2 connexions parallèles vers un même serveur. Techniquement, les navigateurs récents ont augmenté cette limite à une valeur entre 8 et 12 car 2 était beaucoup trop restrictif.
Cela signifie c'est que si vous demandez à votre page web de télécharger 5 feuilles de style, 5 scripts et 10 images, le navigateur ne va lancer le téléchargement que des 12 premiers éléments. Il commencera le téléchargement du 13e uniquement une fois qu'un des 12 premiers sera arrivé, et ainsi de suite. Ici encore, la concaténation vous permet de laisser plus de canaux disponibles pour télécharger les autres assets de votre page.
Les fichiers CSS et Javascript se concatènent très bien. Il suffit simplement de créer un fichier final qui contient le contenu mis bout-à-bout de tous les fichiers initiaux. Votre processus de build devrait pouvoir s'en charger sans problème, mais un solution simple peut s'écrire en quelques lignes :
À noter que la concaténation d'images (CSS Sprites) est aussi possible, mais nous ne l'aborderons pas dans cet article.
Compression
Maintenant que nous avons réduit le nombre de fichiers, notre deuxième tâche va être de rendre ces fichiers plus légers, afin qu'ils se téléchargent plus rapidement.
Pour cela, il existe une formule magique formidable nommée Gzip qui permet de réduire de 66% en moyenne le poids des assets textuels.
La bonne nouvelle c'est que la majorité des assets que nous utilisons dans la création d'un site web sont du texte. Les briques principales comme le HTML, le CSS et le Javascript bien sur, mais aussi les formats classiques de retour de votre API : XML et JSON. Et beaucoup d'autres formats qui ne sont en fait que du XML déguisé : flux RSS, webfonts, SVG.
Gzip, et c'est assez rare pour le souligner, est parfaitement interprété par tous les serveurs et tous les navigateurs du marché (jusque IE5.5, c'est dire). Il n'y a donc aucune raison de ne pas l'utiliser.
Si un navigateur supporte le Gzip, il enverra un header Accept-Encoding: gzip au serveur. Si le serveur décèle ce header dans la requête, il compressera le fichier à la volée avant de le retourner au client, en y ajoutant le header Content-Encoding: gzip, et le client le décompressera à la reception.
L'avantage est donc d'avoir un fichier de taille réduite qui transite sur le réseau, avec en contrepartie le serveur et le client qui s'occupent respectivement de la compression/décompression. Sur n'importe quelle machine issue des 10 dernières années, l'overhead de la compression/décompression en gzip est absolument négligeable. Par contre, le fait d'avoir un fichier bien plus léger qui transite sur le réseau permet des gains très importants.
Les librairies de compression Gzip sont disponibles sur tous les serveurs du marché, il suffit généralement simplement de les activer en leur indiquant les types de fichiers qui doivent être compressées. Vous trouverez ci-dessous quelques exemples sur les serveurs les plus connus :
S'il y a bien une optimisation de performance qui nécessite peu de travail à mettre en place et qui améliore grandement les performances de chargement, c'est bien le Gzip. Cela ne nécessite aucun changement sur les fichiers servis, uniquement une activation de config sur le serveur.
Minification
Pour aller plus loin, vous pouvez aussi investir sur la minification de vos assets. HTML, CSS et Javascript sont encore une fois les meilleurs candidats pour la minification.
La minification est un procédé qui va ré-écrire le code de vos assets dans une version qui utilise moins de caractères, et qui donc pésera moins lourd sur le réseau. D'une manière générale cela va surtout supprimer les commentaires et les sauts de ligne, mais des minificateurs plus spécialisés pourront renommer les variables de vos Javascript en des valeurs plus courtes, regrouper vos sélecteurs CSS ou supprimer les attributs redondants de vos pages HTML.
L'ajout d'un processus de minification est plus complexe que l'activation du Gzip, et les gains sont aussi moins importants. C'est pourquoi nous vous conseillons de toujours commencer par la compression Gzip.
Cache
À présent que nous avons réussi à limiter le nombre de fichiers et à faire baisser leur poids, la prochaine étape est de les télécharger le moins souvent possible.
L'idée principale ici est qu'il est inutile de faire télécharger à votre visiteur un contenu qu'il a déjà téléchargé et possède donc en local sur son poste.
Nous allons commencer par expliquer comment fonctionne le cache HTTP car c'est un domaine qui est généralement mal compris des développeurs. Il y a en fait deux principes fondamentaux à comprendre dans le cache HTTP: la fraicheur, et la validation.
Fraicheur
On peut voir la fraicheur d'un asset comme une date limite de consommation. Lorsque l'on télécharge un élément depuis le serveur, celui-ci nous l'envoie accompagné d'un header indiquant jusqu'à quelle date cet élément est encore frais.
Si jamais le client à besoin à nouveau du même élément, il commence par vérifier la fraicheur de celui qu'il a en cache. S'il est encore frais, il ne fait pas de requête au serveur, et utilise directement celui qu'il a sur son disque. On ne peut pas faire plus rapide, car il n'y a alors absolument aucune connexion réseau impliquée.
Par contre, si jamais la date de fraicheur est dépassée, alors le navigateur va lancer une nouvelle requête au serveur pour récupérer la nouvelle version.
En HTTP 1.0, le serveur retourne un header Expires avec la date limite de fraicheur. Par exemple: Expires: Thu, 04 May 2014 20:00:00 GMT. Dans cet exemple, si jamais le navigateur demande à nouveau le même asset avant le 4 Mai 2014 à 20h, alors il le lira depuis son cache, sinon il interrogera le serveur.
Cette notation a un défaut majeur dans le fait que les dates sont fixées de manière absolue. Cela signifie que le cache de tous les clients perdra sa fraicheur en même temps. Et vous aurez donc potentiellement tous les clients qui feront une nouvelle requête vers votre serveur en même temps pour se mettre à jour, ce qui peut générer un très fort pic de charge à cet instant.
Pour limiter cela et donner plus de flexibilité dans la gestion de la fraicheur, en HTTP 1.1, un nouveau header à été introduit : Cache-Control. Celui-ci accepte plusieurs arguments qui permettent de gérer plus finement la manière de mettre en cache, et celui qui nous intéresse ici est max-age qui permet de définir une durée relative de fraicheur, en secondes.
Votre serveur peut donc répondre Cache-Control: max-age=3600 pour indiquer que l'asset est encore frais pendant 1h (3600 secondes). En faisant ainsi vous pouvez espacer les appels sur une plus longue période.
Validation
La deuxième composante du cache est la validation. Imaginons que notre asset ai terminé sa période de fraicheur, nous allons donc récupérer une nouvelle version de celui-ci sur le serveur. Mais il est possible que l'asset n'ait pas réellement changé sur le serveur depuis la dernière fois. Il serait alors inutile de retélécharger quelque chose que nous avons déjà dans notre cache.
Le principe de validation permet au serveur de gérer cela. Soit l'asset du client est identique à l'asset du serveur, dans ce cas le client peut garder sa version locale. Soit les deux sont différents et dans ce cas le client doit mettre à jour son cache avec la version distante.
Lorsque le client a récupéré l'asset pour la première fois, le serveur lui a répondu avec un header Last-Modified, par exemple Last-Modified: Mon, 04 May 2014 02:28:12 GMT. La prochaine fois que le client fera une requête pour récupérer cet asset, il renverra la date dans son header If-Modified-Since, par exemple If-Modified-Since: Mon, 04 May 2014 02:28:12 GMT.
Le serveur compare alors la date envoyée et celle qu'il possède de son coté. Si les deux correspondent, alors il renverra un 304 Not Modified pour indiquer au client que le contenu n'a pas changé. Celui-ci continuera alors d'utiliser sa version locale. Ainsi, on évite de transmettre du contenu inutile sur le réseau.
Par contre si le serveur voit que le fichier qu'il possède est plus récent que la date envoyée, il répondra avec un 200 OK et le nouveau contenu. Ainsi, le client utilise désormais la dernière version.
En faisant ainsi, on évite donc de télécharger un contenu qu'on possède déjà.
Dans les deux cas, le serveur renvoie de nouvelles informations de fraicheur.
Comme pour la fraicheur, il existe deux couples de headers pour communiquer des informations de validation au serveur. En plus de Last-Modified / If-Modified-Since qui utilisent une date de modification, il est possible d'utiliser des ETags.
Un ETag est un hash qui identifie de manière unique chaque fichier. Si le fichier change, alors son ETag change aussi. Par exemple, le serveur retourne au client lors du premier appel un header ETag: "3e86-410-3596fbbc", et lorsque le client fait à nouveau appel à la même ressource, il envoie un header If-None-Match : "3e86-410-3596fbbc". Le serveur va comparer les deux ETags et retourner un 304 Not Modified s'ils sont identiques ou un 200 OK avec le nouveau contenu s'ils sont différents.
Last-Modified et ETag possèdent des comportements très similaires, mais nous vous conseillons d'utiliser Last-Modified en priorité.
En effet, la spec HTTP indique que si un serveur retourne un Last-Modified et un ETag, alors le navigateur doit prendre en priorité le Last-Modified. De plus, la majorité des serveurs génèrent l'ETag à partir de l'inode du fichier, de manière à ce que celui-ci soit modifié au moindre changement.
Malheureusement, ceci pose des soucis pour peu que vous ayez des serveurs redondés derrière un load-balancer où chaque serveur possède son propre filesystem et donc ses propres inodes. Deux fichiers identiques, sur deux serveurs différents auront des inodes différents et par conséquent des ETag différents. Votre système de validation ne fonctionnera plus dès lors que votre client sera redirigé vers un autre frontal.
À noter que ce problème n'apparait pas sous nginx, qui ne prends pas en compte l'inode dans la génération de son ETag. Sous Apache, l'option FileEtag MTime Size permet de le désactiver, ainsi que etag.use-inode = "disable" sous lighttpd.
Récapitulatif
À la lumière de ces explications, nous pouvons donc retracer le parcours classique du téléchargement d'un asset mis en cache.
Le client effectue une première requête pour récupérer un asset. Il récupère son Cache-Control: max-age pour la fraicheur et son Last-Modified pour la validation.
S'il demande à nouveau le même asset alors que celui-ci est encore frais, il le prends directement depuis son disque local.
S'il le demande au dela de sa date de fraicheur, il fait un appel au serveur en envoyant son If-Modified-Since.
Si le fichier sur le serveur possède la même date de modification que celle envoyée, il retourne un 304 Not Modified.
Si le fichier sur le serveur a été modifié, il retourne un 200 OK avec le nouveau contenu.
Dans tous les cas, le serveur retourne un Cache-Control et un Last-Modified.
Invalidation du cache
Mais le cache est un animal capricieux, et nous savons tous que :
Il y a deux choses complexes en informatique : invalider le cache et nommer les choses.
Et effectivement, invalider le cache de nos clients quand nous avons besoin de faire une mise à jour est extrêmement difficile. C'est en fait tellement difficile que nous n'allons pas le faire du tout.
Comme le navigateur mets en cache chaque URL, si nous souhaitons modifier un contenu, il nous suffit de modifier son URL. Et les URL, c'est quelque chose que nous avons en quantité illimité. Il nous suffit de modifier le nom d'un fichier pour générer un nouvelle URL. On peut ajouter un numero de version, un timestamp ou un hash à notre nom de fichier original pour lui générer une nouvelle url.
Par exemple : style-c9b5fd6520f5ab77dd823b1b2c81ff9c461b1374.css au lieu de style.css.
En mettant un cache très long sur ces assets (1 an est le maximum officiel de la spec), c'est comme si on les gardait en cache indéfiniment. Il nous suffit juste de mettre un cache plus court sur le fichier qui les référence (généralement le fichier HTML).
Ainsi, si on pousse en production une modification sur une feuille de style ou dans un script, il nous suffit de modifier les références à ces fichiers dans nos sources HTML pour que les clients téléchargent les nouveaux contenus. Le cache sur les fichiers HTML est beaucoup plus court, de manière à ce que les changements introduits par notre mise en production soient rapidement répércutées sur nos clients.
Les anciens contenus seront encore en cache chez nos clients mais cela n'a pas d'importance, nous ne les requêterons plus jamais et les éléments non-utilisés du cache des clients se vident régulièrement.
La technique est en fait très proche des Etag vus précédement à la différence qu'ici nous sommes maitres de la génération du nom unique de fichier et du moment où nous souhaitons invalider le cache de nos clients.
Au final, nous utilisons un mélange de ces deux techniques pour gérer un cache optimal.
Les éléments dont l'URL est significative, comme les pages HTML ou les retours d'une API définiront une fraicheur faible (de quelques minutes à quelques heures, en fonction de la fréquence moyenne de mise à jour). Ceci permet de s'assurer que le client aura rapidement la nouvelle version quand celle-ci est déployée, tout en limitant la charge sur le serveur et la quantité d'information transitant sur le réseau.
Pour les éléments dont l'URL n'est pas significative, comme les feuilles de styles, les scripts, les polices de caractère ou les images, on utilisera une fraicheur maximum d'un an. Ceci permettra au client de garder indéfiniment la ressource dans son cache sans avoir besoin d'interroger à nouveau le serveur. On générera par contre une URL différente en fonction d'un hash du contenu à chaque fois que le contenu vient à changer. On prendra bien garde à modifier les références à ces fichiers dans les pages HTML.
Conclusion
Nous avons donc vu comment trois points très simples permettent de diminuer grandement le nombre de total de fichiers à télécharger, les rendre plus légers, et les télécharger moins souvent.
La concaténation automatique des fichiers doit être intégrée dans votre processus de build, afin de garder un environnement de développement clair. La compression en gzip ne nécessite que quelques modifications sur vos serveurs. La mise en place d'une stratégie de cache optimale par contre nécessite à la fois des modifications sur le processus de build et sur la configuration des serveurs.
Toutes ces modifications sont relativement peu couteuses à mettre en place et ne dépendent aucunement ni de la technologie utilisée pour le front-end, ni de celle utilisée pour le back-end. Elles peuvent être mise en place quelle que soit votre stack technique. Il n'y a donc plus aucune raison pour ne pas les déployer dès aujourd'hui.
Hier soir, meetup parisjs chez In'Tech Info, une école d'informatique du coté des Gobelins (dont les locaux semblent être un ancien parking réaménagé). Néanmoins, grande salle, plein de nouveaux venus, ça fait plaisir.
Commençons par le gros point noir du meetup. Celui-ci était censé commencer à 19h, mais c'est seulement à 19h45 que les organisateurs commencent à prendre la parole pour annoncer le programme. Et présenter parisjs, et montrer le nouveau site, et essayer de faire une démo d'édition de markdown en live, et faire son auto-promotion, et donner la parole à tous les sponsors pour qu'ils fasse de même, et du coup c'est super long.
C'est le même travers que le meetup nodejs paris et paris.rb. Ça ne commence jamais à l'heure, et même quand ça commence, on doit encore se taper les publicités avant le film, comme au cinéma. La prochaine fois, je viendrai en retard.
Bon, fini d'être aigri, il y avait une annonce intéressante quand même. NUMA vient d'ouvrir un espace de coworking de 150m², avec café à volonté, ouvert 24h/24, à destination des développeurs, et avec un device lab.
Dev Avengers
Mais les talks ont ensuite relevé le niveau. Christophe Porteneuve, la bible vivante du Javascript, qui appelle tout les auteurs des grands frameworks par leurs petits prénoms et qui réfléchit encore plus vite qu'il ne parle était le premier sur scène. 37 ans, toutes ses dents, 19 ans dans le web, ça envoie du lourd.
Il nous a présenté les outils de travail intra-browser qui permettent d'améliorer la productivité de son workflow de travail. Fini le Ctrl-S, Alt-tab, Ctrl-R pour voir les modifications qu'on vient de faire, on est en 2015 bourdel.
Petite explication de l'utilité des sourcemaps, qui permettent, en ajoutant des commentaires dans un fichier minifié de faire le mapping vers les fichiers sources. Chrome les comprends depuis déjà 4 ans, et nous indique donc les erreurs dans la console réellement là où elles ont lieu dans les fichiers sources. Et encore mieux, elles peuvent faire le lien entre un fichier final et n'importe quel type de fichier source, même des preprocesseurs comme Sass, Less ou Coffescript.
Tout le reste du talk donnait des exemples avec Chrome, car c'est le browser qui possède actuellement les meilleurs outils, même si Firefox et IE12 sont pas loin derrière.
On sait tous qu'on peut modifier le HTML et le CSS à la volée avec l'inspecteur Chrome, mais on peut aussi le faire avec du JS. Le soucis c'est que nos modifs restent en live dans la page chargée, mais que c'est un peu plus compliqué pour les récupérer dans un vrai fichier sur le disque.
Du coup, la solution c'est les workspaces de Chrome. On lui définit un dossier de notre disque dur qui contient nos sources, et une fois qu'on lui a donné l'autorisation, on peut manuellement lui indiquer les mappings entre notre filesystem et notre network. Du coup, en faisant ainsi et avec les sourcemaps, on peut modifier directement un fichier source Sass depuis Chrome.
Bon, sauf que dans ce cas là, on perds la preview instantanée de nos modifs dans le browser, parce que Chrome n'a aucune idée de comment parser du Sass. Mais c'est là que notre outil de build en mode watch peut venir nous aider. Grunt, Gulp et Brunch proposent tous un moyen d'écouter les modifications du filesystem pour lancer des taches en fonction des fichiers modifiés.
Il nous a ensuite parlé de fb-flo, un outil de Facebook qui permet de lier un fichier actuellement chargé par Chrome (CSS ou JS) à un buffer ouvert dans son IDE, et de reporter automatiquement les modifs de l'un vers l'autre, sans avoir besoin de recharger la page.
Dernier outil pour gagner du temps en test crossbrowser, c'est BrowserSync. On ouvre autant de pages qu'on le souhaite sur différents browsers, desktop et mobile, et toute modification sur l'un (scroll, typing dans un formulaire, etc) est répercutée instantanément dans les autres. L'avantage est que pour les clics, il rejoue le même selecteur unique sur chaque device plutot que de cliquer à des coordonnées précises.
Du coup, si on récapitule :
Sourcemaps pour avoir la liaison entre un fichier minifié et les sources des preprocesseurs
Workspaces pour faire le mapping entre un fichier du disque dur et un fichier chargé par Chrome (marche avec les sourcemaps). Je modifie dans Chrome, ça change sur mon disque.
fb-flo pour faire du livereload du browser dès qu'un fichier du disque change. Je modifie sur mon disque, ça recharge dans Chrome.
BrowserSync pour tester sur plusieurs devices/browsers en parallèle.
On a discuté ensuite autour d'une bière et d'une pizza où il m'a convaincu d'essayer Stylus. Syntaxe "clean", à la ruby, jade ou coffeescript. Je ne suis pas fan de cette épuration habituellement, mais j'avoue n'avoir jamais réellement essayé. Par contre le fait de pouvoir redéfinir les propriétés de base CSS (du genre, dès que je mets telle propriété avec telle valeur, alors ça mets automatiquement telle autre). Et aussi, les variables des mixins sont scopées, ce qui est le truc qui m'ennuie le plus avec Sass.
Dans le même genre, il m'a vendu brunch comme étant un grunt-like à base de convention over configuration (ce qui est tout le contraire de Grunt et de son configuration over configuration over configuration...). Du coup, faut vraiment que je teste.
Et il a même dit du bien de famous (un peu moins d'angular, forcément).
Alors, Ionic c'est un framework qui combine Angular et Cordova pour développer des applications hybrides.
Cédric commence par nous expliquer les avantages et inconvénients de faire de l'hybride. Le gros avantage de l'hybride c'est que c'est le même code pour toutes les plateformes, ce qui évite de devoir faire deux applications, pour Android et iPhone, qui coutent deux fois plus cher.
Par contre, mieux vaut éviter l'hybride si on a besoin de perfs au top, parce qu'une surcouche sera toujours plus lente que du natif. Ce qui inclue tous les super effets d'animation mouf-mouf. Si on a besoin de certaines API très liées au device, Cordova ne nous y donnera pas forcément accès. Et finalement, si on n'a besoin de développer que pour une unique plateforme, autant partir sur du natif.
Dans les deux cas, pour pouvoir passer son app sur iPhone, il faudra passer par les 15 jours de validation Apple. Il n'y a rien dans les CGU d'Apple qui bloque l'hybride plus que le natif.
Maintenant, parlons de ce qu'apporte Ionic. Déjà, il utilise Cordova, qui est le moteur open-source utilisé par Phonegap. Il gère aussi parfaitement les affichages d'élements dans une page, même quand on fait apparaitre/disparaitre le clavier (source de bugs divers).
Avec Ionic, on fait une application, pas un site web. On passe sur un paradigme où on réfléchit en terme de "vues" (écrans), et on doit alors penser à comment ceux-ci s'emboitent, quel est le comportement du bouton back, etc.
Ionic est fourni avec des directives (Angular oblige) pour la majorité des éléments de UI classiques d'une app : header, footer, listes avec pull-to-refresh, swipe sur item pour avoir un menu, drag'n'drop, popup de choix d'action, slideshow, etc
Ça s'installe classiquement à base de npm et génère un code boilerplate avec une petite appli pour comprendre comment les différents éléments interagissent. Si vous voulez vraiment aller vite, il existe même le Ionic Creator pour générer sa UI à base de drag'n'drop.
Ça pêche encore du coté Android quand le browser par défaut est le stockbrowser, qui a des perfs bien moins bonne que Chrome. Il y a des solutions en cours de développement pour contrer ça. Il n'est pas non plus compatible sous Windows Phone pour le moment.
Coté UI, Ionic vient avec son propre style. Il y a des essais pour reproduire un style natif Android ou iPhone, mais c'est pas encore au point et jQuery mobile est plus avancé de ce coté là apparemment. Par contre, on a quand même le droit à une classe CSS sur le root indiquant si on est sous Android ou sous IOS pour tweaker notre app en fonction.
VIRTJS
Maël Nison est venu nous parler un peu plus de Ionic, qu'il a utilisé sur un projet perso nommé Start9.
Maël avait déjà présenté un émulateur gameboy qu'il avait développé en javascript. Il a cette fois-ci poussé le concept un peu plus loin en proposant un site web en Ionic, accessible donc depuis n'importe quel browser, sur lequel on puisse uploader ses roms Gameboy et y jouer directement dans le navigateur. L'avantage est d'avoir un système crossplatform, on peut commencer sa partie sur son téléphone dans le métro et la continuer au même endroit sur son desktop plus tard.
Le gros avantage est que c'est un simple site web. Pas besoin d'installer quoique ce soit pour l'utilisateur, et pas besoin de passer par la validation appStore pour le créateur.
Coté techno, c'est du node en backend, avec du sequelize (ORM pour taper sur PostgreSQL et SQLite). Systemjs et Traceur pour ses modules ES6 transformés en ES5. Comme ça, le jour où ES6 est partout, on peut enlever la transformation. Et sinon, du Ionic pour le front.
Pour la suite ils envisagent de supporter de plus en plus de jeux, et de plus en plus de consoles. Ils passeront aussi à Angular 2 quand il sortira (pour rester sur une stack ES6). Leur retour sur Ionic c'est que c'est cool mais encore jeune, les issues sont fixées rapidement (si les mainteners sont pas en vacances...).
Conclusion
Une bonne soirée ParisJS, avec 3 talks très intéressant, une grande salle, de la pizza pour tout le monde et des discussions intéressantes autour d'une bière.
Sketchfab organisait à Numa un meetup, en partenariat avec 3DHubs. Je suis arrivé en retard (19h pour début à 18h), et du coup j'étais très mal placé (sur un fauteuil dos à la scène, derrière un pilier, au fond). Vu qu'il n'y avait pas de micro pour les questions de l'audience, je n'ai pu qu'entendre les réponses.
Ce que j'ai pu en retirer, une machine "perso" coute dans les 3000€ et la majorité des gens sur 3DHubs ne le font pas pour gagner de l'argent (s'ils peuvent se rembourser la machine c'est déjà bien), mais pour rencontrer d'autres makers.
Et... c'était fini !
Néanmoins, en discutant un petit peu autour des tables j'ai découvert un appareil (dont j'ai oublié le nom) qui est une sorte de camera 3D qu'on clipse sur un iPad et qui permet de faire des scans 3D en tournant quelques minutes autour d'un objet. Je l'ai vu à l'œuvre sur le scan de plusieurs participants pour avoir leur buste, et le résultat était pas dégueu du tout pour un si petit appareil.
Plusieurs musées Londoniens ont déjà scanné et ouvert au public certaines de leurs œuvres. En France, l'intérêt ne décolle pas vraiment, nos musées sont plus protecteurs. Par contre, les initiatives un peu pirates pour aller faire des tours dans les jardins municipaux et scanner les statues commencent à prendre vie.
Bon, au final par curiosité c'était intéressant, mais je suis arrivé trop tard pour en tirer trop de choses.