Je suis méta moderne.

Convalescence oblige, ces 3 dernières semaines, je n’ai pas beaucoup travaillé. J’ai plutôt fait comme tout le monde. Je me suis posé dans mon canapé et j’ai regardé des films (pour les amoureux de lifelogging la liste complète est sur senscritique). L’un d’eux m’a particulièrement marqué. Everything everywhere all at once.

On pourrait penser que pour quelqu’un qui lit du de la science-fiction depuis des années, qui a déjà vu Doctor Who, et quelques autres oeuvres d’univers parallèles, il n’y aurait rien là de nouveau. Pourtant. Je l’ai regardé une fois. Puis une 2e fois. Et puis j’ai regardé cette vidéo de bolchegeek qui m’a éclairé sur la distinction entre le moderne, le post-moderne et le méta-moderne. J’ai enchaîné avec Everyone needs Waymond (parce que j’aime Waymond). Et puis je me suis tapé une comparaison intéressante entre Top Gun Maverick (que je n’ai aucune envie de voir) et Everything everywhere all at once dans Why do movies feel so different now ? avant de conclure par Why everything everywhere all at once hits so hard ?

Et c’est après avoir vu cette dernière vidéo que je me suis fait cette réflexion. Réellement, ce film m’a marqué. C’est arrivé peu de fois dans ma vie. Évidemment, comme j’aime le dire à tout le monde, la première fois que ça m’était arrivé, c’est avec Conan le barbare. Qui, lui, n’est même pas un film moderne. Il y a eu d’autres chocs. Par exemple, Thomas Crown. Mais je crois que ça fait vraiment très longtemps que je n’ai pas ressenti. ce bousculement de mes valeurs. Et heureusement, ces différentes analyses critiques m’ont permis de comprendre ce qui m’avait bouleversé dans ce film.

D’abord, et peut-être de façon cruciale, il y a justement cette approche méta moderne. Si je devais essayer de reformuler ce que j’ai compris de ces différentes vidéos, c’est une histoire de diable qu’on ne remet pas dans sa boîte. En effet, quand on est passé de l’art moderne qui vante l’individualisme, le progrès à l’art postmoderne, on a fait entrer l’ironie dans le jeu. Et l’ironie, on peut la faire rentrer, mais on ne peut pas la faire sortir. Autrement dit et d’une manière un peu plus propre, une fois que vous avez vu le punk, vous ne pouvez plus l’enlever de votre regard. Par contre, ce que vous pouvez faire aussi bien avec l’ironie qu’avec le punk ou avec le nihilisme, et c’est ce que fait ce film, vous pouvez reconnaître que ça existe. Mais reconnaître aussi qu’il est possible de choisir un autre chemin, et c’est peut-être la chose la plus importante à mon avis, de ce film, c’est être capable de dire. Oui, on peut être nihiliste, oui. On peut choisir de dire que. Rien n’a d’importance. Mais on peut aussi choisir de dire que si rien n’est d’importance, je peux choisir ce qui est important pour moi. Je peux choisir de penser que l’amour, la bienveillance a du sens.

Et ça me fait beaucoup de bien de voir que cette tendance méta-moderne est en train de prendre de la force. Parce que si ce film en est un représentant cinématographique évident, je pense que les œuvres de Becky Chambers, par exemple, lui sont équivalentes dans le domaine de la science-fiction écrite. Ce sont des œuvres qui ont intégré les capacités du Cyberpunk à décrire des univers dystopiques, mais ont choisit de sortir de cette dystopie. Et ça me fait du bien.

Convalescent

Il y a un peu plus de 2 semaines, j’ai été opéré d’une rupture du ligament supra-épineux de l’épaule. Oui, ça fait suite à certaines péripéties antérieures. Et si j’aime à dire que « l’esprit n’est qu’un jouet pour le corps », je ne m’en rends jamais autant compte que dans des moments où mon corps prend le contrôle de mon esprit.

Dans ce cas-ci, ce n’est pas un contrôle strict, entendons nous bien, ça n’est pas le sommeil, ça n’est pas l’hallucination, ça n’est pas la drogue, c’est simplement que la douleur vous diminue. Parce qu’en fait, cette opération est somme toute assez simple. Elle consiste à venir prendre le morceau de tendon sain et enlever le morceau de tendon rompu et remettre le ligament en place. Sauf que pour faire ça, il faut raboter quelques os. Et laissez-moi vous dire que les douleurs osseuses font partie de celles qui résistent bien aux antidouleurs (pas vraiment une chance donc). Donc, pendant près de 2 semaines, j’ai souffert. Plus ou moins intensément …

En vérité au début la douleur était suffisamment intense pour que je ne m’en rende même plus compte à quel point elle l’était. Aujourd’hui, je pense souffrir un peu moins. Néanmoins, cette souffrance est encore suffisante pour que ma tentative de participation au dernier contest Codingame se soit soldé par … rien du tout. Non pas que je n’ai pas vraiment envie de réfléchir, c’est juste que entre la main droite paralysée et l’esprit un peu … mou. Je n’ai en fait pas du tout la tête à ce genre de réflexion et ce genre d’optimisation de code rust. Donc je vais laisser tomber cette participation là et me concentrer sur des sujets moins exigeants temporellement et plus capables de m’apporter de la satisfaction (comme une présentation à venir et la refonte de rrss2imap).

Devoxx, c’est déja fini

Après trois jours, Devoxx, c’est déja fini.

J’ai déja noté les conférences auxquelles j’avais assisté, et je voulais dans cet article écrire différentes autres choses.

D’abord, vous rappeler qu’il existe d’autres sites vous racontant leur expérience de Devoxx. J’ai au moins vu le site de Denis Windler, qui propose un article par jour avec des résumés concis et clairs des différentes conférences vues. Stéphane Philippart a écrit un bel article récapitulatif (qui m’a donné envie de voir une ou deux conférences). Antoine Rey a fait 16 prises de notes à Devoxx. Mon ancien collègue Loïc Mathieu a commencé à publier ses articles. Benjamin Dauvissat a écrit un article très concis, mais intéressant. WeScale a recensé une bonne partie des conférences. Une adhérente des DuchessFr a également produit un bel article.

Je voulais ensuite vous parler de l’expérience humaine.

Un truc que j’ai appris avec le temps, c’est que tous les développeurs veulent vous parler de ce qu’ils font.

C’est comme ça que j’ai discuté un peu avec Hervé Boutemy (développeur de Maven), que j’ai gentiment vanné l’excellent Sébastien Blanc. C’est aussi comme ça que j’ai eu une discussion longue et fascinante avec Geoffrey Couprie et Benjamin Coenen (oui, on s’est fait un petit coin rustacé). Et c’est enfin comme ça que j’ai fait mon retour en train avec un collègue développeur de Decathlon. Nous avons pu comparer nos expériences avec intérêt.

Donc quand vous allez à Devoxx, chaque soir, prenez le temps d’aller au Canadian Embassy, ça vous fera une deuxième conférence très chouette

Ne confondez pas : Arnaud Héritier, c’est le barbu !

Le dernier truc, c’est que cette année, pour la première fois, j’étais orateur. Ca claque, non ?

La prétention est maximale …

Bon, en vrai, même sur un sujet que je maitrise (l’architecture as code) et que j’avais présenté à Snowcamp, j’ai eu quand même une pointe de trac tout à fait classique.

Pour l’anecdote, en repartant, je suis passé Gare du Nord devant une fresque parlant de Sara Bernardt et reprenant la fameuse citation

Le trac, cela vient avec le talent

Sara Bernardt

(oui, c’est un peu prétentieux … comme … moi ?).

En tout cas, être orateur, c’est une sacrée fierté, et surtout une sacrée responsabilité. Et j’en suis aussi heureux qu’honoré.

Et franchement, même si c’est un peu de boulot pour moi, quand je voyais courir les organisateurs, je me disais que j’avais vraiment le beau rôle.

Alors bravo à toute l’équipe d’organisation de Devoxx, et j’espère à l’année prochaine (mais il va falloir que je trouve un truc sacrément bien pour être sélectionné).

Devoxx – 1 2 3 Quarkus

Et on démarre avec une démo de Quarkus.

On va prendre une photo, on va la rendre carré avec une cloud function qui publiera la photo dans un topic kafka. Ce topic kafka sera lu par un bout de code qui tourne dans une VM EC2, et on affichera ça à l’utilisateur.

Et on code la cloud function. C’est évidement fait avec Quarkus. Dans ce cas, on utilise les annotations Spring (parce que tout le monde connaît), un repository Hibernate Panache.

Il existe par ailleurs un framework (Funqy) qui vous permet de créer des cloud functions pour tous les providers. Funqy permet par ailleurs d’utiliser Snapstart (le mécanisme spécifique d’Amazon qui permet des redémarrages plus rapides).

Dans les principes de Quarkus, il y a d’abord le frictionless : le framework est conçu pour éviter autant que possible ces éléments qui font perdre du temps. Donc des bonnes APIs, un dev mode efficace, une dev UI vraiment puissante, et la gestion de tous les modes de déploiement.

Il y a ensuite le déplacement d’autant de tâches que possible au build time (ça accélère considérablement le démarrage de l’application). Ca permet dans la démo d’avoir tous les services qui démarrent en moins d’une seconde, et ça permet aussi d’avoir des tailles mémoires de moins de 200 Mo. Et en compilant tout ça en natif, ça va encore mieux. Les temps de démarrage passent sous la seconde, et la consommation mémoire sous les 100 Mo.

Et aussi un coeur réactif : que vous utilisiez du code réactif ou pas, au bout du compte, Quarkus fera du réactif.

Et enfin, il ne faut pas oublier que Quarkus est pensé pour le cloud. Il y a le support de l’observabilité, un design orienté résilience avec les circuit breaker, la capacité de déployer dans du K8s, et beaucoup de sécurité.

Clément explique par ailleurs qu’en quelques années, beaucoup de concepts ont changé dans le monde de l’informatique : K8s bouge régulièrement, les processeurs ont changé (la montée en force d’ARM, par exemple).

Devoxx – Bâtir des équipes d’ingénierie logicielle mémorables

Jean-Laurent est l’actuel VP of engineering chez Docker …​ depuis 7 ans.

Quatre axes pour l’organisation des équipes

  • Les valeurs
  • La topologie des équipes
  • L’impact des managers
  • Le remote

Dunbar a déterminé qu’au-delà de 100/200 personnes, on a de plus en plus de mal à comprendre qui fait quoi (voir aussi The Tipping Point).

A environ 150 personnes, on peut faire entre 15 et 20 équipes agiles. On ne peut plus faire le pompier partout. Et les interactions croissent exponentiellement avec le nombre de personnes. Quand on est 150, ça fait vraiment beaucoup d’interactions possibles. Donc il faut organiser.

Mais comment aligner les gens ?

Les valeurs

Avec qui vous voulez travailler ? Et comment vous voulez organiser ça. Pour les valeurs, Jean-Laurent nous parle d’Extreme Programming. Qui commence avec les valeurs : simplicité, communication, écoute, respect, courage. Et quand Docker a voulu créer des valeurs, Jean-Laurent n’était pas très enthousiaste.

Aujourd’hui, les valeurs sont l’obsession pour le développeur, l’action immédiate mais réfléchie, l’humilité, la collaboration ouverte.

Réfléchissez à comment les définir, comment les mettre en place. Et ça aide vraiment à avancer.

Les équipes

L’unité de base de l’organisation n’est pas le développeur, mais l’équipe. Une équipe doit avoir une mission, et les laisser aussi autonomes que possibles.

Par défaut, dans une équipe, il y a des développeurs, un PO, un designer, et un engineering manager. Le tech lead est l’un des développeurs, et pas un rôle distinct.

Curieusement, les logiciels de RH n’aiment pas ça.

Globalement, les équipes étaient structurées en utilisant la loi de Conway.

Voir le livre Team Topologies, qui a aidé Jean-Laurent a réorganiser tout ça.

En mettant plus d’équipes en « X-as-a-service », on peut faire grandir mieux l’organisation. (voir sur le blog de Docker l’organisation actuelle).

Le dernier point, c’est de bien réfléchir aux frontières des équipes, et ne pas hésiter à itérer.

L’impact

Pour garantir que les contributions de chacun à l’entreprise soient valorisées, il y a chez Docker un career ladder dans lequel il y a un track contributeur individuel à côté du track management. (voir aussi https://levels.fyi).

Pour Jean-Laurent, un senior engineer a déja dix ans d’expérience, et un staff/principal en aura 15/20.

Dans le manager track, on gère d eplus en plus de gens, et en fait on gère surtout leurs problèmes (arrêts maladies, relations avec les autres, …​).

Et il est important que l’impact de ces deux tracks soit équilibré. Et ce qui est cool, c’est que ça pousse les contributeurs individuels à réfléchir à leur impact. De la même manière, les grilles salariales sont équivalentes.

Pour aller plus loin, lisez donc The manager’s path.

Le remote

Notre industrie a énormément changé à cause du confinement : le remote s’est imposé comme une solution qui marche bien. Aujourd’hui, Docker n’a plus de bureaux physiques.

Le remote rend le management beaucoup plus compliqué : comment savoir qui va bien ? Comment percevoir le non verbal ?

Il y a 10 heures de décalage horaire entre les parties les plus éloignées de Docker. Evidement, c’est l’enfer pour se synchroniser.

Allez vous inscrire sur pragrmaticengineer.com, il explique notamment la nature trimodale des salaires dans l’informatique.

Voir aussi « Remote, office not required« .

Devoxx – Writing greener Java applications

On pense que l’aviation est une industrie dévastatrice pour la planète. Mais aujourd’hui, l’informatique produit plus de gaz à effets de serre que l’aviation. On pourrait penser que ça vient des téléphones portables. Mais en fait les data centers à eux seuls produisent l’équivalent d’un pays comme la Grande-Bretagne, et trois fois plus quand on ajoute les émissions liées au réseau.

Holly pense que c’est important de garder de l’optimisme sur notre capacité à changer le monde. Parce que les gens qui pensent qu’on est foutus ne feront rien. Et les gens qui nient le changement climatique ne feront rien non plus.

Donc on peut faire des choses.

Et si on parle de diminuer les émissions de gaz à effets de serre, c’est la bonne chose à faire pour la planète …​ mais aussi pour les entreprises. C’est plus économique. Ca donne un meilleur score « ESG » (je ne connais pas), ce qui à son tour devient avantage compétitif, mais aussi pour le recrutement.

Il existe des tonnes de frameworks pour ça. L’un des premiers est principles.green. Holly a pris les neufs principes et a essayé de les rendre plus compacts.

L’énergie

Première étape, choisir sa source d’énergie (parce que la plus grande partie de l’électricité dans le monde est produite avec du carbon). Il existe un site (Electricity Maps) qui vous indique quelles régions produisent de l’électricité de façon écologique.

Aux Etats-Unis, les gros datacenters sont en Viriginie parce que les ressources électriques sont abondantes et ces datacentes sont donc alimentés au charbon. Pas terrible. Choisissez donc des datacenters au bon endroit. Et choisissez un cloud provider qui expose l’information de la source d’électricité.

Par ailleurs, l’électricite verte est souvent produite avec du solaire …​ qui ne marche donc que la journée. Donc réfléchissez aussi à vos charges de travail (évitez par exemple la nuit batch, qui utilisera plus facilement des ressources non renouvelables).

Essayez de devenir « carbon-aware », parce que ça a un impact sur vos données, votre orchestration.

Les quatre voyelles

Elasticité

Ca doit vous permettre de faire du scale up, mais aussi du scale down, et ça vous fera des économies très importantes (typiquement éteindre les environnements non prod la nuit, c’est bien).

Imaginez qu’en 2017, 25% des serveurs ne faisaient rien.

Mais pour ça, il faut avoir le courage d’éteindre des applications. Pour pouvoir faire ça, il faut plusieurs choses :

  • l’arrêt/démarrage doit être rapide
  • L’application doit fonctionner (idempotente, résiliente)

Holly appelle ça le LightSwitchOps (et le terme est génial). (voir aussi la présentation sur DailyOff)

Efficience

Il y a des statistiques sur les langages de programmation efficaces (la fameuse étude qui met C comme le langage le plus efficace). C, Rust et Java sont très efficaces, et Python est apocalyptiquement inefficace (autrement dit, ne faites pas de Python). On suppose généralement qu’un langage compilé est plus efficace qu’un langage interprété, pourtant Java est plus efficace que Go …​

Dans le monde Java, en changeant des paramètres de la VM, on peut notoirement améliorer (ou diminuer) les paramètres.

Et si ça fait autant de différence, est-ce que le framework utilisé n’a pas aussi une importance ?

Et c’est le moment où on parle de Quarkus !

Par contre, vérifier que c’est vrai est …​ compliqué : pour mesurer la production de gaz à effet de serre, on mesure la consomation électrique. Avec une machine physique, c’est possible, mais pas facile à intégrer.

Et surtout, ça ne marche pas dans le cloud. On peut mesurer la charge CPU, et obtenir une idée de la consomation en regardant comment son faites les machines du datacenter. Mais on ne mesurera pas le coût lié à la fabrication du matériel.

On peut utiliser des modèles plus simples.

Holly a imaginé le modèle vrooooom. Reprenons le comparatif des langages : la consomation d’énergie semble liée au temps d’exécution. Donc on peut utiliser ce temps d’exécution comme une approximation.

Par ailleurs, votre facture cloud vous donne aussi une idée de votre consomation d’énergie.

Evidement, ces modèles sont faux. Mais il peuvent vous aider à vous faire une idée.

Revenons à Quarkus.

Clément a comparé les besoins de Quarkus pour faire tourner une charge « réaliste » chez un cloudeur avec ceux de Spring. A priori, on pourrait diviser par deux les émissions en passant à Quarkus (parce qu’on change de taille de VM). Et on voit aussi que Quarkus sur la JVM consomme sur le long terme moins que Quarkus natif, et que les autres frameworks, évidement.

Donc Quarkus réduit les émissions de carbone.

Pourquoi le natif consomme plus ? Parce que le use case du natif, c’est une charge de ttravail faible, des ressources machines limitées, ou un grand taux de redéploiement (le serverless). Par contre, quand la charge est grande, que les processus sont long, ou que la charge de travail est constante, Quarkus sur la JVM sera plus efficace.

Bon, la différence diminue.

Il faut bien comprendre que pour optimiser pour la planète, il faut en fait optimiser la performance. Et l’avantage de Quarkus, c’est que le choix natif vs compilé n’est pas si important : on peut se faire un cluster avec du Quarkus natif et du Quarkus compilé, ça permettra beaucoup plus d’élasticité (typiquement en démarrant des instances natives pendant les pics de charge).

Utilité

Tout ça suppose que votre application est utile. L’exemple typique est celui des gens qui écoutent de la musique sur Youtube : la vidéo est envoyée, mais elle n’est pas regardée. Ce serait mieux de ne pas l’envoyer, non ?

Conclusion

On pense que la performance implique plus de pollution (comme avec une voiture). Mais dans le logiciel, c’est le contraire : plus le logiciel est performant, moins il pollue. Et l’avantage, c’est que ça crée des solutions sans regrets. Par exemple, les datacenters utilisant des ressources renouvelables (Montréal, Stockholm) sont en fait moins chers, donc tout le monde y gagne. Et c’est tout l’objectif d’Holly : nous faire comprendre que le logiciel plus écologique est plus intéressant pour tout le monde.

Devoxx – Biais et balivernes

Les biais

Le cerveau est une vieille machine, qui fournit des moyens de réflexion .. bizarres

  • Des intuitions fortes et immédiates
  • Des émotions incontrôlées
  • Des illusions de perception et logiques
  • Une estime de soi parfois incohérente avec la réalité
  • Une forte sensibilité sociale
  • Et des angoisses (qui elles aussi nous gardent en vie)

La rationalité ne fait pas partie de ces éléments, parce que pour la survie à long terme ça n’est pas vraiment nécessaire.

On va parler rapidement d’intelligence et de rationalité. C’est difficile de définir l’intelligence, et même de la mesurer. Dans l’intelligence, il y a la rapidité et la fluidité cognitive, la mémoire, le langage, l’intelligence émotionnelle. La rationalité, c’est la logique, la cohérence. ca peut être dépendant des valeurs de la personne. En un sens, l’intelligence, ça peut être un gros moteur, et la rationalité un frein qui permet de contrôler ce moteur.

L’esprit critique, c’est la capacité à utiliser sa rationalité pour mieux voir quels sont nos croyances et comment elles influent sur cette même rationalité.

Il faut bien comprendre que la bêtise n’est pas la meilleure explication aux croyances irrationnelles. (voir le codex des biais cognitifs sur Wikipedia – qui est peut-être un peu trop complet)

Dans les grands biais, on trouve

  • Le biais de confirmation (parce qu’on adore être confirmé, ce qui est la racine de la plupart des biais.
  • Le biais du survivant (souvent trouvé dans le monde des médecines alternatives) qui vient du fait qu’on n’observe généralement que les données survivantes.
  • L’effet spectateur où plus il y a de monde à assister à un truc, moins les gens vont agir parce qu’ils vont d’abord regarder les autres. Il faut en fait se forcer à exprimer quand on n’est pas d’accord.
  • La cascade d’engagement
  • L’effet de simple exposition
  • La fixité fonctionnelle
  • L’erreur fondamentale d’attribution : on a tendance à croire que ce qui arrive aux gens est lié à leurs qualités ou leurs défauts, même lorsque ça vient du contexte. Et ça dépend des catégories dans lesquelles on a placé les gens.
  • L’effet Dunning Kruger qui est en fait un biais de surconfiance des gens peu compétents dans un domaine spécifique.

Passons à quelques illusions visuelles qui montrent que notre système visuel fait un peu plus que nous permettre de voir : il interprète les images pour les contextualiser dans un monde en trois dimensions où on ne voit qu’une partie des objets.

Les balivernes

Les balivernes sont des histoires qui appuient sur des biais du cerveau (l’homéopathie, par exemple). Pour Thomas, il y a quatre principes

  1. Ca fait une belle histoire
  2. Si on la tourne bien, ça plaira toujours à quelqu’un
  3. Les balivernes utilisent notre intelligence pour survivre
  4. Et il faut beaucoup plus d’énergie pour réfuter une baliverne que pour y croire

(voir par exemple le film Opération Lune)

Devoxx – Conseils pour hacker positivement sa vie

Est-ce qu’on peut résoudre les problèmes d’organisation avec des outils ? Pas sûr. En tout cas, dans cette présentation en forme de témoignage, Emmanuel nous invite à prendre les conseils qui nous intéressent.

Si Emmanuel dessine son niveau de contribution et son plaisir au travail, ça a bougé dans le temps (avec notamment une partie très basse à un moment). Parce que la même semaine, sa femme va à l’hopital, lui annonce qu’elle veut arrêter la vie à deux (même si ils sont toujours ensemble).

Si on y regarde comme un informaticien, on peut considérer deux côtés : les aléas de la vie sont en quelque sorte des entrées/sorties, et le moral fait partie du firmware. D’une façon que je trouve très marrante, Emmanuel voyait à un moment les émotions comme un vestige et a essayé d’optimiser sa vie. En plus, il semlbe qu’Emmanuel soit un peu pessimiste. Mais tout ça, c’est dans la tête, parce que choisir des objectifs irréalistes, c’est dans la tête, tout comme les scénarios catastrophe dans lesquels on peut se projeter ! Et si c’est dans la tête, ça peut se changer.

De la même manière, on réagit aux événements de la vie de façon interne, et on va en reparler.

En attendant, dans le travail, on a une liste des tâches à réaliser qui augmente en permanence. Autrement dit, on peut choisir celles qu’on veut faire ! Surtout qu’on peut influencer sur cette liste de chose pour trouver ce qui peut être utile, ou impactant (ce qui n’est pas la même chose).

Emmanuel est partisan de longue date de la méthode GTD. Ca lui permet aussi à chaque fois de définir un definition of done pour chaque élément. Il ne faut pas oublier non plus de revoir régulièrement la liste des tâches, pour vérifier qu’elles sont toujours alignées avec ses objectifs.

D’autres personnes utilisent aussi le Personal Kanban. Quelle que soit la méthode que vous utilisez, l’essentiel, c’est qu’elle vous garantisse les éléments suivants

  • Supprimer les enjeux artificiels
  • Garantir que la liste des tâches est complète
  • Revoir régulièrement les objectifs

Attention avec GTD. Parce que la vie n’est pas une suite de TODO. Et en plus, il y a toujours un peu plus de trucs à faire.

Dans ces conditions, comment entretenir sa santé mentale ?

Avant tout, parlons un peu de la pyramide de Maslow (qui est un peu contestée par les psychologues). Pour en arriver à la réalisation de votre potentiel, il faut donc remplir tous les étages de la pyramide.

Et pour comprendre tout ça, il faut aller voir un psy. Pour Emmanuel, aller voir le psy l’a aidé à comprendre certaines règles implicites de son fonctionnement mental.

Emmanuel s’est aussi mis à la méditation de pleine conscience pour comprendre quand son attention s’éparpille. Parce que c’est possible de perdre son attention au moment présent, mais c’est mieux de savoir quand on le fait.

Ca peut aussi aider à séparer les pensées de la réalité, aussi à comprendre les croyances limitantes et surtout à se comprendre soi-même.

Emmanuel recommande le livre « méditer jour après jour » de Christophe André. On peut aussi utiliser des applications comme « Petit Bambou ».

Et en fait se pose la question de l’impact. En particulier dans le monde professionnel. Comment améliorer son impact ? En communiquant, en fournissant une vision, avec de l’empathie, en écoutant. Bref, en travaillant autrement.

En fait, Emmanuel a beaucoup lutté pour accepter qu’il était humain et qu’il se mentait initialement à lui-même.

Enfin, il y a eu du travail sur la communication pour séparer les éléments factuels et les émotions. Et pour ça, Emmanuel a travaillé sur la communication non violente.

C’était une présentation hyper intéressante, courageuse et touchante. J’ai beaucoup aimé.

Devoxx – Jay-Z, musique et signal

Si vous ne connaissez pas, Shazam est capable de reconnaître une chanson en quelques secondes. Et Mousstapha (un jeune collègue) voulait savoir comment ça marche …​ Heureusement il y a un article scientifique qui explique bien l’algorithme. Donc comment ça marche ?

  1. On enregistre un signal analogique
  2. On sample
  3. On extrait les fréquences
  4. On en déduit une empreinte
  5. Et on joue le son (ou on le reconnaît).

Et une note, c’est juste une fréquence spécifique de l’onde sonore. Dans la vraie vie, les notes se superposent, et elles ne sont pas pures. C’est-à-dire que l’instrument de musique produit une fréquence fondamentale et un ensemble d’harmoniques. Comment retrouver les différentes notes ? Grâce à la transformée de Fourier ! Elle nous permet de séparer les différentes fréquences. La transformée de Fourier a un problème, c’est qu’elle ne fonctionne que sur des signaux continus. Il existe donc une transformée de Fourier discrète, qui ne marche pas non plus très bien. Mais il existe aussi la transformée de Fourier rapide, qui est elle utilisable.

Donc pour créer notre empreinte, on prend le signal (encodé en 44.1 KHz qu’on va découper en morceaux de 4096 blocs de donnée. Après un coup de FFT, on aura notre empreinte. Et ça s’appelle même un spectrogramme.

A partir du spectrogramme, on peut retrouver les chansons. Shazam ne fait pas exactement ça, puisqu’ils construisent un système de points d’ancrage des différentes notes.

Tout ça ne marche pas très bien dans les remixes ou les samples.

Moustapha a donc implémenté cet algorithme en Typescript.

Et il teste ça en live avec JayZ et Bruno Mars (oui, en jouant les sons en live, ça ambiance bien). Avant d’enchaîner en ajoutant un nouveau son dans sa base de données avant de le détecter. Donc l’algorithme marche …​ mais moins bien que Shazam, qui marche beaucoup plus vite, dans des environnements bruités. Bon, on peut aussi remplacer les fenêtres fixes par des fenêtres glissantes, qui apporteront beaucoup plus de précision.

Devoxx – Appwrite est-il prêt à éteindre Firebase ?

Mes deux collègues lyonnais viennent nous parler d’Appwrite. Quand ils étaient étudiants, ils faisaient pas mal de projets avec React et Firebase.

A quoi ça sert ?

Firebase est un backend as a service créé en 2011 et racheté par Google en 2014.

Appwrite est une solution open-source auto-hébergée fournissant là aussi un backend as a service. Le développement a commencé en 2019, le projet est reconnu sur ProductHunt.

Mise en place

Firebase

Il suffit de créer un projet sur la console, et de créer un fichier d’authentification.

Appwrite

Appwrite est livré sous forme de 20 conteneurs Docker avec du Traefik, du MariaDB, du Redis, …​

Il existe un conteneur de démarrage qui va lancer tous les autres conteneurs. Il existe aussi un fichier docker-compose.yml configurable avec un fichier d’environnement. Il y a encore des fournisseurs (Digital Ocean ou GitPod) vous livrant une version packagée. Et il existe enfin une version cloud.

Interface

Firebase

L’interface de Firebase est très complète, et assez lisible (tableau de bord, état du stockage, authentification, documents sont accessibles).

Appwrite

L’interface est clairement inspirée de celle de Firebase, mais elle est beaucoup plus simple et « mieux rangée ».

Authentification

Firebase

Firebase fournit une solution d’authentification très complète, avec support de l’authentification par messagerie, téléphone, Google, support de l’OAuth avec Twitter/Facebook/GitHub/Google

En plus, Firebase fournit un modèle d’interface qui fait qu’on peut se logger en 4 lignes.

Appwrite

Appwrite fournit un service de gestion de compte avec 36 providers d’authentification OAuth.

Stockage

Firebase

Firebase fournit deux service : realtime database et stockage principal. Firebase permet aussi de stocker les données offline (et c’est vraiment bien)

Appwrite

Appwrite ne fournit pas le stockage offline. Mais en revanche Appwrite définit un schéma pour chaque collection (avec des types de données pour tous les attributs). Appwrite supporte également le Typescript. Et l’équipe de dév a ajouté hier la capacité de créer des relations entre les attributs de différentes collections.

Stockage de fichiers

Les deux technologies sont très similaires avec toutes les fonctionnalités classiques de gestion de documents. Et dans les deux cas, on peut aussi ajouter une analyse antivirus.

Appwrite fournit toutefois quelques ajouts

  • Des méthodes de téléchargement de fichier pour différents usages (téléchargement, preview)
  • Le choix du mécanisme de stockage de fichier
  • Et on peut faire des manipulations sur les fichiers avant de les exposer (dans l’exemple créer une image ronde).

Cloud functions

Firebase

Elles sont codées en JS/TS et sont déclenchables de multiples façons (cron, requête http)

Appwrite

Les cloud functions sont programmables dans 11 langages différents.

Et tout le reste

SDK

Il y a à peu près autant de SDK d’un côté ou de l’autre, mais pas toujoursles mêmes langages.

Changements en temps réel

Supporté des deux côtés, avec une syntaxe légèrement différente.

Hosting firebase

Le fait que Firebase soit fourni par Google apporte des services complémentaires (histing d’application, machine learning, en tout il y en a 22)

Les plus d’Appwrite

Il existe une API Rest pour piloter tous les services. Comme il y a une API, il y a aussi une CLI qui peut piloter tous les services. Appwrite fournit aussi un support GraphQL pour tous les services (sauf l’authentification).

Prix

Firebase

Il y a un plan gratuit (quand on atteint les limites ça ne marche plus). Au dela, il y a un pay as you go, qui peut parfois entraîner des surprises (même si il est possible de se définir des limites de prix)

Appwrite

Appwrite est gratuit, mais il faut l’héberger. L’instance déployée par les orateurs coûtait à peu près autant que Firebase.

Communauté

Google vend le produit et met en place des événements autour d’Appwrite. Appwrite a un discord (comme tous les projets open-source) très réactif.

Conclusion

Appwrite a toutefois quelques points faibles. Malgré tout, Appwrite est très simple à l’usage, très souple (pour le stockage de fichiers, la base de données, par exemple), et la confidentialité et la sécurité sont mieux gérées.

D’autres alternatives existent

  • Supabase (open-source)
  • AWS Amplify