Le dernier meetupParisHacker avait lieu, une fois de plus, à Tektos. Il y avait une centaine d'inscrits sur meetup, mais on était au final à peine une vingtaine, sans doute la faute à la veille d'un week-end prolongé. En tout cas, c'était dommage.
On a eu le droit à trois talks, entrecoupés de pause pour prendre des bières et du fromage. D'abord, Vincent nous a parlé des challenges rencontrés à Algolia pour avoir un réseau distribué, ensuite Laurent nous a parlé de Couchbase Mobile et Emmanuel de Diffbot.
Challenges of Distributed Search Network
Déjà, je dois dire que bossant avec Vincent, j'avais déjà vu son talk quelques heures plus tôt. Du coup, j'étais un peu moins assidu pour prendre des notes, je vais quand même tenter d'en retranscrire le plus important.
Vincent travaille donc à Algolia, et même s'il travaille essentiellement sur les aspectsfront-end d'Algolia, il nous a quand même donné une idée plus générale de ce qu'il se passe sur un service en SaaS comme Algolia.
Sa présentation était en trois parties, d'abord une explication de ce qu'implique de faire de la recherche sur le net, ensuite ce que propose Algolia et finalement quelques tips et REX.
Search Engine ≠ Database
Déjà, la recherche sur le net, on n'y fait plus réellement attention, mais on passe la majorité de notre temps à faire des recherches sur Google pour trouver ce qu'on recherche. On commence quasiment toutes nos sessions de browsing par une session de recherche, mais il s'empêche que les algos et l'infrastructure qui tournent derrière sont très complexes.
On remarque aussi que bien souvent, la pertinence des résultats de recherches de Google est bien supérieure à la pertinence des résultats au sein même d'un site, si bien qu'on en vient à faire quelque chose de complètement absurde mais qui marche très bien : rechercher sur Google pour trouver quelque chose dans un site en particulier. Mais on reviendra là dessus plus tard, quand on parlera d'Algolia précisément.
Bon, déjà éliminons quelques misconceptions. Un moteur de recherche n'est pas une base de données. Dans une base de données, on fait des tas d'opérations (INSERT, UPDATE, DELETE, SELECT, etc) et on a un langage de query qui permet d'exprimer des demandes complexes.
Par contre, dès qu'on veut faire une recherche full text, on se retrouve avec des opérations couteuses, comme le LIKE %FOO% qui, en plus de devoir scanner l'ensemble des items, ne sait pas gérer les typos ou les pluriels.
Par contre, dans un moteur de recherche, on ne doit s'occuper que d'un seul type d'opération : la recherche. Pas besoin de langage aussi complexe que du SQL, on se concentre sur une seule opération et on l'optimise pour le use-case le plus commun : la recherche full text.
Indexing and Querying
Gérer un moteur de recherche nécessite deux parties. D'abord on indexe, ensuite on recherche. L'indexation consiste à enregistrer les documents de manière optimisée pour le search. Quand ensuite vient la recherche, en plus de retourner l'ensemble des documents qui correspondent aux termes envoyés, on doit aussi les classer par pertinence.
L'indexation peut se vulgariser assez facilement. Pour chacun des documents à indexer on liste les mots qui le composent, puis on fait une liste inversée de ces mots. Ainsi, on a une structure simple clé/valeur qui pour chaque clé (mot) comprends une liste de valeurs (les documents qui contiennent ce mot). Un peu comme un sommaire à la fin d'un livre de cuisine qui va pour la ligne tomate, indiquer toutes les pages de recettes qui utilisent des tomates. Et les résultats de recherche pour foo bar sont donc simplement l'intersection des résultats de recherche de foo et de bar.
Ça, c'est pour la partie théorique et simplifiée. En vérité, la structure qui contient cette relation terme/document est bien plus compliquée pour gérer les pluriels, les synonymes et les fautes de frappe, mais l'idée sous-jacente reste la même.
Algolia
Maintenant qu'on a vu un peu de théorie pour démystifier la recherche, voyons ce que propose Algolia. Algolia se pose comme un Google à l'intérieur de notre application. Plutôt que d'aller chercher dans un index de pages web, Algolia permet d'aller chercher dans un index de données qui nous sont propres (users, produits, vidéos, whatever). La force d'Algolia réside avant tout dans la vitesse d'exécution.
Le temps entre la pression de la touche par l'utilisateur et l'affichage des résultats sur son écran ne dépasse pas les 50ms (latence réseau comprise). Cette vitesse permet de faire des UI qui affichent les résultats directement quand l'utilisateur tape une nouvelle lettre de son clavier plutôt que d'attendre de devoir lui faire recharger une nouvelle page de résultats. Je ne parle même pas de la manière dont tout cela aide le cerveau humain en lui suggérant des éléments plutôt qu'en le faisant travailler à se souvenir de ce qu'il veut taper.
Bref, on a eu une belle démonstration d'Algolia sur HackerNews (spéciale dédicace à ParisHacker). Vincent nous a ensuite parlé du réseau distribué d'Algolia dans 12 datacenters dans le monde et nous a ensuite parlé des trois piliers de la performance qu'Algolia s'efforce d'optimiser : Software, Hardware et Network.
Pour le software, il faut savoir que la première version du moteur d'Algolia était fait sous forme de SDK embarqué dans des applications mobiles. Il fallait donc réussir à tirer profit au maximum des capacités de la machine pour pouvoir créer une expérience de search ultra rapide. On parle là de micro optimisation à la milliseconde. Le code a continué depuis d'évoluer et de s'améliorer et est aujourd'hui inclus directement sous forme de code natif dans les nginx des serveurs Algolia.
Coté Hardware, les serveurs tournent sur du matériel custom, dont les processeurs, la RAM et les SSD sont sélectionnés avec soins. Plusieurs tweaks sont appliqués directement sur le kernel pour avoir aussi les meilleurs rendus, et ce n'est pas le genre de chose qu'on peu faire sur des machines classiques.
Finalement, le gros des pertes de performances venant du réseau, Algolia a misé au maximum sur un réseau distribué de manière à pouvoir être au plus proche des utilisateurs. On a beau faire toutes les optimisation que l'ont peut, il arrive un moment où on ne peut pas faire transiter l'information plus vite que la vitesse de la lumière, donc le seul moyen est de se rapprocher au maximum de l'utilisateur final. En plus de la proximité géographique, il faut faire attention au peering que possèdent les opérateurs où on mets ses serveurs.
Pro Tips
Finalement, Vincent nous a fait part de 10 tips qu'Algolia a appris en mettant au point son infra et qu'ils partagent.
Déjà, il n'existe pas un provider unique et magique qui est présent dans tous les pays du monde avec un formidable débit. AWS c'est cool, mais il n'est pas présent en Inde, en Afrique et dans une bonne partie de l'Asie. Il faut donc utiliser aussi d'autres providers, et dans ce cas il faut essayer d'en avoir le moins possible pour ne pas compliquer les transactions. Aussi, il faut s'attendre à quelques surprises au niveau de la douane, ce n'est pas toujours facile de faire livrer des serveurs dans certains pays et alors il faut attendre plusieurs mois...
Vient ensuite la question du prix. Avec plusieurs providers, la même infra ne coûte pas le même prix dans plusieurs pays. Parfois il n'est pas possible d'avoir la même infra, certains serveurs n'étant pas disponibles, ou alors la tarification est différente. Dans ces cas là, est-ce qu'il faut reporter cette complexité dans la tarification faite à l'utilisateur ou ne proposer qu'un prix unique à l'utilisateur ? Algolia a choisir de masquer toute cette complexité, proposant le même prix à tout le monde.
Proposant une réplication dans 12 datacenters, Algolia a du se pencher sur un système de réplication. Comment faire discuter tout ces datacenters et rendre la recherche distribuée ? La solution la plus simple est souvent la meilleure. Chaque datacenter possède une copie de la donnée et est composé de trois machines. Une de ces machines est un master, sur lequel peuvent se faire les écritures, et les deux autres des slaves qui ne font que de la lecture.
Ensuite, on parle de DNS. Déjà la petite anecdote c'est qu'un .io sera plus lent qu'un .com ou .net. Ayant voulu se la jouer cool, comme toutes les startups, Algolia est initialement parti sur un .io, mais ce TLD étant beaucoup plus récent, il n'y a que 6 serveurs qui font foi pour la résolution de ce TLD alors que .com et .net en ont beaucoup plus.
Algolia utilise la résolution DNS pour sélectionner le datacenter le plus proche de l'utilisateur. Pour cela, il faut un fournisseur qui accepte la geo ip et l'edns. Mais surtout, la résolution DNS est un gros SPOF. Les SDK implémentent donc un mécanisme de fallback si jamais la résolution DNS principale fail, ils vont utiliser un deuxième fournisseur.
Pour s'assurer que tout ceci tourne correctement, Algolia utilise de simples sondes. Ce sont de petits serveurs peu consommateurs, éparpillés dans le monde, qui vont pinguer et exécuter quelques opérations classiques 24/24. Ils envoient leurs données à un master qui affiche l'état du réseau en temps réel sur status.algolia.com.
La fin du talk a été agrémentée de questions et de quelques bières, puis on est passés aux deux autres présentations.
Aujourd'hui, on est habitué à avoir une connexion à peu près tout le temps. Mais quand elle se dégrade, ou pire, quand on n'a plus de connexion du tout, on se retrouve avec une application qui au mieux est lente et frustrante, au pire ne fonctionne pas du tout et est donc encore plus frustrante.
Si on regarde les raisons pour lesquelles les gens laissent de mauvais ratings aux applications sur les stores, c'est globalement parce que les apps crashent ou sont lentes.
Le problème majeur derrière ça que CouchBase Mobile cherche à résoudre est l'endroit où les données sont stockées. Évidemment, si les données sont stockées sur un serveur distant et qu'on n'a pas de connexion pour y accéder, l'application ne peut pas fonctionner.
Par contre, si on inverse le paradigme et qu'on considère que la source principale de la donnée se trouve directement sur le téléphone de l'utilisateur, alors les applications peuvent travailler en mode offline tout le temps. L'offline devient le mode par défaut et la synchronisation avec un serveur distant devient une opération secondaire, quand la connexion revient.
J'avais déjà vu d'autres personnes attaquer ce problème, comme hood.ie ou PouchDB. Là, Couchbase Mobile nous promets une libraire simple à utiliser, rapide, basée sur du json schemaless et qui prends peut de mémoire. Elle fonctionne sous forme d'évènements et se charge de la synchronisation automatiquement.
Son store est un store de type document, avec un système de clé/valeur versionnées (permettant de gérer les conflits entre plusieurs versions, et laissant à l'utilisateur le soin de gérer manuellement les conflits qui ne peuvent pas être réglés automatiquement).
La suite de la présentation était une démo à base de live coding, mais j'ai complètement décroché.
The Web as a structured database
Ensuite, Emmanuel Charon de Diffbot nous a parlé de leur outil de scraping à base de reconnaissance visuelle.
Leur outil fait du scraping de pages web, mais il ne va pas regarder le code HTML sous-jacent, ni même faire de la reconnaissance d'image, il va à la place simuler un cerveau humain à qui on donne une image, et il va en extraire les informations importantes.
Diffbot est capable d'analyser n'importe quelle page web et d'en ressortir une représentation en JSON en analysant le contenu. Il peut en sortir les commentaires, les images, les tags associés (qu'il déduit depuis le texte, même s'ils ne sont pas directement taggués comme tels). Il fait un peu d'analyse de sentiment (positif/négatif) bien que cette partie ne soit pas encore assez au point pour qu'ils la mettent trop en avant.
Le but de Diffbot est de pouvoir permettre de faire des queries de manière humaines, comme "toutes les chaussures qui ont des commentaires qui les disent confortables" ou "toutes les mentions de untel dans les deux dernières semaines".
Ce mois-ci, les HumanTalks étaient chez Deezer, dans leur belle grande salle du rez-de-chaussée. Un beau frigo rempli nous fait de l'œil, le buffet va être bien, Deezer a tout prévu.
La soirée s'est plutôt bien passée, malgré les quelques fails. Déjà, un des speakers n'est pas venu, alors qu'il avait confirmé encore la veille et n'a pas jugé utile de prévenir. L'un des trois autres speakers l'a alors remplacé au pied levé, mais sa présentation, trop commerciale, n'était pas très convaincante.
Du coup, toutes nos pizzas sont aussi arrivées avec un peu de retard et il a fallu attendre un peu avant de pouvoir manger. Le tout dans une salle bas de plafond, avec une clim qui marche mal. Oh, et on a eu le rétroprojecteur qui s'est mis à faire grève durant l'introduction aussi. Mais sisi, je vous assure, c'était bien.
Github Awards, découvrez votre ranking
Vincent Daubry, co-fondateur de Yooboox et développer Ruby/iOS nous parle d'un petit side project qu'il a récemment mis au point et qui a assez fait parler de lui.
Il avait vu il y a quelques temps une présentation de Sacha, qui parlait des side-projects, et que ceux-ci devaient rester simples, prendre peu de temps et surtout être fun.
Du coup, de son coté il s'est donné 2 semaines, en bossant le soir et le week-end pour terminer son projet. 2 semaines c'est assez long pour pouvoir construire quelque chose, et assez court pour ne pas se lasser.
Son projet, nommé GitHub Awards permet de "noter" les différentes personnes inscrites sur GitHub pour voir qui est le plus gros commiteur sur telle ou telle techno selon différentes zones géographiques. C'est tout con, et ça le faisait marrer, ce qui est largement suffisant pour un side-project.
Pour faire ça il a commencé à récupérer la liste de tous les users de GitHub et leur localisation. Puis, il a récupéré l'ensemble des repos, leur nombre de stars et les langages associés. Il y a ensuite un petit travail pour recoder les coordonnées de location en quelque chose de plus exploitable par son système et ensuite il faut mettre au point une petit formule de ranking de tout ce beau monde.
Bon, l'avantage c'est que GitHub ouvre une API qui permet de récupérer toute ces infos sans avoir besoin de crawler les pages manuellement. Le problème c'est que la masse de données est énorme et GitHub ne permet que 5000 appels par heure par clé d'API. Néanmoins, GitHub propose une version "bulk" de son API qui expose moins d'informations mais permets d'en récupérer plus d'un coup.
Heureusement, il existe à coté le projet GitHub Archive qui indexe depuis 2011 l'ensemble des activités sur tous les repos de GitHub. C'est à dire les commentaires, les PR, les clones, etc. Tout ceci représente beaucoup de données mais est requêtable avec Google Big Query et l'ensemble du dataset, bien que conséquent, peut être monté en mémoire avec Redis.
Du coup, après le coté technique, Vincent à souhaité tester le coté commercial. Il a posté sur HackerNews, a été featuré sur ProductHunt et a ainsi réussi à atteindre les 200 millions de visiteurs (ce qui représente quand même 15% des utilisateurs de GitHub). Ce qui est impressionnant c'est que son site web est un simple Rails (protégé par un bon système de cache) et qu'il a bien tenu la charge.
Sa conclusion, que je partage, c'est qu'il ne faut pas laisser trainer ses side-projects. Il faut les sortir du placard rapidement, pour qu'ils ne prennent pas la poussière, et se donner un temps limité pour éviter cet effet d'abandon.
Licences open-sources
Le second talk, je l'attendais avec impatience. Mickael Andrieu souhaitais nous parler de licences Open-Source et des différences entres elles, ce qui est un sujet bien obscur pour moi.
Malheureusement, je n'en sors pas avec beaucoup plus d'informations qu'avant. Je ne me risquerai pas à faire un résumé du talk car je dois bien avouer que je n'ai rien compris aux explications.
J'ai bien compris qu'il y avait une forte différence entre Libre et Open-Source, mais je suis toujours aussi incapable de l'expliquer précisément, et je ne sais toujours pas expliquer la différence une MIT, GPL et Creative Commons.
Ah si, j'ai noté qu'il avait créé un site, www.choisirunelicence.com qui doit expliquer tout ça en détail.
B.A.-BA du scraping
Alexandre Gindre, ex collègue d'Octo nous a ensuite parlé de web scraping. Il a tout présenté dans des beaux slides brandés Octo mais il a bien précisé que ce dont il allait nous parlait n'était pas fait dans le cadre d'Octo. En effet, certaines parties du scraping sont assez floues vis-à-vis de la légalité.
Déjà, il faut bien faire la différence entre le scraping et le crawling. Le crawling va récupérer la totalité d'un site externe pour l'indexer tel quel de son coté (ce que fait Google typiquement). Le scraping de son coté va "uniquement" extraire certaines infos du site.
L'archi nécessaire pour faire du scraping est assez simple mais est à peu de choses près toujours la même. Dans un premier temps on va requêter le site cible, si possible caché derrière un proxy, et on va en extraire les données intéressantes. On va ensuite stocker ces données chez nous et les présenter dans une nouvelle UI, avec de nouvelles features.
Alors, est-ce que c'est bien légal ? C'est là que c'est flou. Normalement, d'après la loi du droit d'auteur sur les bases de données, ce qui est sur un site appartient à son auteur. Mais en même temps, si ces données sont accessibles publiquement, il peut être admis qu'on puisse les utiliser. La jurisprudence vient rajouter un part de complexité dans l'équation aussi. Opodo avait scrapé les pages de Ryanair, et Ryanair avait alors porté plainte, mais Opodo a fini par gagner le procès car Ryanair n'a pas pu prouver que le scraping leur avait porté préjudice, bien au contraire.
Par contre, si jamais le site cible indique clairement qu'il ne faut pas le scraper, alors il ne vaut mieux pas s'y frotter. C'est par exemple le cas de societe.com. Quand à savoir si une telle indication a réellement une force légale, c'est moins sur.
Ce qui est sur par contre c'est que même si le scraping en lui-même n'est pas interdit, il faut faire attention aux méthodes utilisées. Si on tape dessus comme un bourrin et qu'on mets en péril la stabilité de la plateforme, on risque d'être apparenté à un DDoS, ce qui est cette fois tout à fait répréhensible et relève du pénal.
On connait Opodo comme site de scraping qui agrège les données de plusieurs sources, mais il en existe plein d'autres. Il y a PriceWiki qui scrape le prix d'objets de la vie courante de différents pays afin de comparer le prix de la vie. Rapportive qui mets en commun les informations de LinkedIn, les photos et les adresses mails d'une personne. GetHuman qui scrape les sites webs pour en extraire les adresses mails des gens à contacter.
Si vous voulez le faire vous-même, il existe quelques outils en SaaS qui peuvent vous mâcher une grosse partie du boulot. Kimonolabs qui en quelques clics vous transforme n'importe quelle page en une API. Import.io qui vous propose un GUI pour vous permettre de scraper n'importe quoi, s'occupe de vous masquer derrière un proxy et vous prévient en cas de mise à jour.
En un peu plus manuel, il y a Scrapy et ScrapingHub pour la version SaaS qui vous permet d'héberger vous même le scraper, de gérer la fréquence de mise à jour et le pool d'ip à utiliser.
Si vous voulez le faire à la main, la combo Tor, Squid et Polipo permet de facilement anonymiser ses connections. Après pour parser le HTML et en extraire les infos intéressantes il y a Nokogiri en lib Ruby, mais celle-ci ne gère pas toute la logique de connexion, gestion des erreurs HTTP, etc. C'est juste une lib de parsing HTML, donc il vous faut obtenir le fichier initial.
Il a fini par quelques conseils de sioux pour éviter de trop se faire remarquer. Hidemyass pour changer son ip facilement. Envoyer de simples requêtes curl en HEAD pour checker si la page a été mise à jour ou non. Regarder les flux RSS qui sont une source énorme d'infos sur les pages du site. Regarder les robots.txt et les sitemaps, et envoyer un faux header pour se faire passer pour Google Bots ouvre aussi pas mal de portes.
Un talk super intéressant, pour une discipline que nous avons tous déjà du pratiquer au moins une fois, mais qui est toujours aussi casse-gueule et manuelle.
BackBee
Et donc, le dernier talk, au pied levé par Mickael (qui nous avait déjà présenté les licences libres un peu avant). Il nous a parlé de BackBee, le CMS "orienté gestion de contenu" (?) qu'il développe, fondé sur Symfony et Doctrine.
Encore une fois, j'ai pas réussi à vraiment comprendre ce qu'il faisait. Je me souviens qu'il y a de la config en yaml, un client js en front distinct du back, un système de templating, une API Rest, la possibilité de faire de l'edit in place mais très honnêtement je serai bien incapable de dire ce que ça fait réellement.
Conclusion
Au final, une soirée sympa mais malgré tout placée sous le signe du fail.
Pour la session d'Avril, les HumanTalks avaient lieu chez Meetic. Meetic en a profité pour nous faire une petite présentation de l'historique de la boite. Ils sont aujourd'hui dans la position de la startup qui a grandit très vite, qui a racheté plusieurs autres boites et qui se retrouve très rapidement avec un legacy et un SI complexe. Ils sont aujourd'hui dans une phase de simplification, à base d'architecture REST, d'industrialisation, de TDD, de BDD, un peu de Docker dans un coin, et plein de choses intéressantes.
Ils sortent aussi progressivement du travail avec les prestataires qui ont anciennement développé leurs applications pour les internaliser aujourd'hui, et redonner un coup de jeune à leur présence en web mobile, puis sur le desktop. Ils ont des concurrents beaucoup plus hypes avec Tinder et Happn et veulent rester à la page.
Après cette petite entrée en matière et après la présentation des HumanTalks, on est partis sur les talks.
L'UX n'est pas là où vous le pensez
On commence par le talk le moins technique de la soirée, plutôt porté sur l'UX pour débutants. Christophe Michel, d'Arolla nous raconte une petite histoire de toilettes d'une grande banque française noire et rouge.
Les toilettes sont un lieu exclusivement utilitaire, on y va parce qu'on a besoin d'y aller, et on n'y va que pour une seule chose. C'est donc un très bon endroit pour s'entrainer à faire de l'ergonomie.
Malheureusement, les toilettes dont il nous parle semblent avoir été fait en dépit du bon sens. Les portes ne peuvent pas s'ouvrir complètement car elles tapent contre la céramique des toilettes, obligeant les gens à se contorsionner pour entrer ou sortir. Les pictogrammes sur les portes censés indiquer si ce sont des toilettes homme ou femme sont peu clairs, et il a fallu rajouter une indication au marqueur pour réussir à faire la différence. Une fois toutes ces épreuves terminées, on doit encore se battre avec les lavabos dont la vasque hyper-profonde se voit affublée de robinets qui coulent au ras des bords et d'une sèche-main "automatique" qui ne se mets jamais en marche.
Bref, tout cette introduction permettait de mettre en valeur le fait que les personnes ayant construit ces lieux ne se sont jamais mis dans la peau des utilisateurs. Tout cela sent bon le cahier des charges suivi à la lettre, sans réfléchir à l'utilisation réelle des personnes finales.
Et cela fait un bon parallèle avec le développement des applications. Bien souvent, quand on développe et qu'on reste focus sur les fonctionnalités à ajouter, on ne pense pas à l'utilisateur final. On va mettre des menus déroulants de 125 entrées pour choisir un pays même si 99% de nos utilisateurs seront en France. Et déjà ça, c'est mieux que de demander aux users d'entrer eux-mêmes l'id du pays dans un champ libre...
On utilise aussi des messages de confirmation cryptiques, du genre "Êtes-vous sur de ne pas vouloir annuler votre action ? Oui. Non. Annuler". Dans ces cas là, un messages reformulé et surtout des boutons plus explicites permettent de lever les ambigüités.
Finalement, le talk mettant en garde les développeurs sur la facilité que l'on peut avoir à choisir la solution techniquement la plus simple, et celle que l'on sait utiliser avec notre background, mais qui n'est généralement pas la plus évidente pour l'utilisateur final.
Je regrette un peu que le talk n'est pas donné plus de pistes d'améliorations (faut-il intégrer un ergonome à part entière dans l'équipe, si oui à quel moment ? Au début, tout le long, à la fin ? Ou bien est-ce un travail qui doit être dilué dans toute l'équipe). Je reste un peu sur ma faim, mais c'est une piqure de rappel bienvenue.
Dans les commentaires de la page meetup, Christophe a donné pas mal d'idées de lecture pour creuser plus profondément :
On a ensuite enchainé sur le talk de Jean-Christophe Honde de Meetic, qui travaille justement dans l'équipe de refonte de l'appli mobile. Full disclosure: je viens de passer les 6 derniers mois dans cette équipe, donc le sujet m'étais très familier.
JC a orienté son talk non pas sur les spécificités de la refonte Meetic mais sur le choix de la technologie pour le faire. Ils sont partis sur famous, un framework d'animations JavaScript dont la promesse est de délivrer des performances aussi bonnes sur tous les devices, même les plus vieillissants.
Il explique comment et pourquoi ils ont fait ce choix. Pour lui, une technologie est viable en entreprise si elle corresponds aux trois critères suivantes : le code est testable, la communauté est active, et elle apporte quelque chose d'innovant.
Il est inutile de rappeler pourquoi les tests sont exceptionnellement importants (réduit le cout de devs, évite les non-régressions, fait office de documentation, etc), et on va surtout parler des deux suivants. Une communauté active permet de s'assurer que la techno sera maintenue pendant plusieurs années, et le coté innovant permet à la société qui l'utilise d'avoir un avantage face à ses concurrents.
L'appli n'est pas entièrement bâtie sur famous, il y a aussi un socle en Angular, mais là n'était pas le sujet du talk donc on est passé vite les classiques reproches qui lui sont fait.
Pour JC, la promesse de famous est de réussir là où HTML5 a échoué. C'est à dire que les specs CSS3 promettent monts et merveilles en terme d'animation, mais le support est encore fragmentaire, parfois inexistant ou beaucoup trop lent sur de vieux devices. Famous quand à lui se pose comme une couche JavaScript sur les propriétés CSS 3D Transform. Ces propriétés utilisent la puissance du GPU des devices de manière à utiliser au maximum les possibilités du téléphone, et l'abstraction Famous permet de simplifier leur écriture.
Et ça marche. Famous utilise en partie le DOM HTML classique, mais place tout ses éléments en position:absolute dans un viewport de taille fixe et les anime en CSS. Des tas de démos du framework permettent de s'en rendre compte, tout s'anime dans tous les sens, comme cette table périodique des éléments en 3D.
Sauf que ce que Famous ne fait pas, ce sont les éléments de UI. La librairie ne fournit pas, ou très peu, d'éléments permettant de créer un UI facilement (comme peut le faire Ionic par exemple). Il faut donc récréer soi-même toute cette partie. Au final, on résout effectivement le problème de performance, mais au prix d'un plus long développement pour refaire ce que HTML nous offrait nativement (un peu comme Flipboard et leur surutilisation du canvas.
Si on rajoute à cela que Famous et Angular on des cycles de digest différents et qu'il faut réussir à synchroniser les deux, on rajoute une complexité supplémentaire.
Au final, des dires mêmes de JC, Famous ça marche, mais c'est compliqué. Il faut vraiment vouloir se plonger dedans et avoir un vrai besoin de perfs pour que cela vaille le coup. C'est couteux, mais c'est aujourd'hui d'après lui le seul moyen sur le marché.
Au final, j'en ressors en me disant que c'est une techno puissante, mais que j'utiliserais plutôt pour des animations 3D et pas pour de la UI (à moins d'avoir un vrai prérequis de support de vieux devices comme Meetic).
Son talk était fait comme un cours didactique où on commençait avec un code dont les responsabilités étaient très couplées. Une méthode instanciait un nouvel objet avant de le manipuler, ce qui rendait le tout difficilement testable (car difficile à mocker).
Elle a petit à petit transformé le code en inversant les concerns, et en ajoutant Google Guice dans l'histoire. À noter que l'exemple était évidemment donné en Java (Google Guice étant un framework d'injection de dépendance pour Java), et n'ayant jamais fait de Java, j'ai décroché en cours de route. Malheureusement, ses slides avaient peu de contraste de couleur et environ la moitié de la salle ne pouvait pas lire ses exemples.
J'ai quand même réussi à comprendre qu'une force de Guice était de permettre d'insérer des annotations au dessus de ses méthodes pour indiquer comment l'injection de dépendance devait se faire, ce qui permettait de garder un code simple mais explicite.
Au final, j'ai apprécié la démarche de refacto pas à pas (cela m'a fait penser à un chapitre de Practical Object-Oriented Design in Ruby de Sandi Metz où elle explique aussi par l'exemple comment inverser les contrôles.
Vim, il y a encore des gens qui codent avec ça en 2015 ?
J'ai ensuite donné la dernière présentation, sur vim, mon éditeur de tous les jours. Il est assez difficile de faire un récapitulatif de ce qu'est vim et surtout de donner envie d'essayer en 10mn, mais j'ai réussi à aborder la majorité des sujets qui me semblaient importants.
Vous pouvez trouver les slides ici, mais j'ai avant tout parlé du fait que pour nous autres développeurs, notre éditeur de code est notre outil le plus important. On passe des heures devant jour après jour et année après année, il faut donc que cet outil nous fasse gagner du temps et que ce soit un plaisir de l'utiliser. C'est notre éditeur qui doit se plier à nous et non pas l'inverse.
Je n'ai pas souhaité lancer un troll entre vim, emacs, IntelliJ, Sublime et tous les bons éditeurs qui existent, j'ai simplement parlé de celui que j'utilise et de pourquoi je l'apprécie.
Les avantages principaux de vim découlent tous du fait que c'est un éditeur en mode console. Une fois qu'on a lancé vim, on reste dans sa console et on fait tout au clavier. Vim est pensé comme ça, du coup, tout est pensé pour être fait sans souris, et cela va beaucoup plus vite une fois qu'on connait les touches. Ça permet aussi d'éviter de se faire mal aux avant-bras à force d'aller chercher sa souris sur la table et de se cogner le bras sur le rebords de la table, jour après jour, de manière répétées, pendant des années.
Vim fonctionne en deux modes principaux : le mode normal et le mode insert. Le mode insert est celui que tous les autres éditeurs appellent le mode normal: on appuie sur une touche, cette lettre s'affiche à l'écran. Pour vim en mode normal, quand on appuie sur une suite de touches, notre code en est modifié. On peut se déplacer comme ça dans le fichier, déplacer des lignes ou des mots, changer des arguments, faire des copié-collé.
Pour la petite histoire, j'avais assisté à un ParisJS il y a quelques années où Ryan Dahl, le créateur de nodejs était venu présenter son bébé. Il avait fait une séance de live coding avec vim et j'avais été bien plus ébahi par vim que par nodejs à l'époque. Le code semblait se créer sous mes yeux sans que je comprenne comment il avait fait. Et c'est une force de vim que je retrouve aujourd'hui, maintenant que je connais les commandes principales. La barrière entre le moment où j'ai une idée dans la tête et celle où mon code est modifié pour refléter cette idée est de plus en plus courte, ce qui me permets de rester in the zone.
J'ai finalement terminé en donnant plusieurs exemples de ce en quoi vim était customisable : macros, plugins, remapping de touches, appel à la ligne de commande, etc.
L'exercice était difficile, mais plusieurs personnes m'ont ensuite dit avoir envie d'essayer, je suis donc satisfait :). Si vous voulez jeter un œil à ma config vim, c'est par ici que ça se passe.
Conclusion
Meetic nous a ensuite régalé avec d'excellents bagels et cookies (quantités telles qu'on avait encore de quoi manger le lendemain midi) et les discussions/trolls ont pu continuer sereinement dans la cafétéria.
Le mois prochain, les HumanTalks se passent chez Deezer, venez nombreux !
C'est Valtech qui nous a fait l'honneur de nous héberger dans leurs magnifiques locaux. On a pu profiter des talks confortablement assis dans de superbes fauteuils de salle de cinéma. Ça a aussi été mon bizutage comme co-organisateur, à monter sur scène pour présenter les HumanTalks à ceux qui n'étaient encore jamais venus. Valtech, Mailjet et Breaz, les sponsors, ont rapidement fait une petite présentation, et les talks ont ensuite rapidement commencé.
Tests de performances
Claude Falguière nous a parlé de la difficulté à faire des tests de performances. Initialement, les tests de perfs étaient là pour s'assurer que la machine cible allait réussir à tenir la charge des requêtes qui allaient lui arriver dessus. Aujourd'hui, avec la puissance du Cloud, il suffit d'agrandir la machine en question pour régler les problèmes de perfs. Le but des tests aujourd'hui n'est plus de s'assurer que la machine tienne la charge, mais que la charge coûte moins cher.
Dans le joyeux monde des entreprises, il y a deux moyens de faire de la perf. Le premier, c'est de ne pas en faire : on fonce, on code, on déploie et ça plante, et après on essaie de patcher pour éviter les catastrophes. Ou alors, le problème est déjà arrivé par le passé et alors on a ancré dans le process qu'il fallait faire des tests de perf. Alors on coche la case sur la checklist avant de mettre en prod et ça nous donne un petit sentiment de sécurité.
Sauf que bien sur, les tests ne sont jamais réellement fait sur un environnement équivalent à celui de production, et donc le résultat n'a pas beaucoup de sens. Garbage in, garbage out.
Le vrai objectif final à avoir, à ne pas perdre de vue, c'est que tout doit fonctionner en prod. On vérifie bien sur en dev si ça fonctionne, car si ça foire en dev, ça va foirer aussi en prod, mais c'est pas parce que ça marche en dev que le travail est terminé.
On peut extrapoler les besoins de la prod à partir d'un petit subset de dev. On regarde les fuites mémoires, on regarde la consommation, et on peut extrapoler sur ce que ça va pouvoir tenir/combien ça va nous couter une fois scalé.
La prod doit être monitorée, on doit avoir des metrics sur ce qu'il se passe quand de vrais utilisateurs utilisent le système dans des conditions réelles. Et ces informations doivent être facilement accessibles, visibles et lisibles par tout le monde. Allez, on peut lacher le buzzword, il faut que ça soit devOps. Il faut que les devs qui ont codé la feature puissent voir son implication sur les ressources une fois en prod, voir la RAM utilisée, le nombre de connexions parallèles, les bottlenecks, etc. Ce n'est que comme ça qu'ils pourront améliorer leur soft pour améliorer les perfs.
C'est un travail régulier, un aller-retour entre le code bien couvé au chaud en dev, puis son exposition au monde extérieur et son amélioration. On peut rajouter quelques tests de performance automatiques, mais uniquement sur les metrics critiques (disponibilité, temps de réponse) et les tunnels critiques (paiement).
Mais les tests ne seront jamais assez, parce que la production est par définition imprévisible. Et la question n'est pas "Et si la prod plante ?" mais "Quand va la prod planter ?". L'infrastructure (et c'est aussi bien du point de vue technique qu'organisationnel) doit accepter l'échec, et apprendre de ses erreurs. Il faut quelque chose de flexible, qui scale, qui soit agile, qui puisse apprendre et trouver des solutions. Par exemple, prévoir une possibilité de faire du feature flipping des features les plus gourmandes permet de réguler la charge en offrant un service minimum degradé.
Il faut aussi penser à un mode dégradé. Que se passe-t'il si l'une des briques vient à tomber ? Est-ce qu'elle emporte tout avec elle, ou est-ce qu'on a un backup ? Par exemple prévoir un opérateur de paiement en ligne de backup au cas où le premier vienne à tomber permet de s'assurer que notre génération de revenus n'est pas intimement liée au bon vouloir d'un third party. Identifier les SPOFs et prévoir un backup.
Une bonne technique pour pouvoir tester une nouvelle feature et ses implications en terme de perfs sans pour autant la balancer directement dans le grand bain de la prod est d'opérer un Dark Launch. On créé en fait une copie de la prod, mais de manière cachée, qui contient la nouvelle feature. Et pour chaque requête qui arrive sur la prod, on la renvoie aussi sur la version dark. On peut voir comme ça si la version dark parvient à suivre la charge ou si elle s'écroule. Et si elle s'écroule, elle ne gêne pas les utilisateurs car elle leur est complétement cachée. Et cela nous génère tout un tas de logs et de datas qui vont nous permettre d'itérer encore sur la version dark avant de la sortir du coté visible.
Une autre technique similaire est de pousser les nouvelles features à de plus en plus d'utilisateurs, graduellement. Par exemple, une feature n'est activée que sur demande explicite des utilisateurs, sur une liste triée représentative ou pour un pourcentage aléatoire. La feature est techniquement en prod, déployée pour tout le monde, mais le feature flipping sélectif s'assure que tout le monde ne soit pas impacté directement.
Ces deux méthodes possèdent néanmoins un défaut, c'est sur la structure des données. Si une partie des utilisateurs ont accès à une feature et pas l'autre, il est probable que la structure de leurs données soit différente. Il faut donc bien s'assurer qu'on puisse faire cohabiter les deux.
Finalement on a aussi un peu parlé de la Simian Army de Netflix qui ressort dans toutes les présentations de ce genre. Elle leur permet de tuer aléatoirement des nœuds de leur infra en suivant le principe que "de toutes façons, la prod va péter, alors autant que ce soit nous qui le fassions".
Au final, encore une fois, pas de scaling sans devOps.
L'holacratie, travailler sans manager
Olivier Le Lan, coach agile de SOAT nous a fait un retour d'expérience sur le changement d'organisation qu'ils ont eu au sein de leur équipe de coachs agiles à SOAT. 4 coachs, managés par une personne. Puis un jour le manager s'en va, et les 4 coachs se demandent s'ils ont besoin d'un manager, ou s'ils peuvent se débrouiller seuls.
Le terme holacratie vient du grec holons, qui veut dire aussi bien l'entité constitutive, que le tout qu'elle constitue.
En suivant l'adage que "Le management, c'est bien trop important pour le laisser à une seule personne", ils ont trouvé une autre solution. Le management, c'est une technologie qui sépare les exécutants des pensants, et comme toute technologie, elle finit par être dépassée. L'agile de son coté remets en cause tout ça, incite les équipes à s'auto-organiser, à faire confiance à l'intelligence collective. Du coup, est-ce que le management est utile en mode agile ?
Il nous a parlé de Zappos qui a supprimé 1500 postes de managers pour les redistribuer à d'autres postes dans l'entreprise, et remis tout le monde au même niveau de hiérarchie.
Chez Soat ils se sont séparés en différents cercles, regroupés par affinités, par buts (cercles de coachs agile, cercles par projets, cercles par techno, etc). Chaque individu faisant partie de plusieurs cercles, et chaque cercle étant auto-organisé.
Le principe fondamental de l'holacratie est qu'on continue d'avoir un manager, mais ce n'est plus une personne, c'est un rôle, qui est tournant au sein des individus d'un même cercle. Chaque individu peut avoir plusieurs rôles (dans différents cercles) et plusieurs individus peuvent avoir le même rôle.
C'est pour le moment une expérimentation chez SOAT, qui porte ses fruits dans le cercle des coachs agiles. À eux 4 ils se sont répartis les rôles et les changent régulièrement (une réunion par mois où les rôles peuvent être changés), chacun est responsable d'être le lien privilégie avec les autres cercles de SOAT (comm', rh, etc).
Le point principal pour la création d'un cercle auto-géré comme cela c'est que tous les acteurs doivent être alignés sur le WHY de leur cercle ET sur le WHY de leur entreprise. Même si les objectifs de chacun sont légérement différents, le but n'est pas d'avoir un consensus de tous, mais un consentement de chacun. Il ne faut pas que tout le monde dise oui, il suffit que personne ne dise non.
Il y avait un sceptique dans la salle pour qui une telle organisation était utopique, et qui était rassuré de voir qu'on ne supprimait pas le management, mais qu'on supprimait juste le manager. La différence est que ce rôle de manager qui est dévolu à l'un des membres du cercle ne doit pas lui prendre plus de 10% de son temps, par opposition à un individu dont c'est le travail fulltime.
REX très intéressant au final, l'expérience semble très bien se passer à SOAT.
Ionic Framework
Loïc Knuchel nous a ensuite parlé d'un sujet plus tech, le framework Ionic. Mélange d'Angular et de Cordova, il permet de développer des applications hybrides assez facilement.
Loïc est un dev-front end et un entrepeneur, et il a plein d'idées. Et la plupart du temps, ces idées se décomposent sous forme d'appli mobile. Avec Ionic, il peut rapidement faire des protos pour les tester.
Ionic est livré avec une batterie de composants (packagés sous forme de directive Angular) pour la majorité des besoins de UI des applis d'aujourd'hui. C'est un peu le Bootstrap de la UI mobile web, avec des sliders, des listes, des boutons, des pull-to-refresh, des popovers, des onglets, etc.
Visuellement, les styles sont très orientés iOS mais une version Material est en cours. Ionic est aussi livré avec un petit outil en ligne de commande qui permet de générer un splashscreen, des icones, de gérer le livereload, d'inclure Crosswalk pour une execution plus rapide, et de tester les différentes vues Android/iOS directement dans le browser.
La version 1.0 vient de sortir officiellement, ce qui donne vraiment envie de tester le système pour des POCs rapides. Pour une petite idée d'appli qui reste dans les standards de UI actuels, et pour se concentrer uniquement sur le fonctionnel, ça semble un choix tout à fait sain. Je testerai sans doute sur un side project bientot.
Il n'y a pas de gestion native de l'offline, mais des plugins cordova (donc non-spécifiques à Ionic) permettent de l'ajouter.
Bien sur, ça reste du web mobile, avec de l'Angular, dans une WebView donc oui ça sera moins rapide que du natif, mais ça restera assez rapide pour qu'on ne s'en plaigne pas. Ça a aussi l'avantage de pouvoir se prendre en main plus facilement par des fronteux, et ça peut soit se packager sous forme d'app, soit directement accessible sous forme de site web (et dans ce cas, pas besoin d'approbation du store).
L'intrapreneuriat, qu'est-ce que c'est ?
Finalement, c'est Christopher Parola, co-fondateur d'elCurator qui vient nous parler d'intrapreneuriat. Ayant suivi un peu la vie d'elCurator à Octo, son talk a quand même répondu à quelques questions que je me posais sur cette structure (pourquoi ? qui possède quoi ?).
Il nous raconte un peu le début du projet, une idée qui avait été lancée à Octo, lui et Jérémy qui travaillent dessus sur leur temps perso, le partage au sein d'Octo. C'était un parfait bac à sable pour eux deux pour apprendre Rails et le Lean Startup. 2 ans plus tard, elCurator est une structure à part entière et eux deux en sont salariés.
Question financement, au début tout est payé de leur poche : nom de domaine, hébergement. En tournant sur Heroku, ils limitent énormément les coûts. Plus tard, ils seront hébérgés dans les locaux d'Octo.
Pourquoi avoir fait la bascule au bout de 2 ans ? Pour eux, c'est parce qu'ils commençaient à avoir des clients, et l'envie de travailler sur le projet à temps plein, mais cela peut-être fait plus tôt, voire dès le début. L'intrapreneuriat est encore quelque chose d'assez vague, il y a très peu de littérature sur le sujet et peu d'exemples, donc il n'y a pas vraiment une seule façon de faire, c'est en fonction du projet, des sociétés et des gens.
C'est d'autant plus flagrant au niveau de la structure juridique. Il n'y a aucune règle particulière, aucun statut spécial, tout est encore une fois à faire en bonne intelligence avec l'entreprise. Dans le cas d'elCurator, ils ont monté une SAS, et se sont répartis les parts. La question de la propriété intellectuelle du produit est par contre une question plus complexe à résoudre, surtout dans le cas d'elCurator où une partie a été créé sur du temps perso et une autre sur du temps de salarié Octo. Son conseil: statuer sur ce point le plus tôt possible.
Le même conseil est donné quand à la répartition des parts. Plus la société est créée tard, et donc plus la répartition des parts à lieu tardivement, plus les négociations sont complexes. Une fois que le projet est parti, que du monde a travaillé dessus, qu'il rapporte déjà de l'argent, il est plus dur de discuter séparation des parts. Bien sur, il ne faut pas non plus commencer à se séparer les parts alors que rien n'a été créé, on risque de tomber dans le syndrome du groupe de rock d'adolescents qui splitte avant d'avoir écrit la moindre chanson car ils ne sont pas d'accord sur comment séparer leurs futurs millions.
Dans le cas d'elCurator, la séparation a été effectuée équitablement entre les deux associés et Octo, puis Octo a abondé pour racheter des parts, un peu comme une levée de fonds.
Pour l'entreprise, incuber une société lui permet d'innover dans un domaine qui n'est pas son domaine premier, lui permet de se diversifier, et de ne pas perdre des collaborateurs qui seraient sinon partis faire leur projet ailleurs. Pour les créateurs, l'avantage majeur est la sécurité. En restant incubé chez Octo, ils continuaient de garder leur salaire pendant 2 ans, tout en bénéficiant de locaux, d'un écosystème et d'un carnet d'adresse.
La différence majeure entre un intrapreneur et un entrepreneur se situe ici. L'entrepreneur se moque des risques, il croit fermement à son idée et est prêt à vivre de peu, de travailler beaucoup, pour monter son idée.
Finalement une question de l'assistance qui m'a semblé assez folle, sur une rumeur qui court sur Octo. D'après la personne qui posait la question, Octo donnerait environ 20% de temps à chaque employé pour travailler sur des projets perso (à la Google), mais si jamais ces projets sont rentables, tout les bénéfices vont dans la poche d'Octo. Pour être plutôt bien placé pour le savoir, je peux dire que cette rumeur n'est vraie ni dans ses fondements ni dans ses conclusions.
Conclusion
Super session, comme d'habitude. 4 talks très intéressants et des discussions qui ont duré jusque tard dans la nuit après coup. Du technique, de l'orga, des retours d'expérience, un très bon mélange !
Première fois que je mets les pieds dans un meetup Meteor. Je n'ai jamais touché à la techno et ne l'ai suivie que de loin. Mais comme l'invité d'honneur de ce meetup est mon pote Sacha, j'y suis allé par curiosité.
Criteo a hébergé le meetup, dans une salle très spacieuse. Bon, c'était en sous-sol et on n'avait pas d'accès Wifi, mais ils se sont carrément rattrapé sur le buffet (Sushis + pizzas pour nourrir un régiment). Comme d'habitude, Criteo fait son speech de recrutement bien rodé : "on est gros, on paye bien, on a toutes les stacks dans notre SI, il suffit juste que vous soyiez assez bon pour nous rejoindre".
Pour en revenir aux meetups Meteor, ça fait deux ans qu'ils existent, mais de manière assez organique, sans véritablement de date fixe, ni de format spécifique. À partir de ce meetup, ils deviendront réguliers, tous les 3e mardis de chaque mois (choisi de manière à ne pas se mettre le même soir que d'autres meetups déjà existants). Ce soir, le format était de 4 présentations, suivi d'un buffet, puis de discussions par groupe. Au final, après avoir mangé, les discussions ont continué, mais de manière très informelle, et c'était pas plus mal.
Meteor + Docker
La première présentation était d'un side projet qui permet de piloter des instances Docker depuis une UI web. La motivation était de ne pas avoir besoin de taper des lignes de commande longues pour spawner des instances, et de pouvoir voir sur un dashboard l'état de ces instances.
Visuellement ça ressemble à un site classique en Bootstrap, avec la liste des images disponibles, possibilité de les spawner en un clic ou de configurer un peu les valeurs par défaut (port, working directory, etc).
Par derrière, Docker exposant une API REST avec un endpoint streamant le flux des events, Meteor se pluggue juste dessus et transmets ces events dans une base mongoDB. La base représente donc à tout moment l'état actuel des instances. Ces états sont alors renvoyés en temps réel aux différents clients.
Ça signifie que même les instances lancées/tuées depuis une autre source que l'UI web sont quand même visualisables dans la UI.
La facilité avec laquelle on peut plugguer un flux d'event dans du web temps réel sur X clients était assez impressionante, même si je ne suis pas bien sur du use-case d'un tel projet.
Telescope
La seconde présentation était celle de Sacha. Il présentait Telescope, le projet open-source sur lequel il travaille depuis 2 ans, et qui lui a servi de base/exemple pour le livre Discover Meteor.
Telescope est destiné à créer un clone de HackerNews. Une liste de threads, sur lesquels les gens peuvent voter et laisser des commentaires. Mais surtout, il est extensible pour que chacun se l'approprie et puisse rajouter de nouvelles fonctionnalités.
Il nous a fait un tour d'horizons des différentes versions de Telescope disponibles en production. Déjà crater.io, qui rassemble la communauté meteor en restant très proche du telescope original.
thedrop.club de son coté utilise telescope pour la musique. Chacun peut poster une musique de soundcloud, tout le monde peut voter, et le site se transforme alors en immense playlist qu'on peut jouer depuis son browser.
On a codebuddies où chacun peut proposer une room hangout pour discuter d'un problème de code. On réserve sa place, puis on se retrouve à l'heure donnée pour discuter. On continue une version proche de thedrop, mais pour les beatbox en video (j'ai pas retrouvé le lien par contre).
Et finalement, un seconde création de Sacha, crunchhunt qui agrége tous les posts de TechCrunch et les classe par nombre de share, avec un aperçu. Pour ça il utilise une fonction native de meteor qui parse un flux RSS, il rajoute un coup de kimonolabs par dessus pour APIfier les pages de TechChrunch pour en ressortir le nombre de shares et génère un thumbnail avec l'API d'embedly.
Au final, on voit que Telescope peut être utilisé pour créer rapidement des sites sur le même modèle, et ça peut être un très bon exemple pour apprendre à structurer son code Meteor.
Finalement, la session de question réponse à porté sur les plugins intéressants à utiliser. simpleschema apporte le principe de Model (le M de MVC) et les validations qui vont avec. autoform permet de générer automatiquement des formulaires de CRUD pour ces schemas.
Je retiendrais que Meteor est très au point pour ce qui est de la gestion du cache. Comme le code client et serveur est mélangé, dès qu'on pousse une modification sur le serveur, tous les clients la reçoivent instantanément. Par contre, vu que tout est basé sur des websockets, le scaling de ce genre d'appli n'est pas évident, mais ce n'est pas un soucis propre qu'à Méteor. De même, il subit les mêmes problèmes que n'importe quelle appli SPA : pas de server-side rendering, donc il faut que tout le JS soit chargé coté client avant que quoique ce soit ne soit affiché, et défaut de SEO.
Startups d'État
Matti Schneider nous a ensuite parlé de son travail en Meteor au sein des startups d'état. En particulier, il nous a parlé de comment il a pu développer en 5 jours une appli Meteor de simplification de gestion des fiches de banc.
Vous ne savez pas ce que sont les fiches de banc ? Et bien moi non plus je n'en avais aucune idée. Si j'ai bien tout retenu (parce que c'était quand même pas la procédure la plus simple), ce sont les fiches qui servent à tenir le compte des amendements sur une loi. Celles-ci se retrouvent imprimées en plusieurs exemplaires (selon un formalisme sans doute hérite de Napoléon) et rangé dans des classeurs.
Quand une loi possède des milliers d'amendements (parce que nos députés n'ont pas envie qu'elle passe trop vite), il faut des salles entières pour stocker les classeurs en questions, et garder l'ordre chronologique des amendements devient une tache titanesque qui demande énormément de travail manuel.
Matti a donc rapidement développé un POC en se basant sur une API de l'Assemblée Nationale qui permet de récupérer la liste des amendements (dans un format XML non documenté quand même sinon ça serait trop facile). Et à partir de là, c'est juste une question de skill Meteor pour présenter cela dans une belle UI qui permet à chaque cabinet de député de lister les amendements et indiquer un résumé en quelques lignes et si le député doit voter pour ou contre.
Bref, une belle simplification !
Libreboard
Une autre démo technique en Meteor hyper impressionnante. Celle-ci n'est rien de moins que la réimplémentation open-source en Meteor de Trello. Exactement les mêmes features que Trello (même plus, avec l'i18n), mais libre et installable chez soi.
Bon, vu qu'ils ont quand même piqué la CSS de Trello ils ont du enlever le projet de GitHub, mais il est quand même dispo sur leur git perso.
Franchement, impossible de voir la différence avec l'original, c'est vraiment du beau boulot.
Tuniliv
Finalement, une demo de tuniliv, un site Tunisien permettant de faire de la livraison entre particuliers. L'un passe une annonce comme quoi il souhaite envoyer un objet (taille Small, Medium, Large) de telle ville vers telle ville. Un autre peut accepter l'offre et se faire rémunerer pour ça.
La démo a été faite avec deux browsers ouverts ensemble pour montrer les interactions entre les deux, ça marche plutôt bien. Le site n'a pas encore réussi à terminer complétement une transaction entre deux personnes, mais en même temps il n'est pas en production depuis longtemps.
La version 1.0 vient de sortir officiellement, ce qui donne vraiment envie de tester le système pour des POCs rapides. Pour une petite idée d'appli qui reste dans les standards de UI actuels, et pour se concentrer uniquement sur le fonctionnel, ça semble un choix tout à fait sain. Je testerai sans doute sur un side project bientot.
