Podcasts about ESLint

Jemima Abu, Senior Product Engineer at CAIS, joins the podcast to unpack her no-fluff approach to functional programming in JavaScript. From why predictable code matters to how higher-order functions like map and reduce can save your sanity, Jemima breaks down real-world lessons on purity, immutability, and when it's okay to not be a functional purist. Links https://v3.jemimaabu.com https://www.jemimaabu.com https://www.linkedin.com/in/jemimaabu https://x.com/jemimaabu https://github.com/jemimaabu We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Jemima Abu.

Josh Goldberg joins Amy and Brad to unpack the recent ESLint V9 release and its impact on the TypeScript ecosystem. From explaining the nuances of flat config migration to debating the proper separation between Prettier and ESLint, Josh offers practical advice for improving developer workflows. The conversation covers Josh's journey as a full-time open source maintainer, the Open Source Pledge initiative, and best practices for implementing linting in CI/CD pipelines. Plus, Josh shares behind-the-scenes details from the inaugural SquiggleConf event.Chapter Marks00:00 - Intro00:48 - Welcome Josh Goldberg01:06 - Working in open source and getting paid03:10 - The Open Source Pledge04:49 - ESLint V9 and flat config changes07:25 - Migration challenges with flat config09:52 - Understanding ESLint config format11:50 - How most people use ESLint16:20 - Prettier vs ESLint responsibilities18:47 - Conflict between Prettier and ESLint21:26 - TypeScript's role in ESLint25:01 - TypeScript ESLint packages explained27:43 - Linters for other languages29:31 - ESLint in CI/CD pipelines32:03 - Auto-fixing in different environments37:14 - AI's role in linting and formatting41:45 - SquiggleConf discussion44:15 - Conference tooling and Q&A system46:33 - Future SquiggleConf plans47:13 - Picks and PlugsBrad GarropyPick: Philips Hue smart lighting system - Set up Christmas lights with Hue smart outlets for easy control via phone or voice commandsPlug: Brad's BlueSky account - @bradgarropy.comJosh GoldbergPick: BlueSky social network - Appreciates how it feels like early Twitter without spam bots and complicated server setupsPlug: SquiggleConf - Web development tooling conference returning in September 2025Amy DuttonPick: The Inheritance Games (book) - Describes it as an easy-to-read young adult fiction with puzzles, similar to Knives OutPlug: Amy's BlueSky account - @selfteachmeLinksMentioned in the EpisodeTypeScript ESLintESLint v9 migration docsESLint Config InspectorSentry Grave $750k to Open Source MaintainersOpen Source Pledge initiativeSquiggle Conf websitePrisma PulsePhilips Hue smart lightingThe Inheritance Games (book mentioned by Amy)Social Media AccountsBrad's BlueSky account: @bradgarropy.comAmy's BlueSky account: @selfteachmeJosh Goldberg's BlueSky Account: @joshuakgoldberg.comRelated ResourcesESLint Stylistic projectESLint Config PrettierESLint Plugin Prettier"Create TypeScript Apps" project (Josh's tooling package)Awesome ESLint repo (collection of ESLint plugins)Manual to Magical: AI in Developer Tooling: Tobbe's talk on using AI to write code modsNicholas Zakas discussing the ESLint config system on Syntax podcastTools MentionedHuskyLint-stagedCursorBiome and OXLint (Rust-based linters)GitHub Actions

Dans cet épisde en audio et en vidéo (youtube.com/lescastcodeurs), Guillaume et Emmanuel discutent des 15 ans de Go, d'une nouvelle approche de garbage collecting, de LLMs dans les applications Java, dobservabilité, d'une attaque de chaine d'approvisionnement via javac et d'autres choses. Enregistré le 13 décembre 2024 Téléchargement de l'épisode LesCastCodeurs-Episode-319.mp3 News Langages Go fête son 15ème anniversaire ! https://go.dev/blog/15years discute les 15 ans la corrections de gotchas dans les for loops (notamment les variables étaient loop scoped) le fait que la compile echoue si on attend une version de go superieure seulement depuis go 1.21 en parallele de la gestion de la chaine d'outil (c'est en 2023 seulement!) opt-in telemetrie aussi recent Construire OpenJDK à partir des sources sur macOS https://www.morling.dev/blog/building-openjdk-from-source-on-macos/ de maniere surprenante ce n'est pas tres compliqué Papier sur l'aproche Mark-scavenge pour un ramasse miette https://inside.java/2024/11/22/mark-scavenge-gc/ papier de recherche utiliser l'accessibilité pour preuve de vie n'est pas idéal: un objet peut etre atteignable mais ne sera jamais accedé par le programme les regions les plus pauvres en objets vivant voient leurs objets bouger dans uen autre region et la regio libéré, c'est le comportement classique des GC deux methodes: mark evaguate qui le fait en deux temps et la liveness peut evoluer ; et scavenge qui bouge l'objet vivant des sa decouverte ont fait tourner via ZGC des experience pour voir les objects consideres vivants et bougés inutilement. resultats montrent un gros taux d'objets bougés de maniere inutile proposent un algo different ils marquent les objets vivants mais ne les bougent pas avant le prochain GC pour leur donner une change de devenir unreachable elimine beaucoup de deplacement inutiles vu que les objets deviennent non accessible en un cycle de GC jusquà 91% de reduction ! Particulierement notable dans les machines chargées en CPU. Les tokens d'accès court ou longs https://grayduck.mn/2023/04/17/refresh-vs-long-lived-access-tokens/ pourquoi des long access tokens (gnre refresh token) sont utilises pour des short lived dans oauth 2.0 refresh token simplifient la revocation: vu que seul le auth serveur a a verifier la révocation et les clients vérifient l'expiration et la validité de la signature refresh token ne sont envoyés que entre endpoints alors que les access tokens se baladent pas mal: les frontières de confiance ne sont pas traversées refresh token comme utilise infréquement, et donc peut etre protegee dans une enclave les changements de grants sont plus simple tout en restant distribuable histoire des access refresh token et access token permet de mieux tracer les abus / attaques les inconvenients: c'est plus compliqué en flow, the auth serveur est un SPOF amis mitigeable Java Advent est de retour https://www.javaadvent.com/calendar backstage Java integrite par defaut (et ses consequences sur l'ecosysteme) timefold (sovler) Les extensions JUNit 5 OpenTelemetry via Java Agent vs Micrometer analyse statique de code CQRS et les fonctionalités modernes de Java java simple (sans compilatrion, sans objet fullstack dev with quarkus as backend José Paumard introduit et explique les Gatherers dans Java 24 dans cette vidéo https://inside.java/2024/11/26/jepcafe23/ Librairies Micronaut 4.7, avec l'intégration de LangChain4j https://micronaut.io/2024/11/14/micronaut-framework-4-7-0-released/ Combiner le framework de test Spock et Cucumber https://www.sfeir.dev/back/spock-framework-revolutionnez-vos-tests-unitaires-avec-la-puissance-du-bdd-et-de-cucumber/ les experts peuvent écrire leurs tests au format Gherkin (de Cucumber) et les développeurs peuvent implémenter les assertions correspondantes avec l'intégration dans Spock, pour des tests très lisibles Spring 6.2 https://spring.io/blog/2024/11/14/spring-framework-6-2-0-available-now beans @Fallback améliorations sur SpELet sur le support de tests support de l'echape des property placeholders une initioalisation des beans en tache de fond nouvelle et pleins d'autres choses encore Comment créer une application Java LLM tournant 100% en Java avec Jlama https://quarkus.io/blog/quarkus-jlama/ blog de Mario Fusco, Mr API et Java et Drools utilise jlama + quarkus + langchain Explique les avantage de l'approche pure Java comme le cycle de vie unique, tester les modeles rapidement, securite (tout est in process), monolithe ahahah, observabilité simplifiée, distribution simplifiée (genre appli embarquée) etc Vert.x 5 en seconde incubation https://vertx.io/blog/eclipse-vert-x-5-candidate-2-released/ Support des Java modules (mais beacoup des modules vert.x eux-même ne le supportent pas support io_uring dans vert.x core le load balancing côté client le modele des callbacks n'est plus supporté, vive les Futur beaucoup d'améliorations autour de gRPC et d'autres choses Un article sur Spring AI et la multi modalite audio https://spring.io/blog/2024/12/05/spring-ai-audio-modality permet de voir les evolutions des APIs de Spring AI s'appluie sur les derniers modeles d'open ai des examples comme par exemple un chatbot voix et donc comment enregistrer la voix et la passer a OpenAI Comment activer le support experimental HTTP/3 dans Spring Boot https://spring.io/blog/2024/11/26/http3-in-reactor-2024 c'ets Netty qui fait le boulot puis Spring Netty l'article décrit les etapes pour l'utiliser dans vos applis Spring Boot ou Spring Cloud Gateway l'article explique aussi le cote client (app cliente) ce qui est sympa Infrastructure Un survol des offres d'observabilité http://blog.ippon.fr/2024/11/18/observabilite-informatique-comprendre-les-bases-2eme-partie/ un survol des principales offres d'observabilité Open source ou SaaS et certains outsiders Pas mal pour commencer à défricher ce qui vous conviendrait blog de ippon Web Sortie de Angular 19 https://blog.ninja-squad.com/2024/11/19/what-is-new-angular-19.0/ stabilité des APIs Signal APIs migration automatique vers signals composants standalone par défaut nouvelles APIs linkedSignal et resource de grosses améliorations de SSR et HMR un article également de Sfeir sur Angular 19 https://www.sfeir.dev/front/angular-19-tout-ce-quil-faut-savoir-sur-les-innovations-majeures-du-framework/ Angluar 19 https://www.sfeir.dev/front/angular-19-tout-ce-quil-faut-savoir-sur-les-innovations-majeures-du-framework/ composant standalone par default (limiter les problemes de dependances), peut le mettre en strict pour le l'imposer (ou planter) signalement des imports inutilisés @let pour les variables locales dans les templates linkedSignal (experimental) pour lier des signaux entre eux (cascade de changement suite a un evenement hydratation incrementale (contenu progressivement interactif avec le chargement - sur les parties de la page visible ou necessaires et event replay, routing et modes de rendu en rendy hybride, Hot module replacement etc The State of Frontend — dernière compilation des préférences des développeurs en terme de front https://tsh.io/state-of-frontend/ React en tête, suivi de Vue et Svelte. Angular seulement 4ème Côté rendering framework, Next.js a la majorité absolue, ensuite viennent Nuxt et Astro Zod est la solution de validation préférée Pour la gestion de date, date-fns est en tête, suivi par moment.js Côté state management, React Context API en première place, mais les suivants sont tous aussi pour React ! Grosse utilisation de lodash pour plein d'utilités Pour fetcher des resources distantes, l'API native Fetch et Axios sont les 2 vaincoeurs Pour le déploiement, Vercel est premier Côté CI/CD, beaucoup de Github Actions, suivi par Gitlab CI Package management, malgré de bonnes alternatives, NPM se taille toujours la part du lion Ecrasante utilisation de Node.js comme runtime JavaScript pour faire du développement front Pour ce qui est du typing, beaucoup utilisent TypeScript, et un peu de JSdoc, et la majorité des répondants pensent que TypeScript a dépassé JavaScript en usage Dans les API natives du navigateur, Fetch, Storage et WebSockets sont les APIs les plus utilisées La popularité des PWA devrait suivre son petit bonhomme de chemin En terme de design system, shadcn.ui en tête, suivi par Material, puis Bootstram Pour la gestion des styles, un bon mix de plain old CSS, de Tailwind, et de Sass/CSS Jest est premier comme framework de tests Les 3/4 des développeurs front utilisent Visual Studio Code, quant au quart suivant, c'est JetBrains qui raffle les miettes Pour le build, Vite récolte les 4/5 des voix ESLint et Prettier sont les 2 favoris pour vérifier le code   Parfois, on aimerait pouvoir tester une librairie ou un framework JavaScript, sans pour autant devoir mettre en place tout un projet, avec outil de build et autre. Julia Evans explore les différents cas de figure, suivant la façon dont ces librairies sont bundlées https://jvns.ca/blog/2024/11/18/how-to-import-a-javascript-library/ Certaines librairies permette de ne faire qu'un simple import dans une balise script Certaines frameworks sont distribués sous forme d'Universal Module Definition, sous CommonJS, d'ESmodule franchemet en tant que noob c'est compliqué quand même Data et Intelligence Artificielle L'impact de l'IA en entreprise et des accès aux documents un peu laxistes https://archive.ph/uPyhX l'indexing choppe tout ce qu'il peut et l'IA est tres puissante pour diriger des requetes et extraires les données qui auraient du etre plus restreintes Différentes manières de faire de l'extraction de données et de forcer la main à un LLM pour qu'il génère du JSON https://glaforge.dev/posts/2024/11/18/data-extraction-the-many-ways-to-get-llms-to-spit-json-content/ l'approche “je demande gentiment” au LLM, en faisant du prompt engineering en utilisant du function calling pour les modèles supportant la fonctionnalité, en particulier avant les approches de type “JSON mode” ou “JSON schema” ou effectivement si le modèle le supporte aussi, toujours avec un peu de prompting, mais en utilisant le “JSON mode” qui force le LLM a générer du JSON valide encore mieux avec la possibilité de spécifier un schema JSON (type OpenAPI) pour que le JSON en sortie soit “compliant” avec le schéma proposé Comment masquer les données confidentielles avec ses échanges avec les LLMs https://glaforge.dev/posts/2024/11/25/redacting-sensitive-information-when-using-generative-ai-models/ utilisation de l'API Data Loss Prevention de Google Cloud qui permet d'identifier puis de censurer / masquer (“redacted” en anglais) des informations personnelles identifiables (“PII”, comme un nom, un compte bancaire, un numéro de passeport, etc) pour des raison de sécurité, de privacy, pour éviter les brèche de données comme on en entend trop souvent parler dans les nouvelles On peut utiliser certains modèles d'embedding pour faire de la recherche de code https://glaforge.dev/posts/2024/12/02/semantic-code-search-for-programming-idioms-with-langchain4j-and-vertex-ai-embedding-models/ Guillaume recherche des bouts de code, en entrant une requête en langue naturel Certains embedding models supportent différents types de tâches, comme question/réponse, question en langue naturelle / retour sous forme de code, ou d'autres tâches comme le fact checking, etc Dans cet article, utilisation du modèle de Google Cloud Vertex AI, en Java, avec LangChain4j Google sort la version 2 de Gemini Flash https://blog.google/technology/google-deepmind/google-gemini-ai-update-december-2024/ La nouvelle version Gemini 2.0 Flash dépasse même Gemini 1.5 Pro dans les benchmarks Tout en étant 2 fois plus rapide que Gemini 1.5 Pro, et bien que le prix ne soit pas encore annoncé, on imagine également plus abordable Google présente Gemini 2 comme le LLM idéal pour les “agents” Gemini propose une vraie multimodalité en sortie (premier LLM sur le marché à le proposer) : Gemini 2 peut entrelacer du texte, des images, de l'audio Gemini 2 supporte plus de 100 langues 8 voix de haute qualité, assez naturelles, pour la partie audio Un nouveau mode speech-to-speech en live, où on peut même interrompre le LLM, c'est d'ailleurs ce qui est utilisé dans Project Astra, l'application mobile montrée à Google I/O qui devient un vrai assistant vocale en live sur votre téléphone Google annonce aussi une nouvelle expérimentation autour des assistants de programmation, avec Project Jules, avec lequel on peut discuter en live aussi, partager son code, comme un vrai pair programmeur Google a présenté Project Mariner qui est un agent qui est sous forme d'extension Chrome, qui va permettre de commander votre navigateur comme votre assistant de recherche personnel, qui va être capable de faire des recherches sur le web, de naviguer dans les sites web, pour trouver les infos que vous recherchez Cet autre article montre différentes vidéos de démos de ces fonctionnalités https://developers.googleblog.com/en/the-next-chapter-of-the-gemini-era-for-developers/ Un nouveau projet appelé Deep Research, qui permet de faire des rapports dans Gemini Advanced : on donne un sujet et l'agent va proposer un plan pour un rapport sur ce sujet (qu'on peut valider, retoucher) et ensuite, Deep Research va effectuer des recherches sur le web pour vous, et faire la synthèse de ses recherches dans un rapport final https://blog.google/products/gemini/google-gemini-deep-research/ Enfin, Google AI Studio, en plus de vous permettre d'expérimenter avec Gemini 2, vous pourrez aussi utiliser des “starter apps” qui montrent comment faire de la reconnaissance d'objet dans des images, comment faire des recherches avec un agent connecté à Google Maps, etc. Google AI Studio permet également de partager votre écran avec lui, en mobile ou en desktop, de façon à l'utiliser comme un assistant qui peut voir ce que vous faites, ce que vous coder et peut répondre à vos questions Méthodologies Un article de GitHub sur l'impact de la surutilisation des CPU sur la perf de l'appli https://github.blog/engineering/architecture-optimization/breaking-down-cpu-speed-how-utilization-impacts-performance/ c'est surprenant qu'ils ont des effets des 30% de perf c'est du a la non limit thermique, au boost de frequece qui en suit ils ont donc cherché le golden ratio pour eux autour de 60% ils prennent des morceaux de cluster kube poru faire tourner les workloads et ajoutent des wqorkload CPU artificiels (genre math) Sécurité Attaque de la chaîne d'approvisionnement via javac https://xdev.software/en/news/detail/discovering-the-perfect-java-supply-chain-attack-vector-and-how-it-got-fixed s'appuie sur l'annotation processeur l'annotation processors des dependances est chargé et executé au moment du build du projet et cherche les annotations processor dans le user classpath (via le pattern serviceloader) et donc si la dependance est attaquée et un annotation processor est ajouté ou modifié on a un vecteur d'attaque au moment de la compilation du projet ciblé des qu'on deparre l'IDE en gros workaround, activer -proc:none et activer les annotation processors explicitly dans votre outil de build certaines améliorations dans le JDK: le compilateur note qu'il execute un annotation processor dans java 23+ les annotation processors sont deactivés par defaut Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 19 décembre 2024 : Normandie.ai 2024 - Rouen (France) 20 janvier 2025 : Elastic{ON} - Paris (France) 22-25 janvier 2025 : SnowCamp 2025 - Grenoble (France) 24-25 janvier 2025 : Agile Games Île-de-France 2025 - Paris (France) 30 janvier 2025 : DevOps D-Day #9 - Marseille (France) 6-7 février 2025 : Touraine Tech - Tours (France) 21 février 2025 : LyonJS 100 - Lyon (France) 28 février 2025 : Paris TS La Conf - Paris (France) 20 mars 2025 : PGDay Paris - Paris (France) 20-21 mars 2025 : Agile Niort - Niort (France) 25 mars 2025 : ParisTestConf - Paris (France) 26-29 mars 2025 : JChateau Unconference 2025 - Cour-Cheverny (France) 28 mars 2025 : DataDays - Lille (France) 28-29 mars 2025 : Agile Games France 2025 - Lille (France) 3 avril 2025 : DotJS - Paris (France) 10-11 avril 2025 : Android Makers - Montrouge (France) 10-12 avril 2025 : Devoxx Greece - Athens (Greece) 16-18 avril 2025 : Devoxx France - Paris (France) 29-30 avril 2025 : MixIT - Lyon (France) 7-9 mai 2025 : Devoxx UK - London (UK) 16 mai 2025 : AFUP Day 2025 Lille - Lille (France) 16 mai 2025 : AFUP Day 2025 Lyon - Lyon (France) 16 mai 2025 : AFUP Day 2025 Poitiers - Poitiers (France) 24 mai 2025 : Polycloud - Montpellier (France) 5-6 juin 2025 : AlpesCraft - Grenoble (France) 11-13 juin 2025 : Devoxx Poland - Krakow (Poland) 12-13 juin 2025 : Agile Tour Toulouse - Toulouse (France) 12-13 juin 2025 : DevLille - Lille (France) 24 juin 2025 : WAX 2025 - Aix-en-Provence (France) 26-27 juin 2025 : Sunny Tech - Montpellier (France) 1-4 juillet 2025 : Open edX Conference - 2025 - Palaiseau (France) 18-19 septembre 2025 : API Platform Conference - Lille (France) & Online 2-3 octobre 2025 : Volcamp - Clermont-Ferrand (France) 6-10 octobre 2025 : Devoxx Belgium - Antwerp (Belgium) 16-17 octobre 2025 : DevFest Nantes - Nantes (France) 6 novembre 2025 : dotAI 2025 - Paris (France) 12-14 novembre 2025 : Devoxx Morocco - Marrakech (Morocco) 23-25 avril 2026 : Devoxx Greece - Athens (Greece) 17 juin 2026 : Devoxx Poland - Krakow (Poland) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

Show DescriptionHow do you like your turkey at Thanksgiving, building social capital with the neighbors, a brief SportsTalk Show segment, noticing easter eggs in apps and the web, what is a component anyway, CSS parts follow up, and questions about Alpine.JS and ESLint. Listen on Website →Links How to Spatchcock Chicken, a Step-by-Step Guide Half-Life Scott Jehl on Web Components CSS Parts Relief ESLint Sorting Plugin GitLens Biome Sponsors

TypeScript is a superset of JavaScript that adds static typing with optional type annotations. It was created at Microsoft and first released in 2012. TypeScript ESLint enables ESLint and Prettier to run on TypeScript code. Josh Goldberg is a host for Software Engineering Daily, the author of Learning TypeScript by O'Reilly, and a Microsoft MVP. The post TypeScript ESLint with Josh Goldberg appeared first on Software Engineering Daily.

In this panel episode, join our producer Emily and hosts Josh and Paul as they discuss the debate around rewriting JavaScript tools in faster languages, the exciting release of Svelte 5, and the newly introduced Void Zero toolchain. Links Paul Mikulskis https://www.linkedin.com/in/paul-mikulskis-37a50b4a https://www.youtube.com/@SuperSynthguy?app=desktop Josh Goldberg https://www.joshuakgoldberg.com https://twitter.com/JoshuaKGoldberg https://www.youtube.com/@JoshuaKGoldberg https://fosstodon.org/@JoshuaKGoldberg https://bsky.app/profile/joshuakgoldberg.com https://www.twitch.tv/JoshuaKGoldberg https://github.com/JoshuaKGoldberg We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr)

TypeScript is a superset of JavaScript that adds static typing with optional type annotations. It was created at Microsoft and first released in 2012. TypeScript ESLint enables ESLint and Prettier to run on TypeScript code. Josh Goldberg is a host for Software Engineering Daily, the author of Learning TypeScript by O'Reilly, and a Microsoft MVP. The post TypeScript ESLint with Josh Goldberg appeared first on Software Engineering Daily.

ESLint is a static code analysis tool for identifying and fixing problems in JavaScript code. It helps developers maintain code quality and consistency by enforcing coding standards and detecting issues such as syntax errors, stylistic problems, and bugs. Nicholas Zakas is the creator of ESLint. He joins the show to talk about working at Yahoo The post Creating ESLint with Nicholas Zakas appeared first on Software Engineering Daily.

React and JavaScript expert Cory House discusses the creation of custom development tools for React applications, sharing insights from his recent talk at React Rally and exploring how the right tools can shape development workflows and enhance automated testing strategies. Links https://www.bitnative.com https://github.com/coryhouse/ama https://x.com/housecor https://github.com/coryhouse https://stackoverflow.com/users/26180/cory-house https://www.linkedin.com/in/coryhouse https://www.pluralsight.com/authors/cory-house https://www.reactjsconsulting.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Cory House.

ESLint is a static code analysis tool for identifying and fixing problems in JavaScript code. It helps developers maintain code quality and consistency by enforcing coding standards and detecting issues such as syntax errors, stylistic problems, and bugs. Nicholas Zakas is the creator of ESLint. He joins the show to talk about working at Yahoo The post Creating ESLint with Nicholas Zakas appeared first on Software Engineering Daily.

In this Potluck episode of Syntax, Scott and Wes answer your questions, from weighing the trade-offs between numerous small npm packages and a few larger ones to managing the challenges of work-from-home life. They also explore CSS modules, strategies for shrinking JavaScript bundles, and even where to find the best replacement ear cups for your headphones. Show Notes 00:00 Welcome to Syntax! 00:38 Commentating basketball. 01:16 Brought to you by Sentry.io. 02:09 The video podcast doesn't translate well to audio. 04:08 Many small npm packages vs a few large. 09:55 Developers dealing with WFH, ADHD, and kids. 15:59 CSS modules for scoping styles to components. 20:55 Scoped CSS in React? 23:21 Reducing JS bundle sizes. Bundle Phobia. Javascript Bundle Analysis [Beta]. 29:44 Balancing learning, doing, and teaching. 33:04 Making maps local first. 36:20 How to pronounce ‘schema'. Wes Bos Tweet. 37:09 HTML tag. 40:11 Where to get replacement ear cups for headphones? wickedcussions. Scott's Audeze Headphones. 42:21 ESLint and hiding errors. 48:48 Sick Picks & Shameless Plugs. Sick Picks Scott: Allen Wrench Set. Wes: Clarkson's Farm – Amazon Prime. Shameless Plugs Wes: Syntax.fm, YouTube Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

David Neal, developer advocate and Asana content creator, discusses his talk, The Illustrated Guide to Node.js. David shares insights from his 10-year journey with Node.js, discussing its origins, use cases, and why it remains a vital tool for developers, giving insights into JavaScript's evolution and practical tips for navigating the Node.js ecosystem. Links https://reverentgeek.com https://twitter.com/reverentgeek https://techhub.social/@reverentgeek https://staging.bsky.app/profile/reverentgeek.com https://www.threads.net/@reverentgeek https://github.com/reverentgeek https://www.youtube.com/ReverentGeek https://www.linkedin.com/in/davidneal We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: David Neal.

This week we're delighted to have Nicholas Zakas on the show to talk about ESLint. ESLint is a tool that helps you find and fix problems in your JavaScript code by writing plugins that check for patterns in your code's AST. We talk about the history of ESLint, the challenges of building a linter, and the future of of ESLint. https://x.com/slicknet https://eslint.org/ Episode sponsored By MUX (https://mux.com) Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership

Josh Goldberg joins Nick & Chris to discuss the latest updates from ESLint, typescript-eslint & the new flat config format. They also discuss creating reusable configs & project generators before pivoting to talk about a new conference focused on developer tooling. Finally, Chris & Josh talk about the past, present & future of Mocha.

Josh Goldberg joins Nick & Chris to discuss the latest updates from ESLint, typescript-eslint & the new flat config format. They also discuss creating reusable configs & project generators before pivoting to talk about a new conference focused on developer tooling. Finally, Chris & Josh talk about the past, present & future of Mocha.

Josh Goldberg, TypeScript ES-Lint Maintainer, discusses the newest features and benefits of TypeScript ESLint v8, AI in coding, and industry adoption cycles. He highlights the improved performance and type-aware linting feature of TypeScript ESLint v8. They talk about the importance of using proper tools for better coding outcomes, the "trough of disillusionment" in technology adoption, and discuss the Gartner hype cycle. Sponsored by This Dot Watch this episode on YouTube Read more on our blog

Scott and Wes sit down with Vjeux from Meta to dive deep into the origins and evolution of Prettier, the widely-used code formatter. They discuss the challenges faced, the decision-making process behind its features, and what the future holds for this indispensable tool in the developer's toolkit. Show Notes 00:00 Welcome to Syntax! 01:45 Brought to you by Sentry.io. 02:19 New swag! 03:25 Who is Vjeux? 06:56 Is management the key to successful projects? 08:50 The genesis of Prettier. 12:08 Why other JS formatters didn't work. 16:56 Focusing on edge-cases. 17:41 The goal for Prettier. Prettier Philosophy. 18:31 Next step, integrations. 19:37 Should you run Prettier on save or commit? 21:34 Does Prettier's limitations lead to higher adoption? Prettier Config. 25:01 What was the most controversial default setting? 28:14 Does Facebook use semicolons? 29:18 Getting approval to devote 6 months to Prettier. 31:42 Working with Mark Zuckerberg. 32:43 Was there ever consideration to augment ESLint instead? Prettier vs. Linters. 35:34 What are your thoughts on the Rust-based alternatives? 36:44 Prettier's $10,000 bounty. 39:32 What is the future of Prettier? 44:54 Prettier is available in almost every language. 47:59 Advice for other open-source maintainers. 53:26 Sick Picks & Shameless Plugs. Sick Picks Vjeux: TransformersJS. Shameless Plugs Vjeux: Prettier x Syntax Swag. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Welcome back to another episode of Building Better Developers. Today, we're tackling an issue that every developer faces at some point: panic during software delivery. Whether it's a critical bug or a new feature that isn't functioning as expected, panic can strike anytime your software fails in the hands of a user. Rob and Michael cover handling software delivery panic with practical tips and real-life examples. Listen to the Podcast on Handling Software Delivery Panic The Inevitable Bug: Why Panic Happens Delivering software is a delicate process. Even when you've thoroughly tested your code and believe it to be bulletproof, something can always go wrong. Often, the panic ensues because: Unexpected User Behavior: Users may interact with the software in ways you didn't anticipate. This is particularly common in beta tests or early releases where feedback is crucial. Overlooked Bugs: Some users have a knack for breaking things. These users often find bugs that slipped through your QA processes. Critical Stakeholders: When a manager, CEO, or client encounters a problem, the stakes feel much higher. Their frustration can quickly escalate to panic. Real-Life Panic: A Case Study on Handling Software Delivery Panic Recently, Rob faced this scenario with a technically knowledgeable customer. Despite understanding the development process, the customer encountered a show-stopping bug in an alpha version. Their immediate reaction was that the project was nowhere near completion, creating a sense of panic. During our call, he expressed concerns that none of the features seemed to work. He acknowledged that bugs and design flaws were expected at this stage, but the issue was so severe that it led to a dramatic loss of confidence in the project. Handling Software Delivery Panic Step 1: Stay Calm and Analyze The first and most crucial step when faced with panic is to stay calm. Take a deep breath and focus on understanding the situation: Reproduce the Issue: Identify the user's steps to encounter the bug. Sometimes, it's as simple as a permission issue or an unanticipated input. Prioritize Fixes: Address the most critical issues first, especially those that block user progress. Step 2: Effective Communication Reassure the stakeholders that you're on top of the situation: Acknowledge the Problem: Validate their concerns and show you understand the impact. Outline the Next Steps: Explain how you plan to fix the issue and provide a realistic timeline. Step 3: Learn and Improve Use this experience to strengthen your development and testing processes: Enhance Testing: Incorporate the steps that led to the bug into your testing scenarios. Automated tests can help catch these issues earlier. Add Logging: Improve logging to gather more information if a similar problem arises in the future. Real-Life Tips from Experience Michael shares an insightful story about a shared work experience. Despite rigorous testing, their boss would find bugs within minutes of a release. This constant scrutiny drove home the importance of thorough testing and the psychological pressure of delivering seemingly flawless code. One key takeaway from Michael's story is the value of Test-Driven Development (TDD). By writing tests before the actual code, you ensure that each function meets the specified requirements. This approach not only catches potential issues early but also clarifies the expected behavior for each part of your application. Practical Advice for Developers Before starting on a new feature or bug fix, consider the following: Clarify Requirements: Ensure you have detailed requirements, including user input constraints and expected outputs. Define Acceptance Criteria: Clearly outline what constitutes a successful implementation. Implement Robust Logging: Log critical operations to simplify debugging and provide insights into any issues that arise. Using Static Code Analysis Tools To Handling Software Delivery Panic SonarQube SonarQube Is a code quality assurance tool that performs in-depth code analysis and generates an analysis report to ensure code reliability. Language Support: Java, JavaScript, C#, PHP, Python, C++, and more. Features: Provides comprehensive code quality and security analysis, integrates with CI/CD pipelines, and offers detailed reports. Strengths: Strong community support, extensive plugin ecosystem, and good integration with various development tools. ESLint ESLint statically analyzes your code to quickly find problems. It is built into most text editors and you can run ESLint as part of your continuous integration pipeline. Language Support: JavaScript, TypeScript. Features: Identifies and reports on patterns in JavaScript, customizable rules, and integration with most text editors and build systems. Strengths: Highly customizable, large number of plugins, and widely used in the JavaScript community. PMD PMD is an extensible multilanguage static code analyzer. It finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, etc. Language Support: Java, JavaScript, Salesforce Apex, PLSQL, XML, XSL. Features: Detects common coding issues like bugs, unused variables, and performance bottlenecks. Strengths: Simple rule configuration, supports multiple languages, and can be integrated into build tools like Maven and Gradle. PyLint Pylint is a static code analyser for Python 2 or 3. The latest version supports Python 3.8.0 and above. Pylint analyses your code without actually running it. It checks for errors, enforces a coding standard, looks for code smells, and can make suggestions about how the code could be refactored. Language Support: Python. Features: Checks for coding standards, errors, and code smells, provides suggestions for code improvements. Strengths: Highly configurable, integrates well with IDEs and CI/CD pipelines, and widely used in the Python community. Final Thoughts on Handling Software Delivery Panic Panic during software delivery is unavoidable, but it's manageable. By staying calm, communicating effectively, and learning from each incident, you can turn these challenging moments into opportunities for improvement. Remember, every bug is a lesson in disguise, pushing you toward becoming a better developer. That's it for today's episode. We hope these insights help you handle panic more effectively and continue building better software. Until next time, keep calm and code on! Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Code Refactoring: Maintaining Clean, Efficient Code Deciphering Code Chaos: Strategies for Writing Maintainable Code Test-Driven Development – A Better Object Oriented Design Approach Behind the Scenes Podcast Video

Join Scott and Wes as they delve into the fascinating realm of Biome.JS alongside Emanuele Stoppa, the mastermind behind it all. Why is it written in Rust? Why are other tools so slow? Could Biome be the ultimate successor to ESLint or Prettier? Grab a seat at the table and find out! Show Notes 00:00 Welcome to Syntax! 00:10 Brought to you by Sentry.io. 01:49 Who is Emanuele Stoppa and what is Biome? 03:18 What happened to Rome? 05:49 Who's paying for Biome to be developed? 07:28 How many people are working on Biome? 09:24 Why do we even need Biome? 11:38 Why are other tools so slow? 12:55 Cost of compute. 14:01 The cache management. 14:30 Why was the decision made to move to Rust? 16:35 The bigger the company, the pricier the compute. 19:49 How to get started with Biome. 23:08 Will Biome offer more features than Prettier? 24:12 Language support. 26:02 A language parser for every language? 27:45 Will plugins need to be written in Rust? GritQL GitHub. 31:25 Ezno, TypeScript Compiler. 33:13 Will we ever see a new TypeScript type-checker? 35:38 What are your thoughts on the types proposal? Proposal Type Annotations. 38:03 What does your average day look like? 41:10 What is your role at Astro? 41:46 What other languages do you know? 43:22 Biome VCS. 45:14 GitHub action setup. 47:04 Supper Club Questions. 47:09 What text editor, theme and font are you using? 48:26 What do you do to stay up to date? 48:54 Sick Picks & Shameless Plugs. Sick Picks Emanuele: Ripley IMDB, Netflix. Shameless Plugs Emanuele: Astro, BiomeJS. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott:X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

### Tematy 0:00 Intro 0:48 Bun 1.1 - https://bun.sh/blog/bun-v1.1 9:12 JavaScript Signals standard proposal - https://github.com/proposal-signals/proposal-signals 11:27 zx 8.0 - https://github.com/google/zx/releases/tag/8.0.0 14:10 Eslint 9.0 - https://eslint.org/blog/2024/04/eslint-v9.0.0-released/ 17:55 Playwright 1.43 - https://github.com/microsoft/playwright/releases/tag/v1.43.0 19:40 Hono 4.2 - https://github.com/honojs/hono/releases/tag/v4.2.0 21:12 Jotai 2.8 - https://github.com/pmndrs/jotai/releases/tag/v2.8.0 23:38 V8 Sandbox - https://v8.dev/blog/sandbox 25:56 Outro

Starting off, Robbie Russell and Robbie Wagner bonding over the complexities of their names in the coffee queue.They dive into the essence of maintainable software, debating the importance of recent commits and the dangers of a single-contributor project.Tech debt, the ever-looming shadow over software development, gets a moment in the spotlight. They share a laugh over buying GitHub stars as a measure of project health.Wagner's approach to tackling tech debt without permission is both rebellious and pragmatic, advocating for quality and refactoring 'on-the-go'.The conversation shifts to the Scout rule in software maintenance, and how constant vigilance is key to overcoming tech debt fatigue.Discussions around Ember.js, its community, and the evolution of front-end development light up the conversation.The narrative takes a turn as they explore automating the mundane, with ESLint, Prettier, and CI tools like Dependabot starring as the unsung heroes in the quest for quality.They touch upon the challenges of maintaining a balance between new features and tech debt, with Wagner emphasizing the sneaky art of integrating tech debt fixes into regular work.Robbie Wagner shares his love for rye whiskey, introducing listeners to his favorite brands and distilleries.Wrapping up, they delve into the world of podcasts, discussing the uniqueness of "Whiskey, Web and Whatnot" and how it blends technical discussions with personal stories and whiskey.Helpful Links:Check out Whiskey, Web and Whatnot for more episodes and whiskey recommendations!Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Josh Goldberg is a full-time open-source developer. He begins by sharing his developer experience and what he is currently working on. He joins the show to talk about "TypeScript, ESLint, and TypeScript ESLint". He dives into what this is all about, how these projects work, how they relate to each other, and much more.SponsorsChuck's Resume TemplateMiroBecome a Top 1% Dev with a Top End Devs MembershipSocialsGitHub: Josh GoldbergJosh GoldbergPicksCharles - Anne Frank House: HomeDan - TypeScript Origins: The DocumentarySteve - Gran Turismo (2023)Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

We review Jeroen Engels' journey with Elm from ESLint to elm-review. Jeroen even gives tips on how to introduce rules to a team.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.08.01GuestJeroen EngelsShow notes[00:00:21] Sponsored by Logistically[00:00:58] Introducing Jeroen Engelselm-reviewElm RadioElm Town 61 – Turning the pages with Dillon Kearnselm-syntaxjfmengels/elm-review-commonjfmengels/elm-review-documentationjfmengels/elm-review-simplifyjfmengels/elm-review-unused[00:02:37] It all started with a book[00:06:09] Getting a job as a backend developer[00:11:33] Senior: Figuring out what you're passionate about[00:15:24] Using ESLint to solve challenges with JavaScript[00:20:25] The refreshing experience of discovering Elm[00:26:13] A greenfield Elm projectCrowdStrike® Falcon LogScale™[00:33:04] Starting elm-reviewelm-analyze[00:42:06] elm-review v2"Implementing multi-file analysis for linters" on Jeroen Engels' blog[00:43:33] Middle names[00:44:40] Humor, coding, & podcastinghttps://postitontheweb.tumblr.com[00:50:19] Challenges with building elm-reviewElm Radio 84 – Writing Great Docs"Pushing unused exports detection one step further" on Jeroen Engels' blog"A tale of failing to design rule boundaries - Data-last functions" on Jeroen Engels' blog

Josh Goldberg is an independent full time open source developer. He works on projects in the TypeScript ecosystem, most notably typescript-eslint: the tooling that enables ESLint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and an active conference speaker. His personal projects range from static analysis to meta-languages to recreating retro games in the browser. Also cats. You can find Josh Goldberg on the following sites: Twitter Blog Here are some links provided by Josh Goldberg: Josh's Book PLEASE SUBSCRIBE TO THE PODCAST Spotify: ⁠http://isaacl.dev/podcast-spotify⁠ Apple Podcasts: ⁠http://isaacl.dev/podcast-apple⁠ Google Podcasts: ⁠http://isaacl.dev/podcast-google⁠ RSS: ⁠http://isaacl.dev/podcast-rss⁠ You can check out more episodes of Coffee and Open Source on ⁠https://www.coffeeandopensource.com⁠ Coffee and Open Source is hosted by Isaac Levin (⁠https://twitter.com/isaacrlevin⁠) --- Support this podcast: https://podcasters.spotify.com/pod/show/coffeandopensource/support

In this episode, we talk with Josh Goldberg about TypeScript ESLint, a tool that enables you to run standard JavaScript tools like eslint and prettier on your TypeScript code. We discuss the recent v6 release, the differences between formatting and styling, and the future of TypeScript ESLint. Josh also shares his thoughts on the future of TypeScript and the JavaScript ecosystem. Sponsored By Raycast (https://www.raycast.com/) https://twitter.com/JoshuaKGoldberg https://typescript-eslint.io/blog/announcing-typescript-eslint-v6/ https://www.learningtypescript.com/ Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership Tooltips Andrew https://github.com/fabian-hiller/valibot https://kysely.dev/ Justin https://github.com/qewer33/qpaperOS https://github.com/denosaurs/deno_python Josh Knip (https://github.com/webpro/knip) Nonviolent Communication (https://en.wikipedia.org/wiki/Nonviolent_Communication)

Josh Goldberg returns to talk about the tool typescript-eslint, and how it makes using ESLint with TypeScript easier. Links https://www.joshuakgoldberg.com https://twitter.com/JoshuaKGoldberg https://www.youtube.com/@JoshuaKGoldberg https://fosstodon.org/@JoshuaKGoldberg https://bsky.app/profile/joshuakgoldberg.com https://www.twitch.tv/JoshuaKGoldberg https://github.com/JoshuaKGoldberg https://typescript-eslint.io https://typescript-eslint.io/blog/announcing-typescript-eslint-v6 Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Josh Goldberg.

Uncover the best ESLint hacks with open source maintainer Josh Goldberg in this episode of the Modern Web Podcast. Enhancing Your Code Quality: TypeScript ESLint brings a new dimension to linting by blending ESLint's capabilities with TypeScript's type-checking. Now, developers can analyze TypeScript code with ease, utilizing linting rules and tools that leverage TypeScript's type-checking APIs. Say goodbye to tedious manual checks and embrace the power of automated code analysis. Version 6.0 Breakthrough: Discover the latest release of TypeScript ESLint V6.0, where preset configurations have been thoughtfully reworked. Developers can now enjoy more granular control over rules, tailoring their linting experience to suit their team's unique preferences and needs. With the separation of stylistic, strict, and opinionated rules, your codebase will reach new heights of consistency and excellence. User-Centered Experience: TypeScript ESLint focuses on developers' needs, actively seeking community feedback and engaging in discussions to ensure the best possible experience. Embrace the power of user-centered and informative error messages, guiding developers in mastering TypeScript and embracing its full potential. Get ready to elevate your TypeScript development with TypeScript ESLint V6.0, offering low configuration, high impact, and unrivaled performance. Boost your code quality and streamline your TypeScript development process with TypeScript ESLint. Say goodbye to manual checks and tedious errors, and unlock the potential of automated code analysis. Take control of your linting experience with V6.0's reworked presets, tailored to your team's preferences. Experience the future of linting with user-centered and informative error messages, guiding you towards mastery of TypeScript. Elevate your development journey with TypeScript ESLint V6.0, the ultimate tool for developer-friendly, efficient, and powerful linting. Host Rob Ocel- Software Architect at This Dot Labs Guest Josh Goldberg- Open Source Maintainer Sponsored by This Dot Labs

Adam has questions this episode: Why does Tailwind bring out the worst in people? Why don't more people just make nice fast apps like Linear? Why is Notion slow? Is sites vs apps a real debate? Is the developer experience getting better? And should Adam help Dax become the Benevolent Dictator of JavaScript that he was born to be?Want to carry on the conversation? Join us in Discord.Links:CamlinkNotionLinearSuperhumanReplicacheESLintBrazilian jiu-jitsuLex Fridman podcastJoe RoganAdam.devMarc Andreessen on Lex FridmanBen HorowitzTopics discussed: (00:00) - You gotta go through Dax first (00:26) - Why does Tailwind bring out the worst in everyone? (01:55) - Cables and gear make the office vibe off (05:12) - Avoiding bloat like Notion (07:17) - Who takes care of planning and logistics in life? (08:16) - Talking Linear and local first (15:53) - Why aren't we all designing better apps? (21:32) - Request for startups to build (26:21) - Is sites vs apps a real thing? (29:19) - Is the developer experience getting better or more complex? (33:21) - Is doing the ESLint dance worth it? (35:30) - Dax the Benevolent Dictator (38:40) - Adam's a martial artist now (47:37) - Why are certain podcasters controversial?

Sponsor: LevelUP Financial PlanningWe're grateful to be sponsored by LevelUP Financial planning, who understands the importance of finding balance between having an awesome life today, and being confident and excited about your future possibilities. If you want to take your financial confidence to the next level, check out levelupfinancialplanning.com.Join Bekah and Dan in this week's episode,  where they talk with Josh Goldberg,  an independent full time open source developer working on projects in the TypeScript ecosystem, where he shares valuable tips and insights on how you can get started with contributing to open source, whether you're a seasoned developer or just dipping your toes into OSS.  Josh also shares the story of his prolific speaking journey over the last couple of years and how staying involved in the tech community has been a rewarding experience.Links:typescript-eslinttypescript-eslint GitHubCode AcademyMicrosoft Sway Josh's Blog posts about applying to conferences:How I Apply to ConferencesHow I Apply to Conferences: FAQsJosh's Book: Learning TypescriptAbout Josh:Hi, I'm Josh! I'm an independent full time open source developer. I work on projects in the TypeScript ecosystem, most notably typescript-eslint: the tooling that enables ESLint and Prettier to run on TypeScript code. I'm also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and an active conference speaker. @JoshuaKGoldberg on Twitter@JoshuaKGoldberg on GitHub@JoshuaKGoldberg@fosstodon.org on mastodonSponsor Virtual Coffee! Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community. Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast! Virtual Coffee: Virtual Coffee: virtualcoffee.io Podcast Contact: podcast@virtualcoffee.io Bekah: dev.to/bekahhw, Twitter: https://twitter.com/bekahhw, Instagram: bekahhw Dan: dtott.com, Twitter: @danieltott

Guests Ruth Cheesley | Josh Goldberg Panelist Richard Littauer Show Notes Note: Due to an issue with Gmail sending the edited podcast to spam (thanks, gmail), this is going out a bit late! Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. This is a special podcast and one of several in this series for GitHub's Maintainer Month. We're interviewing maintainers to ask them about their experience of open source and their experience of living as maintainers. Our first guest is Ruth Cheesley, a maintainer and community lead for Mautic, an open source marketing automation platform. Richard and Ruth dive into open source governance, community engagement, and organizing virtual conferences. Ruth shares how she reinvigorated the Mautic community, highlighting the importance of transparency and empowering community leaders, and she unveils her project focusing on governance and fundraising to ensure Mautic's sustainability. Our next guest is Josh Goldberg, a full-time independent open source developer who's contributed significantly to TypeScript. They discuss Josh's transition from TSLint to TypeScript-ESLint, his efforts to boost developer community efficiency, and the importance of fair compensation for maintainers. Also, there's a conversation on the governance proposal of TypeScript-ESLint and the challenges of fair funding. Hit download to hear more! [00:01:06] Ruth tells us about Mautic and the growing community. Also, the core team/leadership team is made up of team leads for each functional area and Ruth as project lead. [00:03:32] Ruth thinks of herself as a maintainer because she's instrumental in the project's direction and ongoing development. [00:04:21] We hear about a challenging time for Ruth when Mautic was first acquired by Acquia in 2019, she was brought in as community manger to navigate this change and was successful in regaining trust an keeping the project moving forward. [00:07:41] Ruth emphasizes the importance of transparency in building trust, and she encourages maintainers to empower their community members by providing opportunities for leadership and ownership. [00:08:57] What's been fun for Ruth? Organizing Mautic's first-ever conference which was an inclusive, multi-lingual event with over 300 attendees. [00:12:11] Ruth discusses her excitement about the independent project they're working on, focusing on governance and fundraising. She expressed her vision for Mautic to be among the top options when people consider marketing automation tools. [00:13:49] We find out Ruth's long-term career aspirations in open source and community management, and how enjoys the challenge of new tasks and strives to balance her routine administrative duties with more fulfilling tasks that bring her joy. [00:17:01] She advises community managers to keep working in public, even it feels like an echo chamber initially, as people are watching and learning how they can contribute to the project. She suggested that this approach prevents burnout and invites others to generously contribute their time and support to the project. [00:18:09] Find out where you can learn more about Mautic and Ruth on the web. [00:20:22] Josh Goldberg joins us and fills us in on his journey into open source. He discusses the transition from the TSLint project, a linter for TypeScript, to TypeScript-ESLint, a set of extensions on top of ESLint that allows linting of TypeScript code, improving the efficiency and reducing duplication between the ESLint and TSLint communities. [00:22:13] His work is primarily funded through the Open Collective platform and some individual sponsorship on GitHub, and ESLint also sponsors the TypeScript-ESLint project. [00:23:06] We learn about the co-maintainers that work on the team. He also tells us they are working on a governance proposal, involving a system that ranks contributions by points, aiming to encourage maintainers and contributors to keep contributing. [00:24:39] Josh mentions his role as an open source maintainer, which has turned out to be mostly DevRel. [00:25:42] We hear about sustainable funding, and one of the challenges Josh experiences is the necessity to ask for funding, but he sees it as a necessary part of maintaining an open source project that lacks corporate backing. [00:27:10] There's a discussion on sustainable funding and Josh explains how they have different definitions based on their life situations. [00:28:54] Josh tells us the work is primarily funded through the Open Collective platform and some individual sponsorship on GitHub. He also talks about the governance proposal, involving a system that ranks contributions by points, [00:31:51] Josh mentions his role as an open source maintainer, which he initially thought would be half DevRel and half coding, has turned out to be DevRel, and he enjoys interacting with users and networking but misses core coding work. [00:33:03] One of the challenges Josh experiences is the necessity to ask for funding. [00:33:56] Richard suggests the possibility of expanding the TypeScript ESLint team to include toles focused on fundraising and community building, and Josh loves this idea. [00:35:31] Find out where you can follow Josh on the web. Quotes Ruth: [00:04:04] “Maintainers are conductors of an open source project orchestra.” Josh: [00:31:57] “When I came into this, I thought it would half DevRel, half coding, but it's not. It's majority DevRel and I like that.” Spotlight Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) SustainOSS Mastodon (https://mastodon.social/tags/sustainoss) Open Collective-SustainOSS (Contribute) (https://opencollective.com/sustainoss) Richard Littauer Twitter (https://twitter.com/richlitt?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Ruth Cheesley Twitter (https://twitter.com/RCheesley) Ruth Cheesley Website (https://www.ruthcheesley.co.uk/) Mautic (https://www.mautic.org/) Mautic Leadership Team (https://www.mautic.org/mautic-leadership-team) Mautic Contribution (https://www.mautic.org/tag/contribution) Sustain Podcast- 2 episodes featuring guest Ruth Cheesley (https://podcast.sustainoss.org/guests/cheesley) Josh Goldberg Website (https://www.joshuakgoldberg.com/#contact) Josh Goldberg Twitter (https://twitter.com/joshuakgoldberg) TypeScript-ESLint Mastodon (https://fosstodon.org/@tseslint) Open Collective-typescript-eslint (https://opencollective.com/typescript-eslint) Learning TypeScript by Josh Goldberg (https://www.oreilly.com/library/view/learning-typescript/9781098110321/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guests: Josh Goldberg and Ruth Cheesley.

In this week's roundup, hear snippets of our discussions about Svelte's compiler, the difference between linters and formatters, and what React Server Components actually are. This episode features Svelte core team member, Simon Holthausen, open-source maintainer, Josh Goldberg, and Astro's Ben Holmes. Links Apple The future of Svelte with Simon Holthausen - https://bit.ly/3Cv6CPE React, TypeScript, and ESLint with Josh Goldberg - https://bit.ly/3MRkTef Your React questions answered - https://bit.ly/3ONleRD Google The future of Svelte with Simon Holthausen - https://bit.ly/43rEDMC React, TypeScript, and ESLint with Josh Goldberg - https://bit.ly/45MsP9j Your React questions answered - https://bit.ly/3C1eKqO Spotify The future of Svelte with Simon Holthausen - https://bit.ly/3qlqZMf React, TypeScript, and ESLint with Josh Goldberg - https://bit.ly/43IFkkf Your React questions answered - https://bit.ly/3qloGsM Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guests: Ben Holmes, Josh Goldberg, and Simon Holthausen.

Josh Goldberg, open-source maintainer, speaker, and educator, comes onto the show to talk about linting in relation to React and TypeScript. Links https://astro.build https://docs.astro.build https://twitter.com/astrodotbuild https://bholmes.dev https://twitter.com/BHolmesDev https://github.com/bholmesdev https://www.linkedin.com/in/bholmesdev https://www.youtube.com/channel/UCfFNverFDMdWDQGBBC7Zw https://wtw.dev Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Josh Goldberg.

In this supper club episode of Syntax, Wes and Scott talk with Nicholas Zakas about his creation of ESLint, what's coming up in ESLint, and his work as a coach and mentor for programmers. Show Notes 00:34 Welcome 01:20 Guest introduction Human Who Codes Nicholas C. Zakas (@nzakas@fosstodon.org) Twitter @slicknet nzakas on GitHub @humanwhocodes) on Instagram Human Who Codes on YouTube 04:24 Why did you want to build ESLint? 09:08 How does ESLint work? 13:25 How do you work on a project for a decade? 17:12 At what point do you pay attention to JavaScript proposed changes? 20:37 Config systems in JavaScript 31:18 ESLint in Rust? 41:07 Are we going to see ESLint for more languages? 47:06 What kind of coaching do you do for programmers? 02:46 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Apollo Neuro Shameless Plugs Understanding JavaScript Promises Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Recording date: March 9, 2023John Papa @John_PapaWard Bell @WardBellDan Wahlin @DanWahlinCraig Shoemaker @craigshoemakerMaina Wycliffe @mwycliffe_devBrought to you byAG Grid IdeaBladeResources:All Things TypeScript NewsletterGeneral ZodTypescript and Zod schemasTypeScript type assertionTypescript-eslintBetter linting with TypeScript and ESLintLinting in TypeScript using ESLint and PrettierZod vs Yup validation schemasZod, Joi and Yup side by sideWhen should you use Zod?Fetch APITypeScript DecoratorsType Narrowing in TypeScriptGitHub CopilotTimejumps00:28 Welcome back01:43 Guest introduction04:32 Why shouldn't we use assertions?08:31 Sponsor: Ag Grid09:35 Using Zod schemas as the source of truth?13:11 How would you use Zod to validate data?18:51 Sponsor: IdeaBlade19:50 What are your favorite features about Typescript?27:10 What is type narrowing doing?33:10 What are practices people should avoid with Typescript?35:24 Final thoughtsPodcast editing on this episode done by Chris Enns of Lemon Productions.

Roopa Mohan is the principal software engineer for the coding analyzer team here at Salesforce. She loved computers when she was introduced to them in sixth grade and decided she wanted to do coding. The only company she applied to work at, Salesforce, hired her. In this episode, Roopa shares information about how the code analyzer came to be and what is in its future. She discusses how it works, who it works best for, and other tools that it works well in conjunction with.  Listen in to learn more about the Salesforce code analyzer tool and how it can be used in your operations. Show Highlights: What the code analyzer team does for its clients, and who the target audience is. What PMD and its counterpart ESLint are. The customization options for PMD and the code analyzer's role in the customization. What Code Analyzer 3.0 does for retired JavaScript libraries. What might be the future regarding developer tooling and AI technology. Links: Twitter account: @rmohan_sfdc Linkedin account: https://www.linkedin.com/in/roopa-mohan-21a85b20/ Github account: @rmohan20 Links related to Code Analyzer: Public documentation: https://forcedotcom.github.io/sfdx-scanner/ Open-source repo: https://github.com/forcedotcom/sfdx-scanner Blogs: https://developer.salesforce.com/blogs/2020/10/improve-your-code-quality-with-the-salesforce-cli-scanner https://developer.salesforce.com/blogs/2022/10/develop-even-more-secure-code-with-salesforce-code-analyzer

The time has come for a feature length episode on Typescript with guest star Scott Kaye! In this magnum opus, Scott, a Typescript Wizard, details some of the stronger points of Typescript through the lens of two conflicting articles - "Typescript is Terrible for Library Developers" and "Stop Using 'any', There's a Type for That". Evan yells at clouds nearly the entire time. To be serious for a minute - this is a good two-sided conversation about the strengths and (gasp) weaknesses of Typescript - it's worth a listen if you want to finally hear something other than "tYpESCripT Is tHE bESt!!!!!!" Scott introduces Scott's Principles of Typescript™, Evan claims Typescript is an elaborate scheme perpetrated on the developer community by Microsoft, and Joe loses us all talking about "bit shifting". Also, Scott will blow out your eardrums at some point so it's best you just live in fear the entire episode in anticipation. Some links we mentioned: 1. ThePrimeagen on "making an algorithm faster" 2. Scott's Portfolio 3. HackerNews thread about "Typescript is Terrible For Library Developers" 4. ESLint rewrite discussion

In this episode of Syntax, Wes and Scott talk about their predictions in web development for 2023. Show Notes 00:07 Welcome 01:25 SSR JS sites more the norm 03:32 React doing forms 05:39 TypeScript Inferred becomes hot 08:11 Deno gets hotter 12:51 JS Runtimes Mature HTMX 15:00 We will see a new TS Type Checker written in Rust 19:20 New JS APIs 23:37 Writing towards Winter CG Spec Popular. “Worker Ready” script STC 27:05 A new JS framework SolidJS Qwik 29:44 Page Transitions API 32:40 Scott was right / Scotts gonna be right 34:06 Rust becomes more Popular 36:00 React Beta Docs launch after 5 year dev cycle 37:45 CSS Container Queries in Production 41:07 Svelte and Sveltekit Glow Up 43:38 CSS Subgrid 49:19 WASM 51:51 AI Open AI 53:16 Houdini 54:30 People souring on React, Eslint 57:47 Machine learning 01:08 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Scott: Cron Wes: Wyze Headphones Shameless Plugs Scott: LevelUp SvelteKit Tutorial Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

GuestsMario Rogic (twitter) (github)Matthew Griffith (twitter) (github)LinksElmcraft.orgJeroen's Elmcraft article ESLint equivalents in ElmMartin Janiczek's Elmcraft article on Let PolymorphismElmcraft project on GitHubElmcraft discordelm-codegenelm-gqlMatt's Strange Loop talk CodeGen with Types, for Humans, by HumansTail recursion modulo cons elm optimize level 2 prelm-review extractors featureelm-pages-v3-betaelm-pages Script (v3 feature)OpenAI whisper project on GitHubelm-watchelm-bookelm-widgetsL*a*b color spaceelm.develm-watch episodeelm-tailwind-modules color parameterization PR

Web development has changed a lot since the release of ESLint in 2013. Nicholas Zakas, the creator of ESLint, joins us to talk about the complete rewrite of ESLint, goals for the rewrite, and how the rewrite will leverage Rust. Links https://eslint.org https://twitter.com/geteslint https://twitter.com/humanwhocodes https://twitter.com/slicknet https://humanwhocodes.com Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Nicholas Zakas.

Josh talks with James and Amy about teaching TypeScript and ESLint to beginners.SponsorsHashnodeCreating a developer blog is crucial in creating an online presence for yourself. It's proof of work for your future employer. Hashnode makes it easy to start a blog in seconds on your custom domain for free. It's fully optimized for developers and supports writing in Markdown, rich embeds, publishing from GitHub repository, syntax highlighting, and edge caching with Next.js blogs deployed on Vercel. On top of these, Hashnode is free from paywall, ads, and sign-up prompts.Hashnode is a community of developers, engineers, and people in tech. Your article gets instant readership from their growing community.Check out Hashnode, and join the community.Daily.devdaily.dev is where developers grow together. It provides a community-based feed of the best developer news, helping you stay up-to-date. daily.dev aggregates hundreds of sources every few minutes and creates a personal feed for you according to your interests, whether it's web dev, data science, or Elixir. Anything you might be interested in, it has the content for you.Check out daily.devShow Notes00:00 Introduction01:21 Josh's Background02:45 Josh's First Project04:37 TypeScript Beginnings05:43 What is a Generic?08:44 What Makes TypeScript Interesting10:11 Transpiring12:58 Sponsor: Daily.dev13:59 Getting into TypeScript ESLint19:54 ESLint Set Up22:38 Josh's Book16:42 Measuring Book Success29:13 Sponsor: Hashnode29:59 Open Source Developer as a Job Title32:08 When Your Passion is Your Career36:34 Josh's Soapbox39:28 Pro Tips41:24 Picks and Plugs45:35 Something Annoying in ESLint46:55 More Picks and Plugs

Guest Nicholas Zakas Panelists Richard Littauer | Justin Dorfman Show Notes Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. Our guest today is a returning guest that we've had on before. We are excited to have joining us, Nicholas Zakas, who's one of the maintainers on ESLint, which is a tool that helps you find and fix problems in your JavaScript code. Today, we'll learn all about ESLint, the maintainers, contributors, and how they get paid. Also, we'll find out the success behind ESLint, and a post about sponsoring dependencies that Nicholas wrote on his blog. Go ahead and download this episode now to learn more! [00:02:23] Nicholas tells us all about ESLint, their maintainers that work on the project, and how many people have contributed to the project on GitHub. [00:07:29] Nicholas tells us how maintainers get paid as part of his governance strategy. [00:10:04] Justin asked about the fact that ESLint not only pays contributors, but also pays downstream dependencies. [00:12:04] Richard wonders where all the money comes from that gave ESLint this huge surplus, and Nicholas explains how they raised so much and what it is about ESLint that makes that possible. [00:16:10] We hear some reflections from Richard as he congratulates Nicholas and makes some important points about the success of ESLint. [00:20:19] Nicholas fills us in on the OpenJS Foundation Project. [00:23:57] Richard talks about a blog post Nicholas wrote on his blog about sponsoring dependencies, and Nicholas explains the difference between large charismatic projects and smaller projects and how he sees the role of large projects in funding the smaller ones. [00:31:41] We hear what ESLint did with sponsoring dependencies, and Nicholas tells us about some projects that they wanted to support financially, but turned them down. [00:38:06] Find out where you can follow Nicholas and ESLint online. Quotes [00:07:43] “Everybody on the team, the committers, reviewers, technical steering committee, gets paid an hourly rate for their contributions.” [00:07:53] “Contributions can be anything that contributes to the project, reviewing issues and pull requests, attending meetings, helping people on discord, helping people on GitHub discussions, and if people ever go to conferences or meetings representing the team, they can also charge for that.” [00:10:15] “We made a decision the beginning of last year that it was time to start supporting our dependencies.” [00:12:28] “I do think we are lucky in a lot of ways that we've had champions inside of companies who were working within their company to get ESLint's support.” [00:13:13] “In the beginning, we were hesitant to start spending the money because we didn't know how reliable that source of income would be, and we were worried we wouldn't be able to pay a living wage.” [00:21:25] “Being in a foundation is one type of a reputational check mark that an open source project can get.” [00:26:15] “I think OpenSSL is a great example of [the funding problem]. It's a foundational piece of internet infrastructure.” [00:28:31] “We went on backyourstack.com and started looking for the projects that we were depending on that had Open Collective pages and said, as a project, what is good for open source in general, is also good for ESLint.” [00:29:20] “Open source, in general, is this collective of projects that are built on top of projects that are built on top of projects that are built on top of projects, and we have no problem giving that recognition when we're talking about what the project is built upon.” Spotlight [00:39:47] Justin's spotlight is the new book, What if? 2 by Randall Munroe. [00:40:31] Richard's spotlight is David Troupes, Buttercup Festival comic strips. [00:41:03] Nicholas's spotlight is the book, WebAssembly: The Definitive Guide by Brian Sletten Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) Richard Littauer Twitter (https://twitter.com/richlitt?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Justin Dorfman Twitter (https://twitter.com/jdorfman?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Nicholas Zakas Twitter (https://twitter.com/slicknet) Nicholas Zakas GitHub (https://github.com/nzakas) ESLint (https://eslint.org/) ESLint Twitter (https://twitter.com/geteslint?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) ESLint GitHub (https://github.com/eslint/eslint) ESLint-Open Collective (https://opencollective.com/eslint) Sustain Podcast-Episode 101: Nicholas Zakas and ESLint (https://podcast.sustainoss.org/guests/zakas) Sponsoring dependencies: The next step in open source sustainability (Human Who Codes Blog) (https://humanwhocodes.com/blog/2022/06/sponsoring-dependencies-open-source-sustainability/) Sustain Podcast-Episode 117: Mike McQuaid of Homebrew on Sustainably Working on OSS Projects (https://podcast.sustainoss.org/117) Sustain Podcast-Episode 126: GitHub Maintainer Month with Mike McQuaid of Homebrew and Nina Breznik of DatDot (https://podcast.sustainoss.org/126) BackYourStack (https://backyourstack.com/) Securing Open Source Software Act of 2022 (Sustain) (https://discourse.sustainoss.org/t/securing-open-source-software-act-of-2022/1098) What if? 2 by Randall Munroe (https://xkcd.com/what-if-2/) David Troupes-Buttercup Festival comic strips (Patreon) (https://www.patreon.com/buttercupfestival) WebAssembly: The Definitive Guide by Brian Sletten (https://www.oreilly.com/library/view/webassembly-the-definitive/9781492089834/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Nicholas Zakas.

Change log Code Quiz API https://github.com/howToCodeWell/code-quiz Thank you to MetinBaris and everyone else who has contributed to the Code Quiz project Added dotenv package Lots of bugs fixed GitHub Actions on API client EsLint added Unit tests added You're doing Agile spikes wrong Let's talk about Agile spikes. What are they, why do we need them and why are you doing them wrong. Follow on the socials Twitter: https://twitter.com/howtocodewell Instagram : https://www.instagram.com/howtocodewell/ My web development courses ➡️ Learn How to build a JavaScript Tip Calculator ➡️ Learn JavaScript arrays ➡️ Learn PHP arrays ➡️ Learn Python ✉️ Get my weekly newsletter ⏰ My current live coding schedule (Times are BST) Tuesdays 18:00 = Live Podcast YouTube Sundays 15:00 - Live coding on Twitch

Daryl and Scott interview Sid Gundavarapu and Jesse Parsons from Microsoft, and chat about the ESLint rules for Power Apps model-driven apps and Dynamics 365 CE. Some of the highlights: What is ESLint? What are ESLint rules for Power Apps and Dynamics 365? ESLint is like a grammar check for code Power Apps ESLint npm package vs Solution Checker Targeted audience for ESLint rules  Security-focused ESLint rules ESLint auto-fix Daryl's Christmas wish Recommended approach for those who are not using TypeScript yet Spell Checker for VS Code Sid's Info: https://www.linkedin.com/in/sidharthag Jesse's Info: https://www.linkedin.com/in/jesse-parsons-7295b426 Other links: Announcement blog post: https://powerapps.microsoft.com/en-us/blog/announcing-public-preview-of-eslint-rules-for-power-apps-and-dynamics-365/ Discuss feedback/suggestions/concerns on the ESLint rules for Power Apps: https://powerusers.microsoft.com/t5/Power-Apps-Pro-Dev-ISV/Power-Apps-ESLint-npm-package-public-preview/m-p/1679862 Got questions? Have your own tool you'd like to share? Have a suggestion for a future episode? Contact Daryl and Scott at cast@xrmtoolbox.com. Follow us on LinkedIn and @XrmToolCast for updates on future episodes. Do you want to see us too? Subscribe to our YouTube channel to view the last episodes. Don't forget to rate and leave a review for this show at Podchaser. Your hosts: Daryl LaBar: https://www.linkedin.com/in/daryllabar | @ddlabar Scott Durow: https://www.linkedin.com/in/scottdurow | @ScottDurow Editor: Linn Zaw Win: https://www.linkedin.com/in/linnzawwin  | @LinnZawWin Music: https://www.purple-planet.com

Jeroen's tweet on the root cause of false positivesEpistemologyIsabelle and TLA+ (proof systems)Precautionary principlearray-callback-return ESLint ruleelm-review's ModuleNameLookupTableJeroen's Safe unsafe operations in Elm blog postJeroen's Lambda Days 2022 talk (video not yet published)

¿Quieres aprender a programar para crea páginas web desde 0, aplicaciones, y trabajar en la industria tecnológica? ⛺️ BOOTCAMP

This week we're joined by another great contributor to the TypeScript community.Josh Goldberg is the author of O'Reilly's Learning TypeScript and a core contributor to the typescript-eslint.

Natural disaster movies, anyone? It's what Steph's been into, and Chris has THOUGHTS on the drilling in Armageddon. Additionally, a chat around RuboCop RSpec rules happens, and they answer a listener's question, "how do you get acquainted with a new code base?" This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. Greenland (https://www.imdb.com/title/tt7737786/) Geostorm (https://www.imdb.com/title/tt1981128/) San Andreas (https://www.imdb.com/title/tt2126355/) Armageddon (https://www.imdb.com/title/tt0120591/) This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. Flaky tests slow everyone down, break your flow, and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start? BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed. CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. So I've been watching more movies lately. So evenings aren't always great; I don't always feel good being around 33 weeks pregnant now. Evenings I can be just kind of exhausted from the day, and I just need to chill and prop my feet up and all that good stuff. And I've been really drawn to natural disaster like end-of-the-world-type movies, and I'm not sure what that says about me. But it's my truth; it's where I'm at. [chuckles] I watched Greenland recently, which I really enjoyed. I feel like they ended it well. I won't share any spoilers, but I feel like they ended it well. And they didn't take an easy shortcut out that I kind of thought that they might do, so that one was enjoyable. Geostorm, I watched that one just last night. San Andreas, I feel like that's one that I also watched recently. So yeah, that's what's new in my world, you know, your typical natural disaster end-of-the-world flicks. That's my new evening hobby. CHRIS: I feel like I haven't heard of any of the three that you just listed, which is wild to me because this is a category that I find enthralling. STEPH: Well, definitely start with Greenland. I feel like that one was the better of the three that I just mentioned. I don't know Geostorm or San Andreas which one you would prefer there. I feel like they're probably on par with each other in terms of like you're there for entertainment. We're not there to judge and be hypercritical of a storyline. You're there purely for the visual effects and for the ride. CHRIS: Gotcha. Interesting. So quick question then, since this seems like the category you're interested in, Armageddon or Deep Impact? STEPH: Ooh, I'm going to have to walk through the differences because I always get those mixed up. Armageddon is where they take Bruce Willis up to an asteroid, and they have to drill and drop a nuke, right? CHRIS: They sure do. STEPH: [laughs] And then what's Deep Impact about? I guess the fact that I know Armageddon better means I'm favoring that one. I can't place what...how does Deep Impact go? CHRIS: Deep Impact is just there's an asteroid coming, and it's the story and what the people do. So it's got less...it doesn't have the same pop. I believe Armageddon was a Michael Bay movie. And so it's got that Michael Bay special bit of something on it. But the interesting thing is they came out the same year; I want to say. It's one of those like Burger King and McDonald's being right next door to each other. It's like, what are you doing there? Why are you...like, asteroid devastation movies two of you at the same time, really? But yeah, Armageddon is the correct answer. Deep Impact is like a fine movie, but Armageddon is like, all right, we're going to have a movie about asteroids. Let's really go for it. Blow it out. Why not? STEPH: Yeah, I'm with you. Armageddon definitely sticks out in my memory, so I'd vote that one. Also, for your other question that you didn't ask, but you kind of implicitly asked, I'm going to go McDonald's because Burger King fries are trash, and also, McDonald's has better ice cream cones. CHRIS: Okay, so McDonald's fries. Oh no, I was thinking Wendy's, get a frosty from there, and then you make that combination because the frostys are great. STEPH: Oh yeah, that's a good combo. CHRIS: And you need the french fries to go with it, but then it's a third option that I'm introducing. Also, this wasn't a question, but I want to loop back briefly to Armageddon because it's an important piece of cinema. There's a really great...like it's DVD commentary, and it's Ben Affleck talking with Michael Bay about, "Hey, so in the movie, the premise is that the only way to possibly get this done is to train a bunch of oil drillers to be astronauts. Did we consider it all just having some astronauts learn to do oil drilling?" And Michael Bay's response is not safe for radio is how I would describe it. But it's very humorous hearing Ben Affleck describe Michael Bay responding to that. STEPH: I think they addressed that in the movie, though. They mentioned like, we're going to train them, but they're like, no, drilling is such an art and a science. There's no way. We don't have time to teach these astronauts how to drill. So instead, it's easier to teach them to be astronauts. CHRIS: Right. That is what they say in the movie. STEPH: [laughs] Okay. CHRIS: But just spending a minute teasing that one apart is like, being an astronaut is easy. You just sit in the spaceship, and it goes, boom. [laughs] It's like; actually, there's a little bit more to being an astronaut. Yes, drilling is very subtle science and art fusion. But the idea that being an astronaut [laughs] is just like, just push the go-to space button, then you go to space. STEPH: The training montage is definitely better if we get to watch people learn how to be astronauts than if we watch people learn how to drill. [laughs] So that might have also played a role. CHRIS: No question, it is the correct cinematic choice. But whether or not it's the true answer...say we were actually faced with this problem, I don't know that this is exactly how it would play out. STEPH: I think we should A/B test it. We'll have one group train to be drill experts and one group train to be astronauts, and we'll send them both up. CHRIS: This is smart. That's the way you got to do it. The one other thing that I'm going to go...you know what really grinds my gears? In the movie Armageddon, they have this robotic vehicle thing, the armadillo; I believe it's called. I know more than I thought I would remember about this movie. [chuckles] Anyway, continuing on, the armadillo, the vehicle that they use to do the drilling, has the drill arm on it that extends out and drills down into the asteroid. And it has gears on the end of it. It has three gears specifically. And the first gear is intermeshed with the second gear, which is intermeshed with the third gear, which is intermeshed with the first gear, so imagine which direction the first gear is turning, then imagine the second gear turning, then imagine the third gear turning. They can't. It's a physically impossible object. One tries to turn clockwise, and the other one is trying to go counterclockwise, and they're intermeshed. So the whole thing would just cease up. It just doesn't work. I've looked at it a bunch of times, and I want to just be wrong about this. I want to be like; I don't know what's going on. But I think the gears on the drilling machine just fundamentally at a very simple mechanical level cannot work. And again, if you're going to do it, really go for it, Michael Bay. I kind of like that, and I really hate it at the same time. STEPH: I have never noticed this. I'm intrigued. You know what? Maybe Armageddon will be the movie of choice tonight. [chuckles] Maybe that's what I'm going to watch. And I'm going to wait for the armadillo to come out so I can evaluate the gears. And I'm highly amused that this is the thing that grinds your gears are the gears on the armadillo. CHRIS: Yeah. I was a young child at the time, and I remember I actually went to Disney World, and I saw they had the prop vehicle there. And I just kind of looked up at it, and I was like, no, that's not how gears work. I may have been naive and wrong as a child, and now I've just anchored this memory deep within me. In a similar way, so I had a moment while traveling; actually, that reminded me of something that I said on a recent podcast episode where I was talking about names and pronunciation. And I was like, yeah, sometimes people ask me how to pronounce my name. And I can't imagine any variation. That was the thing I was just wrong about because 'Toomay' is a perfectly reasonable pronunciation of my name that I didn't even think... I was just so anchored to the one truth that I know in the world that my name is Toomey. And that's the only possible way anyone could pronounce it. Nope, totally wrong. So maybe the gears in Armageddon actually work really, really well, and maybe I'm just wrong. I'm willing to be wrong on the internet, which I believe is the name of the first episode that we recorded with you formally as a co-host. [chuckles] So yeah. STEPH: Yeah, that sounds true. So you're going to change the intro? It's now going to be like, and I'm Chris 'Toomay'. CHRIS: I might change it each time I come up with a new subtle pronunciation. We'll see. So far, I've got two that I know of. I can't imagine a third, but I was wrong about one. So maybe I'm wrong about two. STEPH: It would be fun to see who pays attention. As someone who deeply values pronouncing someone's name correctly, oh my goodness, that would stress me out to hear someone keep pronouncing their name differently. Or I would be like, okay, they're having fun, and they don't mind how it gets pronounced. I can't remember if we've talked about this on air but early on, I pronounced my last name differently for like one of the first episodes that we recorded. So it's 'Vicceri,' but it could also be 'Viccari'. And I've defaulted at times to saying 'Viccari' because people can spell that. It seems more natural. They understand it's V-I-C-C-A-R-I. But if I say 'Vicceri', then people want to add two Rs, or they want a Y. I don't know why it just seems to have a difference. And so then I was like, nope, I said it wrong. I need to say it right. It's 'Vicceri' even if it's more challenging for people. And I think Chad Pytel had just walked in at that moment when I was saying that to you that I had said my name differently. And he's like, "You can't do that." And I'm like, "Well, I did it. It's already out there in the world." [laughs] But also, I'm one of those people that's like, Viccari, 'Vicceri' I will accept either. In a slightly different topic and something that's going on in my world, there was a small win today with a client team that I really appreciated where someone brought up the conversation around the RuboCop RSpec rules and how RuboCop was fussing at them because they had too many lines in their test example. And so they're like, well, they're like, I feel like I'm competing, or I'm working against RuboCop. RuboCop wants me to shorten my test example lines, but yet, I'm not sure what else to do about it. And someone's like, "Well, you could extract more into before blocks and to lets and to helpers or things like that to then shorten the test. They're like, "But that does also work against readability of the test if you do that." So then there was a nice, short conversation around well, then we really need more flexibility. We shouldn't let the RuboCop metrics drive us in this particular decision when we really want to optimize for readability. And so then it was a discussion of okay, well, how much flexibility do we add to it? And I was like, "Well, what if we just got rid of it? Because I don't think there's an ideal length for how long your test should be. And I'd rather empower test authors to use all the space that they need to show their test setup and even lean into duplication before they extract things because this codebase has far more dry tests than they do duplication concerns. So I'd rather lean into the duplication at this point." And the others that happened to be in that conversation were like, "Yep, that sounds good." So then that person issued a PR that then removed the check for that particular; how long are the examples? And it was lovely. It was just like a nice, quick win and a wonderful discussion that someone had brought up. CHRIS: Ooh, I like that. That sounds like a great conversation that hit on why do we have this? What are the trade-offs? Let's actually remove it. And it's also nice that you got to that place. I've seen a lot of folks have a lot of opinions in the past in this space. And opinions can be tricky to work around, and just deeply, deeply entrenched opinions is the thing that I find interesting. And I think I'm increasingly in the space of those sort of, thou shalt not type linter rules are not ideal in my mind. I want true correctness checks that really tell some truth about the codebase. Like, we still don't have RuboCop on our project at Sagewell. I think that's true. Yeah, that's true. We have ESLint, but it's very minimal, what we have configured. And they more are in the what we deem to be true correctness checks, although that is a little bit of a blurry line there. But I really liked that idea. We turn on formatters. They just do the thing. We're not allowed to discuss the formatting, with the exception of that time that everybody snuck in and switched my 80-line length to a 120-line length, but I don't care. I'm obviously not still bitter about it. [chuckles] And then we've got a very minimal linting layer on top of that. But like TypeScript, I care deeply, and I think I've talked in previous episodes where I'm like, dial up the strictness to 14 because TypeScript tends to tell me more truths I find, even though I have to jump through some hoops to be like TypeScript, I know that this is fine, but I can't prove it. And TypeScript makes me prove it, which I appreciate about it. I also really liked the way you referred to RSpec's feedback to you was that RSpec was fussing at you. That was great. I like that. I'm going to internalize that. Whenever a linter or type system or anything like that when they tell me no, I'm going to be like, stop fussing, nope, nope. [chuckles] STEPH: I don't remember saying that, but I'm going to trust you that that's what I said. That's just my true southern self coming through on the mic, fussing, and then go get a biscuit, and it'll just be a delightful day. CHRIS: So if I give RuboCop a biscuit, it will stop fussing at me, potentially? STEPH: No, the biscuit is just for you. You get fussed at; you go get a biscuit. It makes you feel better, and then you deal with the fussing. CHRIS: Sold. STEPH: Fussing and cussing, [laughs] that's most of my work life lately, fussing and cussing. [laughs] CHRIS: And occasional biscuits, I hope. STEPH: And occasional biscuits. You got it. But that's what's new in my world. What's going on in your world? CHRIS: Let's see. In my world, it's a short week so far. So recording on Wednesday, Monday was a holiday. And I was out all last week, which very much enjoyed my vacation. It was lovely. Went over to Europe, hung out there for a bit, some time in Paris, some time in Amsterdam, precious little time on a computer, which is very rare for me. So it was very enjoyable. But yeah, back now trying to just get back into the swing of things. Thankfully, this turned out to be a really great time to step away from the work for a little while because we're still in this calm before the storm but in a good way is how I would describe it. We have a major facet of the Sagewell platform that we are in the planning modes for right now. But we need to get a couple of different considerations, pick a partner vendor, et cetera, that sort of thing. So right now, we're not really in a position to break ground on what we know will be a very large body of work. We're also not taking on anything else too big. We're using this time to shore up a lot of different things. As an example, one of the fun things that we've done in this period of time is we have a lot of webhooks in the app, like a lot of webhooks coming into the app, just due to the fact that we're an integration of a lot of services under the hood. And we have a pattern for how we interact with and process, so we actually persist the webhook data when they come in. And then we have a background job that processes and watch our pattern to make sure we're not losing anything and the ability to verify against our local version, and the remote version, a bunch of different things. Because turns out webhooks are critical to how our app works. And so that's something that we really want to take very seriously and build out how we work with that. I think we have eight different webhook integrations right now; maybe it's more. It's a lot. And with those, we've implemented the same pattern now eight times; I want to say. And in squinting at it from a distance, we're like; it is indeed identically the same pattern in all eight cases or with the tiniest little variation in one of them. And so we've now accepted like, okay, that's true. So the next one of them that we introduced, we opted to do it in a generic way. So we introduced the abstraction with the next iteration of this thing. And now we're in a position...we're very happy with what we ended up with there. It's like the best of all of the other versions of it. And now, the plan will be to slowly migrate each of the existing ones to be no longer a unique special version of webhook processing but use the generic webhook processing pattern that we have in the app. So that's nice. I feel good about how long we waited as well because it's like, we have webhooks. Let's introduce the webhook framework to rule them all within our app. It's like, no, wait until you see. Check and make sure they are, in fact, the same and not just incidental duplication. STEPH: I appreciate that so much. That's awesome. That sounds like a wonderful use of that in-between state that you're in where you still got to make progress but also introduce some refactoring and a new concept. And I also appreciate how long you waited because that's one of those areas where I've just learned, like, just wait. It's not going to hurt you. Just embrace the duplication and then make sure it's the right thing. Because even if you have to go in and update it in a couple of places, okay, sure, that feels a little tedious, but it feels very safe too. If it doesn't feel safe...I could talk myself back and forth on this one. If it doesn't feel safe, that's a different discussion. But if you're going through and you have to update something in a couple of different places, that's quick. And sure, you had to repeat yourself a little bit, but that's fine. Versus if you have two or three of something and you're like, oh, I immediately must extract. That's probably going to cause more pain than it's worth at this point. CHRIS: Yeah, exactly, exactly that. And we did get to that place where we were starting to feel a tiny bit of pain. We had a surprising bit of behavior that when we looked at it, we were like, oh, that's interesting, because of how we implemented the webhook pattern, this is happening. And so then we went to fix it, but we were like, oh, it would actually be really nice to have this fixed across everything. We've had conversations about other refinements, enhancements, et cetera; that we could do in this space. That, again, would be really nice to be able to do holistically across all of the different webhook integration things that we have. And so it feels like we waited the right amount of time. But then we also started to...we're trying to be very responsive to the pressure that the system is pushing back on us. As an aside, the crispy Brussels snack hour and the crispy Brussels work lunch continue to be utterly fantastic ways in which we work. For anyone that is unfamiliar or hasn't listened to episodes where I rambled about those nonsense phrases that I just said, they're basically just structured time where the engineering team at Sagewell looks at and discusses higher-level architecture, refactoring, developer experience, those sort of things that don't really belong on the core product board. So we have a separate place to organize them, to gather them. And then also, we have a session where we vote on them, decide which ones feel important to take on but try and make sure we're being intentional about how much of that work we're taking on relative to how much of core product work and try and keep sort of a good ratio in between the two. And thus far, that's been really fantastic and continues to be, I think, really effective. And also the sort of thing that just keeps the developer team really happy. So it's like, I'm happy to work in this system because we know we have a way to change it and improve it where there's pain. STEPH: I like the idea of this being a game show where it's like refactor island, and everybody gets together and gets to vote which refactor stays or gets booted off the island. I'm also going to go back and qualify something I said a moment ago, where if something feels safe in terms of duplication, where it starts to feel unsafe is if there's like an area that you forgot to update because you didn't realize it's duplicated in several areas and then that causes you pain. Then that's one of those areas where I'll start to say, "Okay, let's rethink the duplication and look to dry this up." CHRIS: Yep, indeed. It's definitely like a correction early on in my career and overcorrection back and trying to find that happy medium place. But as an aside, just throwing this out there, so webhooks are an interesting space. I wish it were a more commoditized offering of platforms. Every vendor that we're integrating with that does webhooks does it slightly differently. It's like, "Oh, do you folks have retries?" They're like, "No." It's like, oh, what do you mean no? I would love it if you had retries because, I don't know, we might have some reason to not receive one of them. And there's polling, and there are lots of different variations. But the one thing that I'm surprised by is that webhook signing I don't feel like people take it serious enough. It is a case where it's not a huge security vulnerability in your app. But I was reading someone who is a security analyst at one point. And they were describing sort of, I've done tons of in-the-code audits of security practices, and here are the things that I see. And so it's the normal like OWASP Top 10 Cross-Site Request Forgery, and SQL injection, and all that kind of stuff. But one of the other ones he highlighted is so often he finds webhooks that are not verified in any way. So it's just like anyone can post data into the system. And if you post it in the right shape, the system's going to do some stuff. And there's no way for the external system to enforce that you properly validate and verify a webhook coming in, verify that payload. It's an extra thing where you do the checksum math and whatnot and take the signature header. I've seen somewhere they just don't provide it. And it's like, what do you mean you don't provide it? You must provide it, please. So it's either have an API key so that we have some way to verify that you are who you say you are or add a signature, and then we'll calculate it. And it's a little bit of a dance, and everybody does it different, but whatever. But the cases where they just don't have it, I'm like, I'm sorry, what now? You're going to say whom? But yeah, then it's our job to definitely implement that. So this is just a notice out there to anyone that's listening. If you got a bunch of webhook handling code in your app, maybe spot-check that you're actually verifying the payloads because it's possible that you're not. And that's a weird, very open hole in the side of your application. STEPH: That's a really great point. I have not worked with webhooks recently. And in the past, I can't recall if that's something that I've really looked at closely. So I'm glad you shared that. CHRIS: It's such an easy thing to skip. Like, it's one of those things that there's no way to enforce it. And so, I'd be interested in a survey that can't be done because this is all proprietary data. But what percentage of webhook integrations are unverified? Is it 50%? Is it 10%? Is it 100%? It's definitely not 100. But it's somewhere in there that I find interesting. It's not a terribly exploitable vulnerability because you have to have deep knowledge of the system. In order to take advantage of it, you need to know what endpoint to hit to, what shape of data to send because otherwise, you're probably just going to cause an error or get a bunch of 404s. But like, it's, I don't know, it's discoverable. And yeah, it's an interesting one. So I will hop off my webhook soapbox now, but that's a thought. MIDROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half. So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! CHRIS: But now that I'm off my soapbox, I believe we have a topic that was suggested. Do you want to provide a little bit of context here, Steph? STEPH: Yeah, I'd love to. So this came up when I was having a conversation with another thoughtboter. And given that we change projects fairly frequently, on the Boost team, we typically change projects around every six months. They asked a really thoughtful question that was "How do you get acquainted with a new codebase? So given that you're changing projects so often, what are some of the tips and tricks for ways that you've learned to then quickly get up to speed with a new codebase?" Because, frankly, that is one of the thoughtbot superpowers is that we are really good at onboarding each other and then also getting up to speed with a new team, and their processes, and their codebase. So I have a couple of ideas, and then I'd love to hear some of your thoughts as well. So I'll dive in with a couple. So the first one, this one's frankly my favorite. Like day one, if there's a team where I'm joining and they have someone that can walk me through the application from the users' perspective, maybe it's someone that's in sales, or maybe it's someone on the product team, maybe it's a recording that they've already done for other people, but that's my first and favorite way to get to know an application. I really want to know what are users experience as they're going through this app? That will help me focus on the more critical areas of the application based on usage. So if that's available, that's fabulous. I'm also going to tailor a lot of this more to like a Rails app since that's typically the type of project that I'm onboarding to. So the other types of questions that I like to find answers to are just like, what's my top-level structure? Like to look through the app and see how are things organized? Chris, you've mentioned in a previous episode where you have your client structure that then highlights all the third-party clients that you're working with. Are we using engines in the app? Is there anything that seems a bit more unique to that application that I'm going to want to brush up on or look into? What's the test coverage like? Do they have something that's already highlighting how much test coverage they have? If not, is there something that then I can run locally that will then show me that test coverage? I also really like to look at the routes file. That's one of my other favorite places because that also is very similar to getting an overview of the product. I get to see more from the user perspective. What are the common resources that people are going to, and what are the domain topics that I'm working with in this new application? I've got a couple more, but I'm going to pause there and see how you get acquainted with a new app. CHRIS: Well, unsurprisingly, I agree with all of those. We're still searching for that dare to disagree beyond Pop-Tarts and IPAs situation. To reiterate or to emphasize some of the points you made, the sales demo thing? I absolutely love that one because, yes, absolutely. What's the most customer-centric point of view that I can have? Can I then login to a staging version of the site so I can poke around and hopefully not break anything or move real money or anything like that? But understanding why is this thing, not in code, but in actual practical, observable, intractable software? Beyond that, your point about the routes, absolutely, that's one of my go-to's, although the routes there often is so much in the routes, and it's like some of those may actually be unused. So a corollary to the routes where available if there's an APM tool like Scout, or New Relic, or something like that, taking a look at that and seeing what are the heavily trafficked endpoints within this app? I like to think about it as the entry points into this codebase. So the routes file enumerates all of them, but some of them matter, and some of them don't. And so, an APM tool can actually tell you which are the ones that are seeing a ton of traffic. That's a really interesting question for me. Similarly, if we're on Heroku, I might look is there a scheduler? And if so, what are the tasks that are running in the background? That's another entry point into the app. And so I like to think about it from that idea of entry points. If it's not on Heroku, and then there's some other system, like, I've used Cronic. I think it's Cronic, Whenever the Cron thing. Whenever, that's what it is, the Whenever gem that allows you to implement that, but it's in a file within the codebase, which as an aside, I really love that that's committed and expressive in the code. Then that's another interesting one to see. If it's more exotic than that, I may have to chase it down or ask someone, but I'll try and find what are all of the entry points and which are the ones that matter the most? I can drill down from there and see, okay, what code then supports these entry points into the application? I want to give an answer that also includes something like, oh, I do fancy static analysis in the codebase, and I do a churn versus complexity graph, and I start to...but I never do that, if we're being honest. The thing that I do is after that initial cursory scan of the landscape, I try and work on something that is relatively through the layers of the app, so not like, oh, I'll fix the text in a button. But like, give me something weird and ideally, let me pair with someone and then try and move through the layers of the app. So okay, here's our UI. We're rendering in this way. The controllers are integrated in this way, et cetera. This is our database. Try and get through all the layers if possible to try and get as holistic of a view of how the application works. The other thing that I think is really interesting about what you just said is you're like, I'm going to give some answers that are somewhat specific to a Rails app. And that totally makes sense to me because I know how to answer this in the context of a Rails app because those organizational patterns are so useful that I can hop into different Rails apps. And I've certainly seen ones that I'm like, this is odd and unfamiliar to me, but most of them are so much more discoverable because of that consistency. Whereas I have worked on a number of React apps, and every single one I come into, I'm like, okay, wait, what are we doing? How are we doing state management? What's the routing like? Are we server-side rendering, are we not? And it is a thing that...I see that community really moving in the direction of finding the meta frameworks that stitch the pieces together and provide more organizational structure and answer more of the questions out of the box. But it continues to be something that I absolutely love about Rails is that Rails answers so many of the questions for me. New people joining the team are like, oh, it's a Rails app, cool. I know how to Rails, and we get to run with that. And so that's more of a pitch for Rails than an answer to the question, but it is a thing that I felt in answering this question. [laughs] But yeah, those are some thoughts. But interested, it sounds like you had some more as well. I would love to hear what else was in your mind when you were thinking about this. STEPH: I do. And I want to highlight you said some really wonderful things. One that really stuck out to me that I had not considered is using Scout APM to look at heavily-trafficked endpoints. I have that on my list in regards as something that I want to know what's my error tracking, observability. Like, if I break something or if you give me a bug ticket to work on, what am I going to use? How am I going to understand what's going wrong? But I hadn't thought of it in terms of seeing which endpoints are heavily used. So I really liked that one. I also liked how you highlighted that you wish you'd do something fancy around doing a churn versus complexity kind of graph because I thought of that too. I was like, oh, that would be such a nice answer. But the truth is I also don't do that. I think it's all those things. I think it would be fun to make it easy. So I do that with new applications. But I agree; I typically more just dive in like, hey, give me a ticket. Let me go from there. I might do some simple command-line checking. So, for example, if I want to look through app models, let's find out which model is the largest. I may look for that to see do we have a God object or something like that? So I may look there. I just want to know how long are some of these files? But I also don't use a particular tool for that churn versus complexity. CHRIS: I think you hit the nail on the head with like, I wish that were easier or more in our toolset. But here on The Bike Shed, we tell the truth. And that is aspirational code flexing that we do not yet have. But I agree, that would be a really nice way to explore exactly what you're describing of, like, who are the God models? I'll definitely do that check, but not some of the more subtle and sophisticated show me the change over time of all these...like nah, that's not what I'm doing, much as I would like to be able to answer that way. STEPH: But it also feels like one of those areas like, it would be nice, but I would be intrigued to see how much I use that. That might be a nice anecdote to have. But I find the diving into the codebase to be more fruitful because I guess it depends on what I'm really looking at. Am I looking to see how complicated of a codebase this is? Because then I need to give more of a high-level review to someone to say how long I think it's going to take for me to work on a particular feature or before I'm joining a team, like, who do I think are good teammates that would then enjoy working on this application? That feels like a very different question to me versus the I'm already part of the team. I'm here. We're going to have complexity and churn. So I can just learn some of that over time. I don't have to know that upfront. Although it may be nice to just know at a high level, say like, okay, if I pick up a ticket, and then I look at that churn and complexity, to be like, okay, my ticket falls right smack-dab in the middle of that. So it's going to be a fun first week. That could be a fun fact. But otherwise, I'm not sure. I mean, yeah, I'd be intrigued to see how much it helps me. One other place that I do browse is I go to the gem file. I'm just always curious, what do people have in their tool bag? I want to see are there any gems that have been pulled in that are helping the team process some deprecated behavior? So something that's been pulled out of Rails but then pulled into a separate gem. So then that way, they don't have to upgrade just yet, or they can upgrade but then still keep some of that existing old deprecated behavior. That kind of stuff is interesting to me. And also, you called it earlier pairing. That's my other favorite way. I want to hear how people talk about the codebase, how they navigate. What are they frustrated by? What brings them joy? All of that is really helpful too. I think that covers all the ways that I immediately will go to when getting acquainted with a new codebase. CHRIS: I think that covers most of what I have in mind, although the question is framed in an interesting way that I think really speaks to the consultant mindset. How do I get acquainted with a new codebase? But if you take the question and flip it around sort of 180 degrees, I think the question can be reframed as how does an organization help people onboard into a codebase? And so everything we just described are like, here's what I do, here's how I would go about it, and pairing starts to get to collaboration. I think we've talked in a number of episodes about our thoughts on onboarding and being intentional with that, pairing people up. A lot of things we described it's like, it's ideal actually if the organization is pushing this. And you and I both worked as consultants for long enough that we're really in the mindset of like, all right, let's assume I'm just showing up. There's no one else there. They give me a laptop and no documentation and no other humans I'm allowed to talk to. How do I figure this out and get the next feature out to production? And ideally, it's something slightly better than that that we experience, but we're ready for whatever it is. Versus, most people are working within the context of an organization for a longer period of time. And most organizations should be thinking about it from the perspective of how do I help the new hires come into this codebase and become effective as quickly as possible? And so I think a lot of what we said can just be flipped around and said from the other way, like, pair them up, put them on a feature early, give them a walkthrough of the codebase, give them a sales-centric demo. Yeah, I feel equally about those things when said from the other side, but I do want to emphasize that this shouldn't be you're out there in the middle of the jungle with only a machete, and you got to figure out this codebase. Ideally, the organization is actually like, no, no, we'll help you. It's ours, so we know it. We can help you find the weird stuff. STEPH: That's a really nice distinction, though, because you're right; I hadn't really thought about this. I was thinking about this from more of the perspective of you're out in the jungle with a machete, minus we did mention pairing in there [laughs] and maybe a demo. I was approaching it more from you're isolated or more solo and then getting accustomed to the codebase versus if you have more people to lean on. But then that also makes me think of all the other processes that I didn't mention that I would include in that onboarding that you're speaking of, of like, how does this team work in terms of where do I push my code? What hooks are going to run? And then what do I wait for? How many people need to review my code? There are all those process-y questions that I think would ideally be included on the onboarding. But that has happened before, I mean, where we've joined projects, and it's been like, okay, good luck. Let us know if you need anything. And so then you do need those machete skills to then start hacking away. [laughs] CHRIS: We've been burned before. STEPH: They come in handy. [laughs] So when you are in that situation, and there's a comet that's coming to destroy earth, and there's a Rails application that is preventing this big doomsday, the question is, do you take astronauts and train them to be Rails experts, or do you take Rails developers and train them to be astronauts? I think that's the big question. CHRIS: What would Michael Bay do? STEPH: On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Josh Goldberg joins Nick, Chris & a very nasally-sounding KBall for a fun conversation around TypeScript ESLint. They discuss why we need ESLint when we have TypeScript, some useful rules in typescript-eslint, how it works, and a few hot takes along the way!

Josh Goldberg joins Nick, Chris & a very nasally-sounding KBall for a fun conversation around TypeScript ESLint. They discuss why we need ESLint when we have TypeScript, some useful rules in typescript-eslint, how it works, and a few hot takes along the way!

On today's episode, Sarah Dayan discusses open source sustainability with Nicholas Zakas, creator of ESLint. ESLint is a widely popular JavaScript linter with a giant ecosystem of third-party plugins. If you have a JavaScript project with a continuous integration, you are certainly using ESLint and you do not want it to fail. Nicholas is also a seasoned author who wrote several books about JavaScript since the early 2000s and more blog posts that you can probably afford to read.A recurring meme is that all modern digital infrastructure somehow depends on a project that some random person has been thanklessly maintaining for decades. Sustaining open source projects that support countless enterprise products has been a particularly hot topic in tech for the last couple of years.- How do you actively maintain a project that others rely on but doesn't bring revenue?- How do you deal with stress and fatigue?- Is the promise of open source still holding?Nicholas Zakas: @slicknet / humanwhocodes.comSarah Dayan: @frontstuff_io / sarahdayan.devESLint: @geteslint / eslint.orgAlgolia: @algolia / algolia.com