Comme tous les ans, l’agence de Lille organise sa technozaure. La technozaure, c’est la conférence interne de l’agence, qui permet aux consultants d’aborder différents sujets : découvertes et partages sur des sujets variés étaient donc au programme de la journée. Des sujets qui, comme dans toute conférence, ont été proposés lors d’un CFP préalable.
Par ailleurs, cette année, nous avons testé une prise de notes collaboratives afin de construire plus facilement ce compte-rendu. Les notes que vous lisez ont donc été écrites en collaboration par une dizaine de personnes.

Another one bites the Rust

https://twitter.com/ZenikaLille/status/1044155343994060800
Ouah, ça commence fort avec l’hypothèse de Sapir-Whorf. Le langage conditionne la façon dont on pense (langage limité = pensée limitée)
Nicolas fait un rapide historique de Rust. Inventé chez Mozilla Research, pour éviter certains problèmes de mémoire liés au C++. Notamment, le garbage collector, c’est mal ! ça bouffe du CPU pour libérer de la mémoire !
Conçu pour être “safe” au niveau de la désallocation de la mémoire, rapide et directement calculée au compilation-time ; conçu pour faire du système aussi. Pas de null, des types génériques dans les collections ; le pattern matching est également possible; concurrent (channel, threads…)
Quelques projets développés en Rust : Firefox Servo (moteur de rendu expérimental), Conduit et Sōzu (reverse proxy de Clever Cloud).
Deux composants essentiels pour faire du Rust : rustup (gère les compo systèmes de rust) & cargo (équivalent maven)
L’essentiel des IDE supportent maintenant le langage Rust même s’il existe un site nommé Are We IDE yet ? pour connaître la liste des IDE qui supportent le langage.
Nicolas poursuit et démarre une session de live coding, pendant laquelle il va nous exposer des concepts de Rust en développant un client FizzBuzz.
Quelques commandes :

• rustup
• cargo init : crée un fichier cargo.toml et un main.rs (Hello, world !)
• cargo run: compile le main.rs et exécute le ruste.exe du dossier target

Une gestion d’erreur user friendly est intégrée.
crates.io est le repository central de librairies Rust
L’ajout d’une dépendance via Cargo implique le téléchargement des dépendances de manière transitive. Les sources sont récupérées et recompilées.
Il y a 2 types de structures de données : enum et struct … Et apparemment 5 types pour les chaînes de caractères dans Rust !
En Rust, on déclare un binding avec let. Il conserve l’endroit où une variable a été créée. Seule la fonction propriétaire de la variable peut la modifier, à moins de la déclarer mutable (mut). Un binding ne peut être consommé qu’une seule fois, en tout cas, en théorie, car la démo n’a pas permis de le démontrer.
Nicolas insiste sur le fait que le compilateur est ‘cool’, car il est explicite lors des erreurs de compilation. Un langage qui a priori permet une grande liberté dans son écriture et exécution

Ce que nous en avons pensé

Le live coding, c’est cool et facile de se concentrer dessus, même si c’est parfois laborieux.
Comment situer Rust par rapport à OCalm, Erlang, Go ?
L’aspect attirant de Rust, selon moi, est situé dans le compilateur et pas dans la syntaxe du langage qui n’est pas du tout révolutionnaire. (et dans les pratiques clean qu’il implique)
Dommage qu’on n’est pas eu une démo sur la gestion de la mémoire, puisqu’il n’y a pas de GC, comment ça se passe sous le capot .
 

Storytelling

https://twitter.com/ZenikaLille/status/1044205118529441792
En général, le public a une durée d’attention de 15 minutes, heureusement extensible avec le storytelling. Le storytelling existe depuis toujours, et produit toujours un gros business (arts & médias, par exemple).
Le cerveau humain interprète 60 fois plus rapidement les images que les mots.
Olivier compare ensuite une introduction à la CNV (communication non violente) via une définition, et une histoire autour de celle-ci. Évidemment, on retient mieux l’histoire.
Parce qu’une histoire, c’est aussi laisser la possibilité à son public de participer.
Le storytelling s’applique bien à l’apprentissage, les histoires font office de moyens mnémotechniques. Et dans l’informatique, le live coding (qui est une façon de raconter une histoire) rend une présentation technique plus vivante, il est par ailleurs plus facile à un public de développeurs de se concentrer dessus
Le truc c’est de “jouer” avec les comportements du cerveau humain : rendre l’expérience positive, stimuler la passion et l’enthousiasme pour activer les zones de mémoire à long terme… Ne pas hésiter à parler de soi, toujours dans l’idée du partage de connaissances
“Raconter, sans trop vous la raconter”

Ce que nous en avons pensé

On remarquera les slides sans mots, juste des images, qui restent assez vagues (un peu comme les images choisies pour les talks improvisés, exercice fait au Devfest Lille pour ceux qui étaient présents)
 

Apache Beam

C'est a présent @ApacheBeam qui est présenté par @lhauspie pic.twitter.com/RbKG3m95p8

— Zenika Lille (@ZenikaLille) September 24, 2018

 
Et c’est Logan qui reprend la parole pour nous parler de ce framework extrait de Google Dataflow.
Plusieurs utilisations :

• stream data processing : c’est un ensemble de méthodes permettant de traiter des données arrivantes sans fin, sans ordre particulier, au fil de l’eau.
• batch data processing, quand les données arrivent par gros paquets.

Il y a deux grandes familles d’algorithmes d’approximation : top-n et k-mean.
C’est utile pour :

• des données sans fin par nature,
• lorsqu’il faut prendre des décisions rapidement,
• quand la charge doit être lissée

Deux types de méthode pour traiter les données :

1. Time based
2. Time-agnostic

On peut regrouper les traitements par “Event-time”
Quatre questions importantes

• What ? (quel résultat obtenir ? Quelle transformation appliquer ?)
• Where ? (où dans l’event time ? quel windowing choisir ?)
• When ? (quand calculer le résultat ?)
• How ? (comment obtenir le résultat)

Logan enchaîne sur un REX  de chez Xee.

Ce que nous en avons pensé

Ça manque un peu de clarté, beaucoup d’infos et peu d’explications, balayage un peu rapide
J’aurais aimé une démo plutôt qu’une présentation de slides (pas très clair concernant l’application pour l’instant)
 

Base de données graphes avec Neo4j

https://twitter.com/ZenikaLille/status/1044219998535864320
Valentin se lance maintenant dans une présentation de Neo4j.
Un graphe, c’est un ensemble de noeuds qui ont des liens, et tous les deux (noeuds et liens) peuvent porter des attributs. Chaque noeud peut avoir autant de labels et de relations que nous le souhaitons. C’est évidemment applicable aux réseaux sociaux (on évite les jointures entre les tables, car on va rechercher par labels ou par relations) ou aux systèmes de recommandation également.
Les requêtes se font en utilisant Cypher, que Valentin présente comme un AsciiArt utilisable pour les requêtes. Cypher représente les relations de façon intuitive. Quelques requêtes, CREATE, MATCH, MERGE…
Démo !
Valentin nous montre une interface plutôt intuitive à laquelle il manque juste un filet de précaution pour les suppressions…
Le browser permet d’avoir un aperçu visuel des noeuds avec un schéma clair. En fait, l’interface d’administration et de requête est vraiment bien faite : les résultats s’affichent sous forme de graphe, et on peut afficher les attributs.

Ce que nous en avons pensé

Très bon ascenseur émotionnel dès le début de la présentation, où Valentin nous fait croire qu’il a purgé sa base … alors qu’en fait non.
A part ça, neo4j est une base déjà bien installée, la découverte est donc limitée. Cependant, la présentation était bien fichue.
 

Terraform

https://twitter.com/ZenikaLille/status/1044231874128875521
Développé par Hashicorp, Terraform permet de gérer et faire évoluer les infrastructures, notamment les clouds avec du code (infra as code). On peut donc faire le provisioning, de la mise en place de réseaux, de la sécurité ou encore de l’installation de middlewares et de services. Avec Terraform, on décrit les différentes ressources qu’on crée (en termes de machines, d’environnements) avec éventuellement du templating en décrivant l’état cible (comme le fait Kubernetes).
Il y a des providers pour les différents cloud (Amazon, Google, Azure) mais aussi pour Kubernetes (et pour Helm), pour des middlewares (RabbitMQ, PostgreSQL, InfluxDB) ou même certains services SaaS (Datadog, Github/Gitlab)
Maxime enchaîne avec une démo sur un projet vide GCP pour créer un environnement d’IC sur GCP.
Le bon point, c’est qu’il est possible de lister les commandes qui vont être effectuées avant de les appliquer. Notez que Terraform génère un fichier d’état : terraform.tfstate qui permet de lister ce qui a déjà été fait. Si ce fichier est perdu, apparemment, c’est foutu.
Si Terraform permet facilement de créer des VM, il ne s’agit pas d’un orchestrateur de déploiement, il peut donc être utile de le combiner avec Ansible ou Chef, qui vont permettre d’installer les logiciels de plus haut niveau … ou de les configurer.
Terraform reste très proche du provider. Les scripts seront différents d’un provider à l’autre.

Ce que j’en ai pensé

La macro c’est SO 2017, en 2018 faut faire des Sadines!
La démo est très chouette … mais présente juste l’inconvénient de reconstruire avec Terraform ce que permet Jenkins-X. Il aurait été plus intéressant de lier un cluster Kafka à un cluster Elastic, chacun étant déployé chez un provider différent.

Data, sport et inefficiency market

https://twitter.com/ZenikaLille/status/1044241276881829888
Matthieu nous explique comment l’équipe des Oakland Athletics a utilisé les failles dans les règles pour gagner … sans payer plus cher. Pour ça, il faut des données. Heureusement, dans le domaine du sport américain, il y a des tonnes de données disponibles. Avec toutes ces données, on a pu conclure dans le domaine du basket que les meilleurs joueurs NBA sont ceux qui sont bons au lancer franc en sport universitaire. Et dans le même ordre d’idée, la NFL a pu déterminer le coût optimal d’un running back.
En informatique, où est-ce qu’on en est ?
Notre marché est beaucoup plus gros.
Mais en informatique, aucun prestataire ne part parce qu’il est mauvais. Au pire, on sera placé en centre de service. Du coup, pourquoi être bon ?
Qui plus est, il y a une prime à la médiocrité : si on est mauvais, on permet d’avoir plus de TMA, ce qui permet de vendre plus de jours.
Enfin, il y a une prime à la complexité : si un développeur est le seul à comprendre son code, il est plus facile pour lui de rester.
Tout ça parce qu’il n’y a aucune mesure.
Dans “productive projects and teams”, les auteurs ont constaté qu’un bon développeur peut être 16 fois plus performant qu’un mauvais développeur. Et ça n’est qu’un exemple ! D’autres recherches ont montré des résultats du même ordre de grandeur.
Le problème, c’est que les grosses entreprises n’ont pas envie d’évaluer réellement leurs développeurs. Parce qu’elles ne veulent pas mettre en avant leurs points faibles, en plus parce qu’il faudrait plus payer les bons développeurs.
Et même une entreprise comme Zenika n’a pas les moyens de mettre en oeuvre cette évaluation.
Pour conclure, si on cherche les failles permettant de mieux travailler, il y en a en fait des tonnes.

Ce que nous en avons pensé

En fait, les développeurs génèrent des tonnes de données qui ne sont pas exploitées. Et si Matthieu présente une vision assez pessimiste de la chose (tout est pourri, tout le monde est nul, tout le monde s’en fout), il y a néanmoins un très net gisement de qualité dans la collecte et l’exploitation de ces données, pourvu qu’on respecte les droits des individus.
 

Conclusion

Bien que le CFP ait eu lieu pendant les vacances, les sujets étaient de qualité. Nous regrettons toutefois qu’il n’y ait pas eu de présentation front-end … Mais ça fait partie du jeu.
D’un point de vue pratique, la prise de notes collaborative génère un peu de travail de remise en forme, mais offre néanmoins une vision plus complète de la conférence (tout le monde n’est pas inattentif en même temps, et il y a par conséquent toujours quelqu’un qui pense à noter). C’est une initiative à reprendre, en améliorant peut-être les instructions initiales.