Bonjour et bienvenue dans ces nouvelles épisodes de messages à caractère informatique.
Episode 146 est comme vous pouvez voir aujourd'hui c'est un épisode live.
Live depuis le forum PHP de la FUP à Disneyland Paris en effet.
Et avec moi de Yann Merveillotte, le que Leticia, bonjour Leticia. Bonjour.
Jonathan, bonjour Jonathan. Bonjour.
Jeremie, bonjour Jeremie. Bonjour.
Je pense que comme dans tout épisode on peut commencer par un petit tour de table.
Alors, gardons l'ordre. Leticia, tu peux te présenter un petit peu à raconter ce que tu fais et qui tu es et pourquoi tu es ici aujourd'hui ?
Alors, je m'appelle Leticia Avro, je suis experte pas de SQL et je suis ici parce que hier j'ai donné une conférence
où j'ai défendu le SQL injustement, calomnié et diffamé par les développeurs
où on l'accusait de tous les mots, lenteur, complexité, ancienneté, etc.
et j'ai défendu le SQL en démontrant qu'en fait le problème c'était le manque d'enseignement et de connaissance du langage.
Moi, il n'a pas dit que les problèmes ça les développeurs, mais vous, on reviendra.
Jonathan, qui tu es ? Et qu'est-ce que tu fais ici ?
Je suis développeur, je suis aussi speaker, j'ai monté juste après, c'est sur les workers, les jobs et les erreurs que la plupart des gens font
et que je vois tout le temps, partout, peu importe le langage, donc c'est important de le souligner.
Et sinon, au quotidien, je suis un seigneur d'Eve, un peu architecte, un peu lead,
je veux bien partager ce que je trouve et voilà.
Parfait.
Et aussi je suis sur le pseudo grumfi en ligne.
On mettra tout ça, et Yeremi, qui tu es ? Qu'est-ce que tu fais ici ?
Alors, moi je suis plutôt un 6 an demi à la base, donc je n'ai pas développeur
et je ne suis pas speaker, en tout cas, pas dans cette conférence.
Et donc moi, je suis responsable de l'infrastructure à New Oxiety.
Et donc en fait, je suis là avec toute une équipe, on est 10 quand même, en tout.
Ouais, à être là parce qu'on a beaucoup de...
Et il s'est donné un force.
Ouais, on est mis en force.
Parce qu'on a pas mal de dev PHP, même si on fait aussi d'autres langages, donc c'est une conférence intéressante pour nous d'y participer.
Moi, c'est Horace Bonzalez, si vous suivez les Macis, vous me connaissez.
Moi, mon accent.
Donc, je vous disais que je suis tout à l'heure, la conférence est pas à Disneyland Paris.
C'est un peu étrange, c'est très important de la conférence dans l'Hôtel Marvel de Disney, non ?
Déjà, moi ça m'a permis d'acheter des choses dans les boutiques Disney.
C'est un bon argument.
Ouais, voilà, les boucles d'oreille Captain Marvel, on les trouve nulle part ailleurs.
Et puis, il y a deux ans, j'avais prolongé ses jours avec mes filles et on s'était bien marré.
Donc, ouais, pourquoi pas, je veux dire, pourquoi pas allier l'utile à l'agréable.
En fait, ça, c'était il y a dix-quinze ans, vraiment, le moment où nos SQL, ils en sont revenus.
Parce qu'en fait, le nos SQL a ses cas d'usage, mais la majorité des cas quand même,
on les a résolues dans les années 70 et début des années 80 avec le SQL.
Alors, le SQL n'est pas du tout le meilleur langage pour les bases de données relationnelles,
mais c'est celui qui a gagné.
Veta Max, VHS et tout ça, non ?
Oui.
Donc, maintenant, c'est un standard industriel, un standard de fait.
Et surtout, ce que je voulais démontrer, c'est que je vois énormément d'erreurs faites
par les développeurs et les développeuses qui font perdre énormément en performance.
Et le pire, après, c'est qu'on accuse SQL, on dit, ouais, t'as vu, la base, elle est lente.
Non, c'est pas la base qui est lente, c'est la requête qui est malécrite,
c'est la manière d'envisager le SQL qui est mal fait.
Et tiens, donc, j'aime bien les sujets et les germans polémiques,
mais là, la question est pour de vrai.
Mais aujourd'hui, beaucoup de développeurs n'étouche vraiment plus SQL.
Ils passent par des ORM qui font tout l'imagine d'SQL derrière.
Quelle est ton avis sur ces façons de faire ?
Alors, les ORM de manière générale, moi, ce que je peux dire,
c'est quand je suis appelée chez un client pour un problème de perf,
donc 95 % des cas, il y a un ORM.
Et il en est la cause.
Donc après, je suis jamais appelée quand il n'y a pas de problème.
Donc il y a un petit vieil de pompier, quoi.
On appelle ça les vieils de pompier.
Mais par contre, ce que je vois, c'est que les ORM essayent aussi
d'être agnostiques de la base de données.
Et du coup, ils se focalisent sur un tout petit sous-ensemble du SQL,
alors que le SQL peut faire beaucoup plus de choses.
Et puis après, on a aussi des erreurs d'implémentation avec les N+, un requête,
ce genre de choses dont je parle dans ma conf,
qui sont faites parce que les ORM ne sont pas faits par des experts en base de données, en fait.
Ils sont faits par les développeurs pour les développeurs.
Et je pense que les côtés agnostiques, et pour quelque chose aussi,
des côtés des embas nivellés vers les SQL, la plus universelle,
quelque part, ça réduit la possibilité.
Moi, ce que je voulais dire aussi, parce que je suis assez d'accord
qu'on a un manque de connaissance du côté des devs.
Mais c'est aussi les devs, on ne pense pas toujours,
à aller voir dans les outils qu'on a, si on met en PHP, on a la debug bar,
dans tous les frameworks, il y a des debug bars agnostiques qu'on peut installer.
Et on a des informations sur les requêtes qui sont exécutées,
on a les explain plans, etc.
Et ça vaut la peine de prendre le temps, d'apprendre à les utiliser,
parce que dans ce cas-là, on n'a pas besoin de pompiers, en fait.
Apprendre à les utiliser, là par contre, il y a un courbe d'apprentissage certain
que beaucoup de développeurs ne apprennent pas dans leurs courses
ni qu'ils ne savent pas de l'entreprise.
Je veux dire, les développeurs apprennent l'angage, le framework,
me la vas-de-donnès, c'est toujours moi comme un truc à PHP,
et l'externalité de ton applique, tu fais avec,
au moins dans beaucoup de cas, je n'ai pas vu ce...
l'apprentissage de ces outils, ça arrive par des gens courriers,
un peu plus tard dans la carrière.
Alors moi, je vais laisser la parole à notre experte.
C'est que comme tous les outils qu'on utilise,
parce qu'il y a SQL, mais il y a aussi des choses comme Elasticsearch,
comme du Redis, comme plein d'autres sources externes,
et d'ailleurs, j'en parle dans ma toque,
c'est qu'il faut les apprendre, il faut les apprivoiser,
et c'est pareil pour le framework, c'est pareil pour tous les outils.
C'est un apprentissage constant, et si on ne prend pas le temps d'apprendre nos outils,
en fait, on passe à côté de beaucoup, beaucoup, beaucoup de choses.
Moi, je vous dirais quand même nuancer en disant,
c'est pas forcément de la faute des développeurs,
c'est de la faute des managers,
qui ne laissent pas forcément le temps au développeur de faire les choses.
Je veux dire, quand on met les commerciaux en lit,
et qu'ils disent, cette feature il y en a pour une semaine,
on sait très bien comment ça se passe.
Et je n'en veux pas au développeur de ne pas prendre ce temps,
parce que très souvent, on ne leur laisse pas le temps.
On ne considère pas que la veille technologique fait partie du travail de développeur,
ce qui est une faute énorme,
parce qu'un développeur ou une développeuse qui ne continue pas à apprendre
dans cinq ans sur le marché du travail, il vaut plus grand chose.
Ça, c'est un autre vieil et le vieil,
comme considère que, comme beaucoup de développeurs aient le meilleur métier,
la veille technologique, ça doit être une passion qu'ils font les soirées et les week-ends.
C'est vrai que je suis un peu d'accord, effectivement,
si on ne donne pas au développeur l'occasion de continuer une veille,
ça peut devenir très compliqué.
Nous, on essaie quand même de le faire en l'occurrence,
et on a quand même des problèmes de roquettes SQL, il ne faut pas se lorer.
On a parlé hier, c'est l'exemple que tu as pris dans ta con,
c'est un exemple que moi j'ai vu pour le coup.
C'est qu'on a vu une roquette qui n'avait jamais abouti au bout de 9h30.
Petite roquette.
En l'occurrence, c'était moi parce que j'ai eu l'occasion de voir la roquette,
et si on la voyant, je pense qu'il y a moyen de la changer,
et en fait, quand je l'avais récris, je pense que ça n'a pas duré très longtemps,
et elle a duré deux secondes.
Donc, 9h30 à deux secondes, on risque qu'on peut faire des sacres éboues.
Ça c'est un gamin de performance.
Voilà, c'est un gamin de...
Enfin, 9h30, même pas fini, je ne sais pas si elle aurait l'auraient à moutir un jour.
Mais donc, oui, justement, ça existe,
mais dans tous les cas, quand on est développeur un peu junior,
ça n'est pas forcément toutes les subtilités du SQL.
Evidemment, il faut se former dessus,
et c'est un outil aujourd'hui qui est hyper critique dans nos métiers.
En tout cas, pour nous, à New York City, on a énormément de bases post-Gress,
en l'occurrence.
Donc, c'est très important de savoir quand même maîtriser une partie de ce outil,
et de se concentrer uniquement sur le framework qui fait tout magiquement
au LERM pour nous, c'est pas toujours fonctionnel.
Et si je peux rajouter un truc, on n'arrête pas de dire en ce moment,
l'IA va remplacer les développeurs.
En fait, il faut savoir quand même que l'IA se forme sur ce qu'elle trouve,
et le niveau moyen SQL est extrêmement bas.
Donc, pour être sûr de ne pas être remplacé par l'IA,
il suffit juste d'apprendre un peu de SQL,
et vous serez bien au-dessus du niveau.
Et moi, je voudrais juste complémenter ce que t'as dit.
C'est pas spécialement que les juniors, en fait, même les seigneurs.
Parce qu'en fait, quand on est dans notre quotidien,
quand on est le nez dans le guidon, on ne voit pas ce qu'on fait.
Et c'est souvent là où on a besoin à un moment donné d'appeler des pompiers,
des consultants ou peu importe.
Parce qu'en fait, souvent, on travaille dans le quotidien,
on fait du mieux qu'on peut, on a la pression qu'on a,
et en fait, on ne voit pas.
Et ce qu'il faut, c'est arriver à prendre du recul et se dire,
« Ok, est-ce que j'ai vraiment besoin de mon pompier,
ou est-ce que je peux essayer de faire déjà une partie moi-même,
passer de 9 heures à 2 secondes ? »
Ou alors, parfois, on ne s'en sort pas.
Parce que moi, je vois bien dans mon boulot,
on est pas mal de seigneurs dans mon équipe,
et à un moment donné, on a quand même fait appel à un pompier en SQL,
parce que justement, il y a des choses qu'on ne voyait pas.
Et puis, c'est des problèmes aussi infras,
ce n'est pas que d'Eve, parce que ça arrive aussi,
ce n'est pas chez tout le monde les problèmes.
Donc une fois que les problèmes ont été résolus,
oui, ça a été beaucoup mieux.
On a aussi eu d'AirCat qui prenait un certain temps,
et qui se passait à quelques secondes, voire mille secondes.
Donc voilà.
Mais la réflexion sur la IA et la truffe intéressante de Fetifman,
l'ESQL, c'est parmi ses sous-gelats
qui, comme ils n'y a pas,
ont fait des exemples de qualité,
« Bah les moteurs et mon pâté donnent des résultats de qualité,
c'est sa tendance à boucler la Facilman ».
Oui, en ce qui concerne l'IA, effectivement,
ça dépend vraiment des sujets.
Dans cette conférence, il y a beaucoup de talks IA pour le coup,
qui sont très intéressants.
Mais c'est vrai que selon les sujets,
enfin, moi je suis un peu plus infrat pour le coup,
mais donc il y a des sujets sur lesquels je travaille,
qui sont sur le stockage avec ZFS,
des fêtes systèmes qui sont, entre-qui, moins connues,
et le nombre d'erreurs qui sont en train de faire ce truc-là
est vraiment hyper important.
Et en SQL, effectivement, on l'a également constaté,
les requêtes ne sont pas d'une très bonne qualité.
On a quand même des requêtes qui sont largement améliorables
par un humain qui, pour l'instant,
en tout cas Claude, Jean-Gapétain,
ne sont pas à la hauteur sur l'SQL.
Donc, comme l'a dit C.A.D.,
si vous ne voulez pas vous faire remplacer, apprenez SQL.
Bon, on va faire un petit tour.
Déjà, toi tu ne sais pas trop parler de ton talk,
racontes-nous un peu plus parce que le titre,
ça a l'air intéressant, donc il va falloir expliquer plus.
Le titre exact, parce que j'ai du mal,
c'est JobQ & Event Anatomy des erreurs courantes et pistes de résolution.
Donc, en fait, quand j'ai soumis le talk,
j'ai soumis plusieurs talks,
et celui-là, c'est celui que je soumets toujours un talk,
en mode « oh c'est un sujet, j'y vais et je verrai bien ».
Malheureusement, c'est celui-là qui était choisi.
Conference Driven Development.
Voilà.
Et en fait, à mon donné, j'ai fait un plan avec tout ce que je voulais dire,
et puis je me suis dit, ça me paraît fort long.
Je l'ai mis dans une niya en me disant,
je vais voir ce qui me dit en termes de bullet points
et combien de temps il est steam.
Je tombais sur deux heures et demi.
J'ai 40 minutes.
Question comprise.
Donc, j'ai fait « OK, qu'est-ce que j'élimine ? ».
Je regarde des SQLIAM à produits, c'était pas terrible.
Donc, je suis plutôt retourné sur la description du sujet que j'en ai fait.
Et j'ai été à l'essentiel, en fait, c'est-à-dire,
ce que j'ai vu à travers ce que je fais quand même 25 ans que je fais du PHP,
j'ai regardé tout ce que j'avais vu dans différents workers,
que ce soit parallèles à SYNC ou autre,
qui étaient en erreur, que ce soit en PHP ou dans d'autres langages,
que ce soit du Python, du JavaScript ou que c'est.
Et dès que il y avait des choses qui faisaient planter le worker,
parce qu'on avait oublié de gérer des problèmes de SQL,
des problèmes liés à l'ORM qui s'arrêtent,
parce qu'il y a eu une erreur de concurrence,
des problèmes parce que simplement on n'a pas caché une erreur.
Enfin, des choses qui sont relativement basiques,
mais même si on le répète, on les voit tout le temps.
Et donc, je me suis dit, « On va y aller ».
Et je vais parler surtout de choses comme ça,
en fait, qui fait que les workers plantent, on sait pas pourquoi.
Mais je veux aussi mettre deux, trois petites pistes de réflexion
sur le fait de discuter avec l'infra,
parce que c'est important de leur dire, est-ce que notre worker,
qu'est-ce qui arrive quand il plante ?
Est-ce qu'il faut le relancer automatiquement ?
Est-ce qu'au bout d'un certain temps, il ne faut pas faire quelque chose ?
Être attentif à la manière dont il va s'arrêter.
Et donc, par exemple, quand on est dans un environnement unique,
prendre les signaux pour lui dire de s'arrêter.
Des choses qui, moi, me semblent basiques,
sauf que je ne les vois pas.
Quand j'en discute avec des collègues, on me regarde parfois,
un petit peu, ben oui, c'est évident, mais en fait, ils ne le font pas.
Je ne le fais pas non plus parfois.
Donc, ben oui, c'est en fait tous les mêmes erreurs.
Et donc, c'est l'occasion d'en parler,
puis de voir si ça résonne,
et s'il y a des gens qui peuvent attraper une ou deux choses
pour améliorer leur processus chez eux.
Il y a bien ce type de tolles que retournt d'expérience, comme ça.
Bon, et sinon, vu que c'est un masque,
on va parler un petit peu des news et des souliers
que vous tienne à coeur côté tech.
C'est le moment où Leticia va sortir la longue liste
et qu'elle a préparé, parce qu'elle, elle fait ses devoirs,
elle prépare quoi.
Alors, je vais te laisser soulier la première.
Alors, je voulais parler de Postgres 18.
Il se trouve que hier, Clever a annoncé l'arrivée de Postgres 18
chez Clever Cloud,
ce qui est assez impressionnant,
puisque Postgres 18 est sorti il y a dix jours.
Il est sorti le 25 septembre.
Je le sais parce que c'est même une jour-là,
on a fait un meet-up, on a parlé des nouveautés,
de Postgres 18.
La date était bien avec nous.
On l'avait prévue depuis trois mois,
c'est tombé pile poil,
de serre après la release officielle.
Donc, Postgres 18, pour ceux qui ne savent pas,
c'est une release qui a été préparée
entre mai 2024 et mars 2025.
Puis ensuite, il y a le feature freeze et différentes Béta,
Alpha puis Béta, release candidate.
Et ensuite, la version est sortie.
Cette année, elle est sortie plus tôt,
parce qu'il faut savoir que le projet Postgres n'a pas de deadline,
puisqu'on est tous bénévoles, donc ça sort quand c'est prêt.
Il y a des fois, c'est sorti en novembre,
des fois en octobre, là c'est sorti en septembre,
ce qui veut dire qu'il n'y a pas eu trop de bug
sur la phase Béta et release candidate.
Ce qui est plutôt bon signe.
Ou pas.
Et Tiens, avant que tu nous racontes de nouveautés,
pour se persuader que beaucoup de personnes qui ne s'écoutent
n'ont pas été connaissances là,
comment ça se passe justement les processus de release
pour Postgres, par exemple.
Je sais que chaque proyau,
en fait, c'est un peu différent,
mais vous, tu nous as parlé depuis 2024,
c'est un processus long et bien structuré.
Qu'est-ce qui se passe ?
Alors, le projet Postgres est extrêmement strict.
C'est-à-dire que si le futur freeze est passé,
il n'y aura plus rien qui pourra être ajouté.
Ça, c'est le 1re chose.
C'est-à-dire qu'il n'y aura aucune dérogation.
Même s'il y a une super feature de la mort qui tue,
ça ne passera pas.
Il faut dire que le projet Postgres est sûr,
il n'y a pas de clients, en fait.
Donc ça aide à ne pas avoir de pression.
Pareil sur les mineurs et les majeurs,
vers un mineur, il n'y aura jamais de nouvelles fonctionnalités dedans.
C'est que des corrections de bugs, failles de sécurité, etc.
Donc on ne fait que du correctif dans les mineurs.
Ce qui veut dire que les mineurs sont très safe.
Et bien sûr, il faut lire les release notes pour voir les changements,
mais faire un upgrade de mineurs en Postgres, c'est pas grand chose.
Ça veut dire aussi que les développeurs et développeuses qui nous disent,
« Ah non, mon produit marche que dans tel versum mineur de Postgres,
vous montrez juste que vous ne connaissez pas Postgres ».
Je suis désolée, mais ça veut juste dire que eux,
ils ont utilisé telle version.
Mais en fait, vu qu'il n'y a pas de différence de fonctionnalités
entre les versions mineurs de Postgres,
ça n'a pas de sens, en fait.
La recommandation devrait être,
il faut utiliser telle version majeure et la dernière release mineure de la version majeure.

C'est majeur, une question.
Parce que Wulun, nous, on utilise Maria.
Et à un moment donné, on a eu un souci,
justement, dans une version mineure où en fait, il y avait eu un petit bug fix.
Sauf que ce petit bug fix avait fait péter certains types de stockage.
Si on passait de... Si on avait plusieurs nodes
qui pointaient sur des mêmes stockages ou ce genre de choses,
enfin, c'était une configuration un peu particulière qui arrivait surtout en local.
Mais toujours est-il qu'il n'y a jamais ça du côté de Postgres des trucs.
Ça arrive par accident, mais voilà.
Si, ça est arrivé.
Il y a certaines versions mineures où on les a sorties une semaine après.
On a dit, stop, surtout n'installer pas cette version mineure
parce qu'on s'est rendu compte qu'il y a un problème grave dessus.
Ça arrive, c'est rare, mais ça arrive.
Bien sûr, il n'y a aucun logiciel qui a 0 bugs.
Oh, bon, merci.
Non, non, le process est quand même assez long
et on essaye de le faire bien,
mais personne ne peut dire, j'ai 0 bugs de mon appli.
C'est qui dit ça, je ne le crois pas.
Donc c'est un process très stable qui marche bien.
Donc ensuite, quand on est en release candidate,
en fait, on a la chance avec Postgres d'avoir des entreprises
qui contribuent en Postgres en mettant en prod
des versions beta ou release candidate de Postgres,
ce qui nous permet de tester Postgres sur du gros volume.
Parce qu'il faut savoir, là encore, on est tous bénévoles.
Donc on n'a pas des machines.
Alors oui, on a quand même des builds automatiques de Postgres
sur des fermes de machines pour essayer sur plein d'OS différents, etc.
Mais on n'a pas non plus des volumes de prod énormes.
Et rien ne vaut la vraie prod pour tester.
Voilà, c'est ça.
L'avantage pour ces entreprises, c'est qu'ils sont en contact direct
avec les développeurs de Postgres pour corriger les bugs
qui sont corrigeés très rapidement.
C'est-à-dire qu'ils sont relativement sereins
quand ils passent sur la nouvelle version.
Moi, je ne suis pas dans un Core Team.
La Core Team de Postgres, c'est 7 personnes.
Ce n'est pas forcément les plus grands développeurs,
même s'ils pourront arriver dans un Core Team,
il faut plusieurs années de contribution majeure.
Mais en fait, la Core Team ne fait que de l'administratif.
Il gère tous les problèmes de la communauté.
On a eu un problème de trademarque.
Quelqu'un qui avait déplosé la marque Postgres QL Community,
par exemple.
Donc, c'est quelque chose que la Core Team a géré.
Nous, les développeurs, en fait, sur chaque version,
c'est à peu près une centaine.
Mais c'est très disparaît.
Il y en a qui sont payés par la entreprise à 100 % pour développer
pour Postgres, enfin 100 %.
Même pas, disons, 80 % et 20 % du temps,
ils font du support en interne pour les équipes.
Et puis, il y en a comme moi, des fois,
c'est le week-end le soir.
Donc, forcément.
Et en fait, ce qui est très cool dans la communauté,
c'est si on n'a plus le temps de travailler sur un patch,
il n'y a aucune pression.
C'est vraiment la pause parce que je ne peux pas.
C'est cool de voir des communautaires pensant
ce qui garde cet esprit-là.
C'est clair.
D'ailleurs, c'est quelque chose,
il faut bien se rendre compte quand il y a des projets open source.
Il faut vous dire que la plupart du temps,
à part s'il y a des enjeux financiers derrière,
c'est des gens qui font ça sur leur temps libre.
C'est très rare d'avoir des gens qui sont payés.
J'en suis bien à preuve puisque, actuellement,
je suis le seul mainteneur sur l'infrairement aux États-Unitaires
qui s'appelle Atom, qui est infrairement aux États-Unitaires en PHP.
Et j'ai plus le temps.
Ça fait plusieurs années que j'ai plus le temps.
Et c'est vraiment compliqué parce qu'on a envie d'avancer.
C'est d'ailleurs un problème en open source de manière générale.
C'est quand on a un produit qui est amendonné avec plus de gens,
puis il y a moins de gens, puis il y a nouveau plus de gens.
Mais ce n'est pas toujours évident de suivre.
Et plutôt que de râler parce que quelque chose n'avance pas.
Prenez du temps sur vous pour venir contribuer.
Et contribuer, ce n'est pas nécessairement juste
corriger des bugs ou ajouter des nouvelles fiatures.
C'est essayer de comprendre un bug et de donner un cas reproductible.
C'est venir documenter ce qui existe.
Éventuellement refactorer la documentation.
Si vous êtes designer front-end, venir proposer des nouveaux designs.
C'est venir parler parce que parler d'un outil open source,
ça fait toujours plaisir.
Et puis voilà.
Et la plupart des produits open source que vous allez trouver,
vous pouvez poser des questions aux contributeurs.
En général, ils sont faciles d'accès.
Et ils seront très heureux de vous proposer des choses à faire
parce qu'on n'a pas assez de gens qui contribuent.
J'ai l'impression qu'avec le temps, ça diminue le nombre de contributeurs
par rapport à il y a 20 ans.
J'ai vraiment l'impression qu'il y a une baisse de participation dans l'open source.
Ça, je ne sais pas trop dire.
Qu'est-ce que tu penses ? Tu trouves qu'il y a une baisse de...
Moi, ça fait seulement...
Il doit partir à son tour, il a eu une super excuse.
Bon courage !
Moi, ça fait seulement depuis...
Alors, j'ai rejoint la communauté en 2009,
mais ça fait seulement depuis 2017 que je contribue réellement.
Donc, je n'ai pas vu un changement à ce point.
Ce que je vois, c'est que la communauté poserait vieillis.
Ça, c'est sûr.
Je me sens le voir aussi dans le plein de communautés,
dans des meet-ups, dans des conférences.
Moi, je vois que dans plein de meet-ups,
moi, j'avais démarré, il y a un sang avec le Yavayuse group,
qui n'avait pas eu l'impression en France.
Bah, je vois toujours les mêmes gars et filles qui ont voyagé avec moi,
qui ont un message.
Et la moyenne des publics, ça continue à être mon âge se fout.
La moyenne des publics monte avec moi.
C'est vrai que c'est tout dans les conférences.
Il y a une moyenne d'âge qui a quand même camonté.
Après, je pense qu'on fait quand même avec Clever,
en l'occurrence, on est parti,
mais nous aussi, on fait quand même beaucoup d'efforts
d'amener des jeunes en conférence qui voient.
Et aussi leur donner envie d'aide speaker.
Moi, j'essaie de pousser les gens.
C'est très bien, c'est un beau chose à faire.
Parce qu'en fait, c'est vrai que...
Moi, j'ai fait quelques tours,
après, je ne suis pas au niveau de la métisserie,
on est à plus de 100.
Mais il faut se lancer, en fait.
Il ne faut pas hésiter.
C'est vraiment si vous avez un sujet qui vous intéresse,
qui vous passionne et qui est lié à l'informatique,
en l'occurrence, par l'open source en particulier,
vous trouverez toujours une conférence qui, dans le sujet,
vous pourrez submiter votre tour,
puis avec un peu de chance, vous serez pris.
Même si vous n'avez pas besoin d'avoir 20 ans d'expérience
dans la techno.
Et pour démarrer, il n'y a pas qu'à la conférence,
il y a aussi les meet-ups,
et c'est donc de garder en vie tous ces meet-ups-là
qui ont de mal à trouver de nouveaux speakers.
Boba, tu avais d'autres news,
et tu avais d'autres...
Vous allez nous parler aussi de ces nouveautés de post-graduit suite.
Oui, alors j'ai essayé d'aller...
Aller essentiel pour les développeurs et les développeuses.
Il y a deux ans, je vais parler des indexes dans Postgres.
Et j'avais dit, attention, quand vous faites un index
sur plusieurs colonnes, les colonnes A, B, C,
dans votre word, il faut qu'il y ait au moins la colonne A.
Par exemple, si on fait word A égale et B égale,
ça va marcher, mais si on fait word B égale et C égale,
comme on a mis l'index avec l'ordre des colonnes A, B, C,
et qu'il n'y a pas la colonne A,
il ne peut pas utiliser index.
Postgres a implémenté le skip scan sur les index bitrives,
ce qui fait que dans ce cas-là, il pourra utiliser cet index.
Ça veut dire qu'on va réduire drastiquement
le volume d'index sur les bases de données,
ce qui veut dire que ce sera plus performant.
Après, on a la close returning,
dont j'ai parlé hier.
La returning, c'est quand on fait une modification,
insert, update, delete, on peut renvoyer les données.
Avant, Postgres 18, on pouvait renvoyer que les nouvelles données,
les données mises à jour ou 10 litres,
renvoyaient les données supprimées.
Maintenant, on va pouvoir renvoyer hold ou new,
notamment pour l'update.
On va pouvoir renvoyer la totalité des données anciennes
et des nouvelles nouvelles au programme.
Ça, c'est super.
Donc, on va pouvoir vérifier ce qu'il a changé
et qu'on est vraiment dans l'opération que l'on voulait, etc.
Oui.
Les colonnes génériques.
Moi, j'adore les colonnes génériques.
C'est des colonnes qui n'existent pas,
enfin, qui ne sont pas stockées.
Mais on va stocker la définition du SQL,
qui est calculée à partir d'autres colonnes de la même table.
Basiquement, il sortait de formules pour calculer une colonne à la volée.

Par exemple, si on stocke dans la base de données la date de naissance,
on va pouvoir faire une colonne générée avec l'âge.
Parfait.
Je vois bien.
Qui sera généré automatiquement sur...
Et qu'on n'aura pas besoin de la faire
nous côté application avec des codes.
Exactement.
Alors après, là, c'est peut-être un exemple trop basique.
Et en fait, on va pouvoir avoir maintenant des colonnes stockées.
Générées stockées.
Ça veut dire qu'on va pouvoir...
Alors, on avait déjà...
Pardon.
Les colonnes générées stockées.
C'est-à-dire justement, par exemple,
si on a une colonne ou pour un produit, on dit qu'on en a importé temps,
on en a vendu temps, on va pouvoir calculer le stock.
Mais là, maintenant, ce qu'on peut faire,
c'est justement, au lieu de le stocker,
si c'est une opération comme l'âge qui change,
bah, tous les jours, potentiellement,
on va pouvoir le faire une colonne générée virtuelle.
Et du coup, c'est pas stocké,
mais on va pouvoir recuter cette donnée
comme dans un select, comme on souhaite.
Nickel.
Et la dernière que j'ai choisi,
c'est l'élimination automatique des self-joins.
Donc les self-joins, c'est les jointures d'une table sur elle-même.
Alors, normalement, c'est une très mauvaise pratique.
D'ailleurs, Marcus Vinnand, qui est une sommetée mondiale,
sur le SQL, dit que les employés doivent se laver les mains
à pouvoir avoir utilisé une self-join.
Et maintenant, l'optimiseur de Postgres
est capable de supprimer automatiquement ses self-joins.
Ok.
Bah, il y a bien l'effet d'avoir parmi toute la liste des nouveautés.
Les nouveautés, je suis assis, comme ça.
Oui, parce qu'il y en a entre 100 et 150, c'est énorme.
Je vais profiter quand même d'une nouveauté que moi,
je connaissais dans Postgres,
et je suis très content que la version 18 soit sortie,
parce que ça va m'aider à rédiger ma confesse pour Riga.
C'est en fait, il y a aussi des...
Alors, c'est plutôt côté un frappement le coup,
mais on a des statistiques améliorées concernant tout ce qui est vacuum.
Et donc, tous ceux qui ont fini Postgres sont peut-être eu un jour
à se dire que c'est le vacuum, ça fait pas ce que je veux.
Il y a quelque chose qui n'a pas, ou comment ça marche,
je comprends rien.
Donc, en fait, dans Postgres 18,
maintenant, il y a plus de statistiques sur ce qui se passe vraiment
dans l'auto-vacuum et ce genre de choses comme ça.
Donc, ça, c'est une des features que j'attendais avec impatience.
Et donc, on commence aussi à déployer du Postgres 18 en production.
C'est cool.
Donc, Postgres 18, on a fait un petit tour.
Est-ce que vous savez de...
Je sais pas, des projets, des soutis,
des découvertes, c'est d'en y attendre que vous voulez nous parler ?
Oui, alors effectivement,
je n'avais pas mal réfléchi à cette question.
Et il y a un projet qui me tient particulièrement à cœur,
c'est InCas.
Alors moi, je ne suis plus si s'admire que développeur.
Mais ça fait plus de 15 ans que je travaille chez des auditeurs logiciels.
Donc, je connais très bien les développeurs.
Regarde ça.
Et donc, en fait, il y a une petite open source
qu'on utilise dans notre infrastructure.
Donc, c'est en fait un fork de LXD,
même son ancêtre est LXD.
Donc, ça, il y a beaucoup d'historique.
Mais c'est un outil qui permet de faire une plateforme de cloud entière.
Nous, on l'utilise depuis très longtemps,
on va parler de ces déclinaisons LXD, tout ça.
Et en fait, ça permet de faire des conteneurs systèmes,
qui ne sont pas forcément des conteneurs comme Docker, on l'entend.
Ça fait un peu...
C'est interagique.
Enfin, c'est comme une VM, en fait.
Sauf que c'est un conteneur.
Et aussi de faire des machines virtuelles, tout ça.
On a tout un système de clustering qui existe.
On peut même faire tourner du Windows,
vous voulez, ça fonctionne aussi.
Même si nous, on l'utilise essentiellement pour faire tourner des Linux.
Donc, c'est un projet open source pour installer sur plein de distribs.
Et donc, voilà, c'est bon, oui, tu es volé.
T'as oublié de dire que ça permet de remplacer VMware ?
Oui, alors...
Ça, c'est un argument.
Oui, alors c'est vrai qu'il y a eu une petite augmentation de prix de VMware.
Donc, c'est vrai que beaucoup d'entreprises ont cherché des alternatives.
En nous, on a déjà mette l'entité à LXD, donc on a un peu eu trop ce problème.
Mais il y a eu beaucoup de sociétés qui ont cherché des alternatives.
Et que sur, c'est encore, c'est pas fini, les mouvements,
Broadcom n'a pas encore fini de...
De perdre tous ses clients ?
Oui, c'est ça.
Il reste quelques ans, enfin, bien entendu.
Oui, alors il y a plein de projets qui sont un petit peu revenus sur la brèche.
Et aussi, il y a eu Xen, aussi, qui a eu un gain de popularité,
enfin, un gain de popularité depuis VMware à commencer à monter les prix.
Après, il y a d'autres projets comme des genres open stack.
Donc, pour le coup, open stack est quand même un projet qui est plus complexe à mettre en oeuvre.
Il faut une plus grosse équipe.
Il y a Proxmox, aussi, qui sont d'autres outils de virtualisation.
InCus, lui, vraiment, sa particularité, c'est qu'on est avant tout sur du container system.
Donc, ça fait une densité bien plus élevée que des VM, en fait.
Parce qu'on utilise le carnel de l'host.
Et donc, pour ça, c'est très intéressant.
Il y a aussi, pour nous, au niveau stockage, ça peut utiliser les ADFs.
Donc, pour nous, c'est très intéressant parce que c'est un système de fichiers
qui checksempe chaque bloc.
Donc, on est au minimum des corrections.
On utilise aussi SIF.
Enfin, c'est vraiment un système très complet.
Nous, on l'utilise sur plusieurs data centers,
avec un cluster par data center et des interconnectes entre les clusters.
Donc, ça nous fait une availability zone, en fait, qui est entièrement construite avec ce système.
Donc, super projet à crecer, Carmen.
Et en fait, Jeremy, parce que c'est rare de voir un sysadmin dans notre podcast.
En tant que sysadmin, un podcast comme Lemassie qui parle plutôt au DEF,
En quoi peut-il s'intéresser ?
Alors effectivement, pour moi, c'est très intéressant parce que
je travaille avec des DEF tous les jours.
Donc, là, on est au formes PHP.
Donc, on a des DEF PHP, mais on a aussi DEF Java ou dans d'autres techno, du Python.
Pour moi, c'est toujours intéressant d'avoir le point de vue des DEFs
pour que nous, en infrastructure, on soit capable de répondre vraiment en besoin,
de voir les tendances, comment ils fonctionnent,
quelles sont les enjeux, même si j'en ai à la maison, évidemment,
mais c'est toujours intéressant d'avoir ce point de vue-là.
Et aussi, on voit des fois où il y a des petits...
On n'est pas assez alignés, ou on se rend compte que l'infra a ses propres enjeux.
Et donc, pour qu'on travaille tous ensemble correctement,
il faut quand même se dire, OK, ça, c'est mon enjeu infras.
Pour moi, c'est super important, mais pour un développeur, c'est moins important.
Donc, il faut vulgariser, il faut réussir à trouver une abstraction
qui fait qu'on peut mieux travailler ensemble.
Pour moi, c'est pour ça que c'est très intéressant.
Et qu'est-ce que tu penses de tous les movements, de Vops, de tous les côtés ?
Mélanie de DEF et de SOPS de plein de façons différentes.
OK, alors, ouais, effectivement, j'ai mal d'avis là-dessus.
En fait, nous, on a des développeurs vraiment très talentueux qui sont vraiment...
J'ai précisé beaucoup, attention, si je commence comme ça, souvent, il y a peut-être un M.
Il y a un M, il y a un M, il faut le faire d'arriver.
Voilà, donc, ils sont vraiment des experts dans leur domaine.
Mais, voilà, le fameux M, ça reste des six admins, on va dire, moyens au mieux.
Et donc, en fait, je sais que la movements de Vops, c'est une movements très importante.
Mais des fois, on se retrouve donc avec des architectures qui sont...
Enfin, ils essaient de faire du FN, système et réseau, ils font...
Bah, avec leur connaissance, c'est beaucoup moins important.
Et au final, on se retrouve avec des aberrations qui arrivent,
où vraiment, ça n'avait aucun sens et on a des erreurs qui, pour nous, sont grossières.
Donc, évidemment, on a toujours envie de se dire,
oui, on arrivera à faire sans infra, quoi.
On fraque en quelle aidelle et 100%, on arrivera à tout faire.
L'arité, c'est que ça peut marcher.
Si on a condition de mettre des machines, de mesurer.
Non, parce que c'est...
Sur un malentendu, ça peut marcher.
Je prends souvent cet exemple, mais dev, ils sont vraiment des experts.
Et donc, en fait, à un moment, il y avait un bug.
Et donc, en fait, leur solution, c'était, on va se dire, mettons 10 fois plus de machines.
Oui, effectivement, c'est vrai qu'en mettant...
Alors, d'un moment, normalement, ça ne marche plus de toute façon.
Mais c'est vrai que c'est souvent...
On dit, si mettons plus de machines,
de toute façon, les machines coûtent moins cher que de recruter plus de dev.
Donc, pas besoin de fixe le code, on va juste multiplier l'infrastructure par 10.
Alors, ça ne marche pas, ça ne tient pas sur la durée.
Et effectivement, c'est là, on voit que même si on dit qu'on a plus d'eninfra,
on a quand même besoin de gens comme moi,
qui savent de quoi ils parlent pour optimiser ça et travailler en bonne intelligence avec les développeurs.
Je l'ai rajouté quelque chose, c'est les développeurs ont toujours été tenus loin de la prod.
Donc ils ne savent pas ce que c'est.
Eux, ils n'ont pas les appels à 2h du matin.
Et surtout, en termes de sécurité, je ne confierai pas ça à un dev.
C'est là où j'ai vu les pires aberrations, des bases de données ouvertes sur Internet,
entre autres, enfin, ce genre de choses.
Ce n'est pas des infras qu'on fait ça.
Ça, c'est la première chose.
La deuxième chose, c'est le DevOps.
Au départ, l'idée est bonne, c'est-à-dire de travailler ensemble pour aller dans la même direction.
J'adore l'idée.
En fait, ce qui s'est passé, c'est que les Ops ont appris à développer.
Et en plus, ils ont appris à développer uniquement pour automatiser ce qu'ils faisaient avant,
alors qu'ils automatisaient déjà.
C'est juste que c'était en bâche maintenant, c'est en piton.
Mais en fait, c'est juste un changement de langage pour l'infra.
Et en fait, ce qu'on appelle des DevOps, c'est juste un nouveau nom pour l'infra,
mais on adore le marketing dans l'informatique.
Ça, c'est clair.
Et bon, et ça, c'est le cédé côté,
tout imparti des développeurs, les développeurs d'infrastructures.
Les gens qui codent justement des infrastructures,
qui ne sont pas...
Parce que quand on parle des développeurs,
on fait plus tôt référence aux développeurs applicatifs dans cet exemple-là.
Je n'ai pas eu le clavier clavaud dans la plaine des développeurs d'infrastructures,
qui ont fait une fête à la fête de matin.
En fait, justement, Leticia dit très bien,
un truc, c'est qu'on a maintenu pendant longtemps le développeur très loin de la prod.
Quelque part, ça a rangé tout le monde,
ça a rangé le développeur qui n'avait pas de conséquences de...
Ça a rangé aussi la prod qui n'avait pas besoin de former le développeur
à la prod.
Et quand un développeur, il travaille sur de la prod,
il l'appelle à dessert de matin,
et transman,
quand il est nouvelle feature à faire,
c'est le premier à dire,
« Non, mais peut-être on va vérifier avant de l'affaire ».
Ça change la perspective.
Quand il commence à avoir des destrantes,
des appels,
de l'infrastructure à maintenir,
ça change les points de vue énormes, man.
Oui, c'est clairement vrai.
Après, je parle essentiellement de développeurs de logiciels clients,
en l'occurrence,
on travaille beaucoup avec les professionnels de la santé.
Effectivement, ce n'est pas des développeurs qui font de l'infrastructure.
Mais vraiment, on essaye de...
Non, forcément, de les tenir loin de la prod.
Il y en a certains qui ont quand même des accès pour des bugs,
genre de choses.
Et puis on leur donne des outils aussi de monitoring,
ou de pour lire les logs.
Mais en fait,
on veut surtout optimiser leur temps.
En tant que développeur,
il y a beaucoup de temps qui est lié à...
Alors, contrairement à ce que certains croient,
un développeur passe pas toute sa journée à cracher du code,
non sans cesse,
mais il y a beaucoup de temps de réflexion,
d'architecture, etc.
Mais bon, c'est le métier de développeur qui veut ça.
Et donc, on n'a pas envie de les polluer
avec des problèmes purement infrastructures.
Alors, on peut.
C'est des plein de boîtes qu'ils le font.
Mais donc, pour le coup, est-ce que c'est leur passion ?
Est-ce que si...
Ça dépend si ça fait sens.
C'est un cloud provider qu'on nous a fait sens
avoir des développeurs d'infrastructure.
Dans d'autres boîtes, ça fait pas sens de tout.
Ça, c'est clair.
Moi, je voulais dire, on a le même problème
d'imposeres avec les gens qui contribuent le plus à poseres.
Mais ils n'ont pas le temps d'être proches de la prod.
Et du coup, à Montréal, on a été à la unconference.
Donc, les unconferences, on choisit des sujets au départ.
Et on en discute ensemble pour qu'il y ait des feedbacks
de la communauté sur l'importance des features, etc.
et comment les développer.
Et j'étais dans cette salle où il parlait
de comment s'il y avait des workers d'autovacoum
qui étaient au repos, les utiliser
pour paralyser l'autovacoum sur une grosse table.
Et il y a quelqu'un, un développeur, qui a sorti.
Ça ne sert à rien parce que de façon,
on a le partitionnement qui suffit de partitionner à table
et ce sera automagiquement paralysé.
Et là, je fais mes « qu'est-ce qu'on fait de tous les cas d'usage
où on ne peut pas partitionner ? ».
Et en fait, ça n'a eu l'idée pas venue.
Et ce qui est encore plus drôle, c'est que…
donc j'ai expliqué ce point de vue pour défendre des gens
que je vois tous les jours qui sont avec des grosses tables
qui ne peuvent pas partitionner pour telle ou telle raison,
en expliquant que nous, de toute façon,
utiliser ces workers qui sont au repos est une bonne idée
et qu'il fallait permettre ce genre de choses.
Et il y a quelqu'un qui était dans le public
qui est venu me voir après en disant « merci,
parce que je suis dans ce cas d'une table énorme
que je ne peux pas partitionner ».
Et en fait, s'il n'y a pas des gens qui sont proches de la prod
qui vont dire au développeur ce qui est nécessaire,
même au développeur infra,
et bien en fait, ils ne vont pas forcément le savoir.
Et le pire, en fait, c'est quand on ne sait pas,
qu'on ne sait pas, on ne peut pas apprendre.
Ouais, c'est vrai que…
Ouais, c'est quelque chose qu'on a vu effectivement dans…
Alors, le projet PostgreS, c'est très grand,
un gros projet.
Mais effectivement, il y a une partie en tout cas
des gros, gros comiteurs, en fait, qui ne font plus…
Enfin, ou je ne sais pas si ils n'ont jamais fait, en fait,
qui ne gèrent pas de prod, en fait.
Et donc, alors, leurs développements sont très intéressants.
Mais des fois, et je…
De mon avis, mais d'hommes du terrain,
ils n'ont pas vraiment d'applications immédiates
pour la majorité des usages.
Donc, ça peut arriver aussi, c'est-à-dire que l'open source,
c'est l'open source.
Donc, si vous avez envie de faire quelque chose
et que ça vous botte, vous pouvez le faire.
Est-ce que ça va vraiment être utilisé après
par la majorité des gens qui sont sur le projet ?
C'est pas sûr.
Ça rappelle aussi l'importance d'avoir dans les projets
des profils divers qui peuvent donner
des points de vue complètement différents.
Et aussi, si vous utilisez une fonctionnalité
et que vous avez le nom de la personne
qui l'a ajouté au projet, dites-lui merci.
Parce que c'est le seul…
Ça s'appelle point important.
C'est un des rares paiements qu'on a
quand on fait du développement open source.
Et c'est vraiment de sa part de savoir
que la fonctionnalité qu'on a développée est utilisée.
Ça, c'est clair.
C'est vrai. Si vous allez en conférence
et que vous rencontrez quelqu'un qui avait une fille
qui en parle, vous allez juste lui dire merci
ou lui une bière, c'est non moins café.
Les idées sont plus qu'ici.
Ouais. Mais bon, si tu les vois en vrai, c'est encore mieux.
Comme tout à l'heure, je n'en ai pas parlé.
Si vous trouvez un comité à me maintenir,
qui maintient une vie, un projet que vous utilisez,
un petit merci. Ça va très loin.
Et souvent, il y a aussi une barrière, je veux dire.
La barrière d'entrée dans le code de PostgreSQL
est quand même un petit peu haute.
Je ne vais pas mentir.
Mais en fait, j'ai une copine qui est une contributrice majeure de PostgreSQL.
Elle est sortie de l'école.
Elle a commencé à codéancer dans PostgreSQL
parce que l'entreprise qui l'a embauché,
l'a embauché pour faire ça.
Et elle a dit, mais si on m'avait dit que c'était dur,
je ne l'aurais pas fait.
Et en fait, c'est ça. C'est toute la naïveté.
Donc il ne faut pas hésiter à retrouver
sa naïveté d'entrefans, à essayer de réparer des choses
ou d'améliorer des choses sans penser,
c'est impossible ou je n'y arriverai jamais.
Parfois, il faut arriver à tuer cette mauvaise voix dans sa tête et essayer.
Alors vu qu'on est dans la gouvernance open source,
je vais revenir quand même,
c'est pas une casse parce qu'il y avait une histoire que j'ai pas nie.
En fait, le projet est un projet canonical.
En tout cas, c'est comme ça, le XD.
Et donc, le fork n'est pas venu pour rien.
Je ne suis pas entré dans le détail,
mais on veut dire qu'il y a un changement de gouvernance.
Et notamment, il fallait signer une charte pour pouvoir comiter dans le code.
Donc voilà.
Et donc, quasiment tous les gros comiteurs du projet sont partis.
J'ai un certain qui travaillait chez Canonical,
qui ne travaille plus chez Canonical pour le coup.
Et donc, maintenant, c'est un conteneur foundation,
si je ne dis pas de bêtises, qui gère le projet.
Donc, c'est pour qu'il soit vraiment 100% open source
et que personne puisse venir verrouiller un projet après coup
qui est déjà arrivé malheureusement sur d'autres projets.
Donc, un peu comme Aksone, Yankee, Silia, Inkan, Sendane.
Voilà. Donc, je le vais.
Vous savez la raison.
Magique, comment ça a-t-il évolué ?
C'est même un projet qui a une des licences les plus permissives,
puisque la licence post-grèce-QL est proche de Yankee.
En gros, déjà, elle tient en moins de 250 caractères.
Et en gros, c'est vous faites ce que vous voulez,
mais vous ne faites pas de procès.
Donc, il serait parfaitement légal de prendre post-grèce et de le vendre.
Et c'est d'ailleurs ce que font certaines entreprises au cloud.
Il y a des très gros qui ont gagné beaucoup d'argent avec post-grèce,
mais c'est légal et après,
je ne trouve pas forcément moral de pas contribuer dans ce cas-là,
mais ça ne pose pas de problème au projet.
En fait, le projet dit, nous, on vous propose ça,
vous faites ce que vous voulez avec.
Et la manière, en fait, dont le projet fonctionne,
ça s'appelle, en français, on appelle ça l'anarchie organisée.
C'est-à-dire que les gens proposent des idées.
D'ailleurs, il n'est pas nécessaire qu'un problème soit posé pour qu'une solution soit proposée.
Donc, les gens proposent des idées et après,
c'est collectivement qu'on décide si on ajoute.
Et il ne faut pas qu'il y ait une seule personne qui dise non.
Si il y a une personne qui dit non, ça veut dire qu'il faut rediscuter.
Après, si on arrive à la conclusion que la personne est vraiment mauvaise soit, etc.,
c'est jamais arrivé, mais je pense que la cortie me tranchera dans ce cas-là.
Mais généralement, ça se passe très, très bien.
J'ai vu des gens discuter et changer d'avis.
Ça, c'est incroyable.
Donc, vous êtes vraiment dans un consensus dur et vous arrivez à l'avoir.
Et on arrive toujours à ce qui est à la fin,
si la future est acceptée, c'est qu'il n'y a plus personne qui est contre.
Après, parfois sur des futures très complexes,
ça devient difficile d'avoir suffisamment de gens qui sont capables de discuter de cette future.
Parce que ça demande du temps, d'investissement.
Je ne sais pas combien de personnes dans le monde sont capables de parler des lagues numas
liées aux architectures modernes de processeurs.
Mais à mon avis, il n'y en a pas beaucoup.
Donc, du coup, c'est parfois difficile d'aller dire aux gens,
je pense que toi, tu peux, donc je voudrais que tu regardes cette future et que tu regardes ce que tu en penses.
Après, il y a d'autres gens qui vont regarder juste le code en disant,
parce que c'est du C quand même, donc on essaye de ne pas avoir de problème de pointeur, ce genre de choses.
Donc, il y a des gens qui vont regarder juste le code,
juste pour voir s'il est safe.
Il y a plusieurs prismes qui vont être faits sur le code.
Et puis, ça me fait plaisir de voir ces détails sur l'investissement que tu as utilisé.
Bon, il y a quoi que ça fait presque une édition,
c'est que vous savez d'autres petits sujets, d'autres troutis, d'autres projets que vous voulez parler ?
Quel projet ?
Alors oui, j'ai créé plusieurs projets,
mais dernièrement, en fait, il y a quelque chose qui me rendait folle dans Postgres,
c'est que quand on veut se connecter à Postgres avec un client Postgres,
donc il y a plusieurs applications clientes.
Bien sûr, PESQL que tout le monde connaît,
mais PGdom, c'est aussi une application cliente, PGRestore aussi, etc.
Et toutes ces applications ont une syntaxe différente pour se connecter.
Oui, il y a bien remarqué.
Et c'est super pénible.
Et alors, j'ai essayé de le changer dans Postgres,
vu que Postgres a à cœur la rétro-compatibilité, ça posait problème.
Et du coup, j'ai créé un projet qui s'appelle PG Lord of the Rings,
un seul pour les maîtriser tous.
Le nom est génial, il est génial ?
C'est un simple script bash parce que je voulais que ce soit portable et utilisable
sur tous les systèmes sérieux.
On oublie Windows.
Sans avoir à installer de trucs en plus.
Moi, il n'y a rien qui m'énerve plus que de devoir mettre des librairies pitons
ou de faire du NPM.
Enfin bref, ça m'énerve.
Alors que là, c'est un pauvre petit script bash que j'ai créé.
La documentation est complète.
Il y a la documentation en HTML et la documentation en Man Page.
J'ai fait des packages, des biens et des redats.
Et l'idée, c'est simplement d'uniformiser la manière dont on accède au client Postgres.
Parfait, vous m'en valissez un lien pour le projet.
Merci, la idée est géniale et le nom est super.
Et donc pour finir la partie la plus compliquée, il va falloir nous faire
une recommandation musicale pour nos auditeurs.
Quelle musique vous avez maintenant en tête ?
Qu'est-ce que vous voulez mettre en tête pour nos auditeurs ?
Alors, il paraît qu'il n'y a pas tout le monde qui connaît le métal de pirate.
Donc, je conseille « Drink » par Elstorm.
Ok, on a notre recommandation musicale.
Merci Leticia, merci Jeremy.
Non, non, c'est bon. C'est une bonne très bien, Elstorm.
Métal de pirate, qui adore l'idée.
Merci beaucoup d'avoir été là.
J'espère que vous savez tout le reste à Moussan.
Oui, oui, toujours.
Merci à vous de vous abonner à la chaîne.
À très bientôt. Au revoir.