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.
12 édition de ParisHacker. J'étais allé aux premières éditions il y a quelques années, où on discutait des top topics d'HackerNews, où chacun pouvait présenter quelque chose en 5-10mn, où des questions étaient posées à la cantonnade.
Tout ce coté s'est un peu perdu, et j'ai plus l'impression d'aller à un meetup de devs (globalement experimentés), voir quelques présentations sur des sujets divers, mais sans forcément de fil conducteur.
Bref, cette fois-ci, c'était chez Tektos, un incubateur du coté de Marcadet-Poissonniers. Ils incubent des startups assez longtemps (ils en ont une avec 40 employés), et semblent se spécialiser surtout dans les startups tournées vers un marché anglophone.
On a eu le droit à une petite panne de courant dans la salle du meetup qui nous a obligé à nous déplacer dans une autre salle avant que les talks ne commencent réellement.
Hosting large audience websites with Varnish
Maxime Kurkdjian d'Oxalide nous a parlé de leur business d'infogérance des gros sites de presse français. Le début de la conférence était en anglais (ce qui est d'usage aux ParisHacker), mais Maxime avait beaucoup de contenu à nous faire passer et la barrière de la langue l'obligeait à limiter les informations qu'il souhaitait faire passer. On a donc décidé de revenir en français pour la fin de la conférence, et c'était du coup beaucoup plus riche.
Oxalide s'occupe des sites de 20 minutes, l'Express, le parisien ou encore Radio France. Leur cœur de métier est l'amélioration des perfs et la tenue de charge dans les métiers des médias et de la presse.
Ce sont des sites qui possèdent beaucoup de contenu, avec de nouvelles pages ajoutées chaque jour. En cas d'actualité intense, les serveurs sont très demandés, et les pages mises à jour régulièrement. Les articles les plus récents sont beaucoup plus demandés que les articles anciens. Il faut donc réussir à faire scaler tout cela, idéalement sans avoir à changer le parc informatique existant, mais juste en rajoutant le bon système de cache devant.
Le 7 Janvier, les attentats de Charlie Hebdo générent un nombre record de pages vues sur leurs services. 56.000 requêtes / seconde en moyenne, pour plus de 157 millions de visites dans le mois. C'est la plus grande affluence qu'ils aient jamais eu a gérer.
Le challenge d'Oxalide, c'est de réussir à gérer de gros traffic, sur des sites qui ne sont pas forcément bien optimisés pour de la perf. Il lui a été posé la question en fin de session "Si j'ai un site avec 500 millions de requêtes par jour, ça me couterait combien chez vous ?". Il a répondu qu'il ne pouvait pas donner de chiffres aussi facilement, parce que cela dépends pour environ 80% de la dette technique du site qui est derrière. La techno n'a ici aucune importance, c'est vraiment la dette technique et les améliorations sur les serveurs d'origine qui vont être un facteur limitant.
Bref, revenons à Oxalide. Même s'ils peuvent mettre des tas de choses dans le cloud, spawner de nouvelles machines en cas d'affluence, tout n'est pas si rose. Le cloud nous fait croire que nous avons des ressources illimitées à notre service, mais cela n'est pas complétement vrai. Tout simplement parce que notre portefeuille, lui, n'est pas illimité. Il va donc falloir être efficace avec les machines qu'on a.
Continuous improvement
La première étape, c'est de se mettre des objectifs. Nous avons besoin de réponses quantifiables à des questions simples. Quel doit être le temps de réponse maximum autorisé ?, quelle charge doit être tenue sans avoir à dégrader l'UX ?, à quelle vitesse le site doit réagir à des pics de charge ?, quel est le response time autorisé en cas d'affluence ?, etc.
On track toutes ces infos dans des dashboards qui nous donnent l'évolution à court terme, et à long terme. Les seuils doivent être fixés par la direction de l'entreprise. C'est elle qui sait, en fonction de son business model, ce qu'il vaut mieux privilégier.
Réussir à tenir face à une montée en charge, c'est comme jouer à un tower defense. On doit protéger ses ressources les plus chères et les plus fragiles de la horde de connexions qui vont arriver. Nos back-end PHP et nos DB mysql font parti de ces assets à protéger.
On mets donc un cache Varnish devant. Il va absorber 90% des requêtes directement. Ensuite, derrière le Varnish on rajoute quelques autres protections pour réduire l'impact des requêtes qui sont passées : APC, memcache, query cache.
Avec un Varnish bien configuré, on peut multiplier la capacité d'un site par un facteur de 100, et réduire le temps de réponse par un facteur de 10. Comme effet bonus, avec un temps de chargement plus rapide, on améliore aussi l'UX finale.
L'idée est d'avoir un taux de caching de 90% et de tendre vers un 100%.
Varnish en détail
La perfection, ce n'est pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à enlever.
Cette citation de St-Exupery est parfaite dans le domaine de l'optimisation de montée en charge. On veut que chaque élément qui se trouve sur la zone de défense entre les clients et nos serveurs finaux soient le plus rapide possible, et pour ça, il faut qu'il soit le plus léger possible.
Oxalide préconise d'avoir deux lignes de Varnish. La première, la plus proche des clients est la plus stupide possible. Elle sert de cache HTTP simple. Elle peut contenir des dizaines de serveurs Varnish si nécessaire. La deuxième, juste derrière, fait des choses un peu plus intelligentes. Elle active la compression gzip, gère la validation des assets, etc.
En faisant ainsi la première ligne réponds très vite, et si une requête fait un cache miss, elle va taper la seconde, qui est aussi bien rapide, sans avoir à taper les serveurs d'origine. Cette topologie permet aussi de facilement spawner des Varnish en première ligne, qui peuvent être dans le cloud, et donc les décommissioner rapidement une fois la charge terminée. À noter que quand on ajoute un nouveau Varnish dans un pool, il commence avec un cold cache, et va donc devoir requêter l'origine pour se former son cache. Encore une fois, en ayant un deuxième niveau de Varnish, il ne requête pas directement l'origine.
Attention toutefois au domino effect. Il faut faire attention à la consommation de chacune des machines d'un pool de serveurs Varnish. Si on a deux machines et que les deux sont environ à 50% de leur capacité, si l'une tombe, l'autre va se manger toute la charge de la première, et dépasser ses 100% de capacité et tomber aussi. Il faut toujours avoir suffisamment de machine dans un pool pour que même si une machine tombe, la charge sur les autres ne dépasse jamais 50%.
Hardware
Quand on doit gérer du très fort traffic, le commodity hardware ne suffit pas. On veut des éléments qui répondent vite, et qui ne fassent que ça. Il faut donc choisir son hardware en fonction, et Oxalide continue de monter des serveurs physiques "comme avant", pour éviter la couche de virtualisation qui prends du temps, et être au plus près du barebone.
Plusieurs optimisations peuvent se faire directement au niveau du BIOS, et la configuration out of the box des machines du commerce ne fonctionne jamais pour un besoin spécifique de grosse charge.
Le simple fait de changer la taille de la congestion window TCP permet des gains de perfs de 30% sur le réseau.
DevOps
Si on veut gérer un énorme traffic, il faut savoir qu'on va se planter plusieurs fois avant d'y arriver. Pour ça, il ne faut pas avoir peur de l'échec, et apprendre de ses erreurs. Il faut aussi une culture de devOps. S'il y a séparation entre les équipes de dev et les équipes de prod, aucune optimisation ne peut être fait.
Les ops fournissent aux devs des dashboard pour qu'ils puissent suivre l'évolution des différentes mises en prod, des pics de charge actuels, des fichiers les plus sollicités, des bottlenecks dans le code, etc (avec Kibana. Comme ça les devs peuvent aider sur ces points, trouver des solutions et avoir un vrai retour sur l'implication de leur code sur leurs utilisateurs.
Encore une fois, le travail des dev, leur disponibilité, leur implication a beaucoup plus d'importance dans la réussite de la montée en charge que l'installation du Varnish devant. Pour Oxalide, 80% de la reussite ou non de la montée en charge vient du code de l'appli et de sa dette technique. Varnish peut aider, mais pas faire des miracles.
Questions
Viennent ensuite plusieurs questions diverses.
Est-ce que Varnish peut être utilisé à l'intérieur d'un SI, entre deux apps qui communiquent par API ? Oui, sans problème.
Est-ce que Varnish peut aider à cache une API en SaaS où chaque requête est dynamique et dépends du user authentifié ? Oui, à partir du moment où deux requêtes identiques donnent un résultat identique, Varnish peut aider. Si deux fois la même requête donne un résultat dynamique différent, alors non.
Exemple donné de MediaPart qui a multiplié par 5 son nombre d'inscrits après l'affaire Cahuzac. Ils n'ont pas changé leur infra, juste tweaké un peu plus leur Varnish.
Est-ce que Varnish est aussi intéressant pour un site d'e-commerce que pour des sites de presse ? Oui, sur un site d'e-commerce, 99% du site sera en cache dans Varnish, seul le panier et le tunnel de paiement tapera sur l'origine.
On a ensuite eu la droit à un Skype avec Pierre-Rudolf Gerlach, co-fondateur et CTO de Qleek. Qleek est à mi-chemin entre le software et le hardware, le dématérialisé et le physique.
C'est un petit bout de bois de forme hexagonale qui contient une puce RFID dans laquelle on peut stocker n'importe quelle musique, film, playlist, image. Il suffit ensuite de la poser sur un lecteur tout aussi sympa (en bois, de forme douce) pour jouer l'élément en question sur la télé.
Ça permet d'avoir un support physique aux œuvres qu'on aime, sans avoir à démultiplier les formats.
Pierre est un ex-Joshfire, donc habitué des meetups des ParisHackers. Il a aussi bossé sur le Nabaztag donc tout ceci ne lui est pas étranger.
Ils sont trois sur ce projet et après avoir été incubé à Numa (ex-Camping), ils sont maintenant à Bolt, un incubateur hardware à Boston. Le Camping a pu les aider sur le début, sur la partie entrepreneuriat, un peu sur le software, mais n'avait pas d'appui sur le coté hardware.
Leur système fonctionne, ils peuvent en produire, mais ils ne peuvent pas encore en produire en masse et l'incubateur en question va les aider à faire ça. Ils y testent de nouveaux matériaux (liège, plastique, verre), testent leur produit à des températures extrêmes, sous l'eau, sous une forte pression, pour tester ses limites.
Coté software, c'est en grande partie du web, je crois que le backend est en node mais pas sur. Coté hardware on a du RFID, du BLE, de l'ARM et de l'Android. Tout ça dans un mélange de bois, métal, aimants, avec une impression d'image sur le bois pour les personnaliser.
Il existe apparemment plusieurs accelérateurs hardware. Il y a Haxlr8r à Shenzen ou encore Highway 1 à San Franciso. Le leur, Bolt, a incumé iRobot (créateur du Roomba ou encore Pebble. Il est en plein centre-ville de Boston.
La difficulté qu'ils rencontrent actuellement est sur la packaging. Il faut que celui-ci puisse mettre le produit en valeur et expliquer en moins de 2s ce qu'il fait. Il faut aussi beaucoup travailler sur le speech d'explication du produit, et sur le nom à lui donner.
Tous les participants travaillent sur le même problème par équipe de 2 à 4. Google leur fournit un fichier d'input, et un problème à résoudre. Les équipes doivent fournir un fichier d'output et une note leur est automatiquement discernée en fonction de l'output. L'année dernière par exemple, ils avaient un fichier représentant les rues de Paris et ils devaient calculer l'itinéraire optimal pour qu'une Google Car les quadrillent.
Les inscriptions se terminent le 8. Je ne pense pas participer. Je m'étais inscrit l'année dernière mais je m'étais fais recaler dès l'inscription car ils avaient trop d'affluence. Cette année ils donnent un test préparatoire à faire le soir comme épreuvre de pré-sélection.
Au final, passer des épreuves éliminatoires, pour ensuite tous être en compétition pour résoudre un problème de Google me tente pas du tout. Je préfère les hackathons open bar, où tout le monde construit des choses différentes, innovantes, ensemble et pour le fun.
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.
