Third edition of the ParisCSS meetup. I could not attend the first two sessions, so this is a first for me. It took place at Numa, and we were about 70.
CSS Masks
In the first talk, Vincent De Oliveira told us about CSS masks. He started by telling us that we might all already use CSS masks without knowing it.
border-radius and overflow:hidden are actually masking techniques, even if we do not think of them that way. He showed some nice and clever tricks with a few simple divs, rotation animation and overflow:hidden.
He then told us about clipping, or how to use images with some transparent pixels to define which part of an image should be displayed. He had an impressive demo of a text that could be visible trough a complex form (here it was the Eiffel tower), using only an image as background and a mask on top of the element.
The end of the talk was really impressive, but it was also really hard to understand how things were working without testing the code directly. He showed us how he animated icons or animated a cursive script but to be honest I did not really understood how this worked. I'll have to play with the slides.
Rendering performances
The second talk was done by Jean-Pierre Vincent (alias @theystolemynick). I gave him a #millisecondsmatters Algolia shirt right before the talk, and he wore it while speaking. Algolia everywhere ;)
The talk was dense, and a broad array of topics were discussed, but the overall rhythm was slow and it was sometimes hard to follow. The talk started with the conventionnal numbers for this kind of talk (on how speed is directly linked to revenue), but he also spoke about how it is now good for SEO and how the human brain reacts to instant.
He covered the subjects of repaints and reflows in CSS, but focused on CSS animations compared to jQuery animations. Done well, animations can really improve the user speed perception. Quickly moving items or fading images when changing pages can distract the user long enough so she cannot see that a page is currently loading.
His point was that jQuery animations are not inherently slow because they use JavaScript, but because this JavaScript asks position and dimension information to the DOM engine. First, to get the correct values, the DOM engine must force a reflow of the whole page. Also, it requires a communication bridge between the JavaScript thread and the DOM engine, which requires stopping both of them while they communicate.
For every animation that do not depend on user input (eg. moving an image from one fixed position to another), we can pre-compute the bounds and simply create two CSS classes (one for the start and one for the end), and use CSS animations to let the GPU handle the rendering.
For "unpredictable animations" (eg. based on the way the user moves her mouse or scroll the page), there is no silver bullet. The main advice is to throttle or debounce the call. There is no need to fire an animation on every scroll event, but only on the first or last one.
As always, there is no perfect solution. One must be aware of all the pros and cons of every technique. For example, using the GPU (through CSS animations) allows for much faster rendering, but will also drain the battery more quickly on mobile devices. One can use the translateZ(0) trick to force an animation to use the GPU, but this will prevent browsers from doing any optimisation natively.
The trickiest part is that some devices have better GPU than others. Sometimes, it is better to let the CPU handle the animation in specific browser/device targets. As it is near impossible to perfectly target each mobile/browser with the best implementation, you either have to go for the lowest common denominator, or only focus on a few specific devices. None of this solutions are optimal.
He gave a rapid overview of the various layout techniques in CSS. We started with <table>-based layout, using the HTML markup to split our page. Then, we used float and display: table, which are still hacks and not made to do layout. Then came display: inline-block which have all the pros of inline (stays on the same line) and block (can have dimensions), but still has its own shortcomings (whitespace in markup and parent font-size can impact the rendering).
In the end, doing layouts in CSS is not easy and requires a deep knowledge of all the quirks and limitations. Frameworks like Bootstrap exists so users do not see the complex code used to do a simple grid layout. Few people really know how things work internally.
Then came flexbox, which is a set of CSS properties here for layout purposes. With it, you no longer need Bootstrap for your grid needs.
Still, all this techniques requires you to have specific markup to separate your rows from your columns. If you want to do a specific layout on various RWD breakpoints, and move an element from one row to another you might have to add the element twice to the markup and show/hide them depending on the current viewport.
display: grid is the future of CSS and fixes all that. By adding this to a parent element and then adding grid-row and grid-column attributes to children elements, we can simply specify where each cell should go. It also comes with its own set of rules letting you define a custom grid template, default spacing, stacking cells, move cells on breakpoints, define their dimensions based on the available space and even do ASCII art to draw your grid.
This is brilliant and really really powerful while having a simple and straightforward syntax. Unfortunatly, this is only available in the latest Chrome under an experimental flag.
Anyway, this future CSS syntax will one day become our present CSS syntax, so we'd better start using it now to get familiar with it and push issues and feature requests.
Conclusion
The overall level of the talks is quite high for a young meetup like this one, and the large number of attendees shows that Paris needed a CSS meetup. I will speak at the next event and encourage you to submit your talk ideas or proposals.
Note: For this post, I'll try to write in english. I'm now working in an english-speaking company and I'm already writing emails in english to give feedback on the HumanTalks sessions. I'm not used to write such lengthy posts in english, though. Hopefully I'll get better at it the more I do it.
This HumanTalks session took place at UrbanLinkers, a Parisian recruiting company. The room was packed and we had just enough seats for everybody.
IBM Bluemix
The first talk was by Alain Airbon, which was very nervous. He said so right at the beginning of his talk, but it was quite obvious. He talked about Bluemix, which is the PaaS developed by IBM. He showed us how the Bluemix dashboard UI was working, but it felt a lot like a commercial presentation, and we did not learn anything we could have learned in 10 minutes in the dashboard ourselves.
I did not really understood what Bluemix was actually doing. He spent very little time explaining what a PaaS was (he compared it to IaaS, explaining the differences, but even for IaaS, I would have loved to have an explanation). I think Amazon is to IaaS what Heroku is to PaaS, but I'm not even sure.
It was clear that Alain was very nervous, and wanted the audience to like his talk on stage, but it did feel too shallow, and too commercial. And developers have a very low tolerance to bullshit. An advice I could give to first-time speakers would be to talk about something they really like and are passionate about, so the audience can feel how they feel about it. A personal feedback on how he used Bluemix to deploy one of its own projects would have worked better I think.
Still, I liked the way he introduced Bluemix: "Bluemix is simply Cloudfoundry, repainted to the IBM colors. We might not be better than the alternatives, but at least we follow standards and use an open-source project". This was honest and straight to the point.
I hope this first talk will not discourage him from trying again another time, we're still open to hosting him again and can give some advice on public speaking.
Michel is convinced that regular code review inside a team will lead to better, more maintainable and more stable code in production. He announces numbers as high as a ROI of 4 to 1. For one hour spent on code review, we can save up to four hours of debugging. Almost 65% of bugs can be found before shipping, thanks to the reviews.
Michel then shared 3 personal stories with us. First, he told us about that time when he worked for 10 days on a feature that was originally estimated to 3 days. In the end he did a lot of refactoring, touched hundred of classes and thousands of LOC. Once done, he asked a colleague for a review. 30 minutes later, one of them came back to him with a few issues spotted, mostly variable naming and a few typos. So they pushed to production.
Two weeks later, a bug popped in. After two days investigating, it was obvious that the bug came from this new feature, so they had to start debugging live.
Here is what they did wrong. First, they rushed the whole thing. On average, you cannot review more than 300LOC/hour, so take your time and do it with a fresh mind, not late at night. If the feature involves a lot of changes, it's expected that the review also take some time. Also, Michel should not have waited 10 days before submitting his work for a review, he should have asked feedback earlier.
But also, it seems that the reviewer did not know what to look for in the code review. He found typos and naming issues, but he did not really looked inside the logic and the behavior. No-one told him what to look for.
In the second story, Michel told us about Bob who came to him one day at the coffee machine. Bob was upset, he was saying that Martin code was really ugly, that he was still doing hard-coded SQL queries. Bob said he spent the last hour fixing the issues of Martin.
That was a perfect recipe for failing at code review as well. Bob never spoke to Martin directly, he just complained to Michel. Instead they should have talked together. Then, Bob should never have corrected the issues himself. The author should fix its own errors, otherwise he will never learn. And finally this whole story of hard coded SQL queries had never been written anywhere, so you cannot blame people for not following it.
The last story was about Kent and Beckie (pun intended that were arguing loudly about snake_case vs camelCase, shouting in the open-space. In the end, Kent left saying "you're a shitty coder, Beckie!".
This is really the worse that could happen. Kent was criticizing people, not their code. When in doubt, always refer to the principles of the Egoless Programming. Your code is not an extension of yourself. It can be judged, improved or deleted, this has nothing to do with you.
Also, it was not the right time to argue about snake_case or camelCase. Refrain from starting a framework war or any kind of trolling when doing a code review. This is not the time nor the place. Find compromises, write it down and follow it.
I really liked this talk. Michel gave real-life examples that we can all understand. Coding involves much more human contact that we could initially imagine. The code of a project belongs to the community building it, not to the one person that wrote it. Anyone can write code. Writing maintainable, understandable, shareable code is harder. The only way to do it properly is to talk to your colleagues, and code together.
Memory techniques
This talk, I gave it myself. I've written a summary of it on my blog.
How to hack your electricity meter
Cédric Finance told us about how he hacked its electricity meter at home with a Raspberry Pi. He did not actually really hacked it, he simply plugged the Raspberry Pi to the public part of the meter and read the data sent by it.
He did it because he realized that we never really know how much electricity we're using. When we leave the water tap open, it's obvious how much water we're wasting, and we can almost see money flowing down the sink. For electricity, we never really know until we receive our bill.
Getting back to the technical side of things. The meter sends data as a stream of keys/values. The data is not self explanatory but fortunately the spec is available and it can easily be parsed. He realized that it gave him a much more accurate set of information than what was printed on its bill.
As soon as he got the data, he pushed it to Thingspeak, a SaaS service to push streamed data and generate graphs. With that he quickly saw that its water heater was malfunctioning. It was supposed to only work on off-peak hours, but was actually always working. Knowing that, he fixed it.
He then dropped Thingspeak to build a custom dashboard to capture data with a higher frequency. He let it run for more than a year and was then able to compare usage from one year to the next.
At first he did it just for fun, but he soon realized that he could better understand its electricity consumption and make some improvements to it. Now he went ever further, with humidity and heat sensors in his home and graphs for all that.
Conclusion
Once again, a nice series of talks. And once again, my favorites are the personal sharing of experience.
Next month will be a special event as we'll be celebrating the HumanTalks Paris birthday, in a bigger room than usual. Hope to see you there.
Deuxième jour de ParisWeb. La conclusion de mon CR précédent était un peu négative, mais cette deuxième journée m'a redonné la pêche et l'envie de faire de belles choses.
Digital Death and Digital afterlife
On commence par un sujet sérieux, celui de la mort dans le monde digital. Qu'arrive-t'il à notre avatar, notre présence en ligne une fois que nous sommes morts ? Tout le monde ici finira par mourir un jour, pourtant assez peu ont déjà écrit leur testament et encore moins ont pensé à ce qu'il arrivera à tous leurs comptes (Facebook, Google, Dropbox, etc) une fois qu'ils ne seront plus là.
Si on fait un rapide calcul, au vu de l'espérance de vie moyenne et du nombre de personnes sur Facebook, on a 10.000 personnes sur Facebook qui meurent chaque jour. C'est à dire qu'aujourd'hui, un compte sur 30 sur Facebook est un compte d'une personne décédée. Peut-être que dans votre friendlist, vous avez des personnes décédées mais vous ne le savez pas vous-même. Surtout que si on continue sur cette lancée, on devrait avoir sur Facebook plus de morts que de vivants d'ici 2065 ou 2100. Creepy, non ?
La mort peut toucher n'importe qui à n'importe quel age. Un accident, une fausse manœuvre et vous disparaissez, vous laissez derrière vous votre famille et vos amis et votre présence en ligne.
Nous sommes une génération numérique. Notre vie se trouve sur nos smartphones, laptops et dans le cloud. On n'envoie plus de cartes postales, on ne garde plus de photos papier de nous ou de nos amis, tout est dématérialisé. Notre famille ne peut donc pas se rattacher à des éléments matériels pour se souvenir de nous, il leur faut notre présence en ligne. Mais laisser ses comptes actifs alors que nous sommes morts, n'est-ce pas un peu morbide ?
Surtout quand ces comptes continuent d'agir comme s'ils étaient actif. Quand Facebook vous rappelle l'anniversaire d'un proche décédé, ou qu'il apparait toujours dans la liste de vos destinataires.
Certains services ont commencé à gérer ce problème. Facebook permet de transformer la page d'un membre décédé en mémorial, pour qu'elle reste toujours là, mais qu'on comprenne que la personne n'est plus. Il faut pour cela qu'un membre de la famille fasse une demande, avec quelques preuves (carte d'identité et certificat de décès par exemple). Il est aussi possible sur Facebook de faire la configuration de son compte post-mortem de manière pro active. C'est à dire qu'on définit ce qui doit arriver quand on meurt. Est-ce qu'on supprime le compte ? Est-ce qu'on en passe l'ownership à quelqu'un d'autre ? Et si oui, avec quels droits ?
La question est intéressante, car on ne souhaite pas forcément que notre vie privée de notre vivant devienne publique, même à notre famille ou nos amis, une fois mort. Notre historique de mails, nos comptes bancaires, nos messages privés, etc.
Certains services comme FB et Google permettent de prévoir un moyen de vérification de si vous êtes vivant, en vous envoyant un mail tous les 3 mois en vous demandant d'y répondre. Si vous n'y répondez pas, c'est sans doute que vous êtes mort... Sauf qu'il peut y avoir plein de raisons de ne pas pouvoir s'identifier sur Google pendant 3 mois: un voyage dans un pays sans Internet, une hospitalisation longue, un séjour un prison. Et on n'a pas envie de dire au monde que l'on est mort quand ce n'est pas le cas.
Du coup, plusieurs sociétés tentent de résoudre ce problème, comme Eter9 qui dit être en mesure de continuer à faire vivre vos comptes en ligne même après votre mort grâce à une IA qui a réussit à apprendre vos patterns de posts durant votre vie. On commence à toucher à des questions philosophiques: si une machine est en mesure de répliquer de manière invisible notre présence en ligne, sommes-nous réellement mort en ligne ?
D'autres sociétés comme SecureSafe permettent de stocker tous les mots de passe utile de notre vie numérique pour les passer à qui vous le souhaitez une fois mort. Perpetu quand à lui permet d'envoyer un message à des proches ou des réseaux sociaux une fois décédé. Mais toutes ces sociétés sont encore très jeunes, et il y a de fortes chances que ce soit elles qui meurent avant nous.
La question est très intéressante et me fait réfléchir sur le sujet. Je voudrais que mon décès soit quelque chose d'assez simple à gérer par mes proches, mais en même temps je ne me vois pas donner mes mots de passe d'accès à mes services personnels à quiconque, pas même à un coffre-fort numérique. Il va me falloir penser à une solution à ça !
La veille techno pour les vieux croutons
Thibault Jouannic nous a parlé, dans une conférence très drôle, de la veille technologique. Le sujet m'intéressait énormément, surtout sur la manière de continuer à faire de la veille dans le temps dans un milieu qui évolue aussi rapidement que le notre.
On voit souvent des directeurs techniques qui étaient sans doute très bons à l'époque où ils ont été nommés à ce poste, mais qui ne se sont pas tenus à jour depuis et qui sont simplement dépassés aujourd'hui. Le monde du développement web évolue extrêmement rapidement. J'ai même l'impression qu'il évolue aujourd'hui encore plus vite que quand j'ai commencé, mais c'est peut-être simplement moi qui vieillit, ou qui m'intéresse à plus de choses.
Pour rester à jour, il faut apprendre à changer, ne pas avoir peur d'apprendre de nouveaux outils, de changer ses habitudes ou ses méthodologies. Parfois, cela nous fait culpabiliser parce qu'on voit des tas de gens plus doués que nous, qui donnent des conférences sur des sujets à la pointe comme si ça paraissait naturel (oui, je pense à toi Christophe.
La clé numéro une à une bonne veille technologique durable dans le temps c'est de commencer par ne pas avoir honte de ne pas tout connaitre. Certes, au début quand une nouvelle techno sortait, on avait envie de la tester tout de suite le soir ou le week-end et cela nous amusait. Aujourd'hui avec un nouveau framework JS par semaine et un nouveau task runner tous les mois, c'est difficile de rester enthousiaste à l'idée de tout apprendre à chaque fois.
Si on commence à se forcer dans cet état d'esprit, on fini par en être dégouté et la veille techno devient une corvée, chronophage et pénible. Pour éviter de tomber dans ce travers, il suffit de moins culpabiliser. Inutile de tout apprendre, on peut filtrer ce qui est nécessaire, laisser quelques mois à une techno pour savoir si elle vaut le coup qu'on s'y investisse, discuter avec d'autres personnes qui l'ont utilisée réellement sur des projets, prendre des feedbacks et en discuter.
Inutile de continuer à faire des side projects tous les soirs et week-ends, ce ne sont pas des conditions réelles de vrai projet qu'on mènera à bien. Il peut être plus intéressant simplement de discuter avec d'autres personnes pour savoir quel framework est utile dans quel contexte.
Good Robot, Bad Robot
François Hodierne, qui bosse à EyeEm à Berlin nous a ensuite parlé des robots (ceux qui viennent faire des hits sur vos sites de manière automatique). Il existe en ce sens plusieurs types de robots.
On a les bons robots, ceux de Google, Yahoo et compagnie qui scannent votre site pour l'indexer. Idem, on a Twitter qui vient chopper un aperçu de la page quand on partage un lien, ou encore les lecteurs de flux RSS, Pingdom, Pocket, etc. Tout ces services ont besoin de venir faire des hits sur votre serveur, et vous avez besoin de ces services, donc vous devez les laisser passer.
Coté Bad Robots, on a tous les robots qui cherchent à poster des commentaires de spam, de bruteforcer l'entrée à votre interface d'admin, de scrapper vos pages pour les afficher ailleurs ou encore de scanner les vulnérabilités de la version de votre CMS. On a aussi un gros nombre de bots d'arnaque à la publicité, de robots qui viennent scanner vos pages pour simuler des affichages de publicité.
Après, on a des robots bizarres. On ne sait pas trop ce qu'ils font là. Ils n'ont pas de User-Agent, ou des valeurs étranges (comme "Library foo v0.12"), des robots qui semblent être des bots de Google, mais qui indexent toujours les mêmes pages. Certains sont des restes de scripts buggués, ou oubliés.
D'après le speaker, la proportion de hits sur un serveur est entre 60 et 80% d'origine automatique, ce qui me semble énorme. L'avantage c'est que les bons robots suivent les robots.txt, les metatags et les sitemaps. Les autres font un peu n'importe quoi.
Histoire de les trier facilement, on peut regarder son IP et tester l'IP avec des API qui existent pour voir si elle est déjà enregistrée sur Spamhaus, ou sur le Project Honey Pot. Il existe des listes blanches officielles des IP des Google bots par exemple.
Il semble aussi possible de checker la cohérence des headers entre eux, vérifier que telle version de browser envoie bien, (avec les bonnes virgules au bon endroit) les bons headers, et si non considérer que c'est suspicieux.
Content Security Policy
Troisième mini conférence de la matinée, cette fois-ci Nicolas Hoffman nous parle des CSP, Content Security Policy qui permettent au serveur d'envoyer des directives dans les headers, indiquant au browser ce qu'il a le droit de charger et depuis où.
Ça fonctionne selon un principe de whitelist, où, pour les scripts et les CSS on indique la liste exhaustive des serveurs source autorisés (il est possible d'utiliser des wildcards). Selon les types il est aussi possible d'autoriser certaines notations ou pas. Par exemple interdire les styles inline en CSS ou les onclick en JavaScript.
Ce sont en fait tous les vecteurs qui peuvent être utilisés pour trouver des failles de sécurité, que le serveur envoie au browser pour lui dire de les bloquer. Si jamais le browser les trouve, il bloque complètement le téléchargement ou l'exécution. Cela permet d'avoir un genre de linter hardcore qui bloque complètement si jamais les règles ne sont pas suivies.
Les erreurs sont affichées dans la console, mais il est aussi possible d'indiquer une url sur le serveur vers laquelle elles peuvent être envoyées. Il est aussi possible de l'activer en mode report only, où rien n'est bloqué mais où les erreurs sont encore envoyées.
ES6
Matthieu Lux, alias @Swiip, nous parle de ES6 en nous expliquant les nouveautés de cette nouvelle version, et surtout qu'on peut commencer à l'utiliser dès maintenant grâce à Babel (anciennement 6to5, un extraordinaire outil d'à peine 1 an).
Tout d'abord, on oublie les var en ES6. On a à la place les const, qui sont des var en read-only (et on se rends compte en les utilisant qu'on a vraiment rarement besoin de modifier la valeur d'une variable). Mais aussi les let, qui sont comme des var, mais scopées au block (if, for, ...) au lieu de n'être scopée qu'à la fonction.
Niveau strings, on a maintenant le backtick comme délimiteur, qui permet de faire du multiline et de l'interpolation de variable avec la syntaxe ${foo}. C'est tout con, mais ça va nous éviter de rajouter des + partout tout le temps pour faire du multiline et ajouter des variables dans nos textes.
Tout ça c'est surtout du sucre syntaxique, et dans le même genre on a aussi les keyword class et extends qui font leur entrée et permettent de définir des classes de manière nettement plus lisible. En terme de feature, ça n'apporte rien aux classes qu'on utilisait déjà, mais ça nous évite de devoir définir une fonction pour ensuite modifier son prototype.
Hérité de CoffeeScript on récupère aussi les fat arrows (=>) qui permettent de simplifier l'écriture d'un fonction tout en gardant le scope de this dans l'affaire. Plus besoin de mettre des .bind(this) partout.
On attaque ensuite les features un peu plus poussées et aussi beaucoup plus utiles, comme import et export. ES6 fournit un moyen natif de faire des exports depuis ses modules. Autre sucre syntaxique déjà bien connu des rubyistes, on peut définir plusieurs retours et les attribuer en une seule fois:
let[a,b]=[1,2];// a === 1; b === 2let{user:x}={user:3}// x === 3
On a aussi l'arrivée des générateurs, qui sont des fonctions définies avec un * à la fin, dont l'exécution peut être stoppée avec yield, puis reprise avec next. Il est même possible de passer une valeur à next pour reprendre l'exécution avec de nouvelles entrées. La structure étant encore jeune dans ma tête, les cas d'usages ne me sautent pas encore bien aux yeux mais cela semble quand même très puisant, surtout cumulé à des promesses pour pouvoir écrire de manière linéaire un ensemble de calls asynchrones.
Vendez votre méthodologie
Retour dans le grand amphi ensuite où j'ai assisté à une présentation d'un designer. Même si nous n'avons pas le même cœur de métier, les propos étaient néanmoins intéressants et tout à fait applicables à d'autres professions.
Celui-ci nous explique que même si on fait du très bon travail, il arrive que notre client ne soit pas satisfait, qu'il ait l'impression qu'on ne se soit pas foulé et qu'on lui demande beaucoup d'argent pour pas grand chose.
Là dessus, il insiste sur le fait que nous ne vendons pas une réalisation finale, mais surtout une méthodologie qui nous amène à ce résultat. Par définition notre client ne connait pas notre métier (s'il le connaissait, il le ferait lui-même et ne ferait pas appel à nous), nous nous devons donc d'être pédagogue et de lui expliquer ce que nous faisons.
Dans beaucoup d'industries, la formule de fabrication du produit fini est cachée (Nutella, Coca-Cola), alors que dans notre métier, nous nous devons de montrer comment les choses fonctionnent. La curiosité de savoir comment les choses sont fabriquées est quasi-universelle, on aime tous regarder les making-of, presque plus que regarder l'œuvre elle-même. Nous avons envie de savoir quels ont été les obstacles, les solutions, les moments forts de la création. Et c'est cela que nous nous devons de retranscrire à nos clients.
Si nous ne le faisons pas, nous risquons de nous heurter à des jugements purement subjectifs du type j'aime bien, j'aime pas (sans doute beaucoup plus vrai en design qu'en dev), alors qu'en leur donnant des clés pour comprendre le parcours qui nous a amené à notre objectif, à la fois nous les éduquons, et nous les faisons jouer selon nos règles.
Les clients aiment être guidés, mais ils aiment aussi savoir qu'ils en ont pour leur argent. Instinctivement ils préfèreront quelque chose qui leur semble avoir demandé plus de travail que quelque chose qui leur semble trop simple. Un design rempli d'effets photoshop (glossy, lens flare, etc) pourrait sembler à ces yeux non avertis comme quelque chose de riche, alors qu'un design sombre et épuré, ne gardant que l'essentiel leur semblera bâclé. Il est donc important de leur montrer à quel point le travail de simplification est loin d'être facile, mais surtout qu'il va dans le sens de leur demande.
Si nous parvenons à être assez pédagogue le client ressortira en ayant appris un morceau de notre métier. À nous d'aller à son rythme, en lui expliquant ce qu'il ne comprends pas, en lui montrant les différentes étapes. Il appréciera d'autant plus le résultat final s'il voit les différentes étapes de conception et qu'il s'approprie les contraintes et les solutions trouvées.
Nous ne sommes pas des magiciens, qui faisons des choses extraordinaires sans expliquer comment. Nous faisons des choses qui semblent simple, en expliquant à quel point cela est complexe.
Le designer qui murmurait à l'oreille des ordinateurs
Il a montré certaines des commandes de base (cd, pwd, ls, rm), mais en mettant surtout l'accent sur le plus haut degré de configuration que permet l'édition de fichiers textes que les GUI. Il a aussi précisé que certaines taches sont bien plus rapides en ligne de commande qu'avec un GUI (le téléchargement de gros fichiers avec wget ou le déploiement avec ssh par exemple).
J'étais clairement pas la cible de ce talk, mais je me disais que je pourrais peut-être comprendre ce qui faisait peur aux designers dans la ligne de commande. J'en sors pas avec beaucoup plus d'arguments qu'avant (mais en même temps, je ne cherchais pas à convaincre des designers de passer à la ligne de commande).
Découper son application, pourquoi, comment?
On a ensuite eu un REX de Blablacar dans leur passage d'une appli monolithique à un ensemble de microservices. Les REX, c'est toujours intéressant.
Benjamin et Olivier, l'un dev et l'autre ops nous racontent ça vu depuis l'intérieur. Ils sont passés d'une grosse appli Symfony (qui est déjà la v3) en mode spaghetti (400.000 LOC, 30.000 commits) à un ensemble de microservices.
Enfin, pas vraiment en fait, ils sont en train de le faire. Ils ont réussi à développer l'une des nouvelles features (les avis), dans un service à part, avec une équipe pluri-disciplinaire dédiée. Celle-ci travaille à la fois avec l'ancienne codebase et la nouvelle (ce qui évite que des gens se sentent "punis" en travaillant sur le legacy alors que d'autres s'amusent avec un environnement neuf).
Ils ne crachent pas sur le monolithique pour autant, celui-ci à ses avantages. Notamment parce qu'on est obligé de passer par là quand on débute. Il n'y a aucun intéret à tout découper en petits services quand la société démarre, vu qu'on ne sait pas encore où on va, tout découpage que l'on fera sera sans doute très mal découpé. Une seule appli est aussi plus facile à comprendre pour un nouveau membre de l'équipe, et plus simple à déployer.
Néanmoins, une grosse codebase créé aussi des conflits git incessants, des MEP longues (et par conséquent des hotfix longs à déployer). La maintenabilité est mauvaise et ne fait qu'empirer avec le temps. Le code mort prolifère, mais est virtuellement indétectable (les effets de bord d'une simple ligne de code dans une feature à un extrême peut avoir des implications sur une feature de l'autre coté, sans que cela soit détectable). Au final, coté équipe, on se retrouve aussi avec des gens qui touchent à toutes les features, mais sans qu'il n'y ait réellement d'expert sur quelque chose.
Avec leur passage à l'international récent, le passage à des microservices est devenu une question capitale pour Blablacar. Pouvoir déployer des bouts d'appli séparément et donc réduire les temps de MEP était un de leurs objectifs. Pour les équipes, le fonctionnement en micro-startup leur permet de posséder un ownership de la partie où ils travaillent. L'isolation de leur service les rends aussi maitre des choix techniques et leur permet de changer le système de stockage (d'un système de DB vers un autre par exemple), sans impacter le reste du système.
D'un point de vu ops, cela nécessite plus de travail. Chaque micro service pouvant être développé avec une stack différente, cela nécessite de faire communiquer des pièces hétérogènes ensemble et donc un plus grand temps de bootstrap pour chaque projet. Néanmoins, au final le gain est grand pour les ops aussi, qui, si jamais quelque chose tourne mal, peuvent identifier facilement, sans avoir besoin de devs, quelle partie est en feu.
En REX final, ils nous indiquent que ce passage était nécessaire pour eux, et semble nécessaire pour tout système à partir d'un moment, mais que cela ne va pas régler tous les problèmes. C'est un choix qui doit être réfléchi, et qui ne se fait pas du jour au lendemain.
Design de soi
J'ai ensuite enchainé avec une conférence beaucoup moins technique, mais beaucoup plus personnelle, sur le design de soi, ou comment valoriser son identité sur le net. La salle était pleine, plusieurs personnes ont même du quitter la salle faute de place. À en croire le tonnerre d'applaudissement au démarrage, il semblait que Marie Guillaumet, la speakeuse, était déjà bien connue d'une partie de la salle.
Du coup, elle nous a partagé des conseils pour gérer son image personnelle en ligne. La limite est floue entre entre personnal branding et le personnal branling. L'idée du talk est d'appuyer sur le fait que nous possédons tous une identité en ligne, professionnelle et personnelle, mais nous n'en sommes pas forcément conscient, et ne la maitrisons pas forcément correctement. Le talk était essentiellement tourné vers notre identité pro ici, sur la manière de nous valoriser sans en faire trop.
L'idée principale est que je dois partager qui je suis, ce que je fais, sans chercher à me faire mousser. Je pense que la conférence eu un certain écho avec ses spectateurs car j'ai vu beaucoup plus de résumés de ParisWeb sur Twitter que les autres années, ce dont je suis très content. Tout ce que l'on poste individuellement sur le net et qu'on partage fait partie de notre présence en ligne et nous définit. Cela doit être fait sans arrière-pensée d'auto promotion, mais il est important d'en avoir conscience afin de pouvoir s'en servir comme d'un atout professionnel (ce qui est particulièrement important pour les free-lances).
Je me permets une digression par rapport au message de Marie. Je suis complètement raccord avec elle sur le fait que l'image que nous renvoyons (en ligne et hors ligne) possède un impact réel et très important sur notre vie professionnelle. C'est d'autant plus vrai quand on exerce en tant que freelance, mais aussi pour des postes de salariés plus classique (et se ressent alors fortement quand on cherche un nouveau poste). Écrire des articles de blog sur un sujet qui nous passionne fait ressortir notre coté humain, qui peut parfois être masqué sous la pile de retweet technique que l'on poste. Il ne faut pas avoir peur d'évoquer ses idées, coup de cœurs et coups de gueule, même si tout le monde ne sera pas d'accord avec nous (ce qui est de toutes façons impossible). Au pire on se ferme des contacts avec des gens gênés par nos propos, mais nous n'aurions pas aimé travailler avec eux de toutes façons. Au mieux on se fait contacter par des gens qui partagent nos valeurs, ce qui est un vrai bonheur.
Bref, revenons au propos de la conférence, et aux freins psychologiques que l'ont peut avoir. À ce propos, je vous renvoie à la conférence de Kyan et Navo qui soulève à peu près les mêmes points.
Le frein principal qui nous empêche de prendre la parole (par écrit ou par oral), et que l'on se dit que plein d'autre personnes pourrait le faire mieux que nous. On se dit que l'on n'est pas assez expert, que ce que l'on va dire à déjà été dit ou n'est pas intéressant, bref, on est frappé du syndrome de l'imposteur. Et bien cela se soigne, il vous suffit de savoir que vous êtes légitime, que vous avez quelque chose à dire. Quelque soit votre degré d'expertise, ce que vous avez à dire est important car il est unique et il vous est personnel. Et les histoires personnelles sont importantes à partager, elles ont beaucoup plus de portée que de simples articles techniques.
Il ne faut pas non plus avoir peur de s'exprimer à titre personnel, on n'en devient pas plus vulnérable pour autant, au contraire, on en devient plus facile d'accès. En partageant vos idées personnelles, comme je le disais plus haut, vous aller toucher vos lecteurs sur le plan personnel. Tout le monde ne sera peut-être pas d'accord, mais cela n'a pas d'importance, et n'ayez pas peur d'être jugé, c'est très libérateur de pouvoir parler sans crainte. Par contre, quelque chose de très important est d'être le même sur le web et dans la vie. Si vous vous créez un personnage sur le web, il sera très rapidement mis à nu pour ce qu'il est vraiment lors de rencontres réelles. À l'inverse, si vous avez des choses passionnantes à partager de visu, partagez-les aussi en ligne.
Si vous ne savez pas sur quel sujet poster, dites-vous que tout le monde a besoin de contenu original et intéressant. Un retour d'expérience, un partage de connaissance, un making of d'une de vos réalisations, la liste de vos influences, tout ça c'est personnel et donc par définition c'est original. Allez y, partagez. Parlez du travail des autres, faites des CR des meetups et conférences où vous allez, faites un bilan des projets que vous venez de terminer, contribuer à des projets open-source.
Si vous ne savez pas quel ton adopter, faites comme si vous écriviez pour votre meilleur ami, ne vous mettez pas de barrière sur le style, le fond est plus important que la forme. Dans le doute, dites-vous que la personne qui vous lira ne connait rien au sujet, donc n'hésitez pas à détailler les éléments qui peuvent sembler complexes.
Une remarque qui semble évidente, c'est que vous ne risquez pas de dévaloriser votre travail en en parlant, au contraire. Vous n'êtes pas fait d'une sorte de "potion magique" qui vous donne vos pouvoirs, et vous ne risquez pas de perdre ces pouvoirs en partageant la recette de la potion magique. Au contraire, à écrire sur ce que vous savez vous consoliderez vos connaissances, vous irez plus loin mais surtout vous les partagerez. La connaissance ne vaut rien si elle n'est pas partagée.
N'en faites pas trop non plus. Soyez vous-même, ne vous forcez pas à faire ou dire des choses qui ne vous ressemblent pas, mais vous n'êtes pas non plus obligé de partager toute votre intimité. Les détails de votre vie privée n'ont sans doute pas leur place sur votre timeline Twitter professionnelle, vos peines de cœur et vos coups de gueule dans les embouteillages n'apportent rien. Levez aussi la pédale sur les retweets de compliments, sur le name dropping et l'auto congratulation.
Finalement, un point sur la forme qui peut vous permettre de regrouper l'ensemble de vos comptes en ligne sous une même identité c'est d'utiliser une couleur qui vous est spécifique et en tartiner toutes vos pages de profils. Utiliser un favicon représentatif et utiliser la même photo de profil partout. Tout ce qui permet de faire le lien entre toutes vos identités pour vous identifier comme une seule et même personne (ou au contraire pour faire la séparation entre votre avatar professionnel et votre avatar privé) est bon à prendre.
Finalement, si vous êtes convaincu mais pensez que vous n'avez pas le temps de faire tout ça, pas de panique. Vous n'avez pas besoin de tout faire d'un coup, la démarche est progressive. Faites petit à petit, rien ne presse. Mais surtout, n'ayez pas honte de ne pas tout faire. Si vous n'avez pas de compétence en développement, prenez un Wordpress tout fait. Si vous n'avez pas de compétences en design, prenez un thème tout fait.
C'est ce genre de conférence que j'aime à ParisWeb, j'en ressors avec un boost de motivation et une grande liste de choses à faire, que j'ai envie de faire.
CozyCloud
La dernière conférence officielle de la journée (on enchainera sur une conférence surprise sur la LSF juste après) était présentée par Tristan Nitot, ex-Mozilla.
Tristan nous fait un état des lieux du net depuis ses début. Il parle du net comme d'un pharmakon, quelque chose qui peut être aussi bien un poison qu'un médicament, selon les doses et selon les cibles. Il nous parle de la mort de Netscape et de l'émergence des standards pour éviter que le web ne stagne, entre les mains de quelques monopoles.
Il nous rappelle qu'aujourd'hui en 2015 le web est complètement différent de ce que l'on aurait pu imaginer. Tout le monde possède un smartphone, les GAFAs sont les mastodontes du réseau, des tas de sites fonctionnent selon un système de SaaS gratuit pour les utilisateurs.
Le grand public englobe ça sous le nom de cloud, mais il est vrai que dans les fait, c'est du SaaS. Rien à installer, le site web fonctionne comme une appli, qui peut être mise à jour pour tout le monde en même temps, et la plupart du temps les utilisateurs n'ont même pas un centime à débourser (Facebook, Gmail, etc).
Sauf que les clients, ce n'est pas nous. Tout comme les cochons dans un abattoir ne sont pas les clients. Ils ont beau avoir un toit sur la tête et être bien nourris, tout cela au final n'est pas construit pour eux. Les vrais clients sont en bout de chaine et eux ne sont que la matière première. Aujourd'hui, nous ne sommes pas les clients, nous sommes (ou plutôt les données que nous produisons), le véritable pétrole du XXIe siècle.
Ces données sont ensuite revendues, essentiellement à des régies publicitaires, mais tout simplement à quiconque souhaite les acheter (et qui possède les fonds suffisants). Mais d'autres organismes sont aussi intéressés par ces informations, comme les révélations Snowden nous l'ont bien montré, des états entiers cherchent à obtenir ces informations. S'ils ne peuvent les obtenir par des moyens légaux, le fait que ces données soient centralisées chez quelques acteurs principaux rends leur espionnage et leur siphonnage plus facile.
On peut répondre qu'on s'en moque, car on n'a rien à cacher. C'est peut-être vrai en temps qu'individu, mais en tant qu'organisation commerciale vous avez sans doute des choses à cacher, des choses que vous n'aimeriez pas voir rendues visibles par vos concurrents. Et même en temps qu'individu, même si vous ne faites rien d'illégal, vous avez quand même sans doute des choses que vous ne souhaiteriez pas rendre publiques. Tristan donne l'exemple du verrou qu'il ferme dans ses toilettes, non pas qu'il fasse quelque chose d'illégal ou de répréhensible dans ses toilettes, mais simplement qu'il y fait quelque chose de privé.
Il donne ensuite l'exemple de sa douche, sous laquelle il chante (mal) tous les matins. Mais il sait aussi qu'il arrête de chanter sitôt qu'il sait que sa femme est rentrée à la maison. Par honte ou par peur on ne sait pas, mais il ne souhaite pas que sa femme l'entende chanter (mal), alors il se tait. Ce simple exemple montre qu'un individu qui se sait épié modifie son comportement (même si cet exemple n'a rien de très scientifique, je pense que vous en voyez le sens).
Pour lutter contre tout ça, Tristan propose quelques règles à suivre. Déjà, se débarrasser du mythe qui voudrait que la publicité soit un mal nécessaire. La publicité nous donne la sensation d'obtenir un service gratuitement. Vu qu'on donne une grosse partie de nos données en échange, ce n'est déjà clairement pas gratuit. Ensuite, il nous faudrait nous reposer sur du matériel que nous possédons, plutôt que d'utiliser un système distant contrôlé par un autre organisme. Il est possible de faire des serveurs peu consommateurs et assez puissants pour 35€ avec un Raspberry Pi aujourd'hui.
Sur ces machines, on y mets évidemment du logiciel libre plutôt que des softs fermés. On chiffre nos échanges de manière a rendre illisible pour toute source extérieur le contenu de nos échanges. Pour ça, il semblerait que Let's Encrypt soit une solution intéressante. On utilise des standards pour rendre tout ça interopérable, et on saupoudre le tout d'une UI simple qui ne laisse personne dehors.
Jusqu'ici, je suis à fond avec Tristan, ses arguments me paraissent solides, je pense que je les réutiliserait. Je suis son chemin de pensée et j'attends avec impatience sa solution.
Et là, c'est le drame.
La présentation tourne à la présentation commerciale pour Cozy, la nouvelle boite de Tristan. Cozy par-ci, Cozy par-là, même quand il n'y a aucun rapport avec le sujet. Si encore Cozy résolvait les problèmes soulevés avant pourquoi pas, mais là, même pas.
En quelques mots, Cozy est un système open-source qui permet de synchroniser toutes ses données au même endroit, sur un device qu'on contrôle, afin d'en rester maitre. Sauf que, à part créer un nouveau silo qui amalgame encore plus de données de plusieurs sources, je vois pas trop ce que ça change avec la situation actuelle. Certes, je peux le stocker chez moi sur mes devices, mais Tristan mettait quand même en avant que Cozy fournissait "gratuitement" l'hébergement sur leurs serveurs. Donc à part un nouveau silo à aller siphonner, je vois vraiment pas ce que ça apporte.
Plus ça allait plus le discours était commercial et complètement orthogonal avec les valeurs énoncées au démarrage. On liste toutes les features de Cozy, on nous montre que le design est responsive (bravo) mais on oublie complètement le sujet de fond. On nous montre que Cozy récupère les mails depuis Gmail, les contacts de notre téléphone et nos données bancaires.
Mais l'apothéose c'était quand même l'exemple de la facture détaillée de SFR, où Tristan nous dit qu'avec Cozy il serait possible de lier les numéros de téléphone de la facture avec notre liste de contact pour savoir quels sont les destinataires qui nous coutent le plus cher. Sérieux ? À croire que posséder de la donnée corrompt tout le monde. Ce n'est pas parce que l'on peut croiser toutes les données que l'on possède qu'on doit le faire. À commencer comme ça on cherche à obtenir encore plus de data pour faire encore plus de liaisons, exactement comme les GAFAs contre qui on luttait au début de la présentation.
Parce que faut pas oublier que dans ces exemples, le Cozy ne contient qu'une copie des données qui ont été récupérées chez notre banque, chez Google ou chez SFR. On a juste ajouté un nouveau nœud qui possède une nouvelle copie des données, tout bien rangé au même endroit, et tout bien lié.
Il nous incite à essayer Cozy, qui est gratuit, en nous disant "Allez-y, mettez-y plein de données, pour qu'on améliore nos systèmes. Bien sur on ne regarde pas la data hein, c'est juste pour qu'on s'améliore". Après tout le speech qu'il a donné avant, comment peut on avoir envie d'essayer Cozy ?
Dans la session de questions/réponses qui a suivi, il a même dit qu'il espérait que des sociétés fassent des applications pour Cozy, en donnant l'exemple de EDF qui pourrait "faire une appli Cozy qui, en échange de vos données, vous donne 2 mois gratuits". Sérieux, je ne vois absolument pas la différence avec le modèle des GAFAs actuel.
Au final, soit j'ai vraiment rien compris, soit le discours était vraiment pas rodé. Je n'ai pas été le seul à avoir trouvé cette présentation bien trop commerciale (même les talks sponsorisés étaient moins commerciaux).
LSF
Bon, on a quand même pu finir la conférence sur une note plus gaie, avec l'une des meilleures conférences de cette session. Pour ceux qui ne sont jamais venus à ParisWeb, il faut savoir que toutes les conférences sont traduites en Langue des Signes Française en live par une interprète, sur scène. Le grand amphi a aussi le droit à une retranscription textuelle en vélotypie.
Cette année on a donc eu le droit à une présentation de l'une des interprètes LSF pour nous en apprendre plus sur cette langue. Oui, car on dit langue des signes et pas langage des signes. Et oui, ce sont des signes et pas ni des gestes ni des mimes.
La LSF n'est pas une langue internationale, même si la grammaire de base est la même il y a des différences culturelles entre différents pays. Certains pays ont même plusieurs langues des signes officielles, et différents pays francophones n'utilisent pas la même langue des signes non plus.
On se pose souvent la question de mais comment diable font-elles pour réussir à traduire ce speaker qui parle super vite, avec des termes techniques ?. La réponse est ben, elles y arrivent pas. Elles se renseignent avant l'évènement sur le sujet des conférences pour savoir un peu de quoi on va parler et de quels mots barbares vont être utilisés, mais tous n'ont pas encore de transcription en LSF, du coup il faut parfois faire des périphrases. Et quand le speaker enchaine les acronymes, avec un débit continu, c'est bien difficile de réussir à tout attraper. Encore pire quand ils y casent des blagues !
Le métier d'interprète est difficile et il y a 4 écoles en France qui peuvent y former. Là bas on y apprends, outre les signes eux-mêmes, à faire une gymnastique du cerveau particulière pour être en mesure d'entendre, de comprendre, d'analyser, de se représenter et de signer ce que vient de dire l'orateur, tout en faisant la même chose pour la phrase suivante, le tout sans jamais s'arrêter. On dit que les femmes sont généralement plus douées pour faire plusieurs choses en même temps et c'est vrai que je n'ai vu que des femmes interprètes LSF cette année (il me semble qu'il y avait un homme il y a deux ans).
Elles font normalement des shifts de 15mn sur scène, mais le débit à ParisWeb était tellement rapide et les mots tellement complexes qu'elles réduisent à 10mn pour pouvoir tenir les deux jours. D'ailleurs, dans le monde des interprètes en France, il y a celles qui ont fait ParisWeb et celles qui ne l'ont pas fait. Certaines adorent et veulent revenir tous les ans (pour l'ambiance, pour l'accueil) et d'autres trouvent cela trop dur et on ne les revoit jamais.
Au final, un grand grand merci pour nous avoir fait partager ce métier que nous côtoyons chaque année pendant deux jours sans se douter de tout ce qu'il implique réellement derrière. C'était très agréable et très instructif de nous avoir montré l'envers du décor.
Ateliers
J'ai continué le lendemain sur les ateliers, très intéressants aussi, remplis de discussions passionnantes sur ES6, sur l'avenir de notre métier (et sur notre vie après la mort) et où j'ai fait de jolis petits dessins. Je n'ai pas de résumé détaillé à écrire cette fois-ci par contre.
Conclusion
Même si la première journée m'avait laissé sur ma faim, les deux suivantes m'ont reboosté. ParisWeb c'est quand même un moment magique entouré de passionnés, dans une ambiance bienveillante de partage. Quand je me suis levé dimanche matin j'étais déçu de ne pas commencer une nouvelle journée de ParisWeb.
Le futur de ParisWeb est incertain par contre, une grande partie du staff quitte le navire après cette 10e année et une nouvelle génération va devoir se lever pour faire durer l'aventure. Demain soir a lieu un AperoWeb où on discutera de tout cela, et j'irai y faire un tour. J'aimerai aider à ce que ParisWeb continue, mais je ne suis pas certain d'avoir le temps nécessaire pour cela. On verra demain.
Aujourd'hui, je reviens du premier jour des conférences ParisWeb 2015, qui avaient lieu au Beffroi de Montrouge. ParisWeb c'est 3 jours de conférences, j'y vais presque tous les ans et je me suis rendu compte que même si j'avais pris des notes à la session de l'année dernière, je n'avais jamais pris le temps de remettre mes notes au propre pour poster sur ce blog.
Pour éviter que cela se reproduise cette année, j'ai décidé d'écrire mon résumé dès la fin de la journée. C'est à chaud, pas forcément bien construit, mais le voici:
Internet et libertés: pour un engagement des acteurs du numérique
La conférence d'ouverture commence directement par la Quadrature du Net, représentée par Adrienne Charmet. Adrienne nous rappelle que même si notre métier est de travailler dans le milieu du web, une grosse partie de notre vie privée se passe aussi sur le Web. Et même si on pouvait encore croire il y a quelques années qu'on pouvait faire du Web sans s'intéresser à la politique qui tourne autour, ce n'est aujourd'hui plus possible.
Il semble que le monde politique ne comprenne pas le milieu qu'il tente de légiférer, il essaie de calquer des modèles qui marchaient ailleurs sur le modèle international décentralisé qu'est le net. Les aberrations que sont les lois et leur absurdité nous saute au yeux (quand on nous dit qu'on va utiliser une adresse IP pour identifier une personne... Ça nous parait tellement gros et stupide et débile et absurde qu'on ne relève pas, et pourtant...), mais des lois, qui vont réellement influer sur notre existence et celle de nos enfants sont fondées sur ces incompréhensions.
Adrienne nous fait donc un rapide récapitulatif des 4 grosses lois qui touchent au numérique de l'histoire de France récente. Elle appuie sur le fait que nous sommes encore assez gentils aujourd'hui, à nous élever publiquement sur nos sites persos en changeant le fond en noir où en écrivant à quel point nous ne sommes pas d'accord avec ces projets de loi (ce qui est déjà pas mal), mais que nous pouvons aller plus loin.
Si on passe rapidement sur les 4 lois en question on a d'abord la Loi Renseignement, qui à la suite des évènements de Charlie Hebdo, légalise et élargit les pratiques des agences de renseignement. Ces pratiques vont bien trop loin, et il n'est pas possible d'accepter tout et n'importe quoi sous prétexte de lutte contre le terrorisme. Même si la loi est passée, elle est passée en douleur, et ce qui était présenté comme une loi de sécurité, est finalement devenue une loi de liberté publique.
Là encore, la vision du développeur que je suis, quand on me parle de surveillance de masse de la population, on a beau me dire que la surveillance sera effectuée en masse, sans ciblage, et uniquement sur les metadatas, au lieu de me rassurer ça m'inquiète encore plus. Il suffit qu'on dise "metadata" et "algorithme" à un politique et tout à coup ça parait moins dangereux. Que la surveillance soit effectuée par une machine codée par un humain ou par un humain directement, la seule différence c'est la puissance de calcul, qui est des ordres de grandeur plus importante par la machine.
L'argument évident du "si j'ai rien à me reprocher ça ne me pose pas de problème" m'énerve toujours autant. Déjà le simple fait de savoir que tu es surveillé va te faire agir différemment. Ce n'est pas parce que tu n'as rien à te reprocher que tu souhaites étaler ta vie privée, celle de ta femme et celle de tes enfants à n'importe qui. Et toutes les victimes des dictatures, elles non plus elles n'avaient rien à se reprocher, et pourtant c'était tellement plus facile quand on pouvait savoir ce qu'elles disaient à tout moment.
Bref, les arguments généralement évoqués pour faire changer les politique d'avis ont rarement à voir avec ces considérations humaines. Généralement on parle de profits perdus, de compétitivité du pays qui baisse, etc. On prends l'exemple des USA où les GAFA ont fait pression contre le gouvernement pour qu'il se rétracte de SOPA, arguant que si les citoyens savent qu'ils sont épiés, ils auront moins confiance, et que s'ils ont moins confiance ils achèteront moins. En France on argue que surveiller les communications va faire fuir les business qui se basent eux aussi sur la confiance. Ces arguments, aussi véridiques soient ils me dérangent toujours autant comme n'étant pas le vrai fond.
La prochaine bataille sera sans doute sur le chiffrement, qui est attaqué avec le sophisme idiot comme quoi le chiffrement est utilisé par les méchants, alors il faut interdire le chiffrement. Ça empêchera pas les bad guys d'utiliser du chiffrement, mais ça supprimera simplement l'anonymat.
On enchaine donc sur la neutralité du net, sur le principe fondamental de ne pas filtrer les paquets en fonction de leur type ou leur provenance. Envoyer du texte, des vidéos ou des mails fait appel aux même couches sous-jacentes, leur prix ne doit pas être différent. Et surtout, personne ne doit être en mesure de pouvoir payer plus cher pour avoir un accès privilégié.
S'ensuit le classique débat sur le modèle publicitaire en ligne. Celui qui dit que c'est mal de bloquer les publicités parce que c'est le seul moyen qu'ont les créateurs de site de gagner leur vie et qu'en faisant ainsi on les vole. Non, non et non. Je n'ai pas envie qu'un site vienne vomir sur mon écran ses publicités qui clignotent et font de la musique, m'empêchent de lire mon contenu, me piquent de la data sur mon forfait, ralentissent mes pages et vont sniffer mon parcours. Tout ça sans m'avoir à aucun moment demandé mon avis. Donc non, tes pubs tu te les mets où je pense et ne viens pas me faire la morale, merci.
C'est extrêmement intrusif, à la fois sur la partie visible de l'iceberg (une pub qui clignote et vient gêner ma lecture), mais aussi sur toute la partie qu'on ne voit pas et sur toutes les informations que le tracker récupère. La législation européenne qui demande qu'on prévienne quand un cookie est mis me fait bien rire quand on voit tout ce que les régies pubs enregistrent dans des formats bien plus difficile à supprimer que des cookies, sans qu'on ne leur demande rien.
BREF. Le but de la conférence d'Adrienne était de faire réagir, et là dessus je peux dire qu'elle a réussi, je pensais pas écrire autant sur le sujet. Elle nous incite à parler de ces sujets autour de nous, à notre famille, nos amis, nos collègues, poster des articles, montrer que c'est une préoccupation importante, pour que cela devienne une cause politique.
Dev front à mach 1 au quotidien
On continue avec une conférence ultra-rapide de Christophe Porteneuve (comme d'hab). C'était la suite du talk DevAvengers qu'il avait déjà fait à ParisJS, en version à peine updatée.
Je vous invite à lire le CR que j'avais fait sur le sujet car le fond est le même. Christophe nous incite à perdre le moins de temps possible, à profiter des outils qui sont là pour nous faciliter la vie.
À commencer par le browser, dans lequel on peut faire du live edit du CSS, JS et HTML et qui nous propose une completion dynamique de ce qui est chargé au runtime. Le tout marche même en mobile avec un simple câble USB. Ça marche même avec les fichiers minifiés/compilés du moment qu'on fournit les sourcemaps, et on peut même lier les fichiers chargés avec un workspace sur notre disque pour que les changements faits en live soient changés aussi sur disque. Bref, bonheur.
Les DevTools proposent des tas de fonctions comme ça qui ne sont pas forcément très connues, mais qu'on peut apprendre sur codeschool, youtube ou sur html5rocks. Il nous conseille aussi d'utiliser les DevTools dédiés à nos frameworks (React, Angular, Ember ou Redux.
Il nous montre ensuite BrowserSync qui utilise des websockets pour faire du hot-reload de CSS/JS/HTML et même de synchroniser browsers ensemble. Niveau build, lui qui chantait les louanges de Brunch il n'y a pas si longtemps s'est récemment converti à Webpack, cumulé à jspm. J'ai pas encore bien cerné ce que ces deux outils faisaient, il va falloir que je me penche dessus. Par dessus (ou à coté, en dessous, j'ai pas suivi) il propose de rajouter SystemJS qui permet de charger n'importe quel type de module (AMD, CommonJS, Global ou ES6) de manière compatible.
Les deux derniers slides sont allés très vite, j'ai pas eu le temps de tout noter, dommage c'était ceux qui m'intéressaient le plus. J'ai eu le temps de noter qu'il conseillait Chai, Sinon, Mocha pour les tests et BabelJS pour tester de l'ES6 dès maintenant. Ça tombe bien, c'est déjà ce que j'utilise.
CSS Grid Layout
On a ensuite enchainé sur une conférence technique sur le CSS Grid layout et sur cette spec qui n'est aujourd'hui accessible qu'en mode experimental dans Chrome. En quelques mots, l'idée est de pouvoir définir notre layout directement dans le CSS sans avoir besoin de gérer un markup à base de rows et de cols.
Ça va donc plus loin que les vieux float et leur hacks, les table (en HTML ou en CSS) ou même les flexbox. L'idée est de passer un display: grid à un parent, et ensuite tout un nouveau monde de grid-template-columns et grid-template-rows s'ouvre à nous sur les enfants.
La syntaxe est assez complexe et j'ai décroché de l'explication à plusieurs moments. C'est le genre de choses que j'ai envie de tester par moi-même plutôt que d'écouter en conférence. Tous les exemples qu'elle citait sont de toutes façons disponibles sur http://gridbyexample.com.
Au final j'en retiens qu'il y une toute nouvelle terminologie à apprendre pour ce système, mais qu'il permet de définir facilement un layout, même en RWD. Et il permet de définir combien de cells, en hauteur comme en largeur, chaque partie de notre layout doit prendre. On peut même positionner plusieurs cellules au même endroit et joueur sur leur ordre de stack avec zindex. On peut même faire de l'ASCII art pour dessiner notre layout, et une nouvelle unité de mesure, le fr, fait son apparition.
Ça semble extrêmement puissant, j'ai hâte que cela soit mieux supporté pour commencer à tester. C'est un grand pas dans la bonne direction. On s'affranchit des hacks de CSS pour avoir un vrai système de layouting, sans devoir noyer son markup sous un tas de classes pour gérer le RWD.
RGAA 3
Aurélien Levy de Temesis nous a ensuite fait un récapitulatif de ce que la norme RGAA 3 implique. Pour rappel, RGAA signifie Référentiel Général d'Accessibilité pour les Administrations.
N'ayant jamais du l'implémenter sur aucun site, les changement par rapport à la version précédente ne m'ont pas passionné.
OpenID Connect
François Petitit nous a ensuite parlé de FranceConnect et de son implémentation du protocole OpenID Connect. La présentation était très claire, mais on voit bien comment FranceConnect se place au centre d'une interaction où il est à la fois fournisseur d'identité et fournisseur de données.
L'exemple donné était le jeune parent qui souhaite faire une demande à la CAF pour son enfant. La CAF a besoin de son identité et de quelques infos supplémentaires pour faire les papiers. Deux organismes possèdent ces infos: les impôts ou AMELI. L'utilisateur peut choisir de s'identifier avec un de ces deux services, il rentre ses login/pass sur l'un ou l'autre et il est ensuite redirigé vers le site de la CAF avec tous les champs déjà remplis.
En arrière plan, FranceConnect s'est identifié auprès des impôts, a redirigé l'utilisateur, effectué un échange de tokens et récupéré les infos demandés. Ça parait super simple et j'ai hâte que cela arrive plus fortement dans nos administrations.
Webperf 2.0
En début d'aprem, Stéphane Rios de Fasterize nous a fait un état des lieux de la Webperf aujourd'hui. Je m'attendais à apprendre pas mal de choses et j'ai été plutôt déçu. Rien de bien neuf sous le soleil, surtout qu'on avait déjà eu une conférence sur le sujet l'année dernière qui disait à peu près la même chose.
Je sais bien que les bonnes pratiques Webperf ne changent pas tous les ans, et heureusement, mais je m'attendais à en ressortir avec plus d'éléments. On a commencé par voir pas mal de graphiques pour voir pourquoi la webperf c'était bien, puis on a attaqué les points pratiques.
J'ai pas été tout à fait d'accord avec tous les points soulevés d'ailleurs. Dire que la concaténation de CSS est contre-productive car il a un client qui a inliné l'ensemble de ses fonts en base64 dans un fichier, ou qui a atteint la limite des sélecteurs CSS de IE9, c'est se tromper de bataille. La concaténation de CSS est pour moi une bonne chose, à condition qu'on ne mette pas n'importe quoi dedans comme dans cet exemple.
J'ai pas réussi à suivre l'argument qu'il avait contre le lazyloading, comme quoi cela cassait le parseur HTML spéculatif, ni pourquoi mettre les js en bas de page ou minifier ses assets était inutile.
Ensuite on est parti sur quelques techniques de sioux pour charger des fonts en évitant le FOUT (à base de loadCSS), de mettre le CSS du critical path en inline dans le head ou encore de jouer avec les pre-fetch.
Un petit rappel rapide que HTTP2 ça va être mieux dans l'absolu, mais qu'on n'y est pas encore et que ça va casser toutes les bonnes pratiques qu'on connaissait (qui deviendront sans doute même contre-productives).
Point intéressant sur webp, qui est un format d'image supérieur à jpg, mais qui nécessite un lecteur spécial hors browser si les utilisateurs veulent sauvegarder l'image pour la voir plus tard. Coté compression, mozjpeg et lossygif sont toujours les meilleurs.
J'attendais peut-être un peu trop de cette conférence, mais je n'ai pas appris grand chose de neuf. Comme toujours il n'y a pas de silver bullet, plein de choses fonctionnent bien, mais même les bonnes pratiques les plus éprouvées méritent d'être testées en condition réelles sur chaque projet pour voir ce qui est vraiment pertinent.
Creating a culture of code quality
David West de Pinterest nous a ensuite parlé de code de qualité. Sortant d'un an et demi d'Octo, je suis assez familier avec le sujet. Là encore, je n'ai pas appris grand chose, si ce n'est des arguments intéressants pour convaincre d'autres personnes des bienfaits du code de qualité.
Tout d'abord sa définition de la qualité avec laquelle je suis tout à fait raccord:
Quality is pride of workmanship
Quand le code est de qualité, on lui fait confiance, et quand on fait confiance au code on peut le modifier facilement et le faire évoluer rapidement.
Chez Pinterest, ils ont des linters et des tests partout. Ils peuvent refactorer sans crainte et sont même allé plus loin en écrivant un script qui modifie automatiquement leur ancienne codebase en React, et en s'assurant que tout marche bien car les linters et les tests passent toujours!
Il nous a parlé de flow, qui est un type checker statique. Je ne connaissais pas et je vais me pencher là dessus, ça me semble très intéressant. Coté CSS il nous parle de csslint qui permet de checker les propriétés inconnues (souvent dues à des fautes de frappe), les sélecteur vides (sans doute du à un refacto), les propriétés connues pour causer des soucis de perf ou d'accessibilité ou tout simplement pour faire respecter les conventions.
Coté Javascript, ils utilisent eslint et Jest qui utilise le virtual DOM de React et qui du coup leur permet de faire des tests qui vont encore plus vite.
REX Styleguide
On a ensuite eu une présentation du chef de projet front de la refonte du site Relais & Chateaux sur l'importance du styleguide dans une équipe.
Ce document (sous forme HTML/CSS/JS) permet de partager au sein de l'équipe, et avec le client le langage visuel du projet. Il évolue dans le temps et sert à la fois de référentiel et de documentation.
Pour ce projet, ils ont suivi le principe de l'Atomic Design et le document présente donc les différents atomes, leurs groupements en molécules et des exemples d'organismes et de templates.
Il fournit des exemples de code HTML avec le rendu à coté ainsi qu'une liste exhaustive des couleurs et des fonts utilisées, avec un nom unique pour chacune et une représentation de celle-ci. Cela permet à toute l'équipe de parler le même langage.
Êtes-vous au top ?
Et la conférence WTF de ParisWeb, celle qui ne parle pas de Web mais qui en reste extrêmement intéressant quand même. Ici, Nattacha Hennocq d'Orange, nous explique comment rentrer dans un mode de pensée qui favorise la créativité.
On peut par exemple faire des side projects à coté, pour tester des choses nouvelles, mais bien souvent on ne termine pas les side projects commencés. On peut faire des choses plus simples chaque jour par contre, comme essayer d'écrire de la main gauche si on est droitier ou chercher à apprendre quelque chose de nouveau mentalement ou physiquement.
Cela peut être aussi simple que se forcer à se souvenir d'une réunion, qui a dit quoi. Ou compter les mots quand on lit, dessiner les réunions, bref faire des choses pas très compliquées mais qu'on ne fait pas, bien qu'elles soient à notre portée.
On peut se forcer à penser à des scénarios absurdes, écrire des listes de choses sur un sujet précis, faire une mind-map de n'importe quoi, se donner quelques minutes pour dessiner 30 symboles différents dans des cercles, cartographier un problème complexe qui ne comporte pas forcément de solution, mais juste se forcer à trouver des liens et des imbrications.
Beaucoup plus dur c'est faire attention à nos biais cognitifs, qui par définitions nous sont inconscients. Les deux plus flagrants sont celui qui nous fait penser que ce qui me ressemble est mieux, ou que les effets néfastes d'un changement surpassent ses effets positifs.
Ne pas hésiter à montrer son travail, à le partager, à en discuter. Avoir conscience de soi, de ce que l'on fait, de ce que l'on va faire, même dans les quelques secondes suivantes.
J'ai bien aimé l'idée et le coté décalé du reste des autres conférences de la journée.
Hybride
La dernière conférence de la journée a été une des très bonnes surprises. Un bon overview de ce qu'est le web hybride aujourd'hui, les différentes technos et leurs différences. Je me souviens avoir vu un talk à la TakeOffConf qui faisait un état des lieux des bases de données NoSQL général dans le même genre et c'est vraiment un type de talk que j'affectionne beaucoup.
L'histoire du monde hybride a commencé avec Phonegap, qui s'est ensuite fait racheter par Adobe. Puis Facebook a annoncé que le HTML5 était mort et qu'ils partaient en tout natif.
En fait, le soucis du HTML5, c'est qu'il n'existait pas de SDK pour faire des applis mobiles, alors que ceux-ci sont bien présents en iOS et Android. Pour un développeur hybride, il faut partir de rien.
Il y aujourd'hui pas mal de frameworks pour aider à faire ça, avec des méthodes très différentes. D'un coté on a les applications hybrides à base de webview avec HTML/CSS/JS et de l'autre on a celles qui ne font que du JS qui pilote des composants natifs (comme ReactNative). Cette deuxième version est encore assez jeune donc peu stable encore mais prometteuse car elle a l'avantage de ne pas demander de recompilation de l'app.
Coté Webview, il nous a parlé rapidement de Famous, qui est un moteur de rendu à base de CSS Transform3D. Il n'y a aucun élément de UI avec, c'est plutôt réservé à des applications événementielles. On a sinon Onsen UI, qui est le "Bootstrap du mobile".
Mais surtout on a Ionic, qui est un mix entre Angular, Gulp, Sass et Cordova (pour packager le tout en une application standalone). Le projet parvient à lever des millions, est bien suivi, avec une doc bien complète, une communauté active et un écosystème de tooling complet. Il propose même des thèmes qui s'adaptent au device sur lequel ils tournent (iOS ou Android).
Ionic ne supporte que iOS6+ et Android 4.1+, mais avec les dernières versions d'Android il profite de la mise à jour automatique de Chrome. Pour accéder aux fonctionnalités natives des téléphones, il propose son propre système de plugin (qui nécessite de coder la fonctionnalité en iOS ou en Android, et ensuite d'y déléguer l'appel depuis l'appli Ionic).
Aujourd'hui, Ionic est le clair vainqueur du monde de l'hybride, mais si un autre système voyait le jour en remplaçant la couche Angular par du React, il lui prendrait sans doute sa place.
Conclusion
Au final je ressors mitigé de cette première journée de ParisWeb. Je me souviens de mon premier ParisWeb en 2006, où j'avais appris plus en deux jours de confs qu'en 6 mois de veille technologique. Je suis revenu chaque année depuis (sauf en 2012, où je vivais en Nouvelle-Zélande). Je m'étais déjà fait la réflexion l'année dernière, mais c'est encore plus flagrant cette année : je n'ai pas le sentiment d'avoir appris grand chose cette année.
Sans doute parce que j'ai plus d'expérience et que du coup je prends plus mon pied en nouvelles découvertes dans des confs comme dotScale, qui touche quelque chose d'encore neuf pour moi.
Je pense que je ne suis plus forcément la cible de ParisWeb, ou que j'ai mal choisi mes conférences aujourd'hui mais entre celles que j'avais déjà vu et celles qui ne m'ont rien appris, j'ai plus autant cette magie de l'événement qui reste en moi après la fin de la journée.
Mais il reste deux jours d'événement, et j'ai quand même pas l'intention de les rater :)
Note: For this post, I'll try to write in English. I'm now working in an english-speaking company and I'm already writing emails in English to give feedback on the HumanTalks sessions. I'm not used to write such lengthy posts in English, though. Hopefully I'll get better at it the more I do it.
This session occurred at Prestashop new office. Right near the Gare St-Lazare in Paris, the office was brand new and really nice. For those that don't know, Prestashop is the "Wordpress of e-commerce". They did a quick recruiting speech at the start of the meetup, and they are looking for devops and front-end devs.
OpenID Connect
The first talk was from my former coworker and mentor, François Petitit from Octo. He talked about the France Connect initiative, pushed by the French government to have some kind of state platform where all administrations could exchange data in a uniformed way.
This ultimate goal is, as a citizen, that you do not have to fill the same form asking for your name, address and social security number every time you apply to a state service. Also, this will remove the burden of having to provide all the necessary papers to an administration. With the France Connect initiative, your profile will be centralized and shared between all the state instances and they could securely get documents from one another.
François worked on the main bricks of implementation and on one of the first real-life implementations. France Connect wraps several identity providers and identity clients. Each brick can be either provider or client.
This mean that one brick could act as a provider of identity, responding to requests of other bricks with data about a citizen. It could also act as a client, asking data about a citizen to other bricks of the network.
The application on which François worked was both, so he had to implement both sides. The protocol used behind the scenes is OpenId Connect which is already used by Google, Microsoft or Paypal. This must not be confused with OpenId.
OpenId was the ancestor, but it has now be deprecated and OpenId Connect is the new standard, which is based on OAuth 2. The OpenId group is an official group that can certify libraries and implementations of the protocol.
The OpenId Connect norm was finalized in 2014, with already some implementations in production. When you sign-in with Google on any site, this is using OpenId Connect. The spec defines ways to normalize the way sessions across several sites are handled, as well as how multi-identities on one site should be treated.
François told us about the real-life scenario they were implementing. Let's imagine you want to apply for a scholarship from you city website. Here, we are dealing with three actors. You, as the main user. The city, through its website. And an identity provider (to tell the city who you are).
You start by navigating to your city website. It asks for identification. You can choose which site can give your identification from a list (it could be the social security, or the tax department). You're then redirected to the website you choose. You login there and you're automatically redirected back to the initial website (the city one), with all your information already filled in. The needed data was send by the social security/tax department you logged to.
OpenId connect defines a set of standard to define a person, what fields should be used. This makes exchange between different providers easier.
The current landscape of OpenId is full of libraries, used by big names and most of them are officially certified. You need about 3 days of work to be able to consume information from a provider. To become yourself a provider this can take a bit longer. From their experience, what took the most time was not the implementation it self, but being able to get access to the data in the first place.
Nevertheless, it is important to note that the OpenId specs are very large and some areas are not clear or you can do the same thing in very different ways. This results in various client/provider implementation handling thing so differently that they are not really compatible in the end.
Make your business SPOF-less
The second talk was from Alex Centar, one of the founders of Jumboweb, a French web agency of 4 people. They mostly do web and mobile custom applications. Their company is growing, which makes them have less and less time. They decided to start working remotely and gave us some feedback on how to make it go smoothly, even when something goes wrong.
They realized that they had a lot of SPOFs in the way they did things. When you start looking for SPOFs, you find a lot of them. The A/C can be a SPOF during summer. Internet access and electricity certainly are. And each of the 4 members of the company are SPOFs also if they disappear.
They started to count how many projects would fail if one team member had an accident? 1, 2, 10? And would it put the whole company down? They had to find a way to limit that.
First of all, they added fallbacks to the tools they often use. Having a fixed telephone line in case the mobile one stops working. Backup all their work from their laptop machines to a decentralized server automatically, in another location.
Then, they put all the passwords in a Keepass file, shared in their Dropbox. They gave access to the Calendar and Financial information to everybody. Any tool one of them was using was also opened so anyone could use it, even if they did not need it at the time. This includes TODO lists, bug trackers, Evernote, Slack. The goal was that everybody had access to the same information.
Then, they started sharing their work. They wanted to do more than simply working together, they wanted to be able to have each of them able to work on all projects easily.
They do systematic peer programming, so that the code of one project is not in only one person head, but at least in two. They do code review on everything, at first with only the two developers involved, then with all the team. That way, everybody works on every projects, and when a critical bugfix is required, people at least know where to start. But still, they keep only one privileged interlocutor for each project when speaking with their customers. They kept that because it is better for the customer to always have the same person they are talking to.
They found that this was providing the best quality of their work. Everyone is able to work from anywhere, everybody learns, seniors can teach juniors and no project is ever stalled.
But our jobs requires that we do a lot of technology watch to keep us afloat in this ever-changing world of web development. So, to be sure that all of them had enough time to read and learn while keeping the company running they created a kind of reward system.
Each worked day earn employees "free time" that can be used for technology watch without pressure. They did the math and know the minimum number of worked hours that will keep their company running. Anyone has a counter of free time available and you're encouraged to use it. I must admit I did not completely understood the algorithm used here, but they did an open-source webapp to keep track of all the time spend on work and gained (they use the Freckle API to keep track of time).
They decided that the goal of their company was the well-being of the 4 of them. More time for family, more time for personal stuff, while still earning enough money to live with enough comfort. They get payed by the hour, they know what the budget for a project is, so they can easily know when they're making a profit and when they're not.
Mobile development recap
The next talk was the story of David Wursteisen that wanted to create a native app. He followed the advice from John Carmak (the creator of DOOM), who said that it is easier to launch application on small platforms, because you have less options and less things to consider.
So David started creating it own game on an Android device, but he soon discovered than creating a game is much more difficult than he initially thought. You need to be good on a large set of skills.
So he started working on a simple app instead. He wanted an app that automatically set its phone to vibration mode when he was at work, maximum volume when at home, and silence mode at any other moment.
He first downloaded an existing app that did the same thing, to see if the idea was actually useful. The test was positive, but the app he tested had much more features than he really needed. So he started working on its own app, with only one feature, but one he needed.
Before coding anything, he started testing the UI with slides. He showed it to several people, but nobody could understand how it worked. He tried with icons instead of text labels, people reacted better. Then he did a quick paper mockup and tested it on a few friends. He managed to simplify the UI still a bit more.
So he started coding. At first he followed the Google tutorials and guidelines, but he found them to be overwhelmingly complex and finally used tools he already knew : IntelliJ and Java. He lost a bit of time understanding how to register its app on the Play Store, but finally it was released.
He then discovered than debugging an app in the wild is hard. When the app crashes on one of your user's phone, you have no way to access the stacktrace to debug (unless the user clicks on "Send the crash report". But nobody does that). He had to release a new version that included a crash reporter built-in.
The app was working quite well, he now had to find a price to sell it. He chose 0.79€. Now, it was time to make discovering of the app in the Play Store easier. At first it was quite hard to find the app (it is named Georing, but the Play Store suggested Goering instead. Not very helpful). He tried the good old method of contacting (online) newspaper to talk about its app, but none never replied.
He increased the price. 0.79€ seemed to cheap, so he thought that by increasing it, it would show that the app was of good quality. It actually did not change anything on its number of download. He finally decided to put it completely free (and here an important note, it is not possible to revert this choice. Once an app is set as free, there is no way to set a price for it later, so be careful when making that choice).
This change actually paid off (no pun intended), as he got 15 new downloads! He then tried to make it more known by using Twitter, talking about it in meetups, to his friends and family. He considered adding ads inside the app at one point, but finally decided not to.
In the end, I really liked this talk because it shown the whole journey of someone who never created a native app to one that is available on the store. He did not spend too much time on the technical side but much more on all the questions you have to ask yourself when doing this kind of thing.
This was a very honest explanation, and I liked the posture he chose regarding price, ads, iterations and the MVP process.
Tails
Last talk was by Jean Baylon, and about the Tails Linux distribution.
The goal of the distribution is to be anonymous when going on the Internet. It lets journalists pass through the multiple layers of censorship. It actually is part of the base tech package of Reporters Without Borders and was also approved by Snowden.
Their are currently about 11k users (and one can wonder how we can get this number if the goal is actually to stay anonymous, maybe number of downloads?) and there are about 20 developers committing on the project on a regular basis. It got part of its funding from other projects in the field, like TOR, Debian or the Freedom of Press Foundation.
Tails should be used when you are doing something out of the ordinary. And it is not enough to protection your anonymity. If you use Tails to buy something on Amazon with your credit card and have it delivered at your place, it won't help.
What it does is having TOR and Firefox installed and configured by default. It also has an encrypted pidgin and automatically spoof the MAC address. It is loaded with aircrack ng to check the current wifi security and reliability and also contains a bitcoin wallet.
You can run it from a USB key, without installing anything, with absolutely everything loaded in memory. It means that it won't even leave a file on the file system. Its UI can mimic common windows UI in case you have to load it from a public cyberspace. You can even use a virtual keyboard that would bypass any hardware key logger that might be present in the keyboard.
Nice and interesting project, whose internal tools are now more and more common practice in the more popular distributions.
I'll just finish on a small note. The simple fact that you searched for it on Google would put you on some kind of list somewhere in the NSA files. And coming to a meetup that talked about it as well. And maybe just even reading this blog post.
Conclusion
Nice and varied talks as usual, honest feedback about projects people actually did. That's why I like the HumanTalks so much.
