The Bike Shed

thoughtbot

4.9(122개의 평가)
과학 기술
매주 업데이트

On The Bike Shed, hosts Joël Quenneville and Stephanie Minn discuss development experiences and challenges at thoughtbot with Ruby, Rails, JavaScript, and whatever else is drawing their attention, admiration, or ire this week.

2일 전

447: How to (not) implement impersonation

For developers, impersonation can be a powerful tool, but with great power comes great responsibility. In today’s episode, hosts Stephanie and Joël explore the complexities of implementing impersonation features in software development, giving you the ability to take over someone’s account and act as the user. They delve into the pros and cons of impersonation, from how it can help with debugging and customer support to its prime drawbacks regarding security and auditing issues. Discover why the need for impersonation is often a sign of poor admin tooling, alternative solutions to true impersonation, and the scenarios where impersonation might be the most pragmatic approach. You’ll also learn why they advocate for understanding the root problem and considering alternative solutions before implementing impersonation. Tune in today for a deep dive into impersonation and the best ways to use it (or not use it)!  Key Points From This Episode: What’s new in Stephanie’s world: how Notion Calendar is helping her manage her schedule. Joël’s quest to find a health plan: how he used a spreadsheet to compare his options. A client request to build an impersonation feature, and why Joël has mixed feelings about it. What an impersonation tool does: it allows you to take over someone’s account. When it’s useful to use implementation as a feature, like for debugging and support. Potential risks and responsibilities associated with impersonation. Why the need for impersonation often indicates poor admin tooling. Technical and security implications of impersonation. Solutions for logging the audit trail when you’re doing impersonation. Differentiating between the logged-in user and the user you’re rendering views for. Building an app that isn’t as tightly coupled to the “current user.” Suggested alternatives to true impersonation. The value of cross-functional teams and collaborative problem-solving. Links Mentioned in Today’s Episode: Mailtrap Notion Calendar 'Implementing Impersonation' Sustainable Web Development with Ruby on Rails The Bike Shed Joël Quenneville on LinkedIn Joël Quenneville on X Support The Bike Shed WorkOS Support The Bike Shed

38분
11월 12일

446: All about rewrites

When is it time for a rewrite? How do you justify it? If you’re tasked with one, how do you approach it? In today’s episode of The Bike Shed, we dive into the tough question of software rewrites, sharing firsthand experiences that reveal why these projects are often more complicated and risky than they first appear. We unpack critical factors that make or break a rewrite, from balancing developer satisfaction with business value to managing stakeholder expectations when costs and timelines stretch unexpectedly. You’ll hear about real-world rewrite pitfalls like downtime and reintroducing bugs, as well as strategies for achieving similar improvements through incremental changes or refactoring instead. If you’re a developer or team lead considering a rewrite, this conversation offers a pragmatic perspective that could save your team time, effort, and potential setbacks. Tune in to learn how to make the best call for your codebase and find out when a rewrite might actually be necessary! Key Points From This Episode: Accessible selectors versus test IDs: best practices in Capybara and React Testing Library. Balancing test coverage with pragmatism and risk tolerance with Good Enough Testing. Software rewrites and the tough questions around deciding when they're necessary. The importance of prioritizing business value over frustrations with the current codebase. Drawbacks of rewrites, such as downtime, data loss, and reintroducing past bugs. Risks of “grass is greener” thinking and using mocked data in demos. Unrealistic expectations of full feature parity and why an MVP approach is better. How incremental refactoring can achieve similar goals to a complete rewrite. The appeal and hubris of a “fresh start” and why it’s much more complex than that. Balancing innovation with practicality: ways to introduce new elements without rewriting. An example that illustrates when a rewrite might actually be necessary. Reasons that early prototypes and test builds are the best candidates for rewrites. Links Mentioned in Today’s Episode: Mailtrap WorkOS Matt Brictson: ‘Simplify your Capybara selectors’ React Testing Library Guidelines Capybara Accessibility Selectors Good Enough Testing ‘RailsConf 2023: The Math Every Programmer Needs by Joël Quenneville’ ‘Testing Your Edge Cases’ 'Working Iteratively' 'Technical Considerations to Help Scale Your Product' Dan McKinley: ‘Choose Boring Technology' The Bike Shed Joël Quenneville on LinkedIn Joël Quenneville on X Support The Bike Shed Support The Bike Shed

36분
10월 29일

445: Working Iteratively

Does having smaller, more frequent iterations help to ease your cognitive load? During this episode, we discuss the benefits and challenges of working iteratively and whether or not it can prevent costly errors. You’ll hear about juggling individual pieces effectively, factors that incentivize and de-incentivize working iteratively, and how Joël gauges whether or not a project should be broken up into smaller tasks. It can be hard to adopt small iterations, and this conversation also touches on the idea of ‘good enough code’ and discusses how agility can reduce the cost of making changes. Tuning in, you’ll hear about some of the challenges of keeping up with changes as they evolve and why it is beneficial to do so. You will also be equipped with a thought experiment involving elephant carpaccio to build your understanding of working iteratively, explore the challenge of keeping up with evolving changes, and more. Thanks for listening. Key Points From This Episode: Stephanie shares a recent mishap that happened at work and what she learned from it. Unpacking pressures and other aspects that may have contributed to the error. Joël’s recent travels and his fresh appreciation for fall. The cost of an incident occurring, how this increases, and the role of code review. Benefits and pitfalls of more regular code review. Why working with smaller chunks of work is helpful for Joël’s focus. Juggling individual pieces effectively. Factors that de-incentivize working iteratively such as waiting on 24-hour quality control processes. How working iteratively can facilitate better communication. Why Joël feels that work that spans a few days should be broken up into smaller chunks. The idea of ‘good enough code’. How agility can reduce the cost of making changes. Using the elephant carpaccio exercise to bolster your understanding of working iteratively. The challenge of keeping up with changes as they evolve and why it is beneficial to do so. Involvement from the team and the capacity to change course. Links Mentioned in Today’s Episode: WorkOS Working Incrementally Working Iteratively Elephant Carpaccio Exercise The Bike Shed Joël Quenneville on LinkedIn Joël Quenneville on X Support The Bike Shed Support The Bike Shed

40분
10월 15일

444: From Solutions To Patterns

What’s the difference between solving problems and recognizing patterns, and why does it matter for developers? In this episode, Stephanie and Joël discuss transitioning from collecting solutions to identifying patterns applicable to broader contexts in software development. They explore the role of heuristics, common misconceptions among junior and intermediate developers, and strategies for leveling up from a solution-focused mindset to thinking in patterns. They also discuss their experiences of moving through this transition during their careers and share advice for upcoming software developers to navigate it successfully. They explore how learning abstraction, engaging in code reviews, and developing a strong intuition for code quality help developers grow. Uncover the issue of over-applying patterns and gain insights into the benefits of broader, reusable approaches in code development. Join us to discover how to build your own set of coding heuristics, the pitfalls of pattern misuse, and how to become a more thoughtful developer. Tune in now! Key Points From This Episode: Stephanie unpacks the differences between patterns and solutions. The role of software development experience in recognizing patterns. Why transitioning from solving problems to recognizing patterns is crucial. Joël and Stephanie talk about the challenges of learning abstraction. Hear pragmatic strategies for implementing patterns effectively. How junior developers can build their own set of heuristics for code quality. Discover valuable tools and techniques to identify patterns in your work. Find out about approaches to documenting, learning, and sharing patterns. Gain insights into the process of refactoring a solution into a pattern. Outlining the common mistakes developers make and the pitfalls to avoid. Steps for navigating disagreements and feedback in a team environment. Links Mentioned in Today’s Episode: WorkOS RubyConf 2021 - The Intro to Abstraction I Wish I'd Received 'Ruby Science' Refactoring.Guru Thoughtbot code review guide The Bike Shed Joël Quenneville on LinkedIn Joël Quenneville on X Support The Bike Shed Support The Bike Shed

35분
10월 8일

443: Rails World and Open Source with Stefanni Brasil

Learning from other developers is an important ingredient to your success. During this episode, Joël Quenneville is joined by Stefanni Brasil, Senior Developer at Thoughtbot, and core maintainer of faker-ruby. To open our conversation, she shares the details of her experience at the Rails World conference in Toronto and the projects she enjoyed seeing most. Next, we explore the challenge of Mac versus Windows and how these programs interact with Ruby on Rails and dive into Stefanni’s involvement in Open Source for Thoughtbot and beyond; what she loves about it, and how she is working to educate others and expand the current limitations that people experience. This episode is also dedicated to the upcoming Open Source Summit that Stefanni is planning on 25 October 2024, what to expect, and how you can get involved. Thanks for listening! Key Points From This Episode: Introducing and catching up with Thoughtbot Senior Developer and maintainer of faker-ruby, Stefanni Brasil. Her experience at the Rails World conference in Toronto and the projects she found most inspiring. Why accessibility remains a key topic. How Ruby on Rails translates on Mac and Windows. Stefanni’s involvement in Open Source and why she enjoys it. Her experience as core maintainer at faker-ruby. Ideas she is exploring around Jeremy Evans’ book Polished Ruby Programming and the direction of Faker. Involvement in Thoughtbot’s Open Source and how it drew her in initially. The coaching series on Open Source that she participated in earlier this year. What motivated her to create a public Google doc on Open Source maintenance. An upcoming event: the Open Source Summit. The time commitment expected from attendees. How Stefanni intends to interact with guests and the talk that she will give at the event. Why everyone is welcome to engage at any level they are comfortable with. Links Mentioned in Today’s Episode: Stefanni Brasil Stefanni Brasil on X Thoughtbot Open Summit Open Source Issues doc Open Source at Thoughtbot Polished Ruby Programming Faker Gem Rails World  The Bike Shed Joël Quenneville on LinkedIn Support The Bike Shed

32분
10월 1일

442: Paradigms - What is a Program?

What is a program? Your answer to this question will determine the paradigm through which you view programming. During this episode, you’ll come to understand how things change once you develop an awareness of your paradigm, and what. To kick off this episode, Stephanie shares key insights she took from Planet Argon’s 2024 Ruby on Rails survey and dives deeper into her history with Ruby on Rails. Next, we dive into the definition of a paradigm and unpack three different paradigms you might hold as a developer: procedural, object-oriented, and functional. Considering how each of these impacts the way that you might approach your work as a developer, and what you can learn from the ones that are less familiar to you. Joël describes his scripting style and evaluates the concept of pure functions and their place in development, and we close by digging deeper into how your paradigm might impact the code that you write. Tune in to hear all this and more. Key Points From This Episode: The EPI feature that Joël has started to build out for his client. Why Stephanie is excited about the results of Planet Argon’s 2024 Ruby on Rails community survey. What a procedural program is: programming envisions a program as a series of instructions to a computer. Defining an object-oriented paradigm: programming envisions a program as the behavior that emerges from objects talking to each other. How a functional paradigm envisions a program as a series of data transformations. Alan Turing and Alonzo Church’s approach to understanding this. How a lot of the foundations of computer science came to be built before we had computers. Using Ruby to make judgments and assessing whether or not this is a procedural habit. Why Joël describes his scripting style as being very procedural. Unpacking the meaning of functional programming. Evaluating the concept of pure functions. Considering how your paradigm may impact the Ruby code that you write. Links Mentioned in Today’s Episode: 2024 Ruby on Rails Community Survey Church-Turing Thesis Dynamic type systems are not inherently more open What is Functional Programming? Blocks as an abstraction vs for loops Functional core imperative shell Testing objects with a functional mindset  The Bike Shed Joël Quenneville on LinkedIn Support The Bike Shed Support The Bike Shed

42분
9월 24일

441: The Pickaxe Book with Noel Rappin

For a long time, Programming Ruby was the authority in the developing world. Now, a much-needed update has been published. During this conversation, we are joined by Noel Rappin, who shares how his frustration at the idea of static type in Ruby motivated him to investigate why he felt this way, as he published his findings in The Pickaxe Book. We discuss how this book differs from previous material he has published, explore a recent blog post series that explored the idea of failing fast, and address the widespread opinion that developers should take a simpler approach that is more accessible. Noel also explores the responsibility of understanding how readers consume material and the importance of providing thorough context as an author, how Programming Ruby became the most significant programming reference, and the surprising journey that led Noel to realize he was able to provide an updated version of the theory in it. Next, we dive into some of the more opinionated blog posts Noel has posted and the harshest feedback he has received in response to them. You’ll also hear about his research and learning during the act of writing the book. Join us today to hear all this and more. Key Points From This Episode: Noel Rappin’s recently published work, The Pickaxe Book, on current versions of Ruby. The inception of the book during discussions about the collision of Sorbet and Ruby. How his background made him comfortable with the idea that there are no static types. A recent blog post series and how it answered a question about failing fast. Considering whether developers pursue simpler things that are more accessible to a wider range of coders. The problem of thoroughness and longevity in writing instructional material. Developing awareness of how readers consume and contextualize theory and opinion. How Programming Ruby became the most significant programming reference. Noel’s updated version of this material in his latest book. His blog posts on real-life applications of Ruby and the feedback he receives. How he goes about framing blog posts as opinion or instruction. Determining what community consensus is. The bewilderment that often accompanies onboarding sessions. Research and learning leading up to writing and publishing the book. Feedback and reviews on the book. Links Mentioned in Today’s Episode: Noel Rappin Noel Rappin on X Programming Ruby  How Not to Use Static Typing in Ruby  David Copeland Talk  Better Know a Ruby Thing  How To Manage Duplicate Test Setup, Or Can I Interest You in Weird RSpec?   Better Know a Ruby Thing: On The Use of Private Methods Standardrb Rails Test Prescriptions Programming Ruby: A Pragmatic Programmer’s Guide  The Bike Shed Joël Quenneville on LinkedIn Support The Bike Shed Support The Bike Shed

40분
9월 17일

440: When we stray from Rails defaults

When does it make sense to step away from Rails conventions? What are the limits of convention over configuration? While Rails conventions provide a solid foundation, there are times when customization is necessary to meet specific project needs. In this episode, Joël and Stephanie dive into the tradeoffs of breaking away from Rails defaults. They explore the limits of convention over configuration and share their experiences with customizing beyond the typical Rails setup. Joël offers insights from a recent project where the client opted for all dry-rb objects, and they unpack the benefits and potential challenges of this approach. Stephanie talks about why people tend to shy away from certain Ruby features and her lessons regarding leveraging callbacks for code development. Explore different testing frameworks, the situations when following Ruby defaults is better, the benefits of the ActiveModel ecosystem, and more! Whether you are a Rails purist or looking to bend the rules, this episode will help you understand the pros and cons of stepping outside the Ruby on Rails box. Don’t miss it! Key Points From This Episode: Joël shares details about a large-scale refactoring initiative he has been working on. Stephanie’s recent legacy-code production problem and lessons from her experience. What Joël would have done differently when building his refactoring initiative. The problems of renaming background applications during code development. Why the open-close principle is valuable for making class changes to a system. Reasons that a migration strategy is vital for navigating new and legacy code. Explore approaches for overcoming synchronization issues between systems. Learn about the concept of connascence for coupling systems together. Considerations for using asynchronous tools with a connascence approach. Practical ways to maintain naming consistency during code development. The importance of differentiating between web and business-logic layers. Situations where relying on callbacks for connascence becomes problematic. Other issues that callback problems can reveal during code development. Joël unpacks the scenarios where he deviates from the Ruby on Rails standard. Frameworks for testing code and final takeaways from Joël and Stephanie. Links Mentioned in Today’s Episode: 'Refactoring Legacy Code with the Strangler Fig Pattern' Connascence of Name (CoN) ActiveModel docs GitHub | activemodel 'Vanilla Rails is plenty' GitHub | minitest GitHub | test-unit Episode 435: Cohesive Code with Jared Norman Ruby on Rails The Bike Shed Joël Quenneville on LinkedIn Support The Bike Shed Support The Bike Shed

43분

모두 보기(447개)

4.9

최고 5점

122개의 평가

Valuable for All Developers

2023. 04. 11.

Rintel

I am a Python developer and derive a lot of value and enjoyment from the podcast despite the fact that the hosts are Ruby developers. The podcast does an excellent job in presenting topics of interest to all software developer, so don’t be put off by the hosts “day jobs.”
Informative and just plain good radio

2022. 05. 19.

zman603

The two co-hosts have chemistry and the show is also well edited. It wouldn't surprise me if somebody on the team has radio experience. The show sounds like a bubbly chat ar the coffee machine between two senior engineers. On the technical side it definitely leans toward Ruby on Rails subjects. It doesn't dive deep into any particular topic, so I in that sense can't say I've "learned" anything from it. It's a good way to stay aware of current software trends. It's where I first heard about Tailwind CSS or that Cypress tests help you write more accessible websites. I often leave an episode with the thought, "Oh, that sounds cool. Let me check this out." From the topics covered it sounds like the hosts are in their 30s. They're drifting away from technical questions and more toward project management and leadership. For example "How do we mentor junior devs in a remote office?" or "How do I balance my time between managing and building?" One final kudos: so many people talk a big game about accessibility. They walk the walk. Each episode has a full transcript.
2 yrs of listening

2021. 04. 13.

bnmounir

One of the best tech podcasts. Highly recommend!
Great podcast! I always learn something new.

2020. 06. 05.

Dr. Oktober

Despite being a side project of Thoughtbot, this podcast is surprisingly well produced and always has interesting guests and topics. Even though it might seem a bit lazy, I actually like that they source a lot of their guests internally because it seems like all the guests and hosts are automatically a lot more comfortable with each other and can dive right into deeper topics. I also like that they bounce around different ecosystems and don't only talk about Ruby or Elixir or JS or whatever. A really unique and fun podcast.