10 Nov 2015For the third year anniversary of the HumanTalks, we did a special event. We were hosted at the Société Générale headquarters, in one of the most beautiful conference room I've ever seen. There also was more attendees than usual, and we gave some goodies, T-shirts and JetBrain licenses at the end.
It was also the first session with Antoine Pezé as our official new team member.
And for me, the first time I went to the SG building. I must say I had a bad feeling about the place at first. I feel like La Défense is really a creepy place, with everything I don't like about modern society. Big grey buildings that tower over you, and everything seems to have been constructed for giants. As a human being, you feel out of place. Big tall towers with thousands of people working in them, all dressed the same. The only sources of light were from the ads and the mall windows. Grey, work, consume.
But then, in all this ocean of sadness, we met with Adrien Blind who is in charge of organising the meetups at the Société Générale. And I discovered that the SG is actually much more interesting in the inside than the outside. They are quick to iterate, have DevOps all the way from top to bottom, and really know and apply Agile and Software Craftsmanship philosophy. We'll see more about that in the last talk.
Front-end testing
The first talk was done by William Ong, former coworker from Octo. He presented the front-end testing ref card they developed. It's a physical cardboard flyer that lists all the different kind of tests you can do to your front-end (from unit testing to performance testing and security testing), with examples, tools and advices.
The content of the refcard is really really great. It gives a nice overview of what can (and should be done) today, but also advices on the costs of each of them and when to implement them or not.
The web frontend landscape evolved a lot in the past years, and it is getting more and more complex with more and more logic being moved from the back-end to the front. To keep it sustainable, we now need to use the same kind of tooling we're used to use on the backend: testing harnesses.
Unit testing are a must have. He won't even develop on that subject because it is obvious. No good quality code can endure the stress of time without unit testing. Code that isn't unit tested is not finished.
But then, came all the other kinds of tests. When should we use them? Which tools should we use? Are they really needed? All the other tests are harder to put in place, so you should only add them if it helps you fight a pain you already experienced. They are costly to start, costly to maintain, so the benefit must be higher than the cost.
For integration testing (here also named end-to-end testing or functional testing), you should only add them on the critical path of your users. The one that generate money (subscription funnel) for example. This kind of test will indirectly test the whole stack. It will warn you when the core functionality you're testing is broken, but won't really help you diagnose where the issue could come from (database, back-end, front-end, etc.). These tests are also the longest to write and will yield false positive whenever you update the design/markup.
Talking about design, it is also possible to test your design. Using PhantomCSS, you can take screenshots of your whole page or specific parts of it and check that they did not change with the previous commit. This will help you diagnose changes to the website created by a seemingly unrelated CSS commit. Those tests can be invaluable, but they will also yield false positive results when a design change is actually expected. As for the integration test, limit yourself to the real main parts of your app.
You can also test for common security exploits, like the top 10 OWASP. Some tools can test them on your website and warn you of any vulnerability. Another approach can also be to ask for a security audit, and I personally also recommend opening an open hacker bounty program, like HackerOne.
In the end, all tests share one benefit: they give you the freedom to make the code evolve without being afraid of breaking things. It gives you complete trust in the code.
It was William first public talk, and the room was quite impressive with more than 120 attendees, so I guess he freaked out a bit. There were a few silences where you could feel that William was intimidated, and he looked a lot at his slides to give him some assurance. In the end, the message was here and it was interesting, and we'll be happy to have him on stage another time if he wants.
How to win at TCG with code
I don't know how many coffees Gary Mialaret took before coming on stage for the next talk, but he seemed to be really happy to be here and was almost jumping and running while speaking.
Gary told all us about TCG (Trading Card Games), and how those kind of game are no longer really about trading (Hearthstone for example, does not allow trading of cards). The main common ground of all those games is that it's a duel between two players, where each player create its deck of cards before the game and must carefully balance the number of monster/spell cards (that can make him win), with the resource cards (that are needed for using the monster/spell cards).
Empirically, every hardcore Magic player knows that a balanced deck needs 24 resource card, but Gary wanted to get to the math behind it to prove that it was the most optimal number.
He introduced us to the hypergeometric distribution mathematical function, that can calculate the probability of drawing a hand with at least n "good" cards, given the number of cards in a hand, the number of cards in a deck, and the ratio of good/bad cards in a deck.
While applying the method to a basic Magic deck we do not get the 24 cards we talked about earlier. This is because this method does not take into account another Magic mechanism called Mulligan, that lets you discard all your starting hand and start with a new one instead. To simulate that, he had to resort to a bit more coding. He generated thousands of different hands, discarding them when they did not meet his expectation and managed to get back to the magical 24 number.
He went even further, simulating basic Magic rules, playing against what is called a goldfish (a player that does not respond to attacks, and basically does nothing). He went on creating adaptive algorithms, applying something similar to genetic selection on deck creation. He starts with simple deck, make them play against goldfishes, then keep the one that works best, apply a few random slight changed (a bit more of that card, a bit less of that one), and make them play again until he reached the best possible deck.
His final conclusion is that we should not hesitate to put some of our developer mind in action to solve things that are not related to development. The most important thing when we want to solve a problem, is to know which questions we're looking answers for. Magic is a very complex game, it is not possible to code every possible rule and generate every possible deck to find the ultimate one. But by focusing on one specific problem, we can learn a lot about the underlying principles and this, in turn, helps us devise a better deck.
How our brain reacts to instant
The next talk was done by Gaetan Gachet, with whom I work at Algolia. He talked about the way our brain reacts to instant feedbacks.
His presentation was explaining the theory of Information Foraging. The main idea is that the way we are today looking for information on websites is similar to what our ancestors were doing when hunting.
When you hunt you know a few interesting places where you know you might find game. But sometimes, not game shows up, so you wait a bit more. And more. And more. Until you decide that it is not worth waiting any longer, and that you might actually just move to the next place you know could be a good hunting place.
But this second place is far away, and it will take you hours to get there, so that's why you wanted to wait here a little longer. But now, you decide that your current spot is not good enough and you'll take the chance to move to the next one.
What happened in your brain was actually a simple equation of risks and return. At the start it seemed more interesting to stay, to see if you could find something here, because you know that this place should have animals to hunt. But the more you wait without results, the more you're thinking that moving to the next place might actually be more interesting. Until you decide that you've wasted enough time and actually move.
When looking for information online we act the same. We first go to a first website, because Google told us that it might have the information we are looking for. We are searching their list of products, trying to find the one we want. We are skimming pages and pages of results until we realize that what we are looking for is not here, and that maybe we'll have more luck going to the next website.
This would not have happened if either the first website let you easily find what you're looking for, or would easily tell you that it does not have what you're looking for. It is just a matter of how much information you get compared to the time you spend.
In that analogy, Google is actually the whole territory the hunter can access in a day, while each website is a known hunting zone. But because Google is so fast, moving from one hunting zone to the next is actually really easy. And so you are more easily convinced to try another hunting zone if you did not find what you were looking for in the first minutes or second of hunting.
The paradox here is that the faster Google is, the less time people will spend on your site, because they know they can easily go search in another website if yours does not yield relevant results quickly.
That is why it is very important to give quick and relevant results to user searches when they come to your website, because you have competitors, and users will easily jump to a competitor website if they do not find what they are looking for on your website. Being the top first result on a Google page search is not enough.
Culture Craft
Last talk of the day was a nice story about what happened at Société Générale in the past years, by Thomas Pierrain. Some people wanted to "wake up" the organisation. They felt like the overall strategy of the company was not adapted to its current culture. And that the current culture was slowly dying because of that.
The speaker actually confessed that he wanted to leave the company at that time. But he stopped short when he realized that his thinking was actually just something along the lines of "it was better before", which is what stupid old men are usually saying. And he didn't want to become a stupid old man, so he decided to do something about it.
He started organizing BBLs internally, where they will book a room during lunch and one of them was going to talk about a subject he was passionate about while the other would listen to him (and eat their lunch). They also organized some coding dojo, where everybody in a room would work on the same computer problem, one after another, and everybody helping others.
But it did not started that fast. At first he was alone. So he asked a friend if he would be interested in listening to him speak at a BBL. The friend was ok, and talked about it to other friends. So they did it. They did not tell the management, or booked a room. They just took an empty room and did it. They knew that because they were some of the oldest developers in the company, nobody would listen to them. So they just did it.
The first BBL was a success. The room was small, so not everybody could come in. Those who couldn't come in wanted to come to the next one. It started to work on a "first come, first served" principle and gave the event a nice image.
They also created some events codenamed "Dude, you have to see this!". In those events, they take a room and one person opens a Youtube/TEDTalk video he liked, everybody watches it, and then everybody discuss it.
And they kept creating things like that. Things like lunch mob, where they gather together for lunch and code on a project and push everything at the end. They posted photos internally, put some on Twitter and in the end, what started as a single initiative is now a well-known fact of how things are working at the SG.
His main advice was simply to make it happen. Some people won't like it, so don't invite them and don't try to convince them. Focus on those that are interested and build something for them and with them.
Conclusion
Overall a really nice session. Thanks a lot to the Société Générale to have hosted us in that wonderful room, and thanks for their very inspiring talk as well.
Unfortunately, even if the room had all the video capture capabilities, we still did not manage to get the videos... It taught us to always record with our own devices :)
20 Oct 2015Third 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 slides are already available here.
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.
CSS Grids
The last talk was done by my fellow co-organizer of the HumanTalks Paris, Mathieu Parisot.
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.
13 Oct 2015Note: 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.
How to fail at code review
The second talk was by Michel Domenjoud, from Octo Technology. He was giving the same talk two days after at the Agile Tour Lille. Michel shared with us some stories about code review, and specifically peer review.
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.
02 Oct 2015Deuxiè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 === 2
let {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
Thierry Michel, de EPIC, nous a ensuite fait un petit cours de ligne de commande à destination des designers. À en croire ses exemples, tous les designers sont sous Mac d'ailleurs.
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.
