IFTTD - If This Then Dev

Pour l'épisode #57 je recevais Kevin Georges K8S - Engineering Manager chez OVH. Kevin était venu nous raconter l’histoire de kubernetes et son apport dans les data-center. Mais pas que ! Car le gain est aussi côté dev. On y parlait forcément DevOps, et la place de K8s dans cette méthode. Kevin nous racontait aussi comment K8s est utilisé chez OVH et par les clients OVH. Avec lui nous plongions en détail sur les use-cases classiques où K8s excelle, et les edge-case qui peuvent se présenter.Continuons la discussion@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)@0xd33d33 (https://twitter.com/0xd33d33)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)

“Kubernetes crée un vrai fossé entre les ops et les dev”Né au coeur de Google, Kubernetes a su se faire une place de choix dans le monde des outils pour gérer sa prod. Ordonnanceur incontournable aujourd’hui, il se confronte malgré tout à sa hype: tout le monde veut en faire, mais ça ne s’applique pas à tous les projets ! Loin de là.  Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s’intéresse à Kubernetes, techno open-source mais créée par Google afin de mieux concilier leurs immenses data-center, leur besoin de haute dispo, et un besoin évident d'efficacité économique et technique.Le D.E.V. de la semaine est Kevin Georges K8S - Engineering Manager chez OVH. Kevin vient nous raconter l’histoire de kubernetes et son apport dans les data-center. Mais pas que ! Car le gain est aussi côté dev. On y parle forcément DevOps, et la place de K8s dans cette méthode. Kevin nous raconte aussi comment K8s est utilisé chez OVH et par les clients OVH. Avec lui nous plongeo

Pour l'épisode #56 je recevais Agnès Haasser, développeuse web indépendante et certifiée Opquast. Agnès est développeuse de longue date dans le web et était venue nous raconter ce qui l’a amenée à s’intéresser à cette certification. Elle nous présentait aussi les 5 piliers de ces règles et des exemples pratiques d’application. Nous évoquions aussi ce que cela a changé dans sa façon de concevoir des sites et coder. Pour en parler je reçois Jihed Othmani, invité de l'épisode #65.Continuons la discussion@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)

“Mettez un attribut ‘for’ sur vos labels d’une checkbox”Nous parlons souvent de l’amélioration des technos, les nouvelles versions, les nouveaux frameworks, les nouveaux langages. Mais la sagesse populaire nous apprends que c’est dans les vieilles marmites que nous faisons les meilleures soupes ! Le progrès ne vient pas forcément de nouvelles technos, il peut venir aussi de meilleures pratiques. Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s'intéresse à la certification Opquast et les règles de codes qui vont avec. Cet organisme, guidé par une communauté, propose un ensemble de règles pour un web meilleur. 5 piliers qui veulent rendre le web plus agréable pour tous, en prenant en compte des sujets d’accessibilité, bien sûr, mais aussi de respect de la vie privée, de performance et d’ergonomie. Il est possible d’être certifié, mais les règles sont accessible à tous. Apprendre à faire mieux est donc possible pour tous. Le D.E.V. de la semaine est Agnès Haass

Pour l'épisode #55 je recevais Sébastien Descamps, Directeur technique, Senior Developer et auditeur Go chez Zenika Bordeaux. Il était venu nous parler de Go, avec son expertise d’audit et ce qu’il en a appris après l’avoir vu utilisé chez plusieurs clients. Nous parlions de la philosophie à l’origine de Go (une histoire de compilation), des usages de Go, des joies à coder en Go et des petits problèmes quotidien. Sébastien nous exposait sa vision de ce langage avec son passé de dev Java, et nous avions pu ainsi les comparer au niveau gestion de ressources (meilleure discussion autour des garbages collector!)Continuons la discussion@seb_express (https://twitter.com/seb_express)@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)

“Go a été conçu pour résoudre des problèmes de Google et Google a de gros problèmes”Facebook a commencé sur PHP puis, à force d’évolutions, ils ont créé une version très différente du PHP, appelée Hack. Apple a créé Swift pour ses applications sur ses divers OS. De son côté, Google a créé son propre langage aussi, pour remplacer le C cette fois. C’est donc une tendance de fond chez les GAFA, quand un outil n’est plus adapté à l’échelle qu’ils atteignent, ils créent leur propre outil. Mais alors, est-il utile d’utiliser ces langages quand nous ne sommes pas un GAFA ? Google a des sujets et des volumétrie que personne d’autre, ou presque, ne connaît. Le Go est-il donc un outil adapté pour tous ? et si oui, pour faire quoi ? Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s'intéresse en particulier au GO. Langage créé par Google, toujours dans sa version 1, Mais que l’on trouve de plus en plus utilisé en dehors de Google. Je cherche à en savoir plus sur ce langa

Pour l’épisode 54 je recevais Anthony le Goas, Directeur technique et Bruno Sabot front-end développeur chez Zenika. Anthony et Bruno viennent nous parler de leurs expériences avec Javascript mais aussi avec tous ces framework. Ils nous expliquent les performances que l’on peut améliorer avec Javascript et comment y parvenir. Quelque soit le framework utilisé !Pour en parler je recçois Laetitia Avrot, invitée de l’épisode 61.Liens évoqués pendant l’émissionPageSpeed Insights, l’outil de Google pour analyser la performance des pages web : https://developers.google.com/speed/pagespeed/insights/?hl=frOutils d’aide à l’optimisation du code JavaScript : https://perf.link/ ou https://jsperf.com/SvelteJS le framework (ou plutôt le compilateur) dont on a parlé pendant l’épisode : https://svelte.dev/Retrouvez tous nos épisodes sur notre site https://ifttd.io/listes-des-episodes/Continuons la discussion@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)@brunosabot (https://twitter.com

“On ne fait plus beaucoup de javascript aujourd’hui. Les développeurs.euses ont surtout des compétences sur un ou plusieurs frameworks”Javascript a connu jQuery, puis AngularJS, puis node, puis vue et react. Autrement dit le petit langage de scripting pour “animer un peu de texte” sur une page a beaucoup changé ! Tellement changé que nous embarquons désormais de vrai framework pour l'exécution du code dans le navigateur client. Mais quid de la performance dans tout cela ? Ces nouveaux framework ne seraient-ils pas qu’un lourd appendice qui améliore les capacités au détriment du temps de chargement ou de la rapidité d'exécution ? Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, nous nous intéressons à la performance du javascript et surtout à ce que l’on doit faire pour gagner en performance. Nous nous posons aussi la question de la nécessité ou pas de gagner en performance, bien sûr !Les D.E.V. de la semaine sont Anthony le Goas, Directeur technique et Bruno S

Pour l’épisode #53 je recevais Rayna Stamboliyska, Head of Data Security chez YesWeHack. Rayna vient nous raconter son parcours bien sûr mais aussi son approche de la sécurité au quotidien. Son travail avec des devs, et des ops, ses déboirs avec des équipes peut formées aux réalitées de la sécurité. Elle partage avec nous aussi ses conseils pour assurer une fiabilité de ses services de la conception jusqu’au run.Pour en parler je reçois Pascal Combescot, invité de l’épisode 58Retrouvez tous nos épisodes sur notre site https://ifttd.io/listes-des-episodes/Continuons la discussion@MaliciaRogue (https://twitter.com/MaliciaRogue) @ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)

“On veut des gens qui ont une expertise sur tout le cycle de vie, que les rôles et responsabilités soient portées par tous. Cela pose des questions de pérennité et de stabilité”Avec la généralisation du tout “as code”, on demande aux développeurs d’assumer un rôle de plus en plus vaste, allant du dev jusqu'à l’ops en passant du coup par la sécurité. Mais avec ces rôles qui augmentent, les responsabilités en font de même. Or, la sécurité étant un élément clé pour la survie d’une entreprise, ce rôle et ces responsabilités peuvent-elles être portées par le dev seul ? Qui doit être en charge de la politique de sécurité et que faut-il mettre dedans ?Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s'intéresse à ce qu’est la sécurité applicative et qui doit en être responsable. Dans un monde ultra connecté, où les gens peuvent être très dépendants d’un service mais aussi une entreprise tributaire du bon fonctionnement de ses services, la notion de sécurité applicati

Un épisode très différent cette semaine, car c’est le 52ème. Ça fait donc 1 an que ce podcast existe. Il me semblait donc opportun de profiter de ce numéro anniversaire pour parler de la veille que nous faisons tous en tant que dev. Que vous faites, vous aussi, tout simplement en écoutant ce podcast… Enfin je pense.Pour l’occasion je ne suis pas seul, je me suis entouré d’autres podcasteurs tech !!Benoit Gantaume de Artisan développeurChristophe Chaudier de Radio DevOpsStephane Beuret e Electro-monkeysThomas Gerardin, aka DamyR, de We speak cloudAnthony Heukmes de The mature developerAllez découvrir leurs podcasts. Les sujets et les angles sont différents, leurs podcasts sont extra, leur format visionnaire. Oui, ce sont des D.E.V. !Liens évoqués pendant l’émissionCommencez par les épisodes suivants : Faites confiance au destin pour choisir parmis les épisodes de Artisan Développeur: https://artisandeveloppeur.fr/podcast/Découvrez la veille évoquée par Radio DevOps https://lydra.fr/rdo-4-comment-organiser-sa-v

Dans l’épisode #51 je recevais Daniel le Berre, chercheur au CNRS et récipient de la médaille de l’innovation en 2018. Daniel vient nous expliquer le problème SAT sur lequel il travaille depuis des années, “Le plus simple des problème difficiles” pour reprendre ses mots. Il nous parle de son parcours, de ce qui l’a amené à vouloir être enseignant-chercheur, ses contributions sur le problème SAT et ce qui l’anime en tant que chercheur.   Pour en parler, je reçois Hugo FarizonÉcouter l’épisode #51 – A la recherche de l’interrupteur perdu – Daniel Le BerreContinuons la discussion@dleberre (https://twitter.com/dleberre)@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)

“C’est un résultat en soit que ça ne fonctionne pas”Quand on parle des métiers de la tech, on parle généralement de dev front, dev back, dev mobile, dev embarqué … Mais on oublie souvent une option pourtant intéressante: chercheu.r.se. Ce métier qui véhicule beaucoup de cliché à pourtant un attrait fort pour les passionnés: c’est une exploration d’une techno, d’un problème ou d’une solution. C’est la possibilité de trouver la meilleure solution à un problème donné, pas seulement la plus rentable. Mais alors que fait donc un chercheur ? Que fait une chercheuse qui a trouvé ? Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s’intéresse au métier de chercheu.r.se en informatique, ce qui occupe ses journées, la répartition recherche et enseignement et surtout les valeurs qui animent ce métier.Le D.E.V. de la semaine est Daniel le Berre, chercheur au CNRS et récipient de la médaille de l’innovation en 2018. Daniel vient nous expliquer le problème SAT sur lequel il

Pour l’épisode 50 je recevais Jacques Ducloy, chercheur et développeur à l’INIST. À 73 ans, Jacques est développeur depuis plus de 50 ans. Jacques vient nous raconter les changements qu’il a pu voir en 50 ans de dev. Les technos bien sûr, mais surtout les comportements. Rien, ou presque, n’existait quand il a commencé. Il fallait donc tout inventer. Il nous explique comment en quelques décennies cet esprit d’innovation s’est perdu pour transformer le métier de dev en métier d'exécutant. Rendant l’évolution de carrière compliquée dans un tel contexte. Il nous raconte aussi comment les choses changent à nouveau avec le retour des passionnés.Pour en parler je reçois Bruno Sabot, invité de l’épisode #54Écouter l’épisode #50 – Etre dev sénior et sénior – Jacques DucloyContinuons la discussion@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https://www.linkedin.com/company/if-this-the

“Dans les années 70 on apprenait et on inventait quand même. Depuis les années 80 on apprends aux gens comment faire sans les laisser inventer”Selon les entreprises à partir de 7 ans d'expérience on devient “dev sénior”. Dans le système français, une carrière dure 6 fois plus longtemps. Donc que se passe-t-il quand on est développeur plus longtemps ? pendant 20 ans, ou même 50 ans ? L’industrie de la tech a-t-elle un problème avec ses séniors ?Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s’intéresse aux séniors. Pas juste les développeurs séniors. Mais ces seniors qui sont encore en contact direct avec le code. Les équipes de dev sont très jeunes. La moyenne d'âge y dépasse rarement 35 ans. Pourtant on ne peut pas tous quitter le métier en vieillissant ! Les technos changent vite, très vite. “Coder nécessite de se tenir à jour” dit-on. Pourtant en 2020 on fait encore énormément de C, de C++ et de Java.  Le D.E.V. de la semaine est Jacques Ducloy, chercheur

“Les 2 valeurs cardinales de l’artisan développeur sont la fierté et l’excellence. Si on ne met pas le pragmatisme au milieu on peut se perdre”Nous pratiquons un métier très nouveau à l’échelle des métiers de l’humanité. Métier très intellectuel et pourtant si proche de l’artisanat. Hyper connecté.e, hyper branché.e, le.a dev vit dans un monde hyper technologique. Qu’est-ce qui nous motive, qu’est ce qui nous rends heureux ? Sommes nous motivé par notre soif de technologie ? Ou au contraire par le désir de créer quelque chose ? Ou encore de participer à un projet qui nous dépasse ?Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, cherche le bonheur. Ni plus ni moins. Qu’est ce qui nous rends heureux, nous, développeurs ? Nous cherchons à comprendre ce qui nous motive, où se situe notre accomplissement et épanouissement professionnel. Et surtout comment nous pouvons insuffler, pour toute notre équipe, cette recherche de la satisfaction et du bonheur au travail.L

“Ce n’est pas que mettre des étoiles dans les yeux. Il y a surtout le côté communautaire, humain. Pouvoir échanger avec les gens”C’est un métier qui a pris beaucoup d’importance ces dernières années. Avec la généralisation des APIs, la multiplication de services qui se créent, le travail de développement constitue de plus en plus à intégrer un ensemble de services. Mais bien souvent la doc ou le tuto ne suffisent pas. Il faut aussi choisir entre les différents produits disponible sur le marché lequel nous allons intégrer. Entrent alors en scène les évangélistes, les developer advocates et les DevRel. Ces developpeurs.ses qui représentent une entreprise, un service et participe à une communauté. Quels sont les fonctions de ces devRels ? comment sont-ils perçus en interne ? Qu’apportent-il à la communauté ?Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, met en lumière les devRels et leur métier. Qu’il s’agisse d’un poste dédié, ou d’un rôle assumé par quelques

Pour l'épisode #47, je recevais Loïc Etienne, fondateur de MedVir. D’abord médecin urgentiste puis créateur de la plateforme sur minitel 36 15 Ecran santé en 1987, Loïc a très vite pris le parti d’inclure l’informatique dans le diagnostic. Il vient nous raconter ces 30 années passées à concevoir, petit à petit, l’intelligence qui est derrière MedVir. D’abord un travail manuel via le minitel, puis automatisé aujourd’hui, MedVir réplique le travail mené en consultation avec une compréhension du malade. Loïc nous raconte comment son modèle s’est construit et comment MedVir est aujourd’hui intégré et perçu par les médecins et patient.Pour parler de cet épisode je reçois Daniel Le Berre.Ecoutez l'épisode #47 - De Dr House à Dr Smart-house - Dr Loïc EtienneContinuons la discussion@drLoicETIENNE (https://twitter.com/drLoicETIENNE)@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https:/

“Partir de 1 millions d’expressions de malades pour arriver à 380 symptômes possibles ”Les avancées de l’IA nous promettent un médecin plus intelligent, plus efficace et qui ne laisse rien passer. Mais avant que l’intelligence en médecine puisse être artificielle, il faut passer par de l’humain. Les capteurs devront fortement se multiplier avant de pouvoir se passer de la compréhension des symptômes par le malade. Alors comment peut on sereinement diagnostiquer un patient avec de l’IA aujourd’hui ? Qu’est ce qui a déjà changé ? Quel chemin reste-t-il à parcourir ?Ce nouvel épisode d’IFTTD - If This Then Dev, présenté par Bruno Soulez et produit par CosaVostra, s’intéresse à la médecine virtuelle. Les progrès dans la guérison et la détection de symptômes ont été colossal depuis plus d’un siècle. Mais le diagnostic, de son côté, reste très humain. Compiler des symptômes, comprendre le propos et les implications de ce que raconte un malade avec ses mots, cela reste la force du médecin, son métier. Mais avec l’IA

Pour l'épisode 46 je recevais Frédéric Bordage, créateur de GreenIT.fr, la communauté historique (2004) des acteurs du numérique responsable qui a lancé la démarche d’écoconception de service numérique en 2009 via le Collectif conception numérique responsable. Frédéric était venu nous expliquer où est le véritable impact du numérique, et notre responsabilité dans cet impact. Il nous montrait aussi comment nous pouvons changer cet impact, pour le mieux, et surtout à quelle échelle il faut agir pour que cela ait une influence.Pour en parler je recois Mathilde Lemée, l'invitée de l'épisode #62.Ecoutez l’épisode complet #46 – De l’ordinateur beige au numérique vert – Frédéric BordageContinuons la discussion@greenIT (https://twitter.com/greenit)@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)Discord (https://discord.gg/FpEFYZM)Facebook (https://www.facebook.com/ifthisthendev/)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)