Podcasts about code reviews

News includes the release of Elixir 1.18.2 with various enhancements and bug fixes, a new experimental SQL sigil for Ecto that brings automatic parameterized queries, a recent GOTO 2025 talk featuring Saša Jurić on code reviews. We talked with Jonatan Kłosko about his work on PythonX, a new library for executing Python code inside Elixir, the Fine library for working with C++ NIFs, and much more! Show Notes online - http://podcast.thinkingelixir.com/244 (http://podcast.thinkingelixir.com/244) Elixir Community News https://gigalixir.com/thinking (https://gigalixir.com/thinking?utm_source=thinkingelixir&utm_medium=shownotes) – Visit Gigalixir.com to sign up and get 20% off your first year. Or use the promo code "Thinking" during signup. https://github.com/elixir-lang/elixir/releases/tag/v1.18.2 (https://github.com/elixir-lang/elixir/releases/tag/v1.18.2?utm_source=thinkingelixir&utm_medium=shownotes) – Elixir 1.18.2 was released with enhancements to Code.Fragment and Regex, plus bug fixes for CLI, ExUnit, IEx.Autocomplete, and mix deps.update. https://github.com/elixir-lang/elixir/releases/tag/v1.18.1 (https://github.com/elixir-lang/elixir/releases/tag/v1.18.1?utm_source=thinkingelixir&utm_medium=shownotes) – Elixir 1.18.1 included bug fixes for Kernel, ExUnit.Case, mix compile.elixir, mix escript.build, and Mix.Shell, especially related to error handling and Windows compatibility. https://www.erlang.org/news/174 (https://www.erlang.org/news/174?utm_source=thinkingelixir&utm_medium=shownotes) – Erlang OTP 28 RC-1 is out with a new source Software Bill of Materials (SBOM) on the Github Releases page. https://github.com/elixir-dbvisor/sql (https://github.com/elixir-dbvisor/sql?utm_source=thinkingelixir&utm_medium=shownotes) – A new experimental SQL sigil for Ecto brings an extensible SQL parser to Elixir with automatic parameterized queries. https://groups.google.com/g/elixir-ecto/c/8MOkRFAdLZc (https://groups.google.com/g/elixir-ecto/c/8MOkRFAdLZc?utm_source=thinkingelixir&utm_medium=shownotes) – The experimental SQL sigil for Ecto is being discussed on the Elixir-Ecto mailing list. https://www.youtube.com/watch?v=AYUNI2Pm6_w (https://www.youtube.com/watch?v=AYUNI2Pm6_w?utm_source=thinkingelixir&utm_medium=shownotes) – New talk from GOTO 2025 with Saša Jurić and Adrienne Braganza Tacke on "Small PRs, Big Impact - The Art of Code Reviews." https://alchemyconf.com/ (https://alchemyconf.com/?utm_source=thinkingelixir&utm_medium=shownotes) – AlchemyConf is coming up March 31 - April 3 in Braga, Portugal. https://www.gigcityelixir.com/ (https://www.gigcityelixir.com/?utm_source=thinkingelixir&utm_medium=shownotes) – GigCity Elixir and NervesConf are happening in Chattanooga, TN, USA with NervesConf on May 8 and the main event on May 9-10. https://www.elixirconf.eu/ (https://www.elixirconf.eu/?utm_source=thinkingelixir&utm_medium=shownotes) – ElixirConf EU will be held May 15-16, 2025 in Kraków & Virtual. https://goatmire.com/#tickets (https://goatmire.com/#tickets?utm_source=thinkingelixir&utm_medium=shownotes) – Goatmire tickets are on sale now for the event happening September 10-12, 2025 in Varberg, Sweden. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources https://dashbit.co/blog/dashbit-plans-2025 (https://dashbit.co/blog/dashbit-plans-2025?utm_source=thinkingelixir&utm_medium=shownotes) https://github.com/thewca/wca-live (https://github.com/thewca/wca-live?utm_source=thinkingelixir&utm_medium=shownotes) – Speed cubing software https://dashbit.co/blog/running-python-in-elixir-its-fine (https://dashbit.co/blog/running-python-in-elixir-its-fine?utm_source=thinkingelixir&utm_medium=shownotes) https://hexdocs.pm/pythonx/Pythonx.html (https://hexdocs.pm/pythonx/Pythonx.html?utm_source=thinkingelixir&utm_medium=shownotes) https://github.com/livebook-dev/pythonx (https://github.com/livebook-dev/pythonx?utm_source=thinkingelixir&utm_medium=shownotes) https://bsky.app/profile/josevalim.bsky.social/post/3liyrfvlth22c (https://bsky.app/profile/josevalim.bsky.social/post/3liyrfvlth22c?utm_source=thinkingelixir&utm_medium=shownotes) – Jose said “We said we will focus on interoperability for 2025 and we are ready to share the first results.” https://github.com/elixir-nx/fine (https://github.com/elixir-nx/fine?utm_source=thinkingelixir&utm_medium=shownotes) – “Fine” is a new package related to the elixir-nx organization. It's a C++ library enabling more ergonomic NIFs, tailored to Elixir. https://peps.python.org/pep-0703/ (https://peps.python.org/pep-0703/?utm_source=thinkingelixir&utm_medium=shownotes) – Discussion about removing the Python GIL Find us online - Message the show - Bluesky (https://bsky.app/profile/thinkingelixir.com) - Message the show - X (https://x.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen on X - @brainlid (https://x.com/brainlid) - Mark Ericksen on Bluesky - @brainlid.bsky.social (https://bsky.app/profile/brainlid.bsky.social) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel on Bluesky - @david.bernheisel.com (https://bsky.app/profile/david.bernheisel.com) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern)

Roy Derks, Developer Experience at IBM, talks about the integration of Large Language Models (LLMs) in web development. We explore practical applications such as building agents, automating QA testing, and the evolving role of AI frameworks in software development. Links https://www.linkedin.com/in/gethackteam https://www.youtube.com/@gethackteam https://x.com/gethackteam https://hackteam.io We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Roy Derks.

In this episode, I sit down with Stephen Smith, founder of the Center for Building, to uncover the labyrinthine world of building codes—how they're made, who really influences them, and why they end up stifling the very innovation and affordability we need. From the peculiarities of elevator requirements to the often overlooked role of local politics and special interests, we unpack how these complex rules shape our homes, buildings, and cities more than we might realize.TAKEAWAYSWhy Building Codes Matter: Even if you're not a builder or developer, codes dictate your home's layout, the price of housing, and whether your favorite small condo project can even get off the ground.The ICC (International Code Council) Isn't Really “International”: You'll learn how this non-governmental body, which writes most U.S. building codes, can be both extremely influential and surprisingly insular.Over-Regulation's Real-World Costs: We break down how elevator mandates, fire codes, and accessibility requirements—though well-intended—sometimes create perverse incentives that drive up costs or discourage better solutions.Local Politics & Hidden Interests: Discover how “government members” and private manufacturers shape these codes, and why your mayor or city council may have little say in regulations that affect everyone.A Path Forward: Stephen shares practical ways policymakers and citizens can get involved in reforming the system, focusing on a more human-centered approach that balances safety, cost, and beautyCHAPTERS00:00 The Challenge of Building Codes in the U.S.03:06 The Role of Building Codes in Urban Development05:46 Understanding the American Way of Building09:09 The Impact of Building Codes on Housing Costs12:09 Elevator Regulations and Their Consequences14:52 Harmonization of Codes and Standards18:11 Over-Dimensioning in American Construction21:05 Labor Issues in the Construction Industry23:57 The Need for Code Review and Justification26:49 The Tyranny of Bureaucracy in Building Codes38:49 The Grenfell Fire and Its Aftermath45:05 Design Innovations in Building Codes48:25 Understanding the ICC and Code Writing58:09 The Revolving Door: Industry and Regulation01:07:26 The Role of Government in Building Codes01:15:20 Getting Involved: Supporting Change in Building CodesCONNECT WITH STEPHENCenter for Building https://www.centerforbuilding.org/BlueSky: https://bsky.app/profile/stephenjacobsmith.com Email: stephen@centerforbuilding.orgMENTIONED RESOURCESElevator research: https://admin.centerforbuilding.org/wp-content/uploads/2024/12/Elevators.pdf CONNECT WITH AUSTIN TUNNELLNewsletter: https://playbook.buildingculture.com/https://www.instagram.com/austintunnell/https://www.linkedin.com/in/austin-tunnell-2a41894a/https://twitter.com/AustinTunnellCONNECT WITH BUILDING CULTUREhttps://www.buildingculture.com/https://www.instagram.com/buildingculture/https://twitter.com/build_culturehttps://www.facebook.com/BuildCulture/SPONSORSThank you so much to the sponsors of The Building Culture Podcast!Sierra Pacific Windows: https://www.sierrapacificwindows.com/One Source Windows: https://onesourcewindows.com/

Merrill Lutsky is the cofounder and CEO of Graphite, an AI-powered code reviewer that's used by tens of thousands of users. They are backed by amazing investors including Andreessen Horowitz.Merrill's favorite book: Never Split the Difference (Author: Chris Voss)(00:01) Introduction(00:06) Teaching AI to Understand Code(02:40) AI-Assisted Code Generation and Code Review(06:20) Current Landscape of AI-Assisted Code Review(09:04) Motivation Behind Launching Graphite(16:52) Landing the First Paying Users and Early Learnings(21:42) Growth Experiments: Wins and Misses(26:27) Current Scale of Graphite(29:12) Tech Stack Behind Graphite(33:12) Future of AI-Assisted Coding and Graphite's Role(35:37) Rapid Fire Round--------Where to find Merrill Lutsky: LinkedIn: https://www.linkedin.com/in/merrill-lutsky/--------Where to find Prateek Joshi: Newsletter: https://prateekjoshi.substack.com Website: https://prateekj.com LinkedIn: https://www.linkedin.com/in/prateek-joshi-91047b19 X: https://x.com/prateekvjoshi 

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereAdrienne Braganza Tacke - Senior Developer Advocate at Cisco & Author of "Looks Good To Me: Constructive Code Reviews"Paul Slaughter - Staff Fullstack Engineer at GitLab & Creator of Conventional CommentsRESOURCESAdriennehttps://x.com/AdrienneTackehttps://github.com/AdrienneTackehttps://www.linkedin.com/in/adriennetackehttps://www.instagram.com/adriennetackehttps://www.adrienne.iohttps://blog.adrienne.ioPaulhttps://x.com/souldzinhttps://github.com/souldzinhttps://gitlab.com/pslaughterhttps://gitlab.com/souldzinhttps://souldzin.comDESCRIPTIONPaul Slaughter and Adrienne Braganza Tacke delve into the critical role of communication in code reviews, emphasizing how soft skills can significantly enhance the engineering process. Adrienne, drawing insights from her upcoming book, explores the expectations for software engineers in code reviews, offers practical tips for improving communication, and shares her unique perspective on the parallels between writing and reviewing code.Their conversation highlights the importance of fostering a positive feedback culture and leading by example to create a collaborative environment within teams.RECOMMENDED BOOKSAdrienne Braganza Tacke • "Looks Good to Me": Constructive Code ReviewsAdrienne Braganza Tacke • Coding for KidsGrace Huang • Code Reviews in TechMartin Fowler • RefactoringMatthew Skelton & Manuel Pais • Team TopologiesDave Thomas & Andy Hunt • The Pragmatic ProgrammerBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking 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, we dive deep into the dynamics of working solo versus being part of a development team. From the ideal team composition at large companies to the challenges of maintaining open source projects, our hosts share their experiences and insights. Learn about the crucial roles of designers and product managers, the importance of documentation, and why even senior developers still Google Git commands. Whether you're a solo developer looking to collaborate or a team player wanting to improve your workflow, this episode has something for everyone. Chapter Marks00:00 - Introduction01:16 - The Perfect Team Composition02:44 - Different Approaches to Team Building04:37 - Working Without Designers: The FedEx Experience08:10 - Documentation and Project Requirements12:30 - The Role of Documentation in Team Success14:47 - Documentation's Impact on Career Growth15:14 - Onboarding and Documentation Connection16:51 - Open Source Project Management19:45 - Automation in Open Source22:34 - Deals for Devs: Managing Contributors25:29 - Branch Management and PR Workflows29:59 - Solo Development Practices31:21 - Git Commands and Team Workflows35:14 - Open Source Knowledge Barriers38:02 - The Importance of Admitting What You Don't Know39:15 - Episode Wrap-up LinksNick Taylor's Blog Post about GitHub Code Owners - https://dev.to/opensauced/supercharge-your-repository-with-code-owners-4clgB Dougie's GitHub Action for the "Take" command - https://github.com/bdougie/take-action/blob/main/action.ymlChantastic's Git Course on Epic Web - https://www.epicweb.dev/tutorials/git-fundamentalsGitHub Documentation on Squash Merging vs Rebase Merging - https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-mergesMerge vs Rebase vs Squash - https://gist.github.com/mitchellh/319019b1b8aac9110fcfb1862e0c97fbGitHub Issue Forms Documentation - https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-formsGitHub Pull Request Templates Guide - https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repositoryGitHub Code Owners Documentation - https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-ownersVirtual Coffee's Hacktoberfest Resources - https://hacktoberfest.virtualcoffee.io/OpenSauce - https://opensauced.pizza/The "Working Genius" Assessment - https://www.workinggenius.com/Gun.io Work Personality Quiz - https://gun.io/workstyle/Deals for Devs Project - https://www.dealsfordevs.com/GitHub Actions Documentation on Release Management - https://docs.github.com/en/actions/sharing-automations/creating-actions/releasing-and-maintaining-actionsConventional Commits Documentation - https://www.conventionalcommits.org/en/v1.0.0/

Are you helping or holding your team back? In this episode, I explore why sharing technical answers with your development team might not be the best way to help them grow. Instead, learn how to use resourceful questions to empower your team members to think critically, solve problems independently, and build long-term confidence. This coaching strategy is rooted in co-active coaching principles and can transform how you mentor junior developers or lead your software team. Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching Join the Thriving Tech Community: https://thrivingtechnologist.com/community As a tech lead, manager, or mentor, it's natural to want to provide answers when your team is stuck. But constantly solving problems for them can create dependency and stifle their growth. By shifting from a directive approach to a coaching mindset, you'll help your team develop essential skills, foster ownership, and reduce your own workload in the long run. In this video, I'll share practical examples and techniques you can start using today to guide your team effectively without always giving them the solution. If you've ever felt the pressure to be the “go-to expert” on your team, this episode will challenge that belief and show you a better way to lead. Coaching your team to solve their own problems not only benefits them but also makes you a stronger leader. Watch now to learn how to implement these strategies and take your leadership to the next level! You can also watch this episode on YouTube.  Chapter markers / timelinks: (0:00) Introduction (1:14) 1 Bringing Out The Best in Your Software Team (1:31) 1.1 Solving Problems For People Holds Them Back (2:48) 1.2 Let People Struggle (4:36) 1.3 The Role of Resourceful Questions (11:30) 1.3.1 Examples of Resourceful Questions (11:35) 1.3.1.1 "Have You Broken This Up Into Smaller Pieces?" (12:33) 1.3.1.2 "Have You Really Considered ALL Your Options?" (14:07) 1.3.1.3 "What if I Wasn't Available?" (15:09) 1.4 Shifting From Expert to Coach (22:36) 1.5 The Long-Term Benefits of Coaching (26:16) 2 How To Start Leading Like a Coach (26:48) 2.1 Start Small (28:50) 2.2 You Don't Need Formal Training (29:50) 2.3 Where to Start Coaching (30:02) 2.3.1 Code Reviews (31:08) 2.3.2 Design Reviews  (32:46) 2.3.3 Project Planning (33:30) 2.3.4 Debugging Sessions (34:30) Get Help with Leadership Visit me at thrivingtechnologist.com

ORDINANCES AND RESOLUTIONS CB2024-181: A Resolution Appointing Jason Dodds to the Code Review & Appeals Board in the City of Champaign  CB2024-182: A Resolution Appointing Benjamin Bloomer to the Human Relations Commission in the City of Champaign CB2024-183: A Resolution Approving the Preliminary/Final Plat of Interstate Research Subdivision No. 2 CB2024-184: A Resolution Approving the Preliminary/Final Plat of Gail Market Subdivision CB2024-185: An Ordinance Amending the Zoning Map of the City of Champaign to Rezone 605 North First Street from the CB1, Central Business Urban Fringe Zoning District to the CB3, Central Business Campustown Zoning District  CB2024-186: An Ordinance Approving a Special Use Permit to Allow for Transitional Housing in the CN, Commercial Neighborhood Zoning District CB2024-187: A Resolution Authorizing the City Manager to Execute a Change Order with Heartland Parking, Inc. for Management Services for the Hill Street Parking Deck CB2024-188: A Resolution Authorizing the City Manager to Execute Subrecipient Agreements with Various Agencies

Exploring AI, Cybersecurity, and Open Source with Chris Lindsey from Mend.io In this episode of the FINOS podcast, Grizz Griswold interviews Chris Lindsey, a Security Evangelist from Mend.io. They discuss the intersection of AI, cybersecurity, and open-source software. Chris shares his extensive experience in software development and application security, providing insights into secure coding practices, the critical role of open source in development, and practical approaches to managing AI technology within highly regulated industries. Tune in to learn about the challenges and strategies in the evolving landscape of AI and cybersecurity. 00:00 Introduction to AI and Security 01:07 Meet Chris Lindsey of Mend.io 02:34 Chris Lindsey's Origin Story 04:39 Challenges in Secure Software Development 07:00 Open Source Security Concerns 15:28 AI in Code Reviews and Security 20:09 The Role of AI in Cybersecurity 29:25 About Mend.io and Its Tools 32:18 Final Thoughts and Future Discussions Chris Lindsey: https://www.linkedin.com/in/chris-lindsey-39b3915/ Mend.io: https://www.mend.io/ Grizz's Info | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/aarongriswold/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠grizz@finos.org⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Find more info about FINOS: On the web: https://www.finos.org/ Twitter: https://twitter.com/FINOSFoundation LinkedIn: https://www.linkedin.com/company/finosfoundation/ 2024 State of Open Source in Financial Services Download: ⁠https://www.finos.org/state-of-open-source-in-financial-services-2024⁠ FINOS Current Newsletter Here: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.finos.org/newsletter About FINOS FINOS (The Fintech Open Source Foundation) is a nonprofit whose mission is to foster the adoption of open source, open standards, and collaborative software development practices in financial services. It is the center for open source developers and the financial services industry to build new technology projects that have a lasting impact on business operations. As a regulatory compliant platform, the foundation enables developers from these competing organizations to collaborate on projects with a strong propensity for mutualization. It has enabled codebase contributions from both the buy- and sell-side firms and counts over 50 major financial institutions, fintechs and technology consultancies as part of its membership. FINOS is also part of the Linux Foundation, the largest shared technology organization in the world. Get involved and join FINOS as a Member.

In this engaging episode, Mon-Chaio and Andy dive deep into the topic of peer code reviews. They begin by providing historical context, tracing back code review practices to IBM's research in the 70s and 80s, and examine the efficacy of modern-day peer reviews. The hosts debate the true benefits of code reviews, discussing whether they genuinely enhance quality or merely serve as a process ritual. They also explore alternative methods like pair programming, and propose innovative ideas for improving peer review processes, such as detailed walkthroughs and code review checklists. Listeners are encouraged to experiment with different tactics and to consider feedback on their own peer review approaches. Join Mon-Chaio and Andy as they navigate the intricacies of peer reviews and share actionable insights for refining this critical practice in software engineering organizations. References Investigating the effectiveness of peer code review in distributed software development based on objective and subjective data Advances in Software Inspections The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data An empirical study of the impact of modern code reviewpractices on software quality Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise Are Two Heads Better than One? On the Effectiveness of Pair Programming From Async Code Reviews to Co-Creation Patterns

In this episode, Dominik Dorfmeister, TanStack maintainer, joins us to discuss component composition in React. He discusses breaking components apart, managing conditional rendering, and the benefits of early returns in improving code readability and maintainability. Links https://tkdodo.eu/blog/component-composition-is-great-btw https://tkdodo.eu/blog https://github.com/TkDodo https://www.dorfmeister.cc https://x.com/TkDodo https://www.linkedin.com/in/dominik-dorfmeister-8a71051b9 We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Dominik Dorfmeister.

To kick off Elixir Wizards Season 13, The Creator's Lab, we're joined by Zach Daniel, the creator of Igniter and the Ash framework. Zach joins hosts Owen Bickford and Charles Suggs to discuss the mechanics and aspirations of his latest brainchild, Igniter—a code generation and project patching framework designed to revolutionize the Elixir development experience. Igniter isn't just about generating code; it's about generating smarter code. By leveraging tools like Sourcerer and Rewrite, Igniter allows developers to modify source code and batch updates by directly interacting with Elixir's AST instead of regex patching. This approach streamlines new project setup and package installations and enhances overall workflow. They also discuss the strategic implications of Igniter for the broader Elixir community. Zach hopes Igniter will foster a more interconnected and efficient ecosystem that attracts new developers to Elixir and caters to the evolving needs of seasoned Elixir engineers. Topics discussed in this episode: Advanced package installation and code generation improve the developer experience Scripting and staging techniques streamline project updates Innovative methods for smoother installation processes in Elixir packages High-level tools apply direct patches to source code Progressive feature additions simplify the mix phx.new experience Chaining installers and composing tasks for more efficient project setup Continuous improvement in developer experiences to boost Elixir adoption Encourage listeners to collaborate by sharing code generation patterns Introduction of a new mix task aimed at removing the "unless" keyword in preparation for Elixir 1.18 You can learn more in the upcoming book "Building Web Applications with Ash Framework" by Zach and Rebecca Links mentioned: https://smartlogic.io/ https://alembic.com.au/blog/igniter-rethinking-code-generation-with-project-patching https://hexdocs.pm/igniter/readme.html https://github.com/ash-project/igniter https://www.zachdaniel.dev/p/serialization-is-the-secret https://www.zachdaniel.dev/p/welcome-to-my-substack https://ash-hq.org/ https://hexdocs.pm/sourceror/readme.html https://smartlogic.io/podcast/elixir-wizards/s10-e09-hugo-lucas-future-of-elixir-community/ https://github.com/hrzndhrn/rewrite https://github.com/zachdaniel https://github.com/liveshowy/webauthn_components https://hexdocs.pm/elixir/Regex.html https://github.com/msaraiva/vscode-surface https://github.com/swoosh/swoosh https://github.com/erlef/oidcc https://alembic.com.au/ https://www.zachdaniel.dev/ Special Guest: Zach Daniel.

Code reviews can be highly beneficial but tricky to execute well due to the human factors involved, says Adrienne Braganza Tacke, author of *Looks Good to Me: Actionable Advice for Constructive Code Review.* In a recent conversation with *The New Stack*, Tacke identified three challenges teams must address for successful code reviews: ambiguity, subjectivity, and ego.Ambiguity arises when the goals or expectations for the code are unclear, leading to miscommunication and rework. Tacke emphasizes the need for clarity and explicit communication throughout the review process. Subjectivity, the second challenge, can derail reviews when personal preferences overshadow objective evaluation. Reviewers should justify their suggestions based on technical merit rather than opinion. Finally, ego can get in the way, with developers feeling attached to their code. Both reviewers and submitters must check their egos to foster a constructive dialogue.Tacke encourages programmers to first review their own work, as self-checks can enhance the quality of the code before it reaches the reviewer. Ultimately, code reviews can improve code quality, mentor developers, and strengthen team knowledge. Learn more from The New Stack about code reviews:The Anatomy of Slow Code Reviews One Company Rethinks Diff to Cut Code Review TimesHow Good Is Your Code Review Process?Join our community of newsletter subscribers to stay on top of the news and at the top of your game. 

In this episode of the Modern Web Podcast, we sit down with Shashi Lo, Senior UX Engineer at Microsoft and the founder of the Gridiron Survivor project. Shashi shares his approach to mentoring junior developers by helping them bridge the gap between boot camp and their first job in tech. We cover the challenges of onboarding, the importance of code reviews, and how companies can better support new talent by investing in mentorship and training. Shashi also talks about his experience with building a community of learners, the process of de-risking junior candidates, and why companies should be more proactive in nurturing the next generation of developers.  00:00 - Meet Shashi Lo 02:25 - The Gridiron Survivor Project 05:02 - The Importance of Code Reviews 07:25 - Teaching the Basics of Project Communication 09:47 - Code Reviews as a Learning Tool 12:06 - Why Shashi Mentors: Giving Back to the Community 14:26 - The Importance of De-Risking Junior Candidates 16:41 - Building in Public: Transparency and Learning 19:00 - Assessing Candidates for the Gridiron Survivor Project 21:25 - The Power of Simple Coding Tests 23:45 - Scaling Up Skills: From Small Tasks to Big Projects 26:07 - Should Companies Be Doing This? 28:25 - Finding Hidden Gems in the Job Market 30:47 - The Challenges of Filtering Candidates 33:02 - Where to Find Shashi Online 34:38 - Closing Remarks Follow Shashi Lo on Social Media Twitter: https://x.com/shashiwhocodes Linkedin: https://www.linkedin.com/in/shashilo/ Github: https://github.com/shashilo Sponsored by This Dot.

“A lot of problems that we are facing in code review are due to the interface. We are not actually giving feedback to a person, but we are just filling in text boxes and looking at code." Dr. Michaela Greiler is a code review advocate and runs the “Awesome Code Reviews” workshops. In this episode, we discuss the importance of making code reviews awesome. We discuss the common challenges of code reviews, emphasizing the need for a balanced approach that considers both the technical and social aspects. Michaela also shares insights on how to assess and improve code review practices within teams, highlighting the code review quadrant of review speed and feedback value. Our discussion further explores the correlation between code reviews and developer experience, emphasizing the role of psychological safety and a positive feedback culture. Finally, Michaela provides valuable tips on code review tools and techniques, including the use of checklists and strategies for managing context switching. If you're looking to enhance your team's code review process and foster a positive developer experience, listen now and take your code reviews to the next level!   Listen out for: Career Journey - [00:01:53] Awesome Code Review - [00:05:33] Assessing Code Review Practices - [00:11:41] Code Review Speed - [00:18:23] Code Review & Developer Experience - [00:23:31] Improving Code Review Cultural Aspect - [00:29:13] Code Review Tools - [00:35:36] Code Review Techniques - [00:42:11] Context Switching - [00:48:15] 3 Tech Lead Wisdom - [00:54:14] _____ Michaela Greiler's BioFor over 15 years, Michaela Greiler has helped software teams build high-quality software in an efficient and effective way. Her mission is to lead teams to unlock their full potential during company workshops and team coaching sessions. She shares her findings through articles on her blog or in scientific journals, in publications such as freecodecamp and at conferences. She also runs a weekly newsletter that more than 2500 people enjoy. In this newsletter, she shares her thoughts on relevant software engineering topics and helps you stay up-to-date. She's also the host of the software engineering unlocked podcast. Here, she interviews experienced developers, product managers and CTOs about how they build software. Follow Michaela: Awesome Code Reviews – awesomecodereviews.com Personal Website – michaelagreiler.com LinkedIn – linkedin.com/in/mgreiler Twitter – @mgreiler SE Unlocked Podcast – softwareengineeringunlocked.com _____ Our Sponsors Enjoy an exceptional developer experience with JetBrains. Whatever programming language and technology you use, JetBrains IDEs provide the tools you need to go beyond simple code editing and excel as a developer.Check out FREE coding software options and special offers on jetbrains.com/store/#discounts.Make it happen. With code. Manning Publications is a premier publisher of technical books on computer and software development topics for both experienced developers and new learners alike. Manning prides itself on being independently owned and operated, and for paving the way for innovative initiatives, such as early access book content and protection-free PDF formats that are now industry standard.Get a 40% discount for Tech Lead Journal listeners by using the code techlead24 for all products in all formats. Like this episode?Show notes & transcript: techleadjournal.dev/episodes/189.Follow @techleadjournal on LinkedIn, Twitter, and Instagram.Buy me a coffee or become a patron.

Neste episódio do podcast Elixir em Foco, Adolfo Neto, Herminio Torres, Cristine Guadelupe e Zoey Pessanha recebem George Guimarães, um dos fundadores da Plataformatec e atualmente Engineering Manager na Cloudwalk. George compartilha sua experiência com o Elixir e suas funções na Cloudwalk, onde está envolvido em projetos de Acquiring e Agents AI. Ele também discute o impacto do Elixir no campo de aprendizado de máquina, apresentando seu repositório no GitHub, “Awesome Machine Learning and Elixir”, que reúne recursos valiosos para a comunidade de desenvolvedores. Além disso, George fala sobre sua trajetória na Plataformatec e sua experiência como CEO da SourceLevel, uma empresa focada em medir a produtividade de equipes de software. O episódio também aborda sua iniciativa de criar o Protótipo Podcast, onde busca compartilhar o que está acontecendo no ecossistema Elixir, e sua participação em webinars e meetups que promovem a linguagem e suas aplicações. George Guimarães: Perfil no Linkedin https://www.linkedin.com/in/georgeguimaraes/ GitHub https://github.com/georgeguimaraes Twitter  https://x.com/georgeguimaraes   Mastodon @georgeguimaraes@mastodon.social  Rebrandly https://rebrand.ly/georgeguimaraes  CloudWalk https://www.cloudwalk.io/ JIM https://www.jim.com/  Awesome Machine Learning and Elixir A curated list of Machine Learning packages and resources for the Elixir programming language. https://github.com/georgeguimaraes/awesome-machine-learning-elixir  Agilistas estão morrendo! https://bit.ly/4d9LY7Y  Spotify Model Nunca Existiu? Como Assim? https://www.youtube.com/watch?v=1wstlCLmT7w  The Real Real https://www.youtube.com/watch?v=6A6eXFd8olw https://www.youtube.com/watch?v=sTs_4T1ufLY Webinar de Elixir da Source Level em abril de 2020 https://archive.is/o7thF “da quarentena” Protótipo Podcast https://prototipo.tech/ ttps://open.spotify.com/show/5MErBHgSpMATMy6So1UKIh  Castálio Podcast - 141 - George Guimarães - Code Review (2019) https://www.youtube.com/watch?v=mvLL5QS34No Marcelo Park | Posicionamento Estratégico para diferenciação e tracionamento | UNITE 2020 https://www.youtube.com/watch?v=aUcm0bam2fc  Chat do Vagas ponto com https://www.vagas.com.br/ Geovane Fedrecheski PhD, Research Engineer at Inria Paris Egresso Poli https://scholar.google.com/citations?hl=pt-BR&user=TBf0rLkAAAAJ&view_op=list_works&sortby=pubdate https://www.linkedin.com/in/geovane-fedrecheski  https://www.teses.usp.br/teses/disponiveis/3/3142/tde-26072023-074626/pt-br.php https://geonnave.com/  https://x.com/geonnave Venmo https://www.remessaonline.com.br/blog/venmo/  Canal Plataformatec https://www.youtube.com/@PlataformatecCompany A RAG for Elixir https://bitcrowd.dev/a-rag-for-elixir/  How even the simplest RAG can empower your team https://bitcrowd.dev/how-even-the-simplest-RAG-can-empower-your-team/  ElixirLab https://elixirlab.org/  Assista a esta entrevista no YouTube em⁠⁠ ⁠⁠⁠https://www.youtube.com/@elixiremfoco  . Escute a esta entrevista no Spotify em⁠ ⁠https://podcasters.spotify.com/pod/show/elixiremfoco   Associe-se à Erlang Ecosystem Foundation em⁠⁠ ⁠⁠⁠https://bit.ly/3Sl8XTO⁠⁠ ⁠⁠⁠ . O site da fundação é⁠⁠ ⁠⁠⁠https://bit.ly/3Jma95g ⁠⁠  Nosso site é⁠⁠ ⁠⁠⁠https://elixiremfoco.com   Estamos no X em @elixiremfoco⁠⁠ ⁠⁠⁠https://x.com/elixiremfoco  Nosso email é ⁠⁠elixiremfoco@gmail.com  .

Guest: Abraham Aranguren, Managing Director at 7ASecurity [@7aSecurity]On LinkedIn | https://www.linkedin.com/in/abrahamaranguren/____________________________Hosts: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________Episode NotesIn this On Location episode recorded in Lisbon at the OWASP AppSec Global event, Sean Martin engages in a comprehensive discussion with Abraham Aranguren, a cybersecurity trainer skilled at hacking IoT, iOS, and Android devices. The conversation delves into the intricacies of mobile application security, touching on both the technical and procedural aspects that organizations must consider to build and maintain secure apps.Abraham Aranguren, known for his expertise in cybersecurity training, shares compelling insights into identifying IoT vulnerabilities without physically having the device. By reverse engineering applications, one can uncover potential security flaws and understand how apps communicate with their IoT counterparts. For instance, Aranguren describes exercises where students analyze mobile apps to reveal hardcoded passwords and unsecured Wi-Fi connections used to manage devices like drones.A significant portion of the discussion revolves around real-world examples of security lapses in mobile applications. Aranguren details an incident involving a Chinese government app that harvests personal data from users' phones, highlighting the serious privacy implications of such vulnerabilities. Another poignant example is Hong Kong's COVID-19 contact-tracing app, which stored sensitive user information insecurely, revealing how even high-budget applications can suffer from critical security flaws if not properly tested.Sean Martin, drawing from his background in software quality assurance, emphasizes the importance of establishing clear, repeatable processes and workflows to ensure security measures are consistently applied throughout the development and deployment phases. He and Aranguren agree that while developers need to be educated in secure coding practices, organizations must also implement robust processes, including code reviews, automated tools for static analysis, and third-party audits to identify and rectify potential vulnerabilities.Aranguren stresses the value of pentests, noting that organizations often show significant improvement over multiple tests. He shares experiences of clients who, after several engagements, greatly reduced the number of exploitable vulnerabilities. Regular, comprehensive testing, combined with a proactive approach to fixing identified issues, helps create a robust security posture, ultimately making applications harder to exploit and dissuading potential attackers.For businesses developing apps, this episode underscores the necessity of integrating security from the ground up, continuously educating developers, enforcing centralized security controls, and utilizing pentests as a tool for both validation and education. The ultimate goal is to make applications resilient enough to deter attackers, ensuring both the business and its users are protected.Be sure to follow our Coverage Journey and subscribe to our podcasts!____________________________Follow our OWASP AppSec Global Lisbon 2024 coverage: https://www.itspmagazine.com/owasp-global-2024-lisbon-application-security-event-coverage-in-portugalOn YouTube:

Guest: Abraham Aranguren, Managing Director at 7ASecurity [@7aSecurity]On LinkedIn | https://www.linkedin.com/in/abrahamaranguren/____________________________Hosts: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martinMarco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society PodcastOn ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli____________________________Episode NotesIn this On Location episode recorded in Lisbon at the OWASP AppSec Global event, Sean Martin engages in a comprehensive discussion with Abraham Aranguren, a cybersecurity trainer skilled at hacking IoT, iOS, and Android devices. The conversation delves into the intricacies of mobile application security, touching on both the technical and procedural aspects that organizations must consider to build and maintain secure apps.Abraham Aranguren, known for his expertise in cybersecurity training, shares compelling insights into identifying IoT vulnerabilities without physically having the device. By reverse engineering applications, one can uncover potential security flaws and understand how apps communicate with their IoT counterparts. For instance, Aranguren describes exercises where students analyze mobile apps to reveal hardcoded passwords and unsecured Wi-Fi connections used to manage devices like drones.A significant portion of the discussion revolves around real-world examples of security lapses in mobile applications. Aranguren details an incident involving a Chinese government app that harvests personal data from users' phones, highlighting the serious privacy implications of such vulnerabilities. Another poignant example is Hong Kong's COVID-19 contact-tracing app, which stored sensitive user information insecurely, revealing how even high-budget applications can suffer from critical security flaws if not properly tested.Sean Martin, drawing from his background in software quality assurance, emphasizes the importance of establishing clear, repeatable processes and workflows to ensure security measures are consistently applied throughout the development and deployment phases. He and Aranguren agree that while developers need to be educated in secure coding practices, organizations must also implement robust processes, including code reviews, automated tools for static analysis, and third-party audits to identify and rectify potential vulnerabilities.Aranguren stresses the value of pentests, noting that organizations often show significant improvement over multiple tests. He shares experiences of clients who, after several engagements, greatly reduced the number of exploitable vulnerabilities. Regular, comprehensive testing, combined with a proactive approach to fixing identified issues, helps create a robust security posture, ultimately making applications harder to exploit and dissuading potential attackers.For businesses developing apps, this episode underscores the necessity of integrating security from the ground up, continuously educating developers, enforcing centralized security controls, and utilizing pentests as a tool for both validation and education. The ultimate goal is to make applications resilient enough to deter attackers, ensuring both the business and its users are protected.Be sure to follow our Coverage Journey and subscribe to our podcasts!____________________________Follow our OWASP AppSec Global Lisbon 2024 coverage: https://www.itspmagazine.com/owasp-global-2024-lisbon-application-security-event-coverage-in-portugalOn YouTube:

Hands-On als Engineering Manager: Yay or Nei? Leute, die einmal das Handwerk des Software-Engineerings professionell ausgeübt haben und dann ins Management wechseln, haben oft den Drang, ihr Hardskills nicht zu verlieren. Doch durch den neuen Job sind die Prioritäten nun andere: People Leadership, das Team effizient halten, Strategie und Roadmaps entwickeln. Wo bleibt denn da noch die Zeit am Code mitzuarbeiten?Wir stellen uns die Frage: Warum ist das so? Muss das sein, dass Manager weiterhin technisch sind? Und wenn ja, welche Gefahren birgt das? Aber auch: Wie können wir es möglich machen, obwohl unser Kalender sagt, dass die Woche mit Meetings bereits belegt ist?Darum geht es in dieser Episode. Viel Spaß!Bonus: Auch Manager laufen auf Kaffee.Das schnelle Feedback zur Episode:

Key Insights:Importance of Code Reviews: Code reviews are essential for error detection, understanding new features, adhering to coding standards, and ensuring only reviewed code is deployed.Emotional Impact: Emotional dynamics play a significant role, with 30% of developers reviewing code from less favored colleagues, which can lead to biased judgments and negative feelings.Striving for Objectivity: Despite personal feelings, approximately 76% of developers strive for objectivity to maintain professionalism.Impact of Developer Experience: The experience level of a developer also influences the depth of code reviews and the manner in which feedback is provided.Perceptions Formed: Reviewers' perceptions of code quality can affect their views on the author's skills or character.Strategies to Mitigate Bias: The episode outlines multiple strategies to reduce bias in code reviews, such as involving multiple reviewers, standardizing review criteria, and implementing anonymous reviews.Additional Resources: Read the full paper called "How social interactions can affect Modern Code Review"Visit awesomecodereviews.com to discover Dr. McKayla's latest article on the top 10 code review techniques and methodologies, including systematic approaches like using checklists and change-impact analysis.Conclusion: The podcast sheds light on both the positive and negative impacts of human factors in code reviews and emphasizes the need for strategies to minimize bias, enhancing both code quality and team dynamics.

In Office Hours Episode 6, SmartLogic Developers Anna Dorigo and Bilal Hankins join Elixir Wizards Sundi and Dan to discuss their experiences maintaining a decade-old Ruby on Rails codebase. They delve into the critical importance of deeply understanding the codebase, keeping dependencies current, and adapting to the original application's evolving priorities and design choices. The conversation spans a range of topics, including accessibility, testing, monitoring, and the challenges of deploying database migrations in production environments. The guests share effective strategies for sustaining and enhancing older codebases, such as employing automated tools, performing code audits, and adhering to clean coding principles. Key topics discussed in this episode: Grasping the legacy codebase and its historical context Overcoming accessibility issues in older applications Safe dependency management and upgrades The effects of application scaling on database performance The critical role of comprehensive test suites in legacy systems Using tools like Sentry for error tracking and performance monitoring The benefits of automated security and dependency scans Juggling client needs with budget constraints Local simulation techniques for large datasets The value of iterative code reviews and maintaining clean code Utilizing git history for contextual understanding Onboarding strategies for legacy projects Removing obsolete code and avoiding "magic numbers" Importance of descriptive naming for better code clarity Leveraging a rich repository of example code for learning and reference Proactive code audits to anticipate issues Managing pull request sizes for smoother reviews Communicating effectively about upgrades and potential impacts Strategies for handling large databases efficiently Ensuring thorough test coverage Keeping open lines of communication with clients regarding ongoing maintenance Links mentioned: COBOL programming language https://developer.ibm.com/languages/cobol/ Ruby on Rails https://rubyonrails.org/ ARIA Rules (Accessible Rich Internet Applications) https://www.w3.org/TR/using-aria/ Shawn Vo on Elixir as a Competitive Advantage https://smartlogic.io/podcast/elixir-wizards/s5e5-vo/ Bundler Audit Ruby Gem https://rubygems.org/gems/bundler-audit/ Sentry application monitoring and error tracking software  https://sentry.io/ Dependabot Github automated dependency updates Mix hex.audit https://hexdocs.pm/hex/Mx.Tasks.Hex.Audit.html Git Blame https://git-scm.com/docs/git-blame Cow hoof trimming videos - The Hoof GP on YouTube (TW graphic imagery) Special Guests: Anna Dorigo and Bilal Hankins.

In this episode of WPwatercooler, titled “To Bot or Not to Bot,” hosts Jason Tucker, Sé Reed, and Jason Cosper dive into the implications and ethical considerations of utilizing bots, specifically ChatGPT, in the realm of WordPress development. The discussion kicks off with an anecdote from Sé, who experimented with using ChatGPT to solve a coding problem related to grouping WordPress pages in the admin area. This led to a broader conversation about the reliability, safety, and future role of AI-generated code in production environments. The episode touches on themes such as the balance between automation and manual oversight, the evolving landscape of WordPress plugin development, and the importance of adhering to coding standards. Throughout, the hosts share personal experiences, concerns, and the potential they see in integrating AI tools like ChatGPT into their workflows, all while maintaining a critical eye on the implications for developers and the wider WordPress community. Links https://github.com/WordPress/WordPress-Coding-Standards https://fedi.simonwillison.net/@simon/112147026040154264 https://labs.perplexity.ai https://huggingface.co/docs/transformers/model_doc/code_llama https://unmaintained.tech Chapters 00:00 Intro 00:16 Introducing the Hosts and Their Quirky Banter 01:03 Inspiration from Discord: Tackling WordPress Page Chaos 06:18 The Quest for Better Page Organization: A Plugin Solution 08:40 ChatGPT to the Rescue: Crafting a Custom Plugin 10:54 Testing and Tweaking: The Plugin's Journey to GitHub 12:28 The Ethical Dilemma: Using Bots for Code Generation 14:34 Learning to Code with ChatGPT: A Personal Journey 17:59 Ensuring Code Quality: The Role of Large Language Models 20:44 The Future of Plugin Development: Community Collaboration 22:00 The Open Source Dilemma: Plugins, Patches, and the Power of Collaboration 23:00 Navigating the Free vs. Pro Plugin Conundrum 23:47 The No Maintenance Intended Tag: A New Approach to Open Source 24:37 The Challenges of Community Contributions and Code Reviews 25:06 Harnessing AI for Code Generation: A New Frontier 29:49 The Trust Crisis in Plugin Repositories 35:01 AI vs. Traditional Coding: Navigating the New Landscape 39:06 The Ethical Dilemma of Using AI-Generated Code 43:39 Collaborative Coding with AI: The Future of Development? What is WPwatercooler? WPwatercooler is streamed live and recorded as the self-titled show on the WPwatercooler Network. Our objective with the show since the beginning has been to help people in this industry have a place to hear people, much like themselves, talk about the technologies and methods we all use on a daily basis. We named WPwatercooler to be that, the watercooler that WordPress folks can gather around and participate in the conversation, or just sit back and learn from the discussion. Our listeners and contributors come from all walks of life and all backgrounds. We strive to make this place as welcoming and accessible as we can. Learn more at https://www.wpwatercooler.com/wpwatercooler What is Dev Branch? Dev Branch is streamed live and recorded monthly on the first friday of the month as the developer-focused discussions of the WPwatercooler Network. Dev Branch is released on its own podcast feed and made available live and on-demand in video format on Facebook, YouTube, LinkedIn, and Twitch. Learn more at https://www.wpwatercooler.com/devbranch

The Elixir Wizards Podcast is back with Season 12 Office Hours, where we talk with the internal SmartLogic team about the stages of the software development lifecycle. For the season premiere, "Testing 1, 2, 3," Joel Meador and Charles Suggs join us to discuss the nuances of software testing. In this episode, we discuss everything from testing philosophies to test driven development (TDD), integration, and end-user testing. Our guests share real-world experiences that highlight the benefits of thorough testing, challenges like test maintenance, and problem-solving for complex production environments. Key topics discussed in this episode: How to find a balance that's cost-effective and practical while testing Balancing test coverage and development speed The importance of clear test plans and goals So many tests: Unit testing, integration testing, acceptance testing, penetration testing, automated vs. manual testing Agile vs. Waterfall methodologies Writing readable and maintainable tests Testing edge cases and unexpected scenarios Testing as a form of documentation and communication Advice for developers looking to improve testing practices Continuous integration and deployment Links mentioned: https://smartlogic.io/ Watch this episode on YouTube! youtu.be/unx5AIvSdc Bob Martin “Clean Code” videos - “Uncle Bob”: http://cleancoder.com/ JUnit 5 Testing for Java and the JVM https://junit.org/junit5/ ExUnit Testing for Elixir https://hexdocs.pm/exunit/ExUnit.html Code-Level Testing of Smalltalk Applications https://www.cs.ubc.ca/~murphy/stworkshop/28-7.html Agile Manifesto https://agilemanifesto.org/ Old Man Yells at Cloud https://i.kym-cdn.com/entries/icons/original/000/019/304/old.jpg TDD: Test Driven Development https://www.agilealliance.org/glossary/tdd/ Perl Programming Language https://www.perl.org/ Protractor Test Framework for Angular and AngularJS protractortest.org/#/ Waterfall Project Management https://business.adobe.com/blog/basics/waterfall CodeSync Leveling up at Bleacher Report A cautionary tale - PETER HASTIE https://www.youtube.com/watch?v=P4SzZCwB8B4 Mix ecto.dump https://hexdocs.pm/ectosql/Mix.Tasks.Ecto.Dump.html Apache JMeter Load Testing in Java https://jmeter.apache.org/ Pentest Tools Collection - Penetration Testing https://github.com/arch3rPro/PentestTools The Road to 2 Million Websocket Connections in Phoenix https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections Donate to Miami Indians of Indiana https://www.miamiindians.org/take-action Joel Meador on Tumblr https://joelmeador.tumblr.com/ Special Guests: Charles Suggs and Joel Meador.

Lex chats with Richard Ma, CEO of Quantstamp -a leading blockchain security company. Richard kicks off by discussing the origins of the company and the importance of security in the blockchain space. He explains that the idea for Quantstamp came after he invested in Ethereum and witnessed the hack of the DAO, which prompted him to focus on the security side of Ethereum. Richard describes how Quantstamp conducts audits of blockchain projects, identifying vulnerabilities and providing recommendations for improvement. He emphasizes the importance of reading audit reports and understanding the risks associated with projects. Richard also discusses different types of adversaries in the blockchain space, including nation-state actors, developers seeking recognition, and financially motivated hackers. He believes that while established projects will become more secure over time, new experimental projects will always carry some level of risk. Richard suggests that AI-based debuggers could help improve security auditing in the future. He highlights EigenLayer, ZK-rollups, and the development on Solana as exciting sectors to watch in the coming years. MENTIONED IN THE CONVERSATION Quantstamps's Website: https://bit.ly/3Iv6zX4Richard's LinkedIn: https://bit.ly/3IvaxyO Topics: blockchain, security, audit, hacking, hacks, crypto, cryptocurrency, digital assets, Web3, DeFi Companies: Quantstamp, Ethereum, MakerDAO, Compound, EigenLayer ABOUT THE FINTECH BLUEPRINT 

The inspiration for this was a piece about the art of the good code review. Throughout my career, I've seen code reviews grow and change. From formal meetings to automated notifications and asynchronous discussions to complete lip service to the process. I'd like to think that most organizations are beyond the latter and there is some sort of review beyond the developer, but I still see a lack of other eyes looking at code before it's deployed, especially database code. The article above opens with the idea of why we review code. The main reason is to create ownership, or more specifically, shared ownership. I had never thought of it in these terms, even though I think the ideas of standards and patterns are certainly shared items. Having everyone take ownership not only keeps quality high but could help you share knowledge and also ensure everyone feels a responsibility to safeguard all the code. This also helps everyone keep an eye on the larger picture of the entire codebase. Read the rest of The Art of the Code Review

In this conversation, Ben interviews Caleb Porzio, the creator of AlpineJS and Laravel Livewire. The discussion ranges from discussions about life in general to specific testing practices and which notebook Caleb uses.LinksTuple.app - The best app for pair programmingAlpineJS Laravel Livewire Caleb's VSCode Course TakeawaysApply core truths to life outside of programming.Find ways to make difficult tasks easier.Change your environment to support your goals.Value tests as much as, if not more than, the code itself.Keep methods and functions short for better code quality.Embrace your strengths and delegate tasks that don't bring you joy.Focus on the meaty tasks that excite you.Consider rewrites carefully and prioritize other solutions first.Pull down unfamiliar code and interact with it to understand it better.Start the day with tasks that align with your goals and priorities.Chapters(00:00) - Introduction and Background (03:51) - Overview of LiveWire and Alpine (12:09) - Caleb's Programming Style (20:09) - Functional vs Object-Oriented Programming (25:39) - The Appeal of Functional Programming (32:01) - The Challenges of Learning Object-Oriented Programming (33:06) - Memory Allocation and Functional Languages (36:30) - Starting Complicated Projects (40:10) - Writing Blog Posts as Problem-Solving (42:30) - Core Beliefs (48:21) - Materials (49:20) - Getting into the Zone (51:14) - The Value of Tests Over Code (55:27) - Transitioning to Non-Typical Apps (01:03:00) - Radical Practices at Tuple (01:05:50) - Managing Pull Requests and Code Reviews (01:06:33) - Starting the Day and Prioritizing Tasks (01:07:41) - Balancing Maintenance and Long-Term Goals (01:09:52) - Finding Motivation for Maintenance Tasks (01:10:50) - Embracing Strengths and Delegating Weaknesses (01:11:46) - Continuous Improvement and Learning (01:14:19) - Favorite Tools and Productivity Hacks (01:19:07) - Core Beliefs and Values in Coding (01:21:19) - Benefits of Short Methods and Single File Principle (01:21:57) - Approaching Unfamiliar Code (01:22:51) - The Pros and Cons of Rewrites (01:23:46) - Final Thoughts and Passion for Coding

“A lot of developers tie their self-worth to their code. Being able to let go of your ego and understanding the feedback is based on the code, and it has nothing to do with anything about me. It's just the code.” Adrienne Tacke is a software engineer, keynote speaker, and the author of the upcoming book “Looks Good To Me”. In this episode, we discuss code reviews and why it is an essential part of the software development process. Adrienne discusses the importance and benefits of code review, the common code review workflow and the different roles involved, how to provide effective code review comments, and why we should leverage on code review tools and automation. She also provides tips on how to speed up our code review turnaround time.   Listen out for: Career Journey - [00:03:31] Looks Good to Me (LGTM) - [00:09:05] Code Review Story - [00:12:24] Importance of Code Review - [00:15:38] Code Review Benefits - [00:20:27] Code Review Role: Author - [00:25:50] Code Review Role: Reviewer - [00:32:42] Code Review Role: The Team - [00:38:41] Code Review Tools & Automation - [00:45:53] Effective Code Review Comments - [00:51:44] Code Review Turnaround - [00:57:45] 3 Tech Lead Wisdom - [01:04:56] _____ Adrienne Tacke's BioAdrienne is a Filipina software engineer, keynote speaker, author of the best-selling book Coding for Kids: Python, and a LinkedIn Learning instructor who's reached over 65,000 learners with her courses (a number she'll likely surpass when you read this). She is writing Looks Good To Me: Constructive Code Reviews, a labor of love that she hopes will improve code reviews everywhere. Perhaps most important, however, is that she spends way too much money on desserts and ungodly amounts of time playing Age of Empires II. Follow Adrienne: LinkedIn – linkedin.com/in/adriennetacke Twitter / X – @AdrienneTacke Instagram – @adriennetacke Website – adrienne.io _____ Our Sponsors Miro is your team's visual workspace to connect, collaborate, and create innovations together, from anywhere. Sign up today at miro.com/podcast and get your first 3 Miro boards free forever. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/159. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

On today's episode, Elixir Wizards Owen Bickford and Dan Ivovich compare notes on building web applications with Elixir and the Phoenix Framework versus Ruby on Rails. They discuss the history of both frameworks, key differences in architecture and approach, and deciding which programming language to use when starting a project. Both Phoenix and Rails are robust frameworks that enable developers to build high-quality web apps—Phoenix leverages functional programming in Elixir and Erlang's networking for real-time communication. Rails follows object-oriented principles and has a vast ecosystem of plug-ins. For data-heavy CRUD apps, Phoenix's immutable data pipelines provide some advantages. Developers can build great web apps with either Phoenix or Rails. Phoenix may have a slight edge for new projects based on its functional approach, built-in real-time features like LiveView, and ability to scale efficiently. But, choosing the right tech stack depends heavily on the app's specific requirements and the team's existing skills. Topics discussed in this episode: History and evolution of Phoenix Framework and Ruby on Rails Default project structure and code organization preferences in each framework Comparing object-oriented vs functional programming paradigms CRUD app development and interaction with databases Live reloading capabilities in Phoenix LiveView vs Rails Turbolinks Leveraging WebSockets for real-time UI updates Testing frameworks like RSpec, Cucumber, Wallaby, and Capybara Dependency management and size of standard libraries Scalability and distribution across nodes Readability and approachability of object-oriented code Immutability and data pipelines in functional programming Types, specs, and static analysis with Dialyzer Monkey patching in Ruby vs extensible core language in Elixir Factors to consider when choosing between frameworks Experience training new developers on Phoenix and Rails Community influences on coding styles Real-world project examples and refactoring approaches Deployment and dev ops differences Popularity and adoption curves of both frameworks Ongoing research into improving Phoenix and Rails Links Mentioned in this Episode: SmartLogic.io (https://smartlogic.io/) Dan's LinkedIn (https://www.linkedin.com/in/divovich/) Owen's LinkedIn (https://www.linkedin.com/in/owen-bickford-8b6b1523a/) Ruby https://www.ruby-lang.org/en/ Rails https://rubyonrails.org/ Sams Teach Yourself Ruby in 21 Days (https://www.overdrive.com/media/56304/sams-teach-yourself-ruby-in-21-days) Learn Ruby in 7 Days (https://www.thriftbooks.com/w/learn-ruby-in-7-days---color-print---ruby-tutorial-for-guaranteed-quick-learning-ruby-guide-with-many-practical-examples-this-ruby-programming-book--to-build-real-life-software-projects/18539364/#edition=19727339&idiq=25678249) Build Your Own Ruby on Rails Web Applications (https://www.thriftbooks.com/w/build-your-own-ruby-on-rails-web-applications_patrick-lenz/725256/item/2315989/?utm_source=google&utm_medium=cpc&utm_campaign=low_vol_backlist_standard_shopping_customer_acquisition&utm_adgroup=&utm_term=&utm_content=593118743925&gad_source=1&gclid=CjwKCAiA1MCrBhAoEiwAC2d64aQyFawuU3znN0VFgGyjR0I-0vrXlseIvht0QPOqx4DjKjdpgjCMZhoC6PcQAvD_BwE#idiq=2315989&edition=3380836) Django https://github.com/django Sidekiq https://github.com/sidekiq Kafka https://kafka.apache.org/ Phoenix Framework https://www.phoenixframework.org/ Phoenix LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#content Flask https://flask.palletsprojects.com/en/3.0.x/ WebSockets API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API WebSocket connection for Phoenix https://github.com/phoenixframework/websock Morph Dom https://github.com/patrick-steele-idem/morphdom Turbolinks https://github.com/turbolinks Ecto https://github.com/elixir-ecto Capybara Testing Framework https://teamcapybara.github.io/capybara/ Wallaby Testing Framework https://wallabyjs.com/ Cucumber Testing Framework https://cucumber.io/ RSpec https://rspec.info/

This week, the Elixir Wizards are joined by Yohana Tesfazgi and Wes Bos to compare notes on the experience of learning Elixir vs. JavaScript as your first programming language. Yohana recently completed an Elixir apprenticeship, and Wes Bos is a renowned JavaScript educator with popular courses for beginner software developers. They discuss a variety of media and resources and how people with different learning styles benefit from video courses, articles, or more hands-on projects. They also discuss the current atmosphere for those looking to transition into an engineering career and how to stick out among the crowd when new to the scene. Topics Discussed in this Episode Pros and cons of learning Elixir as your first programming language Materials and resources for beginners to JavaScript and Elixir Projects and methods for learning Elixir with no prior knowledge Recommendations for sharpening and showcasing skills How to become a standout candidate for potential employers Soft skills like communication translate well from other careers to programming work Learning subsequent languages becomes more intuitive once you learn your first How to decide which library to use for a project How to build an online presence and why it's important Open-source contributions are a way to learn from the community Ship early and often, just deploying a default Phoenix app teaches deployment skills Attend local meetups and conferences for mentoring and potential job opportunities Links Mentioned https://syntax.fm/ https://fly.io/ https://elixirschool.com/en Syntax.fm: Supper Club × How To Get Your First Dev Job With Stuart Bloxham (https://syntax.fm/show/667/supper-club-how-to-get-your-first-dev-job-with-stuart-bloxham) Quinnwilton.com (https://quinnwilton.com/) https://github.com/pallets/flask https://wesbos.com/courses https://beginnerjavascript.com/ Free course: https://javascript30.com/ https://pragmaticstudio.com/ https://elixircasts.io/ https://grox.io/ LiveView Mastery YouTube Channel (https://www.youtube.com/channel/UC7T19hPLqQ-Od3Rb3T2OX1g) Contact Yohana: yytesfazgi@gmail.com

On Security Now, Steve Gibson and Leo Laporte discuss how HackerOne's breach bounty payouts have surpassed $300 million total, with AI seen as a top emerging target by 55% of hackers surveyed. For the full episode go to: https://twit.tv/sn/946 Hosts: Leo Laporte and Steve Gibson You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/ Sponsor: GO.ACILEARNING.COM/TWIT

On Security Now, Steve Gibson and Leo Laporte discuss how HackerOne's breach bounty payouts have surpassed $300 million total, with AI seen as a top emerging target by 55% of hackers surveyed. For the full episode go to: https://twit.tv/sn/946 Hosts: Leo Laporte and Steve Gibson You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/ Sponsor: GO.ACILEARNING.COM/TWIT

On Security Now, Steve Gibson and Leo Laporte discuss how HackerOne's breach bounty payouts have surpassed $300 million total, with AI seen as a top emerging target by 55% of hackers surveyed. For the full episode go to: https://twit.tv/sn/946 Hosts: Steve Gibson and Leo Laporte You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/ Sponsor: GO.ACILEARNING.COM/TWIT

“We need to change our ways of working to give importance to the work quality that we deliver, ensure we keep raising our bar, and pass it on to the next generation of developers." Srihari Sridharan is a software architect and the author of “Craft Your Code”. In this episode, we discussed software craftsmanship and how to become better software engineers. Srihari first began by sharing the relationship between software craftsmanship and high-quality code. He described some practices for improving code quality, such as establishing coding standards, improving code readability, doing effective code review, and managing technical debt. He also explained the importance of software engineers understanding different architectural styles and domain knowledge. Srihari also shared strategies for creating high-performing teams by establishing psychological safety and trust.   Listen out for: Career Journey - [00:03:08] Bridging the Students Gap with Industry - [00:06:11] Writing “Craft Your Code” - [00:09:36] Software Craftsmanship and High Quality Code - [00:12:18] Root Causes of Low Quality Code - [00:15:26] Coding Standards - [00:20:15] Code Aesthetics - [00:24:17] Code Readability - [00:28:09] Tabs vs Spaces - [00:32:31] Code Review - [00:34:12] Managing Technical Debt - [00:39:36] Psychological Safety & Trust - [00:46:23] Mind Maps - [00:52:09] Architecture & Domain Knowledge - [00:54:00] 3 Tech Lead Wisdom - [01:02:33] _____ Srihari Sridharan's BioSrihari Sridharan is a Software Architect and Engineer with a hands-on approach. He is a speaker, conducting courses and delivering talks on software craftsmanship and writing clean code. Srihari's areas of expertise encompass refactoring, design patterns, enterprise application architectural patterns, integration patterns, and cloud-native design patterns. Srihari is also a reviewer and a senior technical proof-reader for Manning Publications Co, and he serves as a member of the ‘Board of Studies - Department of Information Technology' at B.S Abdur Rahman Crescent Institute of Science & Technology. Residing in Chennai with his wife Swathy and son Advaith, Srihari enjoys spending quality time with his family. In his leisure time, he loves playing cricket, writing blogs, reading books, and cooking. Follow Srihari: Website – https://topmate.io/srihari_sridharan LinkedIn – linkedin.com/in/srihari-sridharan/ _____ Our Sponsors Miro is your team's visual workspace to connect, collaborate, and create innovations together, from anywhere.Sign up today at miro.com/podcast and get your first 3 Miro boards free forever. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/152 Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

Eine Code-Änderung zieht immer ein Code-Review nach sich und löst Wartezeiten aus. Aber muss das so sein? In dieser Episode sprechen Anja, Martin E. und Martin O. anlässlich des Prinzips „Ship“, „Show“ oder „Ask“ von Rouan Wilsenach über Code-Reviews. Dazu fragten sie Kolleginnen und Kollegen nach ihren Meinungen und Praxiserfahrungen und diskutieren auf dieser Grundlage gemeinsam, wann und in welchem Umfang Pull Requests und Code-Reviews sinnvoll und hilfreich sind. Außerdem beleuchten sie, was das mit Vertrauen im Team, Qualitätssicherung und Feedback zu tun hat, und zeigen, wie viele unterschiedliche Bereiche Code-Reviews streifen.

Why effective code reviews can bring many benefits to data science teams, the origin story of the sketch package to transpile R code to JavaScript, and a primer on error handling in both R and Python. Episode Links This week's curator: Colin Fay - @_ColinFay (https://twitter.com/_ColinFay) (Twitter) Pull Requests, Code Review, and The Art of Requesting Changes (https://matthewrkaye.com/posts/series/doing-data-science/2023-04-14-code-review/code-review.html) Sketch Package looks to add JavaScript to R packages (https://www.r-consortium.org/blog/2023/04/26/sketch-package-looks-to-add-javascript-to-r-packages) Error Handling in R and Python (https://towardsdatascience.com/error-handling-in-r-and-python-5a4d60f3fba6) Entire issue available at rweekly.org/2023-W18 (https://rweekly.org/2023-W18.html) Supplement Resources What they forgot to teach you about R https://rstats.wtf Sketch - Interactive sketches in R https://github.com/kcf-jackson/sketch {purrr} safely https://purrr.tidyverse.org/reference/safely.html quickemu - Quickly create and run optimised Windows, macOS and Linux desktop virtual machines https://github.com/quickemu-project/quickemu Supporting the show Use the contact page at https://rweekly.fireside.fm/contact to send us your feedback Get a New Podcast App and send us a boost! https://podcastindex.org/apps?elements=Boostagrams%2CValue Support creators with boostagrams using Podverse and Alby: https://blog.podverse.fm/support-creators-with-boostagrams-and-streaming-sats-using-podverse-and-alby/ A new way to think about value: https://value4value.info Get in touch with us on social media Eric Nantz: @theRcast (https://twitter.com/theRcast) (Twitter) and @rpodcast@podcastindex.social (https://podcastindex.social/@rpodcast) (Mastodon) Mike Thomas: @mike_ketchbrook (https://twitter.com/mike_ketchbrook) (Twitter) and @mike_thomas@fosstodon.org (https://fosstodon.org/@mike_thomas) (Mastodon)

Dodo besucht Elton in Hamburg! Das nutzen die beiden, um euch mitzunehmen in einen mehr oder weniger typischen Arbeitstag. Dodo ist Senior Data Scientist bei Opinary und Elton arbeitet als Senior Software Engineer bei Orbit Ventures. Dabei werfen die beiden selbstverständlich mit Begriffen aus dem Tech-Jargon um sich und erklären Worte aus der agilen Welt wie Ticket, Backlog, Weekly und Refinement. Es geht um Bugs, QA und Freitags-Deployments. Es geht auch um Cloud, Code Reviews und Retrospektiven. Zur Krönung des Abends findet ein Tech Meetup statt, das den eigentlichen Grund von Dodos Besuch darstellt: Denn sie ist Hauptspeaker und erzählt von einem spannenden Case, an dem sie gearbeitet hat. Hört rein und werft einen Blick in die Arbeitswelt der beiden! Links: Opinary https://opinary.com/ Orbit Ventures https://orbitdigital.de/ Techsnack Blog https://techsnack.orbitdigital.de/ Dodos Blog Beitrag zum Thema das Meetups: https://cloud.google.com/blog/topics/developers-practitioners/opinary-generates-recommendations-faster-cloud-run?hl=en Das Meetup https://www.meetup.com/de-DE/tech-x-orbit/events/291355210/ Die Meetup Gruppe https://www.meetup.com/de-DE/tech-x-orbit/ Agile Arbeitsweisen https://digitaleneuordnung.de/blog/agiles-arbeiten/

Earn additional income by sharing your opinion on userinterviews.com!Episode Resources:Alexander's TwitterAlexander's ResearchAwesome Code ReviewsPapers:An exploratory study on confusion in code reviewsEmotions and Perceived Productivity of Software Developers at the WorkplaceRecognizing developers' emotions while programmingGendered Experiences of Software Engineers During the COVID-19 CrisisDeveloper experience research paper  About Alexander SerebrenikAlexander is a Full Professor of Social Software Engineering at the Software Engineering and Technology cluster of Eindhoven University of Technology (TU/e). Alexander's research goal is to facilitate evolution of software by taking into account social aspects of software development.

Linh and Dimitri share their frustrations with Fedex… slowly… Check out Linh's app, Not Phở, a cook that introduces the user to Vietnamese cuisine, especially dishes other than Phở. It runs on iPhone, iPad, and Mac. It also have an iMessage sticker pack so that you can share with all your friends and family. App Store: https://apps.apple.com/app/apple-store/id1525104124?pt=14724&ct=Podcast&mt=8 Website: https://notpho.app Follow us on Twitter: https://twitter.com/LinhAndDimiChan Follow Dimitri on Twitter: https://twitter.com/dimitribouniol Follow Linh on Twitter: https://twitter.com/linhbouniol Follow Linh on Instagram: https://www.instagram.com/linhbouniol

Patrick and I are always stressing the importance of code reviews and collaboration when developing.  On Freund, co-founder & CEO at Wilco, is super familiar with how code review processes can go well, or become a hinderance. In today's episode with us, he shares his unique perspective on code reviews and maintaining high code quality!00:00:56 Introductions00:01:38 On's first exposure to tech00:06:04 Game development adventures00:11:12 The difference between university and real-world experiences00:17:43 A context switch question00:24:41 Points of frustration00:30:53 Build versus Buy complications00:32:06 Code reviews00:39:58 Quality of code00:45:12 Using callouts for the right reasons00:49:57 Code reviews can be too late sometimes00:52:11 Using social interaction as pre-review orientation00:57:03 How not to use code reviews01:01:35 Where Wilco helps programmers learn01:09:11 Working in Wilco01:11:49 FarewellsResources mentioned in this episode:Links: On Freund:Linkedin: https://www.linkedin.com/in/onfreund Wilco: Website: https://www.trywilco.com/ Twitter: https://twitter.com/trywilco Linkedin: https://www.linkedin.com/company/trywilco  References:Micro-Adventure:https://en.wikipedia.org/wiki/Micro_Adventure  If you've enjoyed this episode, you can listen to more on Programming Throwdown's website: https://www.programmingthrowdown.com/ Reach out to us via email: programmingthrowdown@gmail.com You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Make code reviews your superpower at awesomecodereviews.com!About Michael LynchMichael is a software engineer and entrepreneur. He has launched several businesses after leaving Google in 2018. His hardware/software business, called TinyPilot, lets you control any computer remotely and has brought him the most success so far.Episode Resources:Michael's TwitterHow to Do Code Reviews Like a HumanTiny Pilot

Chris Toomey is back! (For an episode.) He talks about what he's been up to since handing off the reins to Joël. He's been playing around with something at Sagewell that he enjoys. At the core of it? Serializers. Primalize gem (https://github.com/jgaskins/primalize) Derek's talk on code review (https://www.youtube.com/watch?v=PJjmw9TRB7s) Inertia.js (https://inertiajs.com/) Phantom types (https://thoughtbot.com/blog/modeling-currency-in-elm-using-phantom-types) io-ts (https://gcanti.github.io/io-ts/) dry-rb (https://dry-rb.org/) parse don't validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) value objects (http://wiki.c2.com/?ValueObject) broader perspective on parsing (https://thoughtbot.com/blog/a-broader-take-on-parsing) Enumerable#tally (https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a5fb11ea) RubyConf mini (https://www.rubyconfmini.com/) where.missing (https://boringrails.com/tips/activerecord-where-missing-associations) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And today, I'm joined by a very special guest, former host Chris Toomey. CHRIS: Hi, Joël. Thanks for having me. JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Chris, what's new in your world? CHRIS: Being on this podcast is new in my world, or everything old is new again, or something along those lines. But, yeah, thank you so much for having me back. It's a pleasure. Although it's very odd, it feels somehow so different and yet very familiar. But yeah, more generally, what's new in my world? I think this was probably in development as I was winding down my time as a host here on The Bike Shed, but I don't know that I ever got a chance to talk about it. There has been a fun sort of deep-in-the-weeds technical thing that we've been playing around with at Sagewell that I've really enjoyed. So at the core of it, we have serializers. So we take some data structures in our Ruby on Rails code base, and we need to serialize them to JSON to send them to the front end. In our case, we're using Inertia, so it's not quite a JSON API, but it's fine to think about it in that way for the context of this discussion. And what we were finding is our front end has TypeScript. So we're writing Svelte, which is using TypeScript. And so we're stating or asserting that the types like, hey, we're going to get this data in from the back end, and it's going to have this shape to it. And we found that it was really hard to keep those in sync to keep, like, what does the user mean on the front end? What's the data that we're going to get? It's going to have a full name, which is a string, except sometimes that might be null. So how do we make sure that those are keeping up to date? And then we had a growing number of serializers on the back end and determining which serializer we were actually using, and it was just...it was a mess, to put it lightly. And so we had explored a couple of different options around it, and eventually, we found a library called Primalize. So Primalize is a Ruby library. It is for writing JSON serializers. But what's really interesting about it is it has a typing layer. It's like a type system sort of thing at play. So when you define a serializer in Primalize, instead of just saying, here are the fields; there is an ID, a name, et cetera, you say, there is an ID, and it is a string. There is a name, and it is a string, or an optional string, which is the even more interesting bit. You can say array. You can say object. You can say an enum of a couple of different values. And so we looked at that, and we said, ooh, this is very interesting. Astute listeners will know that this is probably useless in a Ruby system, which doesn't have types or a compilation step or anything like that. But what's really cool about this is when you use a Primalize serializer, as you're serializing an object, if there is ever a type mismatch, so the observed type at runtime and the authored type if those ever mismatch, then you can have some sort of notification happen. So in our case, we configured it to send a warning to Sentry to say, "Hey, you said the types were this, but we're actually seeing this other thing." Most often, it will be like an Optional, a null sneaking through, a nil sneaking through on the Ruby side. But what was really interesting is as we were squinting at this, we're like, huh, so now we're going to write all this type information. What if we could somehow get that type information down to the front end? So I had a long weekend, one weekend, and I went away, and I wrote a bunch of code that took all of those serializers, ran through them, and generated the associated TypeScript interfaces. And so now we have a build step that will essentially run that and assert that we're getting the same thing in CI as we have committed to the codebase. But now we have the generated serializer types on the front end that match to the used serializer on the back end, as well as the observed run-time types. So it's a combination of a true compilation step type system on the front end and a run-time type system on the back end, which has been very, very interesting. JOËL: I have a lot of thoughts here. CHRIS: I figured you would. [laughs] JOËL: But the first thing that came to mind is, as a consultant, there's a scenario with especially smaller startups that generally concerns me, and that is the CTO goes away for a weekend and writes a lot of code... CHRIS: [laughs] JOËL: And brings in a new system on Monday, which is exactly what you're describing here. How do you feel about the fact that you've done that? CHRIS: I wasn't ready to go this deep this early on in this episode. JOËL: [laughs] CHRIS: But honestly, that is a fantastic question. It's a thing that I have been truly not struggling with but really thinking about. We're going to go on a slight aside here, but I am finding it really difficult to engage with the actual day-to-day coding work that we're doing and to still stay close to the codebase and not be in the way. There's a pattern that I've seen happen a number of times now where I pick up a piece of work that is, you know, one of the tickets at the top of the backlog. I start to work on it. I get pulled into a meeting, then another meeting, then three more meetings. And suddenly, it's three days later. I haven't completed this piece of work that was defined to be the next most important piece of work. And suddenly, I'm blocking the team. JOËL: Hmmm. CHRIS: So I actually made a rule that I'm not allowed to own critical path work, which feels weird because it's like, I want to be engaged with that work. So the counterpoint to that is I'm now trying to schedule pairing sessions with each of the developers on the team once a week. And in that time, I can work on that sort of stuff with them, and they'll then own it and run with it. So it makes sure that I'm not blocking on those sorts of things, but I'm still connected to the core work that we're doing. But the other thing that you're describing of the CTO goes away for the weekend and then comes back with a new harebrained scheme; I'm very sensitive to that, having worked on; frankly, I think the same project. I can think of a project that you and I worked on where we experienced this. JOËL: I think we're thinking of the same project. CHRIS: So yes. Like, I'm scarred by that and, frankly, a handful of experiences of that nature. So we actually, I think, have a really healthy system in place at Sagewell for capturing, documenting, prioritizing this sort of other work, this developer-centric work. So this is the feature and bug work that gets prioritized and one list over here that is owned by our product manager. Separately, the dev team gets to say, here are the pain points. Here's the stuff that keeps breaking. Here are the things that I wish was better. Here is the observability hard-to-understand bits. And so we have a couple of different systems at play and recurring meetings and sort of unique ceremonies around that, and so this work was very much a fallout of that. It was actually a recurring topic that we kept trying a couple of different stabs at, and we never quite landed it. And then I showed up this one Monday morning, and I was like, "I found a thing; what do we think?" And then, critically, from there, I made sure I paired with other folks on the team as we pushed on the implementation. And then, actually, I mentioned Primalize, the library that we're using. We have now since deprecated Primalize within the app because we kept just adding to it so much that eventually, we're like, at this point, should we own this stuff? So we ended up rewriting the core bits of Primalize to better fit our use cases. And now we've actually removed Primalize, wonderful library. I highly recommend it to anyone who has that particular use case but then the additional type generation for the front end. Plus, we have some custom types within our app, Money being the most interesting one. We decided to model Money as our first-class consideration rather than just letting JavaScript have the sole idea of a number. But yes, in a very long-winded way, yes, I'm very sensitive to the thing you described. And I hope, in this case, I did not fall prey to the CTO goes away for the weekend and made a thing. JOËL: I think what I'm hearing is the key difference here is that you got buy-in from the team around this idea before you went out and implemented it. So you're not off doing your own things disconnected from the team and then imposing it from on high. The team already agreed this is the thing we want to do, and then you just did it for them. CHRIS: Largely, yes. Although I will say there are times that each developer on the team, myself included, have sort of gone away, come back with something, and said, "Hey, here's a WIP PR exploring an area." And there was actually...I'm forgetting what the context was, but there was one that happened recently that I introduced. I was like; I had to do this. And the team talked me out of it, and I ended up closing that PR. Someone else actually made a different PR that was an alternative implementation. I was like, no, that's better; we should absolutely do that. And I think that's really healthy. That's a hard thing to maintain but making sure that everyone feels like they've got a strong voice and that we're considering all of the different ways in which we might consider the work. Most critically, you know, how does this impact users at the end of the day? That's always the primary consideration. How do we make sure we build a robust, maintainable, observable system, all those sorts of things? And primarily, this work should go in that other direction, but I also don't want to stifle that creative spark of I got this thing in my head, and I had to explore it. Like, we shouldn't then need to never mind, throw away the work, put it into a ticket. Like, for as long as we can, that more organic, intuitive process if we can retain that, I like that. Critically, with the ability for everyone to tell me, "No, this is a bad idea. Stop it. What are you doing?" And that has happened recently. I mean, they were kinder about it, but they did talk me out of a bad idea. So here we are. JOËL: So you showed up on Monday morning, not with telling everyone, "Hey, I merged this thing over the weekend." You're showing up with a work-in-progress PR. CHRIS: Yes, definitely. I mean, everything goes through a PR, and everything has discussion and conversation around it. That's a strong, strong like Derek Prior's wonderful talk Building a Culture of Code Review. I forget the exact name of it. But it's one of my favorite talks in talking about the utility of code review as a way to share ideas and all of those wonderful things. So everything goes through code review, and particularly anything that is of that more exploratory architectural space. Often we'll say any one review from anyone on the team is sufficient to merge most things but something like that, I would want to say, "Hey, can everybody take a look at this? And if anyone has any reservations, then let's talk about it more." But if I or anyone else on the team for this sort of work gets everybody approving it, then cool, we're good to go. But yeah, code review critical, critical part of the process. JOËL: I'm curious about Primalize, the gem that you mentioned. It sounds like it's some kind of validation layer between some Ruby data structure and your serializers. CHRIS: It is the serializer, but in the process of serializing, it does run-time type validation, essentially. So as it's accessing, you know, you say first name. You have a user object. You pass it in, and you say, "Serializer, there's a first name, and it's a string." It will call the first name method on that user object. And then, it will check that it has the expected type, and if it doesn't, then, in our case, it sends to Sentry. We have configured it...it's actually interesting. In development and test mode, it will raise for a type mismatch, and in production mode, it will alert Sentry so you can configure that differently. But that ends up being really nice because these type mismatches end up being very loud early on. And it's surprisingly easy to maintain and ends up telling us a lot of truths about our system because, really, what we're doing is connecting data from many different systems and flowing it in and out. And all of the inputs and outputs from our system feel very meaningful to lock down in this way. But yeah, it's been an adventure. JOËL: It seems to me there could almost be two sets of types here, the inputs coming into Primalize from your Ruby data structures and then the outputs that are the actual serialized values. And so you might expect, let's say, an integer on the Ruby side, but maybe at the serialization level, you're serializing it to a string. Do you have that sort of conversion step as part of your serializers sometimes, or is the idea that everything's already the right type on the Ruby side, and then we just, like, to JSON it at the end? CHRIS: Yep. Primalize, I think, probably works a little closer to what you're describing. They have the idea of coercions. So within Primalize, there is the concept of a timestamp; that is one of the types that is available. But a timestamp is sort of the union of a date, a time, or I think they might let through a string; I'm not sure if there is as well. But frankly, for us, that was more ambiguity than we wanted or more blurring across the lines. And in the implementation that we've now built, date and time are distinct. And critically, a string is not a valid date or time; it is a string, that's another thing. And so there's a bunch of plumbing within the way you define the serializers. There are override methods so that you can locally within the serializer say, like, oh, we need to coerce from the shape of data into this other shape of data, even little like in-line proc, so we can do it quickly. But the idea is that the data, once it has been passed to the serializer, should be up the right shape. And so when we get to the type assertion part of the library, we expect that things are in the asserted type and will warn if not. We get surprisingly few warnings, which is interesting now. This whole process has made us pay a little more intention, and it's been less arduous simultaneously than I would have expected because like this is kind of a lot of work that I'm describing. And yet it ends up being very natural when you're the developer in context, like, oh, I've been reading these docs for days. I know the shape of this JSON that I'm working with inside and out, and now I'll just write it down in the serializer. It's very easy to do in that moment, and then it captures it and enforces it in such a useful way. As an aside, as I've been looking at this, I'm like, this is just GraphQL, but inside out, I'm pretty sure. But that is a choice that we have made. We didn't want to adopt the whole GraphQL thing. But just for anyone out there who is listening and is thinking, isn't this just GraphQL but inside out? Kind of. Yes. JOËL: I think my favorite part of GraphQL is the schema, which is not really the selling point for GraphQL, you know, like the idea that you can traverse the graph and get any subset of data that you want and all that. I think I would be more than happy with a REST API that has some kind of schema built around it. And someone told me that maybe what I really just want is SOAP, and I don't know how to feel about that comment. CHRIS: You just got to have some XML, and some WSDLs, and other fun things. I've heard people say good things about SOAP. SOAP seems like a fine idea. If anything, I think a critical part of this is we don't have a JSON API. We have a very tightly coupled front end and back end, and a singular front end, frankly. And so that I think naturally...that makes the thing that I'm describing here a much more comfortable fit. If we had multiple different downstream clients that we're trying to consume from the same back end, then I think a GraphQL API or some other structured JSON schema, whatever it is type of API, and associated documentation and typing layer would be probably a better fit. But as I've said many a time on this here, Bike Shed, Inertia is one of my favorite libraries or frameworks (They're probably more of a framework.) one of my favorite technological approaches that I have ever found. And particularly in buildings Sagewell, it has allowed us to move so rapidly the idea that changes are, you know, one fell swoop changes everything within the codebase. We don't have to think about syncing deploys for the back end and the front end and how to coordinate across them. Our app is so much easier to understand by virtue of that architecture that Inertia implies. JOËL: So, if I understand correctly, you don't serialize to JSON as part of the serializers. You're serializing directly to JavaScript. CHRIS: We do serialize to JSON. At the end of the day, Inertia takes care of this on both the Rails side and the client side. There is a JSON API. Like, if you look at the network inspector, you will see XHR requests happening. But critically, we're not doing that. We're not the ones in charge of it. We're not hitting a specific endpoint. It feels as an application coder much closer to a traditional Rails app. It just happens to be that we're writing our view layer. Instead of an ERB, we're writing them in Svelte files. But otherwise, it feels almost identical to a normal traditional Rails app with controllers and the normal routing and all that kind of stuff. JOËL: One thing that's really interesting about JSON as an interchange format is that it is very restrictive. The primitives it has are even narrower than, say, the primitives that Ruby has. So you'd mentioned sending a date through. There is no JSON date. You have to serialize it to some other type, potentially an integer, potentially a string that has a format that the other side knows how it's going to interpret. And I feel like it's those sorts of richer types when we need to pass them through JSON that serialization and deserialization or parsing on the other end become really interesting. CHRIS: Yeah, I definitely agree with that. It was a struggling point for a while until we found this new approach that we're doing with the serializers in the type system. But so far, the only thing that we've done this with is Money. But on the front end, a while ago, we introduced a specific TypeScript type. So it's a phantom type, and I believe I'm getting this correct. It's a phantom type called Cents, C-E-N-T-S. So it represents...I'm going to say an integer. I know that JavaScript doesn't have integers, but logically, it represents an integer amount of cents. And critically, it is not a number, like, the lowercase number in the type system. We cannot add them together. We can't -- JOËL: I thought you were going to say, NaN. CHRIS: [laughs] It is not a number. I saw a n/a for not applicable somewhere in the application the other day. I was like, oh my God, we have a NaN? It happened? But it wasn't, it was just n/a, and I was fine. But yeah, so we have this idea of Cents within the application. We have a money input, which is a special input designed exactly for this. So to a user, it is formatted to look like you're entering dollars and cents. But under the hood, we are bidirectionally converting that to the integer amount of cents that we need. And we strictly, within the type system, those are cents. And you can't do math on Cents unless you use a special set of helper functions. You cannot generate Cents on the fly unless you use a special set of helper functions, the constructor functions. So we've been really restrictive about that, which was kind of annoying because a lot of the data coming from the server is just, you know, numbers. But now, with this type system that we've introduced on the Ruby side, we can assert and enforce that these are money.new on the Ruby side, so using the Money gem. And they come down to the front end as capital C Cents in the type system on the TypeScript side. So we're able to actually bind that together and then enforce proper usage sort of on both sides. The next step that we plan to do after that is dates and times. And those are actually almost weirder because they end up...we just have to sort of say what they are, and they will be ISO 8601 date and time strings, respectively. But we'll have functions that know this is a date string; that's a thing. It is, again, a phantom type implemented within our TypeScript type system. But we will have custom functions that deal with that and really constrain...lock ourselves down to only working with them correctly. And critically, saying that is the only date and time format that we work with; there is no other. We don't have arbitrary dates. Is this a JSON date or something else? I don't know; there are too many date syntaxes. JOËL: I like the idea of what you're doing in that it sounds like you're very much narrowing that sort of window of where in the stack the data exists in the sort of unstructured, free-floating primitives that could be misinterpreted. And so, at this point, it's almost narrowed to the point where it can't be touched by any user or developer-written code because you've pushed the boundaries on the Rails side down and then on the JavaScript side up to the point where the translation here you define translations on one side or, I guess, a parser on one side and a serializer on the other. And they guarantee that everything is good up until that point. CHRIS: Yep, with the added fun of the runtime reflection on the Ruby side. So it's an interesting thing. Like, TypeScript actually has similar things. You can say what the type is all day long, and your code will consistently conform to that asserted type. But at the end of the day, if your JSON API gets in some different data...unless you're using a library like io-ts, is one that I've looked at, which actually does parsing and returns a result object of did we parse to the thing that you wanted or did we get an error in that data structure? So we could get to that level on the client side as well. We haven't done that yet largely because we've essentially pushed that concern up to the Ruby layer. So where we're authoring the data, because we own that, we're going to do it at that level. There are a bunch of benefits of defining it there and then sort of reflecting it down. But yeah, TypeScript, you can absolutely lie to yourself, whereas Elm, a language that I know you love dearly, you cannot lie to yourself in Elm. You've got to tell the truth. It's the only option. You've got to prove it. Whereas in TypeScript, you can just kind of suggest, and TypeScript will be like, all right, cool, I'll make sure you stay honest on that, but I'm not going to make you prove it, which is an interesting sort of set of related trade-offs there. But I think we found a very comfortable resting spot for right now. Although now, we're starting to look at the edges of the Ruby system where data is coming in. So we have lots of webhooks and other external partners that we're integrating with, and they're sending us data. And that data is of varying shapes. Some will send us a payload with the word amount, and it refers to an integer amount of cents because, of course, it does. Some will send us the word amount in their payload, and it will be a floating amount of dollars. And I get a little sad on those days. But critically, our job is to make sure all of those are the same and that we never pass dollars as cents or cents as dollars because that's where things go sad. That is job number one at Sagewell in the engineering team is never get the decimal place wrong in money. JOËL: That would be a pretty terrible mistake to make. CHRIS: It would. I mean, it happens. In fintech, that problem comes up a lot. And again, the fact that...I'm honestly surprised to see situations out there where we're getting in floating point dollars. That is a surprise to me because I thought we had all agreed sort of as a community that it was integer cents but especially in a language that has integers. JavaScript, it's kind of making it up the whole time. But Ruby has integers. JSON, I guess, doesn't have integers, so I'm sort of mixing concerns here, but you get the idea. JOËL: Despite Ruby not having a static type system, I've found that generally, when I'm integrating with a third-party API, I get to the point where I want something that approximates like Elm's JSON decoders or io-ts or something like that. Because JSON is just a big blob of data that could be of any shape, and I don't really trust it because it's third-party data, and you should not trust third parties. And I find that I end up maybe cobbling something together commonly with like a bunch of usage of hash.fetch, things like that. But I feel like Ruby doesn't have a great approach to parsing and composing these validators for external data. CHRIS: Ruby as a language certainly doesn't, and the ecosystem, I would say, is rather limited in terms of the options here. We have looked a bit at the dry-rb stack of gems, so dry-validation and dry-schema, in particular, both offer potentially useful aspects. We've actually done a little bit of spiking internally around that sort of thing of, like, let's parse this incoming data instead of just coercing to hash and saying that it's got probably the shape that we want. And then similarly, I will fetch all day instead of digging because I want to be quite loud when we get it wrong. But we're already using dry-monads. So we have the idea of result types within the system. We can either succeed or fail at certain operations. And I think it's just a little further down the stack. But probably something that we will implement soon is at those external boundaries where data is coming in doing some form of parsing and validation to make sure that it conforms to unknown data structure. And then, within the app, we can do things more cleanly. That also would allow us to, like, let's push the idea that this is floating point dollars all the way out to the edge. And the minute it hits our system, we convert it into a money.new, which means that cents are properly handled. It's the same type of money or dollar, same type of currency handling as everywhere else in the app. And so pushing that to the very edges of our application is a very interesting idea. And so that could happen in the library or sort of a parsing client, I guess, is probably the best way to think about it. So I'm excited to do that at some point. JOËL: Have you read the article, Parse, Don't Validate? CHRIS: I actually posted that in some code review the other day to one of the developers on the team, and they replied, "You're just going to quietly drop one of my favorite articles of all time in code review?" [laughs] So yes, I've read it; I love it. It's a wonderful idea, definitely something that I'm intrigued by. And sort of bringing dry-monads into Ruby, on the one hand, feels like a forced fit and yet has also been one of the other, I think strongest sort of architectural decisions that we've made within the application. There's so much imperative work that we ended up having to do. Send this off to this external API, then tell this other one, then tell this other one. Put the whole thing in a transaction so that our local data properly handles it. And having dry-monads do notation, in particular, to allow us to make that manageable but fail in all the ways it needs to fail, very expressive in its failure modes, that's been great. And then parse, don't validate we don't quite do it yet. But that's one of the dreams of, like, our codebase really should do that thing. We believe in that. So let's get there soon. JOËL: And the core idea behind parse, don't validate is that instead of just having some data that you don't trust, running a check on it and passing that blob of now checked but still untrusted data down to the next person who might also want to check it. Generally, you want to pass it through some sort of filter that will, one, validate that it's correct but then actually typically convert it into some other trusted shape. In Ruby, that might be something like taking an amorphous blob of JSON and turning it into some kind of value object or something like that. And then anybody downstream that receives, let's say, money object can trust that they're dealing with a well-formed money value as opposed to an arbitrary blob of JSON, which hopefully somebody else has validated, but who knows? So I'm going to validate it again. CHRIS: You can tell that I've been out of the podcasting game for a while because I just started responding to yes; I love that blog post without describing the core premise of it. So kudos to you, Joël; you are a fantastic podcast host over there. I will say one of the things you just described is an interesting...it's been a bit of a struggle for us. We keep sort of talking through what's the architecture. How do we want to build this application? What do we care about? What are the things that really matter within this codebase, and then what is all the other stuff? And we've been good at determining the things that really matter, thinking collectively as a group, and I think coming up with some novel, useful, elegant...I'm saying too many positive adjectives for what we're doing. But I've been very happy with sort of the thing that we decide. And then there's the long-tail work of actually propagating that change throughout the rest of the application. We're, like, okay, here's how it works. Every incoming webhook, we now parse and yield a value object. That sentence that you just said a minute ago is exactly what I want. That's like a bunch of work. It's particularly a bunch of work to convert an existing codebase. It's easy to say, okay, from here forward, any new webhooks, payloads that are coming in, we're going to do in this way. But we have a lot of things in our app now that exist in this half-converted way. There was a brief period where we had three different serializer technologies at play. Just this week, I did the work of killing off the middle ground one, the Primalized-based thing, and we now have only our new hotness and then the very old. We were using Blueprinter as the serializer as the initial sort of stub. And so that still exists within the codebase in some places. But trying to figure out how to prioritize that work, the finishing out those maintenance-type conversions is a tricky one. It's never the priority. But it is really nice to have consistency in a codebase. So it's...yeah, do you have any thoughts on that? JOËL: I think going back to the article and what the meaning of parsing is, I used to always think of parsing as taking strings and turning them into something else, and I think this really broadened my perspective on the idea of parsing. And now, I think of it more as converting from a broader type to a narrower type with failures. So, for example, you could go from a string to an integer, and not all strings are valid integers. So you're narrowing the type. And if you have the string hello world, it will fail, and it will give you an error of some type. But you can have multiple layers of that. So maybe you have a string that you parse into an integer, but then, later on, you might want to parse that integer into something else that requires an integer in a range. Let's say it's a percentage. So you have a value object that is a percentage, but it's encoded in the JSON as a string. So that first pass, you parse it from a string into an integer, and then you parse that integer into a percentage object. But if it's outside the range of valid percentage numbers, then maybe you get an error there as well. So it's a thing that can happen at multiple layers. And I've now really connected it with the primitive obsession smell in code. So oftentimes, when you decide, wait, I don't want a primitive here; I want a richer type, commonly, there's going to be a parsing step that should exist to go from that primitive into the richer type. CHRIS: I like that. That was a classic Joël wildly concise summary of a deeply complex technical topic right there. JOËL: It's like I'm going to connect some ideas from functional programming and a classic object-oriented code smell and, yeah, just kind of mash it all together with a popular article. CHRIS: If only you had a diagram. Podcast is not the best medium for diagrams, but I think you could do it. You could speak one out loud, and everyone would be able to see it in their mind's eye. JOËL: So I will tell you what my diagram is for this because I've actually created it already. I imagine this as a sort of like pyramid with different layers that keep getting smaller and smaller. So the size of type is sort of the width of a layer. And so your strings are a very wide layer. Then on top of that, you have a narrower layer that might be, you know, it could be an integer, or you could even if you're parsing JSON, you first start with a string, then you parse that into a Ruby hash, not all strings are valid hashes. So that's going to be narrower. Then you might extract some values out of that hash. But if the keys aren't right, that might also fail. You're trying to pull the user out of it. And so each layer it gets a richer type, but that richer type, by virtue of being richer, is narrower. And as you're trying to move up that pyramid at every step, there is a possibility for a failure. CHRIS: Have you written a blog post about this with said diagram in it? And is that why you have that so readily at hand? [laughs] JOËL: Yes, that is the case. CHRIS: Okay. Yeah, that made sense to me. [laughs] JOËL: We'll make sure to link to it in the show notes. CHRIS: Now you have to link to Joël blog posts, whereas I used to have to link to them [chuckles] in almost every episode of The Bike Shed that I recorded. JOËL: Another thing I've been thinking about in terms of this parsing is that parsing and serializing are, in a sense, almost opposites of each other. Typically, when you're parsing, you're going from a broad type to a narrow one. And when you're serializing, you're going from a narrow type to a broader one. So you might go from a user into a hash into a string. So you're sort of going down that pyramid rather than going up. CHRIS: It is an interesting observation and one that immediately my brain is like, okay, cool. So can we reuse our serializers but just run them in reverse or? And then I try and talk myself out of that because that's a classic don't repeat yourself sort of failure mode of, like, actually, it's fine. You can repeat a little bit. So long as you can repeat and constrain, that's a fine version. But yeah, feels true, though, at the core. JOËL: I think, in some ways, if you want a single source of truth, what you want is a schema, and then you can derive serializers and parsers from that schema. CHRIS: It's interesting because you used the word derive. That has been an interesting evolution at Sagewell. The engineering team seems to be very collected around the idea of explicitness, almost the Zen of Python; explicit is better than implicit. And we are willing to write a lot of words down a lot of times and be happy with that. I think we actually made the explicit choice at one point that we will not implement an automatic camel case conversion in our serializer, even though we could; this is a knowable piece of code. But what we want is the grepability from the front end to the back end to say, like, where's this data coming from? And being able to say, like, it is this data, which is from this serializer, which comes from this object method, and being able to trace that very literally and very explicitly in the code, even though that is definitely the sort of thing that we could derive or automatically infer or have Ruby do that translation for us. And our codebase is more verbose and a little noisier. But I think overall, I've been very happy with it, and I think the team has been very happy. But it is an interesting one because I've seen plenty of teams where it is the exact opposite. Any repeated characters must be destroyed. We must write code to write the code for us. And so it's fun to be working with a team where we seem to be aligned around an approach on that front. JOËL: That example that you gave is really interesting because I feel like a common thing that happens in a serialization layer is also a form of normalization. And so, for example, you might downcase all strings as part of the serialization, definitely, like dates always get written in ISO 8601 format whenever that happens. And so, regardless of how you might have it stored on the Ruby side, by the time it gets to the JSON, it's always in a standard format. And it sounds like you're not necessarily doing that with capitalization. CHRIS: I think the distinction would be the keys and the values, so we are definitely doing normalization on the values side. So ISO 8601 date and time strings, respectively that, is the direction that we plan to go for the value. But then for the key that's associated with that, what is the name for this data, those we're choosing to be explicit and somewhat repetitive, or not even necessarily repetitive, but the idea of, like, it's first_name on the Ruby side, and it's first capital N name camel case, or it's...I forget the name. It's not quite camel case; it's a different one but lower camel, maybe. But whatever JavaScript uses, we try to bias towards that when we're going to the front end. It does get a little tricky coming back into the Ruby side. So our controllers have a bunch of places where they need to know about what I think is called lower camel case, and so we're not perfect there. But that critical distinction between sort of the names for things, and the values for things, transformations, and normalizations on the values, I'm good with that. But we've chosen to go with a much more explicit version for the names of things or the keys in JSON objects specifically. JOËL: One thing that can be interesting if you have a normalization phase in your serializer is that that can mean that your serializer and parsers are not necessarily symmetric. So you might accept malformed data into your parser and parse it correctly. But then you can't guarantee that the data that gets serialized out is going to identically match the data that got parsed in. CHRIS: Yeah, that is interesting. I'm not quite sure of the ramifications, although I feel like there are some. It almost feels like formatting Prettier and things like that where they need to hold on to whitespace in some cases and throw out in others. I'm thinking about how ASTs work. And, I don't know, there's interesting stuff, but, again, not sure of the ramifications. But actually, to flip the tables just a little bit, and that's an aggressive terminology, but we're going to roll with it. To flip the script, let's go with that, Joël; what's been up in your world? You've been hosting this wonderful show. I've listened in to a number of episodes. You're doing a fantastic job. I want to hear a little bit more of what's new in your world, Joël. JOËL: So I've been working on a project that has a lot of flaky tests, and we're trying to figure out the source of that flakiness. It's easy to just dive into, oh, I saw a flaky Test. Let me try to fix it. But we have so much flakiness that I want to go about it a little bit more systematically. And so my first step has actually been gathering data. So I've actually been able to make API requests to our CI server. And the way we figure out flakiness is looking at the commit hash that a particular test suite run has executed on. And if there's more than one CI build for a given commit hash, we know that's probably some kind of flakiness. It could be a legitimate failure that somebody assumed was flakiness, and so they just re-run CI. But the symptom that we are trying to address is the fact that we have a very high level of people re-verifying their code. And so to do that or to figure out some stats, I made a request to the API grouped by commit hash and then was able to get the stats of how many re-verifications there are and even the distribution. The classic way that you would do that is in Ruby; you would use the GroupBy function from enumerable. And then, you would transform values instead of having, like, say; each commit hash then points to all the builds, an array of builds that match that commit hash. You would then thumb those. So now you have commit hashes that point to counts of how many builds there were for that commit hash. Newer versions of Ruby introduced the tally method, which I love, which allows you to basically do all of that in one step. One thing that I found really interesting, though, is that that will then give me a hash of commit hashes that point to the number of builds that are there. If I want to get the distribution for the whole project over the course of, say, the last week, and I want to say, "How many times do people run only one CI run versus running twice in the same commit versus running three times, or four times, or five or six times?" I want to see that distribution of how many times people are rerunning their build. You're effectively doing that tally process twice. So once you have a list of all the builds, you group by hash. You count, and so you end up with that. You have the Ruby hash of commit SHAs pointing to number of times the build was run on that. And then, you again group by the number of builds for each commit SHA. And so now what you have is you'll have something like one, and then that points to an array of SHA one, SHA two, SHA three, SHA four like all the builds. And then you tally that again, or you transform values, or however, you end up doing it. And what you end up with is saying for running only once, I now have 200 builds that ran only once. For running twice in the same commit SHA, there are 15. For running three times, there are two. For running four times, there is one. And now I've got my distribution broken down by how many times it was run. It took me a while to work through all of that. But now the shortcut in my head is going to be you double tally to get distribution. CHRIS: As an aside, the whole everything you're talking about is interesting and getting to that distribution. I feel like I've tried to solve that problem on data recently and struggled with it. But particularly tally, I just want to spend a minute because tally is such a fantastic addition to the Ruby standard library. I used to have in sort of like loose muscle memory transform value is grouped by ampersand itself, transform values count, sort, reverse to H. That whole string of nonsense gets replaced by tally, and, oof, what a beautiful example of Ruby, and enumerable, and all of the wonder that you can encapsulate there. JOËL: Enumerable is one of the best parts of Ruby. I love it so much. It was one of the first things that just blew my mind about Ruby when I started. I came from a PHP, C++ background and was used to writing for loops for everything and not the nice for each loops that a lot of languages have these days. You're writing like a legit for or while loop, and you're managing the indexes yourself. And there's so much room for things to go wrong. And being introduced to each blew my mind. And I was like, this is so beautiful. I'm not dealing with indexes. I'm not dealing with the raw implementation of the array. I can just say do a thing for each element. This is amazing. And that is when I truly fell in love with Ruby. CHRIS: I want to say I came from Python, most recently before Ruby. And Python has pretty nice list comprehensions and, in fact, in some ways, features that enumerable doesn't have. But, still, coming to Ruby, I was like, oh, this enumerable; this is cool. This is something. And it's only gotten better. It still keeps growing, and the idea of custom enumerables. And yeah, there's some real neat stuff in there. JOËL: I'm going to be speaking at RubyConf Mini this fall in November, and my talk is all about Enumerators and ranges in enumerable and ways you can use those to make the APIs of the objects that you create delightful for other people to use. CHRIS: That sounds like a classic Joël talk right there that I will be happy to listen to when it comes out. A very quick related, a semi-related aside, so, tally, beautiful addition to the Ruby language. On the Rails side, there was one that I used recently, which is where.missing. Have you seen where.missing? JOËL: I have not heard of this. CHRIS: So where.missing is fantastic. Let's assume you've got two related objects, so you've got like a has many blah, so like a user has many posts. I think you can...if I'm remembering it correctly, it's User.where.missing(:posts). So it's where dot missing and then parentheses the symbol posts. And under the hood, Rails will do the whole LEFT OUTER JOIN where the count is null, et cetera. It turns into this wildly complex SQL query or understandably complex, but there's a lot going on there. And yet it compresses down so elegantly into this nice, little ActiveRecord bit. So where.missing is my new favorite addition into the Rails landscape to complement tally on the Ruby side, which I think tally is Ruby 2.7, I want to say. So it's been around for a while. And where.missing might be a Ruby 7 feature. It might be a six-something, but still, wonderful features, ever-evolving these tool sets that we use. JOËL: One of the really nice things about enumerable and family is the fact that they build on a very small amount of primitives, and so as long as you basically understand blocks, you can use enumerable and anything in there. It's not special syntax that you have to memorize. It's just regular functions and blocks. Well, Chris, thank you so much for coming back for a visit. It's been a pleasure. And it's always good to have you share the cool things that you're doing at Sagewell. CHRIS: Well, thank you so much, Joël. It's been an absolute pleasure getting to come back to this whole Bike Shed. And, again, just to add a note here, you're doing a really fantastic job with the show. It's been interesting transitioning back into listener mode for the show. Weirdly, I wasn't listening when I was a host. But now I've regained the ability to listen to The Bike Shed and really enjoy the episodes that you've been doing and the wonderful spectrum of guests that you've had on and variety of topics. So, yeah, thank you for hosting this whole Bike Shed. It's been great. JOËL: And with that, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeeeee!!!!!!!! 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.

checkout our website: https://www.brakeingsecurity.com Follow and subscribe with your Amazon Prime account to our Twitch stream: https://twitch.tv/brakesec   Twitter: @infosystir @boettcherpwned @bryanbrake @brakesec Find us on all your favorite podcast platforms! Please leave us a 5 star review to help us grow!

On This Week in Google, Jeff Jarvis, Stacey Higginbotham, and Ant Pruitt discuss Google's push to have anonymous code review procedures for developers as it may discourage bias in reviews. For the full episode, visit twit.tv/twig/670 Hosts: Jeff Jarvis, Stacey Higginbotham, and Ant Pruitt You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

On This Week in Google, Jeff Jarvis, Stacey Higginbotham, and Ant Pruitt discuss Google's push to have anonymous code review procedures for developers as it may discourage bias in reviews. For the full episode, visit twit.tv/twig/670 Hosts: Jeff Jarvis, Stacey Higginbotham, and Ant Pruitt You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

Welcome to Remote Ruby and thanks for joining us!  Today the guys cover bet, basketball, and Adidas! And if we haven't lost you yet, we have a “Three-peat” guest joining us, and that is Steve Polito, who's a Developer at thoughtbot. We'll be talking with Steve about careers around programming, the importance of practicing Code Review, and great emojis to use for a good PR Review.  We also find out from Steve how the non-technical/technical interview was like, how Rails helped him get better at architecture, he shares some recommendations on ways you can get a job if you have no prior experience, and how his Twitter presence has helped him.  Go ahead and download this episode now to find out more![00:01:45] We hear Steve's background and how he got to where he is today.[00:08:05] Steve tells us how the process was going from IMPACT to thoughtbot, he explains the things he liked about the interview process at thoughtbot and doing Code Review after the interview.[00:13:43] Jason and Andrew talk about how praise is important when leaving feedback on PRs.[00:15:42] Steve brings up a good point Andrew made abut PR Review misses in the guide and he shares advice what he does.[00:16:26] Andrew explains how some emojis mean different things to different people and to keep that in mind when using them, and the guys shares which ones they use for a good PR Review.[00:20:01] Steve tells us what the non-technical/technical interview was like.[00:23:00] Andrew asks Steve if by the nature of way Rails works, if that helped him get better at architecture versus some of the other things out there. [00:26:41] The topic of hiring is brought up, searching a candidate, and things you can do to bolster your resume when you have no experience, and Steve shares some recommendations that may help if you have no prior experience.[00:29:53] Jason brings up Steve wanting to learn to build an authentication generator from scratch and he explains what he did. [00:33:40] Andrew announces to please make your users confirm their email address if they input it on your sign-up form.[00:34:31] We find out how Steve's Twitter presence helped him since Andrew says he's one of the best out there, and if he's naturally open to feedback. Panelists:Jason CharnesAndrew MasonGuest:Steve PolitoSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterJason Charnes TwitterAndrew Mason TwitterSteve Polito TwitterSteve Polito WebsiteSteve Polito LinkedInRemote Ruby Podcast-Episode 88: Following up with Steve PolitoRemote Ruby Podcast-Episode 74: From Agency Life to Software Development: Q&A with Steve Politothoughtbot Code Reviews

Tomas Reimers and Greg Foster join us to talk about Graphite, an open-source CLI and a code review dashboard built for engineers who want to write and review smaller pull requests, stay unblocked, and ship faster. We talk about developer workflows, the pivot from Screenplay to Graphite, Graphite's recent Series A announcement, and more. Links https://graphite.dev https://twitter.com/tomasreimers https://twitter.com/gregmfoster https://graphite.dev/blog (https://graphite.dev/blog/post/EjK76U2pBbR7RGYBo21A) https://podrocket.logrocket.com/screenplay Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form here (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! Review us Reviews are what help us grow and tailor our content to what you want to hear. Give us a review here (https://ratethispodcast.com/podrocket). Contact us https://podrocket.logrocket.com/contact-us @PodRocketpod (https://twitter.com/PodRocketpod) What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup/?pdr). Special Guests: Greg Foster and Tomas Reimers.

Bob and Randy were joined this week by Matt Van Itallie, founder and CEO of Sema. Sema has two great tools: Code Review, a Chrome extension that makes code reviews more robust with structured feedback and easy access to best practices, and Codebase Solution that offers comprehensive reports that evaluate the quality of code, code security, and third party IP risk. Matt tells Bob and Randy the history of the company and these tools, and then explains that these tools not only strengthen product code, they also strengthen developer skills and inter-developer relationships. Sema's tools are interesting and we hope you enjoy finding out about this company as much as we did.

On this episode, we're joined by Boston Globe senior newsroom developer Vince Dixon. Vince's job is to create interactive and data-driven visuals for Boston Globe.com. He previously worked at Eater.Vince also does a lot of visual-oriented personal passion projects for his blog, Code Review – including a look at 28 Black Pioneers in Journalism, Design, and Technology in 2019.Vince talked about his journalism path, the types of projects he works on, and the value of knowing how to code. He also told the story of several Black journalism pioneers.You can find many of Vince's projects, including pieces on the history of police brutality, his study on purse-clutching, and how Black people influenced the origins of many American music genres at VinceDixonPortfolio.com.