Malgré mes 8 ans révolus d'expérience et ma veille continue, j'en apprends encore tous les jours. Merci Julien d'avoir mis des mots sur des concepts que je connaissais, et d'avoir raffraîchit ma mémoire avec des exemples concrets. L'une des meilleurs conf à ce sujet (IMO).
Pas fantastique cette intervention de Mr Nitot, il a un peu tourné toutollogue. Du coup sa présentation des enjeux climatiques est correcte mais sans plus (c'est un peu le pb quand on n'est pas spécialiste du domaine). Les saillies sur le nucléaire sont du niveau greenpeace. Et puis surtout, le gros problème du talk c'est qu'en pratique les gens s'échinent à optimiser depuis toujours, et même aujourd'hui. D'ailleurs on comprend un peu en creux qu'il s'agit d'optimiser les performances brutes de l'application, mais dans certain cas c'est peut-être plus malin d'optimiser la maintenabilité (direction qui a été prise depuis quelques années). Perfs ou maintenabilité, quel aspect il vaut mieux privilégier ? Ben ça dépend ! Une application ultra-optimisée mais difficilement maintenable c'est peut-être plus énergivore si tous les clients doivent la mettre à jour tout le temps. Autre exemple, si les nouveaux applicatifs MacOs ont été plus lents d'un coup c'est à cause des checks de sécu déployés à tous les endroits du code: indolores sur des CPUs costauds, inutilisables sur les plus anciens. Pas évident de statuer sur ce cas: la sécu c'est en trop par rapport au fonctionnel ? Bref, le sujet semble beaucoup plus complexe que ce que présente le talk, et de toute façon l'optimisation c'est un sujet à la marge. Si on veut avoir un impact significatif sur les émissions de CO2, c'est aux usages qu'il faut s'attaquer, c'est ça qui donne le plus de levier.
Merci pour cette présentation Nicolas ! Je trouve la notion de basculement Compose -> Kube super intéressante, et quelques questions me taraudent : - À 1:02:23 quand tu te rends sur l'app port 5735, tu te rends bien sur l'app setup avec Compose ? Le rendu aurait été le même via Kube, ou bien le problème de StorageClass serait-il apparu ? - Si je dispose d'une intégration Traefik dans mon Compose, y a t il un lien de fait avec compose-bridge ? Encore merci pour ta présentation, très belle journée à toi.
Une n-ième présentation sur le thème de l'API versioning... mais pour une fois avec une solution concrète pour appréhender le sujet. Merci pour la clarté des explications et pour avoir imaginer cette solution. 👍👍👍
Seulement 19000 vues et 400 likes sur cette conf alors que tous les gens bossant dans le développement logiciel devraient la voir (plusieurs fois) et la liker. Qu'est-ce que vous attendez ?
Très bonne conférence. Remarques : * Le Time-To-Market n'est pas forcément la priorité des DSI. Quand la DSI est vue comme un centre de cout, respecter le budget et maitriser les risques sont plus importants. Pour mettre au premier plan la livraison de la valeur en continu, le métier et l'informatique doivent travailler de concert. * La taylorisation du métier d'informaticien a fait beaucoup de mal en France notamment et ce n'est pas terminé. Ce mouvement avait été engagé en réaction à la hausse des TJM autour de l'année 2000 (bug de l'an 2000 et juste avant passage à l'Euro). On avait alors posé que le cout d'un projet comme le produit du TJM (Tarif Journalier moyen) et du nombre de JH (Jour-Homme). Pour faire baisser le cout, il faut donc agir sur le TJM (travail des acheteurs) et sur le JH (travail des pilotes de projets). Également, on joue sur le mix-profil pour réduire la séniorité de l'équipe et faire encore baisser le TJM. Ce modèle est imparable sur le papier, sauf qu'il suppose que la productivité est constante. Et c'est là que le bât blesse ! * La performance ne se réduit pas à l'accumulation de JH. l'informaticien en tant qu'ingénieur polyvalent et évolutif peut développer une forte productivité (d'un facteur pouvant aller de 1 à 10 ou de 1 à 20, selon les études). Le travail en équipe apporte un effet multiplicateur. Cela milite pour des équipes polyvalentes, appuyés par des centres d'expertise. "L'équipe, c'est le produit." * La vidée m'a fait penser à une application de la Loi de Conway. Si on segmente le cycle de vie du projet en plusieurs équipes, chaque équipe va organiser son espace. Et à la fin, le flux de valeur est orthogonal à l'organisation et donc s'écoule difficilement.
Je n'ai jamais compris pourquoi mettre une interface pour un service ou un pojo, lorsqu'on a qu'une seule implémentation dans le projet. A part multiplier la complexité et le nombre de classe par 2, ca n'a aucun interet.
Merci pour cette vidéo ! J'aurai une question, avec l'utilisation d'une base de donnée telle que postgres, à quelle niveau dans l'architecture est-ce qu'on doit gérer l'atomicité des transactions ? Dans une application sans cet architecture généralement on les effectue au niveau des services mais dans notre cas où on veut éviter de mélanger les règles métiers et l'infrastructure base de donnée j'ai du mal à visionner cette partie.
La Loi d'erooM : remplaçons la Loi de Moore par l'optimisation du logiciel par un facteur 2 tous les 2 ans ! Une vidéo de Tristan Nitot sur la Loi de Moore, qui a doublé la puissance des ordinateurs tous les 2 ans, occasionnant ainsi une course effrénée entre matériel et logiciel, et un immense gaspillage en ressources et en énergie sur ces 50 dernières années. Qui n'a pas entendu la phrase "Mon ordinateur est devenu trop lent" ? Bien-sûr que les ordinateurs ne ralentissent pas ! C'est le le logiciel qui est devenu trop gros, trop gourmand. Maintenant que la Loi de Moore s'est heurtée aux limites de la physique, pourquoi ne pas enfin travailler à l'optimisation du logiciel, pour une économie plus circulaire et toujours autant de travail pour l'industrie du logiciel qui emploie nombre d'entre nous ? Je recommande cette vidéo et le billet de blog qui l'accompagne (blog.octo.com/pour-en-finir-avec-la-loi-de-moore/) à toute personne qui s'intéresse à l'impact environnemental des utilisations du numérique. Une vidéo qui est passionnante à visionner grâce aux talents d'orateur de Tristan Nitot, mais qui mérite bien plus de vues (seulement 304 à l'heure où j'écris ceci). Merci à Philip-Dylan Gleonec, PhD qui me l'a faite connaitre !
merci au BreizhCamp de m'avoir accueilli pendant la session 2023 et à l'audience pour son attention et ses questions sur le sujet de la documentation de code et du traçage d'exécution :) Deux liens que je voulais vous partager : - le projet et sa documentation pour tracer l'exécution de votre code Python : github.com/lucsorel/pydoctrace - le diaporama de cette présentation : github.com/lucsorel/doc-tracing (le pdf est versionné à la racine)
![[Rennes DevOps] Docker Compose est mort, vive Docker Compose ! - Nicolas De Loof](/img/0.gif)