Podcasts about orms

In this episode of HTML All The Things, Mike chats with William Madden, Developer Advocate at Prisma, to uncover what makes modern ORMs essential in today's development workflows. They break down what an ORM is, why developers should care, and how Prisma sets itself apart in the crowded ORM space. William also dives into the technical challenges of building an ORM, the reasoning behind Prisma's shift from Rust binaries to TypeScript, and what's on the horizon for the platform. Whether you're deep in backend development or just getting started with databases, this episode offers insights you won't want to miss. Show Notes: https://www.htmlallthethings.com/podcasts/why-prisma-is-still-the-best-orm-w-william-madden Try out Prisma: https://www.prisma.io/docs/getting-started Use our affiliate link (https://scrimba.com/?via=htmlallthethings) for a 20% discount!! Full details in show notes.

Daten(banken) versionieren – klingt maximal unsexy, spart aber Stress im Deployment. Warum ohne Schema-Versionierung selbst kleine Änderungen große Probleme verursachen und was ORMs, Flyway oder Liquibase damit zu tun haben, erfahrt ihr hier. Daten historisieren ist ein Must-have für Compliance, Reproduzierbarkeit und Modellierung. Aber Achtung: Nicht jede Lösung passt für jede Datenbank und den Live-Betrieb. Wir geben Tipps, wie ihr eure Datenprodukte systematisch und effizient im Griff behaltet. **Zusammenfassung** Schema-Versionierung ist essenziell, um Änderungen an Datenbanken nachvollziehbar und reibungslos ins Deployment einzubinden Fehlende Versionierung kann zu kaputten Prozessen führen, wenn Schema-Änderungen nicht dokumentiert und automatisiert umgesetzt werden Werkzeuge wie ORMs, Flyway oder Liquibase helfen dabei, Änderungen an Datenbankschemata strukturiert zu verwalten Historisierung von Daten ist für Compliance, Reproduzierbarkeit und Modellierung entscheidend   Ansätze zur Datenhistorisierung: Append-only-Strategien vs. System-Versionierung Herausforderungen: Performance-Engpässe, hohe Pflegekosten und Kompatibilitätsprobleme je nach Datenbank und Migrationstool   Best Practices: Versionierung systematisch einführen, Automatisierung priorisieren und sicherstellen, dass Downgrades funktionieren.   **Links** #58: Arm, aber sexy: Data Warehousing at Scale ohne Budget https://www.podbean.com/ew/pb-gywt4-1719aef #52: In-process Datenbanken und das Ende von Big Data https://www.podbean.com/ew/pb-tekgi-16896e4 #36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1 Flyway: https://www.red-gate.com/products/flyway/ Liquibase: https://www.liquibase.com/ Alembic (für SQLAlchemy): https://alembic.sqlalchemy.org/en/latest/ MariaDB: https://mariadb.org/ ClickHouse: https://clickhouse.com/ Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

Prisma started as a GraphQL backend and pivoted into one of the most widely used ORMs in the world. Now, they've launched Prisma Postgres, and CEO Søren Bramer Schmidt is here to break down the journey, the challenges, and the massive technical innovations behind it—including bare-metal servers, Firecracker microVMs, and unikernels. If you care about databases, performance, or scaling, this one's for you.Want to learn more Postgres? Check out my Postgres course: https://masteringpostgres.com.Follow Søren:Twitter: https://twitter.com/sorenbsGitHub: https://github.com/prisma/prismaPrisma Postgres: https://www.prisma.io/postgresFollow Aaron:Twitter:  https://twitter.com/aarondfrancis LinkedIn: https://www.linkedin.com/in/aarondfrancisWebsite: https://aaronfrancis.com - find articles, podcasts, courses, and more.Chapters:00:00 - Introduction01:15 - The Origins of Prisma: From GraphQL to ORM02:55 - Why Firebase & Parse Inspired Prisma04:04 - The Pivot: From GraphQL to Prisma ORM06:00 - Why They Abandoned Backend-as-a-Service08:07 - The Open Source Business Model Debate10:15 - The Challenges of Monetizing an ORM12:42 - Building Prisma Accelerate & Pulse14:55 - How Prisma Accelerate Optimizes Database Access17:00 - Real-Time Database Updates with Prisma Pulse20:03 - How Prisma Pulse Handles Change Data Capture (CDC)23:15 - Users Wanted a Hosted Database (Even When Prisma Didn't)25:40 - Why Prisma Finally Launched Prisma Postgres27:32 - Unikernels, Firecracker MicroVMs & Running Millions of Databases31:10 - Bare Metal Servers vs. AWS: The Controversial Choice34:40 - How Prisma Routes Queries for Low Latency38:02 - Scaling, Cost Efficiency & Performance Benefits42:10 - The Prisma Postgres Roadmap & Future Features45:30 - Why Prisma is Competing with AWS & The Big Cloud Players48:05 - Final Thoughts & Where to Learn More

John McRae, Director of Orms, rejoins the virtual couch four years on from his first visit and this time with new Orms Director, Miranda MacLaren. The conversation with Rachel and Louise explores practice resilience and diversification and the decision as part of those aims to bring in new directors from other practices. www.orms.co.uk Coaches On The Couch is co-hosted by Louise Rodgers and Rachel Birchmore who are exec and leadership coaches. They design and deliver bespoke leadership development programmes and coaching for architects, engineers and other consultancies across the built environment. For more info

ACCC's Oncology Reimbursement Meetings (ORMs) assist members in navigating the frequent changes in oncology reimbursement and regulations through expert-led sessions in different regions across the US. In addition to bringing attendees up to speed on annual updates to the revenue cycle, a wide range of related issues that can impact oncology reimbursement are brought to the table, including navigation reimbursement, expanding existing financial programs, and providing important services for patients. The dates and locations for the Spring 2025 in-person ORMs have been announced, with more information to follow. Guest:  John J. Montville, MBA, FACHE, FACMPE, FACCC, COA Executive Director, Oncology Service Line Mercy Health – Paducah Cancer Center Quote:  “These meetings have true takeaways. It's not just about networking [although] that is important in this industry...You walk away with pages of notes of things you want to bring back to your program to make it better.” For more information about ACCC's upcoming Oncology Reimbursement Meetings in 2025, visit the ACCC website. Additional Resources:  Reimbursement Changes Seek to Reduce Disparities in Access to Cancer Care Breaking Down Principal Illness Navigation Services: Helping Oncology Providers and Administrators Document, Code, and Bill for Patient Navigation Services The Centers for Medicare & Medicaid Services Will Pay for Patient Navigation—Now What – Oncology Issues Virtual Fall 2024 Oncology Reimbursement Meeting

On this episode of the Crazy Wisdom Podcast, host Stewart Alsop is joined by Yury Selivanov, the CEO and co-founder of EdgeDB, for a fascinating discussion about the reinvention of relational databases. Yury explains how EdgeDB addresses modern application development challenges by improving developer experience and rethinking decades-old database paradigms. They explore how foundational technologies evolve, the parallels between software and real-world systems like the electrical grid, and the emerging role of AI in coding and system design. You can connect with Yury through his personal Twitter account @1st1 (https://twitter.com/1st1) and EdgeDB's official Twitter @EdgeDatabase (https://twitter.com/edgedatabase).Check out this GPT we trained on the conversation!Timestamps00:00 Introduction to the Crazy Wisdom Podcast00:27 What is EdgeDB?00:58 The Evolution of Databases04:36 Understanding SQL and Relational Databases07:48 The Importance of Database Relationships09:27 Schema vs. No-Schema Databases14:14 EdgeDB: SQL 2.0 and Developer Experience23:09 The Future of Databases and AI Integration26:43 AI's Role in Software Development27:20 Challenges with AI-Generated Code29:56 Human-AI Collaboration in Coding34:00 Future of Programming Languages44:28 Junior Developers and AI Tools50:02 EdgeDB's Vision and Future PlansKey InsightsReimagining Relational Databases: Yury Selivanov explains how EdgeDB represents a modern rethinking of relational databases. Unlike traditional databases designed with 1970s paradigms, EdgeDB focuses on improving developer experience by introducing object-oriented schemas and hierarchical query capabilities, bridging the gap between modern programming needs and legacy systems.Bridging Data Models and Code: A key challenge in software development is the object-relational impedance mismatch, where relational database tables do not naturally map to object-based data models in programming languages. EdgeDB addresses this by providing a high-level data model and query language that aligns with how developers think and work, eliminating the need for complex ORMs.Advancing Query Language Design: Traditional SQL, while powerful, can be cumbersome for application development. EdgeDB introduces EdgeQL, a modern query language designed for readability, hierarchical data handling, and developer productivity. This new language reduces the friction of working with relational data in real-world software projects.AI as a Tool, Not a Replacement: While AI has transformed coding productivity, Yury emphasizes that it is a tool to assist, not replace, developers. LLMs like GPT can generate code, but the resulting systems still require human oversight for debugging, optimization, and long-term maintenance, highlighting the enduring importance of experienced engineers.The Role of Schema in Data Integrity: Schema-defined databases like EdgeDB allow developers to codify business logic and enforce data integrity directly within the database. This reduces the need for application-level checks, simplifying the codebase while ensuring robust data consistency—a feature that remains critical even in the era of AI.Integrating AI into Databases: EdgeDB is exploring innovative integrations of AI, such as automatic embedding generation and retrieval-augmented generation (RAG) endpoints, to enhance data usability and simplify complex workflows. These capabilities position EdgeDB as a forward-thinking tool in the rapidly evolving landscape of AI-enhanced software.Balancing Adoption and Usability: To encourage adoption, EdgeDB is incorporating familiar tools like SQL alongside its advanced features, lowering the learning curve for new users. This approach combines innovation with accessibility, ensuring that developers can transition seamlessly to the platform while benefiting from its modern capabilities.

 In today's episode, Charles, Steve, and AJ, are joined by back-end engineer and team lead at Homebound, Stephen Haberman. We delve into the fascinating world of SQL c and its revolutionary approach to managing SQL queries with dedicated SQL files, delivering benefits such as reduced typing errors and pre-deployment checks. Stephen also walks us through the advantages and limitations of ORMs versus query builders like Prisma and Drizzle, sharing insights into Joyce ORM's unique philosophy and simplified CRUD operations.They explore the intricacies of Domain Driven Design (DDD), its emphasis on ubiquitous language, and how it shapes business logic and storage management. AJ contributes by discussing the potential of SQL c and Slonik for dynamic query building. Additionally, they discuss Steven's innovative work with GraphFileWorker and GrafAST, highlighting the performance improvements in GraphQL backends. Whether you're intrigued by the technicalities of ORMs, the evolution of database tools, or just love a good anecdote, this episode packed with technical insights and lively discussions is one you won't want to miss. Join them on this journey into the world of database management and development!SocialsLinkedIn: Stephen HabermanPicks AJ - TypeScript to JSDocAJ - MySQL to TypeScriptAJ - sqlcAJ - Slonik (Node + Postgres)AJ - SwiftUI EssentialsAJ - Introduction to SwiftUI AJ - Trump, but not saying dumb thingsCharles - Biblios | Board GameCharles - FreeStyle Libre 3 System | Continuous Glucose MonitoringStephen - Grafast | GrafastBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Erik Darling makes your database faster in exchange for money. He is a DBA, developer, and architect with a track record of tackling even the most challenging technical issues. He runs a SQL Server Consulting and Coaching practice. In addition to his consulting services, he is also passionate about blogging, training, and contributing to open-source projects that help with SQL Server troubleshooting. He's given many public speaking engagements on the topic at conferences and events around the world, like PASS Summit and SQLBits.   Topics of Discussion: [2:57] Eric's journey into SQL Server and database performance tuning. [4:25] Challenges faced in early SQL Server work and evolving technical debt. [7:47] The standard problems with databases over time. [11:14] How technical debt shows up in SQL Server databases. [15:20] How abstraction layers like ORMs contribute to technical debt. [22:38] Performance issues as a result of technical debt in databases. [25:19] Key advice on database schema design to improve performance. [30:46] Key differences between Azure SQL DB and managed instances. [37:23] Staffing challenges and solutions for managing SQL Server environments.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Darling Data Darling Data on X Erik Darling Darling Data on LinkedIn Darling Data on TikTok   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

IntroductionIn this episode of Maintainable, Robby speaks with Lutz Hühnken, Head of Engineering Excellence at Upvest, about the transformative power of event-driven architecture in software development. Lutz brings his extensive experience to the table, discussing how breaking down complex systems into manageable modules and leveraging event-driven design can lead to more resilient and maintainable software.Topics Discussed[00:05:32] Introduction to Well-Maintained Software: Lutz shares his thoughts on the key characteristics of maintainable software, emphasizing modularity and simplicity.[00:10:24] Challenges with "Magic" in Code: The pitfalls of relying too much on frameworks and ORMs, including examples from Lutz's experience with Hibernate.[00:11:16] Understanding Event-Driven Architecture: Lutz explains the fundamentals of event-driven architecture and its advantages over traditional command-driven approaches.[00:13:50] The Role of Promises in Event-Driven Systems: How clear design-time responsibilities ensure reliability in event-driven communication.[00:15:43] Choreography vs. Orchestration: The debate between these two approaches to managing workflows and why Lutz favors choreography for most systems.[00:17:57] Onboarding Developers in Event-Driven Systems: Tips for effectively integrating new team members into an event-driven architecture.[00:26:52] The Role of Engineering Excellence at Upvest: Lutz discusses his new role and the importance of systems thinking in guiding architectural decisions.[00:34:55] Managing Technical Debt: Lutz offers insights into balancing feature development with addressing technical debt, emphasizing the importance of a healthy investment distribution.Key TakeawaysBreaking down large systems into smaller modules with clear boundaries can significantly enhance maintainability.Event-driven architecture offers a powerful way to decouple system components, making them more resilient and scalable.Developers should be cautious of "magic" in code, such as heavy reliance on ORMs, which can obscure underlying complexities and hinder maintainability.Choreography often provides a more scalable and maintainable approach than orchestration in managing complex workflows.Technical debt should be managed proactively, with regular investments in refactoring and productivity enhancements to maintain long-term software health.Resources MentionedLutz Hühnken's BlogEvent-Driven Architecture by Martin FowlerThe Open Society and Its Enemies by Karl PopperConnect with Lutz HühnkenLinkedInTwitterThanks 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 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! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Matt is a Microsoft Data Platform MVP and has worked with SQL Server since 2000. He is the leader of the Lexington, KY Data Technology Group and a frequent domestic and international community speaker. He's an IDERA ACE alumnus and Redgate Community Ambassador. His original data professional role was in database development, which quickly evolved into query tuning work that further evolved into being a DBA in the healthcare realm. He has supported several critical systems utilizing SQL Server and managed dozens of live site SQL Server implementations. As a Microsoft Lead Data Architect at Centric Consulting, he works with customers large, medium, and small to migrate to the cloud, make their data estate operate efficiently, and find the right tools and solutions within the Microsoft Data Platform.   Topics of Discussion: [3:08] Matt's career journey and overcoming a fear of public speaking. [5:42] Changes and consistencies in working with SQL Server over the years. [7:18] Advice on the process and tools for database change management and DevOps. [12:29] Recommendations for database monitoring and observability. [19:30] Specific monitoring tool recommendations and their pros and cons. [24:04] The role of ORMs and their impact on database performance. [30:59] Thoughts on the evolution of microservices and database architecture patterns. [36:55] Considerations for working with small versus large database sizes.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! SQLBITS Author Matt Gordon Matt Gordon Microsoft Page Matt Gordon on LinkedIn Racing FivecoRacing IG   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

In this episode, the hosts discuss their experiences with different codebases, from the best they've worked on to the worst. They explore the complexities of evolving and maintaining legacy code, the challenges of debugging, and the importance of clean architecture. Key points include the pain of working with ORMs, and the impact of early design decisions on long-term project health. They also touch on reactivity concerns in modern frameworks and share personal anecdotes of both successful and problematic coding practices.Follow the show and be sure to join the discussion on Discord! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. New episodes drop weekly on Wednesday.And, if you're feeling the love, support us on Patreon.With audio editing and engineering by ZCross Media.Full show notes and transcript here.

BuffStampede.com publisher Adam Munsterteiger catches up with Parker Orms, who led Wheat Ridge to a state championship then played at CU from 2009-13. Orms owns "Hats by Parker Thomas," a cowboy hat fitting company, which has re-connected him with the Buffs.

Scott and Wes chat with Alex Blokh and Andrew Sherman, the co-founders of Drizzle ORM, about building a modern ORM from the ground up. They dive into the importance of type safety, creating filters with Drizzle, and the differences between Drizzle and other ORMs like Prisma. Show Notes 00:00 Welcome to Syntax! Syntax × Drizzle Swag. 01:15 What is Drizzle? 02:36 The genesis of Drizzle. 04:15 The process of building an ORM. 05:38 ‘100% Type-Safe' and why that's not a great goal. 07:50 Who is responsible for writing the complicated TypeScript? 09:40 Is an ORM necessary for anyone working with data? 12:15 Creating a product that fits different complexities. 13:19 Brought to you by Sentry.io. 13:44 Creating filters in Drizzle. Callback-based, or imported. Why? 19:22 Drizzle vs Prisma vs Kysely. 22:45 Are you friendly with Prisma? 23:35 Relational queries. 25:17 Query vs select. 27:42 Maintaining so many different technologies. 30:37 Switching databases. 31:39 Drizzle Studio. Drizzle Studio Syntax Theme. 35:00 Accessing Cloudflare D1 SQLite requires connection through a worker. 37:40 Drizzle Kit. 41:37 Will you ever support MongoDB? 42:10 Supporting PGlite and local data storage landscape. DrizzleORM v0.30.6 release notes. 44:00 Being a developer in Ukraine in 2024. How to support Ukraine: Savelife, United24. 51:07 Drizzle is expanding. 53:50 Sick Picks + Shameless Plugs. Sick Picks Andrew - Smart Swim Goggles. Shameless Plugs Andrew - Savelife, United24. Scott - Syntax × Drizzle 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

Episode Notes Our guest is Lukas Eder, creator of jOOQ (https://jooq.org/) - a fluent Java API for SQL building and execution. In this episode, JUXT Head of Product Jeremy Taylor and Lukas Eder discuss the often under-appreciated power and significance of SQL for developers, and how Lukas' jOOQ library helps Java developers sidestep the pitfalls of ORMs. Lukas has been developing jOOQ since 2009 and has diligently supported many thousands of companies with their use of relational databases since then. He has written huge amounts of documentation and blogged extensively to advocate for SQL. As mentioned during the introduction, the inspiration behind recording this episode was an excellent talk Lukas gave a few years ago titled "How Modern SQL Databases Come up with Algorithms that You Would Have Never Dreamed Of": https://www.youtube.com/embed/wTPGW1PNy_Y?si=hfxju9VPSfhlIb70.

Episode 77: In this episode of Critical Thinking - Bug Bounty Podcast Joel and Justin discuss some fresh writeups including some MongoDB injections, ORMs, and exploits in Kakao and iOS before pivoting into a conversation about staying motivated and avoiding burnout while hunting.Follow us on twitter at: @ctbbpodcastWe're new to this podcasting thing, so feel free to send us any feedback here: info@criticalthinkingpodcast.ioShoutout to YTCracker for the awesome intro music!------ Links ------Follow your hosts Rhynorater & Teknogeek on twitter:https://twitter.com/0xteknogeekhttps://twitter.com/rhynorater------ Ways to Support CTBBPodcast ------Hop on the CTBB Discord at https://ctbb.show/discord!We also do Discord subs at $25, $10, and $5 - premium subscribers get access to private masterclasses, exploits, tools, scripts, un-redacted bug reports, etc.Resources:MongoDB NoSQL Injectionhttps://soroush.me/blog/2024/06/mongodb-nosql-injection-with-aggregation-pipelines/Mongo DB Is Web Scalehttps://www.youtube.com/watch?v=b2F-DItXtZs1-click Exploit in Kakaohttps://stulle123.github.io/posts/kakaotalk-account-takeover/Unsecure time-based secret and Sandwich Attackhttps://www.aeth.cc/public/Article-Reset-Tolkien/secret-time-based-article-en.htmlReset Tolkienhttps://github.com/AethliosIK/reset-tolkieniOS URL Scheme Hijacking Revampedhttps://evanconnelly.github.io/post/ios-oauth/PLORMBING YOUR DJANGO ORMhttps://www.elttam.com/blog/plormbing-your-django-orm/#contentTimestamps:(00:00:00) Introduction(00:02:07) MongoDB NoSQL Injection(00:12:42) 1-click Exploit in Kakao(00:33:21) Time-based secrets and Reset Tolkien(00:39:26) iOS URL Scheme Hijacking Revamped(00:51:42) ORMs(00:58:57) Community Bug Submission(01:07:45) Motivation, Mental Sharpness, and Burnout avoidance

Scott and CJ dive into the world of SQLite Cloud with special guests Brian Holt and Marco Bambini. They explore why SQLite is gaining traction, its unique features, and the misconceptions surrounding its use—let's get into it! Show Notes 00:00 Welcome to Syntax! 01:20 Who is Brian Holt? 02:26 Who is Marco Bambini? 05:12 Why are people starting to talk so much about SQLite now? 08:47 What makes SQLite special or interesting? 09:46 What is a big misconception about SQLite? 11:13 Installed by default in operating systems. 12:03 A perception that SQLite is intended for single users. 13:36 Convincing developers it's a full-featured solution. 15:11 What does SQLite do better than Postgres or MySQL? 17:30 SQLite Cloud & local first features. 20:38 Where does SQLite store the offline information? 23:08 Are you typically reaching for ORMs? 25:00 What is SQLite Cloud? 27:29 What makes for an approachable software? 29:18 What make SQLite cloud different from other hosted SQLite options? 32:13 Is SQLite still evolving? 34:40 What about branching? 37:37 What is the GA timeline? 40:04 How does SQLite actually work? 41:19 Questions about security. 44:28 But does it scale? 45:52 Sick Picks + Shameless Plugs. Sick Picks Brian: Trainer Road Marco: Tennis Shameless Plugs Brian: SQLite Cloud, Frontend Masters - Containers. 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

The ACCC Oncology Reimbursement Meetings (ORMs) help all members of the multidisciplinary cancer care team navigate the annual changes in oncology reimbursement and regulations— while improving their knowledge on effective strategies for success in an everchanging oncology landscape. In this episode, CANCER BUZZ speaks with Jordan Karwedsky, financial counselor, Green Bay Oncology, about her session at the ORMs last fall, where she discussed best practices cancer care teams can adopt as they prepare for the open enrollment season.   “If you have a patient who is uninsured or underinsured, make a note that is a reminder for you so come November when open enrollment begins, you can reach out to them and help them optimize their insurance. In the meantime, if they need treatment, then work with the drug companies to save them as much money on their treatment.”   “Highlights from recent ORMs include how to work with your legislature, either at the state or federal level, to advocate for laws that will help patients.”   Jordan Karwedsky Financial Counselor    Green Bay Oncology     In one of the upcoming ORMs this spring, Karwedsky will share strategies for patient navigation in the digital age. For more information, please visit the ACCC website. Resources: ·      Preparing for Open Enrollment ·      ACCC Financial Advocacy Network ·      ACCC Financial Advocacy Boot Camp ·      ACCC Patient Assistance & Reimbursement Guide ·      Patient Navigation: Taking Stock of the Past and Looking to the Future

We chat with Gwen Shapira, co-founder of Nile, about her journey to creating a virtualized, serverless Postgres database service. We also dive into the challenges with traditional data architectures and approaches like ORMs. Discuss this episode: ⁠⁠discord.gg/XVKD2uPKyF

Langt om længe kan Trollefar igen sætte sig bag mikrofonen, og det udnytter han til fulde. Han har nemlig fået lov til at sætte sig på stort set hele playlisten, så I kan for lov til at lytte til alt det heavy, han har skubbet barnevogn til under barslen. Vi har dog også besøg af Orms nye faste medlem, Malthe Yde Tiufkær, der fortæller lidt om, hvordan det er at træde ind i et kreativt fæstningsværk som Orm. Og så skal vi naturligvis også snakke om den allerede mythologiske koncert i DR's Koncerthus. Og så sker der simpelthen det, at Sort Søndag i denne uge er klar med decideres breaking news. I hvert fald for alle fans af 00'ernes metaldanmark. Lyt med og find ud af, hvad det er vi sidder på. Værter: Anders Bøtter og Jakob Trolle. Medvirkende: Malthe Yde Tiufkær (Orm). Udsendelse nr. 612. Sort Søndag er Danmarks vigtigste metal podcast. Hver uge får du 1 times tonser tunge toner, i selskab med værterne Anders Bøtter og Jakob Trolle. Sort Søndags trofaste "Giro 666 lyttere" byder ind med både nye og gamle numre, "Musiknyt" sørger for at holde dig helt opdateret og hver måned gennemgås et klassisk metal album i "Månedens Mesterværk".

On this episode of the podcast, cEDH Sylvan Scholars Bear Claymore and Orms_By_Gore join the show to discuss the Sylvan Scholars project and how it works to bring new folks into this end of the format. We also discuss how to entice new players to try cEDH by providing resources to learn how to play. You can find everything Sylvan Scholars here: https://www.bearclaymore.com/sylvanscholars You can find all MTG In Quarantine content here: https://linktr.ee/mtginquarantine You can get 10% off your QuiverTime order at quivertime.com by using promo code "mtgiq" at checkout.

On today's episode, Erik Murdock returns to take a deep dive into an issue that Access Fund and the climbing community have worked on for decades: how fixed anchors are managed in Wilderness areas. It's an issue that requires context, history, and nuance, which is what this episode delivers. Erik begins with a thorough history of climbing in America's Wilderness areas, then we get into the finer details of why managing fixed anchors in these places is a big deal right now. As Erik explains, recently released guidance from the National Park Service and US Forest Service will have serious implications if implemented. Join us for a deep dive into this issue, and submit your comment to the NPS and USFS on their management guidance before January 16th here. 5:12- The early conversations around wilderness - are fixed anchors allowable or prohibited? 8:28- Erik's opening on fixed anchors and wilderness 27:04- Why are fixed anchors being managed now? 30:42- Managing fixed anchors outside of wilderness 41:13- Climbers supporting past wilderness designations 51:23- Protect America's Rock Climbing (PARC) Act 59:26- Minimum Requirements Analysis (MRA) in more depth 1:04:35- Will fixed hardware be removed from existing routes? 1:09:27- Where do we go from here? Wilderness Climbing FAQ: https://www.accessfund.org/latest-news/wilderness-climbing-faq Bolt Prohibition Action Alert: https://www.accessfund.org/latest-news/action-alert-stop-the-bolt-prohibition National Park Service Comment Submission Form (due by Jan 16th, 2024): https://parkplanning.nps.gov/commentForm.cfm?documentID=132387 US Forest Service Comment Submission Form (due by Jan 16th, 2024): https://cara.fs2c.usda.gov/Public/CommentInput?project=ORMS-3524

SQL is Dead, Long Live SQL!Fast jede Applikation hat irgendeine Form von persistenter Datenhaltung. Oft in Form einer Datenbank. Der Platzhirsch bei Datenbanken sind Systeme, die sich mit der Structured Query Language (kurz SQL) abfragen lassen. MySQL, PostgreSQL, Oracle, MSSQL Server, sqlite, Google BigQuery und so weiter.Die coolen Kids haben vielleicht irgendeine Form von NoSQL-Datenbank im Einsatz. Aber auch da kommt man nicht um SQL herum.Für die meisten Entwickler*innen ist SQL ein alter Hut. SELECT * FROM Tabelle WHERE foo = bar GROUP BY id. Das haben wohl die meisten gelernt und damit kommt man schon sehr weit. Doch war es das mit den Möglichkeiten von SQL? Klare Antwort: Nein.Die Sprache wird weiterentwickelt, bekommt moderne Features und hat weitaus mehr zu bieten als manch einer denkt. Und darüber sprechen wir in dieser Episode mit dem SQL-Experten Markus Winand.Wir sprechen über Modernes SQL, die verschiedenen SQL Standards, ORMs und die Trennung von “Daten-Logik” und “Application-Logik” sowie über eine “Can I Use”-Platform für SQL Features.Bonus: Warum die Übernahme von MySQL durch Oracle das Beste war, was MySQL passieren konnte.Das schnelle Feedback zur Episode:

Clint Orms shares his story from rodeo beginnings to leading the thriving Clint Orms Engraving today. Tune in to hear Clint share the captivating story of his personal and professional evolution, offering an inspiring glimpse into the promising future of Western craftsmanship. Listen in...Guests and Links Episode 120:Hosts: Mike Donnell, Kacee Willbanks Colletti, and Sophia JagellaGuest: Clint OrmsVisit the WESA Website

Clint Orms shares his story from rodeo beginnings to leading the thriving Clint Orms Engraving today. Tune in to hear Clint share the captivating story of his personal and professional evolution, offering an inspiring glimpse into the promising future of Western craftsmanship. Listen in...Guests and Links Episode 120:Hosts: Mike Donnell, Kacee Willbanks Colletti, and Sophia JagellaGuest: Clint OrmsVisit the WESA Website

Laurent Doguin, Director of Developer Relations & Strategy at Couchbase, joins Corey on Screaming in the Cloud to talk about the work that Couchbase is doing in the world of databases and developer relations, as well as the role of AI in their industry and beyond. Together, Corey and Laurent discuss Laurent's many different roles throughout his career including what made him want to come back to a role at Couchbase after stepping away for 5 years. Corey and Laurent dig deep on how Couchbase has grown in recent years and how it's using artificial intelligence to offer an even better experience to the end user.About LaurentLaurent Doguin is Director of Developer Relations & Strategy at Couchbase (NASDAQ: BASE), a cloud database platform company that 30% of the Fortune 100 depend on.Links Referenced: Couchbase: https://couchbase.com XKCD #927: https://xkcd.com/927/ dbdb.io: https://dbdb.io DB-Engines: https://db-engines.com/en/ Twitter: https://twitter.com/ldoguin LinkedIn: https://www.linkedin.com/in/ldoguin/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Are you navigating the complex web of API management, microservices, and Kubernetes in your organization? Solo.io is here to be your guide to connectivity in the cloud-native universe!Solo.io, the powerhouse behind Istio, is revolutionizing cloud-native application networking. They brought you Gloo Gateway, the lightweight and ultra-fast gateway built for modern API management, and Gloo Mesh Core, a necessary step to secure, support, and operate your Istio environment.Why struggle with the nuts and bolts of infrastructure when you can focus on what truly matters - your application. Solo.io's got your back with networking for applications, not infrastructure. Embrace zero trust security, GitOps automation, and seamless multi-cloud networking, all with Solo.io.And here's the real game-changer: a common interface for every connection, in every direction, all with one API. It's the future of connectivity, and it's called Gloo by Solo.io.DevOps and Platform Engineers, your journey to a seamless cloud-native experience starts here. Visit solo.io/screaminginthecloud today and level up your networking game.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. This promoted guest episode is brought to us by our friends at Couchbase. And before we start talking about Couchbase, I would rather talk about not being at Couchbase. Laurent Doguin is the Director of Developer Relations and Strategy at Couchbase. First, Laurent, thank you for joining me.Laurent: Thanks for having me. It's a pleasure to be here.Corey: So, what I find interesting is that this is your second time at Couchbase, where you were a developer advocate there for a couple of years, then you had five years of, we'll call it wilderness I suppose, and then you return to be the Director of Developer Relations. Which also ties into my personal working thesis of, the best way to get promoted at a lot of companies is to leave and then come back. But what caused you to decide, all right, I'm going to go work somewhere else? And what made you come back?Laurent: So, I've joined Couchbase in 2014. Spent about two or three years as a DA. And during those three years as a developer advocate, I've been advocating SQL database and I—at the time, it was mostly DBAs and ops I was talking to. And DBA and ops are, well, recent, modern ops are writing code, but they were not the people I wanted to talk to you when I was a developer advocate. I came from a background of developer, I've been a platform engineer for an enterprise content management company. I was writing code all day.And when I came to Couchbase, I realized I was mostly talking about Docker and Kubernetes, which is still cool, but not what I wanted to do. I wanted to talk about developers, how they use database to be better app, how they use key-value, and those weird thing like MapReduce. At the time, MapReduce was still, like, a weird thing for a lot of people, and probably still is because now everybody's doing SQL. So, that's what I wanted to talk about. I wanted to… engage with people identify with, really. And so, didn't happen. Left. Built a Platform as a Service company called Clever Cloud. They started about four or five years before I joined. We went from seven people to thirty-one LFs, fully bootstrapped, no VC. That's an interesting way to build a company in this age.Corey: Very hard to do because it takes a lot of upfront investment to build software, but you can sort of subsidize that via services, which is what we've done here in some respects. But yeah, that's a hard road to walk.Laurent: That's the model we had—and especially when your competition is AWS or Azure or GCP, so that was interesting. So entrepreneurship, it's not for everyone. I did my four years there and then I realized, maybe I'm going to do something else. I met my former colleagues of Couchbase at a software conference called Devoxx, in France, and they told me, “Well, there's a new sheriff in town. You should come back and talk to us. It's all about developers, we are repositioning, rehandling the way we do marketing at Couchbase. Why not have a conversation with our new CMO, John Kreisa?”And I said, “Well, I mean, I don't have anything to do. I actually built a brewery during that past year with some friends. That was great, but that's not going to feed me or anything. So yeah, let's have a conversation about work.” And so, I talked to John, I talked to a bunch of other people, and I realized [unintelligible 00:03:51], he actually changed, like, there was a—they were purposely going [against 00:03:55] developer, talking to developer. And that was not the case, necessarily, five, six years before that.So, that's why I came back. The product is still amazing, the people are still amazing. It was interesting to find a lot of people that still work there after, what, five years. And it's a company based in… California, headquartered in California, so you would expect people to, you know, jump around a bit. And I was pleasantly surprised to find the same folks there. So, that was also one of the reasons why I came back.Corey: It's always a strong endorsement when former employees rejoin a company. Because, I don't know about you, but I've always been aware of those companies you work for, you leave. Like, “Aw, I'm never doing that again for love or money,” just because it was such an unpleasant experience. So, it speaks well when you see companies that do have a culture of boomerangs, for lack of a better term.Laurent: That's the one we use internally, and there's a couple. More than a couple.Corey: So, one thing that seems to have been a thread through most of your career has been an emphasis on developer experience. And I don't know if we come at it from the same perspective, but to me, what drives nuts is honestly, with my work in cloud, bad developer experience manifests as the developer in question feeling like they're somehow not very good at their job. Like, they're somehow not understanding how all this stuff is supposed to work, and honestly, it leads to feeling like a giant fraud. And I find that it's pernicious because even when I intellectually know for a fact that I'm not the dumbest person ever to use this tool when I don't understand how something works, the bad developer experience manifests to me as, “You're not good enough.” At least, that's where I come at it from.Laurent: And also, I [unintelligible 00:05:34] to people that build these products because if we build the products, the user might be in the same position that we are right now. And so, we might be responsible for that experience [unintelligible 00:05:43] a developer, and that's not a great feeling. So, I completely agree with you. I've tried to… always on software-focused companies, whether it was Nuxeo, Couchbase, Clever Cloud, and then Couchbase. And I guess one of the good thing about coming back to a developer-focused era is all the product alignments.Like, a lot of people talk about product that [grows 00:06:08] and what it means. To me what it means was, what it meant—what it still means—building a product that developer wants to use, and not just want to, sometimes it's imposed to you, but actually are happy to use, and as you said, don't feel completely stupid about it in front of the product. It goes through different things. We've recently revamped our Couchbase UI, Couchbase Capella UI—Couchbase Capella is a managed cloud product—and so we've added a lot of in-product getting started guidelines, snippets of code, to help developers getting started better and not have that feeling of, “What am I doing? Why is it not working and what's going on?”Corey: That's an interesting decision to make, just because historically, working with a bunch of tools, the folks who are building the documentation working with that tool, tend to generally be experts at it, so they tend to optimize for improving things for the experience of someone has been using it for five years as opposed to the newcomer. So, I find that the longer a product is in existence, in many cases, the worse the new user experience becomes because companies tend to grow and sprawl in different ways, the product does likewise. And if you don't know the history behind it, “Oh, your company, what does it do?” And you look at the website and there's 50 different offerings that you have—like, the AWS landing page—it becomes overwhelming very quickly. So, it's neat to see that emphasis throughout the user interface on the new developer experience.On the other side of it, though, how are the folks who've been using it for a while respond to those changes? Because it's frustrating for me at least, when I log into a new account, which happens periodically within AWS land, and I have this giant series of onboarding pop-ups that I have to click to make go away every single time. How are they responding to it?Laurent: Yeah, it's interesting. One of the first things that struck me when I joined Couchbase the first time was the size of the technical documentation team. Because the whole… well, not the whole point, but part of the reason why they exist is to do that, to make sure that you understand all the differences and that it doesn't feel like the [unintelligible 00:08:18] what the documentation or the product pitch or everything. Like, they really, really, really emphasize on this from the very beginning. So, that was interesting.So, when you get that culture built into the products, well, the good thing is… when people try Couchbase, they usually stick with Couchbase. My main issue as a Director of the Developer Relations is not to make people stick with Couchbase because that works fairly well with the product that we have; it's to make them aware that we exist. That's the biggest issue I have. So, my goal as DevRel is to make sure that people get the trial, get through the trial, get all that in-app context, all that helps, get that first sample going, get that first… I'm not going to say product built because that's even a bit further down the line, but you know, get that sample going. We have a code playground, so when you're in the application, you get to actually execute different pieces of code, different languages. And so, we get those numbers and we're happy to see that people actually try that. And that's a, well, that's a good feeling.Corey: I think that there's a definite lack of awareness almost industry-wide around the fact that as the diversity of your customers increases, you have to have different approaches that meet them at various points along the journey. Because things that I've seen are okay, it's easy to ass—even just assuming a binary of, “Okay, I've done this before a thousand times; this is the thousand and first, I don't need the Hello World tutorial,” versus, “Oh, I have no idea what I'm doing. Give me the Hello World tutorial,” there are other points along that continuum, such as, “Oh, I used to do something like this, but it's been three years. Can you give me a refresher,” and so on. I think that there's a desire to try and fit every new user into a predefined persona and that just doesn't work very well as products become more sophisticated.Laurent: It's interesting, we actually have—we went through that work of defining those personas because there are many. And that was the origin of my departure. I had one person, ops slash DBA slash the person that maintain this thing, and I wanted to talk to all the other people that built the application space in Couchbase. So, we broadly segment things into back-end, full-stack, and mobile because Couchbase is also a mobile database. Well, we haven't talked too much about this, so I can explain you quickly what Couchbase is.It's basically a distributed JSON database with an integrated caching layer, so it's reasonably fast. So it does cache, and when the key-value is JSON, then you can create with SQL, you can do full-text search, you can do analytics, you can run user-defined function, you get triggers, you get all that actual SQL going on, it's transactional, you get joins, ANSI joins, you get all those… windowing function. It's modern SQL on the JSON database. So, it's a general-purpose database, and it's a general-purpose database that syncs.I think that's the important part of Couchbase. We are very good at syncing cluster of databases together. So, great for multi-cloud, hybrid cloud, on-prem, whatever suits you. And we also sync on the device, there's a thing called Couchbase Mobile, which is a local database that runs in your phone, and it will sync automatically to the server. So, a general-purpose database that syncs and that's quite modern.We try to fit as much way of growing data as possible in our database. It's kind of a several-in-one database. We call that a data platform. It took me a while to warm up to the word platform because I used to work for an enterprise content management platform and then I've been working for a Platform as a Service and then a data platform. So, it took me a bit of time to warm up to that term, but it explained fairly well, the fact that it's a several-in-one product and we empower people to do the trade-offs that they want.Not everybody needs… SQL. Some people just need key-value, some people need search, some people need to do SQL and search in the same query, which we also want people to do. So, it's about choices, it's about empowering people. And that's why the word platform—which can feel intimidating because it can seem complex, you know, [for 00:12:34] a lot of choices. And choices is maybe the enemy of a good developer experience.And, you know, we can try to talk—we can talk for hours about this. The more services you offer, the more complicated it becomes. What's the sweet spots? We did—our own trade-off was to have good documentation and good in-app help to fix that complexity problem. That's the trade-off that we did.Corey: Well, we should probably divert here just to make sure that we cover the basic groundwork for those who might not be aware: what exactly is Couchbase? I know that it's a database, which honestly, anything is a database if you hold it incorrectly enough; that's my entire shtick. But what is it exactly? Where does it start? Where does it stop?Laurent: Oh, where does it start? That's an interesting question. It's a… a merge—some people would say a fork—of Apache CouchDB, and membase. Membase was a distributed key-value store and CouchDB was this weird Erlang and C JSON REST API database that was built by Damian Katz from Lotus Notes, and that was in 2006 or seven. That was before Node.js.Let's not care about the exact date. The point is, a JSON and REST API-enabled database before Node.js was, like, a strong [laugh] power move. And so, those two merged and created the first version of Couchbase. And then we've added all those things that people want to do, so SQL, full-text search, analytics, user-defined function, mobile sync, you know, all those things. So basically, a general-purpose database.Corey: For what things is it not a great fit? This is always my favorite question to ask database folks because the zealot is going to say, “It's good for every use case under the sun. Use it for everything, start to finish”—Laurent: Yes.Corey: —and very few databases can actually check that box.Laurent: It's a very interesting question because when I pitch like, “We do all the things,” because we are a platform, people say, “Well, you must be doing lots of trade-offs. Where is the trade-off?” The trade-off is basically the way you store something is going to determine the efficiency of your [growing 00:14:45]—or the way you [grow 00:14:47] it. And that's one of the first thing you learn in computer science. You learn about data structure and you know that it's easier to get something in a hashmap when you have the key than passing your whole list of elements and checking your data, is it right one? It's the same for databases.So, our different services are different ways to store the data and to query it. So, where is it not good, it's where we don't have an index or a service that answer to the way you want to query data. We don't have a graph service right now. You can still do recursive common table expression for the SQL nerds out there, that will allow you to do somewhat of a graph way of querying your data, but that's not, like, actual—that's not a great experience for people were expecting a graph, like a Neo4j or whatever was a graph database experience.So, that's the trade-off that we made. We have a lot of things at the same place and it can be a little hard, intimidating to operate, and the developer experience can be a little, “Oh, my God, what is this thing that can do all of those features?” At the same time, that's just, like, one SDK to learn for all of the features we've just talked about. So, that's what we did. That's a trade-off that we did.It sucks to operate—well, [unintelligible 00:16:05] Couchbase Capella, which is a lot like a vendor-ish thing to say, but that's the value props of our managed cloud. It's hard to operate, we'll operate this for you. We have a Kubernetes operator. If you are one of the few people that wants to do Kubernetes at home, that's also something you can do. So yeah, I guess what we cannot do is the thing that Route 53 and [Unbound 00:16:26] and [unintelligible 00:16:27] DNS do, which is this weird DNS database thing that you like so much.Corey: One thing that's, I guess, is a sign of the times, but I have to confess that I'm relatively skeptical around, when I pull up couchbase.com—as one does; you're publicly traded; I don't feel that your company has much of a choice in this—but the first thing it greets me with is Couchbase Capella—which, yes, that is your hosted flagship product; that should be the first thing I see on the website—then it says, “Announcing Capella iQ, AI-powered coding assistance for developers.” Which oh, great, not another one of these.So, all right, give me the pitch. What is the story around, “Ooh, everything that has been a problem before, AI is going to make it way better.” Because I've already talked to you about developer experience. I know where you stand on these things. I have a suspicion you would not be here to endorse something you don't believe in. How does the AI magic work in this context?Laurent: So, that's the thing, like, who's going to be the one that get their products out before the other? And so, we're announcing it on the website. It's available on the private preview only right now. I've tried it. It works.How does it works? The way most chatbot AI code generation work is there's a big model, large language model that people use and that people fine-tune into in order to specialize it to the tasks that they want to do. The way we've built Couchbase iQ is we picked a very famous large language model, and when you ask a question to a bot, there's a context, there's a… the size of the window basically, that allows you to fit as much contextual information as possible. The way it works and the reason why it's integrated into Couchbase Capella is we make sure that we preload that context as much as possible and fine-tune that model, that [foundation 00:18:19] model, as much as possible to do whatever you want to do with Couchbase, which usually falls into several—a couple of categories, really—well maybe three—you want to write SQL, you want to generate data—actually, that's four—you want to generate data, you want to generate code, and if you paste some SQL code or some application code, you want to ask that model, what does do? It's especially true for SQL queries.And one of the questions that many people ask and are scared of with chatbot is how does it work in terms of learning? If you give a chatbot to someone that's very new to something, and they're just going to basically use a chatbot like Stack Overflow and not really think about what they're doing, well it's not [great 00:19:03] right, but because that's the example that people think most developer will do is generate code. Writing code is, like, a small part of our job. Like, a substantial part of our job is understanding what the code does.Corey: We spend a lot more time reading code than writing it, if we're, you know—Laurent: Yes.Corey: Not completely foolish.Laurent: Absolutely. And sometimes reading big SQL query can be a bit daunting, especially if you're new to that. And one of the good things that you get—Corey: Oh, even if you're not, it can still be quite daunting, let me assure you.Laurent: [laugh]. I think it's an acquired taste, let's be honest. Some people like to write assembly code and some people like to write SQL. I'm sort of in the middle right now. You pass your SQL query, and it's going to tell you more or less what it does, and that's a very nice superpower of AI. I think that's [unintelligible 00:19:48] that's the one that interests me the most right now is using AI to understand and to work better with existing pieces of code.Because a lot of people think that the cost of software is writing the software. It's maintaining the codebase you've written. That's the cost of the software. That's our job as developers should be to write legacy code because it means you've provided value long enough. And so, if in a company that works pretty well and there's a lot of legacy code and there's a lot of new people coming in and they'll have to learn all those things, and to be honest, sometimes we don't document stuff as much as we should—Corey: “The code is self-documenting,” is one of the biggest lies I hear in tech.Laurent: Yes, of course, which is why people are asking retired people to go back to COBOL again because nobody can read it and it's not documented. Actually, if someone's looking for a company to build, I guess, explaining COBOL code with AI would be a pretty good fit to do in many places.Corey: Yeah, it feels like that's one of those things that would be of benefit to the larger world. The counterpoint to that is you got that many business processes wrapped around something running COBOL—and I assure you, if you don't, you would have migrated off of COBOL long before now—it's making sure that okay well, computers, when they're in the form of AI, are very, very good at being confident-sounding when they talk about things, but they can also do that when they're completely wrong. It's basically a BS generator. And that is a scary thing when you're taking a look at something that broad. I mean, I'll use the AI coding assistance for things all the time, but those things look a lot more like, “Okay, I haven't written CloudFormation from scratch in a while. Build out the template, just because I forget the exact sequence.” And it's mostly right on things like that. But then you start getting into some of the real nuanced areas like race conditions and the rest, and often it can make things worse instead of better. That's the scary part, for me, at least.Laurent: Most coding assistants are… and actually, each time you ask its opinion to an AI, they say, “Well, you should take this with a grain of salt and we are not a hundred percent sure that this is the case.” And this is, make sure you proofread that, which again, from a learning perspective, can be a bit hard to give to new students. Like, you're giving something to someone and might—that assumes is probably as right as Wikipedia but actually, it's not. And it's part of why it works so well. Like, the anthropomorphism that you get with chatbots, like, this, it feels so human. That's why it get people so excited about it because if you think about it, it's not that new. It's just the moment it took off was the moment it looked like an assertive human being.Corey: As you take a look through, I guess, the larger ecosystem now, as well as the database space, given that is where you specialize, what do you think people are getting right and what do you think people are getting wrong?Laurent: There's a couple of ways of seeing this. Right now, when I look at from the outside, every databases is going back to SQL, I think there's a good reason for that. And it's interesting to put into perspective with AI because when you generate something, there's probably less chance to generate something wrong with SQL than generating something with code directly. And I think five generation—was it four or five generation language—there some language generation, so basically, the first innovation is assembly [into 00:23:03] in one and then you get more evolved languages, and at some point you get SQL. And SQL is a way to very shortly express a whole lot of business logic.And I think what people are doing right now is going back to SQL. And it's been impressive to me how even new developers that were all about [ORMs 00:23:25] and [no-DMs 00:23:26], and you know, avoiding writing SQL as much as possible, are actually back to it. And that's, for an old guy like me—well I mean, not that old—it feels good. I think SQL is coming back with a vengeance and that makes me very happy. I think what people don't realize is that it also involves doing data modeling, right, and stuff because database like Couchbase that are schemaless exist. You should store your data without thinking about it, you should still do data modeling. It's important. So, I think that's the interesting bits. What are people doing wrong in that space? I'm… I don't want to say bad thing about other databases, so I cannot even process that thought right now.Corey: That's okay. I'm thrilled to say negative things about any database under the sun. They all haunt me. I mean, someone wants to describe SQL to me is the chess of the programming world and I feel like that's very accurate. I have found that it is far easier in working with databases to make mistakes that don't wash off after a new deployment than it is in most other realms of technology. And when you're lucky and have a particular aura, you tend to avoid that stuff, at least that was always my approach.Laurent: I think if I had something to say, so just like the XKCD about standards: like, “there's 14 standards. I'm going to do one that's going to unify them all.” And it's the same with database. There's a lot… a [laugh] lot of databases. Have you ever been on a website called dbdb.io?Corey: Which one is it? I'm sorry.Laurent: Dbdb.io is the database of databases, and it's very [laugh] interesting website for database nerds. And so, if you're into database, dbdb.io. And you will find Couchbase and you will find a whole bunch of other databases, and you'll get to know which database is derived from which other database, you get the history, you get all those things. It's actually pretty interesting.Corey: I'm familiar with DB-Engines, which is sort of like the ranking databases by popularity, and companies will bend over backwards to wind up hitting all of the various things that they want in that space. The counterpoint with all of it is that it's… it feels historically like there haven't exactly been an awful lot of, shall we say, huge innovations in databases for the past few years. I mean, sure, we hear about vectors all the time now because of the joy that's AI, but smarter people than I are talking about how, well that's more of a feature than it is a core database. And the continual battle that we all hear about constantly is—and deal with ourselves—of should we use a general-purpose database, or a task-specific database for this thing that I'm doing remains largely unsolved.Laurent: Yeah, what's new? And when you look at it, it's like, we are going back to our roots and bringing SQL again. So, is there anything new? I guess most of the new stuff, all the interesting stuff in the 2010s—well, basically with the cloud—were all about the distribution side of things and were all about distributed consensus, Zookeeper, etcd, all that stuff. Couchbase is using an RAFT-like algorithm to keep every node happy and under the same cluster.I think that's one of the most interesting things we've had for the past… well, not for the past ten years, but between, basically, 20 or… between the start of AWS and well, let's say seven years ago. I think the end of the distribution game was brought to us by the people that have atomic clock in every data center because that's what you use to synchronize things. So, that was interesting things. And then suddenly, there wasn't that much innovation in the distributed world, maybe because Aphyr disappeared from Twitter. That might be one of the reason. He's not here to scare people enough to be better at that.Aphyr was the person behind the test called the Jepsen Test [shoot 00:27:12]. I think his blog engine was called Call Me Maybe, and he was going through every distributed system and trying to break them. And that was super interesting. And it feels like we're not talking that much about this anymore. It really feels like database have gone back to the status of infrastructure.In 2010, it was not about infrastructure. It was about developer empowerment. It was about serving JSON and developer experience and making sure that you can code faster without some constraint in a distributed world. And like, we fixed this for the most part. And the way we fixed this—and as you said, lack of innovation, maybe—has brought databases back to an infrastructure layer.Again, it wasn't the case 15 years a—well, 2023—13 years ago. And that's interesting. When you look at the new generation of databases, sometimes it's just a gateway on top of a well-known database and they call that a database, but it provides higher-level services, provides higher-level bricks, better developer experience to developer to build stuff faster. We've been trying to do this with Couchbase App Service and our sync gateway, which is basically a gateway on top of a Couchbase cluster that allow you to manage authentication, authorization, that allows you to manage synchronization with your mobile device or with websites. And yeah, I think that's the most interesting thing to me in this industry is how it's been relegated back to infrastructure, and all the cool stuff, new stuff happens on the layer above that.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Laurent: Thanks for having me and for entertaining this conversation. I can be found anywhere on the internet with these six letters: L-D-O-G-U-I-N. That's actually 7 letters. Ldoguin. That's my handle on pretty much any social network. Ldoguin. So X, [BlueSky 00:29:21], LinkedIn. I don't know where to be anymore.Corey: I hear you. We'll put links to all of it in the [show notes 00:29:27] and let people figure out where they want to go on that. Thank you so much for taking the time to speak with me today. I really do appreciate it.Laurent: Thanks for having me.Corey: Laurent Doguin, Director of Developer Relations and Strategy at Couchbase. I'm Cloud Economist Corey Quinn and this episode has been brought to us by our friends at Couchbase. If you enjoyed this episode, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that you're not going to be able to submit properly because that platform of choice did not pay enough attention to the experience of typing in a comment.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

In this episode we sit down with founder of Distressed Loan Advisors, Jason Milleisen. During one of the worst financial disasters of our time, Jason was a workout specialist at CIT. From being an underwriter, to switching sides of the table and helping distressed borrowers- Jason's here to share his experiences from that time. If you've been enjoying our episodes this season feel free to leave a review, like  our posts, or share our channel- and don't forget to subscribe! Navigate this episode: 2:40 Introducing Jason Milleisen and his company 5:15 "working out" in the Great Recession 7:40 What Lenders Learned from 2008 9:30 Conflicts when considering character 12:18 Discussing offer in compromise 17:39 How do lenders view the role of a workout specialist 22:18 Can a Workout specialist be an alternative to an attorney? 24:16 What kind of work is there for a workout specialist right now? 31:28 Discussing the CAIVRS List and obstacles in receiving 7(a) loans 35:00 Why did Jason start his services? 38:10 What are lenders getting wrong in negotiations? 43:02 Do stronger borrowers get penalized more? 48:00 The emotional aspect of borrowing and negotiating -------------------------------------------------------- This episode is sponsored in part by: Baker Lewis It matters who you partner with to grow and manage your SBA lending business. When you choose Baker Lewis, you partner with professionals as committed to SBA lending as you are. ----------------- Outsourced Risk Management Solutions LLC (ORMS) ORMS is the go-to environmental management firm used by SBA lenders to order environmental due diligence and navigate SBA compliance. If you're interested in having ORMS manage your environmental process, reach out to Derek Ezovski at dezovski@orms.com.

Lars-Erik Roald is a software developer at Systor. He shares his insights and experiences in creating ORM and the evolution of the technology. They dive into the world of ORMs, TypeScript, and a variety of programming and personal ventures. From discussions about the challenges and advantages of ORMs and navigating the complexities of TypeScript to lighthearted banter about swimming, triathlon training, and even some dad jokesSponsorsMiroRaygun - Application Monitoring For Web & Mobile AppsBecome a Top 1% Dev with a Top End Devs MembershipLinksalfateam/rdbSocialsTwitter: Lars-Erik RoaldGitHub: Lars-Erik RoaldPicksCharles - TimpCon 2023Charles - AkropolisSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

It's THE episode you cannot miss, featuring Bob Coleman!  This week on The Art of SBA Lending, Bob Coleman, Publisher of The Coleman Report, is interviewed by our host Ray Drew about whether we've returned to the loosened credit standards of 2007, how technological advances disrupted Bob's business multiple times, and the SBA's new reputation problem thanks to PPP fraud. Hear the legend himself get into details from behind-the-scenes at The Coleman Report, plus his exclusive industry takes!   Navigate this episode:   2:25 Introducing Bob Coleman 6:55 Are we returning to the credit standards of 2007? 9:22 Government assistance now vs the past  11:30 Thoughts on financing young or inexperienced entrepreneurs  14:28 Bobs take on the state of lending in 2020 and PPP 16:12 Bobs background and experience leading to The Coleman Report  20:29 Bob covers the BancServ era 24:36 Potential conflicts between responsible journalism and banking  29:26 Bobs experience and advice on pivoting in your career and being diligent about your brand's reputation 33:57 Introduction to AI in the workplace  36:21 The current reputation of SBA industry 37:05 New changes to the 7a program 43:23 What's next for Bob? ------------------------------------------------------------------------------- This episode is sponsored in part by: Lumos Technologies, Inc Lumos empowers your small business lending growth with cutting-edge analytics and streamlined applications that optimize your performance. If you're ready to take your small business lending to the next level with cutting edge analytics and AI, visit lumosdata.com or lumosdata.com/contact-us ----------------- Outsourced Risk Management Solutions LLC (ORMS) ORMS is the go-to environmental management firm used by SBA lenders to order environmental due diligence and navigate SBA compliance. If you're interested in having ORMS manage your environmental process, reach out to Derek Ezovski at dezovski@orms.com.

Gary Henderson, or as you may know him, "SBA Guy", is with us this week! In this candid episode of "The Art of SBA Lending" we share our thought-provoking wisdom, experiences and differences. This week we're diving deep into: - Having vision and playing the long game - Keeping your mind open to process improvements -The importance of meeting with clients, and your team, face-to-face Listen in today to tap into Gary's invaluable and tenured experience—a true lending champ! ------------------------------------------------------------------------------- This episode is sponsored in part by: Lumos Technologies, Inc Lumos empowers your small business lending growth with cutting-edge analytics and streamlined applications that optimize your performance. If you're ready to take your small business lending to the next level with cutting edge analytics and AI, visit lumosdata.com or lumosdata.com/contact-us ----------------- Outsourced Risk Management Solutions LLC (ORMS) ORMS is the go-to environmental management firm used by SBA lenders to order environmental due diligence and navigate SBA compliance. If you're interested in having ORMS manage your environmental process, reach out to Derek Ezovski at dezovski@orms.com.

Ep 43. AJ Climate Champions with Hattie Hartman and George Morgan. London Eye architect Julia Barfield explains how the climate emergency changed the way her practice, Marks Barfield, operates, as well as what's ahead for the Architects Declare movement. Julia shares insights from recent projects on how to achieve circularity in retrofit, the challenges of stockpiling materials for reuse  and how Orms' material passports can be adapted for retrofit. ‘We must treat all materials as the precious resource they are,' she says. She talks about her practice's Stirling Prize-shortlisted Cambridge Mosque, which is part of a Built by Nature-funded post-occupancy study evaluating the quality of life and performance aspects of five CLT buildings. We also speak to Julia and fellow Architects Declare steering group member Zoe Watson about what AD has achieved four years on as well as its current workstreams, including climate emergency training for design review panels and Meet the Steering Group sessions where AD signatories can seek practical advice on how to further sustainable design within their own practices. As part of an ambitious strategy for change, AD is launching a three-part roadmap aimed at equipping Government policymakers with practical and impactful policies to reduce emissions, kickstart the circular economy and restore social and natural infrastructure.  AD plans to launch its document in Parliament in 2024. For show notes and to catch up on all AJ Climate Champions episodes, click here

The last time we sat down with Daniel was two years ago as he was closing out a $100,000,000+ year. This week, Daniel Park returns to The Art of SBA Lending Podcast to discuss what's changed in the market over the last two years, and how he's been able to keep up. Ray and Daniel go over where you need to stay consistent, and where you need to pivot in order to meet your goals year-over-year. Tune in to get more details on interest rates and the current market, adapting your business model, growing opportunities in the hospitality sector, and what it takes to hit $300,000,000 in 3 years!   --------------------------------------------------- This episode is sponsored in part by: Lumos Technologies, Inc Lumos empowers your small business lending growth with cutting-edge analytics and streamlined applications that optimize your performance. If you're ready to take your small business lending to the next level with cutting edge analytics and AI, visit lumosdata.com or lumosdata.com/contact-us ----------------- Outsourced Risk Management Solutions LLC (ORMS) ORMS is the go-to environmental management firm used by SBA lenders to order environmental due diligence and navigate SBA compliance. If you're interested in having ORMS manage your environmental process, reach out to Derek Ezovski at dezovski@orms.com.

The SBA industry has long been rooted in traditional banking practices. However, with the advent of new technologies and the rise of alternative lenders, the landscape is starting to change.   In this episode, Ray sits down with Andrew Simon, Head of Digital Strategy at Exos Lending. Exos Lending is the newest non-bank lender in the industry and they are already shaking things up.    Andrew and Ray discuss: Leveraging technology and marketing Making the lending process more efficient Embracing new talent and perspectives to drive innovation   Check out Exos' slick website: https://www.exosfinancial.com/what-we-do/sba-lending ------------------- This episode is sponsored in part by:   Lumos Technologies, Inc Lumos empowers your small business lending growth with cutting-edge analytics and streamlined applications that optimize your performance. If you're ready to take your small business lending to the next level with cutting edge analytics and AI, visit lumosdata.com or lumosdata.com/contact-us   ------------------- ORMS   ORMS is the go-to environmental management firm used by SBA lenders to order environmental due diligence and navigate SBA compliance. If you're interested in having ORMS manage your environmental process, reach out to Derek at dezovski@orms.com.

Tom Preston-Werner is the Cofounder at Preston-Werner Ventures. They dive into the world of React, Redwood JS, and the evolving landscape of JavaScript development. They discuss the importance of keeping up with the JavaScript world, the benefits of learning SQL, and the challenges of using ORMs. They also explore the upcoming Redwood JS conference, the future of React Server Components, and the motivations behind building open-source projects. SponsorsChuck's Resume Template Raygun - Application Monitoring For Web & Mobile AppsBecome a Top 1% Dev with a Top End Devs MembershipLinksRedwoodJS: The App Framework for Startups | RedwoodJS.comRedwoodJS ConferenceChatterbug SocialsLinkedIn: Tom Preston-WernerTom Preston-Werner PicksAJ - "If you enjoy switching between feeling like the smartest person on earth and the dumbest person in history all in the same day, programming may be the career for you!" - https://redwoodjs.com/docs/tutorial/intermissionAJ - SemVerAJ - Suzanna Venker (be countercultural)AJ - Amazon FBA Honest ResultsCharles - Risk Legacy | Board GameCharles - Wednesday (TV Series 2022Dan - The Peacemaker (1997)Dan - The Faithful and the Fallen Series by John GwynneSteve - The Spy (TV Mini Series 2019)Tom - Monopoly Deal Card GameSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

As alluded to on the pod, LangChain has just launched LangChain Hub: “the go-to place for developers to discover new use cases and polished prompts.” It's available to everyone with a LangSmith account, no invite code necessary. Check it out!In 2023, LangChain has speedrun the race from 2:00 to 4:00 to 7:00 Silicon Valley Time. From the back to back $10m Benchmark seed and (rumored) $20-25m Sequoia Series A in April, to back to back critiques of “LangChain is Pointless” and “The Problem with LangChain” in July, to teaching with Andrew Ng and keynoting at basically every AI conference this fall (including ours), it has been an extreme rollercoaster for Harrison and his growing team creating one of the most popular (>60k stars at time of writing) building blocks for AI Engineers.LangChain's OriginsThe first commit to LangChain shows its humble origins as a light wrapper around Python's formatter.format for prompt templating. But as Harrison tells the story, even his first experience with text-davinci-002 in early 2022 was focused on chatting with data from their internal company Notion and Slack, what is now known as Retrieval Augmented Generation (RAG). As the Generative AI meetup scene came to life post Stable Diffusion, Harrison saw a need for common abstractions for what people were building with text LLMs at the time:* LLM Math, aka Riley Goodside's “You Can't Do Math” REPL-in-the-loop (PR #8)* Self-Ask With Search, Ofir Press' agent pattern (PR #9) (later ReAct, PR #24)* NatBot, Nat Friedman's browser controlling agent (PR #18)* Adapters for OpenAI, Cohere, and HuggingFaceHubAll this was built and launched in a few days from Oct 16-25, 2022. Turning research ideas/exciting usecases into software quickly and often has been in the LangChain DNA from Day 1 and likely a big driver of LangChain's success, to date amassing the largest community of AI Engineers and being the default launch framework for every big name from Nvidia to OpenAI:Dancing with GiantsBut AI Engineering is built atop of constantly moving tectonic shifts: * ChatGPT launched in November (“The Day the AGI Was Born”) and the API released in March. Before the ChatGPT API, OpenAI did not have a chat endpoint. In order to build a chatbot with history, you had to make sure to chain all messages and prompt for completion. LangChain made it easy to do that out of the box, which was a huge driver of usage. * Today, OpenAI has gone all-in on the chat API and is deprecating the old completions models, essentially baking in the chat pattern as the default way most engineers should interact with LLMs… and reducing (but not eliminating) the value of ConversationChains.* And there have been more updates since: Plugins released in API form as Functions in June (one of our top pods ever… reducing but not eliminating the value of OutputParsers) and Finetuning in August (arguably reducing some need for Retrieval and Prompt tooling). With each update, OpenAI and other frontier model labs realign the roadmaps of this nascent industry, and Harrison credits the modular design of LangChain in staying relevant. LangChain has not been merely responsive either: LangChain added Agents in November, well before they became the hottest topic of the AI Summer, and now Agents feature as one of LangChain's top two usecases. LangChain's problem for podcasters and newcomers alike is its sheer scope - it is the world's most complete AI framework, but it also has a sprawling surface area that is difficult to fully grasp or document in one sitting. This means it's time for the trademark Latent Space move (ChatGPT, GPT4, Auto-GPT, and Code Interpreter Advanced Data Analysis GPT4.5): the executive summary!What is LangChain?As Harrison explains, LangChain is an open source framework for building context-aware reasoning applications, available in Python and JS/TS.It launched in Oct 2022 with the central value proposition of “composability”, aka the idea that every AI engineer will want to switch LLMs, and combine LLMs with other things into “chains”, using a flexible interface that can be saved via a schema.Today, LangChain's principal offerings can be grouped as:* Components: isolated modules/abstractions* Model I/O* Models (for LLM/Chat/Embeddings, from OpenAI, Anthropic, Cohere, etc)* Prompts (Templates, ExampleSelectors, OutputParsers)* Retrieval (revised and reintroduced in March)* Document Loaders (eg from CSV, JSON, Markdown, PDF)* Text Splitters (15+ various strategies for chunking text to fit token limits)* Retrievers (generic interface for turning an unstructed query into a set of documents - for self-querying, contextual compression, ensembling)* Vector Stores (retrievers that search by similarity of embeddings)* Indexers (sync documents from any source into a vector store without duplication)* Memory (for long running chats, whether a simple Buffer, Knowledge Graph, Summary, or Vector Store)* Use-Cases: compositions of Components* Chains: combining a PromptTemplate, LLM Model and optional OutputParser* with Router, Sequential, and Transform Chains for advanced usecases* savable, sharable schemas that can be loaded from LangChainHub* Agents: a chain that has access to a suite of tools, of nondeterministic length because the LLM is used as a reasoning engine to determine which actions to take and in which order. Notable 100LOC explainer here.* Tools (interfaces that an agent can use to interact with the world - preset list here. Includes things like ChatGPT plugins, Google Search, WolframAlpha. Groups of tools are bundled up as toolkits)* AgentExecutor (the agent runtime, basically the while loop, with support for controls, timeouts, memory sharing, etc)* LangChain has also added a Callbacks system for instrumenting each stage of LLM, Chain, and Agent calls (which enables LangSmith, LangChain's first cloud product), and most recently an Expression Language, a declarative way to compose chains.LangChain the company incorporated in January 2023, announced their seed round in April, and launched LangSmith in July. At time of writing, the company has 93k followers, their Discord has 31k members and their weekly webinars are attended by thousands of people live.The full-featuredness of LangChain means it is often the first starting point for building any mainstream LLM use case, because they are most likely to have working guides for the new developer. Logan (our first guest!) from OpenAI has been a notable fan of both LangChain and LangSmith (they will be running the first LangChain + OpenAI workshop at AI Eng Summit). However, LangChain is not without its critics, with Aravind Srinivas, Jim Fan, Max Woolf, Mckay Wrigley and the general Reddit/HN community describing frustrations with the value of their abstractions, and many are attempting to write their own (the common experience of adding and then removing LangChain is something we covered in our Agents writeup). Harrison compares this with the timeless ORM debate on the value of abstractions.LangSmithLast month, Harrison launched LangSmith, their LLM observability tool and first cloud product. LangSmith makes it easy to monitor all the different primitives that LangChain offers (agents, chains, LLMs) as well as making it easy to share and evaluate them both through heuristics (i.e. manually written ones) and “LLM evaluating LLM” flows. The top HN comment in the “LangChain is Pointless” thread observed that orchestration is the smallest part of the work, and the bulk of it is prompt tuning and data serialization. When asked this directly our pod, Harrison agreed:“I agree that those are big pain points that get exacerbated when you have these complex chains and agents where you can't really see what's going on inside of them. And I think that's partially why we built Langsmith…” (48min mark)You can watch the full launch on the LangChain YouTube:It's clear that the target audience for LangChain is expanding to folks who are building complex, production applications rather than focusing on the simpler “Q&A your docs” use cases that made it popular in the first place. As the AI Engineer space matures, there will be more and more tools graduating from supporting “hobby” projects to more enterprise-y use cases. In this episode we run through some of the history of LangChain, how it's growing from an open source project to one of the highest valued AI startups out there, and its future. We hope you enjoy it!Show Notes* LangChain* LangChain's Berkshire Hathaway Homepage* Abstractions tweet* LangSmith* LangSmith Cookbooks repo* LangChain Retrieval blog* Evaluating CSV Question/Answering blog and YouTube* MultiOn Partner blog* Harvard Sports Analytics Collective* Evaluating RAG Webinar* awesome-langchain:* LLM Math Chain* Self-Ask* LangChain Hub UI* “LangChain is Pointless”* Harrison's links* sports - estimating player compatibility in the NBA* early interest in prompt injections* GitHub* TwitterTimestamps* [00:00:00] Introduction* [00:00:48] Harrison's background and how sports led him into ML* [00:04:54] The inspiration for creating LangChain - abstracting common patterns seen in other GPT-3 projects* [00:05:51] Overview of LangChain - a framework for building context-aware reasoning applications* [00:10:09] Components of LangChain - modules, chains, agents, etc.* [00:14:39] Underappreciated parts of LangChain - text splitters, retrieval algorithms like self-query* [00:18:46] Hiring at LangChain* [00:20:27] Designing the LangChain architecture - balancing flexibility and structure* [00:24:09] The difference between chains and agents in LangChain* [00:25:08] Prompt engineering and LangChain* [00:26:16] Announcing LangSmith* [00:30:50] Writing custom evaluators in LangSmith* [00:33:19] Reducing hallucinations - fixing retrieval vs generation issues* [00:38:17] The challenges of long context windows* [00:40:01] LangChain's multi-programming language strategy* [00:45:55] Most popular LangChain blog posts - deep dives into specific topics* [00:50:25] Responding to LangChain criticisms* [00:54:11] Harrison's advice to AI engineers* [00:55:43] Lightning RoundTranscriptAlessio: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO at Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol.ai. [00:00:19]Swyx: Welcome. Today we have Harrison Chase in the studio with us. Welcome Harrison. [00:00:23]Harrison: Thank you guys for having me. I'm excited to be here. [00:00:25]Swyx: It's been a long time coming. We've been asking you for a little bit and we're really glad that you got some time to join us in the studio. Yeah. [00:00:32]Harrison: I've been dodging you guys for a while. [00:00:34]Swyx: About seven months. You pulled me in here. [00:00:37]Alessio: About seven months. But it's all good. I totally understand. [00:00:38]Swyx: We like to introduce people through the official backgrounds and then ask you a little bit about your personal side. So you went to Harvard, class of 2017. You don't list what you did in Harvard. Was it CS? [00:00:48]Harrison: Stats and CS. [00:00:50]Swyx: That's awesome. I love me some good stats. [00:00:52]Harrison: I got into it through stats, through doing sports analytics. And then there was so much overlap between stats and CS that I found myself doing more and more of that. [00:00:59]Swyx: And it's interesting that a lot of the math that you learn in stats actually comes over into machine learning which you applied at Kensho as a machine learning engineer and Robust Intelligence, which seems to be the home of a lot of AI founders.Harrison: It does. Yeah. Swyx: And you started LangChain, I think around November 2022 and incorporated in January. Yeah. [00:01:19]Harrison: I was looking it up for the podcast and the first tweet was on, I think October 24th. So just before the end of November or end of October. [00:01:26]Swyx: Yeah. So that's your LinkedIn. What should people know about you on the personal side that's not obvious on LinkedIn? [00:01:33]Harrison: A lot of how I got into this is all through sports actually. Like I'm a big sports fan, played a lot of soccer growing up and then really big fan of the NBA and NFL. And so freshman year at college showed up and I knew I liked math. I knew I liked sports. One of the clubs that was there was the Sports Analytics Collective. And so I joined that freshman year, I was doing a lot of stuff in like Excel, just like basic stats, but then like wanted to do more advanced stuff. So learn to code, learn kind of like data science and machine learning through that way. Kind of like just kept on going down that path. I think sports is a great entryway to data science and machine learning. There's a lot of like numbers out there. People like really care. Like I remember, I think sophomore, junior year, I was in the Sports Collective and the main thing we had was a blog. And so we wrote a blog. It wasn't me. One of the other people in the club wrote a blog predicting the NFL season. I think they made some kind of like with stats and I think their stats showed that like the Dolphins would end up beating the Patriots and New England got like pissed about it, of course. So people like really care and they'll give you feedback about whether you're like models doing well or poorly. And so you get that. And then you also get like instantaneous kind of like, well, not instantaneous, but really quick feedback. Like if you predict a game, the game happens that night. Like you don't have to wait a year to see what happens. So I think sports is a great kind of like entryway for kind of like data science. [00:02:43]Alessio: There was actually my first article on the Twilio blog with a Python script to like predict pricing of like Daily Fantasy players based on my past week performance. Yeah, I don't know. It's a good getaway drug. [00:02:56]Swyx: And on my end, the way I got into finance was through sports betting. So maybe we all have some ties in there. Was like Moneyball a big inspiration? The movie? [00:03:06]Harrison: Honestly, not really. I don't really like baseball. That's like the big thing. [00:03:10]Swyx: Let's call it a lot of stats. Cool. Well, we can dive right into LangChain, which is what everyone is excited about. But feel free to make all the sports analogies you want. That really drives home a lot of points. What was your GPT aha moment? When did you start working on GPT itself? Maybe not LangChain, just anything to do with the GPT API? [00:03:29]Harrison: I think it probably started around the time we had a company hackathon. I think that was before I launched LangChain. I'm trying to remember the exact sequence of events, but I do remember that at the hackathon I worked with Will, who's now actually at LangChain as well, and then two other members of Robust. And we made basically a bot where you could ask questions of Notion and Slack. And so I think, yeah, RAG, basically. And I think I wanted to try that out because I'd heard that it was getting good. I'm trying to remember if I did anything before that to realize that it was good. So then I would focus on that on the hackathon. I can't remember or not, but that was one of the first times that I built something [00:04:06]Swyx: with GPT-3. There wasn't that much opportunity before because the API access wasn't that widespread. You had to get into some kind of program to get that. [00:04:16]Harrison: DaVinci-002 was not terrible, but they did an upgrade to get it to there, and they didn't really publicize that as much. And so I think I remember playing around with it when the first DaVinci model came out. I was like, this is cool, but it's not amazing. You'd have to do a lot of work to get it to do something. But then I think that February or something, I think of 2022, they upgraded it and it was it got better, but I think they made less of an announcement around it. And so I just, yeah, it kind of slipped under the radar for me, at least. [00:04:45]Alessio: And what was the step into LangChain? So you did the hackathon, and then as you were building the kind of RAG product, you felt like the developer experience wasn't that great? Or what was the inspiration? [00:04:54]Harrison: No, honestly, so around that time, I knew I was going to leave my previous job. I was trying to figure out what I was going to do next. I went to a bunch of meetups and other events. This was like the September, August, September of that year. So after Stable Diffusion, but before ChatGPT. So there was interest in generative AI as a space, but not a lot of people hacking on language models yet. But there were definitely some. And so I would go to these meetups and just chat with people and basically saw some common abstractions in terms of what they were building, and then thought it would be a cool side project to factor out some of those common abstractions. And that became kind of like LangChain. I looked up again before this, because I remember I did a tweet thread on Twitter to announce LangChain. And we can talk about what LangChain is. It's a series of components. And then there's some end-to-end modules. And there was three end-to-end modules that were in the initial release. One was NatBot. So this was the web agent by Nat Friedman. Another was LLM Math Chain. So it would construct- [00:05:51]Swyx: GPT-3 cannot do math. [00:05:53]Harrison: Yeah, exactly. And then the third was Self-Ask. So some type of RAG search, similar to React style agent. So those were some of the patterns in terms of what I was seeing. And those all came from open source or academic examples, because the people who were actually working on this were building startups. And they were doing things like question answering over your databases, question answering over SQL, things like that. But I couldn't use their code as kind of like inspiration to factor things out. [00:06:18]Swyx: I talked to you a little bit, actually, roundabout, right after you announced LangChain. I'm honored. I think I'm one of many. This is your first open source project. [00:06:26]Harrison: No, that's not actually true. I released, because I like sports stats. And so I remember I did release some really small, random Python package for scraping data from basketball reference or something. I'm pretty sure I released that. So first project to get a star on GitHub, let's say that. [00:06:45]Swyx: Did you reference anything? What was the inspirations, like other frameworks that you look to when open sourcing LangChain or announcing it or anything like that? [00:06:53]Harrison: I mean, the only main thing that I looked for... I remember reading a Hacker News post a little bit before about how a readme on the project goes a long way. [00:07:02]Swyx: Readme's help. [00:07:03]Harrison: Yeah. And so I looked at it and was like, put some status checks at the top and have the title and then one or two lines and then just right into installation. And so that's the main thing that I looked at in terms of how to structure it. Because yeah, I hadn't done open source before. I didn't really know how to communicate that aspect of the marketing or getting people to use it. I think I had some trouble finding it, but I finally found it and used that as a lot [00:07:25]Swyx: of the inspiration there. Yeah. It was one of the subjects of my write-up how it was surprising to me that significant open source experience actually didn't seem to matter in the new wave of AI tooling. Most like auto-GPTs, Torrents, that was his first open source project ever. And that became auto-GPT. Yeah. I don't know. To me, it's just interesting how open source experience is kind of fungible or not necessary. Or you can kind of learn it on the job. [00:07:49]Alessio: Overvalued. [00:07:50]Swyx: Overvalued. Okay. You said it, not me. [00:07:53]Alessio: What's your description of LangChain today? I think when I built the LangChain Hub UI in January, there were a few things. And I think you were one of the first people to talk about agents that were already in there before it got hot now. And it's obviously evolved into a much bigger framework today. Run people through what LangChain is today, how they should think about it, and all of that. [00:08:14]Harrison: The way that we describe it or think about it internally is that LangChain is basically... I started off saying LangChain's a framework for building LLM applications, but that's really vague and not really specific. And I think part of the issue is LangChain does do a lot, so it's hard to be somewhat specific. But I think the way that we think about it internally, in terms of prioritization, what to focus on, is basically LangChain's a framework for building context-aware reasoning applications. And so that's a bit of a mouthful, but I think that speaks to a lot of the core parts of what's in LangChain. And so what concretely that means in LangChain, there's really two things. One is a set of components and modules. And these would be the prompt template abstraction, the LLM abstraction, chat model abstraction, vector store abstraction, text splitters, document loaders. And so these are combinations of things that we build and we implement, or we just have integrations with. So we don't have any language models ourselves. We don't have any vector stores ourselves, but we integrate with a lot of them. And then the text splitters, we have our own logic for that. The document loaders, we have our own logic for that. And so those are the individual modules. But then I think another big part of LangChain, and probably the part that got people using it the most, is the end-to-end chains or applications. So we have a lot of chains for getting started with question answering over your documents, chat question answering, question answering over SQL databases, agent stuff that you can plug in off the box. And that basically combines these components in a series of specific ways to do this. So if you think about a question answering app, you need a lot of different components kind of stacked. And there's a bunch of different ways to do question answering apps. So this is a bit of an overgeneralization, but basically, you know, you have some component that looks up an embedding from a vector store, and then you put that into the prompt template with the question and the context, and maybe you have the chat history as well. And then that generates an answer, and then maybe you parse that out, or you do something with the answer there. And so there's just this sequence of things that you basically stack in a particular way. And so we just provide a bunch of those assembled chains off the shelf to make it really easy to get started in a few lines of code. [00:10:09]Alessio: And just to give people context, when you first released LangChain, OpenAI did not have a chat API. It was a completion-only API. So you had to do all the human assistant, like prompting and whatnot. So you abstracted a lot of that away. I think the most interesting thing to me is you're kind of the Switzerland of this developer land. There's a bunch of vector databases that are killing each other out there to get people to embed data in them, and you're like, I love you all. You all are great. How do you think about being an opinionated framework versus leaving a lot of choice to the user? I mean, in terms of spending time into this integration, it's like you only have 10 people on the team. Obviously that takes time. Yeah. What's that process like for you all? [00:10:50]Harrison: I think right off the bat, having different options for language models. I mean, language models is the main one that right off the bat we knew we wanted to support a bunch of different options for. There's a lot to discuss there. People want optionality between different language models. They want to try it out. They want to maybe change to ones that are cheaper as new ones kind of emerge. They don't want to get stuck into one particular one if a better one comes out. There's some challenges there as well. Prompts don't really transfer. And so there's a lot of nuance there. But from the bat, having this optionality between the language model providers was a big important part because I think that was just something we felt really strongly about. We believe there's not just going to be one model that rules them all. There's going to be a bunch of different models that are good for a bunch of different use cases. I did not anticipate the number of vector stores that would emerge. I don't know how many we supported in the initial release. It probably wasn't as big of a focus as language models was. But I think it kind of quickly became so, especially when Postgres and Elastic and Redis started building their vector store implementations. We saw that some people might not want to use a dedicated vector store. Maybe they want to use traditional databases. I think to your point around what we're opinionated about, I think the thing that we believe most strongly is it's super early in the space and super fast moving. And so there's a lot of uncertainty about how things will shake out in terms of what role will vector databases play? How many will there be? And so I think a lot of it has always kind of been this optionality and ability to switch and not getting locked in. [00:12:19]Swyx: There's other pieces of LangChain which maybe don't get as much attention sometimes. And the way that you explained LangChain is somewhat different from the docs. I don't know how to square this. So for example, you have at the top level in your docs, you have, we mentioned ModelIO, we mentioned Retrieval, we mentioned Chains. Then you have a concept called Agents, which I don't know if exactly matches what other people call Agents. And we also talked about Memory. And then finally there's Callbacks. Are there any of the less understood concepts in LangChain that you want to give some air to? [00:12:53]Harrison: I mean, I think buried in ModelIO is some stuff around like few-shot example selectors that I think is really powerful. That's a workhorse. [00:13:01]Swyx: Yeah. I think that's where I start with LangChain. [00:13:04]Harrison: It's one of those things that you probably don't, if you're building an application, you probably don't start with it. You probably start with like a zero-shot prompt. But I think that's a really powerful one that's probably just talked about less because you don't need it right off the bat. And for those of you who don't know, that basically selects from a bunch of examples the ones that are maybe most relevant to the input at hand. So you can do some nice kind of like in-context learning there. I think that's, we've had that for a while. I don't think enough people use that, basically. Output parsers also used to be kind of important, but then function calling. There's this interesting thing where like the space is just like progressing so rapidly that a lot of things that were really important have kind of diminished a bit, to be honest. Output parsers definitely used to be an understated and underappreciated part. And I think if you're working with non-OpenAI models, they still are, but a lot of people are working with OpenAI models. But even within there, there's different things you can do with kind of like the function calling ability. Sometimes you want to have the option of having the text or the application you're building, it could return either. Sometimes you know that it wants to return in a structured format, and so you just want to take that structured format. Other times you're extracting things that are maybe a key in that structured format, and so you want to like pluck that key. And so there's just like some like annoying kind of like parsing of that to do. Agents, memory, and retrieval, we haven't talked at all. Retrieval, there's like five different subcomponents. You could also probably talk about all of those in depth. You've got the document loaders, the text splitters, the embedding models, the vector stores. Embedding models and vector stores, we don't really have, or sorry, we don't build, we integrate with those. Text splitters, I think we have like 15 or so. Like I think there's an under kind of like appreciated amount of those. [00:14:39]Swyx: And then... Well, it's actually, honestly, it's overwhelming. Nobody knows what to choose. [00:14:43]Harrison: Yeah, there is a lot. [00:14:44]Swyx: Yeah. Do you have personal favorites that you want to shout out? [00:14:47]Harrison: The one that we have in the docs is the default is like the recursive text splitter. We added a playground for text splitters the other week because, yeah, we heard a lot that like, you know, and like these affect things like the chunk overlap and the chunks, they affect things in really subtle ways. And so like I think we added a playground where people could just like choose different options. We have like, and a lot of the ideas are really similar. You split on different characters, depending on kind of like the type of text that you have marked down, you might want to split on differently than HTML. And so we added a playground where you can kind of like choose between those. I don't know if those are like underappreciated though, because I think a lot of people talk about text splitting as being a hard part, and it is a really important part of creating these retrieval applications. But I think we have a lot of really cool retrieval algorithms as well. So like self query is maybe one of my favorite things in LangChain, which is basically this idea of when you have a user question, the typical kind of like thing to do is you embed that question and then find the document that's most similar to that question. But oftentimes questions have things that just, you don't really want to look up semantically, they have some other meaning. So like in the example that I use, the example in the docs is like movies about aliens in the year 1980. 1980, I guess there's some semantic meaning for that, but it's a very particular thing that you care about. And so what the self query retriever does is it splits out the metadata filter and most vector stores support like a metadata filter. So it splits out this metadata filter, and then it splits out the semantic bit. And that's actually like kind of tricky to do because there's a lot of different filters that you can have like greater than, less than, equal to, you can have and things if you have multiple filters. So we have like a pretty complicated like prompt that does all that. That might be one of my favorite things in LangChain, period. Like I think that's, yeah, I think that's really cool. [00:16:26]Alessio: How do you think about speed of development versus support of existing things? So we mentioned retrieval, like you got, or, you know, text splitting, you got like different options for all of them. As you get building LangChain, how do you decide which ones are not going to keep supporting, you know, which ones are going to leave behind? I think right now, as you said, the space moves so quickly that like you don't even know who's using what. What's that like for you? [00:16:50]Harrison: Yeah. I mean, we have, you know, we don't really have telemetry on what people are using in terms of what parts of LangChain, the telemetry we have is like, you know, anecdotal stuff when people ask or have issues with things. A lot of it also is like, I think we definitely prioritize kind of like keeping up with the stuff that comes out. I think we added function calling, like the day it came out or the day after it came out, we added chat model support, like the day after it came out or something like that. That's probably, I think I'm really proud of how the team has kind of like kept up with that because this space is like exhausting sometimes. And so that's probably, that's a big focus of ours. The support, I think we've like, to be honest, we've had to get kind of creative with how we do that. Cause we have like, I think, I don't know how many open issues we have, but we have like 3000, somewhere between 2000 and 3000, like open GitHub issues. We've experimented with a lot of startups that are doing kind of like question answering over your docs and stuff like that. And so we've got them on the website and in the discord and there's a really good one, dosu on the GitHub that's like answering issues and stuff like that. And that's actually something we want to start leaning into more heavily as a company as well as kind of like building out an AI dev rel because we're 10 people now, 10, 11 people now. And like two months ago we were like six or something like that. Right. So like, and to have like 2,500 open issues or something like that, and like 300 or 400 PRs as well. Cause like one of the amazing things is that like, and you kind of alluded to this earlier, everyone's building in the space. There's so many different like touch points. LangChain is lucky enough to kind of like be a lot of the glue that connects it. And so we get to work with a lot of awesome companies, but that's also a lot of like work to keep up with as well. And so I don't really have an amazing answer, but I think like the, I think prioritize kind of like new things that, that come out. And then we've gotten creative with some of kind of like the support functions and, and luckily there's, you know, there's a lot of awesome people working on all those support coding, question answering things that we've been able to work with. [00:18:46]Swyx: I think there is your daily rhythm, which I've seen you, you work like a, like a beast man, like mad impressive. And then there's sometimes where you step back and do a little bit of high level, like 50,000 foot stuff. So we mentioned, we mentioned retrieval. You did a refactor in March and there's, there's other abstractions that you've sort of changed your mind on. When do you do that? When do you do like the, the step back from the day to day and go, where are we going and change the direction of the ship? [00:19:11]Harrison: It's a good question so far. It's probably been, you know, we see three or four or five things pop up that are enough to make us think about it. And then kind of like when it reaches that level, you know, we don't have like a monthly meeting where we sit down and do like a monthly plan or something. [00:19:27]Swyx: Maybe we should. I've thought about this. Yeah. I'd love to host that meeting. [00:19:32]Harrison: It's really been a lot of, you know, one of the amazing things is we get to interact with so many different people. So it's been a lot of kind of like just pattern matching on what people are doing and trying to see those patterns before they punch us in the face or something like that. So for retrieval, it was the pattern of seeing like, Hey, yeah, like a lot of people are using vector sort of stuff. But there's also just like other methods and people are offering like hosted solutions and we want our abstractions to work with that as well. So we shouldn't bake in this paradigm of doing like semantic search too heavily, which sounds like basic now, but I think like, you know, to start a lot of it was people needed help doing these things. But then there was like managed things that did them, hybrid retrieval mechanisms, all of that. I think another example of this, I mean, Langsmith, which we can maybe talk about was like very kind of like, I think we worked on that for like three or four months before announcing it kind of like publicly, two months maybe before giving it to kind of like anyone in beta. But this was a lot of debugging these applications as a pain point. We hear that like just understanding what's going on is a pain point. [00:20:27]Alessio: I mean, you two did a webinar on this, which is called Agents vs. Chains. It was fun, baby. [00:20:32]Swyx: Thanks for having me on. [00:20:33]Harrison: No, thanks for coming. [00:20:34]Alessio: That was a good one. And on the website, you list like RAG, which is retrieval of bank debt generation and agents as two of the main goals of LangChain. The difference I think at the Databricks keynote, you said chains are like predetermined steps and agents is models reasoning to figure out what steps to take and what actions to take. How should people think about when to use the two and how do you transition from one to the other with LangChain? Like is it a path that you support or like do people usually re-implement from an agent to a chain or vice versa? [00:21:05]Swyx: Yeah. [00:21:06]Harrison: You know, I know agent is probably an overloaded term at this point, and so there's probably a lot of different definitions out there. But yeah, as you said, kind of like the way that I think about an agent is basically like in a chain, you have a sequence of steps. You do this and then you do this and then you do this and then you do this. And with an agent, there's some aspect of it where the LLM is kind of like deciding what to do and what steps to do in what order. And you know, there's probably some like gray area in the middle, but you know, don't fight me on this. And so if we think about those, like the benefits of the chains are that they're like, you can say do this and you just have like a more rigid kind of like order and the way that things are done. They have more control and they don't go off the rails and basically everything that's bad about agents in terms of being uncontrollable and expensive, you can control more finely. The benefit of agents is that I think they handle like the long tail of things that can happen really well. And so for an example of this, let's maybe think about like interacting with a SQL database. So you can have like a SQL chain and you know, the first kind of like naive approach at a SQL chain would be like, okay, you have the user question. And then you like write the SQL query, you do some rag, you pull in the relevant tables and schemas, you write a SQL query, you execute that against the SQL database. And then you like return that as the answer, or you like summarize that with an LLM and return that to the answer. And that's basically the SQL chain that we have in LangChain. But there's a lot of things that can go wrong in that process. Starting from the beginning, you may like not want to even query the SQL database at all. Maybe they're saying like, hi, or something, or they're misusing the application. Then like what happens if you have some step, like a big part of the application that people with LangChain is like the context aware part. So there's generally some part of bringing in context to the language model. So if you bring in the wrong context to the language model, so it doesn't know which tables to query, what do you do then? If you write a SQL query, it's like syntactically wrong and it can't run. And then if it can run, like what if it returns an unexpected result or something? And so basically what we do with the SQL agent is we give it access to all these different tools. So it has another tool, it can run the SQL query as another, and then it can respond to the user. But then if it kind of like, it can decide which order to do these. And so it gives it flexibility to handle all these edge cases. And there's like, obviously downsides to that as well. And so there's probably like some safeguards you want to put in place around agents in terms of like not letting them run forever, having some observability in there. But I do think there's this benefit of, you know, like, again, to the other part of what LangChain is like the reasoning part, like each of those steps individually involves some aspect of reasoning, for sure. Like you need to reason about what the SQL query is, you need to reason about what to return. But there's then there's also reasoning about the order of operations. And so I think to me, the key is kind of like giving it an appropriate amount to reason about while still keeping it within checks. And so to the point, like, I would probably recommend that most people get started with chains and then when they get to the point where they're hitting these edge cases, then they think about, okay, I'm hitting a bunch of edge cases where the SQL query is just not returning like the relevant things. Maybe I should add in some step there and let it maybe make multiple queries or something like that. Basically, like start with chain, figure out when you're hitting these edge cases, add in the reasoning step to that to handle those edge cases appropriately. That would be kind of like my recommendation, right? [00:24:09]Swyx: If I were to rephrase it, in my words, an agent would be a reasoning node in a chain, right? Like you start with a chain, then you just add a reasoning node, now it's an agent. [00:24:17]Harrison: Yeah, the architecture for your application doesn't have to be just a chain or just an agent. It can be an agent that calls chains, it can be a chain that has an agent in different parts of them. And this is another part as well. Like the chains in LangChain are largely intended as kind of like a way to get started and take you some amount of the way. But for your specific use case, in order to kind of like eke out the most performance, you're probably going to want to do some customization at the very basic level, like probably around the prompt or something like that. And so one of the things that we've focused on recently is like making it easier to customize these bits of existing architectures. But you probably also want to customize your architectures as well. [00:24:52]Swyx: You mentioned a bit of prompt engineering for self-ask and then for this stuff. There's a bunch of, I just talked to a prompt engineering company today, PromptOps or LLMOps. Do you have any advice or thoughts on that field in general? Like are you going to compete with them? Do you have internal tooling that you've built? [00:25:08]Harrison: A lot of what we do is like where we see kind of like a lot of the pain points being like we can talk about LangSmith and that was a big motivation for that. And like, I don't know, would you categorize LangSmith as PromptOps? [00:25:18]Swyx: I don't know. It's whatever you want it to be. Do you want to call it? [00:25:22]Harrison: I don't know either. Like I think like there's... [00:25:24]Swyx: I think about it as like a prompt registry and you store them and you A-B test them and you do that. LangSmith, I feel like doesn't quite go there yet. Yeah. It's obviously the next step. [00:25:34]Harrison: Yeah, we'll probably go. And yeah, we'll do more of that because I think that's definitely part of the application of a chain or agent is you start with a default one, then you improve it over time. And like, I think a lot of the main new thing that we're dealing with here is like language models. And the main new way to control language models is prompts. And so like a lot of the chains and agents are powered by this combination of like prompt language model and then some output parser or something doing something with the output. And so like, yeah, we want to make that core thing as good as possible. And so we'll do stuff all around that for sure. [00:26:05]Swyx: Awesome. We might as well go into LangSmith because we're bringing it up so much. So you announced LangSmith I think last month. What are your visions for it? Is this the future of LangChain and the company? [00:26:16]Harrison: It's definitely part of the future. So LangSmith is basically a control center for kind of like your LLM application. So the main features that it kind of has is like debugging, logging, monitoring, and then like testing and evaluation. And so debugging, logging, monitoring, basically you set three environment variables and it kind of like logs all the runs that are happening in your LangChain chains or agents. And it logs kind of like the inputs and outputs at each step. And so the main use case we see for this is in debugging. And that's probably the main reason that we started down this path of building it is I think like as you have these more complex things, debugging what's actually going on becomes really painful whether you're using LangChain or not. And so like adding this type of observability and debuggability was really important. Yeah. There's a debugging aspect. You can see the inputs, outputs at each step. You can then quickly enter into like a playground experience where you can fiddle around with it. The first version didn't have that playground and then we'd see people copy, go to open AI playground, paste in there. Okay. Well, that's a little annoying. And then there's kind of like the monitoring, logging experience. And we recently added some analytics on like, you know, how many requests are you getting per hour, minute, day? What's the feedback like over time? And then there's like a testing debugging, sorry, testing and evaluation component as well where basically you can create datasets and then test and evaluate these datasets. And I think importantly, all these things are tied to each other and then also into LangChain, the framework. So what I mean by that is like we've tried to make it as easy as possible to go from logs to adding a data point to a dataset. And because we think a really powerful flow is you don't really get started with a dataset. You can accumulate a dataset over time. And so being able to find points that have gotten like a thumbs up or a thumbs down from a user can be really powerful in terms of creating a good dataset. And so that's maybe like a connection between the two. And then the connection in the other way is like all the runs that you have when you test or evaluate something, they're logged in the same way. So you can debug what exactly is going on and you don't just have like a final score. You have like this nice trace and thing where you can jump in. And then we also want to do more things to hook this into a LangChain proper, the framework. So I think like some of like the managing the prompts will tie in here already. Like we talked about example selectors using datasets as a few short examples is a path that we support in a somewhat janky way right now, but we're going to like make better over time. And so there's this connection between everything. Yeah. [00:28:42]Alessio: And you mentioned the dataset in the announcement blog post, you touched on heuristic evaluation versus LLMs evaluating LLMs. I think there's a lot of talk and confusion about this online. How should people prioritize the two, especially when they might start with like not a good set of evals or like any data at all? [00:29:01]Harrison: I think it's really use case specific in the distinction that I draw between heuristic and LLM. LLMs, you're using an LLM to evaluate the output heuristics, you have some common heuristic that you can use. And so some of these can be like really simple. So we were doing some kind of like measuring of an extraction chain where we wanted it to output JSON. Okay. One evaluation can be, can you use JSON.loads to load it? And like, right. And that works perfectly. You don't need an LLM to do that. But then for like a lot of like the question answering, like, is this factually accurate? And you have some ground truth fact that you know it should be answering with. I think, you know, LLMs aren't perfect. And I think there's a lot of discussion around the pitfalls of using LLMs to evaluate themselves. And I'm not saying they're perfect by any means, but I do think they're, we've found them to be kind of like better than blue or any of those metrics. And the way that I also like to use those is also just like guide my eye about where to look. So like, you know, I might not trust the score of like 0.82, like exactly correct, but like I can look to see like which data points are like flagged as passing or failing. And sometimes the evaluators messing up, but it's like good to like, you know, I don't have to look at like a hundred data points. I can focus on like 10 or something like that. [00:30:10]Alessio: And then can you create a heuristic once in Langsmith? Like what's like your connection to that? [00:30:16]Harrison: Yeah. So right now, all the evaluation, we actually do client side. And part of this is basically due to the fact that a lot of the evaluation is really application specific. So we thought about having evaluators, you could just click off and run in a server side or something like that. But we still think it's really early on in evaluation. We still think there's, it's just really application specific. So we prioritized instead, making it easy for people to write custom evaluators and then run them client side and then upload the results so that they can manually inspect them because I think manual inspection is still a pretty big part of evaluation for better or worse. [00:30:50]Swyx: We have this sort of components of observability. We have cost, latency, accuracy, and then planning. Is that listed in there? [00:30:57]Alessio: Well, planning more in the terms of like, if you're an agent, how to pick the right tool and whether or not you are picking the right tool. [00:31:02]Swyx: So when you talk to customers, how would you stack rank those needs? Are they cost sensitive? Are they latency sensitive? I imagine accuracy is pretty high up there. [00:31:13]Harrison: I think accuracy is definitely the top that we're seeing right now. I think a lot of the applications, people are, especially the ones that we're working with, people are still struggling to get them to work at a level where they're reliable [00:31:24]Swyx: enough. [00:31:25]Harrison: So that's definitely the first. Then I think probably cost becomes the next one. I think a few places where we've started to see this be like one of the main things is the AI simulation that came out. [00:31:36]Swyx: Generative agents. Yeah, exactly. [00:31:38]Harrison: Which is really fun to run, but it costs a lot of money. And so one of our team members, Lance, did an awesome job hooking up like a local model to it. You know, it's not as perfect, but I think it helps with that. Another really big place for this, we believe, is in like extraction of structured data from unstructured data. And the reason that I think it's so important there is that usually you do extraction of some type of like pre-processing or indexing process over your documents. I mean, there's a bunch of different use cases, but one use case is for that. And generally that's over a lot of documents. And so that starts to rack up a bill kind of quickly. And I think extraction is also like a simpler task than like reasoning about which tools to call next in an agent. And so I think it's better suited for that. Yeah. [00:32:15]Swyx: On one of the heuristics I wanted to get your thoughts on, hallucination is one of the big problems there. Do you have any recommendations on how people should reduce hallucinations? [00:32:25]Harrison: To reduce hallucinations, we did a webinar on like evaluating RAG this past week. And I think there's this great project called RAGOS that evaluates four different things across two different spectrums. So the two different spectrums are like, is the retrieval part right? Or is the generation, or sorry, like, is it messing up in retrieval or is it messing up in generation? And so I think to fix hallucination, it probably depends on where it's messing up. If it's messing up in generation, then you're getting the right information, but it's still hallucinating. Or you're getting like partially right information and hallucinating some bits, a lot of that's prompt engineering. And so that's what we would recommend kind of like focusing on the prompt engineering part. And then if you're getting it wrong in the, if you're just not retrieving the right stuff, then there's a lot of different things that you can probably do, or you should look at on the retrieval bit. And honestly, that's where it starts to become a bit like application specific as well. Maybe there's some temporal stuff going on. Maybe you're not parsing things correctly. Yeah. [00:33:19]Swyx: Okay. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. [00:33:35]Harrison: Yeah. Yeah. [00:33:37]Swyx: Yeah. [00:33:38]Harrison: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. [00:33:56]Swyx: Yeah. Yeah. [00:33:58]Harrison: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. [00:34:04]Swyx: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. [00:34:17]Harrison: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah, I mean, there's probably a larger discussion around that, but openAI definitely had a huge headstart, right? And that's... Clawds not even publicly available yet, I don't think. [00:34:28]Swyx: The API? Yeah. Oh, well, you can just basically ask any of the business reps and they'll give it to you. [00:34:33]Harrison: You can. But it's still a different signup process. I think there's... I'm bullish that other ones will catch up especially like Anthropic and Google. The local ones are really interesting. I think we're seeing a big... [00:34:46]Swyx: Lama Two? Yeah, we're doing the fine-tuning hackathon tomorrow. Thanks for promoting that. [00:34:50]Harrison: No, thanks for it. I'm really excited about that stuff. I mean, that's something that like we've been, you know, because like, as I said, like the only thing we know is that the space is moving so fast and changing so rapidly. And like, local models are, have always been one of those things that people have been bullish on. And it seems like it's getting closer and closer to kind of like being viable. So I'm excited to see what we can do with some fine-tuning. [00:35:10]Swyx: Yeah. I have to confess, I did not know that you cared. It's not like a judgment on Langchain. I was just like, you know, you write an adapter for it and you're done, right? Like how much further does it go for Langchain? In terms of like, for you, it's one of the, you know, the model IO modules and that's it. But like, you seem very personally, very passionate about it, but I don't know what the Langchain specific angle for this is, for fine-tuning local models, basically. Like you're just passionate about local models and privacy and all that, right? And open source. [00:35:41]Harrison: Well, I think there's a few different things. Like one, like, you know, if we think about what it takes to build a really reliable, like context-aware reasoning application, there's probably a bunch of different nodes that are doing a bunch of different things. And I think it is like a really complex system. And so if you're relying on open AI for every part of that, like, I think that starts to get really expensive. Also like, probably just like not good to have that much reliability on any one thing. And so I do think that like, I'm hoping that for like, you know, specific parts at the end, you can like fine-tune a model and kind of have a more specific thing for a specific task. Also, to be clear, like, I think like, I also, at the same time, I think open AI is by far the easiest way to get started. And if I was building anything, I would absolutely start with open AI. So. [00:36:27]Swyx: It's something I think a lot of people are wrestling with. But like, as a person building apps, why take five vendors when I can take one vendor, right? Like, as long as I trust Azure, I'm just entrusting all my data to Azure and that's it. So I'm still trying to figure out the real case for local models in production. And I don't know, but fine-tuning, I think, is a good one. That's why I guess open AI worked on fine-tuning. [00:36:49]Harrison: I think there's also like, you know, like if there is, if there's just more options available, like prices are going to go down. So I'm happy about that. So like very selfishly, there's that aspect as well. [00:37:01]Alessio: And in the Lancsmith announcement, I saw in the product screenshot, you have like chain, tool and LLM as like the three core atoms. Is that how people should think about observability in this space? Like first you go through the chain and then you start dig down between like the model itself and like the tool it's using? [00:37:19]Harrison: We've added more. We've added like a retriever logging so that you can see like what query is going in and what are the documents you're getting out. Those are like the three that we started with. I definitely think probably the main ones, like basically the LLM. So the reason I think the debugging in Lancsmith and debugging in general is so needed for these LLM apps is that if you're building, like, again, let's think about like what we want people to build in with LangChain. These like context aware reasoning applications. Context aware. There's a lot of stuff in the prompt. There's like the instructions. There's any previous messages. There's any input this time. There's any documents you retrieve. And so there's a lot of like data engineering that goes into like putting it into that prompt. This sounds silly, but just like making sure the data shows up in the right format is like really important. And then for the reasoning part of it, like that's obviously also all in the prompt. And so being able to like, and there's like, you know, the state of the world right now, like if you have the instructions at the beginning or at the end can actually make like a big difference in terms of whether it forgets it or not. And so being able to kind of like. [00:38:17]Swyx: Yeah. And it takes on that one, by the way, this is the U curve in context, right? Yeah. [00:38:21]Harrison: I think it's real. Basically I've found long context windows really good for when I want to extract like a single piece of information about something basically. But if I want to do reasoning over perhaps multiple pieces of information that are somewhere in like the retrieved documents, I found it not to be that great. [00:38:36]Swyx: Yeah. I have said that that piece of research is the best bull case for Lang chain and all the vector companies, because it means you should do chains. It means you should do retrieval instead of long context, right? People are trying to extend long context to like 100K, 1 million tokens, 5 million tokens. It doesn't matter. You're going to forget. You can't trust it. [00:38:54]Harrison: I expect that it will probably get better over time as everything in this field. But I do also think there'll always be a need for kind of like vector stores and retrieval in some fashions. [00:39:03]Alessio: How should people get started with Langsmith Cookbooks? Wanna talk maybe a bit about that? [00:39:08]Swyx: Yeah. [00:39:08]Harrison: Again, like I think the main thing that even I find valuable about Langsmith is just like the debugging aspect of it. And so for that, it's very simple. You can kind of like turn on three environment variables and it just logs everything. And you don't look at it 95% of the time, but that 5% you do when something goes wrong, it's quite handy to have there. And so that's probably the easiest way to get started. And we're still in a closed beta, but we're letting people off the wait list every day. And if you really need access, just DM me and we're happy to give you access there. And then yeah, there's a lot that you can do with Langsmith that we've been talking about. And so Will on our team has been leading the charge on a really great like Langsmith Cookbooks repo that covers everything from collecting feedback, whether it's thumbs up, thumbs down, or like multi-scale or comments as well, to doing evaluation, doing testing. You can also use Langsmith without Langchain. And so we've got some notebooks on that in there. But we have Python and JavaScript SDKs that aren't dependent on Langchain in any way. [00:40:01]Swyx: And so you can use those. [00:40:01]Harrison: And then we'll also be publishing a notebook on how to do that just with the REST APIs themselves. So yeah, definitely check out that repo. That's a great resource that Will's put together. [00:40:10]Swyx: Yeah, awesome. So we'll zoom out a little bit from Langsmith and talk about Langchain, the company. You're also a first-time founder. Yes. And you've just hired your 10th employee, Julia, who I know from my data engineering days. You mentioned Will Nuno, I think, who maintains Langchain.js. I'm very interested in like your multi-language strategy, by the way. Ankush, your co-founder, Lance, who did AutoEval. What are you staffing up for? And maybe who are you hiring? [00:40:34]Harrison: Yeah, so 10 employees, 12 total. We've got three more joining over the next three weeks. We've got Julia, who's awesome leading a lot of the product, go-to-market, customer success stuff. And then we've got Bri, who's also awesome leading a lot of the marketing and ops aspects. And then other than that, all engineers. We've staffed up a lot on kind of like full stack infra DevOps, kind of like as we've started going into the hosted platform. So internally, we're split about 50-50 between the open source and then the platform stuff. And yeah, we're looking to hire particularly on kind of like the things, we're actually looking to hire across most fronts, to be honest. But in particular, we probably need one or two more people on like open source, both Python and JavaScript and happy to dive into the multi-language kind of like strategy there. But again, like strong focus there on engineering, actually, as opposed to maybe like, we're not a research lab, we're not a research shop. [00:41:48]Swyx: And then on the platform side, [00:41:49]Harrison: like we definitely need some more people on the infra and DevOps side. So I'm using this as an opportunity to tell people that we're hiring and that you should reach out if that sounds like you. [00:41:58]Swyx: Something like that, jobs, whatever. I don't actually know if we have an official job. [00:42:02]Harrison: RIP, what happened to your landing page? [00:42:04]Swyx: It used to be so based. The Berkshire Hathaway one? Yeah, so what was the story, the quick story behind that? Yeah, the quick story behind that is we needed a website [00:42:12]Harrison: and I'm terrible at design. [00:42:14]Swyx: And I knew that we couldn't do a good job. [00:42:15]Harrison: So if you can't do a good job, might as well do the worst job possible. Yeah, and like lean into it. And have some fun with it, yeah. [00:42:21]Swyx: Do you admire Warren Buffett? Yeah, I admire Warren Buffett and admire his website. And actually you can still find a link to it [00:42:26]Harrison: from our current website if you look hard enough. So there's a little Easter egg. Before we dive into more of the open source community things, [00:42:33]Alessio: let's dive into the language thing. How do you think about parity between the Python and JavaScript? Obviously, they're very different ecosystems. So when you're working on a LangChain, is it we need to have the same abstraction in both language or are you to the needs? The core stuff, we want to have the same abstractions [00:42:50]Harrison: because we basically want to be able to do serialize prompts, chains, agents, all the core stuff as tightly as possible and then use that between languages. Like even, yeah, like even right now when we log things to LangChain, we have a playground experience where you can run things that runs in JavaScript because it's kind of like in the browser. But a lot of what's logged is like Python. And so we need that core equivalence for a lot of the core things. Then there's like the incredibly long tail of like integrations, more researchy things. So we want to be able to do that. Python's probably ahead on a lot of like the integrations front. There's more researchy things that we're able to include quickly because a lot of people release some of their code in Python and stuff like that. And so we can use that. And there's just more of an ecosystem around the Python project. But the core stuff will have kind of like the same abstractions and be translatable. That didn't go exactly where I was thinking. So like the LangChain of Ruby, the LangChain of C-sharp, [00:43:44]Swyx: you know, there's demand for that. I mean, I think that's a big part of it. But you are giving up some real estate by not doing it. Yeah, it comes down to kind of like, you know, ROI and focus. And I think like we do think [00:43:58]Harrison: there's a strong JavaScript community and we wanted to lean into that. And I think a lot of the people that we brought on early, like Nuno and Jacob have a lot of experience building JavaScript tooling in that community. And so I think that's a big part of it. And then there's also like, you know, building JavaScript tooling in that community. Will we do another language? Never say never, but like... [00:44:21]Swyx: Python JS for now. Yeah. Awesome. [00:44:23]Alessio: You got 83 articles, which I think might be a record for such a young company. What are like the hottest hits, the most popular ones? [00:44:32]Harrison: I think the most popular ones are generally the ones where we do a deep dive on something. So we did something a few weeks ago around evaluating CSV q

BONUS EPISODE - The Legendary Clint Orms took time to sit down with host Taylor McAdams during the Western and English Sales Association (WESA) show to look back on his career and life and share stories from his humble beginnings. World-renowned, Clint is known for his jewelry quality engraved Western ranger buckles, trophy buckles, dress buckles, money clips, cufflinks, and more.

Aji & guest host Mercedes Bernard talk ORMs & SQL, left outer joins & includes, and strict & eager loading.Reading for this episode: Active Record Query InterfaceThe Bike Shed episode 358: The Class MethodReading for next episode: Active Model BasicsFind Mercedes online at mercedesbernard.com, on mastodon: mercedescodes@mastodon.world, or LinkedIn

In this episode of Syntax, Wes and Scott talk about the benefits and potential drawbacks of using an ORM on your next project, as well as what some of the popular ORMs are. Show Notes 00:10 Welcome 00:39 Dental cleanings 03:00 What's an ORM? 05:51 Benefits of using an ORM 12:54 Validation in ORM 19:18 What about Types? 23:44 Popular ORMs Prisma Sequelize Objection.js Knex.js DrizzleORM - next gen TypeScript ORM Mongoose ODM v7.3.1 TypeORM waterline.js 42:41 Potential downsides to using an ORM 45:53 Database schemas 52:30 Hooks or events 55:27 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Scott: I Think You Should Leave with Tim Robinson Wes: Wise, Formerly TransferWise: Online Money Transfers Shameless Plugs Scott: Sentry 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 Wes Bos on Bluesky Scott on Bluesky Syntax on Bluesky

Nick & KBall sit down with the brilliant Stephen Haberman to discuss all things ORMs!

Nick & KBall sit down with the brilliant Stephen Haberman to discuss all things ORMs!

For this week's episode, Mina is in Japan, the couple read "Active Record Basics" and discuss ORMs, naming conventions and have a special request to you, the listeners.Reading for this episode: "Active Record Basics"Patterns of Enterprise Application Architecture by Martin FowlerMats'z Home ConferenceReading for Episode 5: Chapters 1 - 4 in "Active Record Migrations"

Dans cet épisode, Arnaud, Antonio et Emmanuel décortiquent les nouvelles d'avril et mai. On y discute Java 20, ecrire un profiler de zéro, Quarkus 3 (encore !), Micronaut 4, Podman, JReleaser, GitHub, CloudEvent, GraphQL, licenciements (encore !), et de la question a 1000 francs: librarie vs framework, quelle différence? Mais pas que. Enregistré le 12 mai 2023 Téléchargement de l'épisode LesCastCodeurs-Episode–295.mp3 News Langages Un descriptif du changement de paiement d'Oracle JDK https://horstmann.com/unblog/2023–02–23/ Cay Horstmann Explique OpenJDK avec plusieurs distributeurs Prefère Adoptium dont celle par défaut est Eclipse Temurin Pour Oracle, beaucoup d'options de licenses (no-fee, binary code, OTM license) Oracle depense beaucoup pour Java La license en discussion est Java SE Universal Subscription Licensing passage de license par CPU (Java SE advanced) vers license par employé (et une assiete large) Bref si vous êtes concernés, passer sur OpenJDK: Adoptium, ou d'autres vendeurs Java 20 est sorti : qu'y a t'il de nouveau dans Java 20 par rapport à Java 19 ? https://foojay.io/today/its-java–20-release-day-heres-whats-new/ L'article fait le point sur ce qu'il y a de nouveau par rapport à la précédente release : 4ème preview du pattern matching pour switch 2nde preview des record patterns 2nde preview des virtual threads incubation des scoped values (similaire au thread locals mais pour les virtual threads) 2nde incubation de la structured concurrency 2nd preview de foreign function et memory API 5ème incubation de la vector API (pour utiliser les instructions vectorielles des processeurs) La liste des JEPs : https://openjdk.org/projects/jdk/20/ Les release notes : https://jdk.java.net/20/release-notes dans le pattern matching switch: guarde when Record pattern: utilisation de var. utilisable dans les for aussi maintenant for (Delay(var timeInMS) : delays) quelques changements autour de l'API Thread est non preview (main API) Les ScopedValue sont comme les threadlocal par (virtual) thread mais elles sont immuables une fois écrites. use cases: copie d'etat pour des données non changeantes pour le virtual thread Serait interessant d'avoir des details dessus PDF 2.0 maintenant un vrai format ISO ouvert et gratuit https://www.pdfa.org/sponsored-standards/ standard dispo sans cout versions precedentes étaient payantes clarifications et corrections de beaucoup de corner cases Librairies Écrire un Profiler en 240 lignes de Java https://mostlynerdless.de/blog/2023/03/27/writing-a-profiler-in–240-lines-of-pure-java/ Ce n'est peut-être pas si compliqué d'écrire soi même un Java Profiler ! Et justement cet article nous montre comment le faire, en créant un Java Agent, en analysant les stacks d'appel, et à la fin en créant même un flame-graph en HTML Très didactique ! fondamentallement: appeler Threads:getAlStackStrace reguilerement et faire une liste des methodes visibles et créer un flamegraph a partir de ces données L'équipe de Flutter partage les grands thèmes de sa roadmap https://flutter.dev/go/strategy–2023 Performance, interopérabilité, portabilité, écosystème, sécurité, fondamentaux (comme la documentation, la fidélité des UI natives, adresser les issues publiques) Quarkus 3 est sorti https://quarkus.io/quarkus3/ on a deja couvert Hibernate ORM 6.2 nouvelle DevUI et admin sur un port different Support for Pact quarkus deply et extensibilite de la CLI avec des nouveaux verbes dev services for Kubernetes simule un Kube pour tester les calls vers l'API Kube Java 11 et 17 (recommendé) Jakarta EE Eclipse MicroProfile 6 Une librairie en Java spécialement pour l'astronomie par Cédric Champeau https://melix.github.io/blog//2023/04–22-introducing-astro4j.html différentes librairies et applications pour traiter les images issues de sol'ex qui permet de prendre des photos du soleil Micronaut 4 milestone 2 est sorti. Les nouveautés de Micronaut 4 https://docs.micronaut.io/4.0.0-M2/guide/index.html#whatsNew Kotlin 1.8.0 Experimental Support for Kotlin Symbol Processing (KSP) Apache Groovy 4.0 Core Changes Java 17 Baseline Improved Modularity GraalVM Metadata Repository and Runtime Initialization Completed javax to jakarta Migration Expression Language Injection of Maps Arbitrary Nesting of Configuration Properties Improved Error Messages for Missing Configuration Improved Error Messages for Missing Beans Tracking of Disabled Beans HTTP Changes Initial Support for Virtual Threads (Loom) Rewritten HTTP layer Annotation-Based HTTP Filters JDK HTTP Client Infrastructure 5 choses à savoir sur Podman Desktop pour un utilisateur Docker https://podman-desktop.io/blog/5-things-to-know-for-a-docker-user Une UI unique pour travailler avec différents moteur de conteneurs, et pas uniquement Docker Compatible avec Docker avec un mode adapté pour fonctionner aussi avec la docker CLI ou docker.sock pour les sockets Support de Compose Support de Kubernetes Securité : on peut utilisé rootless sans avoir les privilèges root socket est particulierement utile pour TestContainer compose n'est pas supporte en tant que tel mais on pout faire utiliser podman par compose podman peut emuiler / executer des definitions de pods si besoin d'exposer des ports code est meilleur mais synchro front back toujours un probleme en pratique erreurs, plus simple en rest avec les codes HTTP a debugger et monitorer version free est une mensonge, les schemas ne peuvent etre cassés pagination est compliqué et non standard et caching est primitif comparé a REST n+1 probleme comme dans les ORMs ou alors dataloaders qui amene de la complexité securite est plus compliqué a cause de la nav libre de GraphQL ecosysteme pas super mature pour les besoins encore et paradoxalement tres complexe Méthodologies Trends technologie et culture par InfoQ https://www.infoq.com/articles/culture-trends–2023/ les licenciement ont cassé les effets de psychological safety dans l'industrie les IA genratives ont un impact fort sur la productivité du développeur mais aussi avec des faiblesses significatives au dela du legal, les responsabilités societales deviennent plus importantes pour retenir employés et clients Le travail asynchrone devient plus accepté socialement et adopter les practiques apportent des bénéfices réels Le travail hybride devient la norme, amener les gens ensemble devient un choix délibéré, plus un horaire fixe Loi, société et organisation Red Hat fête ses 30 ans ! (limite, on n'était même pas nés, hein ?) https://www.redhat.com/en/blog/red-hat–30th-anniversary-celebrating-red-hat-day-north-carolina Red Hat licencie 4% de ses employés https://wraltechwire.com/2023/04/24/red-hat-cutting-hundreds-of-jobs-ceo-says-in-letter-to-employees/ IBM avait annoncé 3900 licenciements il y a peu et cela monte à 5000 avec les licenciements chez Redhat (les effectifs étaient de 2200 à Raleigh et 19000 à l'international) Licenciements suite au contexte économique post Covid, les revenus trimestriels de redhat n.ont été que de 8% en Q1 alors que la croissance était de 15 depuis l'acquisition de redhat par ibm en 2019 Crazy Bob est décédé :scream: https://www.sfgate.com/bayarea/article/mill-valley-man-killed-sf-stabbing–17878809.php Annonce sur TechCrunch https://techcrunch.com/2023/04/05/bob-lee-creator-of-cash-app-and-former-cto-of-square-stabbed-to-death/ Il avait créé le framework Guice, d'injection de dépendance, mais aussi Dagger Il a contribué aux librairies d'Android Il avait proposé une syntaxe alternative aux lambda : CIC Il a coécrit le livre Bitter EJB https://www.manning.com/books/bitter-ejb Il avait des idées bien tranchées, anti-Spring, anti-Groovy (pro-BeanShell), anti-lambda (tels qu'on les connait aujourd'hui) Guillaume l'avait rencontré pour la première fois en 2007 https://blog.octo.com/javaone–2007-et-groovy-chez-google/ Les gens partagent leurs souvenirs sur ce thread sur HackerNews https://news.ycombinator.com/item?id=35457341 10 millions de comptes sur Mastodon https://mastodon.social/@mastodonusercount/110051957865629817 Peut-être pas 10 millions de comptes actifs, mais d'autres commentateurs estiment le nombre d'actifs serait plutôt de 6 à 7 millions actifs, pour effectivement 10 millions de comptes créés donc certains inutilisés ou disparus (serveur disparu) Gordon Moore meure à 94 ans https://www.lemonde.fr/economie/article/2023/03/26/mort-de-gordon-moore-entrepreneur-par-accident-et-cofondateur-d-intel_6167037_3234.html#xtor=AL–32280270-%5Bdefault%5D-%5Bios%5D chimiste de formation, il refuse de bosser autour de la bombe atomique et fini dans la silicon valley fonde un des premiers semiconducteurs (plusieurs transistors ensemble) Intel sera un des rpemier a parier sur le silicium (pour construire de la mémoire) et un des premiers a faire une puce intégré regroupant plusieurs fonctions Twitter open source ses algorithmes de recommendation https://blog.twitter.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm on retrouve le code source sur Github https://github.com/twitter/the-algorithm-ml et quelqu'un a déjà trouvé où il y a des clauses particulières pour le cas où un tweet vient d'Elon Musk, où un tweet vient d'un républicain ou d'un démocrate https://uwyn.net/@danluu@mastodon.social/110119479811452246 L'algorithme de Twitter https://aakashgupta.substack.com/p/the-real-twitter-files-the-algorithm analyse sans sensation trois étapes: aggravation des données, construction des “features”, mixage Followers, nos tweets et nous Plus gros booster likes 30x, puis retweet 20x Features: SimCluster: groupe par categories/personnes le tweet Feature: TwHIN: vecteur de prediction d'engagement pour un tweet donné Features: RealGraph, prend le tweet, the tweeter et le tweeté et construit un graphe pondéré de potentiel d'interaction Règles de confiance et securité: élimine certains sujets (cela censure plus depuis Elon Musk) Mixer: prend tout et construit la “timeline” Utilisateur répond aux réponses: x75 En fait que 80% du code ouvert The end of faking it in silicon valley https://www.nytimes.com/2023/04/15/business/silicon-valley-fraud.html les startup qui brulaient du cash sans business model clair proces et prisons pour falsification de données clients le approches non etique ne sont plus ignorées avant les investisseurs avaient peur de se mettre les createur de boite a dos, maintenant, l'argent vaut cher “finding out who is swimming naked when the tide goes out” Warren Buffet “It feels like we were in a nightclub and the lights just turned on” ils vont evaluer plus exhaustivement les foundateurs le probleme c'est que VC c'est sur la confiance (one way au moins) et que la c'est cassé Rubrique débutant On parle souvent de librairies et de frameworks, mais c'est quoi la différence ? https://www.red-gate.com/simple-talk/development/other-development/the-difference-between-libraries-and-frameworks/ Une librairie est une collection de classes, de fonctions, de code, que l'ont peut utiliser pour des tâches spécifiques, pour éviter au développeur de réinventer la roue (par exemple une librairie comme Joda Time qui permet de simplifier / codifier la représentation du temps) Il y a différents types de librairies : des librairies statiques ou dynamiques, suivant si elles sont chargées au runtime ou bien attachées au code que l'on compile. Il y a des librairies standards (comme celles venant du JDK et donc inclues avec lui) ou des librairies tierces (que l'on va par exemple trouver sur Maven Central) Un framework (un “cadriciel” en bon françois) c'est aussi un ensemble de code, mais aussi de librairies, qui va offrir un cadre de développement pour ses applications. Par exemple un framework web qui permet de créer des applications web plus facilement, ou Tensorflow pour développer de nouveaux algorithmes d'intelligence artificielle, ou Unity pour développer des jeux vidéos Mais un framework est effectivement plus “cadrant” dans le sens où on doit suivre ses recommendations sur comment structurer son code, comment étendre des classes ou interfaces du framework, etc. ainsi que les bonnes pratiques et parfois une boite a outil “prete a l'emploi vs assemblage article decrit les pour et les contre Conférences Une liste de conférences Java https://javaconferences.org/ La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 10–12 mai 2023 : Devoxx UK - London (UK) 12 mai 2023 : AFUP Day - Lille & Lyon (France) 12 mai 2023 : SoCraTes Rennes - Rennes (France) 25–26 mai 2023 : Newcrafts Paris - Paris (France) 26 mai 2023 : Devfest Lille - Lille (France) 27 mai 2023 : Polycloud - Montpellier (France) 31 mai 2023–2 juin 2023 : Devoxx Poland - Krakow (Poland) 31 mai 2023–2 juin 2023 : Web2Day - Nantes (France) 1 juin 2023 : Javaday - Paris (France) 1 juin 2023 : WAX - Aix-en-Provence (France) 1–2 juin 2023 : Agile Tour Toulouse - Toulouse (France) 2 juin 2023 : Flutter Connection - Paris (France) 2–3 juin 2023 : Sud Web - Toulouse (France) 7 juin 2023 : Serverless Days Paris - Paris (France) 14–15 juin 2023 : OW2 openSource Conf - Paris (France) 14–17 juin 2023 : VivaTech (Viva Technology) - https://vivatechnology.com/) - Paris (France) 15–16 juin 2023 : Le Camping des Speakers - Baden (France) 15–17 juin 2023 : Pas Sage En Seine - Choisy-le-Roi (France) 20 juin 2023 : Mobilis in Mobile - Nantes (France) 20 juin 2023 : Cloud Est - Villeurbanne (France) 20–22 juin 2023 : Adeo DevSummit - Lille (France) 21–23 juin 2023 : Rencontres R - Avignon (France) 28–30 juin 2023 : Breizh Camp - Rennes (France) 29 juin 2023 : Google Cloud Summit France - Paris (France) 29–30 juin 2023 : Sunny Tech - Montpellier (France) 29–30 juin 2023 : Agi'Lille - Lille (France) 7–9 juillet 2023 : Nantes Maker Campus - Nantes (France) 8 septembre 2023 : JUG Summer Camp - La Rochelle (France) 18 septembre 2023 : Agile Tour Montpellier - Montpellier (France) 19–20 septembre 2023 : Agile en Seine - Paris (France) 19 septembre 2023 : Salon de la Data Nantes - Nantes (France) & Online 21–22 septembre 2023 : API Platform Conference - Lille (France) & Online 25–26 septembre 2023 : BIG DATA & AI PARIS 2023 - Paris (France) 28–30 septembre 2023 : Paris Web - Paris (France) 2–6 octobre 2023 : Devoxx Belgium - Antwerp (Belgium) 6 octobre 2023 : DevFest Perros-Guirec - Perros-Guirec (France) 10 octobre 2023 : ParisTestConf - Paris (France) 11–13 octobre 2023 : Devoxx Morocco - Agadir (Morocco) 12 octobre 2023 : Cloud Nord - Lille (France) 12–13 octobre 2023 : Volcamp 2023 - Clermont-Ferrand (France) 12–13 octobre 2023 : Forum PHP 2023 - Marne-la-Vallée (France) 19–20 octobre 2023 : DevFest Nantes - Nantes (France) 19–20 octobre 2023 : Agile Tour Rennes - Rennes (France) 26 octobre 2023 : Codeurs en Seine - Rouen (France) 25–27 octobre 2023 : ScalaIO - Paris (France) 26–27 octobre 2023 : Agile Tour Bordeaux - Bordeaux (France) 10 novembre 2023 : BDX I/O - Bordeaux (France) 15 novembre 2023 : DevFest Strasbourg - Strasbourg (France) 16 novembre 2023 : DevFest Toulouse - Toulouse (France) 6–7 décembre 2023 : Open Source Experience - Paris (France) 7–8 décembre 2023 : TechRocks Summit - Paris (France) 31 janvier 2024–3 février 2024 : SnowCamp - Grenoble (France) 19–22 mars 2024 : KubeCon + CloudNativeCon Europe 2024 - Paris (France) 28–29 mars 2024 : SymfonyLive Paris 2024 - Paris (France) 17–19 avril 2024 : Devoxx France - Paris (France) 25–26 avril 2024 : MiXiT - Lyon (France) 25–26 avril 2024 : Android Makers - Paris (France) 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/

On the radio show today:   1 - Jordan Watson: World record jandal runner 5 - Crook Book 7 - Must Watch: Air 10 - Creed Hotline 14 - Livin' on the edge 19 - Poorly explain your job: "hairy growler" 24 - Serj Tankian interview part 2 28 - Dr Caleb's Girlfriend Reviews: System of a Down 32 - Last drinks See omnystudio.com/listener for privacy information.

Summary The most interesting and challenging bugs always happen in production, but recreating them is a constant challenge due to differences in the data that you are working with. Building your own scripts to replicate data from production is time consuming and error-prone. Tonic is a platform designed to solve the problem of having reliable, production-like data available for developing and testing your software, analytics, and machine learning projects. In this episode Adam Kamor explores the factors that make this such a complex problem to solve, the approach that he and his team have taken to turn it into a reliable product, and how you can start using it to replace your own collection of scripts. Announcements Hello and welcome to the Data Engineering Podcast, the show about modern data management Truly leveraging and benefiting from streaming data is hard - the data stack is costly, difficult to use and still has limitations. Materialize breaks down those barriers with a true cloud-native streaming database - not simply a database that connects to streaming systems. With a PostgreSQL-compatible interface, you can now work with real-time data using ANSI SQL including the ability to perform multi-way complex joins, which support stream-to-stream, stream-to-table, table-to-table, and more, all in standard SQL. Go to dataengineeringpodcast.com/materialize (https://www.dataengineeringpodcast.com/materialize) today and sign up for early access to get started. If you like what you see and want to help make it better, they're hiring (https://materialize.com/careers/) across all functions! Data and analytics leaders, 2023 is your year to sharpen your leadership skills, refine your strategies and lead with purpose. Join your peers at Gartner Data & Analytics Summit, March 20 – 22 in Orlando, FL for 3 days of expert guidance, peer networking and collaboration. Listeners can save $375 off standard rates with code GARTNERDA. Go to dataengineeringpodcast.com/gartnerda (https://www.dataengineeringpodcast.com/gartnerda) today to find out more. Your host is Tobias Macey and today I'm interviewing Adam Kamor about Tonic, a service for generating data sets that are safe for development, analytics, and machine learning Interview Introduction How did you get involved in the area of data management? Can you describe what Tonic is and the story behind it? What are the core problems that you are trying to solve? What are some of the ways that fake or obfuscated data is used in development and analytics workflows? challenges of reliably subsetting data impact of ORMs and bad habits developers get into with database modeling Can you describe how Tonic is implemented? What are the units of composition that you are building to allow for evolution and expansion of your product? How have the design and goals of the platform evolved since you started working on it? Can you describe some of the different workflows that customers build on top of your various tools What are the most interesting, innovative, or unexpected ways that you have seen Tonic used? What are the most interesting, unexpected, or challenging lessons that you have learned while working on Tonic? When is Tonic the wrong choice? What do you have planned for the future of Tonic? Contact Info LinkedIn (https://www.linkedin.com/in/adam-kamor-85720b48/) @AdamKamor (https://twitter.com/adamkamor) on Twitter Parting Question From your perspective, what is the biggest gap in the tooling or technology for data management today? Closing Announcements Thank you for listening! Don't forget to check out our other shows. Podcast.__init__ (https://www.pythonpodcast.com) covers the Python language, its community, and the innovative ways it is being used. The Machine Learning Podcast (https://www.themachinelearningpodcast.com) helps you go from idea to production with machine learning. Visit the site (https://www.dataengineeringpodcast.com) to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show then tell us about it! Email hosts@dataengineeringpodcast.com (mailto:hosts@dataengineeringpodcast.com)) with your story. To help other people find the show please leave a review on Apple Podcasts (https://podcasts.apple.com/us/podcast/data-engineering-podcast/id1193040557) and tell your friends and co-workers Links Tonic (https://www.tonic.ai/) Djinn (https://djinn.tonic.ai/?signup) Django (https://www.djangoproject.com/) Ruby on Rails (https://rubyonrails.org/) C# (https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/) Entity Framework (https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/) PostgreSQL (https://www.postgresql.org/) MySQL (https://www.mysql.com/) Oracle DB (https://www.oracle.com/database/) MongoDB (https://www.mongodb.com/) Parquet (https://parquet.apache.org/) Databricks (https://www.databricks.com/) Mockaroo (https://www.mockaroo.com/) The intro and outro music is from The Hug (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/Love_death_and_a_drunken_monkey/04_-_The_Hug) by The Freak Fandango Orchestra (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/) / CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/)

In this supper club episode of Syntax, Wes and Scott talk with Nikolas Burke from Prisma about the role an ORM plays in a tech stack, how Prisma has changed over the years, ways to query data in Prisma, and how migrations work with Prisma. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Storyblok - Sponsor Storyblok is a headless component-based CMS with a real-time visual editor. It offers the flexibility for developers to craft their perfect tech stack, but it also empowers content creators to make changes independently. The result is that every team has the freedom to quickly and easily create the ideal website with limitless extensibility. Other key features include robust Storyblok SDKs and APIs, powerful internationalization options, and an eCommerce-ready platform. FireHydrant - Sponsor Incidents are hard. Managing them shouldn't be. FireHydrant makes it easy for anyone in your organization to respond to incidents efficiently and consistently. Intuitive, guided workflows provide turn-by-turn navigation for incident response, while thoughtful prompts and powerful integrations capture all of your incident data to drive useful retros and actionable analytics. Did we mention that FireHydrant is free? Get started at Firehydrant.com/syntax. Show Notes 00:35 Welcome 01:30 Guest intro @NikolasBurk on Twitter 04:56 How has Prisma evolved? Prisma Keystone GraphQL 10:44 What was Prisma V1? 17:04 Is there any GraphQL specific functions in Prismic? 21:26 Sponsor: Hasura 22:26 What role does an ORM play in a tech stack? 29:54 What is Planetscale? Planetscale The T3 Stack 32:22 Where does TRPC fit? tRPC 33:46 Sponsor: Storyblok 35:28 What is an ORM? Prisma VS Code plugin 42:00 How do migrations work with Prisma? 45:58 Query your data with Prisma client 49:43 Have you looked into alternative JavaScript environments? 55:16 Sponsor: FireHydrant 57:05 Supper Club questions 58:50 SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Lichess Shameless Plugs Prisma blog 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

On today's episode of Credit Union Conversations, Mark is joined by Derek Ezovski. Derek has considerable experience in environmental and property risk management. Spending his entire career helping companies create best practices, Derek shares with us about his business, ORMS, hot-button topics and information on lending and environmental risks to consider. Tune in to learn more!

Today on the show, Will talks about his latest project, Trustified.io and the steps he is considering to make it DevOps ready. Will and Jonathan discuss creating the dev environment, standardized logging, CI/CD, health checks, standardized reporting dashboards, configuring the app, database migration tools, user management, and ORMs. Elements to Make an App DevOps Ready: 1. Creating the dev environment 2. Standardized logging 3. CI/CD 4. Health checks 5. Prometheus 6. Standardized reporting dashboards 7. Configuring the app 8. Database migration tools 9. User management 10. ORMs Sponsors Top End Devs (https://topenddevs.com/) Coaching | Top End Devs (https://topenddevs.com/coaching) Picks Jonathan- 49" CHG90 QLED Gaming Monitor Monitors - LC49HG90DMNXZA (https://www.samsung.com/us/computing/monitors/gaming/49--chg90-qled-gaming-monitor-lc49hg90dmnxza/) Will- The Sovereign Individual: Mastering the Transition to the Information Age (https://www.amazon.com/Sovereign-Individual-Mastering-Transition-Information/dp/0684832720) Will- Trustified.io (http://trustified.io/)

First time co-host Jan Kleinert joins Mark Mirchandani this week to talk about database observability and the cool tools that make it possible. Morgan McLean and Nimesh Bhagat describe database observability, which uses metrics, logs, and other tools to help users understand the health of your database. We talk about Object Relational Mappers and the challenges with using these for debugging database performance. SQL Commenter helps database observability in two ways: it is both a library and a standard, Nimesh tells us. He describes the process for us, detailing exactly how SQL Commenter effects projects. Recently, SQL Commenter was donated to OpenTelemetry to augment the observability offerings, create an application standard, and make it easier for developers to use a variety of different tools and languages. Engineers can get end-to-end traces no matter which database technologies they use. Morgan tells us about Splunk and how information from SQL Commenter is taken into Splunk and used. Backend data like metrics from Cloud Monitoring and client libraries can be correlated together with SQL Commenter and brought into Splunk for full stack observability. Nimesh offers client examples to help us understand how these useful tools integrate for optimal observability. He tells us about the databases and ORMs supported by SQL Commenter. Our guests and co-host Jan give tips to help our listeners get started with SQL Commenter and talk about what they're looking forward to in the future of observability. Nimesh Bhagat Nimesh is a product manager at Google Cloud, he leads Database Observability. He has worked across engineering and product roles, building highly available and high performance enterprise infrastructure used by Fortune 500 companies. His passion lies in combining powerful infrastructure with simple user experience so that every business and developer can build software at scale and velocity. Morgan McLean Morgan is ​​Director of Product Management at Splunk and co-creator of OpenCensus / OpenTelemetry. Cool things of the week Google Cloud Innovators site Redesigning the Cloud SDK + CLI for easier development blog GCP Podcast Episode 291: Redesigning the Cloud SDK and CLI with Wael Manasra and Cody Oss podcast What is Active Assist? video GCP Podcast Episode 235: Active Assist with Chris Law + MariaDB SkySQL with Robert Hedgepeth podcast Interview SQL Commenter site Sequelize site SQL Alchemy site ADO.net site GCP Podcast Episode 247: Cloud SQL Insights with Nimesh Bhagat podcast OpenTelemetry site Splunk site Cloud Monitoring site Cloud Spanner site Cloud SQL site Cloud Trace site Sqlcommenter now extending the vision of OpenTelemetry to databases blog Hosts Mark Mirchandani and Jan Kleinert

Rachel Hoolahan is an architect and sustainability co-ordinator at Orms Architects, a leading London practice with extensive experience working with existing buildings. For the past few years, the practice has engaged in a series of deep research assignments and is utilising this data and knowledge to push the boundaries of sustainable development – both in refurbishment and new build projects.Recently, she led a research piece on material passports as part of a wider Grosvenor Estate Innovation Project into material reuse. The outcome of this work is a methodology for encouraging more meaningful material reuse, by creating a material database for the project. The approach is deliberately open source and flexible, allowing design teams of any size or skill set to apply the work to their projects.Rachel is the recipient of the 2021 AJ100 Sustainability Champion AwardThis episode covers:What circular economy means for buildings Material passportsBuildings as Material Banks (BAMB)Building a culture of sustainabilityConsumerism and fast fashioned As you may have guessed, this episode is all about Circularity, also called Circular Economy. Rachel explains so clearly why reusing construction and building materials is so important, but also practically how to do it, with examples from her own work. We also talk about how Orms Architects are embedding sustainability in their work culture, which is fascinating. And we end with a discussion on consumerism, the fashion industry and how we need a change in mindset to live within the planet's boundaries.Follow the Green Urbanist:https://twitter.com/GreenUrbanPodhttps://www.instagram.com/greenurbanistpodhttps://www.linkedin.com/company/green-urbanist-podcast

In this episode, I talked to Maksim Lin. Maks is a Google Developer Expert in Flutter, and he's an Android and Flutter Developer. He's a passionate contributor, user, and supporter of open-source software. He's also a regular speaker at technical conferences and local developer group meetups.Today, we are going to talk about isolates, isolate groups, the actor model, improvements and limitations of isolates, concurrency, and we will even talk a little bit about "the soul of Erlang and Elixir".It's Maks's second episode on the Flutter 101 podcast. In Episode 21, Maks and I were talking about WebAssembly, Dart, and his Dart-WASM project. In both episodes, I had these "wow" moments, as I realized how important WebAssembly will become in the coming years in software development, I had these "wow" moments, as I realized the potential behind the improvements to the Isolates, how the isolates make Dart such a powerful language... so I really hope that you will be just as excited when you are listening to this episode as I was when we recorded it.Guest: Maksim LinTwitter @mklinGitHub @maksWeb manichord.com: "Flutter and Android App development and consulting"Dart, WASM and AssemblyScript - Oh my!Featherweight Isolates in Flutter (Flutter Engage)Host: Vince VargaTwitter @vincevargadevGitHub @vincevargadevLinkedIn @vincevargadevWeb vincevarga.devFlutter 101 Podcast on Twitter @flutter101devMost relevant past episodes from Flutter 101WebAssembly and Dart with Maksim Lin (Episode 21): I invited Maks to chat as I saw a very interesting post written by him about WASM and Dart. In this episode, we'll clarify what WebAssembly is and why it's important for Flutter and Dart developers.Dart in the Cloud, Backend, Command Line, and Shelf with Kevin Moore (Episode 14): Kevin Moore is a Product Manager at Google working on Dart and Flutter. Dart in the cloud, on the backend, and on the command line. Functions Framework for Dart, Google Cloud Run, Docker and Dart, Shelf, and many many other useful packages.Dart Server Framework Alfred with Ryan Knell (Episode 11): Ryan Knell is the author of the performant, Express.js-like Dart server framework Alfred. We talked about the state of full-stack Dart, ORMs, backend frameworks, Flutter, and many more!Mentioned packagespub.dev/packages/shelf: A model for web server middleware that encourages composition and easy reuseOther resourcesFeatherweight Isolates in Flutter (Flutter Engage)Lightweight Isolates & Faster isolate communication #36097The Soul of Erlang and Elixir - Saša Jurić (GOTO 2019)Actor model (Wikipedia)

My guest in this episode is Kevin Moore. Kevin is a Product Manager at Google working on Dart and Flutter.In one of the last episodes of the Flutter 101 podcast, I talked to Ryan Knell, the author of the Alfred package. Kevin, who works as Product Manager at Google, listened to the episode. He then shared on Twitter, that he would love to come on and explain more about his thoughts on pkg:shelf and Dart on the server and CLI. Of course, I invited him immediately!Most people know Dart as the language behind Flutter. Flutter code is powered by the world-class Dart platform, which enables compilation to 32-bit and 64-bit ARM machine code for iOS and Android, as well as JavaScript for the web and Intel x64 for desktop devices.Dart is also used for tooling, as command-line apps, running web servers, and more. pub.dev is also running on Dart and it's serving millions! It's a great match as a backend language for teams and developers who already write Flutter. If your Flutter app needs a backend or you need to glue some services together, Dart is a great match.We talked about how you can run Dart in the cloud today. You can use Cloud Run's container support, combined with Dart's Docker images, to run server-side Dart code.We briefly talked about the Functions Framework that makes it easy to write Dart functions instead of server applications for handling web requests. Using the framework, you can create functions that handle HTTP requests and CloudEvents and deploy your Dart functions to Google Cloud.Lastly, we also talked about command-line apps, and Kevin shared his tips on which packages can improve your development experience while writing and using Dart on the command line.Guest: Kevin MooreTwitter @kevmooGitHub @kevmooLinkedIn linkedin.com/in/kevmooReddit @kevmooMedium @kevmooHost: Vince VargaTwitter @vincevargadevGitHub @vincevargadevLinkedIn @vincevargadevWeb vincevarga.devMost relevant past episodes from Flutter 101Dart Server Framework Alfred with Ryan Knell (Episode 11): Ryan Knell is the author of the performant, Express.js-like Dart server framework Alfred. We talked about the state of full-stack Dart, ORMs, backend frameworks, Flutter, and many more!Dart on AWS Lambda and Serverless Computing with Sebastian Döll (Episode 6): We talked to Sebastian Döll (GitHub Microsoft, previously Solutions Architect at AWS) about serverless computing, the state of serverless Dart, and how he implemented a custom AWS Lambda Runtime for Dart.Backend and Frontend Web with Dart with Jermaine Oppong (Episode 7): We talked about backend and frontend Dart with Web Developer and YouTuber Jermaine Oppong. Shelf, Alfred, Aqueduct, Angel, AngularDart, and more.Mentioned packagespub.dev/packages/shelf: A model for web server middleware that encourages composition and easy reusepub.dev/packages/functions_framework: FaaS (Function as a service) framework for writing portable Dart functionspub.dev/packages/shelf_router: A convenient request router for the shelf web framework, with support for URL parameters, nested routers, and routers generated from source annotationspub.dev/packages/args: Library for defining parsers for parsing raw command-line arguments into a set of options and values using GNU and POSIX style optionspub.dev/packages/build_cli: Parse command-line arguments directly into an annotation class using the power of build_runner and source_genpub.dev/packages/completion: A package to add shell command completion to your Dart applicationOther ResourcesPop, Pop, Win! + source code: demonstration app for the open-source Dart project from Google: an implementation of Minesweeper in DartThe Chromium ProjectsArs Technica: Google has released Dartium, a Chromium build with a Dart VM (2012)Fandom Google Wiki: Dartium: "Dartium is a modified version of Chromium that is designed to support the Dart language."Dart News and Updates: The new AdWords UI uses Dart - we asked why (2016)Good to Great: Why Some Companies Make the Leap... and Others Don't by Jim C. CollinsRack: a Ruby Webserver InterfaceAnnouncing Dart 2.13: (...) Official Docker support and Dart on Google CloudDockerDocker Official ImagesDart Docker Official ImagesKubernetes - Production-grade container orchestrationDart Docs - Google Cloud (Cloud Run, Functions, Kubernetes, Compute Engine, App Engine)Announcing Dart support for GitHub ActionsIt's All Widgets! hosted by Hillel Coren: Kevin MooreYouTube Kevin Moore: Code generation with the Dart build systemYouTube Google IO Q&A: Cloud, Dart, and full-stack Flutter