C’est la Technozaure de Lille !

Avant toute chose, qu’est-ce qu’une Technozaure ?
Il s’agit d’une demi-journée de conférences internes lors de laquelle nos Z proposent des sujets de talks à présenter à leur collègues. Elles ont lieu 1 fois par trimestre et par agence Zenika. Tous types de sujets peuvent être abordés : des sujets techniques bien sûr, mais aussi traitant de la diversité au travail, le bien-être, etc.
Aujourd’hui, je vous propose une petite rétrospective de notre Technozaure Lilloise ! A vos souris, prêts, lisez !

Ne me libère pas, je m’en charge

Un premier talk sur la diversité et la présence des femmes dans les métiers techniques, dans les médias, dans les arts. Laetitia et Elya constatent d’abord que les femmes sont sous-représentées. 
Pourtant, autant de jeunes femmes ont des bacs techniques que de jeunes hommes. Alors où disparaissent-elles ?
En plus, il y a des modèles de femmes espionnes, scientifiques et même informaticiennes. Par exemple, le logiciel d’ENIAC a été développé par des femmes. Plusieurs femmes ont participé à la conception de COBOL (qui à l’époque était une bonne idée). Alors pourquoi si peu de femmes ? Pas assez d’écoute ? Pas de légitimité ? Ou … à cause de la menace du stéréotype ?
Et typiquement, dans un environnement dominé par les hommes blancs, l’utilisation de la double contrainte élimine les profils qui ne rentrent pas dans cette case.
Comment pallier ces stéréotypes ?

• Soit par la démonstration, mais c’est long et compliqué.
• Soit en forçant les mentalités à changer, en donnant des exemples.

Autrement dit, au lieu de vous libérer, il faudrait d’abord délivrer les hommes de leurs préjugés. Ce qui est peut-être le meilleur conseil de cette présentation : les femmes n’ont pas de problème, mais certains hommes, oui.

Avoir une maison connectée libre ! Introduction à Open Hab

Pierre, qui débute dans l’IoT, va nous parler maison connectée et d’Open Hab.
Contexte :
Pierre a acheté trois ampoules Philips avec un interrupteur et un boîtier de contrôle.
Problème : tout est propriétaire (lampe, boitier, interrupteur). Mais il a une vingtaine d’ampoules dans sa maison. Pierre a également une machine à cocktail et un aquarium.
Alors comment connecter les ampoules IFTTT, des lampes (quelle que soit leur marque), ou d’autres devices ? En creusant un peu, Pierre a trouvé plusieurs alternatives open source.

• Jeedom
• OpenHab

Comme OpenHab est plus simple à installer, c’est la solution qu’a choisie Pierre. C’est une solution simple, avec une API REST, compatible Zigbee (donc Philips Hue) et EnOcean.
Dans OpenHab, on a un panneau de contrôle configurable et réactif. Les éléments de ce panneau de contrôle sont des items, qu’on peut configurer facilement. En bonus, on peut créer des plugins qui permettent par exemple de créer des chatbots.
Pierre nous fait alors une petite démo d’une maison miniature avec une diode, un thermomètre, et une connexion à Google Home (parce que Pierre aime Google Home).
Première chose, l’affichage de la diode est bien contrôlé par OpenHab (ce que nous montre d’abord Pierre).
Et ensuite, il construit un écran permettant de piloter la diode depuis OpenHab.
Et enfin, il connecte Google Home à son installation OpenHab et nous montre qu’effectivement, il peut récupérer la température depuis son téléphone ou allumer et éteindre sa diode.

Que se passe-t-il lorsque je vais sur Google.fr ?

Delphin et Nathan vont nous parler de ce qu’il se passe lorsqu’on se connecte à Google.fr
Evidemment, vous entrez le nom de votre site dans Chrome et vous tapez sur ENTER. (ici doublepenne.com)
Et là, il y a plusieurs parties :

• user interface
• browser engine
• rendering engine
• networking
• js interpreter
• ui backend
• data persistence

Et donc, quand on tape une requête, on passe par la couche networking.
On envoie une requête HTTP qui va d’abord passer par une résolution DNS. Cette résolution se fait sur le DNS que vous utilisez, qui va se connecter au root DNS (pour récupérer le nom du serveur gérant les “.com”), puis au serveur gérant les “.com” qui va donner l’adresse du serveur.
On y voit une certaine parallèle entre les couches OSI et un courrier physique.
Dans un courrier physique, on a une adresse physique, et pour notre requête, on a une adresse IP. Et pour déterminer le destinataire à une adresse donnée, on donne son nom, ce qui correspond au port TCP.
On rentre ensuite dans les détails du transport TCP. Établissement de la connexion, gestion de la congestion…
Passons maintenant au HTTPS, avec en introduction la différence entre cryptage symétrique et asymétrique. Pour Nathan, le terme asymétrique est mal choisi : il vaut mieux parler de clés de lecture et de clés d’écriture (et c’est vraiment une bonne vision). Et clairement, chiffrer ne suffit pas : il faut aussi certifier qu’une clé de signature est bien émise par le correspondant auquel on souhaite parler. Certains certificats sont présents sur votre ordinateur. Mais pas tous, parce qu’il y en a un paquet. Grâce au principe de “chain of trust”, on peut utiliser des certificats pour peu qu’ils soient certifiés par une autorité de certification que votre ordinateur connaît.
Grâce à tous ces éléments, on sait comment effectuer la requête. Reste maintenant à interpréter le résultat pour l’afficher. Pour ça, on parse le document HTML reçu, on en déduit les éléments complémentaires (CSS, JS, images, …). Avec ces éléments, on construit un rendering tree (qui ne contient que les éléments affichables). Et tout ça est affiché dans le layout engine.
En conclusion, cette présentation nous a appris énormément de choses grâce à Delphin et Nathan et ça parle de pâtes.

k3s, c’est 5 de moins que k8s

k3s, c’est une distribution certifiée de Kubernetes (k8s) créée par Rancher Labs.
L’objectif, c’est de rendre k8s facile à installer. Comme c’est plus simple, il suffit de 512 Mo de RAM pour le serveur, et 70 Mo par nœud.
Dans les simplifications, il y a par exemple le remplacement d’etcd par SQLite, la suppression des plugins, des API legacy ou alpha. Il y a aussi l’intégration de Helm, de Traefik. Mais aussi l’intégration de la commande kubectl dans le binaire.
Cela va vraisemblablement être pratique pour l’edge computing, l’IoT, la CI et les clusters pour une seule application.
Dans les usages typiques, il y a aussi (évidemment) le fait de déployer des clusters K8s de développement (sans Minikube).
Nicolas va tenter, à travers plusieurs démos, de nous montrer les avantages de cette solution. Et là, comme dans Kaamelott, tout ne se passe pas comme prévu.

Heureusement, Nicolas arrive finalement à nous montrer le déploiement de quelques conteneurs dans k3s (en utilisant Rancher v2 pour se faciliter l’installation des applications).

Votre stack micro service, je vous la sers bloquante ou réactive ?

Pourquoi la programmation réactive ?
Dans une application monothread, dès qu’on a un IO, l’application se met en attente. Classiquement, pour accélérer ça, on utilise du multithread, qui présente plusieurs inconvénients (limite du nombre de thread par machine, et coût du création des threads).
D’où le reactive manifesto, dans lequel on va essentiellement passer des messages qui vont permettre d’éviter ces limitations. Il y a des implémentations pour la plupart des langages.
Dans Spring, vous pouvez utiliser Webflux, qui va utiliser Reactor 3. A noter que pour le réseau, il faut utiliser rsocket (et r2jdbc pour l’accès aux bases SQL)
Sébastien nous démontre donc l’intérêt de cette approche à travers une démo.
Pour ça, il récupère depuis une API web un flux (au sens reactor) de magasins. Pour chaque magasin, il récupère les avis clients ainsi que les horaires d’ouverture du magasin.
Il y a par ailleurs des moyens de tester les flux de façon unitaire.
Pour conclure, le talk est intéressant parce qu’on se concentre sur les messages, on utilise une API fonctionnelle de façon non bloquante, et enfin parce qu’on gère correctement la back-pressure.

Kubernetes and Vault integration for dummies

L’objectif de l’intégration de Kubernetes et Vault, c’est la meilleure gestion des secrets.
D’abord, comment stocker les secrets ?

• En dur dans l’image ?
  Ça n’est pas terriblement sécurisé.
• Avec des variables d’environnement remplies depuis Keepass ?
  Ça n’est pas terrible parce que Keepass ne fournit pas d’API
• Avec Kubernetes Secret ?
  Les secrets sont seulement cachés dans des fichiers en base64. Et la sécurité est loin d’être assurée.

Il y a évidemment des alternatives plus complètes :

• Bitnami Sealed Secrets (simple avec un conteneur hébergeant une clé privée)
• Vault

Dans Vault, vous avez des tonnes de fonctionnalités utiles :

• le stockage chiffré des secrets
• les secrets dynamiques
• le chiffrage de données
• l’expiration et le renouvellement des secrets
• la révocation des secrets

Sébastien enchaîne avec un petit exemple de secret dans Vault.
On revient sur donc la gestion d’accès défini par une méthode d’authentification, un rôle et des droits d’accès.
Et on reprend notre démo pour accéder à notre secret depuis Kubernetes.
Pour sécuriser les choses, on peut utiliser :

1. Spring qui fournit une méthode de chargement de secrets
2. Vault CRD qui va créer de nouvelles ressources pour accéder aux secrets
3. Un initContainer en utilisant soit Consul Template, soit kube-vault-client.
4. Bank-vault

Dans cette démo, on va utiliser kube-vault-client qui est très simple (mais pas follement maintenu). Et effectivement, on constate que les secrets sont visibles dans l’environnement.

fix(yagni): stop doing useless things

Commençons par git …
Souvent, on a des conventions de messages de commit.
Mais créer des commits qui ne respectent pas ces conventions, ça peut être utile, du moment que les outils qui font les merge permettent d’utiliser un commentaire respectant la convention.
De la même manière, utiliser git flow … c’est pas toujours utile.
Enfin, utiliser git blame, git annotate … ça n’est juste pas une bonne idée : savoir qui a fait l’erreur, c‘est souvent pour le blâmer, et ça n’est du coup pas utile au projet.
Ensuite, la doc est souvent redondante (par exemple les commentaires de getter). Ou elle n’est pas à jour quand il s’agit de commentaires de code (et pas de javadoc/jsdoc). Autrement dit, il pourrait être bien d’écrire son code d’une manière qui évite d’avoir à écrire des commentaires. Ça ne veut pas dire que la doc est inutile. Par exemple, la doc de librairies est utile (parce que vous n’avez pas envie que les utilisateurs de votre librairie aient à regarder le code source). Ou quand le code prend une décision qui ne semble pas triviale.
Pour continuer, mettre un cache Redis, ça peut être une solution compliquée pour un besoin simple.
Dans le même ordre d’idée, on demande souvent à avoir la configuration dans une base de données pour la recharger. Mais ça n’est plus si utile maintenant qu’on a de l’intégration continue qui marche.
Concernant l’agile, il y a tout un tas de cérémonies. Est-ce qu’elles servent à quelque chose ? Si la cérémonie ne sert à rien, pourquoi la conserver ?
Tous ces éléments correspondent en fait à un besoin : communiquer pour effectuer le bon travail au bon moment.
Enfin, un sujet important pour éviter la complexité et d’avoir une CI/CD qui marche bien, ça facilitera beaucoup les choses (parce que ça accélérera la boucle de feedback).
En guise de conclusion, notre travail est rempli de cérémonies humaines ou techniques qu’on adopte sans les questionner. Ça n’est pas une bonne idée, parce que ces cérémonies n’ont un sens que dans un contexte. Et Delphin et Nathan nous aident à nous questionner sur ce contexte.

Le CIA : Le Collectif des Imposteurs Anonymes

En 2018, Logan découvre une étude qui indique que les développeurs se sentent intimidés face à la variété des langages et des frameworks. Et c’est le moment où Elya et lui découvrent le syndrome de l’imposteur.
Ce syndrome décrit des gens qui ont des doutes de leur responsabilité dans leur réussite. Ça n’est néanmoins pas une maladie, et les personnes qui ont créé le terme regrettent le mot “syndrome”. On peut connaître son niveau d’imposture grâce à un test en ligne.
Ce syndrome, quelque part, vient du fait que les attentes des autres pèsent sur les personnes qui subissent ce syndrome. Pour donner un exemple, lorsque Logan a été recruté, sa première réaction a été “comment j’ai fait pour les duper ?”, ce qui exprimait de façon flagrante sa peur du succès.
Parmi les risques associés,

• le burn out : pour ne pas décevoir, on va en donner plus
• la procrastination qu’on peut voir comme une forme de paralysie (parce qu’on veut retarder l’échec autant que possible)

Pour aller plus loin, les créateurs du terme ont cherché à dresser un portrait robot regroupant dix traits de caractère (dont au moins cinq sont présents sur ceux qui souffrent sur ce syndrome). Ces créateurs ont également montré que ce sentiment d’imposture est un sentiment qui peut être temporaire, et qu’on peut dompter.
Et pour le dompter, ça peut être bien de se demander quand cette auto-sous-estimation a pu être bénéfique. Et en quoi cette histoire que je me raconte présente un intérêt maintenant ?
Comment dompter ce sentiment ?

• D’abord en travaillant sur une boucle de feedback positif.
• Ensuite en se concentrant sur le présent.

Enfin, en utilisant le fameux “fake it til you make it”. Dans une présentation TED, l’intervenant, après un accident de voiture, a perdu 2 niveaux de QI et est entré à Princeton (certes plus lentement que les autres), mais a réussi grâce au travail. Et s’il y a bien une chose que les “imposteurs” réussissent, c’est à passer pour des imposteurs, ils sont donc au moins bons en un domaine. Ça veut dire qu’ils peuvent y arriver.

Algorithmes génétiques : Création du clavier (presque !) parfait

Valentin et Maxime vont nous parler d’algorithmes génétiques à travers un clavier. Un algorithme génétique, globalement, ça marche comme ça.

1. Générer une population aléatoire
2. Évaluer la performance de chaque individu avec une fonction de fitness
3. Trier les individus par performance
4. Garder les meilleurs
5. Croiser ces individus
6. Appliquer une mutation aux individus
7. Retourner à l’étape 2

Maxime enchaîne avec un exemple de génération de vecteurs où tous les nombres sont des 1 dans une application web au style … inimitable (c’est au passage un très bon exercice de développement d’algorithme génétique).
Et puis on passe au vrai exemple : générer un layout de clavier optimisé pour l’anglais frappé à un doigt. Le clavier généré est imparfait parce qu’il correspond à une frappe à un doigt, mais aussi parce qu’il n’est adapté qu’au dictionnaire anglais utilisé. Finalement, ils génèrent à chaque fois des layouts subtilement différents, mais qui assurent des performances équivalentes pour taper du texte en anglais.

Architecture hexagonale for dummies

Pour Delphin et Javier, l’architecture, c’est avant tout un ensemble de règles imposées. Martin Fowler dit aussi que c’est les éléments du projet durs à changer. En parlant d’architecture, on distingue aussi la complexité accidentelle et la complexité essentielle. La complexité essentielle, c’est le coeur du fonctionnement du logiciel et la complexité accidentelle les décorations qu’imposent le fonctionnement du projet (base de données, sécurité…)
Du coup, dans le développement, on cherche la maintenabilité en séparant correctement la complexité accidentelle et la complexité essentielle.
Quelle est la différence entre une architecture hexagonale et une architecture en couches ?
Dans une architecture en couches, on a :

• présentation
• domaine
• persistence

Et chaque appel traverse toutes les couches dans les deux sens.
Dans une architecture hexagonale, c’est la persistance qui dépend du domaine (typiquement).
Il y a par conséquent quelques règles

• Séparer application, domaine et infrastructure
• Le domaine ne dépend de rien (pas de code d’infrastructure dans le domaine)

Dans les inconvénients de cette architecture, il y a

• compliqué au premier abord
• il semble difficile de séparer le métier de la couche de persistance (notamment pour la performance)
• C’est un style assez verbeux

Par contre, il y a des avantages

• La testabilité est augmentée
  • En particulier les tests fonctionnels sont plus simples grâce aux mocks de persistance
• Il est possible de créer une architecture émergente facilement.
• La compréhension du domaine est plus facile.
• Le domaine est protégé des composants externes.
• Les migrations techniques sont facilitées.

L’histoire des modes en informatique

Il y a des modes en informatiques, et Nico va nous les présenter (de son point de vue)
Est qu’on utilise un ordinateur de manière efficace ?
Revenons en arrière, comment sommes-nous arrivés à utiliser une tonne de langage ?

• 2000 : la POO a gagné ?

Nico pense que JS n’est pas un langage-objet. Il cite l’article de Douglas Crockford, qui affirme que JS est fonctionnel depuis le début.

• 2010 : Java se fait copier par microsoft, emergence de GWT. en 2012, 200 langages supportés pas la JVM. interpeteur => bytecode => JVM, peu d’effort : attractif.
• 2019 : la programmation fonctionnelle émerge dans tous les langages.
  

Pourquoi tout le monde fait map Reduce ? Nicolas fait l’hypothèse que c’est avant tout parce que Google est basé sur map reduce.

• Côté serveur en 2000 : servlet, packager en WAR, Tomcat, Nagios. On s’est dit qu’on pouvait faire mieux.
  Il y avait JavaEE, mais apparemment ce n’est pas top.
• 2010 : Struts, Wicket (Loïc aime), GWT, JSF. On peut écrire des EJB presque compréhensibles par un être humain.On commence à faire doucement du NoSQL
• 2019: On crée un JAR avec Spring Boot, Micronaut, ou d’autres buzz words. Mais surtout, on utilise Docker, Kubernetes. Ce qui conduit à l’émergence des microservices

Pourquoi Kubernetes a gagné ? Parce que Google l’a fait. Tout le monde veut être Google.
Côté client.
Révolution Chrome. Pub passive-aggressive de la part de Google pour le promouvoir.
Jquery partout.
Aujourd’hui côté navigateur : la trinité React, Angular, VueJS. React parce que Facebook. Mais pourquoi Vue ?
D’après Nico, en utilisant React ou Angular, on bosse un peu pour les boites qui ont créé ces frameworks et qui nous remercient d’améliorer leur application
En bref, retenez les leçons de l’histoire : les transactions, les conteneurs, les réseaux de neurones (une des premières applications de l’informatique).
Ne soyez pas des CDD (Conference driven developers).

Pour terminer, quelques conclusions en vrac : coder un framework ressemble à une forme de lobbying (influence de Google, Microsoft, Facebook…), il faut se méfier des silver bullets et des solutions imposées par des modes (par exemple : git convainc les gens que la qualité logicielle se vaut à la stratégie de branche).

Encore une session réussie ! Merci à tous les participants et au trimestre prochain !