Podcasts about Clojure

Episode Notes In this engaging episode of the JUXT Cast, Jeremy Taylor and Malcolm Sparks sit down with Ryan Robitaille, the founder of Rabbit, https://github.com/ryrobes/rvbbit. Ryan shares his unique journey—from working with Oracle systems as a young Solutions Engineer to becoming a creative force in the world of data visualization. Ryan explores his experience building Rabbit, a tool designed to bridge the gap between proprietary BI tools and custom-built engineering solutions. Frustrated by the limitations of traditional tools like Tableau, Ryan envisioned a platform that offers the "best of both worlds": the simplicity of drag-and-drop dashboards with the power and flexibility of live coding and version control. Key Takeaways from the Episode: The Origins of Rabbit: How Ryan's passion for combining artistry and data engineering sparked the creation of a platform that feels like a "game engine for data." Balancing Build vs. Buy: Insights into the perpetual organizational dilemma of purchasing BI tools versus building in-house solutions. Clojure's Role: How Clojure and its philosophy of "code is data" played a pivotal role in Rabbit's architecture and flexibility. The Tableau Experience: Ryan reflects on Tableau's transformative early days and where the tool has hit its limits. Empowering End-Users: Why Ryan believes tools should offer a low bar for entry but a high ceiling for complexity. With fascinating anecdotes and deep technical insights, this episode sheds light on how data platforms can evolve to empower creativity, transparency, and collaboration.

Episode Notes This latest episode of the JUXTCast features Gene Kim, a Wall Street Journal bestselling author, celebrated researcher, and multiple award-winning Chief Technology Officer. Gene is widely recognized for his contributions to the DevOps movement and for co-authoring influential works such as The Phoenix Project and The DevOps Handbook. In this engaging discussion, Gene reflects on his career journey, from his time as the founder and CTO of Tripwire to his rediscovery of the joy of programming through Clojure. The episode explores key themes including high-performing technology organizations, the transformative role of AI in programming, and the strategic importance of modularity in systems design. The conversation also offers unique insights into the evolving role of AI in augmenting developer productivity and creativity. Gene shares his hands-on experience with pair programming and discusses the intersection of REPL-based programming, economic principles in software design, and the future of junior developers in an AI-enhanced ecosystem. Thoughts on a “DORA for GenAI and developers” study: https://x.com/RealGeneKim/status/1856146004724330862  2 hour pair programming with Steve Yegge! https://twitter.com/RealGeneKim/status/1860507119096869363 Description of what I did while walking dog: https://twitter.com/RealGeneKim/status/1853860996689064211  “From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code,” https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html?m=1 XTDB: https://docs.xtdb.com/quickstart/sql-overview.html

Alex Miller on GitHub - https://github.com/puredanger Clojure 1.12 - https://clojure.org/news/2024/09/05/clojure-1-12-0 Clojure Conj 20% ticket discount - https://ti.to/nubank/clojureconj-2024/discount/CLOJURESTREAM FREE Clojure Conj ticket - create an issue on https://github.com/clojurestream/podcast and propose a podcast episode. Out of the proposed podcast one person will be chosen and awarded ticket to 2024 Clojure Conj.

Episode Notes In this episode, JUXT's CEO Jon Pither, CTO Malcolm Sparks, and Head of Delivery Joe Littlejohn, are joined by guest Software Engineer Jake Howard to engage in a thoughtful discussion on the enduring static vs dynamic typing debate. While static typing has long been a staple in programming, the conversation leans toward the growing appeal of dynamic typing in modern software practices. The team explores how dynamic typing allows for quicker iteration, greater flexibility, and better adaptation to shifting project demands. They also take time to weigh the structure and reliability that static typing provides, making for a balanced look at both approaches.

This is a recap of the top 10 posts on Hacker News on September 5th, 2024.This podcast was generated by wondercraft.ai(00:38): UE5 Nanite in WebGPUOriginal post: https://news.ycombinator.com/item?id=41458987&utm_source=wondercraft_ai(01:56): AlphaProteo generates novel proteins for biology and health researchOriginal post: https://news.ycombinator.com/item?id=41457331&utm_source=wondercraft_ai(03:09): Porting systemd to musl Libc-powered LinuxOriginal post: https://news.ycombinator.com/item?id=41454779&utm_source=wondercraft_ai(04:22): Clojure 1.12.0 is now availableOriginal post: https://news.ycombinator.com/item?id=41460037&utm_source=wondercraft_ai(05:28): Building a WoW (World of Warcraft) Server in ElixirOriginal post: https://news.ycombinator.com/item?id=41454741&utm_source=wondercraft_ai(06:46): Common food dye found to make skin and muscle temporarily transparentOriginal post: https://news.ycombinator.com/item?id=41459865&utm_source=wondercraft_ai(07:53): The Early Days of Valve from a Woman InsideOriginal post: https://news.ycombinator.com/item?id=41460276&utm_source=wondercraft_ai(08:59): Desed: Demystify and debug your sed scriptsOriginal post: https://news.ycombinator.com/item?id=41453557&utm_source=wondercraft_ai(10:11): Deploying Rust in Existing Firmware CodebasesOriginal post: https://news.ycombinator.com/item?id=41458508&utm_source=wondercraft_ai(11:26): serverless-registry: A Docker registry backed by Workers and R2Original post: https://news.ycombinator.com/item?id=41458240&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

Episode Notes Our guest is Niall Murphy, CEO of Stanza - a company founded by a group of experienced SREs with a vision to provide the tools, coding platform, culture and community to give any organization industry-leading reliability. Niall previously worked at Google where he co-authored the book "Site Reliability Engineering: How Google Runs Production Systems" (2016). In this podcast episode, we discussed Niall's extensive experience including his role within an important era for Google's infrastructure transformation beginning in the late 2000s, and the wider contemporary challenges in the SRE landscape. Niall's reflections on operating distributed systems has lead him to the conclusion that there is still a profound missing gap in SRE tooling between discovering 'signals' and taking 'actions'. The conversation begins by alluding to a couple of other recent podcasts we've recorded on distributed systems in 2024, one with Mark Burgess and the other with András Gerlits. Happy listening!

Lords: * Erica * Casey Topics: * Isn't it great to have a coelom? * Solving problems by waiting for another bigger problem to occur and override the previous problem * Mammals learning to eat cephalopods * https://crookedtimber.org/2024/03/16/occasional-paper-when-armor-met-lips/ * A Narrow Fellow in the Grass, by Emily Dickinson * https://www.poetryoutloud.org/poem/a-narrow-fellow-in-the-grass-1096/ * Personal project retrospectives Microtopics: * That thing you just heard. * Assigning your new hire an office. * Plugging over a million leaking gas and oil wells in West Texas. * The Topic Lords Promise. * A bag that your organs sit in. * Undifferentiated tissues. * How dissecting an earthworm is different from dissecting a gummy worm. * Inflating your coelom in order to take out your spleen. * Organisms with high diseectability. * The anti-coelom lobby. * Undifferentiated tubes of goo that get depression. * The gummy worm future we're all looking forward to. * Fluid things going on in the organism. * A car that has a huge dent in it and it doesn't matter because the car still gets around no problem. * Good car ideas. * A bad thing happening but it's not your fault. * Buying your house in a point and clock adventure online. * Rediscovering all the things you have stored at your parent's house. * Multi-episode Topic Lords story arcs. * Which colored stripes are on Wikipedia's Non-Notable Flag. * The Topic Lords explainer episode where everyone finds out what this show is about. * Serial Podcast Monogamy. * Podcast guilt. * Discussing all the same topics as the last episode with no self-awareness. * Non-Stop Coelom Celebration. * My own very special walking bag of guts. * Evolving cheek muscles to suck meat out of a spiral shell. * Losing your baby lips. * What it's like to eat a planarian. * Cephalopods that have evolved to eat mammals. * The giant squid that have never been seen alive. * The colossal squid vs. the giant squid. * Finding a mobius strip solution so borh your flag and your neighbor'a flag can be biggest. * Our flag that represents limpness will be your downfall. * Non-stop sensationalized documentaries about North Korea. * Opening the border to North Korea so we can finally interview the people about the colossal squid. * Emily Dickinson slipping into Yoda Speak. * Being too busy reading to understand what you're reading. * Whether the Emily Dickinson poem about the snake is actually about a snake or about a dick or both. * It's coming at your feet! It likes a boggy acre! * A polysexual attitude towards nature. * Emily Dickinson making thousands of attempts to fix the Gilligan's Island theme. * Herman Melville describing Moby Dick as "the Ebon Whale" because he didn't have Wikipedia. * Moby Dick annotated by biologists who explain why all the whale facts are wrong. * Game Developers doing a "post-mortem" of projects that are ongoing. * Befunge. * Clojure and other Lisps. * Watching your own programming livestreams to learn how to learn better. * A huge block of text off to the side that tells you how to play the game. * Fine-grained tactical mistakes. * Why people keep telling game developers to learn to ship a game. * The most significant barrier between you and putting a work of art out in the world. * Inventing metrics for success for game engines that never ship. * Rewriting your game engine to have cooler tech but be way harder to make levels for. * Modern Jim-Style Content. * Artists trash talking their own work while they're showing it to you. * A sign on your forehead reading "ask me about my severely negative feedback." * The George W. Bush childhood home. * A community built on everyone's shared desire to leave. * The ethic of owning a shotgun. * The last of the Midland Odessa complaining. * Big Bend and Carlsbad Caverns. * An airport full of ads for oil wells and oil well accessories. * The Chris Kyle American Sniper Memorial. * A plaque on a sculpture explaining whether the flag represents a penis. * Everything's a dick if you squint hard enough. * An assassin of federal judges.

Neste programa, exploramos as profundezas de Clojure e do Language Server Protocol (LSP) com a participação de Eric Dallo. Discutimos como essas tecnologias estão redefinindo o desenvolvimento de software, tornando o processo mais eficiente e adaptável. Este episódio é destinado a desenvolvedores que desejam aprimorar suas habilidades técnicas e líderes empresariais interessados em integrar soluções avançadas em suas operações empresariais. Assuntos abordados no tema Introdução ao Clojure (Linguagem de Programação Funcional) Benefícios em utilizar o Clojure e a diferença com outras linguagens O que é LSP (Language Server Protocol)? Definição de LSP e discussão sobre como ele padroniza a comunicação entre editores de código e servidores de linguagem Como Clojure e LSP trabalham juntos para proporcionar uma experiência de desenvolvimento otimizada. Exemplos práticos de configurações e integrações. Revisão das principais ferramentas e extensões que melhoram o uso de Clojure e LSP. Impacto dessas ferramentas na produtividade do desenvolvedor. Dicas para aqueles que desejam começar ou melhorar seu uso dessas tecnologias. Mercado de Trabalho   Links úteis Participe da nossa comunidade no Discord: https://discord.com/invite/hGpFPsV2gB Pesquisa de satisfação Café Debug 2024  https://docs.google.com/forms/d/e/1FAIpQLSdlkPGS-sqfD3QOmkddRDqj7dlYE8mpIlZXORIfTtn-MztKKA/viewform https://github.com/clojure-lsp/clojure-lsp https://clojure-lsp.io/clients/ https://clojure.org/ https://alefeans.medium.com/por-que-clojure-82b47ea4774c https://www.gta.ufrj.br/grad/09_1/versao-final/mpls/LSP.html https://github.com/nubank/state-flow https://mishadoff.com/blog/clojure-design-patterns/ Participantes Jéssica Nathany Software Developer  e  host)LinkedIn: https://www.linkedin.com/in/jessica-nathany-carvalho-freitas-38260868/Weslley Fratini (Software Developer e co-host)LinkedIn: https://www.linkedin.com/in/weslley-fratini/ Eric Dallo (apelido Greg) - Software Developer)LinkedIn: https://www.linkedin.com/in/ericdalloGithub: https://github.com/ericdallo Anuncie em nosso site: http://www.cafedebug.com.brProdutora AGO Filmes: https://thiagocarvalhofotografia.wordpress.com/ publicidade envie para: debugcafe@gmail.comSee omnystudio.com/listener for privacy information.

Show Notes:

Episode Notes In this podcast episode, JUXT CTO Malcolm Sparks, JUXT Head of Delivery Joe Littlejohn, and XTDB Head of Product Jeremy Taylor spoke with guest Mark Burgess, an independent researcher and writer. Formerly a professor at Oslo University College in Norway and the creator of the CFEngine software and company, Mark was invited to write the foreward (https://sre.google/sre-book/foreword/) to Google's 2016 book: "Site Reliability Engineering - How Google runs production systems". They discuss Mark's journey to developing Promise Theory and explored techniques to 'scale simplicity' in the creation of large, reliable systems. One common (yet false) assumption is that all components of a system can be trusted to be 100% reliable. This misconception can lead to costly workarounds in production. They touch on the 'congruence' debate, considering whether and to what extent we should be concerned with the inherent inefficiencies in 'the automated building of things from scratch.' They also discuss the counter-intuitive observation that digital systems are far more complex and less resilient than analog systems, and how this may be due to the absence of an error-correcting mechanism in digital systems to maintain equilibrium. Please let us know if you have any points to add or if you were inspired by any part of the discussion. Happy listening!

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 Notes Our guest is András Gerlits, founder of OmniLedger - a technology for simplifying distributed consistency across systems. In this episode we discussed the various interpretations of the idea of ‘consistency' in software and technology more generally. András has been developing OmniLedger for several years and has written about the many problems it attempts to solve on his blog. These problems include the basic challenges of database scaling, the issues that typically arise through the adoption of microservices, and the pitfalls of distributing transactions. Since recording this episode, András has published a walkthrough of what ‘Observer-Centric Consistency' looks like, by applying OmniLedger across a single database namespace that is transparently replicated across two federated instances of a Sprint Boot ‘Petclinic' demo application. The code (configuration) for that walkthrough can be found here: https://github.com/omniledger/spring-petclinic At the end of the recording we mentioned the XT24 conference that took place in May - you can see a write up of that here. Please sign up to our newsletter in the footer of this page to be first to hear about our future conferences.

The conversation covers topics such as the rebranding of Clojure Camp, Arne's hometown, his travels around the world, his love for tea, the differences between Europe and the United States, and his interests in cooking and gardening. Jordan and Arne discuss their shared interest in circus arts, specifically juggling and flow state. They talk about the European Juggling Convention and the meditative and mental benefits of juggling. They also delve into the topic of Taoism and its influence on their lives, discussing the philosophy of going with the flow and finding natural ways of being. They touch on the importance of self-awareness, mindfulness, and the potential pitfalls of narcissistic spirituality. They also explore the similarities and differences between teaching and leadership, emphasizing the importance of empathy and vulnerability in both roles. Heart of Clojure is a community conference that aims to create a holistic and vibrant experience for software engineers. The conference focuses on deepening the understanding of working in the software industry and building software for the world. It draws inspiration from conferences like Strange Loop and the European Juggling Convention, incorporating activities, workshops, and interactive sessions alongside keynote talks. The organizers aim to create an intimate and inclusive atmosphere where attendees can come alive and explore different aspects of their identity beyond being software engineers. Heart of Clojure encourages open source contributors and maintainers to propose interactive sessions, workshops, and contributor onboarding activities. The conference will take place on September 18-19, 2024, in Leuven, Belgium. Links: Arne - https://github.com/plexus Heart of Clojure - https://2024.heartofclojure.eu/ Overtone - https://github.com/overtone/overtone Keywords: Arne, Belgium, Lambda Island, , Clojure Camp, gaiwan, travels, tea, Europe, United States, cooking, gardening, circus arts, juggling, flow state, European Juggling Convention, Taoism, self-awareness, mindfulness, narcissistic spirituality, teaching, leadership, empathy, vulnerability, Heart of Clojure, community conference, holistic experience, software industry, software engineers, activities, workshops, interactive sessions, keynote talks, open source contributors, contributor onboarding, Leuven, Belgium.

SEASON 3 LETZ GO! Thank you to sponsors: Clojurists Together, Nubank, Zane Shelby, Dustin Getz, Robert Randolph and superuser Hey Friends! We're back! email `heylilpodcast@gmail.com` if so inclined or you'd like to suggest a guest for this season. Summary: Hang out with me and my buddy David Nolen. We learn about his background in film and music, his interest in interactive media, and his journey into programming. We learn how and why he creates a musical environment at home. Plus the story on discovering Clojure and ClojureScript.He shares the challenges of maintaining an open-source project and we reflect on the masochistic nature of software development and the importance of experience in making pragmatic decisions. He expresses pride in his open source work and emphasizes the value of simplicity in tooling. The conversation concludes with a discussion on the balance between providing hand-holding and catering to experienced users. Keywords: film, music, interactive media, programming, performance, improvisation, teaching music, Clojure, ClojureScript, new media, Lisp, Clojure, ClojureScript, open-source, software development, experience, pragmatism, simplicity, tooling Produced by: L. Jordan Miller Intro & Outro track: "CrabbyPatties" by L. Jordan Miller

Mark Wardle, Chief Clinical Information Officer, and Vaughn Vernon discuss the intersection of healthcare and technology. Mark emphasizes the need for technology to improve patient care and the challenges of integrating digital systems in healthcare.Mark also highlights the importance of Domain-Driven Design in healthcare, as it allows for a more patient-centered approach and better communication between clinicians and patients. He discusses the limitations of current electronic health records and the need for tools that support continuity of care. Mark believes that technology should be used to enhance the human connection in healthcare and improve patient outcomes.Mark discusses the application of Domain-Driven Design (DDD) in healthcare and its potential to address the complexity and challenges in the industry. He emphasizes the need to break down healthcare systems into modular components and build them based on a shared understanding of the domain. Wardle highlights the importance of technical standards, interoperability, and the use of common models to decouple systems and improve integration. He also discusses the role of open source in healthcare and the potential for disruptive innovation. Wardle envisions a future where technology enables faster iteration, better orchestration of clinical pathways, and improved decision-making in healthcare.TakeawaysTechnology has the potential to greatly improve patient care in healthcare.DDD is crucial in healthcare to create a patient-centered approach and improve communication between clinicians and patients.Current electronic health records are often not user-friendly and do not support continuity of care.Technology should be used to enhance the human connection in healthcare and improve patient outcomes. Domain-Driven Design can help address the complexity and challenges in healthcare by breaking down systems into modular components and building them based on a shared understanding of the domain.Technical standards and interoperability are crucial for decoupling systems and improving integration in healthcare.Open source has the potential to disrupt the healthcare industry by providing foundational building blocks and higher-value tools.Improving orchestration of clinical pathways and decision-making in healthcare can be achieved through the use of technology and data-driven approaches.Faster iteration, better integration, and improved decision-making can lead to a learning health and care system that continuously improves patient outcomes.Mark WardleMark is a Consultant Neurologist and Chief Clinical Information Officer in the UK. He is also a keen software developer, building a range of clinician and patient-facing applications, most recently preferring to work in Clojure and ClojureScript. He thinks digital technologies should play a fundamental role in improving and transforming health and care with Domain-Driven Design playing a key role in unbundling the electronic patient record, and turning what we think of as health applications inside-out. Hosted on Acast. See acast.com/privacy for more information.

This interview was recorded at GOTO Copenhagen for GOTO Unscripted.http://gotopia.techRead the full transcription of this interview hereRichard Feldman - Functional Programming Language Expert, Author of "Elm in Action" & Creator for the Roc Programming LanguageJames Lewis - Principal Consultant & Technical Director at ThoughtworksRESOURCESRichardhttps://twitter.com/rtfeldmanhttps://linkedin.com/in/rtfeldmanhttps://github.com/rtfeldmanhttps://www.roc-lang.orghttps://twitter.com/sw_unscriptedJameshttps://twitter.com/boicyhttps://linkedin.com/in/james-lewis-microserviceshttps://www.thoughtworks.com/radarDESCRIPTIONJoin Richard Feldman and James Lewis as they unpack a new programming language and what it brings to the ecosystem. They navigate through the nuances of language selection, exploring the sweet spot between fun and standardization. From Elm's role in front-end development to Scala's adoption patterns and Dart's transformation into Flutter, the discussion takes you on a journey across diverse programming landscapes.Discover the ins and outs of Roc, a fresh face in the coding scene, and the driving force behind its creation. Learn about its architecture, design principles, and standout features, including parsing strategies and a candid comparison with other languages. Explore the excitement around Roc's innovative traits and its knack for performance optimization, unveiling its potential in the dynamic world of functional programming.RECOMMENDED BOOKSRichard Feldman • Elm in ActionTim McNamara • Rust in ActionCristian Salcescu • Functional Programming in JavaScriptYehonathan Sharvit • The Clojure WorkshopTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Episode Notes Our guest is Prof. Viktor Leis, a Full Professor in the Computer Science Department at the Technical University of Munich. His research revolves around designing high-performance data management systems and includes core database systems topics such as query processing, query optimization, transaction processing, index structures, and storage. [0] In this episode we discussed a paper that Viktor recently co-authored with Thomas Neumann, titled "A Critique of Modern SQL And A Proposal Towards A Simple and Expressive Query Language", for CIDR 2024. [2] Beyond the specifics of SQL, many other topics are touched on also including: machine learning in the database, a critique of PostgreSQL, and the potential for massive performance gains in the world of practical database systems. Notes: [0] https://www.cs.cit.tum.de/dis/team/prof-dr-viktor-leis/ [1] https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf [2] https://github.com/neumannt/saneql/ [3] https://www.cs.cit.tum.de/dis/research/leanstore/ [4] https://www.dbos.dev/blog/announcing-dbos

Episode Notes Beyond the headlines, this JUXTCast episode exposes the intricate challenges in managing and securing complex IT systems, providing a more detailed understanding of the Horizon scandal, and hopefully serving as a straightforward reminder for individuals and organizations to stay vigilant and proactive in ensuring the reliability and integrity of the technology that we use and trust. The JUXT team — Malcolm Sparks (CTO), Joe Littlejohn (Head of Delivery) and Alex Davis (Senior Software Engineer) — were joined by Andras Gerlits, adding an important perspective to the conversation: Andras Gerlits' work: http://omniledger.io/ Andras Gerlits' blog: https://andrasgerlits.medium.com For more insights on this episode, please check out Malcolm's post: https://www.juxt.pro/blog/juxtcast-horizon/

This week's guest describes Event Sourcing as, “all I'm going to use for the rest of my career.” But what is Event Sourcing? How should we think about it, and how does it encourage us to think about writing software?In this episode we take a close look at systems designed around the idea of Events, with guest Bobby Calderwood. Bobby's been designing (and helping others design) event based architectures for many years, and enthusiastically recommends it not only as a system-design technique, but as a way of solving business problems faster and more reliably.During this discussion we look at the various ways of defining event systems, what tools we need to implement them, and the advantages of thinking about software from an event-based perspective. Along the way we discuss everything from Clojure, Bitemporality & Datomic to Kafka and more traditional databases - all in the service of capturing real-world events and building simple systems around them.–EventStoreDB: https://developers.eventstore.com/The CloudEvents standard: https://cloudevents.io/Datomic: https://www.datomic.com/Adam Dymitruk's Event Modelling Explanation: https://eventmodeling.org/Bobby's Event Modelling course: https://developer.confluent.io/courses/event-modeling/intro/Bobby on Twitter: https://twitter.com/bobbycalderwoodBoddy on LinkedIn: https://www.linkedin.com/in/bobbycalderwood/Kris on Twitter: https://twitter.com/krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/–#software #softwarepodcast #programming #eventsourcing #eventdrivenarchitecture #kafka

This interview was recorded for the GOTO Book Club.gotopia.tech/bookclubRead the full transcription of the interview hereYehonathan Sharvit - Author of Data-Oriented programmingJames Lewis - Principal Consultant & Technical Director at ThoughtworksRESOURCESGet 35% discount on all Manning products with code: *ytGOTO35*Yehonathantwitter.com/viebelgithub.com/viebellinkedin.com/in/viebelblog.klipse.techJamestwitter.com/boicylinkedin.com/in/james-lewis-microservicesDESCRIPTIONUnlock the power of data-oriented programming with this groundbreaking guide ‘Data-Oriented Programming: Reduce software complexity‘, introducing a paradigm that revolutionizes software design by representing data through generic immutable structures. DOP simplifies state management, streamlines concurrency and eradicates common issues in object-oriented code, all while offering language-agnostic flexibility. In this GOTO Book Club episode, author Yehonathan Sharvit spoke to James Lewis about how you can change the way you look at programming where code is clearer, state-related bugs are history, and your applications are more robust.This conversation-driven book is complete with code snippets and diagrams about DOP and the best part—it's not bound to a single programming language, making it adaptable to JavaScript, Ruby, Python, Clojure and traditional languages like Java or C#. Learn to design data models for business entities and implement state management systems without mutating data. Discover how to separate code from data, write data-oriented unit tests, and specify the shape of your data, all while gaining a deeper understanding of these exciting new concepts.The interview is based on the book "Data-Oriented Programming"RECOMMENDED BOOKSYehonathan Sharvit • Data-Oriented ProgrammingYehonathan Sharvit • The Clojure WorkshopZhamak Dehghani • Data MeshEberhard Wolff & Hanna Prinz • Service MeshPiethein Strengholt • Data Management at ScaleMartin Kleppmann • Designing Data-Intensive ApplicationsTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

In this episode of Elixir Wizards, Xiang Ji and Nathan Hessler join hosts Sundi Myint and Owen Bickford to compare actor model implementation in Elixir, Ruby, and Clojure. In Elixir, the actor model is core to how the BEAM VM works, with lightweight processes communicating asynchronously via message passing. GenServers provide a common abstraction for building actors, handling messages, and maintaining internal state. In Ruby, the actor model is represented through Ractors, which currently map to OS threads. They discuss what we can learn by comparing models, understanding tradeoffs between VMs, languages, and concurrency primitives, and how this knowledge can help us choose the best tools for a project. Topics discussed in this episode: Difference between actor model and shared memory concurrency Isolation of actor state and communication via message passing BEAM VM design for high concurrency via lightweight processes GenServers as common abstraction for building stateful actors GenServer callbacks for message handling and state updates Agents as similar process abstraction to GenServers Shared state utilities like ETS for inter-process communication Global Interpreter Lock in older Ruby VMs Ractors as initial actor implementation in Ruby mapping to threads Planned improvements to Ruby concurrency in 3.3 Akka implementation of actor model on JVM using thread scheduling Limitations of shared memory concurrency on JVM Project Loom bringing lightweight processes to JVM Building GenServer behavior in Ruby using metaprogramming CSP model of communication using channels in Clojure Differences between BEAM scheduler and thread-based VMs Comparing Elixir to academic languages like Haskell Remote and theScore are hiring! Links mentioned in this episode: theScore is hiring! https://www.thescore.com/ Remote is also hiring! https://remote.com/ Comparing the Actor Model and CSP with Elixir and Clojure (https://xiangji.me/2023/12/18/comparing-the-actor-model-and-csp-with-elixir-and-clojure/) Blog Post by Xiang Ji Comparing the Actor model & CSP concurrency with Elixir & Clojure (https://www.youtube.com/watch?v=lIQCQKPRNCI) Xiang Ji at ElixirConf EU 2022 Clojure Programming Language https://clojure.org/ Akka https://akka.io/ Go Programming Language https://github.com/golang/go Proto Actor for Golang https://proto.actor/ RabbitMQ Open-Source Message Broker Software  https://github.com/rabbitmq JVM Project Loom https://github.com/openjdk/loom Ractor for Ruby  https://docs.ruby-lang.org/en/master/ractor_md.html Seven Concurrency Models in Seven Weeks: When Threads Unravel (https://pragprog.com/titles/pb7con/seven-concurrency-models-in-seven-weeks/)by Paul Butcher Seven Languages in Seven Weeks (https://pragprog.com/titles/btlang/seven-languages-in-seven-weeks/) by Bruce A. Tate GenServer https://hexdocs.pm/elixir/1.12/GenServer.html ets https://www.erlang.org/doc/man/ets.html Elixir in Action (https://pragprog.com/titles/btlang/seven-languages-in-seven-weeks/) by Saša Jurić Redis https://github.com/redis/redis Designing for Scalability with Erlang/OTP (https://www.oreilly.com/library/view/designing-for-scalability/9781449361556/) by Francesco Cesarini & Steve Vinoski Discord Blog: Using Rust to Scale Elixir for 11 Million Concurrent Users (https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users) Xiang's website https://xiangji.me/ Feeling Good: The New Mood Therapy (https://www.thriftbooks.com/w/feeling-good-the-new-mood-therapy-by-david-d-burns/250046/?resultid=7691fb71-d8f9-4435-a7a3-db3441d2272b#edition=2377541&idiq=3913925) by David D. Burns Special Guests: Nathan Hessler and Xiang Ji.

Venture into the rich tapestry of professional programmer history with the prolific Uncle Bob Martin on this episode of the Mob Mentality Show.

We reflect on Clojure, the community, and how much we have to be thankful for.

Episode Notes In October 2023, Nathan Marz announced the Clojure API to Rama, a new programming platform for building distributed applications that was released last August. Red Planet Labs revealed Rama for the first time by building and operating a Twitter-scale Mastodon instance that's 100x less code than Twitter wrote to build the equivalent. Soon after this announcement, we invited Nathan as a guest on the JUXTCast to find out more. In this episode, we delve into some of the conceptual foundations of Rama, the influence the Clojure language has had on its design and discuss some of the many difficult problems Nathan and his team have had to solve in the course of developing Rama. Not to be missed! For more information about Rama and it's Clojure API, you can read this post on Red Planet Labs blog: "Introducing Rama's Clojure API: build end-to-end scalable backends in 100x less code".

Richard talks with Nikita Prokopov, an open-source Clojure developer and creator of the Fira Code typeface, about some of the reasons he'd felt a sense of disenchantment with the direction of software in the past, and strategies he's developed for improving things in the future.

Episode Notes In this episode, JUXT Head of Delivery, Joe Littlejohn, is joined by JUXT software engineers Aaron Knauf and Mariusz Saternus to talk Platform Engineering, and their experiences delivering effective developer platforms in large tech organisations. Link to Jeremy Taylor's webinar "Bitemporality and the Art of Maintaining Accurate Databases" — as mentioned by Joe at the top of the episode. This podcast is powered by Pinecast.

Kit Workshop - https://clojure.stream/workshops/kit Dimitri on Twitter - twitter.com/yogthos Dimitri on GitHub - github.com/yogthos Dimitri on 500px - 500px.com/p/dmitrisotnikov Dimitri's website - yogthos.net Kit on GitHub - https://github.com/kit-clj/kit Kit's website - https://kit-clj.github.io/ Clojure courses, workshops, and more ... https://clojure.stream/

We compose our thoughts on why Clojure expressiveness is so effective but can be so hard to learn.

Non-tech Music Banter An Updated Look At Concert Merchandise Sales & Trends in 2022 Why Venues Take Merch Cuts The Taylor Swift Economy: The largest music tour in history is a hospitality phenomenon A litany of languages and their passing, software archaeology and the issues of adopting new languages? Clojure - (next Rich) JDK 21 to be released next month: JDK 21 Release Candidates & JVM Language Summit has a good overview. JEP 430: String Templates (Preview) Not a fan of the syntax, but also appreciate it's not just "string interpolation", it makes it very clear you're doing something different. I like that it's easily expandable and not too different from other languages that use r"Raw String here". NOTE: String Template Processing is runtime, not compile time, as Mark was thinking, as with being able to work well with Freemarker templates – which may work, but not as I implied. JEP 431: Sequenced Collections look like a nice improvement for consistency – annoying for library writers who may find it more useful, tho. Mark: 440: Record Patterns and 441: Pattern Matching for switch – having used these a bit now I love them, in places they fit – they work well for Algebraic Data Type style things, but should be used in moderation tho. JEP 443: Unnamed Patterns and Variables (Preview) It's a small win, but not having to name things “ignore” or “expected” etc. JEP 445: Unnamed Classes and Instance Main Methods (Preview) Initially didn't think I'd find much interest in this, but the more I experiment with Dagger.IO pipelines, and with the forthcoming Java SDK I can see this being enjoyable. JBang as an alternative JEP draft: Prepare to Restrict The Use of JNI - JDK 22 to start warning on JNI usage…  The Reddit thread is well - as you expect :) JEP draft: Prepare to Restrict The Use of JNI (Updated): r/java Flame threads on the JNI command flag option. Quick Fire Last Minute things: Dagger, a ❤️  story | Flipt Blog Tutorial · arxanas/git-branchless Wiki · GitHub BONUS Material Apache Wicket PatternFly Elements - PatternFly Elements

Episode Notes In this episode, Jeremy Taylor, James Henderson, and Malcolm Sparks are joined by Kent Beck to discuss programming, bitemporality, and the state of Agile. For more insights, please visit this post about the podcast.

Episode Notes 'The Holy War' song: https://www.youtube.com/watch?v=1kcOfWSDEjg 'A first look at the XT20 venue': https://www.youtube.com/watch?v=0Xt4PsvZO8w Banking Transformation Summit: https://bankingtransformationsummit.com/ Babashka Conf: https://babashka.org/conf/ Babashka Talks 2023: https://www.youtube.com/playlist?list=PLaN-rC-CjQqDu1AVhGdGOoEqsSAhd2W6t XTDB: https://www.xtdb.com/ JUXT 10-Year Anniversary Talks: https://www.youtube.com/playlist?list=PLrCB9bq0iVIpI2Tz7F0gZM5PDigchRFXF

Episode Notes This podcast episode focuses on some topics that are mentioned in S5E1 "Post-Conj Roundup, Databases, and the LLM era": https://pinecast.com/listen/dc20b264-48cd-4f84-8291-d60dfc4801ab.mp3.

Bailey & Jesse chat with Horace Williams, a member of the first proto-Turing program called Hungry Academy in 2012. Horace was one of the first instructors at Turing and is a current Staff Software Engineer at Medallion. The discuss the early days of code schools and Turing, Horace's work on political campaigns, Clojure, Ann Arbor, and other topics. If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a free Try Coding class at turing.edu/try-coding.

As a developer, it's crucial to understand the various types of databases available so you can choose the right tool for the job. In this episode, we're shining a spotlight on bitemporal databases with James Henderson, lead developer of of a new bitemporal database called XTDB.You may have already created an ad-hoc bitemporal database without realizing it, but James and his team have been hard at work building a custom database that's tailor-made for situations where having two notions of time are essential. Join us to learn about the what and why of bitemporality and explore the process of designing and building a database in Clojure.Ready to get started with XTDB? Visit https://www.xtdb.com/v2 to learn more.Want to get involved with the XTDB community? Head over to https://discuss.xtdb.com.Follow XTDB on Twitter at https://twitter.com/xtdb_com and Kris Jenkins at https://twitter.com/krisajenkins.Connect with Kris on LinkedIn at https://www.linkedin.com/in/krisjenkins/.

I give another reason why I don't encounter so many type errors in Clojure.

We try out the most secure messaging app in the world, and Wes' new note system that's so great you'll want to abandon your current one.

Out of the Tar Pit is in the grand pantheon of great papers, beloved the world over, with just so much influence. The resurgence of Functional Programming over the past decade owes its very existence to the Tar Pit's snarling takedown of mutable state, championed by Hickey & The Cloj-Co. Many a budding computational philosophizer — both of yours truly counted among them — have been led onward to the late great Bro86 by this paper's borrow of his essence and accident. But is the paper actually good? Like, really — is it that good? Does it hold up to the blinding light of hindsight that 2023 offers? Is this episode actually an April Fools joke, or is it a serious episode that Ivan just delayed by a few weeks because of life circumstances and his own incoherent sense of humour? I can't tell. Apologies in advance. Next time, we're going back to our usual format to discuss Intercal. Links Before anything else, we need to link to Simple Made Easy. If you don't know, now you know! It's a talk by Rich Hickey (creator of Clojure) that, as best as I can tell, widely popularized discussion of simplicity and complexity in programming, using Hickey's own definitions that built upon the Tar Pit paper. Ignited by this talk, with flames fanned by a few others, as functional programming flared in popularity through the 2010s, the words “simple”, “easy”, “complex”, and “reason about” became absolutely raging memes. We also frequently reference Fred Brooks and his No Silver Bullet. Our previous episode has you covered. The two great languages of the early internet era: Perl & TcL For more on Ivan's “BLTC paradise-engineering wombat chocolate”, see our episode on Augmenting Human Intellect, if you dare. For more on Jimmy's “Satoshi”, see Satoshi Nakamoto, of course. And for Anonymous, go on. Enemy of the State — This film slaps. “Some people prefer not to commingle the functional, lambda-calculus part of a language with the parts that do side effects. It seems they believe in the separation of Church and state.” — Guy Steele “my tempo” FoC Challenge: Brooks claimed 4 evils lay at the heart of programming — Complexity, Conformity, Changeability, and Invisibility. Could you design a programming that had a different set of four evils at the heart of it? (Bonus: one of which could encompass the others and become the ur-evil) The paper introduces something called Functional Relational Programming, abbreviated FRP. Note well, and do not be confused, that there is a much more important and common term that also abbreviates to FRP: Family Resource Program. Slightly less common, but yet more important and relevant to our interests as computer scientists, is the Fluorescence Recovery Protein in cyanobacteria. Less abundant, but again more relevant, is Fantasy Role-Playing, a technology with which we've all surely developed a high degree of expertise. For fans of international standards, see ISO 639-3 — the Franco-Provençal language, represented by language code frp. As we approach the finality of this paragraph, I'll crucially point out that “FRP”, when spoken aloud all at once at though it were a word, sounds quite like the word frp, which isn't actually a word — you've fallen right into my trap. Least importantly of all, and also most obscurely, and with only minor interest or relevance to listeners of the podcast and readers of this paragraph, we have the Functional Reactive Programming paradigm originally coined by Conor Oberst and then coopted by rapscallions who waste time down by the pier playing marbles. FoC Challenge: Can you come up with a programming where informal reasoning doesn't help? Where you are lost, you are without hope, and you need to get some kind of help other than reasoning to get through it? Linear B LinearB Intercal Esolangs FoC Challenge: Can you come up with a kind of testing where using a particular set of inputs does tell you something about the system/component when it is given a different set of inputs? It was not Epimenides who said “You can't dip your little toesies into the same stream” two times — presumably because he only said it once. Zig has a nicely explicit approach to memory allocation. FoC Challenge: A programming where more things are explicit — building on the example of Zig's explicit allocators. Non-ergonomic, Non-von Neumann, Nonagon Infinity One of Ivan's favourite musical acts of the 00s is the ever-shapeshifting Animal Collective — of course

Richard talks to Eric Normand about his experiences using both Haskell and Clojure in production, and his perspectives on comparing and contrasting the approaches of the two languages. Eric hosts a podcast (https://ericnormand.me/podcast) and you can use code podsoftunsc22 at checkout to get a discount on his book Grokking Simplicity: https://www.manning.com/books/grokking-simplicity

The key message begins with the observation that categories and concepts have central examples and fuzzy boundaries. The idea that categories are usefully defined by boolean-valued necessary and sufficient conditions is outdated. The stock example is the question: "Is the pope a bachelor?" The answer is, "Well, technically", but there are clearly more central examples that capture more of the concept's connotations. (See Lakoff's 1987 Women, Fire, and Dangerous Things: What Categories Reveal About the Mind. Gregory L. Murphy's 2004 The Big Book of Concepts is more exhaustive and covers different theories.)Examples teach you what lays within the (fuzzy) boundary. Counterexamples teach you what lays outside. You need both.Stories stimulate the kind of learning that happens from lived experience and social interaction. These claims are illustrated by the kind of examples, counterexamples, and stories that I think Etienne Wenger should have (but mostly did not) use in his 1998 Communities of Practice: Learning, Meaning, and Identity. The episode isn't a comprehensive – or perhaps even accurate – explanation of his theory. Because (I believe) of how the book was written, my understanding of the theory is shaky.I also drew on these writings: Wenger, Snyder, and McDermott, Cultivating Communities of Practice: A Guide to Managing Knowledge, 2002Cox, Andrew M., "What are communities of practice? A comparative review of four seminal works", 2005Etienne Wenger, "Communities of Practice and Social Learning Systems: the Career of a Concept", 2010I mentioned Tinderbox, a note-taking app, and Bike, an outliner.I mentioned my habit of writing books that include mistakes that are later corrected. As advertised, the first book I wrote this way is RubyCocoa: Bringing Some Ruby Love to OS X Programming. That's a book about dead technology, and is out of print. Perhaps the best example of this style was the unfinished An Outsider's Guide to Statically Typed Functional Programming, which is free. (The finished part is about Elm, which alas also seems dead.) Functional Programming for the Object-Oriented Programmer is an introduction to Clojure, uses something of the include-mistakes style, was pretty successful, but is old enough I've also made it free. The description of the apocryphal story of Saint Thecla is from the Apocrypals podcast. There's more than just man-eating seals.The science fiction story Año Nuevo is by Ray Naylor.----Picture of Magritte's "The Treachery of Images" via Flickr user darryl_mitchel,  under Creative Commons Attribution-ShareAlike 2.0 Generic license.

About GeneGene Kim is a multiple award-winning CTO, researcher and author, and has been studying high-performing technology organizations since 1999. He was founder and CTO of Tripwire for 13 years. He has written six books, including The Unicorn Project (2019), The Phoenix Project (2013), The DevOps Handbook (2016), the Shingo Publication Award winning Accelerate (2018), and The Visible Ops Handbook (2004-2006) series. Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations.Links: The Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ The Unicorn Project: https://www.amazon.com/Unicorn-Project-Developers-Disruption-Thriving/dp/B0812C82T9 The DevOps Enterprise Summit: https://events.itrevolution.com/ @RealGeneKim TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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: If you asked me to rank which cloud provider has the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud. Their developer experience is unparalleled and, in the early stages of building something great, that translates directly into velocity. Try it yourself with the Google for Startups Cloud Program over at cloud.google.com/startup. It'll give you up to $100k a year for each of the first two years in Google Cloud credits for companies that range from bootstrapped all the way on up to Series A. Go build something, and then tell me about it. My thanks to Google Cloud for sponsoring this ridiculous podcast.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out. Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by a man who needs no introduction but gets one anyway. Gene Kim, most famously known for writing The Phoenix Project, but now the Wall Street Journal best-selling author of The Unicorn Project, six years later. Gene, welcome to the show.Gene Kim: Corey so great to be on. I was just mentioning before how delightful it is to be on the other side of the podcast. And it's so much smaller in here than I had thought it would be.Corey Quinn: Excellent. It's always nice to wind up finally meeting people whose work was seminal and foundational. Once upon a time, when I was a young, angry Unix systems administrator—because it's not like there's a second type of Unix administrator—[laughing] The Phoenix Project was one of those texts that was transformational, as far as changing the way I tended to view a lot of what I was working on and gave a glimpse into what could have been a realistic outcome for the world, or the company I was at, but somehow was simultaneously uplifting and incredibly depressing all at the same time. Now, The Unicorn Project does that exact same thing only aimed at developers instead of traditional crusty ops folks.Gene Kim: [laughing] Yeah, yeah. Very much so. Yeah, The Phoenix Project was very much aimed at ops leadership. So, Bill Palmer, the protagonist of that book was the VP of Operations at Parts Unlimited, and the protagonist in The Unicorn Project is Maxine Chambers, Senior Architect, and Developer, and I love the fact that it's told in the same timeline as The Phoenix Project, and in the first scene, she is unfairly blamed for causing the payroll outage and is exiled to The Phoenix Project, where she recoils in existential horror and then finds that she can't do anything herself. She can't do a build, she can't run her own tests. She can't, God forbid, do her own deploys. And I just love the opening third of the book where it really does paint that tundra that many developers find themselves in where they're just caught in decades of built-up technical debt, unable to do even the simplest things independently, let alone be able to independently develop tests or create value for customers. So, it was fun, very much fun, to revisit the Parts Unlimited universe.Corey Quinn: What I found that was fun about—there are few things in there I want to unpack. The first is that it really was the, shall we say, retelling of the same story in, quote/unquote, “the same timeframe”, but these books were written six years apart.Gene Kim: Yeah, and by the way, I want to first acknowledge all the help that you gave me during the editing process. Some of your comments are just so spot on with exactly the feedback I needed at the time and led to the most significant lift to jam a whole bunch of changes in it right before it got turned over to production. Yeah, so The Phoenix Project is told, quote, “in the present day,” and in the same way, The Unicorn Project is also told—takes place in the present day. In fact, they even start, plus or minus, on the same day. And there is a little bit of suspension of disbelief needed, just because there are certain things that are in the common vernacular, very much in zeitgeist now, that weren't six years ago, like “digital disruption”, even things like Uber and Lyft that feature prominently in the book that were just never mentioned in The Phoenix Project, but yeah, I think it was the story very much told in the same vein as like Ender's Shadow, where it takes place in the same timeline, but from a different perspective.Corey Quinn: So, something else that—again, I understand it's an allegory, and trying to tell an allegorical story while also working it into the form of a fictional work is incredibly complicated. That's something that I don't think people can really appreciate until they've tried to do something like it. But I still found myself, at various times, reading through the book and wondering, asking myself questions that, I guess, say more about me than they do about anyone else. But it's, “Wow, she's at a company that is pretty much scapegoating her and blaming her for all of us. Why isn't she quitting? Why isn't she screaming at people? Why isn't she punching the boss right in their stupid, condescending face and storming out of the office?” And I'm wondering how much of that is my own challenges as far as how life goes, as well as how much of it is just there for, I guess, narrative devices. It needed to wind up being someone who would not storm out when push came to shove.Gene Kim: But yeah, I think she actually does the last of the third thing that you mentioned where she does slam the sheet of paper down and say, “Man, you said the outage is caused by a technical failure and a human error, and now you're telling me I'm the human error?” And just cannot believe that she's been put in that position. Yeah, so thanks to your feedback and the others, she actually does shop her resume around. And starts putting out feelers, because this is no longer feeling like the great place to work that attracted her, eight years prior. The reality is for most people, is that it's sometimes difficult to get a new job overnight, even if you want to. But I think that Maxine stays because she believes in the mission. She takes a great deal of pride of what she's created over the years, and I think like most great brands, they do create a sense of mission and there's a deep sense of the customers they serve. And, there's something very satisfying about the work to her. And yeah, I think she is very much, for a couple of weeks, very much always thinking about, she won't be here for long, one way or another, but by the time she stumbles into the rebellion, the crazy group of misfits, the ragtag bunch of misfits, who are trying to find better ways of working and willing to break whatever rules it takes to take over the very ancient powerful order, she falls in love with a group. She found a group of kindred spirits who very much, like her, believe that developer productivity is one of the most important things that we can do as an organization. So, by the time that she looks up with that group, I mean, I think she's all thoughts of leaving are gone.Corey Quinn: Right. And the idea of, if you stick around, you can theoretically change things for the better is extraordinarily compelling. The challenge I've seen is that as I navigate the world, I've met a number of very gifted employees who, frankly wind up demonstrating that same level of loyalty and same kind of loyalty to companies that are absolutely not worthy of them. So my question has always been, when do I stick around versus when do I leave? I'm very far on the bailout as early as humanly possible side of that spectrum. It's why I'm a great consultant but an absolutely terrible employee.Gene Kim: [laughing] Well, so we were honored to have you at the DevOps Enterprise Summit. And you've probably seen that The Unicorn Project book is really dedicated to the achievements of the DevOps Enterprise community. It's certainly inspired by and dedicated to their efforts. And I think what was so inspirational to me were all these courageous leaders who are—they know what the mission is. I mean, they viscerally understand what the mission is and understand that the ways of working aren't working so well and are doing whatever they can to create better ways of working that are safer, faster, and happier. And I think what is so magnificent about so many of their journeys is that their organization in response says, “Thank you. That's amazing. Can we put you in a position of even more authority that will allow you to even make a more material, more impactful contribution to the organization?” And so it's been my observation, having run the conference for, now, six years, going on seven years is that this is a population that is being out promoted—has been promoted at a rate far higher than the population at large. And so for me, that's just an incredible story of grit and determination. And so yeah, where does grit and determination becomes sort of blind loyalty? That's ultimately self-punishing? That's a deep question that I've never really studied. But I certainly do understand that there is a time when no amount of perseverance and grit will get from here to there, and that's a fact.Corey Quinn: I think that it's a really interesting narrative, just to see it, how it tends to evolve, but also, I guess, for lack of a better term, and please don't hold this against me, it seems in many ways to speak to a very academic perspective, and I don't mean that as an insult. Now, the real interesting question is why I would think, well—why would accusing someone of being academic ever be considered as an insult, but my academic career was fascinating. It feels like it aligns very well with The Five Ideals, which is something that you have been talking about significantly for a long time. And in an academic setting that seems to make sense, but I don't see it thought of or spoken of in the same way on the ground. So first, can you start off by giving us an intro to what The Five Ideals are, and I guess maybe disambiguate the theory from the practice?Gene Kim: Oh for sure, yeah. So The Five Ideals are— oh, let's go back one step. So The Phoenix Project had The Three Ways, which were the principles for which you can derive all the observed DevOps practices from and The Four Types of Work. And so in The Five Ideals I used the concept of The Five Ideals and they are—the first—Corey Quinn: And the next version of The Nine whatever you call them at that point, I'm sure. It's a geometric progression.Gene Kim: Right or actually, isn't it the pri—oh, no. four isn't, four isn't prime. Yeah, yeah, I don't know. So, The Five Ideals is a nice small number and it was just really meant to verbalize things that I thought were very important, things I just gravitate towards. One is Locality and Simplicity. And briefly, that's just, to what degree can teams do what they need to do independently without having to coordinate, communicate, prioritize, sequence, marshal, deconflict, with scores of other teams. The Second Ideal is what I think the outcomes are when you have that, which is Focus, Flow and Joy. And so, Dr. Mihaly Csikszentmihalyi, he describes flow as a state when we are so engrossed in the work we love that we lose track of time and even sense of self. And that's been very much my experience, coding ever since I learned Clojure, this functional programming language. Third Ideal is Improvement of Daily Work, which shows up in The Phoenix Project to say that improvement daily work is even more important than daily work itself. Fourth Ideal is Psychological Safety, which shows up in the State of DevOps Report, but showed up prominently in Google's Project Oxygen, and even in the Toyota production process where clearly it has to be—in order for someone to pull the andon cord that potentially stops the assembly line, you have to have an environment where it's psychologically safe to do so. And then Fifth Ideal is Customer Focus, really focus on core competencies that create enduring, durable business value that customers are willing to pay for, versus context, which is everything else. And yeah, to answer your question, Where did it come from? Why do I think it is important? Why do I focus on that? For me, it's really coming from the State of DevOps Report, that I did with Dr. Nicole Forsgren and Jez Humble. And so, beyond all the numbers and the metrics and the technical practices and the architectural practices and the cultural norms, for me, what that really tells the story of is of The Five Ideals, as to what one of them is very much a need for architecture that allows teams to work independently, having a higher predictor of even, continuous delivery. I love that. And that from the individual perspective, the ideal being, that allows us to focus on the work we want to do to help achieve the mission with a sense of flow and joy. And then really elevating the notion that greatness isn't free, we need to improve daily work, we have to make it psychologically safe to talk about problems. And then the last one really being, can we really unflinchingly look at the work we do on an everyday basis and ask, what the customers care about it? And if customers don't care about it, can we question whether that work really should be done or not. So that's where for me, it's really meant to speak to some more visceral emotions that were concretized and validated through the State of DevOps Report. But these notions I am just very attracted to.Corey Quinn: I like the idea of it. The question, of course, is always how to put these into daily practice. How do you take these from an idealized—well, let's not call it a textbook, but something very similar to that—and apply it to the I guess, uncontrolled chaos that is the day-to-day life of an awful lot of people in their daily jobs.Gene Kim: Yeah. Right. So, the protagonist is Maxine and her role in the story, in the beginning, is just to recognize what not great looks like. She's lived and created greatness for all of her career. And then she gets exiled to this terrible Phoenix project that chews up developers and spits them out and they leave these husks of people they used to be. And so, she's not doing a lot of problem-solving. Instead, it's this recoiling from the inability for people to do builds or do their own tests or be able to do work without having to open up 20 different tickets or not being able to do their own deploys. She just recoil from this spending five days watching people do code merges, and for me, I'm hoping that what this will do, and after people read the book, will see this all around them, hopefully, will have a similar kind of recoiling reaction where they say, “Oh my gosh, this is terrible. I should feel as bad about this as Maxine does, and then maybe even find my fellow rebels and see if we can create a pocket of greatness that can become like the sublimation event in Dr. Thomas Kuhn's book, The Structure of Scientific Revolutions.” Create that kernel of greatness, of which then greatness then finds itself surrounded by even more greatness.Corey Quinn: What I always found to be fascinating about your work is how you wind up tying so many different concepts together in ways you wouldn't necessarily expect. For example, when I was reviewing one of your manuscripts before this went to print, you did reject one of my suggestions, which was just, retitle the entire thing. Instead of calling it The Unicorn Project. Instead, call it Gene Kim's Love Letter to Functional Programming. So what is up with that?Gene Kim: Yeah, to put that into context, for 25 years or more, I've self-identified as an ops person. The Phoenix Project was really an ops book. And that was despite getting my graduate degree in compiler design and high-speed networking in 1995. And the reason why I gravitated towards ops, because that was my observation, that that's where the saves were made. It was ops who saved the customer from horrendous, terrible developers who just kept on putting things into production that would then blow up and take everyone with it. It was ops protecting us from the bad adversaries who were trying to steal data because security people were so ineffective. But four years ago, I learned a functional programming language called Clojure and, without a doubt, it reintroduced the joy of coding back into my life and now, in a good month, I spend half the time—in the ideal—writing, half the time hanging out with the best in the game, of which I would consider this to be a part of, and then 20% of time coding. And I find for the first time in my career, in over 30 years of coding, I can write something for years on end, without it collapsing in on itself, like a house of cards. And that is an amazing feeling, to say that maybe it wasn't my inability, or my lack of experience, or my lack of sensibilities, but maybe it was just that I was sort of using the wrong tool to think with. That comes from the French philosopher Claude Lévi-Strauss. He said of certain things, “Is it a good tool to think with?” And I just find functional programming is such a better tool to think with, that notions like composability, like immutability, what I find so exciting is that these things aren't just for programming languages. And some other programming languages that follow the same vein are, OCaml, Lisp, ML, Elixir, Haskell. These all languages that are sort of popularizing functional programming, but what I find so exciting is that we see it in infrastructure and operations, too. So Docker is fundamentally immutable. So if you want to change a container, we have to make a new one. Kubernetes composes these containers together at the level of system of systems. Kafka is amazing because it usually reveals the desire to have this immutable data model where you can't change the past. Version control is immutable. So, I think it's no surprise that as our systems get more and more complex and distributed, we're relying on things like immutability, just to make it so that we can reason about them. So, it is something I love addressing in the book, and it's something I decided to double down on after you mentioned it. I'm just saying, all kidding aside is this a book for—Corey Quinn: Oh good, I got to make it worse. Always excited when that happens.Gene Kim: Yeah, I mean, your suggestion really brought to the forefront a very critical decision, which was, is this a book for technology leaders, or even business leaders, or is this a book developers? And, after a lot of soul searching, I decided no, this is a book for developers, because I think the sensibilities that we need to instill and the awareness we need to create these things around are the developers and then you just hope and pray that the book will be good enough that if enough engineers like it, then engineering leaders will like it. And if enough engineering leaders like it, then maybe some business leaders will read it as well. So that's something I'm eagerly seeing what will happen as the weeks, months, and years go by. Corey Quinn: This episode is sponsored in part by DataStax. The NoSQL event of the year is DataStax Accelerate in San Diego this May from the 11th through the 13th. I've given a talk previously called the myth of multi-cloud, and it's time for me to revisit that with... A sequel! Which is funny given that it's a NoSQL conference, but there you have it. To learn more, visit datastax.com that's D-A-T-A-S-T-A-X.com and I hope to see you in San Diego. This May.Corey Quinn: One thing that I always admired about your writing is that you can start off trying to make a point about one particular aspect of things. And along the way you tie in so many different things, and the functional programming is just one aspect of this. At some point, by the end of it, I half expected you to just pick a fight over vi versus Emacs, just for the sheer joy you get in effectively drawing interesting and, I guess, shall we say, the right level of conflict into it, where it seems very clear that what you're talking about is something thing that has the potential to be transformative and by throwing things like that in you're, on some level, roping people in who otherwise wouldn't weigh in at all. But it's really neat to watch once you have people's attention, just almost in spite of what they want, you teach them something. I don't know if that's a fair accusation or not, but it's very much I'm left with the sense that what you're doing has definite impact and reverberations throughout larger industries.Gene Kim: Yeah, I hope so. In fact, just to reveal this kind of insecurity is, there's an author I've read a lot of and she actually read this blog post that she wrote about the worst novel to write, and she called it The Yeomans Tour of the Starship Enterprise. And she says, “The book begins like this: it's a Yeoman on the Starship Enterprise, and all he does is admire the dilithium crystals, and the phaser, and talk about the specifications of the engine room.” And I sometimes worry that that's what I've done in The Unicorn Project, but hopefully—I did want to have that technical detail there and share some things that I love about technology and the things I hate about technology, like YAML files, and integrate that into the narrative because I think it is important. And I would like to think that people reading it appreciate things like our mutual distaste of YAML files, that we've all struggled trying to escape spaces and file names inside of make files. I mean, these are the things that are puzzles we have to solve, but they're so far removed from the business problem we're trying to solve that really, the purpose of that was trying to show the mistake of solving puzzles in our daily work instead of solving real problems.Corey Quinn: One thing that I found was really a one-two punch, for me at least, was first I read and give feedback on the book and then relatively quickly thereafter, I found myself at my first DevOps Enterprise Summit, and I feel like on some level, I may have been misinterpreted when I was doing my live-tweeting/shitposting-with-style during a lot of the opening keynotes, and the rest, where I was focusing on how different of a conference it was. Unlike a typical DevOps Days or big cloud event, it wasn't a whole bunch of relatively recent software startups. There were serious institutions coming out to have conversations. We're talking USAA, we're talking to US Air Force, we're talking large banks, we're talking companies that have a 200-year history, where you don't get to just throw everything away and start over. These are companies that by and large, have, in many ways, felt excluded to some extent, from the modern discussions of, well, we're going to write some stuff late at night, and by the following morning, it's in production. You don't get to do that when you're a 200-year-old insurance company. And I feel like that was on some level interpreted as me making fun of startups for quote/unquote, “not being serious,” which was never my intention. It's just this was a different conversation series for a different audience who has vastly different constraints. And I found it incredibly compelling and I intend to go back.Gene Kim: Well, that's wonderful. And, in fact, we have plans for you, Mr. Quinn.Corey Quinn: Uh-oh.Gene Kim: Yeah. I think when I say I admire the DevOps Enterprise community. I mean that I'm just so many different dimensions. The fact that these, leaders and—it's not leaders just in terms of seniority on the organization chart—these are people who are leading technology efforts to survive and win in the marketplace. In organizations that have been around sometimes for centuries, Barclays Bank was founded in the year 1634. That predates the invention of paper cash. HMRC, the UK version of the IRS was founded in the year 1200. And, so there's probably no code that goes that far back, but there's certainly values and—Corey Quinn: Well, you'd like to hope not. Gene Kim: Yeah, right. You never know. But there are certainly values and traditions and maybe even processes that go back centuries. And so that's what's helped these organizations be successful. And here are a next generation of leaders, trying to make sure that these organizations see another century of greatness. So I think that's, in my mind, deeply admirable.Corey Quinn: Very much so. And my only concern was, I was just hoping that people didn't misinterpret my snark and sarcasm as aimed at, “Oh, look at these crappy—these companies are real companies and all those crappy SAS companies are just flashes in the pan.” No, I don't believe that members of the Fortune 500 are flash in the pan companies, with a couple notable exceptions who I will not name now, because I might want some of them on this podcast someday. The concern that I have is that everyone's work is valuable. Everyone's work is important. And what I'm seeing historically, and something that you've nailed, is a certain lack of stories that apply to some of those organizations that are, for lack of a better term, ossified into their current process model, where they there's no clear path for them to break into, quote/unquote, “doing the DevOps.”Gene Kim: Yeah. And the business frame and the imperative for it is incredible. Tesla is now offering auto insurance bundled into the car. Banks are now having to compete with Apple. I mean, it is just breathtaking to see how competitive the marketplaces and the need to understand the customer and deliver value to them quickly and to be able to experiment and innovate and out-innovate the competition. I don't think there's any business leader on the planet who doesn't understand that software is eating the world and they have to that any level of investment they do involves software at some level. And so the question is, for them, is how do they get educated enough to invest and manage and lead competently? So, to me it really is like the sleeping giant awakening. And it's my genuine belief is that the next 50 years, as much value as the tech giants have created: Facebook, Amazon, Netflix, Google, Microsoft, they've generated trillions of dollars of economic value. When we can get eighteen million developers, as productive as an engineer at a tech giant is, that will generate tens of trillions of dollars of economic value per year. And so, when you generate that much economic activity, all problems become solvable, you look at climate change, you take a look at the disparity between rich and poor. All things can be fixed when you significantly change the economic economy in this way. So, I'm extremely hopeful and I know that the need for things like DevOps are urgent and important.Corey Quinn: I guess that that's probably the best way of framing this. So you wrote one version that was aimed at operators back in 2013, this one was aimed at developers, and effectively retails and clarifies an awful lot of the same points. As a historical ops person, I didn't feel left behind by The Unicorn Project, despite not being its target market. So I guess the question on everyone's mind, are you planning on doing a third iteration, and if so, for what demographic?Gene Kim: Yeah, nothing at this point, but there is one thing that I'm interested in which is the role of business leaders. And Sarah is an interesting villain. One of my favorite pieces of feedback during the review process was, “I didn't think I could ever hate Sarah more. And yet, I did find her even to be more loathsome than before.” She's actually based on a real person, someone that I worked with.Corey Quinn: That's the best part, is these characters are relatable enough that everyone can map people they know onto various aspects of them, but can't ever disclose the entire list in public because that apparently has career consequences.Gene Kim: That's right. Yes, I will not say who the character is based on but there's, in the last scene of the book that went to print, Sarah has an interesting interaction with Maxine, where they meet for lunch. And, I think the line was, “And it wasn't what Maxine had thought, and she's actually looking forward to the next meeting.” I think that leaves room for it. So one of the things I want to do with some friends and colleagues is just understand, why does Sarah act the way she does? I think we've all worked with someone like her. And there are some that are genuinely bad actors, but I think a lot of them are doing something, based on genuine, real motives. And it would be fun, I thought, to do something with Elizabeth Henderson, who we decided to start having a conversation like, what does she read? What is her background? What is she good at? What does her resume look like? And what caused her to—who in technology treated her so badly that she treats technology so badly? And why does she behave the way she does? And so I think she reads a lot of strategy books. I think she is not a great people manager, I think she maybe has come from the mergers and acquisition route that viewed people as fungible. And yeah, I think she is definitely a creature of economics, was lured by an external investor, about how good it can be if you can extract value out of the company, squeeze every bit of—sweat every asset and sell the company for parts. So I would just love to have a better understanding of, when people say they work with someone like a Sarah, is there a commonality to that? And can we better understand Sarah so that we can both work with her and also, compete better against her, in our own organizations?Corey Quinn: I think that's probably a question best left for people to figure out on their own, in a circumstance where I can't possibly be blamed for it.Gene Kim: [laughing].That can be arranged, Mr. Quinn.Corey Quinn: All right. Well, if people want to learn more about your thoughts, ideas, feelings around these things, or of course to buy the book, where can they find you?Gene Kim: If you're interested in the ideas that are in The Unicorn Project, I would point you to all of the freely available videos on YouTube. Just Google DevOps Enterprise Summit and anything that's on the plenary stage are specifically chosen stories that very much informed The Unicorn Project. And the best way to reach me is probably on Twitter. I'm @RealGeneKim on Twitter, and feel free to just @ mention me, or DM me. Happy to be reached out in whatever way you can find me. Corey Quinn: You know where the hate mail goes then. Gene, thank you so much for taking the time to speak with me, I appreciate it.Gene Kim: And Corey, likewise, and again, thank you so much for your unflinching feedback on the book and I hope you see your fingerprints all over it and I'm just so delighted with the way it came out. So thanks to you, Corey. Corey Quinn: As soon as my signed copy shows up, you'll be the first to know.Gene Kim: Consider it done. Corey Quinn: Excellent, excellent. That's the trick, is to ask people for something in a scenario in which they cannot possibly say no. Gene Kim, multiple award-winning CTO, researcher, and author. Pick up his new book, The Wall Street Journal best-selling The Unicorn Project. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you hated this podcast, please leave a five-star review on Apple Podcasts and leave a compelling comment.Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

Jaret Binford on GitHub - https://github.com/Jaretbinford Alex Miller on GitHub - https://github.com/puredanger 15 years of Clojure - https://www.youtube.com/watch?v=exSRG-iL74Q Request podcast - https://github.com/clojurestream/podcast Video Courses: https://clojure.stream https://www.learnpedestal.com/ https://www.learndatomic.com/ https://www.learnreitit.com/ https://www.learnreagent.com/ https://www.learnreframe.com/ https://www.jacekschae.com/

Following our previous episode on Richard P. Gabriel's Incommensurability paper, we're back for round two with an analysis of what we've dubbed the Worse is Better family of thought products: The Rise of Worse Is Better by Richard P. Gabriel Worse is Better is Worse by Nickieben Bourbaki Is Worse Really Better? by Richard P. Gabriel Next episode, we've got a recent work by a real up-and-comer in the field. While you may not have heard of him yet, he's a promising young lad who's sure to become a household name. Magic Ink by Bret Victor Links The JIT entitlement on iOS is a thing that exists now. Please, call me Nickieben — Mr. Bourbaki is my father. A pony is a small horse. Also, horses have one toe. Electron lets you build cross-platform apps using web technologies. The apps you build in it are, arguably, doing a bit of "worse is better" when compared to equivalent native apps. Bun is a new JS runner that competes somewhat with NodeJS and Deno, and is arguably an example of "worse is better". esbuild and swc are JS build tools, and are compared to the earlier Babel. The graphs showing the relative lack of churn in Clojure's source code came from Rich Hickey's A History of Clojure talk. To see those graphs, head over to the FoC website for the expanded version of these show notes. Some thoughts about wormholes. futureofcoding.org/episodes/059See omnystudio.com/listener for privacy information.

Array Cast - August 19, 2022 Show NotesMany thanks to Marshall Lochbaum, Rodrigo Girão Serrão, Bob Therriault, Conor Hoekstra, Adám Brudzewsky and Romilly Cocking for gathering these links:[01] 00:00:03 BYTE magazine https://en.wikipedia.org/wiki/Byte_(magazine)[02] 00:01:02 Org Mode https://orgmode.org/[03] 00:02:58 Toronto Meet-up https://www.meetup.com/en-AU/programming-languages-toronto-meetup/events/287695788/ New York Meet-up https://www.meetup.com/programming-languages-toronto-meetup/events/287729348/[04] 00:04:19 Morten Kromberg episode https://www.arraycast.com/episodes/episode21-morten-kromberg[05] 00:05:01 Romilly's video 'An Excellent Return' https://dyalog.tv/Dyalog08/?v=thr-7QfQWJw[06] 00:06:12 Ferranti Pegasus computer https://en.wikipedia.org/wiki/Ferranti_Pegasus[07] 00:09:09 System 360 in APL http://keiapl.org/archive/APL360_UsersMan_Aug1968.pdf[08] 00:16:50 Mind Map https://en.wikipedia.org/wiki/Mind_map[09] 00:17:00 Dyalog https://www.dyalog.com/[10] 00:18:20 Digitalk https://winworldpc.com/product/digital-smalltalk/5x[11] 00:18:30 Smalltalk https://en.wikipedia.org/wiki/Smalltalk[12] 00:21:17 Raspberry Pi https://www.raspberrypi.org/[13] 00:22:10 Robotics on Dyalog website https://www.dyalog.com/blog/2014/08/dancing-with-the-bots/[14] 00:22:45 Neural Network https://en.wikipedia.org/wiki/Neural_network David Marr https://en.wikipedia.org/wiki/David_Marr_(neuroscientist)[15] 00:23:21 Jetson Nano https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-nano/[16] 00:23:38 Spiking neural networks https://en.wikipedia.org/wiki/Spiking_neural_network[17] 00:24:02 JAX https://jax.readthedocs.io/en/latest/notebooks/quickstart.html[18] 00:27:00 Numpy https://numpy.org/[19] 00:28:21 Nested arrays https://aplwiki.com/wiki/Nested_array[20] 00:29:07 flip Numpy https://numpy.org/doc/stable/reference/generated/numpy.flip.html flipud https://numpy.org/doc/stable/reference/generated/numpy.flipud.html#numpy.flipud[21] 00:31:07 Pegasus Autocode http://blog.rareschool.com/2014/09/pegasus-autocode-revisited.html[22] 00:32:05 Atlas computer 1966 https://en.wikipedia.org/wiki/Atlas_(computer)[23] 00:34:30 Raspberry Pi pico https://www.raspberrypi.com/products/raspberry-pi-pico/[24] 00:36:33 Booker and Morris https://dl.acm.org/doi/pdf/10.1145/364520.364521[25] 00:38:12 Romilly's Blog Markdown http://blog.rareschool.com/2022/05/apl-and-python-go-head-to-head.html[26] 00:41:30 Languages that are built from concatenation https://en.wikipedia.org/wiki/Agglutination[27] 00:44:30 Alan Kay https://en.wikipedia.org/wiki/Alan_Kay[28] 00:47:12 Clojure https://en.wikipedia.org/wiki/Alan_Kay Forth https://en.wikipedia.org/wiki/Forth_(programming_language) Haskell https://www.haskell.org/[29] 00:50:00 Cosy http://www.cosy.com/language/[30] 00:51:38 Py'n'APL https://dyalog.tv/Dyalog21/?v=gOUFXBUMv_A[31] 01:00:12 Logic Analyzer https://en.wikipedia.org/wiki/Logic_analyzer[32] 01:02:15 Back propagation in neural networks https://en.wikipedia.org/wiki/Backpropagation[33] 01:07:38 Stefan Kruger 'Learn APL' https://xpqz.github.io/learnapl/intro.html[34] 01:08:10 Rodrigo Girão Serrão videos https://www.youtube.com/channel/UCd_24S_cYacw6zrvws43AWg[35] 01:08:27 João Araújo episode https://www.arraycast.com/episodes/episode33-joao-araujo[36] 01:08:59 Rodrigo Girão Serrão Neural networks https://www.youtube.com/playlist?list=PLgTqamKi1MS3p-O0QAgjv5vt4NY5OgpiM[37] 01:10:55 Functional Geekery podcast https://www.functionalgeekery.com/[38] 01:11:36 Conor's Security talk https://www.youtube.com/watch?v=ajGX7odA87k[39] 01:12:38 SICP https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs[40] 01:12:55 Alan McKean Rebecca Wirfs-Brock "Object Design" https://books.google.ca/books?id=vUF72vN5MY8C&printsec=copyright&redir_esc=y#v=onepage&q&f=false[41] 01:13:35 Growing Object Oriented Guided by Tests http://www.growing-object-oriented-software.com/[42] 01:15:01 Design Patterns vs Anti pattern in APL https://www.youtube.com/watch?v=v7Mt0GYHU9A[43] 01:18:25 Pop2 https://hopl.info/showlanguage.prx?exp=298&language=POP-2 Pop2 on pdf-11 https://www.cs.bham.ac.uk/research/projects/poplog/retrieved/adrian-howard-pop11.html[44] 01:18:52 Donald Michie https://en.wikipedia.org/wiki/Donald_Michie[45] 01:21:30 Menace robot http://chalkdustmagazine.com/features/menace-machine-educable-noughts-crosses-engine/[46] 01:22:05 Menace in APL https://romilly.github.io/o-x-o/an-introduction.html

Why we think Malcolm Gladwell is wrong about remote work, and the complicated answer to a simple question.

We debate the lies our tool makers tell us, if Clojure has a Rails-sized hole, and the secrets of a successful software engineer.

We debate the lies our tool makers tell us, if Clojure has a Rails-sized hole, and the secrets of a successful software engineer.

Once again, Stack Overflow takes the pulse of the developer community where we have all collectively decided to switch to Clojure, while Michael is changing things up, Joe is a future predicting trailblazer, and Allen is "up in the books"

Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec. Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure! Page transitions Overview (https://youtu.be/JCJUPJ_zDQ4) Using yield_self for composable ActiveRecord relations (https://thoughtbot.com/blog/using-yieldself-for-composable-activerecord-relations) A Case for Query Objects in Rails (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) Customer.io (https://customer.io/) Turning the database inside-out with Apache Samza | Confluent (https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/) Datomic (https://www.datomic.com/) About CRDTs • Conflict-free Replicated Data Types (https://crdt.tech/) Apache Kafka (https://kafka.apache.org/) Resilient Management | A book for new managers in tech (https://resilient-management.com/) Mixpanel: Product Analytics for Mobile, Web, & More (https://mixpanel.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're -- STEPH: Oh, I have golden roads, yes. [laughter] CHRIS: You might should inform that you've got golden roads, yeah. STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that. CHRIS: [laughs] STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it? [laughter] CHRIS: Do you want to fight? STEPH: Yeah, are we going to fight? CHRIS: I might could fight you. STEPH: I might could. I might should. [laughter] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari. But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming. CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others? STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those. CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody. STEPH: Oh, I'm behind. CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it. STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie. CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene. [laughter] STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is. CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs] STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five. CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie. STEPH: Yeah, that would be death by Top Gun. CHRIS: But not the normal way, the different, indirect death by Top Gun. STEPH: I don't know what the normal way is. [laughs] CHRIS: Like getting shot down by a Top Gun pilot. [laughter] STEPH: Yeah, that makes sense. [laughs] CHRIS: You know, the dogfighting in the plane. STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note. And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec. And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things. But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name. Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up. But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over? How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never. CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles] STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup. CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior's phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here... I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise. And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal. But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it. STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it. And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do. CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing. STEPH: Cool. Well, that's a huge help to me. What's going on in your world? CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well." So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at. But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty. One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there. And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this. STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I? [laughter] CHRIS: What am I actually? STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating. CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly. There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me. Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures. STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool. CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures. And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through. So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting. STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs] CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs] STEPH: No, raving. I will never forget now, raving. [laughs] CHRIS: So, I mean, we've done this before. STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends." [laughter] CHRIS: Actually, we got a handful of emails on that. [laughter] STEPH: Did you know the English language? CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs] But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it. But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake. Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph? STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know. CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still. [laughter] STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters. So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it. So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there. And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it. But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods. So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by. And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this? CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic. And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can. The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before. STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process. Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time. CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that. STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world? CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing. Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event. And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy. As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set. So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either. There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream. So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that. And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together. STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world. And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next? CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application. So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit. But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there. There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It's like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this. But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out. STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again? While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world? CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me. We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it. But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it. STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next. But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it would be great to own that. But that the other time if there's this other service that has already built that product and they're doing it super well, then let's keep letting them manage that portion of our business until we really need to bring it in-house. Because then we need to incorporate it more into our application itself so then we can surface things to the user. That's the part where then I get really interested, or that's the pain point that I could see is if we wanted more of that behavior analysis, that then we want to surface that in the app, then always having to go to a third-party would start to feel tedious or could feel more brittle. CHRIS: Yeah, I'm definitely 100% on not rebuilding Mixpanel in our app and being okay with the fact that we're sending that. Again, the thing that I did to make myself feel better about this is stream the data to S3 so that I have a version of it. And if we want to rebuild the data warehouse down the road to build some sort of machine learning data pipeline thing, we've got some raw data to work with. But I'm noticing lots of places where we're transforming a side effect, a behavior that we have in the system to dispatching an event. And so right now, we have a bunch of stuff that we pipe over to Slack to inform our admin team, hey, this thing happened. You should probably intervene. But I'm looking at that, and we're doing it directly because we can control the message in Slack a little bit better. But I had this thought in the back of my mind; it's like, could we just send that as an event, and then some downstream tool can configure messages and alerts into Slack? Because then the admin team could actually instrument this themselves. And they could be like; we are no longer interested in this event. Users seem fine on that front. But we do care about this new event. And all we need to do as the engineering team is properly instrument all of that event stream tapping. Every event just needs to get piped over. And then lots of powerful tools downstream from that that can allow different consumers of that data to do things, and broadly, that dispatch events, consume them on the other side, do fun stuff. That's the story. That's the dream. But I don't know; I can't connect all the dots. It's probably going to take me a couple of weeks to connect all these dots, or maybe years, or maybe my entire career, something like that. But, I don't know, I'm going to keep trying. STEPH: This feels like a fun startup narrative, though, where you start by building the thing that people can interact with. As more people start to interact with it, how do we start giving more of our team the ability to then manage the product that then all of these users are interacting with? And then that's the part that you start optimizing for. So there are always different interesting bits when you talk about the different stages of Sagewell, and like, what's the thing you're optimizing for? And I'm sure it's still heavily users. But now there's also this addition of we are also optimizing for our team to now manage the product. CHRIS: Yes, you're 100%. You're spot on there. We have definitely joked internally about spinning out a small company to build this analytics alerting tool [laughs] but obviously not going to do that because that's a distraction. And it is interesting, like, we want to build for the users the best thing that we can and where the admin team fits within that. To me, they're very much customers of engineering. Our job is to build the thing for the users but also, to be honest, we have to build a thing for the admins to support the users and exactly where that falls. Like, you and I have talked a handful of times about maybe the admin isn't as polished in design as other things. But it's definitely tested because that's a critical part of how this application works. Maybe not directly for a user but one step removed for a user, so it matters. Absolutely we're writing tests to cover that behavior. And so yeah, those trade-offs are always interesting to me and exploring that space. But 100%: our admin team are core customers of the work that we're doing in engineering. And we try and stay very close and very friendly with them. STEPH: Yeah, I really appreciate how you're framing that. And I very much agree and believe with you that our admin users are incredibly important. CHRIS: Well, thank you. Yeah, we're trying over here. But yeah, I think I can wrap up that segment of me rambling about ideas that are half-formed in my mind but hopefully are directionally important. Anyway, what else is up with you? STEPH: So, not that long ago, I asked you a question around how the heck to manage themes that I have going on. So we've talked about lots of fun productivity things around managing to-dos, and emails, and all that stuff. And my latest one is thinking about, like, I have a theme that I want to focus on, maybe it's this week, maybe it's for a couple of months. And how do I capture that and surface it to myself and see that I'm making progress on that? And I don't have an answer to that. But I do have a theme that I wanted to share. And the one that I'm currently focused on is building up management skills and team lead skills. That is something that I'm focused on at the moment and partially because I was inspired to read the book Resilient Management written by Lara Hogan. And so I think that is what has really set the idea. But as I picked up the book, I was like, this is a really great book, and I'd really like to share some of this. And then so that grew into like, well, let's just go ahead and make this a theme where I'm learning this, and I'm sharing this with everyone else. So along that note, I figured I would share that here. So we use Basecamp at thoughtbot. And so, I've been sharing some Basecamp posts around what I'm learning in each chapter. But to bring some of that knowledge here as well, some of the cool stuff that I have learned so far...and this is just still very early on in the book. There are a couple of different topics that Laura covers in the first chapter, and one of them is humans' core needs at work. And then there's also the concept of meeting your team, some really good questions that you can ask during your first one-on-one to get to know the person that then you're going to be managing. The part that really resonated with me and something that I would like to then coach myself to try is helping the team get to know you. So as a manager, not only are you going out of your way to really get to know that person, but how are you then helping them get to know you as well? Because then that's really going to help set that relationship in regards of they know what kind of things that you're optimizing for. Maybe you're optimizing for a deadline, or for business goals, or maybe it's for transparency, or maybe it would be helpful to communicate to someone that you're managing to say, "Hey, I'm trying some new management techniques. Let me know how this goes." [chuckles] So there's a healthier relationship of not only are you learning them, but they're also learning you. So some of the questions that Laura includes as examples as something that you can share with your team is what do you optimize for in your role? So is it that you're optimizing for specific financial goals or building up teammates? Or maybe it's collaboration, so you're really looking for opportunities for people to pair together. What do you want your teammates to lean on you for? I really liked that question. Like, what are some of the areas that bring you joy or something that you feel really skilled in that then you want people to come to you for? Because that's something that before I was a manager...but it's just as you are growing as a developer, that's such a great question of like, what do you want to be known for? What do you want to be that thing that when people think of, they're like, oh, you should go see Chris about this, or you should go see Steph about this? And two other good questions include what are your work styles and preferences? And what management skills are you currently working on learning or improving? So I really like this concept of how can I share more of myself? And the great thing about this book that I'm learning too is while it is geared towards people that are managers, I think it's so wonderful for people who are non-managers or aspiring managers to read this as well because then it can help you manage whoever's managing you. So then that way, you can have some upward management. So we had recent conversations around when you are new to a team and getting used to a manager, or maybe if you're a junior, you have to take a lot of self-advocacy into your role to make sure things are going well. And I think this book does a really good job for people that are looking to not only manage others but also manage themselves and manage upward. So that's some of the journeys from the first chapter. I'll keep you posted on the other chapters as I'm learning more. And yeah, if anybody hasn't read this book or if you're interested, I highly recommend it. I'll make sure to include a link in the show notes. CHRIS: That was just the first chapter? STEPH: Yeah, that was just the first chapter. CHRIS: My goodness. STEPH: And I shortened it drastically. [laughs] CHRIS: Okay. All right, off to the races. But I think the summary that you gave there, particularly these are true when you're managing folks but also to manage yourself and to manage up, like, this is relevant to everyone in some capacity in some shape or form. And so that feels very true. STEPH: I will include one more fun aspect from the book, and that's circling back to the humans' core needs at work. And she references Paloma Medina, a coach, and trainer who came up with this acronym. The acronym is BICEPS, and it stands for belonging, improvement, choice, equality, predictability, and significance. And then details how each of those are important to us in our work and how when one of those feels threatened, then that can lead to some problems at work or just even in our personal life. But the fun example that she gave was not when there's a huge restructuring of the organization and things like that are going on as being the most concerning in terms of how many of these needs are going to be threatened or become vulnerable. But changing where someone sits at work can actually hit all of these, and it can threaten each of these needs. And it made me think, oh, cool, plus-one for being remote because we can sit wherever we want. [laughs] But that was a really fun example of how someone's needs at work, I mean, just moving their desk, which resonates, too, because I've heard that from other people. Some of the friends that I have that work in more of a People Ops role talk about when they had to shift people around how that caused so much grief. And they were just shocked that it caused so much grief. And this explains why that can be such a big deal. So that was a fun example to read through. CHRIS: I'm now having flashbacks to times where I was like, oh, I love my spot in the office. I love the people I'm sitting with. And then there was that day, and I had to move. Yeah, no, those were days. This is true. STEPH: It triggered all the core BICEPS, all the things that you need to work. It threatened all of them. Or it could have improved them; who knows? CHRIS: There were definitely those as well, yeah. Although I think it's harder to know that it's going to be great on the way in, so it's mostly negative. I think it has that weird bias because you're like, this was a thing, I knew it. I at least understood it. And then you're in a new space, and you're like, I don't know, is this going to be terrible or great? I mean, hopefully, it's only great because you work with great people, and it's a great office. [laughs] But, like, the unknown, you're moving into the unknown, and so I think it has an inherent at least questioning bias to it. STEPH: Agreed. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.