Podcast appearances and mentions of jason swett

In this special crossover episode, we make a slight departure from our typical format to chat with Adrian and Yaro from the Friendly Show and Jason from the Code with Jason podcast about a topic near and dear to our hearts: organizing regional Ruby conferences. Adrian is the organizer of Friendly.rb in Bucharest. Jason is the organizer of Sin City Ruby in Las Vegas. And as long-time listeners may know, Jeremy co-organized Blue Ridge Ruby in Asheville, NC back in 2023.

In this episode of Code with Jason, host Jason Swett interviews Prarthana Shiva, a senior software engineer at NexHealth, who shares how her team is handling massive database scaling challenges. Prarthana explains their PostgreSQL database's growth to 24 terabytes (with projections to triple within a year) and details their innovative solutions including read replicas, Elasticsearch implementation, Redis caching, external write-ahead logs, and optimized vacuuming processes. The conversation also touches on Jason's own database challenges with his CI platform and concludes with Prarthana's upcoming presentation at Sin City Ruby 2025, where she'll discuss their transition from schema-based to row-based multi-tenancy for better scalability.Prarthana Shiva on LinkedInSin City Ruby

Join us for a fascinating episode where we explore the development of SaturnCI—a new and user-friendly Continuous Integration tool that arose from frustrations with existing solutions like CircleCI and GitHub Actions. Our guest, Jason Sweat, shares his passion for creating a platform that not only simplifies the user experience but actively incorporates feedback from early adopters. Through candid conversations, Jason recounts his journey as a content creator in the Ruby community, and how it inspired him to address the shortcomings he observed in CI tools.We delve into the technical challenges faced as SaturnCI grows, particularly those relating to user scalability as it onboarded new customers. Jason offers valuable insights into his tech stack choices while drawing attention to the importance of creating streamlined interfaces that cater to developers' needs. The conversation shifts to the foundation of community through his upcoming Sin City Ruby conference, showcasing the efforts made to facilitate connection among participants and ensure each attendee leaves with new friendships and knowledge.Toward the end of our episode, we touch upon Jason's unique approach to outreach through his snail mail newsletter, where he shares insights and stories beyond technology. This creative endeavor highlights how stepping away from screens can cultivate a deeper connection with the audience. With an inviting conversational tone and enriching discussions, this episode is packed with valuable insights for anyone interested in CI tools, community-building, and finding the courage to innovate within your space. Be sure to subscribe and share your thoughts with us!Send us some love.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

This podcast episode features a lively conversation between Jason Swett and Nick Schwaderer, covering a range of topics from Thanksgiving traditions to Ruby conferences, personal philosophies, and even the idea of starting a long-format, freeform podcast. They discuss their approaches to cooking turkey, the quirks of different Thanksgiving side dishes across the U.S., and the experience of celebrating American holidays abroad. The conversation then shifts to Sin City Ruby and Rails World, with Nick reflecting on how conferences create strong community bonds. They also delve into personal growth, handling adversity, and the importance of resilience in career and life.

In this episode, Jason, Chris, and Andrew catch up with each other before diving into a conversation with Jason Swett. Jason, an author, speaker, and creator, discusses his monthly snail mail newsletter "Nonsense Monthly" and the upcoming Sin City Ruby conference scheduled for April 2025 in Vegas, Baby! The discussion then shifts to various topics surrounding software testing, including the challenges of test setup, duplication in tests, and the philosophical aspects of tests as specifications. Jason also talks about his latest book, "Professional Rails Testing" and his experiences and insights on consulting and improving technical leaders. Hit download now to hear more!HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you. Jason Charnes X/Twitter Chris Oliver X/Twitter Andrew Mason X/Twitter

Jason Swett and Irina Nazarova discuss the revitalization of the Ruby community, focusing on the announcement of Sin City Ruby 2025 in Las Vegas. They highlight the importance of small, intimate gatherings for networking, insights from past events, the resurgence of Ruby meetups in San Francisco, and the role of mentorship in fostering growth.- Evil Martians- Martian Events- Sin City Ruby

At Rails Conf 2024, I gathered several of our favorite ruby podcasters for a giant crossover episode! In this episode we have: * Drew Bragg from Code and the Coding Coders Who Code It - https://podcast.drbragg.dev/ * Julie J from Ruby For All - https://www.rubyforall.com/ * Jason Swett from Code with Jason - https://www.codewithjason.com/ * Joël Quenneville from The Bikeshed - https://bikeshed.thoughtbot.com/ Sponsors Honeybadger (https://www.honeybadger.io/) As an Engineering Manager or an engineer, too much of your time gets sucked up with downtime issues, troubleshooting, and error tracking. How can you spend more time shipping code and less time putting out fires? Honeybadger is how. It's a suite of monitoring tools specifically for devs. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!

In this episode of 'Ruby for All', host Andrew is joined by guest Drew Bragg to talk about the ins and outs of the Sin City Ruby conference. Drew provides a comprehensive breakdown of the event, highlighting the mix of technical and lifestyle talks presented, the benefits of regional conferences for building community and networking, and the unique atmosphere that smaller, regional conferences offer. Additionally, the episode covers the importance of Ruby and Rails in current technology, personal experiences with speaking and organizing community events, and thoughts on the future of regional programming conferences. The conversation concludes with Drew emphasizing the value of these gatherings in strengthening the Ruby community and encouraging participation in future events. Hit download now to hear more! [00:00:29] Drew introduces himself and tells us what he does, and Andrew explains why he didn't attend the conference and what he did instead. [00:02:45] Drew talks about his game show-style talk he gave, which is interactive and challenges attendees' knowledge of esoteric Ruby syntax. [00:05:31] Andrew brings up seeing Jason's talk and the attendee makeup at Sin City Ruby, noting many new faces and speculating on the impact of regional conferences bringing in local attendees who might not travel to larger conferences. [00:07:51] Andrew asks about the speakers' dinner, which Drew describes as a communal eating experience. [00:11:42] Drew explains the first day began with a forced socialization event which Drew found more pleasant in a smaller conference setting.[00:12:44] Andrew inquires about the style of talks at Sin City Ruby, wondering if there was a particular focus. Drew describes the conference as having a mix of topics with some technical, business-related, and lifestyle-oriented tasks related to Ruby and Rails. [00:14:01] Drew mentions enjoying Stéfanni Brasil's talk, Jason's live coding dressed as Elvis was very entertaining and hilarious, and Obie Fernandez's closing keynote offering a different perspective on AI's impact on the industry.[00:15:40] Regarding lack of recordings at the conference, Drew sees benefits form a speaker's perspective, and acknowledges that recordings can be valuable for review and as a portfolio asset. [00:18:41] Drew prefers speaking at smaller conferences for the close-knit atmosphere and better audience interaction but acknowledges that larger conferences have their own advantages.[00:21:12] Andrew asks what went well with this conference, and Drew explains he appreciates the laid-back nature and mentioned the relaxed atmosphere set by organizer Jason Swett made the event feel more like a meetup.[00:24:23] Drew shares that he didn't find any aspect of the conference that didn't go well and praises the simplicity of regional conferences like Sin City Ruby.  He emphasizes the convenience of Vegas as a conference location. [00:25:40] Discussing Vegas itself, both Andrew and Drew enjoyed visiting Hoover Dam and the overall experience of connecting with people with shared interests in Ruby.  They also touch on having fun people-watching and the vibrant environment of “Old Vegas.”[00:27:55] Drew's takeaway from the conference is the reaffirmation of Ruby and Rails' potential and expresses enthusiasm for the talks he attended, singling out Tom Rossi's as particularly energetic and engaging. [00:31:01] Drew promotes the idea of attending or organizing local conferences for their intimate nature and the connections they foster. He gives a shout-out to several upcoming Ruby conferences. [00:32:05] Find out where you can follow Drew and his podcast online.Panelist:Andrew MasonGuest:Drew BraggSponsors:GoRailsHoneybadgerLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteDrew Bragg X/TwitterDrew Bragg MastodonDrew Bragg WebsiteCode and the Coders who Code it Podcast Sin City Ruby 2024 (00:29) - Sin City Ruby: Drew's Introduction (02:45) - Game Show Talk: Testing Ruby Knowledge (05:31) - New Faces at Sin City Ruby (07:51) - Speakers' Dinner: A Communal Experience (11:42) - Forced Socialization: Networking Made Easy (12:44) - Talk Styles: Technical to Lifestyle (14:01) - Highlight Talks: From Elvis to AI (15:40) - The No-Recording Debate (18:41) - Small vs. Large: Conference Dynamics (21:12) - What Made Sin City Ruby Shine (24:23) - The Simplicity of Regional Conferences (25:40) - Vegas Adventures: Beyond the Conference (27:55) - Ruby's Vibrant Future and Energetic Talks (31:01) - The Value of Local Conferences (32:05) - Following Drew: Online and Beyond

Jason Swett is well-known in the Rails community for his podcast, Code with Jason, and his book, The Complete Guide to Rails Testing. Jason joins us to talk about his recent transition back into consulting after working for companies for the past few years. He shares about various projects he's been working on, building his personal brand, and his newest coaching service.Jason is also hosting the 2nd iteration of Sin City Ruby at the Tropicana Las Vegas! Get your ticket and come meet Jason, Jeremy, Jess and a host of other Ruby friends!Links:TwitterWebsiteBookSin City RubyMentioned:Friendly.rb talkMillion Dollar Consulting, Alan Weiss

Matt and Jason talk about Service Objects and try to answer the question "do we need them?"This season of YAGNI was made possible by our friends at Flipper Cloud - Are big launches stressing you out? Then you need feature flags!Flipper Cloud helps your team deploy the code now and then roll out features when you're good and ready. Get started for free atflippercloud.ioJason Swett on Twitter // Code with JasonMatt Swanson on Twitter // arrows.toJason's Snail Mail newsletterBrevity is the soul of wit

Joël has been integrating a third-party platform into a testing pipeline...and it has not been going well. Because it's not something she usually keeps up-to-date with, Stephanie is excited to learn about more of the open-source side of things in Ruby, what's new in the Ruby tooling world, and what folks are thinking about regarding the future of the language. Today's topic is inspired by an internal thoughtbot Slack thread about writing a custom matcher for Rspec. Stephanie and Joël contrast DSLs vs. Object APIs and also talk about: CanCanCan vs Pundit RSpec DSL When is a DSL helpful? Why not use both DSLs & Object APIs? Extensibility When does a DSL become a framework? This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. RubyKaigi 2023 (https://rubykaigi.org/2023/) Mystified by RSpec's DSL? by Jason Swett (https://www.codewithjason.com/mystified-rspecs-dsl-parentheses-can-add-clarity/) Building Custom RSpec Matchers with Regular Objects (https://thoughtbot.com/blog/building-custom-rspec-matchers-with-regular-objects) FactoryBot (https://github.com/thoughtbot/factory_bot) Writing a Domain-Specific Language in Ruby by Gabe Berke-Williams (https://thoughtbot.com/blog/writing-a-domain-specific-language-in-ruby) Capybara (https://teamcapybara.github.io/capybara/) Acceptance Tests at a Single Level of Abstraction (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) CanCanCan (https://github.com/CanCanCommunity/cancancan) Pundit (https://www.capvidia.com/products/pundit) Discrete Math and Functional Programming (https://www.amazon.com/Discrete-Mathematics-Functional-Programming-VanDrunen/dp/1590282604) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a little bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been integrating a third-party platform into our testing pipeline for my client. It has not been going well. We've been struggling a little bit, mostly just because tests just kind of crash. Our testing pipeline is pretty complex. It's a lot of one script, some environment variables, does a few things, shells out to another script, which is in a different language. Does a few more things, shells out to another script, maybe calls out to rake, calls out to a shell script. There are four or five of these in a chain, and it's a bit of a mess. Somewhere along in there, something is not compatible with this third-party service that we're trying to integrate with. I was pairing this week with a colleague. And we were able to reproduce a situation where we were able to get a failure under some conditions and a success under other conditions. So these are basically, if we run the whole chain of scripts that call each other from the beginning, we know we get a failure. And if we skipped entirely the chain of scripts that set up things and then just manually try to invoke a third-party service, that works. And so now we know that there's something in between that's incompatible, and now it's just about narrowing things down. There are a few different approaches we could take. We could try to sort of work our way forward. We know a known point where it breaks and then just try to start the chain one step further and see where it fails. We could try to get fancy and do a binary search, like split it in half and then half and half again. We ended up doing it the other way, where we started at the end. We had our known good point and then just stepping one step back and saying, okay, now we introduce the last script in the chain. Does that work? Okay, that pass is great. Let's go one step further; two scripts up in the chain. And at some point, we find, okay, here's the one script that fails. Now, what is it within this script? And it was a really fun debugging session where we were just narrowing things down until we found the source of the bug. STEPHANIE: Wow, that sounds pretty complicated. It just seems like there are so many layers going on. And it was really challenging to pinpoint where the source of the issue was. JOËL: Definitely. I think all the layers made it really complicated. But having a process that we could follow and then kind of narrowing it down made it almost mechanical to figure out where the bug was once we got to a point where we had a known good point and a known bad point. STEPHANIE: Yeah, that makes sense. Kind of sounds like if you are using git bisect or something like that to narrow down the scope of where the issue could be. I'm curious because this is like a bunch of shell scripts and rake tasks or commands or whatever. What would have made this debugging process easier? JOËL: I think having fewer scripts in this chain. STEPHANIE: [laughs] That's fair. JOËL: We don't need so many scripts that call out to each other in different languages trying to share data via environment variables. So we've got a bit of a Rube Goldberg machine, and we're trying to patch in yet another piece in there. STEPHANIE: Yeah, that's really tough. I was curious if there was, I don't know, any logging or any other clues that you were getting along the way because I know from experience how painful it is to debug that kind of code. JOËL: It's interesting because I feel like normally logging is something that's really useful. In this particular case, we run into an exception at some point. So it's more of under what conditions does the exception happen? The important thing was to find that there is a point where it breaks, and there's a point where it doesn't, and realizing that if we ran some of these commands just directly without going through the whole pipeline, that things did work and that we were not triggering that exception. So all of a sudden, now that tells us, okay, something in our pipeline is wrong. And then we can just start narrowing things down. So yeah, adventures in debugging. Sometimes it's really frustrating, but then when you have a good process, and you find the bug, it's incredibly satisfying. STEPHANIE: I like that you used a process that can be applied to many different problems, in this particular case, debugging a testing pipeline. Maybe not something that we do every day, but certainly, it comes up, and now we have tools to address those kinds of issues as well. JOËL: So my week has been up and down with all of this debugging. What's been new in your world? STEPHANIE: I've been doing some travel planning because I'm going to RubyKaigi in Japan. JOËL: Whoa. STEPHANIE: This is actually going to be my first international conference, so I'm really looking forward to that. I just have never been compelled to travel abroad to go to a tech conference. But I'm really looking forward to going to RubyKaigi because now I've been to the U.S.-based conferences a few times. And I'm excited to see how things are different at an international conference and specifically a RubyKaigi because, obviously, there's a lot of really cool Ruby work happening over there in Japan. So I'm excited to learn about more of the open-source side of things of Ruby, what's new in the Ruby tooling world, and just what folks are thinking about in terms of the future of the language. That's not something I normally keep super up-to-date on. But I'm excited to be around people who do think and talk about these things a lot and maybe get some new insights into my own work. JOËL: Do you find that you tend to keep up more with some of the frameworks like Rails rather than the underlying language itself? STEPHANIE: Yeah, that's a good question. I do think because the framework changes a little more frequently, new releases are kind of more applicable to the work that I'm doing. Whereas language updates or upgrades are a little bit less top of mind for me because the point is that it doesn't have to change [laughs] all that much, and we can continue to work with things as expected and not be disrupted. So it is definitely like a whole new world for me, but I'm really looking forward to it. I think it will be really interesting and just kind of a whole other space to explore that I haven't really because I've usually been focused on more of the web development and industry work side of things. JOËL: What's a Ruby feature that either is coming out in the future or that came out in the last couple of releases that got you really excited? STEPHANIE: I think the conversation about typing in Ruby is something that has been on my radar but has also been ebbing and flowing over time. And I did see a few talks at RubyKaigi this year that are going to talk about how to introduce gradual typing in Ruby. And now that it has been out for a little bit and people have been using it, how people are feeling about it, pros and cons, and kind of where they're going to take it or not take it from there. JOËL: Have you done much TypeScript? STEPHANIE: I have been working more in TypeScript recently but did spend most of my front-end work coding days in JavaScript. And so that transition itself was pretty challenging for me where I suddenly felt a language that I did know pretty well. I was having to be in that...in somewhat of a beginner's mindset again. Even just reading the code itself, there were just so many new things to be looking at in terms of the syntax. And it was a difficult but ultimately pretty rewarding experience because the way I thought about JavaScript afterwards was much more refined, I think. JOËL: Types definitely, I think, change the way you think about code; at least, that's been my experience. STEPHANIE: Yeah, absolutely. I haven't gotten the pleasure to work with types in Ruby just yet, but I've just heard different experiences. And I'm excited to see what experts have to say about it. JOËL: That's the fun of going to a conference. STEPHANIE: Absolutely. So yeah, if any listeners are also headed to RubyKaigi, yeah, look out for me. JOËL: I was recently having a conversation with someone about the fact that a lot of languages provide ways to sort of embed many languages within them. So the Lisp family of languages are really big into macros and metaprogramming. Some other languages are big into giving you the ability to build your own ASTs or have really strong parsing capabilities so that you can produce your own, again, mini-language. And Ruby does this as well. It's pretty popular among the Ruby community to build DSLs, Domain-Specific Languages using some of Ruby's built-in abilities. But it seems to be a sort of universal need or at the very least a universal desire among programmers. Have you ever found yourself as a code author wanting to embed a sort of smaller language within your application? STEPHANIE: I don't think I have, to be honest. It's a very interesting question. Because I think the motivation to build your own mini-language using Ruby would have to be you'd have to have a really good reason for it, and in my experience, I haven't quite encountered that yet. Because, yeah, it seems like a lot of upfront work, a lot of overhead to introduce something like that, especially if it's not necessarily either a really, really particular domain that others might find a use for, or it just doesn't end up seeming worthwhile if I can just write regular, old Ruby code. JOËL: I think you're not alone. I think the Ruby community has been kind of a bit of a pendulum here where several years ago, everything that could be made into a DSL was. Now the pendulum kind of has been swinging the other way. And we see DSLs, but they're not quite as frequent. For those who maybe have not experienced a DSL or aren't quite familiar with the concept, how would you describe the idea? STEPHANIE: I think I would describe domain-specific languages as a bit of a mini-language that is created for a very particular problem space in mind to make development for that domain easier. Oftentimes, I've also kind of seen people describe the benefit of DSLs as being able to read that language as if it were plain English. And so, in my head, I have kind of, at least in the Ruby world, right? We see that a lot in different gems. RSpec, for example, has its own internal DSL, and many people really enjoy it because it took the domain of testing. And the way you write it kind of is how you might read or understand it in English. And so it's a bit easier to talk about what you're expecting in your tests. JOËL: Yeah, it's so high-level and minimal and domain-specific that it almost stops feeling like it's a programming language and can almost feel like it's a high-level configuration for this very particular domain, sometimes even to the point where the idea is that a non-programmer could read it and understand what's going on. STEPHANIE: I think RSpec is actually one of the first Ruby DSLs that you might encounter when you're learning Ruby for the first time. And I've definitely seen developers who are new to Ruby, you know, they're writing code, and they're like, okay, I'm ready to write a test now. And the project uses RSpec because that's what most of us use in our Rails applications. And then they see, like you said, almost a configuration language, and they are really confused. They're not really sure what they're reading. They struggle with the syntax a lot. And it ends up being a point of frustration when they're first starting out if they're not just copying and pasting other existing RSpec tests. I'm curious if you've seen that before. JOËL: I've definitely seen that. And it's a little bit ironic because oftentimes, an argument for DSL is that it makes things simpler that you don't even have to know Ruby; you can just write it. It's simpler. It's easier to write. It's easier to understand. And to a certain extent, maybe that's true. But for someone who does know Ruby and doesn't know your particular little domain language, now they're encountering something that they don't know. And they're having to learn it, and they're having to struggle with it. And it might behave a little bit weirdly compared to how Ruby normally works. And so sometimes it doesn't make it easier for adoption. But it does look really good in a README. STEPHANIE: That's totally fair. I think the other thing that's interesting about RSpec is that a lot of it is really just stylistic. I actually read a blog post by Jason Swett and the headline of it was "Mystified by RSpec's DSL? Some parentheses can add clarity." And he basically goes on to tell us that really RSpec is just leaning on some of Ruby's syntactic sugar of omitting parentheses for method calls. And if you just add the parentheses back in your it blocks or your describes, it can read a lot more like regular Ruby. And you might have a better time understanding what's going on when you realize that we're just passing our descriptors as arguments along with some blocks. JOËL: That's ironic given that oftentimes, the goal of these is to make it look like not Ruby. STEPHANIE: I agree; it is ironic. [laughs] MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: I think another drawback that I've seen with DSLs is that they oftentimes are more limited in their capabilities. So if the designer of the gem didn't explicitly think of your use case, then oftentimes, it can be really hard to extend or to support edge cases that are not specifically designed for that language in the way that plain Ruby is often much more flexible. STEPHANIE: Yeah, that's really interesting because when a gem does have some kind of DSL, a lot of effort probably went into making that the main interface that you would work with or you would use. And when that isn't working for your use case, the design of the underlying objects may or may not be helpful for the changes that you want to make. JOËL: I think it's interesting that you mentioned the underlying objects because those are often sort of not meant for public consumption when you're building a gem that's DSL forward. I think, in many cases, my ideal gem would make those underlying objects the primary interface and then maybe offer DSL as a kind of nice-to-have layer on top for those situations that maybe aren't as complex where writing things in the domain language might actually be quite nice. But keeping those underlying objects as the interface, it's nice to use and well-documented for the majority of people. STEPHANIE: Yeah, I like that too because then you can get the best of both worlds. So speaking of trying to make a DSL work for you, have you ever experienced having to kind of work around the DSL to get the functionality you were hoping to achieve? JOËL: So I think we're talking about the idea of having both a DSL and the underlying objects. And RSpec is a great example of this with their custom matchers. RSpec itself is a DSL, but then they also offer a DSL to allow you to create custom matchers. And it's not super well documented. I always forget how to define them, and so I oftentimes don't bother. It's just kind of too much of a pain for something that doesn't always provide that much value. But if it were easy, I would probably do it more. Eventually, I realized that you could use just regular Ruby objects as custom matchers. And they just seemed to respond to certain methods, just regular old objects and polymorphism. And all of a sudden, now I'm back into all of the tools and mechanisms that I am familiar with, like the back of my hand. I can write objects all day. I can TDD them. I can apply any patterns that I want to if I'm doing something really complicated. I can extract helpers. All of that works really well with the knowledge that I already have without having to sink a lot of time into trying to learn the built-in DSL. So, for the most part, now, when I define custom matchers, I'll often jump directly to creating a regular object and making it conform to the matcher interface rather than relying on the DSL for that. So once we go back to the test, now we're back in DSL land. Now we're no longer talking in terms of objects so much. We'll have some nice methods and they will all kind of read like English. So to pull a recent example that I worked on, I might say something like expect this policy object method to conform to this truth table. STEPHANIE: That's a really interesting example. It actually kind of sounds like it hits the sweet spot of what you were describing earlier in the sense that it has a really nice DSL, but also, you can create your own objects, and that has an interface that you can implement. And yes, have your cake and eat it too. [laughs] But the idea that then you're kind of converting it back to the DSL because that is just what we know, and it has become so normalized. I was talking earlier about okay; when is a DSL worthwhile? When is the use case a good reason to implement it? And especially for gems that I think that are really popular that we as a Ruby community have collectively used most of the time on our projects because we have oftentimes a lot of the same problems that we're solving. It seems like this has become its own shared language, right? JOËL: Yeah, there are definitely some DSLs that we all end up learning because they're just so prominent in the Ruby community, even Rails itself ships with several built-in DSLs. STEPHANIE: Yeah, absolutely. FactoryBot is another one, too. It is a gem by thoughtbot. And actually, in preparation to talk about DSLs with you today, I scoured our blog and found a really great blog post, "Writing a Domain-Specific Language in Ruby" by Gabe Berke-Williams. And it is basically like, here's how to write something like FactoryBot and creating your own little mini Ruby DSL for something that would be very similar to what FactoryBot does for fixtures. JOËL: That's a great resource, and we'll make sure to link that in the show notes. We've been talking about some of the limitations of DSLs or some aspects of them maybe that we personally don't like. What are maybe examples of DSLs that you do enjoy working with? STEPHANIE: Yeah, I have an example for this one. I really enjoy using Capybara's DSL for acceptance testing. I did have to go down the route of writing some custom selectors for...I just had some HTML elements within kind of a complicated table and was trying to figure out how to write some selectors so that I could write the test as if it were in, you know, quote, unquote, "plain English" like, within this table, expect some value. And that was an interesting journey. But I think that it really helped me have a better understanding of accessibility of just the underlying building blocks of the page that I was working with. And, yeah, I really appreciate being able to read those tests from a user perspective and kind of know exactly what they're doing when they're interacting with this virtual browser without having to run it in headful mode and see it for myself. JOËL: It's always great when a DSL can give you that experience of abstracting enough to where it makes the code delightful to work with while also not having too high a cost to learn or being too restrictive in what it allows you to do. Would you make a difference between something that's a DSL versus maybe just code that's written at a higher level of abstraction? So maybe to get back to your example with Capybara, it's really nice to have these nice custom matchers and all of these things to work with HTML pages. If I'm writing, let's say, a helper method at the bottom of a test, I don't think that feels quite like it's a DSL yet. But it's definitely a higher level than specifying CSS selectors. So would you make a difference between those two things? STEPHANIE: That's a good question. I think it's one of those you know it when you see it kind of questions because it just depends on the amount of abstraction, like you mentioned, and maybe even metaprogramming. That takes something from the core language to morph into what you could qualify as a separate language. What do you think about this? JOËL: Yeah, part of me almost wonders if this exists kind of on a continuum, and the boundary might be a little bit fuzzy. I think there might be some other qualifications that come with it as well. Even though DSLs are typically higher-level helpers, it's usually more than just that. There are also sort of slightly different semantics in the way that you would tend to use them to the point where while they may be just Ruby methods, we don't use them like Ruby methods, and even to the point that we don't think of them as Ruby methods. To go back to that article you mentioned from Jason, where just reminding people, hey, if you put params on this, all of a sudden, it helps you remember, oh, it's just a Ruby method instead of being like, oh, this is a language keyword or something. STEPHANIE: Yeah, I wonder if there's also something to the idea of domain specificity where it should be self-service within the domain that you're working. And then it has limitations once you are trying to do something separate from the domain. JOËL: Right, it's an element of focus to this. And I think it's probably also a language is not just one helper; it's a collection typically. So it's probably a series of high-level helpers, potentially. They might not be methods, even though that is ultimately one of the primary interfaces we use to run code in Ruby. So it's a collection of methods that are high-level, but the collection itself is focused. And oftentimes, they're meant to be used in a way where it's not just a traditional method call. STEPHANIE: Right. There's some amount of you bringing to the table your own use case in how you use those methods. JOËL: Yeah, so it might be mimicking a language keyword. It might be mimicking the idea of a configuration. We see that a little bit with ActiveRecord and some of the, let's say, the association and validation APIs. Those kind of feel like, yes, they're embedded in a class, but they feel like either keywords or even just straight-up configuration where you set key-value pairs of things to configure how a particular class is going to work. STEPHANIE: Yeah, that's true for a lot of things in Rails, too, if we're talking about routes and initializers as well. JOËL: So I've complained about some things I don't like about DSLs. I really like the routing DSL in Rails. STEPHANIE: Why is that? JOËL: I think it's very compact and readable. And that's an element that's really nice about DSLs is that it can make things feel very readable and, oftentimes, we read code more often than we write it. And routes have...I was going to say fewer edge cases, but I have seen some really gnarly route files that are pretty awful to work with, especially if you're mostly writing RESTful controllers, and I would recommend that people do. It's really nice to just be able to skim through a route file and be like, oh, these are the resources in my app and the actions I can do on each resource. And here are the ones that are nested. STEPHANIE: Yeah, it almost sounds like a DSL can provide guardrails towards the recommended way of tackling that particular domain. The routes DSL really discourages you from doing anything too complicated because they are encouraging you to follow the Rails convention. And so I think that goes back to the specificity piece of if you've written a DSL, it's because you've thought very deeply about this particular domain and how common problems show up and how you would want people to be empowered by the language rather than inhibited by it. JOËL: I think, thinking more about that, the word that comes to mind is declarative. When you read code that's written with DSLs, typically, it's very declarative. It's more just describing a thing as opposed to either procedural, a series of commands to do, or even OO, where you're composing objects and sending messages to each other. And so problems that lend themselves to being implemented through more descriptive and declarative approaches probably are really good candidates for a DSL. STEPHANIE: Yeah, I like that a lot because when we talk about domains, we're not necessarily talking about a business domain, which is kind of the other way that some folks think about that word. We're talking about a problem space. And the idea of the language being declarative to describe the problem space makes a lot of sense to me because you want it to be flexible enough for different use cases but all within the idea of testing or browser navigation or whatever. JOËL: Yeah. I feel like there's a lot of... there are probably more problems that can be converted to declarative solutions than might initially kind of strike you. Sometimes the problem isn't quite as bounded. And so when you want customizations that are not supported by your DSL, then it kind of falls apart. So I think a classic situation that might feel like something declarative is authorization. Authorization are a series of rules for who can access what, and it would seem like this is a great case for a DSL. Wouldn't it be great to have just one file you can just kind of skim, and we can just see all of the access rules? Access rules that are basically asking to be done declaratively. And we have gems like that. The original CanCan gem and then the successor CanCanCan are trying to follow that approach. Have you used either of those gems? STEPHANIE: I did use the CanCanCan gem a while ago. JOËL: What was your experience with that style of authorization? STEPHANIE: It has been a while but I do remember having to check that original file of like all the different authorizations kind of repeatedly coming back to it to remember, okay, for this rule, what should be allowed to happen here? JOËL: So I think that's definitely one of the benefits is that you have all of your rules stored in one place, and you can kind of scan through the list. My experience, though, is that in practice, it often kind of balloons up and has all of these edge cases in it. And in some earlier versions, I don't know if that's still a problem today, it could even be difficult to accomplish certain things. If you're going to say that access to this particular object depends not on properties of that object itself but on some custom join or association or something like that, that could be really clunky to do or sometimes impossible depending on how esoteric it is or if there's some really complex custom logic to do. And once you're doing something like that, you don't really want to have that logic in your...in this case, it would be the abilities file but inside because that's not really something you express via the DSL anymore. Now you're dropping into OO or procedural world. STEPHANIE: Right. It seems a bit far removed from where we do actually care about the different abilities, especially for one-off cases. JOËL: That is interesting because I feel like there's a bit of a read-versus write-situation happening there as well. It's particularly nice to have, I think, everything in one abilities file for reading and for auditing. I've definitely been in code where there's like three or four ways to authorize, and they're all being used inconsistently, and that's not nice at all. On the other hand, it can be hard with DSL sometimes to customize or to go beyond the rules that are built in. In the case of authorization, you've effectively built a little mini-rules engine. And if you don't have a good way for people to add custom rules without just embedding procedural code into your abilities file, it's going to quickly get out of hand. STEPHANIE: Yeah, that makes sense. On the topic of authorization, you did mention an example earlier when you were writing a policy object. JOËL: I've generally found that that's been my go-to pattern for authorization. I enjoy the Pundit gem that provides some kind of light scaffolding around working with policy objects, but it's a general pattern, and you can absolutely write your own. You don't need a gem for that. Now we're definitely not in the DSL world. We're not doing this declaratively. We're leaning very heavily on OO and saying we're just going to create objects. They talk to each other. They can do anything that any Ruby object can do and as simple or as complex as they need to be. So you have the full power of Ruby and all the patterns that you're used to using. The downside is it is a little bit harder to read and to kind of just audit what's happening in terms of permission because there's no high-level overview anymore. Now you've just got to look through a bunch of classes. So maybe that's the trade-off, flexibility, extensibility versus more declarative style and easy overview. STEPHANIE: That makes a lot of sense because we were talking earlier about guardrails. And because those boundaries do exist, that might not give us the flexibility we want compared to just writing regular Ruby objects. But yeah, we do get the benefit of, like you said, auditing, and at least if we don't try to do some really gnarly, custom stuff, [laughs] something that's easier to read and comprehend. JOËL: And, again, maybe that's where in the best of both worlds situation, you say, hey, I'm creating some form of rules engine, whether it's for describing routes, or authorization, permissions, or users can build custom business rules for a product or something like that. And it's all object-based under the hood. And then, we provide a DSL to make it nice to work with these rules. If a programmer using our gem wants to write a custom rule that just really extends what the ones we shipped can do, allow them to do that via the object API. We have all the objects available to you that underlie the DSL. Add more rules yourself. And then maybe those can be plugged back into the DSL like we saw with the RSpec and custom matchers. Or maybe you have to say, okay, if I have a custom rule object, now I have to just stay in the object space. And I think both of those solutions are okay. But now you've sort of kept those two worlds separate and still allowed people to extend. STEPHANIE: I like that as contributing to the language because language is never static. It changes over time. And that's a way that people can continue to evolve a language that may have been originally written at a certain time and place. JOËL: Moving on from DSLs, we got some listener feedback recently from James, who was listening to our episode on discrete math. And James really appreciated the episode and wanted to share a resource with us. This is the book "Discrete Math and Functional Programming" by Thomas VanDrunen. It's an introduction to discrete math as a theoretical concept taught side by side with the very practical aspect of learning to use the language standard ML, and both of those factor into each other. So you're kind of learning a little bit of theory and some practice, at the same time, getting to implement some discrete math concepts in standard ML to get a feel for them. Yeah, I've not read this book, but I love the concept of pairing a theoretical piece and a practical piece. So I'll drop a link to it in the show notes as well. Thank you, James. STEPHANIE: Yeah, thanks, James. And I guess this is just a little reminder that if our listeners have any feedback or questions they want to write in about, you can reach us at hosts@bikeshed.fm. JOËL: On that note. Shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: 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. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Big thanks to Jason for coming on the show and giving us a discount code for his book to share with you!

Jason Swett is the author of the Complete Guide to Rails Testing. We covered Jason's experience with testing while building relatively small Ruby on Rails applications. Our conversation applies to just about any language or framework so don't worry if you aren't familiar with Rails.A few topics covered:- Listen to advice but be aware of its context. Something good for a large project may not apply to a small one- Fast feedback loops help us work quicker and tests are great for this- If you don't involve things like the database in any of your tests your application may not work at all despite your tests passing- You may not need to worry about scaling at the start for smaller or internal applications - Try to break features into the smallest pieces possible so they can be checked in and reviewed quickly- Jason doesn't remember the difference between a stub and a mock because he rarely uses themRelated Links:- Code with Jason- The Complete Guide to Rails Testing- Code With Jason PodcastTranscript:[00:00:00] Jeremy: today I'm talking to Jason Swett, he's the author of the complete guide to rails testing, a frequent trainer and conference speaker. And he's the host of the code with Jason podcast. So Jason, welcome to software sessions. [00:00:13] Jason: Thanks for having me. [00:00:15] Jeremy: from listening to your podcast, I get a sense that the size of the projects you work on they're, they're relatively modest.Like they're not like a super huge thing. There, there may be something that you can fit all within your head. And I was wondering if you could talk a little bit to that first, so that we kind of get where your perspective is and the types of projects you work on are.[00:00:40] Jason: Yeah. Good question. So that is true. Most of my jobs have been at small companies and I think that's probably typical of the typical developer because most businesses in the world are small businesses. You know, there's, there's a whole bunch of small businesses for every large business. And so most of the code bases I've worked on have been not particularly huge.And most of the teams I've worked on have been relatively small And sometimes so small that it's just me. I'm the only person working on the application. I, don't really know any different. So I can't really compare it to working on a larger application. I have worked at, I worked at AT&T so that was a big place, but I was at, AT&T just working on my own solo project so that wasn't a big code base either.So yeah, that's been what my experience has been like.[00:01:36] Jeremy: Yeah. And I, I think that's interesting that you mentioned most people work in that space as well, because that's basically where I fall as well. So when I listened to your podcast and I hear you talking about like, oh, I have a, I have a rails project where I just have a single server and you know, I have a database and rails, and maybe I have nginx in front, maybe redis it's sort of the scale that I'm familiar with versus when I hear podcasts or articles, you know, I'm reading where they're talking about, oh, we have 500 microservices or we have 200 instances of the application.That's, that's not a space that I've, I've worked in. So I, I found it helpful to, to hear, you know, from you on your show that like, Hey, you know, not everybody is working on these gigantic projects.[00:02:28] Jason: Yeah. Yeah. It's not terribly relatable when you hear about those huge projects.And obviously, sometimes, maybe people earlier in their career can get the wrong idea about what's applicable to their situation. I feel like one of the most dangerous kinds of advice is advice that's good advice, but it's good advice for somebody else.And then I've, I've. Been victim of that, where I get some advice and maybe it's genuinely good advice, but it's not good advice for me where I am doing what I'm doing. And so, I apply the advice, but it's not the right thing. And so it doesn't work out for me. So I'm always careful to like asterisk a lot of the things I say where it's like, Hey, this is, this is good advice if you're in this particular situation, but maybe not for everybody.And really the truth is I, I try not to give advice these days because like advice is dangerous stuff for that very reason.[00:03:28] Jeremy: so, so when you mentioned you try not to give advice and you have this book, the complete guide to rails testing, would you not describe what's in the book as advice? I'm kind of curious what the distinction is there.[00:03:42] Jason: Yeah, Jeremy, right after I said that, I'm like, what am I talking about? I give all kinds of advice. So forget, I said that I totally give advice. But maybe not in certain things like like business advice or anything like that. I do give a lot of advice around testing and various programming things.So, yeah, ignore that part of what I said.[00:04:03] Jeremy: something that I found a little bit unique about rails testing was that a lot of the tests are centered around I guess you could call it like a full integration test, right? Because I noticed when working with rails, if I write a test, a lot of times it's talking to the database, it's talking to if, if I.Have an API or I have a website it's actually talking to the API. So it's actually going through all the layers and spinning up a database and all that. And I wonder if you, you knew how that work, like each time you run a test, is it creating a new database? So that each test is isolated or how does all that stuff actually work?[00:04:51] Jason: Yeah, good question. First. I want to mention something about terminology. So I think one of the most important things for somebody who's new to testing to learn is that in our industry, we don't have a consensus around terminology. So what you call an integration test might be different from what I call an integration test.The thing you just described as an integration test, I might call an acceptance test. Although I happen to also call it an integration test cause I use that terminology too, but I just wanted to give that little asterisk for the listener, because if they're like, wait, I thought an integration test was this.And not that anyway, you asked how does that work? So. It is true that with those types of rails tests, and just to add more terminology into the mix, they call those system tests or system specs, depending on what framework you're using. But those are the tests that actually instantiate a browser and simulating user input, exercise, the UI of the application.And those are the kinds of tests that like show you that everything works together. And mechanically how that works. One layer of it is that each test runs in a database transaction. So when you, you know, in order to run a certain test, maybe you need certain records like a user. And then I don't know if it's a scheduling test, you might need to create an appointment and whatever. All those records that you create specifically for that test that's happening inside of a database transaction. And then at the end of the test, the transaction is aborted. So that none of the data you create during the test actually gets persisted to the database. then regarding the whole database, it's not actually like creating a new database instance at the start of each test and then blowing it away.It's still the same database instance is just the data inside of each test is not being persisted at. [00:07:05] Jeremy: Okay. So when you run. What you would call, I guess you called it an acceptance test, right? Where it's going, it's opening up your website, it's clicking through the website, creating records, things like that. That's happening in a database instance that's created for, I guess, for all your tests that all your tests get to reuse and rails is automatically wrapping your test in a transaction.So even if you're doing five or 10 database queries at the end of all, that they all get rolled back because they're all within the same transaction.[00:07:46] Jason: Exactly. And the reason why we want to do that. Is because of a testing principle that you want your tests to be runnable in any order. And the key thing is you want your tests to be deterministic. So deterministic means that the starting state determines the in-state and it's the same every time, no matter what.So if you have tests a, B and C, it shouldn't be the case that you can run them in the order, ABC, and they all pass. But if you do it CBA, then test a fails because it should only fail. If something's actually wrong, it shouldn't fail for some other reason, like the order in which you run the tests. And so to ensure that property of deterministic newness we need to make it so that each test doesn't leak into the other tests.Cause imagine if that. Database transaction. thing didn't happen. And it's, it's only incidental that that's achieved via database transactions. It could conceivably be achieved some other way. That's just how this happens to work in this particular case. But imagine if no measure was taken to clean up afterward and I, I ran a test and it generated an appointment.And then the test that runs after that does some tests that involves like doing a count of appointments or something like that. And maybe like, coincidentally, my second test passes because I've always run the tests in a certain order. and so unbeknownst to me, test B only passes because of what I did in test a that's bad because now the thing that's happening is different from what I think is happening.And then if it flipped and when we ran it, test B and then test a. It wouldn't work anymore. So that's why we make each test isolated. So it can be deterministic.[00:09:51] Jeremy: and I wonder if you've worked with any other frameworks or any other languages, and if you found that the approaches and those frameworks or languages is similar to rails, like where it creates these, the transaction for you, does the rollback for you and all of that.[00:10:08] Jason: Good question. I have to plead ignorance. I've dabbled a little bit in testing and some other languages or frameworks, but not enough to be able to say anything smart about it. [00:10:22] Jeremy: Yeah, I mean in my experience and of course there are many different frameworks that I'm not familiar with, but in a lot of cases, I I've seen that they don't have this kind of behavior built in, like, they'll provide you a way to test your application, but it's up to you if you want to write code that will wrap everything in a transaction or create a new database instance per test, things like that.That's all left up to you. so I, I think it's interesting that that rails makes that decision for you and makes it to where you don't really have to think about that or make that decision. And for me personally, I found that really helpful.[00:11:09] Jason: Yeah, it's really nice. It's a decision that not everybody is going to be on board with. And by that decision, I mean the general decision of rails to make a lot of decisions for you. And it may not be the case that I agree with every single decision that rails has made, but I do appreciate that that the rails team or DHH, or whoever has decided that rails is just going to have all these sensible defaults.And that's what you get. And if you want to go tweak that stuff, I guess you can, but you get all this stuff this way. Cause we decided what we think is the best way to do it. And that is how most people use their, their rails apps. I think it's great. It eliminates a lot of overhead and then. Use some other technologies, I've done some JavaScript stuff and it's just astonishing how much boiler plate and how many, how much energy I have to expend on decisions that don't really matter.And maybe frankly, decisions that I'm not all that equipped to make, because I don't have the requisite knowledge to be able to make those decisions. And usually I'd rather just have somebody else make those decisions for me. [00:12:27] Jeremy: we've been talking about the more high level tests, the acceptance tests, the integration tests. And when you're choosing on how to test something, how do you decide whether it should be tested that, that level, or if it should be more of a unit level tests, something, something smaller[00:12:49] Jason: Good question. So I want to zoom out just a little bit in order to answer that question and come at it from a distance. So I recently conducted some interviews for a programmer job. I interviewed about 25 candidates, most of those candidates. Okay. And the first step of the interview was this technical coding exercise. most of the candidates did not pass. And maybe, I don't know. Five or six or seven of the candidates out of those 25 did pass. I thought it was really interesting. The ones who failed all failed in the same way and the ones who passed all passed in the same way. And I thought about what exactly is the difference.And the difference was that the programmers who passed, they coded in feedback loops. So I'll say that a different way, the ones who failed, they tried to write their whole program at once and they would spend 15, 20 minutes carefully writing the program. And then at the end of that 20 minutes, they would try to run it.And unsurprisingly to me the program would fail like on line 2 of 30, because nobody's smart enough to write that much code and have the whole thing work. And then the ones who did well. They would write maybe one line of code, run it, observe what happens, compare what they observed to what they expected to see, and if any corrections were needed, they made those corrections and ran it again.And then only once their expectations were satisfied, did they go and write a second line and they would re repeat that process again, that workflow of programming and feedback loops I think is super important. And I think it's what distinguishes, Hmm. I don't exactly want to say successful programmers from unsuccessful programmers, but there's certainly a lot to do with speed.like, think about how much slower it is to try to write your whole program, run it and see that it fails. And then try to find the needle in the haystack. It's like, okay, I just wrote 30 lines. There's a problem somewhere. I don't know where, and now I have to dig through and find it It's so much harder than if you just write one line and you see a problem and you know, that, that problem lines in that line, you just wrote.So I say all that, because testing is just feedback loops automated. So rather than writing a line and then manually running your program and using your own judgment to compare what you observed to what you expected to see you write a test that exercises your code and says, I expect to see this when this happens.And so the kind of test you write now to answer your question will depend first on the nature of the thing you're writing. But for like, if we take kind of the like typical case of, let's say I'm building a form that will allow me to create a customer in a system. And I put in the first name, last name and email address of the customer. that's a really basic like crud functionality thing. There's not a lot of complexity there. And so I am, to be honest, I might just not write a test at all and we can get into how I decide when to write a test and when not to, but I probably would write a test. And if I did, I would write a system spec to use the rails are spec terminology that spins up a browser.I would fill in the first name field with a first name, fill in the last name field with the last name, email, with email click, the submit button. And then I would assert that on the subsequent page, I see some indicator of success. And then if we think about something that. Maybe more involved, like I'm thinking about some of the complicated stuff I've been working on recently regarding um, coming up with a patient's balance in the medical system that I work on.That's a case where I'm not going to spin up a browser to check the correctness of a number. Cause that feels like a mismatch. I'm going to work at a lower level and maybe create some database records and say, when I, when I created this charge and when I create this payment, I expect the remaining balance to be such and such.So the type of test I write depends highly on the kind of functionality.[00:17:36] Jeremy: So it sounds like in the case of something that's more straight forward, you might write a high level test, I guess, where you were saying I just click this button and I see if the thing I expected to be created is there on the next page. And you might create that test from the start and then just start filling in the code and continually running that test you know, until it passes.But you also mentioned that in the case of something simple like that, you might actually. Choose to forego the tests and just take a look you know, visually you open the app and you click that same button and you can see the same result. So I wonder if you could talk a little bit more about how you decide, like, yeah, I'm going to write this test or no, I'm just going to inspect a visually[00:18:28] Jason: Yeah. So real quick before I answer that, I want to say that it's, it's not one of the tests is straightforward or the feature is straightforward that determines which kind of test I write, because sometimes the acceptance test that I write, which spins up a browser and everything. Sometimes that might be quite an involved test and in complicated feature, or sometimes I might write a lower level test and it's a trivially simple one.It has more to do with um, What's, what's the thing that I care about. Like, is it primarily like a UI based feature that, that is like the meat of it? Or is it like a, a lower level, like calculation type thing or something like that? That's kind of what determines which kind of right. But you asked when would I decide not to write a test.So the reason I write tests is because it's just like cost prohibitive to manually perform testing, not just in monetary terms, but like in emotional pain and mental energy and stuff like that. I don't want to go back and manually test everything to make sure that it's still working. And so the ROI on writing automated tests is almost always positive, but sometimes it's not a positive ROI.And so when I don't write it down, It's if these conditions are true, if the cost of that feature braking is extremely low. And if the I'll put that if, if the consequences of the feature breaking are really small and the frequency of the usage is low and the cost of writing the test is high, then I probably won't write a test.For example, if there's some report that somebody looks at once every six months and it's like some like maybe a front desk person who uses the feature and if it doesn't work, then it means they have to instead go get the answer manually. And instead of getting the answer in 30 seconds, it takes them five.Extremely low cost to the failure. And it's like, okay, so I'm costing somebody, maybe 20 bucks once every six months, if this feature breaks. And let's say this test is one that would take like an hour for me to write. Clearly it's better just to accept the risk of that feature breaking once in a while, which it's probably not going to anyway. So those are the questions I ask when I decide and, and to, to be clear, it's not like I run through all those questions for every single test I write in the vast, vast majority of cases. I just write the test because it's a no-brainer that it's, that it's better to write the test, but sometimes my instincts tell me like, Hey, is this really actually important to write a test for?And when I find myself asking that, then I say, okay, what's the consequences of the breakage? How hard is this test to write all that. [00:21:46] Jeremy: So you talked about the consequences being low, but you also talked about maybe the time to write the test being high. What are the types of tasks that, that take a long time to write?[00:21:58] Jason: Usually ones that involve a lot of setup. So pretty much every test requires some data to be in place data, either meaning database, data, or like some object structure or something like that. Sometimes it's really easy sometimes to set up is extremely complicated. and that's usually where the cost comes in.And then sometimes, sometimes you encounter like a technical challenge, like, oh, how do I like download this file? And then like inspect the contents of this file. Like sometimes you just encounter something that's like technically tricky to achieve. But more frequently when a test is hard to write it's because of the setup is hard.[00:22:49] Jeremy: and you're talking about set up being, you need to insert a whole bunch of different rows into your database or different things that interact with one, another things like that.[00:23:02] Jason: Exactly. [00:23:03] Jeremy: when you're testing a system and you create a database that has all these items in it for you to work with, I'm assuming that what's in your test database is much smaller than what's in the real database. So how do you get something that's representative so that if you only have 10 things in your tasks, but in production, there's thousands of them that you can catch that, Hey, this isn't going to work well, once it gets to production,[00:23:35] Jason: Yeah. that's a really interesting question. And the answers that I don't like, I usually don't try to make the test beta test database representative of the production database in terms of scale, obviously like the right data has to be there in order to exercise the test that it has to be true. But I don't, for example, in production at this moment I know there's some tens of thousands of appointments in the database, but locally at any given time, there are between zero and three or, or So appointments in any particular test, that's obviously nowhere near realistic, but it's only becomes relevant in a great, great minority of cases with, with regard to that stuff, the way I approach that is rather to So I'm thinking about some of those through the, for the first time right now, but obviously with performance in general premature optimization is usually not a profitable endeavor. And so I'll write features without any thought toward performance. And then once things are out there and perform it in production observe the bottlenecks and then fix the bottlenecks, starting with what's the highest ROI.And usually tests haven't come into the picture for me. It's cause like, okay. The reason for tests again is, so you don't have to go back and do that manual testing, but with these performance improvements, instead of tests, we have like application performance monitoring tools, and that's what tells me whether something needs an issue or people just say like, Hey, this certain page is slow or whatever.And so tests would be like redundant to those other measures that we have that tell us if there's performance.[00:25:38] Jeremy: Yeah. So that sorta touches on what you described before, where let's say you were writing some kind of report or adding a report and when you were testing it locally, it worked great generated the report. Uh, Then you pushed it out to production. Somebody went to run it and maybe because of an indexing problem or some other issue It times out, or it doesn't complete takes a long time, but I guess what you're saying is in a lot of cases, the, the consequences of that are not all that high.Like the person will try it. They'll see like, Hey, it doesn't work. Either you'll get a notification or they'll let you know, and then that's when you go in and go like, okay, now, now we can fix this.[00:26:30] Jason: Yeah. And I think like the distinction is the performance aspect of it. Because like with a lot of stuff, you know, if you don't have any tests in your application at all, there's a high potential for like silent failure. And so with the performance stuff, we have other ways of ensuring that there won't be silent failure.So that's how I think about that particular.[00:26:56] Jeremy: I guess another thing about tests is when you build an application, a lot of times you're not just interacting with your own database, you're interacting with third-party APIs. You may even be connecting to different pieces of hardware, things like that. So when you're writing a test, how do you choose to approach that?[00:27:23] Jason: yeah, good question. This is an area where I don't have a lot of personal experience, but I do have some there's another principle in testing that is part of the determinism principle where you don't want to involve external HTTP requests and stuff like that in your tests. Because imagine if I run my test today, And it passes, but then I run my test tomorrow and this third-party API is down and my test fails the behavior of my program didn't change. The only thing that's different is this external API is down right now. And so what I do for, for those is I'll capture the response that I get from the API. And I'll usually somehow um, get my hands on a success response and a failure response and whatever kind of response I want to account for.And then I'll insert those captured responses into my tests. So that then on every subsequent run, I can be using these canned values rather than hitting the real API.[00:28:37] Jeremy: I think in your um, the description of your book, you mentioned a section on, on stubs and mocks, and I wonder what you're describing here, which of those two things, is it? And what's the difference?[00:28:53] Jason: Yeah. it's such a tricky concept And I don't even trust myself to say it right every time that I want to remind myself of the difference between mocks and stubs. I have to go back to my own blog posts that I wrote on it and remind myself, okay, what is the difference between a mock and a stub? And I'll just say, I don't remember.Because this isn't something that I find myself dealing with very frequently. It's something that people always want to know about at least in the rails world. But I'll speak for myself at least. I don't find myself having to use or wanting to use mocks and stubs very much.I will say that both mocks and stubs are a form of a testable. So a mock is a testable and a stub is a testable and a testable. It's like a play on stunt double instead of using a real object or whatever it is, you have this fake object. And sometimes that can be used to like trick your program into behaving a certain way or it can be used to um, gain visibility into an area that you otherwise wouldn't have visibility into.And kind of my main use case for mocks and stubs when I do use them, is that when you're testing a particular thing, You want to test the thing you're interested in testing. You don't want to have to involve all the dependencies of the thing you're testing. And so I will like stub out the dependencies.So, okay. Here's an example. I have a rare usage of stubs in my, in my uh, test suite and dear listener. I'm going to use the word stub. Don't give too much credence to that. Maybe. I mean, mock, I don't remember. But anyway, I have this area where we determine a patient's eligibility to get a certain kind of medicine and there's a ton that goes into it and there's all these, like, there's, there's these four different, like coarse-grained determinations and they all have to be a yes in order for it to overall be a yes.That they can get this medicine. It has to do with mostly insurance. And then each one of those four core course grain determinations has some number of fine grain determinations that determines whether it is a yes or a no. If I weren't using mocks and stubs in these tests, then in order to test one determination, I would have to set up the conditions.This goes back to the setup, work stuff we talked about. I'd have to set up all the conditions for the medicine to be a yes. In addition to, to the thing I'm actually interested in. And so that's a waste because that stuff is all irrelevant to my current concern. Let me try to speak a little bit more concretely.So let's say I have determinations ABC. When I'm interested in determination, a I don't want to have to do all the setup work for determinations, B, C, and D. And so what I'll do is I'll mock the determinations for B, C and D. And I'll say for B, just have the function returned true for C same thing, just return true for D return.True. So it'd like short circuits, all that stuff and bypasses the actual logic that gives me the yes, no determination. And it just always gives me a yes. That way. There's no setup work for B, C, and D. And I can focus only on.[00:32:48] Jeremy: And I think it may be hard to say in this example, but would you, would you still have at least one test that would run through and do all the setup, do the checks for ABC and D and then when you're doing more specific things start to put in doubles for the others, or would you actually just never have a full test that actually did the complete setup?[00:33:14] Jason: well, here's how I'm doing this one. I described the scenario where I'm like thoroughly testing a under many different conditions, but stubbing out B, C and D. They don't have another set of tests where I thoroughly test B and stub out a C and D. And so on. I have one thorough set for, for each of those. If you're asking whether I have one that like exercises, all four of them, No.I just have ones for each of the four individually, which is maybe kind of a trade off. Cause it's arguable that I don't have complete confidence because I'm never testing the four together. But in the like trade off of like setup?work and all that, that's necessary to get that complete con confidence and the value of that, like additional, because really it's just like a tiny bit of additional con confidence that I would get from testing all those things together.In that particular case, my judgment was that that was not worth [00:34:19] Jeremy: yeah. Cause I was thinking from their perspective of sometimes I hear that people will have a acceptance test that covers sometimes you hear people call it the happy path, right. Where they everything lines up. It's like a very straightforward case of a feature. But then all the different ways that you can test that feature, they don't necessarily write tests for those, but they just write one for the, the base case.And then, like you said, you actually drill down into more specifics and maybe only test a, a smaller part there, but it sounds like in this case, maybe you made the decision that, Hey, doing a test, that's going to test all four of these things, even in the simplest case is going to involve so much setup and so much work that, that maybe it's not, not worth it in this case.[00:35:13] Jason: Yeah. And I'd have to go back and refresh my memory as to like what exactly this scenario is for those tasks. Because in general, I'm a proponent of having integration tests that makes sure multiple things work together. Okay. You might've seen that Gif where it says like um, two unit tests, zero integration tests, and there's like a cabinet with two doors.Each door can open on its own or, or maybe it's drawers. Each drawer can open on its own, but you can't open both drawers at the same time. And so I think that's not smart to have only unit tests and no integration tests. And so I don't remember exactly why I chose to do that eligibility test with the ABC and D the way I did.Maybe it was just cost-prohibitive to do it altogether. Um, One thing that I want to want to comment on regarding mocks and stubs, there's a mistake that's made kind of frequently where people overdo it with mocks and stuff. They misunderstand the purpose. The purpose again is that you want to test the thing you're testing, not the dependencies of the thing.But sometimes people step out the very thing they're testing. And so they'll like assert that a certain method will return such and such value, but they'll stub the method they're testing so that the method is guaranteed to return the same value and that doesn't actually test anything. So I just wanted to make, mention that as a common mistake to avoid [00:36:47] Jeremy: I wonder if you could maybe give an example of when you, you have a certain feature and the thought process you're going through where you decide like, yes, this is the part that I should have a stub or a mock for. And this is the part where I definitely need to make sure I run the code.[00:37:07] Jason: Well, again, it's very rare that I will use a mocker stub and it's not common that I'll even consider it for better or worse. Like we're talking about. The nature of rails tests is that we spin up actual database records and, and test our models with database data and stuff like that. In other ecosystems, maybe the testing culture is different and there's more mocks and stubs.I know when I was doing some coding with angular, there was a lot more mocking and stubbing. But with rails, it's kind of like everything's available all the time and we use the database a lot during testing. And so mocks and stubs don't really come into the picture too much. [00:37:56] Jeremy: Yeah. It's, it's interesting that you, you mentioned that because like I work with some projects that use C-sharp and asp.net, and you'll a lot of times you'll see people say like you should not be talking to the database in your tests. And you know, they go through all this work to probably the equivalent of a mock or a stub.But then, you know, when I, when I think about that, then I go like, well, but I'm not really testing how the database is going to react. You know, are my, are my queries actually valid. Things like that, because all this stuff is, is just not being run. in some other communities, maybe they're they have different ideas, I guess, about, about how to run tests.[00:38:44] Jason: Yeah, And it's always interesting to hear expressions. Like you should do this or you shouldn't do that, or it's good to do this. It's bad to do that. And I think maybe that's not quite the right way to think about it. It's more like, well, if I do this, what are the costs and benefits of doing this? Cause it's like, nothing exactly is a good thing to do or a bad thing to do.It's just, if you do this, this will happen as a consequence. And if you don't this won't and all that stuff. So people who don't want to talk to the database in their tests, why is that? What, what are the bad things they think will happen if you do that? The drawbacks is it appears to me are it's slow to use the database in any performance problem.Usually the culprit is the database. That's always the first thing I look at. And if you're involving the database and all of your tests, your tests are going to be much slower than if you don't use the database, but the costs of not talking to the database are exactly what you said, where you're like, you're not exercising your real application, you're missing an entire layer and maybe that's fine.I've never tried approaching testing in that way. And I would love to like, get some experience like working with some people who do it that way. Cause I can't say that I know for an absolute fact that that doesn't work out. But to me it just makes sense to exercise everything that you're actually using when the app runs.[00:40:18] Jeremy: what's challenging probably for a lot of people is that if you look online for how to do testing in lots of different frameworks, you'll get different answers. Right. And it's not clear what's gonna fit your situation right? And you know, to, to give an example of, we've been talking about how rails will it, it predominantly focuses on tests that, that talks to the database and it wraps everything in a transaction as we talked about before, so that you can reset the state and things like that.I've also seen in other frameworks where they'll say like, oh, you can run a database test, but you use this in-memory version of the database instead of actually talking to a real MySQL or Postgres instance, or they'll say, oh, for this test we're going to use SQLite in place of the Postgres database you're actually using in production.And it, it makes the, the setup, I suppose, easier. Um, And maybe it makes the tests run quicker, but then it's also no longer the same as what you're really running. So there's like a lot of different approaches that, that people describe and take. And I think it can be hard for, for people to know, like what, what makes sense for me.[00:41:42] Jason: Yeah. And this is another area where I have to plead ignorance because again, I don't have experience doing it the other way. Logically, I feel like my way makes sense, but I don't have empirical experience doing it the other way. [00:41:57] Jeremy: we've talked a little bit about how there's cases where you'll say I'm not going to do this thing because it's going to take a lot of time and I've weighed the benefits. And I wonder if you could give some examples of things where you spent a lot of time on something, and then in hindsight, you, you realize like this really wasn't worth it.[00:42:18] Jason: I don't think I have any examples of that because I don't think it tends to happen very much. I really can't emphasize enough how old, the case where I choose not to write a test for something is like a one in 5,000 kind of thing. It's really not something I do frequently. The mistake is overwhelmingly in the opposite direction.Like somebody may, maybe I will get lazy and I'll skip a test and then I'll realize, oh yeah, This is why I write tests because it actually makes everything easier. And uh, we get pain as as a consequence when we skip tests. So that's usually the mistake I make is not writing a test when I should, rather than writing a test when I should not have [00:43:08] Jeremy: So since then, in general, you, you said that not writing it is, is the, the mistake. How do you get people in the habit of. Of writing the tests where they feel like it's not this thing that's slowing them down or is in the way, but is rather something that's helping them with that feedback loop and is something that they actively want to do.[00:43:33] Jason: Yeah. So to me, it's all about a mindset. So there's a common perception that tests are something extra. Like I've heard stories about, like somebody gives a quote for a project and then the prospective client asks like, well, how much, if we skip tests, how much less would that be? And it's like, oh, it wouldn't be less.It'd be like five times more because tests are a time saver. So I want to try to dispel with that notion. But even so it can be hard to bring oneself, to write task because it feels like something that takes discipline. But in my case, I don't feel like it takes discipline. Because I remind myself of a true fact that it's actually the lazy and easy way to code is to code using tests.And it's the harder, more laborious way to write code. Not using tests because think about what's, what's the alternative to not writing tests. Like we said earlier, the alternative is to manually test everything. And that's just so painful, especially when it's some feature where like, I'm sure you have experience with this, Jeremy, you, you make a code change.And then in order to verify that the thing still works, you have to go through like nine different steps in the browser. And only on that last step, do you get that answer you're after. That's just so painful. And if you write a test, you can automate that. Some things that might present friction in that process, or just like a lack of familiarity with how to write tests and maybe a um, a lack of an easy process for writing tests.And just to briefly touch on that, I think something that can help reduce that. Is to write tests in the same way that I write code in feedback loops. So we talked about writing one line, checking, writing, another line, checking that kind of thing. I write my tests in the same way. First I'll write the shell of the test and then I'll run just the shell, even though it seems kind of dumb to just run the shell cause you know, it doesn't do anything. I do that just to demonstrate to myself that I didn't like make some typo or something like that. I'm starting from like a clean baseline. And then I'll write one line of my test. Maybe if I'm writing a system spec, I'll write a line that creates a user of rum that I know that nothing's going to happen when I run the test, but I'll run it just to see it run and make sure there's no errors.And then I'll add a line that says, log the user in and then I'll run that. And so on just one line at a time. There's this principle that I think is really useful when working, which is to separate the deciding what to do from the actually doing it. I think a lot of developers mixed those two jobs of deciding what to do and doing it in the same step.But if, if you separate those, so you'd like, decide what you're going to have your tests do. And then after that, so like maybe I'll open my test and I'll write in comments what I want to achieve, not in technical terms necessarily, but I'll just write a comment that says, create a user, right? Another comment that says, log in another comment that says, click on such and such.And then once I have those, there, I'll go back to that first line and convert that to code. Okay. My comment that says, create a user, I'll change that to the syntax that actually creates a user and again, using the feedback loop. So I'll run that so that I can, you know, once I'm, once I'm done writing all those comments that say what the test does, I'm now free to forget about it.And I don't have to hold that in my mental Ram anymore. And I can clear my mental RAM. Now all my mental RAM is available to bring, to bear on the task of converting my steps that I already decided into working syntax. If you try to do both those things at the same time, it's more than twice as hard. And so that's why I try to separate.[00:48:04] Jeremy: So that's interesting. So it's like you're designing, I guess, the feature, what you want to build in the context of the test first it's would that be accurate?[00:48:19] Jason: that certainly can be the case. So much of this is context dependent. I very regularly give my self permission to be undisciplined and to go on exploratory spikes. And so if I have like very, if I have a really vague idea about what shape a feature is going to take, I give myself permission to forget about tests and I just write some code and I feel cause there's two reasons to write code.You know, a code is not only a work product code is also a thinking. so I would let go into a different mode, I'll say, okay, I'm not trying to create a work product right now. I'm just using code as a thinking medium, to figure out what I'm even going to do. So that's what I'll do in that case. And then maybe I'll write the test afterward, but if it's very clear, what the thing is that I'm going to write, then I'll often write the test first again, in those two phases of deciding what it's going to be and the deciding how it works.And I won't do a thing where, where, like I write 10 test cases and then I go through one by one and write code to make them pass. Usually I'll write one test, make a pass, write a second test, make it pass and so on. [00:49:38] Jeremy: okay. So the more exploratory aspect, I guess, would be when. You're either doing something that you haven't done before, or it's not clear to you what the features should be is, is that right?[00:49:58] Jason: Yeah, like maybe it's a feature that involves a lot of details. There's like a lot of room for discretion. It could be implemented in more than one way. Like how would I write a test for that? If I don't even know what form it's going to take? Like there's decisions to be made, like, what is the, the route going to be that I visit for this feature?What am I even going to call like this entity and that entity and stuff like that. And I think that goes back to my desire to not juggle and manage. Multiple jobs at the same time. I don't want to, I don't want to overly mix the design job with the testing job. Cause testing can help with design, but design in like a code structure sense.I usually don't want to mix testing with like UI design and not even UI design, like, like design in the highest sense. Meaning like what even is this thing? How does it work? Big picture wise and stuff like that. That's not the kind of design that testing helps with in my mind of the kind of design that testing helps with again, is the code structure.So I want to have my big picture design out of the way before I start writing my test. [00:51:21] Jeremy: and in terms of the big picture design, is that something that you keep all in your head or are you writing that down somewhere? I'm just wondering what your process is.[00:51:34] Jason: Yeah, it can work a number of different ways in the past. I've done usability testing where I will do some uh, pen and paper prototypes and then do some usability testing with, with users. And then I will um, convert those pen and paper prototypes to something on the computer. The idea being pen and paper prototypes are the cheapest to create and change.And then the more you cement it, the more expensive it gets to change. So only once I'm fairly certain that the pen and paper prototypes are right. Will I put it into something that's more of a formal mock. And then once I have my formal mock-up and that's been through whatever scrutiny I want to put it through, then I will do the even more expensive step of implementing that as a working feature.Now having said all that, I very rarely do I go through all that ceremony. Sometimes a feature, usually a feature is sufficiently small, that all that stuff would be silly to do. So sometimes I'll start straight with the the mock-up on the computer and then I'll work off of that. Sometimes it's small enough that I'll just make a few notes in a note-taking program and then work off of that.What is usually true is that our tickets in our ticketing system have a bulleted list of acceptance criteria. So we want to make it very black and white. Very yes, no. Whether a particular thing is done and that's super helpful because again, it goes back to the mixing of jobs and separating of jobs.If we've decided in advance that this feature needs to do these four things. And if it does those four things it's done and it doesn't need to do anything more and if it doesn't meet those four criteria, then it's not done then building the thing is just a matter of following the instructions. Very little thinking is involved.[00:53:45] Jeremy: depending on the scope of the feature, depending on how much information you have uh, you could either do something elaborate, I suppose, where, you know, you were talking about doing prototypes or sketches and, and so on before you even look at code or there could be something that's not quite that complicated where you have an idea of what it is and you might even play with code a little bit to get a sense of where it should go and how it should work.But it's all sort of in service of getting to the point where you know enough about how you're going to do the implementation and you know enough about what the actual feature is to where you're comfortable starting to write steps in the test about like, these are the things that are going to happen.[00:54:35] Jason: Yeah. And another key thing that might not be obvious is that all these things are small. So I never work well, I shouldn't say never, but in general, I, don't work in a feature. That's going to be like a week long feature or something like that. We try to break them down into features that are at most like half.And so that makes all that stuff a lot easier. Like I use the number four as an example of how many acceptance criteria there might be. And that's a pretty representative example. We don't have tickets where there's 16 acceptance criteria because the bigger something is the more opportunity there is for the conceive design to turn out, not to be viable.And the more decisions that can't be made, because you don't know the later step until the earlier decision is made and all that kind of stuff. So the small size of everything helps a lot.[00:55:36] Jeremy: but I, I would imagine if you're breaking things into that small of a piece, then would there be parts that. You build and you tasked and you deploy, but to the user, they actually don't see anything. Is that the appraoch?[00:55:52] Jason: definitely, we use feature flags. Like for example, there's this feature we're working on right now, where we have a page where you can see a long list of items. The items are of several different types right now. You just see all of them all the time, but depending on who you are and what your role is in the organization, you're not going to be interested in all those things.And so we want people to be able to have check boxes for each of those types to show or hide those things. Whereas checkbox feature is actually really big and difficult to add. And so the first thing that I chose to do was to have us add just one single check box for one type. And even that one, single checkbox is sufficiently hard that we're not even giving people that yet.We coded it so that you get the check boxes and that one checkbox is selected by default. When you uncheck it, the thing goes away, but it's selected by default so that we can feature flag that. So the checkbox UI is hidden. Everything looks just the way it did before. And now we can wait until this feature is totally done before we actually surface it to users.So it's the idea of making a distinction between deployment and release. Cause if we try to do this whole big thing, it's, it's gonna take weeks. If we try to do the whole thing, that's just too much risk for something to go wrong. And then like, we're going to deploy like three weeks of work at once.That's like asking for trouble. So I'm a huge fan of feature flags. [00:57:35] Jeremy: Interesting. So it's like the, it's almost like the foundation of the feature is going in. And if you were to show it to the user well, I guess in this case, it actually did have a function right at you. You could filter by that one category. [00:57:52] Jason: oh, I was just going to say you're exactly right. It wouldn't be a particularly impressive or useful feature, but what we have is complete it's it's not finished, but it is complete. [00:58:06] Jeremy: I'm not sure if you have any examples of this, but I imagine that there are changes that are large enough that I'm not sure how you would split it up until you, you mentioned like half a days worth of time. And I, I wonder if either have examples of features like that or a general sense of how, what do you do if you, you can't figure out a way to split it up that small.[00:58:34] Jason: I have yet to encounter a feature that we haven't been able to break up into pieces that are that small. So, unfortunately, I can't really say anything more than that because I just don't have any examples of exceptions [00:58:49] Jeremy: For, for people listening, maybe that should be a goal at least like, see if you can make everything smaller, see if you can ship as little as possible, you know, maybe you don't hit that half a day mark, but at least give it a, give it a try and see what you can do.[00:59:10] Jason: yeah. And the way I care would characterize it, maybe wouldn't be to ship as little as possible at a time, but to give a certain limit that you try not to go over. And it's, it's a skill that I think can be improved with practice. You learn certain techniques that you can use over and over. Like for example, one way that I split things up sometimes is we will add the database tables in one chunk. And we'll just deploy that, cause that presents a certain amount of risk, you know, when you're adding database tables or columns or anything like that, like it's always risky when you're messing with the structure of the database. So I like to do just that by itself. And it's kind of tidy most of the time because because it's not something that's like naturally visible to the user is just a structural change.So that's an example of the kind of thing that you learn as you gain practice, breaking bigger things up into smaller pieces. [01:00:16] Jeremy: so, and, and that example, in terms of whatever issue tracking system you use, what, what would you call that? Would you just call that setting up schema for X future features, or I'm just kinda curious how you characterize that.[01:00:35] Jason: yeah, something like that. Those particular tickets don't have great names because ideally each ticket has some amount of value that's visible to the user and that one totally doesn't, it's a purely nuts and bolts kind of thing. So that's just a case where the name's not going to be great, but what's the alternative can't think of anything better. So we do it like that. [01:01:02] Jeremy: you feel like that's, that's lower risk shipping something that's not user-facing first. Then it is to wait until you have at least like one small thing that, you know, is connected to that change.[01:01:19] Jason: Yeah. I had a boss in the past who had a certain conception of the reason to do deployments. And, and her belief was that the reason that you deploy is to deliver value to the user which is of course true, but there's another really good reason to deploy, which is to mitigate risk. The further production and development are able to diverge from one another, the greater, the risk.When you do a deployment. I remember one particular time at that job, I was made to deploy like three months of work at once and it was a disaster and I got the blame because I was the one who did the work. And quite frankly, I was really resentful that that had. And that's part of what informs my preference for deploying small amounts of work at a time.I think it's best if things can be deployed serially, like rather than deploying in patches, just finish one thing, deploy it, verify it, finish the next thing, deploy it, verify it. I have the saying that it's better to be a hundred percent done with half your work than halfway done with a hundred percent of your work. For, for the hopefully obvious reason that like, if, if you have 15 things that are each halfway in progress, now you have to juggle 15 balls in your head. Whereas, if you have 15 things you have to do, and then you finish seven of them, then you can completely forget about those seven things that you finished and deployed and verified and all that.And your mental bandwidth is freed up just to focus on the remaining work. [01:03:10] Jeremy: yeah, that, that makes sense. And, and also if you are putting things out bit by bit, And something goes wrong, then at least it's not all 15 things you have to figure out, which was it. It's just the last thing he pushed out.[01:03:26] Jason: Exactly. Yeah. It's never fun when you deploy a big delta and something goes wrong and it's a mystery. What introduced the problem? It's obviously never good if you deploy something that turns out to be a problem, but if you deployed just one thing and something goes wrong, at least you can. Roll it back or at the very least have a pretty decent idea of where the problem lies. So you can address it quickly. [01:03:56] Jeremy: for sure. Well I think that's probably a good place to leave it off on, but is there anything else about testing or just software in general that you, you thought we should've brought up?[01:04:09] Jason: Well, maybe if I can leave the listener with one thing um, I want to emphasize the importance of programming and feedback loops. It was a real eye-opener for me when I was interviewing these candidates to notice the distinct difference between programmers, who didn't program and feedback loops and programmers, who do I have a post about it?I'm just, it's just called how to program and feedback loops. I believe if anybody's interested in the details. Cause I have like. It's like seven steps to that feedback loop. First, you write a line of code, then you do this. I don't remember all seven steps off the top of my head, but it's all there in the blog post.Anyway, if I could give just one piece of advice to anybody who's getting into programming, it's a program in feedback loops. [01:05:00] Jeremy: yeah, I think that's been the, the common thread, I suppose, throughout this conversation is that whether it's. Writing the features you want them to be as small as possible. So you get that feedback of it being done. And like you said, taking it off of your plate. Then there's the being able to have the tests there as you write the features so that you get that immediate feedback, that this is not doing what the test says it should be doing.So yeah, it makes it, it makes a lot of sense that basically in everything we do try to get to a point where we get a thumbs up, we get at, this is complete. The faster we can do that, the better we'll we'll all be off. Right.[01:05:46] Jason: exactly. Exactly. [01:05:50] Jeremy: if people want to check out your book, check out your podcast, I think you even have a, a conference coming up, right? Uh, where, w where can they learn about that.[01:06:02] Jason: So the hub for everything is code with jason.com. So that's where I always. Send people, you can find my blog, my podcast, my book there. And yeah, my conference it's called sin city ruby. It's a Ruby conference. This will only be applicable dear listener, if you're listening before March 24th, 2022. But yeah, it's, it's happening in Las Vegas.It's going to be just a small intimate conference and it's a whole different story, but I kind of put on this conference accidentally. I didn't intend to do a conference. I just kind of uh, stumbled into it, but I think it will be a lot of fun. But yeah, that's, that's another thing that I have going on. [01:06:49] Jeremy: What, what was it that I guess. Got you into deciding this is, this is what I want to do. I want to make a conference. [01:06:58] Jason: Well, it started off as I was going to put on a class, but then nobody bought a ticket. And so I had to pivot. And so I'm like, okay, I didn't sell any tickets to this class. Maybe I can sell some tickets to a conference. And luckily for me, it turns out I was right because I was financially obligated to a hotel where I had reserved space for the class.So I couldn't just cancel it. I had to move forward somehow. So that's where the conference came. [01:07:28] Jeremy: interesting. yeah, I'm, I'm always kind of curious. How people decide what they want to attend, I guess, like, you know, you said how you didn't get enough signups for your class, but you get signups for a conference. And you know, the people who are signing up and want to go, I wonder to to them, what is, what is it about the going to a conference that is so much more appealing than, than going to a class?[01:07:54] Jason: Oh, well, I think in order to go to a class, the topic has to be of interest to you. You have to be in like a specific time and place. The price point for that kind of thing is usually much higher than for, for a conference. Whereas with a conference it's affordable to individuals, you don't have to get your boss's permission necessarily, at least not for the money. It's more of like a, you don't have to be a specific kind of person in a specific scenario in order to benefit from it. It's a much more general interest. So that's why I think I've had an easier time selling tickets to that. [01:08:31] Jeremy: Mm, mm. Yeah, it's, it's more of a I wanna get into a room with a bunch of people and just learn a bunch of cool stuff and not necessarily have a specific specific thing you're looking to get out of it, I guess.[01:08:46] Jason: Yeah. There's no specific outcome or anything like that. Honestly, it's mostly just to have a good time. That's the main thing I'm hoping to get out of it. And I think that is the main draw for people they want to, they want to see their friends in the Ruby community form relationships and stuff like that. [01:09:07] Jeremy: Very cool. Jason good luck with the conference and thank you so much for coming on software software sessions.[01:09:13] Jason: Thanks a lot. And uh, thanks for having me. 

Lokasyon Sponsorumuz Han Spaces'a teşekkür ederiz. Han Spaces: https://www.hanspaces.com/LİNKLERÜretim Bandı Bülten: https://uretimbandi.substack.com/Ender'in Bahsettiği Teknik Bölümü: https://uretimbandi.com/teknik-ibrahim-acikgoz-mattermost-acik-kaynak-gelistirmek/Lumost: https://lumost.net/Çay Kahve İnsan: https://caykahveinsan.com/KONUŞULANLAR(03:09) İstatistikler(10:25) Yabancı dildeki bölümler(28:34) Yılın Soruları: En aklında kalan bölüm(31:07) En şaşırtan bölüm(34:44) En öğretici bölüm(36:42) Kiminle bölüm çekmek isterdin?(41:48) Önümüzdeki sene(47:31) Teşekkürler-----KONUŞULAN BÖLÜMLEREmre Ertan ile Getir Nasıl Ürün Geliştiriyor? https://uretimbandi.com/getir-nasil-urun-gelistiriyor/Continuous Product Discovery with Teresa Torres:https://uretimbandi.com/continuous-product-discovery-with-teresa-torres/Teknik: Cem Başaranoğlu ile Hepsiburada Nasıl Yazılım Geliştiriyor:https://uretimbandi.com/hepsiburada-nasil-gelistiriyor/Teknik: Rails Testing, Making a Podcast and Developers' Life with Jason Swett:https://uretimbandi.com/rails-testing-podcast-developers-swett/Teknik: Furkan Kılıç ile Boş Zamanlarında Freelance Çalışmak:https://uretimbandi.com/teknik-kilic-ile-bos-freelance/Teknik: Hatice Edis ile Bir Front-End Yolculuğu: https://uretimbandi.com/hatice-edis-frontend-yolculugu/Teknik: Working at Shopify as an Engineer and Being a Ruby Committer with Peter Zhu:https://uretimbandi.com/teknik-shopify-engineer-ruby-committer-peter-zhu/Teknik: Adem İlter ile Video İçerik Üretimi ve Product Designer / Frontend Dev Olmak:https://uretimbandi.com/ilter-video-icerik-product-designer-frontend-olmak/Teknik: Sinan Ege ile Hepsiburada Mobil Nasıl Yazılım Geliştiriyor: https://uretimbandi.com/sinan-ege-ile-hepsiburada-mobil-nasil-yazilim-gelistiriyor/Teknik: Trendyol Mobil Takımı ve Mobil Test Süreçleri: https://uretimbandi.com/trendyol-mobil-takimi-ve-mobil-test-surecleri/Meriç Dağlı – LinkedIn nasıl ürün geliştiriyor?https://uretimbandi.com/meric-dagli-linkedin-nasil-urun-gelistiriyor/Papara Nasıl Ürün Geliştiriyor?https://uretimbandi.com/papara-nasil-urun-gelistiriyor/ Deniz İrgin'le yazılımcı gözünden ürün yönetimi:https://uretimbandi.com/deniz-irginle-yazilimci-gozunden-urun-yonetimi/ Serdar Akın ile büyüyen şirketlerde inovasyon-optimizasyon dengesi:https://uretimbandi.com/serdar-akin-ile-buyuyen-sirketlerde-inovasyon-optimizasyon-dengesi/ Ali Doğacan Aydın ile Otsimo Nasıl Ürün Geliştiriyor?https://uretimbandi.com/ali-aydin-otsimo-nasil-urun-gelistiriyor/Akın Ömeroğlu ile Açık Kaynak Üzerine:https://uretimbandi.com/akin-omeroglu-ile-acik-kaynak/ Teknik: Lemi Orhan Ergin ile Kod İnceleme Süreçleri:https://uretimbandi.com/lemi-orhan-ergin-ile-kod-inceleme-surecleri/ Teknik: Merve İşler – Topluluk Yöneticiliği nedir?https://uretimbandi.com/merve-isler-topluluk-yoneticiligi-nedir/----Üretim Bandı'nın Slack grubu olduğunu biliyor muydunuz? 1500'den fazla ürün yöneticisi, girişimci, yazılımcı, tasarımcının bir arada bulunduğu aktif ürün topluluğuna siz de katılın:>>> uretimbandi.com/slackİki haftada bir yayınladığımız, ürün geliştirmeyle alakalı bültenimizi de aşağıdaki linkten takip edebilirsiniz:>>> uretimbandi.com/bulten

This multi-podcast crossover episode was recorded live at RubyConf 2021 in Denver. In this episode you'll hear Jemma Issroff, Emily Giurleo, Nick Schwaderer, Jason Charnes, Andrew Mason and Jason Swett.

[00:00:28] The panelists introduce themselves.[00:01:37] We hear what everyone is most excited about being at RubyConf and the talks they are most excited about going to.[00:04:11] Jason Swett shares how he prepped for the workshops, and Nick and Emily tell us about their talks. [00:08:13] Jemma asks the panelists why they come to conferences and what brings them here.[00:11:12] Everyone here is a podcaster, so we find out why they do these podcasts.[00:15:11] The panelists share what is so special and unique about the Ruby community.[00:18:59] Find out which podcast episodes the panelists are most proud of that they put out. [00:22:42] What do the panelists think about the diversity of people they bring on to their podcasts? [00:26:33] The panelists all share some great stories about Brittany Martin, how awesome she is, how she's one of the best interviewers, and what a GEM she is!   [00:29:49] Jemma wonders how the panelists stay on top of what's going on in the Ruby community.[00:32:01] The panelists talk about how they, as podcasters, think through what might be interesting to talk about on their podcasts.[00:37:10] Find out who the panelists call their “Ruby Heroes.” [00:44:34] The panelists tell us how they find themselves consistently producing podcast episodes without suffering from burnout. Panelists:Jemma IssroffAndrew MasonJason CharnesEmily GiurleoNick SchwadererJason SwettSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterAndrew Mason TwitterJason Charnes TwitterChris Oliver Twitter Jemma Issroff TwitterEmily Giurleo TwitterNick Schwaderer GitHubJason Swett TwitterRemote Ruby PodcastThe Ruby on Rails PodcastThe Code with Jason PodcastRuby WeeklyPeter Cooper TwitterWNB.rb TwitterRemote Ruby Podcast-Episode 139: Learning in Public | Alpine & Inertia (our mental health episode)Remote Ruby Podcast-Episode 100-Upgrading Rails with Ernesto TagwerkerRemote Ruby Podcast-Episode 97-Joined by Adam Wathan: TailwindCSS, Tailwind UI, and ActionView ComponentsThe Code with Jason Podcast-Episode 28-Sandi Metz, Author of POODR (with Special Guest TJ Stankus)The Ruby on Rails Podcast-Episode 271: MEGA RailsConf 2019 Recap with Chris OliverThe Ruby on Rails Podcast-Episode 385: Minimal Flame Wars (Prettier, Parsing and Regex) with Kevin NewtonObie Fernandez TwitterThe Rails 5 Way (Addison-Wesley Professional Ruby Series) by Obie FernandezAaron Patterson TwitterCollin Jilbert TwitterBrittany Martin TwitterBrandon Weaver Twitter

Recorded live from Rubyconf 2021 in Denver, CO with an audience! Panelists from The Ruby on Rails Podcast, Code with Jason and Remote Ruby gathered to chat about why they were excited to attend Rubyconf, favorite episodes and to field listener questions. Moderated By: Jemma Issroff, The Ruby on Rails Podcast () Panelists: Andrew Mason, Remote Ruby (https://twitter.com/andrewmcodes) Jason Charnes, Remote Ruby (https://twitter.com/jmcharnes) Jason Swett, Code with Jason (https://twitter.com/JasonSwett) Emily Giurleo, The Ruby on Rails Podcast (https://twitter.com/EmilyGiurleo) Nick Schwaderer, The Ruby on Rails Podcast (https://twitter.com/Schwad4HD14) Show Notes & Links: Rubyconf 2021 (https://rubyconf.org/) WNB.rb (https://twitter.com/wnb_rb) Ruby5: A Twice-Weekly 5 Minute Ruby News Podcast (http://www.rubyinside.com/ruby5-ruby-news-podcast-2441.html) Ruby Weekly (https://rubyweekly.com/?m) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform. Go to Honeybadger.io (https://www.honeybadger.io/) and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. Scout APM (http://scoutapm.com/rubyonrails) Try their error monitoring and APM free for 14-days, no credit card needed! And as an added bonus for Ruby on Rails listeners: Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at http://scoutapm.com/rubyonrails (http://scoutapm.com/rubyonrails).

GUESTJason SwettLinkedin: https://www.linkedin.com/in/jasonswett/Twitter: https://twitter.com/jasonswettLINKSCode with Jason: https://www.codewithjason.com/TOPICS(02:13) being more visible to the community(03:08) Starting to write(07:15) Data sets vs tour specs(09:18) Testing(17:23) Mocking(24:18) Code with Jason(27:08) Daily routine (34:53) Logic & epistemology----Üretim Bandı'nın Slack grubu olduğunu biliyor muydunuz? 1000'den fazla ürün yöneticisi, girişimci, yazılımcı, tasarımcının bir arada bulunduğu aktif ürün topluluğuna siz de katılın:>>> uretimbandi.com/slackİki haftada bir yayınladığımız, ürün geliştirmeyle alakalı bültenimizi de aşağıdaki linkten takip edebilirsiniz:>>> uretimbandi.com/bulten

Jason Swett goes over creating a medical app with Rails. It's hosted on AWS using Kubernetes and has been up and running since 2019.

[00:01:02] Chris, Jason, and Andrew tell us the story behind Remote Ruby and how it started.  [00:03:42] Jason Swett tells us the origin of where Rails with Jason came from. [00:04:42] Chris Toomey and Stephanie share the story behind The Bike Shed. [00:07:10] Brittany tells us her story behind The Ruby on Rails podcast. [00:08:07] We find out how Remote Ruby and The Bike Shed are put together and planned out week to week. [00:10:50] Jason Swett and Brittany tell us how they select guests for their podcasts. [00:12:20] Brittany is curious to know if any of the panelists could host the podcast they are currently hosting now if they weren't actively working in Ruby.[00:16:00] Brittany wonders if Steph has ever had a client from thoughtbot say, Hey, were you talking about me, whenever she's talking about her current client on the podcast.[00:16:44] Andrew fills us in on how things have changed for him since he's not working at CodeFund which was an open source thing and people could see what he was actively working on. Now he's working for a company where it's closed source and you might not be able to reveal as much as much what he's working on at any given time.[00:19:32] The topic we discuss here is if there is a way to market the podcasts so that other developers will listen to it, and if there's a way we can make our podcasts accessible to the general software community as opposed to just Ruby.[00:22:23] The panelists share their views on if there is room for more Ruby on Rails Podcasts outside of the ones that are on this episode today. [00:25:15] Brittany is curious and wonders if anyone ever had the funny experience of realizing that you're not just podcasting into the ether and what you're saying and doing matters. [00:28:15] The conversation shifts to legacies which is a good one!  We find out if anybody puts any thought into the legacy of their podcast, whether or not they will stay with it to the end, if they will eventually pass it off, and whether or not they think about it's their responsibility to the community to make sure that it keeps going. [00:32:54] We wrap up this fantastic mega episode with everyone telling us where you can listen to their podcast and where you can follow them online.Host:Brittany MartinPanelists:Chris OliverJason CharnesAndrew MasonStephanie ViccariChris ToomeyJason SwettSponsor:HoneybadgerLinks:Brittany Martin TwitterThe Ruby on Rails PodcastJason Charnes TwitterAndrew Mason TwitterChris Oliver TwitterGo RailsGo Rails TwitterRemote RubyRemote Ruby Twitter Chris Toomey TwitterStephanie Viccari TwitterThe Bike Shed PodcastThe Bike Shed Podcast TwitterJason Swett WebsiteThe Rails with Jason PodcastUpload-Amazon Prime

This is the sweeps week episode, the epic crossover episode, the mega episode! We have a very special episode as Chris, and Steph teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. They cover the origins of their shows, their experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. Remote Ruby (https://remoteruby.transistor.fm/) Rails with Jason (https://www.codewithjason.com/rails-with-jason-podcast/) Ruby on Rails podcast (https://5by5.tv/rubyonrails) *Transcript: * STEPH: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. This week we have a very special episode as Chris, and I teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. This episode was so much fun to record, and we have Brittany Martin to thank as she organized and moderated this special event. So without further ado, here is the mega Ruby episode. BRITTANY: Welcome, everyone. We have a whopping seven podcast hosts recording today. So, listeners, you are in for a treat. This is the sweeps week episode, the epic crossover episode, the mega episode. We're going to need our editor to insert some epic sound effects right here. Announcer: The mega episode. BRITTANY: So let's go ahead and introduce the crew today. I am Brittany Martin from the Ruby on Rails Podcast. CHRIS OLIVER: I'm Chris Oliver from Remote Ruby. JASON CHARNES: I am Jason Charnes, also from Remote Ruby. ANDREW: I am Andrew Mason, also from Remote Ruby. STEPH: And I'm Stephanie Viccari from The Bike Shed. CHRIS TOOMEY: I'm Chris Toomey from The Bike Shed. JASON SWETT: And I'm Jason Swett from Rails with Jason BRITTANY: Today, we're going to cover the origins of our shows, our experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. Now I know personally, I really enjoy the origin story behind Remote Ruby. So, Chris Oliver, could you kick us off with that? CHRIS OLIVER: Yeah, we can go back maybe to the first time that Jason and I met, which was Jason emailed me out of the blue and was like, "Hey, are you going to be at RailsConf?" And I wasn't planning on it, but it was over in Kansas City, like four hours away from me. I was like, "No, I'm not going, but I'll meet you." So we went and drove over there and met and have been friends ever since. And Jason had the idea of doing an online meetup. And I'll let him explain where that started and turned into the Remote Ruby Podcast. JASON CHARNES: I thought it would be a good idea. There weren't any online meetups. This was pre even the idea of shutting down the world for a pandemic. And maybe I was just too soon because I got Chris to speak at the first one, and we had 40, 50 people. I spoke at the next one, and there were 20. And by the third one, there were five of us. So it wasn't really a super sustainable thing for me to do. So Chris and I got together and said, "What if we tried podcasting?" Chris, you hadn't really done your own podcast at that point, had you? CHRIS OLIVER: No, I don't think so. And you and I were just having calls every week or whatever just to hang out and chat. And we were like, why don't we just record that and publish that as a podcast? And here we are. JASON CHARNES: Yeah. So we've been doing that. I think we started in 2018, so yeah, three years in June, and somehow people still keep listening to us talk but probably because we brought along our friend, Andrew. ANDREW: Wow. Okay. No, that's not true. But yes, I was a guest on Remote Ruby before I joined as a host. And not to get into the details, but I was on another podcast, and something went down, and I no longer was on that podcast anymore. And Chris and Jason were like, "Do you want to come hang out with us?" And I was like, [chuckles] "Absolutely." So I started doing that, and at the same time, I also started The Ruby Blend with Nate Hopkins and Ron Cooke. And so we were doing that for a while until that had to tragically shut down. But I'm still here with Jason and Chris. I guess I should also mention that Jason Swett gave me my start in podcasting a month or two after I started full-time as a Rails developer on a now archived show called The Ruby Testing Podcast. BRITTANY: Which is the perfect segue because Jason Swett was also my first opportunity to guest on a podcast. So I was already hosting, but I hadn't guested, which is kind of the opposite order. So, Jason, do you want to tell the origin of where Rails with Jason came from? JASON SWETT: Sure. I'd been involved with podcasting since around 2016. I somehow ended up on the Ruby Rogues Podcast and was on there for maybe a year or so. And then, somehow, I got the idea that I could start my own podcast. And as an experiment, I started a podcast that I called The Ruby Testing Podcast, which I figured was sufficiently narrow that I could get some traction. And to my surprise, guests actually said yes to coming on the show. And also, to my surprise, people actually listened to the podcast. That gave me some confidence. So maybe a year later, I broadened, and I changed from The Ruby Testing Podcast to just Rails with Jason. And I have been doing that for something like two years. BRITTANY: That's fantastic. I want to move to probably our most experienced podcast veteran, and that would be Chris Toomey. When I was learning how to code, I was listening to Giant Robots and then was excited for the transition that The Bike Shed took. Chris, I would love to hear the story of what it was like taking over a really popular podcast and really maintaining the drive behind it. CHRIS TOOMEY: So, as you mentioned, I had done a little bit of podcasting. It was about a six-month run where I was a co-host on Giant Robots, which was the original podcast of thoughtbot. And that was more in the business and sort of how do we build a software company? So at that point, I was running Upcase, which was the subscription learning platform that thoughtbot had. So I was talking about the inner details of the business, and the marketing tests, and A/B tests and things like that that I was doing. And every week, I was sharing my MRR rather transparently in that thoughtbot way that we do. I did that for, like I said, about six months and then took a while off. And in the background, thoughtbot had started up a new podcast called The Bike Shed, and that started October 31st of 2014. So The Bike Shed has been going for a long time now, and that was hosted by Derek Pryor and Sage Griffin. And they ran that for a number of years. I think it was about four years that the two of them worked collectively on that. But at some point, they both moved on from thoughtbot, and there was an opportunity for new hosts to step in. So I took over in August of 2018. So I've been doing this now for about three years. And so, for that first year, I took the opportunity to do a tour around thoughtbot and talk with many different individuals from the company and a handful of people external to thoughtbot. But I knew that there were so many great voices and ideas and points of view within thoughtbot that I really wanted to spend some time getting to know more of them personally and then sharing that as much as I could with the existing audience that The Bike Shed had. But secretly, all along, I was looking for a person to hang out with all the more so, and Steph was the person that was a perfect choice for that. And so, for the past two years, Steph and I have been chatting. And I will send it over to Steph to share a little bit of her point of view on that transition. But from my point of view, it's been fantastic. STEPH: I still remember exactly when we had the conversation. You were running The Bike Shed and doing an incredible job of just having weekly guests. And then you'd reached out to me and said, "Hey, would you be interested in doing an episode?" And I thought, "No, absolutely not. I can't podcast. I can't begin to do this." So you continued to convince me. And finally, you said something that resonated where you were like, "Well, we can just show up and record, and we don't have to publish. We can just see how it goes." I was like, that's a perfect safety net. I'm into that. So I showed up, and I think the first episode that you and I recorded ended up being titled What I Believe About Software. And it was a lot of fun. I realized I have a lot of things to say. And after that, I think it was another month or so. You continued interviewing more guests, but then you reached out to me and asked me if I wanted to be a co-host. And at that point, I was super jazzed about it, and it's been wonderful. It's been a roller coaster. I have learned a ton. BRITTANY: I'm kind of seeing a pattern here where over the last three years, it seems like Remote Ruby came into place, Bike Shed transitioned. That's when I took over as host of the 5by5 Ruby on Rails Podcast. We're going to call it the golden era of the Ruby Podcasts. But for me, I probably have the longest-running podcast. It was started back in 2009 on the 5by5 Network, but it's gone through many different hosts. And so, I took over roughly about three and a half years ago as the main host from Kyle Daigle. And then, just a couple of weeks ago, as I announced on my podcast, we took the podcast independent. We are now just The Ruby on Rails Podcast. And I'm starting to change the model where I'm bringing in more co-hosts. So that way, I can get those regular updates that I really appreciate on all these podcasts we have featured on the show today. I am curious. I want to talk about how we put together the episodes and plan out how everything's going to go down. I know for me, I'm currently a mix of interviews and co-host episodes. So I'd love to hear from Andrew. How do you plan out what Remote Ruby is going to be week to week? ANDREW: This is an easy question because we don't at all. We don't plan. We do have some guests that come on, and sometimes, they may get their Zoom link the day of; who's to say? But we really don't have a plan. We don't talk about what we're going to talk about beforehand. We all just kind of show up, and I think we have that kind of relationship and flow where it always just works. JASON CHARNES: And I think part of that came from actually how Chris and I started the show because we were trying to make it as low stress as possible because we knew if we put a lot of pressure on it, we would stop doing it. Our first episodes were YouTube live links that we just shared out. And then in our next episodes, we were like, oh, we should start using some software to do this. And then eventually, we got an editor, but that same core of let's just keep it fun for better or for worse, I think, also affects our planning. BRITTANY: I've been lucky in the sense that I have guests sit on all three of the episodes. And I do want to give a compliment to The Bike Shed because it is very well run and very well planned. So I want to kick it over to Steph as to how putting together a Bike Shed episode looks. STEPH: Oh, thank you. That's wonderful to hear, by the way. That's wonderful feedback. So we predominantly use Trello to organize our thoughts. So we will have...and as we're capturing community questions that are coming in, so we will capture those on the board. And then, we will have a ticket that represents a particular episode. Usually, on the day of, we'll share some thoughts about, hey, these are the broad topics I'm interested in. And there's usually some hot takes in there, which is fun because the other person doesn't know exactly what's coming, and we can have real honest conversations on the mic. And then, every so often, we'll grab a beer, and we'll go through that list. And we'll chat through what sparks joy. What do we want to talk about? What would we like to respond to? And that's pretty much how we organize everything that we discuss. Chris, is there anything I've left out that you want to add? CHRIS TOOMEY: I think that mostly covers it. We do occasionally have interviews just as a way to keep some variety and different things going on, but primarily it's the sort of what's new in your world? And I find that those episodes are the ones that I think are the most fun to record for Steph and I when it really feels like a sincere conversation. I've recently taken to a segment I call good idea, terrible idea where I'm like, "I'm actually considering this, Steph. What do you think?" And live on-air, I'm getting Steph's feedback, and generally, we're very aligned. But every once in a while, she's like, "That's a terrible idea. Don't do that." And I love those, and I love being able to share that because I think it's really easy to talk about, you know, here's a list of things that are true about software, but really, everything depends. And it's all the nuance. And so, being able to share some of our more pointed experiences and then share the conversation that we have over those is hopefully very valuable to the audience but definitely the thing that I enjoy the most. BRITTANY: So kicking it over to Jason Swett, I really enjoy the interviews that you do. I'm curious, how do you select guests? JASON SWETT: Well, thanks. Selecting guests is tough. I had Peter Cooper on the other day, and I was telling him that I feel like every guest that I get on the show is the last guest I'm ever going to be able to get on the show. But somehow, I keep finding more and more guests. Early on, it was relatively easy because I would just find book authors, or if somebody else does podcasting, then it's fairly obvious okay, you're the kind of person who does podcasts, so I'll invite you. But it's a little bit tough because I don't want to invite people who aren't into podcasting and would be really thrown, although sometimes that happens. But let's see, sometimes I send an email out to my email list, and I'm like, "Hey, I'm looking for guests for my show." Sometimes I just tweet that I'm looking for guests. And sometimes I get some really interesting guests from surprising places. But at least in the start, it was looking for those authors and podcasters and the people who are known in the Ruby community. BRITTANY: I know for me, I strive to have at least 50% of my interviews be with people who've never been on a podcast before. And so that usually involves the top of the episode they're dry heaving into a paper bag. And I'm explaining to them, don't worry, about halfway through the episode, you're not going to remember that you're recording anymore. It'll be fine. And you know what? It's always fine. And so, I do love hearing from a wide variety from the Ruby community just because it really proves just how big it is. So I'm curious, could you host the podcast that you are currently hosting now if you weren't actively working in Ruby? ANDREW: I could because Chris is the one that has all the clout. I could sit back and make dumb jokes and memes during it. And as long as Chris is there, I think we'll be good. JASON SWETT: Yeah, I think I could because a good majority of what we talk about on Rails with Jason actually has nothing to do with Rails, so that would probably actually work out. STEPH: I think yes is the answer. While a lot of our conversations do focus around Ruby and Rails, we often use a lot of other languages and tools, and those are a lot of fun to talk about. So I think I would just talk about whatever new tool or language that I'm using. So I think yes, it would just take a slightly different form but would still be at its core the same where we're still talking about our daily experiments and adventures in web development. BRITTANY: I agree with you, Steph. I will say that it seems like Chris Oliver and Chris Toomey have an endless well of things to talk about just based on what they do day-to-day. CHRIS TOOMEY: I try and go on adventures and then share as much as I can. But to resonate with what Steph was saying there, we try to make the show more generally about software, and it happens to be that it's grounded in Ruby on Rails because the vast majority of the work that we do is in that. And I just recently started a new project. I was given the choice of I could pick any technology I want, and it remains the technology that makes sense to me to be the foundation of an application that I want to maintain for years and years and years. So, on the one hand, I think I could definitely talk about software more generally. I think I'm doing that most of the time. But at the other end of the spectrum, but it's always going to be based on Ruby because I haven't found a thing elsewhere in the world that is better than that. CHRIS OLIVER: I completely agree with that. I probably have a little bit of a unique thing doing a screencast every week. A lot of those are based on I'm building some project, and I need to build some random feature like Stripe Checkout. And that's a good one to do a screencast on and implement in the project. And then, we can also talk about the decisions along the way on the podcast, which is kind of nice. BRITTANY: Yeah, it feels like every week, Chris Oliver is like, yeah, I've created a new open-source library, and I'm fabulous. [laughs] Let me listen to this. CHRIS OLIVER: Too many of them. I'm currently rewriting a lot of the Pay gem. And it's just one of those things where you make a bunch of decisions. And then, if you make an open-source project, people use it in all these different ways that you didn't intend yourself, and so you want to support that. But then you need to rearchitect things in it. It is a lot of learning as you go, which is always a lot of fun. So those I think are really good topics to talk about when you're building something like that. I'm always amazed by how does the Rails core team make these decisions on what should be in the framework and what shouldn't? And what do they want to maintain, and how do they keep it flexible but yet have some sort of rule with how they allow things to be implemented and whatever? It is a very hard job to have. So I get my little taste of that with some open source but not on their level. BRITTANY: I always thought that you had a good contrast to Jason Charnes because Jason works at Podia. And while you do get to work on a lot of really cool technologies, I feel like the stakes are much higher. So you can't just rip out StimulusReflex and put in something else just because it sounds cool that week. And I love how you talk through the pluses and minuses to making a big change within the Podia codebase. JASON CHARNES: Yeah. I haven't really thought about that contrast before, but it's helpful for me even just to talk it out with two other people once a week, and luckily, pretty cool about me just coming on and talking about hey, these are the steps we took to get here. Yeah, it's a cool dynamic. BRITTANY: Steph, have you ever had a client from thoughtbot say, "Hey, were you talking about me?" whenever you're talking about your current client? STEPH: That is one of my fears at times that it will happen [chuckles] although we stay very positive on the show. That's something that's very important to us. There's enough negativity in the world. So we really want to focus on our positive experiences through the week. But there have been times where I'm speaking about some of the challenges or things that we are running into that yes, the engineering team is listening to the podcast, and they're like, "Oh, I heard you talk about this feature that we're working on or this particular challenge." And that's really cool because they get that behind-the-scenes peek to see how Chris and I are chatting about that. But yet they know enough, and they know which project that I'm on that they recognize exactly the technology and the feature that I'm trying to describe. So that has certainly happened, and it can be a lot of fun when it does. BRITTANY: Andrew, how have things changed for you now that you're not working at CodeFund, which was very much like an open-source thing? People could see what you were actively working on. And now you're working for a company where it's closed source. And so, you might not be able to reveal as much as what you're working on at any given point. ANDREW: It's different, but I don't think it's been an issue per se. I'm not like, oh crap, I let that slip, and I didn't mean to. That's not really an issue. I really cherish the time I had at CodeFund. When I think back on my experiences, that was my favorite time just because I was able to do that thing that a lot of people really want to do. I was working as an open-source developer. We were spiking StimulusReflex; that's when we were building up StimulusReflex and trying to build up the community. I joined Ruby. We started the Ruby Blend, and things were going good before a dramatic turn. But in terms of the closed and open source, it hasn't been that big of a shift just because instead of talking about what I'm doing at work, like, I still talk about it, but I speak about it in more general terms. But I also then kind of freed up to talk a lot more about the dumb crap I do on the nights and weekends. BRITTANY: So the majority of our podcasts either have the word Ruby or Rails in it, but I think we've all agreed that a lot of the topics that we're talking about are not specific to that community. But in a lot of ways, I feel that having podcasts in our community is how we're going to keep our community thriving. So I'm curious if anyone has any thoughts around...is there a way to market our podcasts so that other developers will listen to it? I get really excited when I get listener feedback saying, "Hey, I used to do Rails maybe ten years ago, but I've been listening to your podcast, and I really enjoy such and such episode." How can we make our podcasts accessible to the general software community as opposed to just Ruby? CHRIS TOOMEY: One thing that stands out to me about Ruby and Rails is because it's full-stack, because of its foundations, it tends to be holistically about web development. And so, whereas I look at React projects or other JavaScript or different things that are going on, I see a more narrow focus in those frameworks. And with Ruby and Rails, what I love about it is that it's really about building software. It's about building products that are valuable, that deliver value to end-users. And so that being the core of it, that's the story that constantly brings me back to Ruby and Rails. And it's the story that I want to keep telling as much as possible. And it's the thing that keeps me engaged with this community. And so, I think podcasts are a great way to continue to literally tell those sorts of stories and really celebrate that aspect of Ruby and Rails and why it remains such a productive way to build software. CHRIS OLIVER: I think related to that, one of the things that we should talk about more is the draw of Rails was look at what you can do with one person or two people. And I feel like we went down the JavaScript route, and now you need two teams of people, and you end up building bigger stuff. And Hotwire has kind of been like, hey, here's a reminder of what you can do with a very small team. And I think that resonates a lot with a lot of people building startups and trying to build side projects and everything. And that's one that is Rails-related. But there's a ton of people building Hotwire stuff in Laravel too. And they're all very similar. So I think at a certain point, yeah, we're talking about maybe Rails specifically, but you can apply all those things to different frameworks and just different tools. STEPH: I'd like to add on and extend that because I wholeheartedly agree with what both Chris Toomey and Chris Oliver just said. And in addition, a lot of the conversations that we have on The Bike Shed are focused on Ruby and Rails, but then we will extract that particular concept to the point that it really doesn't matter which language that you're using or which framework that you're using. We're talking more about the high level. What's your process? What are you thinking as you're going through and implementing this? And based on more of our recent conversations, you'd think we're more of a Postgres podcast, how much we hype up Postgres, and the things that we can do at the database layer. So I think there are a lot of ways that we can start with a foundation of this is how we're doing it with Ruby and Rails, but then talk about it at a higher level where then it's really applicable for everybody. JASON CHARNES: If talking about one technology defined your podcast, we might as well be a Laravel podcast because we talk about that framework more than we do Rails sometimes. [chuckles] BRITTANY: So that begs the question: is there room for more Ruby and Rails podcasts outside of who's currently on this call? JASON SWETT: I think so. And I mentioned that Peter Cooper was on our podcast a little bit ago. That's something he and I actually talked about in that episode. And I shared the anecdote about how in the new America's founding, Ben Franklin's brother or something like that wanted to start a newspaper. And somebody told him what a dumb idea that was because America already had a newspaper. And people might say, oh, there are already however many Rails podcasts. There are a small handful. But I think there could be ten more Rails podcasts or even more than that potentially because I think people have an appetite for help, and camaraderie, and stuff like that. And I don't think we've nearly bottomed out in terms of satisfying people's appetite for that stuff. JASON CHARNES: Yeah, I agree with that because a lot of times, when I listen to podcasts, the more you get to know someone, that connection becomes what it's about for me. So, yeah, there's plenty of room. I mean, brand it as Ruby and tell me about your life as a developer I'll listen. CHRIS TOOMEY: I'll also throw it out there that the way you framed the question is like, is there room for it? But one of the wonderful things about podcasting as a medium is it is distributed. It's not centralized. You can start up a podcast any day. And I will say, as someone who inherited a popular podcast or a sufficiently popular podcast and just got to run with that, it has been such a wonderful way to get my voice out there and provide opportunities that I want that for everyone. I want everyone to have this ability to speak about the way they think about software and then find like-minded people and be able to build even many communities within the larger community of Ruby on Rails. So beyond the question of, Is there room?” which I definitely think there is, I so wholeheartedly support anyone pursuing this for their own reason. ANDREW: Yeah, I think to bring it all the way back, one thing that Chris, Jason, and I care a lot about is Ruby as a community. The community aspects of Ruby are very important to us. And we're actively trying to build that up and bring in new people and bringing people onto their first podcast. We say it all the time, like, hey, if you want to come on the show, let us know. We've had a few people even, you know, recognition in jobs from that. So to us, that is the payoff of doing the show. Maybe our show is the first time someone learns about Rails. And that to me is the possibility in the future. It's like, how can we market our shows that markets Ruby as well so that this meme of Ruby being dead finally goes away because it's not. I think it's growing. And I think the more and more we push as people who are public figures in this space that we want to bring more people on, that this is a space for everyone, I think that's just kind of the ethos that all of us have, and I think that's great. BRITTANY: So I'm curious, on a lighter note, has anyone had the funny experience of realizing that you're not just podcasting into the ether and that what you're saying and what you're doing matters? For me, I have definitely been at conferences where people will run up and hug me just because they heard my voice, and they are like, "I didn't know what you looked like, but I have your voice memorized," and it just blew my mind. And I was like, "Thank you so much for being such a loyal listener." And it just proves that people are out there listening. ANDREW: I tend to talk very openly about mental health. And I very often fail in public and talk about it. And I've had a lot of people message me and email me over the past three or four years and be like, "Hey, thank you for talking about this thing that's not actually about Ruby. It's not actually about coding, but it's just about being a developer." And those are the emails that make me feel the best. Like, someone who's out there like, "Yeah, I also feel like this. Thank you for speaking about it." JASON SWETT: I had a surreal experience. I went to India in 2019 through RubyConf India. And this guy wanted to take a selfie with me because apparently, he considered me famous. So that was cool and pretty surprising because I definitely didn't consider myself famous. STEPH: My favorite has been when we receive listener questions because it lets us know that people are listening and engaged in the conversation, and I essentially feel like they're part of the conversation. They will write in to us and share anecdotes, or they'll share answers to some of the questions that Chris and I will pose on the show. But every now and then, we will also get an email from someone that says, "Hey, just thanks for doing the show. I listen, and it's great," and that's all they share. And that, to me, is just the most wonderful thing that I could receive. BRITTANY: Some of my favorite episodes from all of your shows is when we get an inside peek into what people are doing, like Andrew moving. Jason Charnes, you putting together a conference was actually some of my favorite episodes of yours, which was really early on, which proves that I'm a Remote Ruby OG. But I loved hearing the inside track as to what organizing a conference is because I think we need to get more content out there about how difficult but how rewarding it is. JASON CHARNES: Yeah, I hadn't really thought about...that was around those times we hadn't done... It feels like it's been ages since we did Southeast Ruby, but Chris and I actually podcasted from the last Southeast Ruby we did. We just met in a room and recorded. But when I started that conference, I didn't have a lot to go on. So I'm more than glad to share because the reason I started is there were no Ruby conferences around me, plus I'm an open book. So for better or for worse, maybe that's good podcast material. JASON SWETT: Side note, it's one of the most enjoyable conferences I've ever been to. JASON CHARNES: Thank you. BRITTANY: I completely agree. I miss the regional conferences. JASON CHARNES: We lucked out because we were already planning on skipping 2020 because we were tired, and then COVID hit. I just sat on the couch one night and looked at Shannon (she helps me put on the conference), and I was like, "Wow, that would have been terrible. That would have come out of our own bank account, all that loss if we would have already booked somewhere." So phew, when it chills out, we'll try it again. BRITTANY: So let's talk about legacies. I know that some of us have taken over from popular podcasts. Some of us have grown podcasts from the very beginning. So I'm curious, do you ever put any thought into the legacy of your podcast, whether or not you're going to stay with it to the end? Would you eventually pass it off? Do you think about whether or not it's your responsibility to the community to make sure that it keeps going? JASON SWETT: I, for one, plan to have my consciousness uploaded to a supercomputer upon my death so that the Rails with Jason Podcast can continue on indefinitely. JASON CHARNES: Did you recently watch Upload the TV show? JASON SWETT: No, I've never heard of it. JASON CHARNES: Oh, man. That's a whole nother conversation. BRITTANY: Consider that homework, Jason. JASON CHARNES: It's an interesting question because we started ours out of nothing. I wonder, is one of us going to get tired and just quit? I'd like to think that if one of us did, it would keep going because there are plenty of cool people who could hang out and talk Ruby on it. But it's interesting, something that's casually crossed my mind, but I think we're good. I think we're still doing it unless Chris and Andrew have a surprise for me today. ANDREW: Surprise! [chuckles] I've thought about it a few times, specifically because I'm the youngest member of Remote Ruby. What if Jason and Chris just left, and they were like, "Oh, it's all yours now." Could I keep running it by myself? I think honestly, the answer is I would probably still do it just to have an excuse to talk to someone. I enjoy it. It's almost like a hobby at this point. I don't feel any obligation to create it. To me, it's really like an excuse to hang out with two friends, and other good stuff comes from that. But at the end of the day, I cherish that time just us hanging out a lot. CHRIS OLIVER: Yeah. I think that's why we sometimes joke about it being a weekly therapy session where we are just hanging out and chatting about stuff. It's nice to be able to talk about programming things at a high level with people you don't work with that have totally different perspectives and stuff. So yeah, if Jason and Andrew dropped off, I would still try to have conversations with random people I know and keep it going just because it's enjoyable. I would hope that we would be able to keep it going and have other people on there. BRITTANY: I'd love to hear from someone from The Bike Shed. STEPH: I have thought about it. I've thought about it partially from the perspective that Chris Toomey brought up earlier in regards to being on a podcast is an incredible platform. You get to share your opinions, and people listen to you. And they know you, and it's really wonderful marketing. So I have thought about it from the perspective of I want other people to have access to this really wonderful podcast that we put on each week. So part of me is very aware of that and thinking about how more people can have similar exposures. So a sort of a similar event occurred when Chris was moving on from thoughtbot and pursuing other interests. And at that moment, I just thought, oh my goodness, Chris brought me on as co-host, and now I'm here alone, and I don't know what I'm going to do. And I just panicked. I truly don't think I even considered other options. I was like, well, okay, it's over now. This was fun. And then it turned out where Chris was going to stay with the show. So things have just gone on swimmingly, and it's been wonderful. But similar to what someone was saying earlier around when you start listening to a podcast, and you really develop that relationship and you go back to that podcast because you really enjoy hearing from those people and their adventures, it's very similar for me where The Bike Shed is very much the conversations and chats with Chris. So I think if we were to move on, it would be whenever Chris and I decided to move on and give the reins over to somebody else. I don't know if Chris fully agrees, so this will be interesting to find out. [chuckles] CHRIS TOOMEY: I agree with that. Honestly, I'm honored to have continued on in the podcast after having moved on from thoughtbot because, in a very real way, the show is thoughtbot's channel to talk about things. I was at thoughtbot for seven years. I think I live and breathe that truth. And to me, that's what maybe has made sense for me to continue on. But I really do feel a responsibility to keep the show in good shape so that someday someone else gets to inherit this thing because I was so happy to get handed it. It was such a wonderful thing. And it has been such a joy to do for these past three years. But at some point, I do presume that we will move on. And at that point, I do hope that other people pick up the mantle. And thankfully, thoughtbot as an organization, there is a group of individuals that I'm sure there will be someone wonderful that gets to step in, but I'm in no hurry to do that. And, Steph, I hope you're not either. So we'll continue the conversations for now, but I definitely do want to keep this thing alive if for no other reason than I got handed it. I don't feel like I could let it drop on the floor. That doesn't feel right. BRITTANY: Well, I think on that warm, fuzzy feeling, we should wrap up. So let's go through everybody and just tell the listeners where they can listen to your podcasts and follow you. I am Brittany Martin, @BrittJMartin on Twitter. And you can listen to the Ruby on Rails Podcast at therubyonrailspodcast.com. JASON CHARNES: So I'm Jason. We are Remote Ruby. I am @jmcharnes on Twitter. And I'll let the others tell you where you can find them. ANDREW: You can find me everywhere @andrewmcodes. And if you email me, there's a really good chance you're never going to see a response because my email is a disaster. Please don't email me, but you can contact me anywhere else. CHRIS OLIVER: I'm Chris Oliver, and you can find me on Twitter @excid3 or at Go Rails, and of course, gorails.com. And you can find the Remote Ruby podcast at remoteruby.com. CHRIS TOOMEY: I am @christoomey on Twitter. The Bike Shed is @bikeshed on Twitter. We are at bikeshed.fm for a URL. I'm pretty sure www works, but I'm going to go check that real quick after because I want to make sure that's true. And yeah, that's me. And I'll send it over to Steph for her part. STEPH: I am on Twitter @SViccari, and I post programming stuff, usually pictures of cute goats, cute dogs, that kind of content if you're into that. JASON SWETT: For me, if you want to find my podcast, it's Rails with Jason. And if you search for Rails with Jason anywhere, you should be able to find it. And then my website, if you're interested in my blog and all that stuff, is codewithjason.com. BRITTANY: Fantastic. Thank you, everyone, for being on this mega episode today. It was a lot of fun. We are going to be having a podcast panel at RubyConf; we're excited to announce and some of us will be present. So stay tuned for details around that. And if you enjoyed this mega episode and want to see more mega episodes, please let us know on Twitter. All: Bye. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Bye. 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.

The episode you wanted and deserved! Brittany teams up with her favorite Ruby podcast hosts: Chris Oliver, Jason Charnes, Andrew Mason, Chris Toomey, Steph Viccari and Jason Swett in an epic crossover to discuss the origins of their shows, experiences as hosts, why podcasting is so important in keeping the Ruby community thriving and their shows' legacies. Show Notes & Links: Remote Ruby (https://remoteruby.transistor.fm/) The Bike Shed (https://www.bikeshed.fm/) Rails with Jason (https://www.codewithjason.com/rails-with-jason-podcast/) Chris Oliver (@excid3) | Twitter (https://twitter.com/excid3) Jason Charnes (@jmcharnes) | Twitter (https://twitter.com/jmcharnes) Andrew Mason (@andrewmcodes) | Twitter (https://twitter.com/andrewmcodes) Chris Toomey (@christoomey) | Twitter (https://twitter.com/christoomey) Steph Viccari (@SViccari) | Twitter (https://twitter.com/SViccari) Jason Swett (@JasonSwett) | Twitter (https://twitter.com/JasonSwett) Sponsored By: Scout APM (http://scoutapm.com/rubyonrails) Try their error monitoring and APM free for 14-days, no credit card needed! And as an added bonus for Ruby on Rails listeners: Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at http://scoutapm.com/rubyonrails (http://scoutapm.com/rubyonrails). Honeybadger (https://www.honeybadger.io/) Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform. Go to Honeybadger.io (https://www.honeybadger.io/) and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution.

[00:02:00] Chris and Andrew reminisce about Wii Fit, Dungeons & Dragons, and card games, which we learn Andrew became a cheater in card games.  [00:04:57] Andrew gives two shout-outs, Jason Swett had his hundredth podcast of “Rails with Jason” this week, and Brittany Martin moved her Ruby on Rails podcast. [00:07:50] Andrew shares some interesting information he learned about companies moving away from whiteboard interviews and now doing pairing interviews, and Chris talks about how important it is to make interviewing fair to the Junior Developers.[00:14:32] We find out from Andrew that Brittany is hiring right now and to find out more you should listen to her podcast (linked below), and Chris and Andrew chat about how recruiters could be quite helpful in finding a job. [00:21:56] Andrew shares a bunch of notes he took from Brittany's podcast which could help you in your job search. [00:29:10] The guys touch on the topic of mentorship, and Chris mentions a great book to read called, Mastery, which is about mentorship.[00:31:55] Andrew and Chris share their thoughts on the importance of first impressions and how you have to do what works for you. They talk about going to conferences, meeting people at them, and Chris tells us how he met Jason for the first time.[00:42:15] Being ambitious is a hot topic here and we find out about some Ruby projects out there that offer “office hours” where they pair with you on a project with a Senior Programmer, such as Nate Berkopec, who will work with you on Rails and Ruby for free!  Andrew names a few of the Ruby projects such as Puma, Hanami, and Ruby for Good that offer this.  [00:44:06] Chris tells a story about when he was interviewing developers at LaunchCode and finding the right person for the job.[00:46:57] We end with a quick tip from Andrew which is to start reading Ruby and he explains what you need to do. Also, Chris shares a few bits of advice on finding a job.Panelists:Chris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby RadarRuby Radar Twitter The Debut of The Ruby on Rails Podcast-Episode 372 with Brittany Martin and Brian MarianiThe Rails with Jason PodcastMastery by Robert GreeneRuby For GoodHanamiPumaLaunchCodeNate Berkopec Twitter

[00:05:33] Jason introduces himself and tells us what he does. [00:06:48] Jason defines what a service object is and how he views them, and then asks the guys if they use service objects and what comes to mind when they hear the term service objects. [00:11:45] We find out about a blog post that Jason wrote recently that he tells us about. [00:13:49] Chris talks about good complicated examples are the hardest to come up with, and Jason tells us about a challenge he had with cases in his own work and he addresses something Chris said about testing. [00:17:01] We hear Jason’s hypothesis as to why service objects are so popular.[00:22:48] Chris tells us about an app that he made that supports sub domains and custom domains, and he talks about Basecamp open source Name of Person gem and what it does. [00:27:14] Jason talks about some distractions that they’ve come up in their app.[00:30:51] A great point is brought up by Jason about paying close attention to the names of things in Rails you will notice everything is made out of objects. [00:32:29] An obstacle to learning about this stuff is that Rails itself obscures a lot, so Jason shares some recommendations on how to get through it.[00:35:47] We learn more about Jason’s newest book he released on testing called, “The Complete Guide to Rails Testing.” (use code REMOTERUBY for an awesome discount!) [00:39:48] If the testing stuff sounds interesting to you and you want a sample of what Jason’s teaching, go to railstestingguide.com and get a little guide that he put together that helps you get started.  [00:40:38] Find out where you can follow Jason online.Panelists:Jason CharnesChris OliverGuest:Jason SwettSponsor:HoneybadgerLinks:Jason Swett TwitterJason Swett LinkedinCode with JasonThe Rails with Jason PodcastThe Complete Guide to Rails Testing by Jason SwettName of Person-GitHubRailstestingguide.com

Robby speaks with Jason Swett, Software Engineer at Meadows Eye. They discuss the value of understandability, differences between loose and tight coupling in code, and creating a shared vision as a team. Jason also discusses how teams struggle to retain quality engineers and how to teach testing to Ruby on Rails developers.Helpful LinksJason on TwitterJason's WebsiteThe Rails with Jason Podcast[Book Recommendation] How to Win Friends & Influence People, Dale CarnegieSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

Wow, two guests in a row. This one is with Jason Swett of codewithjason.com. As always our random assortment on conversation includes whiskey and other randomness, plus some in depth conversation around retirement, investing in yourself through businesses, and what financial independence means.Jason's site: https://codewithjason.comJOIN OUR DISCORD: https://discord.gg/BSTHjuMRadical Candor: https://amzn.to/31clwbnWebsite: https://www.youtube.com/channel/UCJTcKa11MQNOkT4wsfNFLkQTwitter: https://twitter.com/trobrock and https://twitter.com/gustinjabriel

Jason and I discuss automated testing from a beginner's perspective and its impact on engineering success. Strong opinions included!

Jason Swett and I talk about his education as a programmer and the classes he took in university. I also explain big-O notation in a simple way that (Jason thinks) is useful, and we wander onto topics like philosophy, as Jason and I tend to... For show notes, links, comments and transcripts see: http://justtheusefulbits.com/jtub/jason-swett-when-data-structures-big-o-notation-and-algorithms-were-completely-useless/

Jason Swett is a developer, speaker, author and the host of The Rails with Jason podcast. He and Brittany discussed bringing diversity into the podcasting space and some of his favorite tips from his blog post, "All my best programming tips".

Jason Swett is a developer, speaker, author and the host of The Rails with Jason podcast. He and Brittany discussed bringing diversity into the podcasting space and some of his favorite tips from his blog post, "All my best programming tips".

Jason Swett is a developer, speaker, author and the host of The Rails with Jason podcast. He and Brittany discussed bringing diversity into the podcasting space and some of his favorite tips from his blog post, "All my best programming tips".

The best idea doesn't always win. You have to understand someone and build a relationship with them before they'll listen. Jason Swett, host of the Rails with Jason podcast, and I talk about ways to pitch ideas that'll get people to listen.

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Sponsors Sentry use code “devchat” for 2 months free Triplebyte $1000 signing bonus Redisgreen Panel Charles Max Wood Dave Kimura Special Guest: Jason Swett Episode Summary Jason Swett is a former host on Ruby Rogues. Now he has his own show, Ruby Testing Podcast and runs the site codewithjason.com where he teaches Rails testing. Today, Jason discusses turning fat models into skinny POROs (Plain Old Ruby Objects). He once read an article that said you don’t have to put all your code into active record models, that you can create plain ruby objects. These can go into active models if you want, but you’re not limited to active record models, you can make your own classes. This realazition greatly impacted the way he structures his code. The panelists talk about the individual ways the structure their code. Jason discusses other structuring methods he has tried and gives some examples of using skinny POROs in the apps he works on. They discuss the pros and cons of using skinny POROs instead of active models, pros being it cleans up the model and makes testing easier, and the cons being it adds to a bit of overhead to the application, as somebody unfamiliar with the application might recreate parts if you don’t have an index. The panel discusses how to decide when you want to create a new PORO. They talk about each of their methods and discuss the the usefulness of token generators. They conclude that in order for skinny POROs to be effective in code, they must be well factored and organized, and that unfortunately some complexity in code is unavoidable. Links POROs- Plain Old Ruby Objects Model Active record models Namespace Service objects Value objects CSS Form object Tokens Initializer Singleton object Picks Dave Kimura: Reek Kubernetes Charles Max Wood: Cloud66 Podwrench Podcasting booth New podcasts coming to DevChat-- if you want to revive a podcast that has stopped airing, contact Charles Max Wood Programming Podcasters Slack chat Jason Swett: Practical Object Oriented Design in Ruby Ruby Testing Podcast Codewithjason.com

Sponsors Sentry use code “devchat” for 2 months free Triplebyte $1000 signing bonus Redisgreen Panel Charles Max Wood Dave Kimura Special Guest: Jason Swett Episode Summary Jason Swett is a former host on Ruby Rogues. Now he has his own show, Ruby Testing Podcast and runs the site codewithjason.com where he teaches Rails testing. Today, Jason discusses turning fat models into skinny POROs (Plain Old Ruby Objects). He once read an article that said you don’t have to put all your code into active record models, that you can create plain ruby objects. These can go into active models if you want, but you’re not limited to active record models, you can make your own classes. This realazition greatly impacted the way he structures his code. The panelists talk about the individual ways the structure their code. Jason discusses other structuring methods he has tried and gives some examples of using skinny POROs in the apps he works on. They discuss the pros and cons of using skinny POROs instead of active models, pros being it cleans up the model and makes testing easier, and the cons being it adds to a bit of overhead to the application, as somebody unfamiliar with the application might recreate parts if you don’t have an index. The panel discusses how to decide when you want to create a new PORO. They talk about each of their methods and discuss the the usefulness of token generators. They conclude that in order for skinny POROs to be effective in code, they must be well factored and organized, and that unfortunately some complexity in code is unavoidable. Links POROs- Plain Old Ruby Objects Model Active record models Namespace Service objects Value objects CSS Form object Tokens Initializer Singleton object Picks Dave Kimura: Reek Kubernetes Charles Max Wood: Cloud66 Podwrench Podcasting booth New podcasts coming to DevChat-- if you want to revive a podcast that has stopped airing, contact Charles Max Wood Programming Podcasters Slack chat Jason Swett: Practical Object Oriented Design in Ruby Ruby Testing Podcast Codewithjason.com

Sponsors Sentry use code “devchat” for 2 months free Triplebyte $1000 signing bonus Redisgreen Panel Charles Max Wood Dave Kimura Special Guest: Jason Swett Episode Summary Jason Swett is a former host on Ruby Rogues. Now he has his own show, Ruby Testing Podcast and runs the site codewithjason.com where he teaches Rails testing. Today, Jason discusses turning fat models into skinny POROs (Plain Old Ruby Objects). He once read an article that said you don’t have to put all your code into active record models, that you can create plain ruby objects. These can go into active models if you want, but you’re not limited to active record models, you can make your own classes. This realazition greatly impacted the way he structures his code. The panelists talk about the individual ways the structure their code. Jason discusses other structuring methods he has tried and gives some examples of using skinny POROs in the apps he works on. They discuss the pros and cons of using skinny POROs instead of active models, pros being it cleans up the model and makes testing easier, and the cons being it adds to a bit of overhead to the application, as somebody unfamiliar with the application might recreate parts if you don’t have an index. The panel discusses how to decide when you want to create a new PORO. They talk about each of their methods and discuss the the usefulness of token generators. They conclude that in order for skinny POROs to be effective in code, they must be well factored and organized, and that unfortunately some complexity in code is unavoidable. Links POROs- Plain Old Ruby Objects Model Active record models Namespace Service objects Value objects CSS Form object Tokens Initializer Singleton object Picks Dave Kimura: Reek Kubernetes Charles Max Wood: Cloud66 Podwrench Podcasting booth New podcasts coming to DevChat-- if you want to revive a podcast that has stopped airing, contact Charles Max Wood Programming Podcasters Slack chat Jason Swett: Practical Object Oriented Design in Ruby Ruby Testing Podcast Codewithjason.com

Jason is a freelance software engineer and an expert on Ruby testing. He hosts the Ruby Testing podcast, writes technical books, teaches other developers, and is on a mission to build businesses with his technical skillset. During our talk, Jason shared his expertise in seeking new ways to increase your income as a developer and revealed his own experiences as a developer, author, teacher, and freelancer. Jason's internet home: https://www.codewithjason.com/

Jason Swett joins Chris and Jason (Charnes) to talk about testing in Rails and working with legacy applications.

Jason Swett is a developer, speaker, trainer, author and host of The Ruby Testing Podcast. Jason joined Brittany to discuss legacy Ruby on Rails applications: how to identify them and tackle their challenges from a testing standpoint.

Jason Swett is a developer, speaker, trainer, author and host of The Ruby Testing Podcast. Jason joined Brittany to discuss legacy Ruby on Rails applications: how to identify them and tackle their challenges from a testing standpoint.

Panel: Dave Kimura Eric Berry Nathan Hopkins David Richards Special Guest: Jason Swett In this episode of Ruby Rogues, the panel talks with Jason Swett who is a host of the podcast show, Ruby Testing! Jason also teaches Rails testing at CodeWithJason.com. He currently resides in the Michigan area and works for Ben Franklin Labs. Check-out today’s episode where the panelists and the guest discuss testing topics. Show Topics: 0:00 – Sentry.IO – Advertisement! Check out the code: DEVCHAT @ Sentry.io. 1:07 – I am David Kimura and here is the panel! Tell us what is going on? 1:38 – Jason: I started my own podcast, and have been doing that for the past few months. That’s one thing. I started a new site with CodeWithJason.com. 2:04 – You released a course? 2:10 – Jason: Total flop and it doesn’t exist, but I am doing something else. 2:24 – I bet you learned a lot by creating the course? 2:34 – Jason: The endeavor of TEACHING it has helped me a lot. 2:50 – Tell us why we should drink the Koolaid? 3:02 – Jason: What IS testing? Good question. Whether is it is manual testing or automated testing. We might was well automate it. 3:25 – If we are testing our code what does that look like? 3:34 – Jason: Not sure what you mean, but I am doing tests at a fine grain vs. coarser grain. 4:00 – Show of hands who has...? 4:19 – What different tests are there? 4:20 – Jason: Good question. One term that one person uses is different to a different person. Let’s start with unit tests vs. integration tests. Jason dives into the similarities and differences between these 2 tests (see above). There are different tests, such as: featured tests, acceptance tests, etc. 5:45 – What tests are THE best? 5:50 – Jason: Good question. The kind of tests you are writing depends on what type of coverage you are going for. If I had a sign-up page for a user, I would... 7:36 – What anti-patterns are you seeing? What is your narrative in teaching people how to use them? 8:07 – Jason talks first about his background and his interaction with one of his colleagues. 8:58 – Question. 9:00 – Jason continues with his answers from 8:07. 9:32 – Jason: Feel free to chime-in. What have you done? 9:42 – I often ignore it until I feel bad and then I say: wait-a-minute I am a professional. Then I realize I ignored the problem because I was acting cowardly. 10:29 – For me it depends on the test that it is. One gem that I found is: RSpec RETRY. 11:16 – Jason: The test is flapping because of something is wrong with the database or something else. Since you asked about anti-patterns let’s talk about that! Rails and Angular are mentioned. 13:10 – Do you find that you back off of your unit testing when you are using integration? 13:22 – Jason: It depends on the context we are talking about. Jason talks about featured testing, model-level testing, and more. 13:58 – What is your view on using MOCKS or FAKES. What should we be doing there? 14:10 – Jason: Going to the Angular world I understand Mocks better than now. There was a parable that I think is applicable here about the young and the old fish. 16:23 – Jason continues talking about testing things in isolation. 16:36 – Question.  16:39 – I have been looking for an area to specialize in and I wrote an eBook. (Check out here to see the articles and books that Jason has authored.) Then I was looking around and I wanted to see what people’s issues are with Rails? They have a hard time with testing. I wanted to help them feel competent with it. 18:03 – In your course you have how to choose a framework. I know Ruby has several options on that front – how do you choose? 18:24 – Jason: There are 2 factors to consider. Jason tells us what those two factors are. Jason: Angular, React and Vue. 19:52 – Panelist: I had a conversation with a beginner and we were talking about the different tests. He said the DSL really appealed to him. The surface area of the AI made it approachable for him. 20:27 – Jason: I wished I had figured out DSL out a little better. Understanding the concept of a block. The IT is just a function and you can put parentheses in different areas and... 21:01 – That makes sense. Let’s revisit the Tweet you wrote. 21:35 – Jason: There are certain use cases where it makes sense. Where Gmail was the thing out there. At some point the Internet formed the opinion that... 22:39 – Old saying: Nobody gets fired for using Microsoft and then it was IBM. Nothing wrong with those things if that’s what you are trying to do. Sometimes we make decisions to not be criticized. We try to grab big frameworks and big codes so we are not criticized for. 23:48 – Jason: I think developers have this idea that OLD is OUTDATED. Not so. I think it’s mature, not necessarily outdated. I think it’s a pervasive idea. 24:31 – I think it suffers a bit when all the mind shares get lumped into one thing. The panelist continues... 24:53 – Jason: I don’t know if I like this analogy. 26:00 – I agree with that sentiment. It’s crazy that the complexity has become so pervasive. 26:18 – I think of SPAs as... 26:37 – Jason: Going back to the Tweet I wrote, I am pulling in JavaScript but I am preferring to sprinkle Java into Rails. 27:02 – Absolutely. I think that’s where we agree on. Late in 2017 we had the guest... “Use JavaScript sprinkles.” 27:49 – Panelist chimes-in. 28:37 – Jason: That make sense. Use your preexisting... I am afraid of committing to a single framework. I don’t have anything against JavaScript but I am afraid of using only one thing when something else becomes fashionable. 29:30 – Have you found that Java sparkle approach is easy to test? 29:38 – Jason: I think it’s easier. Client server architecture... 30:10 – Advertisement: Get A Coder Job! 30:41 – Shout-out to the Rails team! What other testing frameworks are there? What if you are not the developer but you are the Quality Assurance (QA) person. They have been given the task of testing on the application. 31:30 – Jason: So someone who is not a developer and they want to test the application. I don’t want to get out of my role of expertise. I did talk to a QA engineer and I asked them: What do you do? All of his tests are manual. He does the same stuff as a Rails developer would do. 32:52 – Panelist talks about pseudo code. 34:07 – Jason: I am curious, Dave, about the non-programmer helping with tests what is the team structure? 34:23 – Dave: You will have one QA per three developers. 34:44 – Jason: If you have a QA person he is integrated within the team – that’s what has been the case for me. 35:02 – Dave: It’s a nice thing to have because we need to crank out some features and we have a good idea what is wrong with the app. We can go in there and see if our application is good, but they are combining different scenarios to do the unit tests and see what they are lacking. They are uncovering different problems that we hadn’t thought of. 36:07 – The organization has to have the right culture for that to work. 36:35 – If it’s a small team then it will help to see what everyone is doing – it’s that engagement level. If the team is too large then it could be a problem. 37:15 – Jason: Engagement between whom? 37:27 – Both. Panelist goes into detail about different engagement levels throughout the team. 38:10 – Jason: Yeah that’s a tough thing. 38:49 – It’s interesting to see the things that are being created. Testing seems to help that out. We are getting bugs in that area or se didn’t design it well there... We see that we need some flexibility and getting that input and having a way to solve the problems. 39:32 – Jason: Continuous deployment – let’s segue into this topic. 41:17 – Panelist: Do you have recommendations on how often we should be deploying in that system per day/week? 41:40 – Jason: We would deploy several times a day, which was great. The more the better because the more frequently you are deploying the fewer things will go wrong. 42:21 – More frequently the better and more people involved. 42:45 – Jason continues this conversation. 42:51 – Panelist: Continuous integration – any time you were say to forgo tests or being less rigid? 43:14 – Jason: I don’t test everything. I don’t write tests for things that have little risks. 43:56 – I think it is a good segue into how you write your code. If you write a code that is like spaghetti then it will be a mess. Making things easier to test. 44:48 – Jason: This is fresh in my mind because I am writing an app called Green Field. 46:32 – Uniqueness Validations, is mentioned by Jason. 47:00 – Anything else to add to testing a Rails application? 47:08 – Jason: Let’s talk about 2 things: walking skeleton and small stories. This book is a great resource for automated testing. Last point that I want to talk about is small stories: continues deployment and continuous delivery. If you make your stories smaller then you are making your stories crisply defined. Have some bullet points to make it really easy to answer the question. Answer the question: is this story done or not done? Someone should be able to run through the bullet points and answer that question. 50:02 – I am in favor of small stories, too. Makes you feel more productive, too. 50:14 – Work tends to lend itself to these types of stories and running a sprint. 51:22 – You don’t have to carry that burden when you go home. You might have too big of a chunk – it carries too much weight to it. 51:47 – Book the Phoenix Project. Work in progress is a bad thing. That makes sense. You want to have fewer balls in the air. 52:17 – Anything else? 52:22 – Jason: You can find me at: CodewithJason.com also Twitter!  52:45 – Advertisement – Fresh Books! 1:01:50 – Cache Fly! Links: Get a Coder Job Course Erlang Ruby Ruby Motion Ruby on Rails Angular Single Page Application (SPA) RSpec – Retry Ruby Testing Podcast The Feynman Technique Model Book: Growing Object-Oriented Software, Guided by Tests (1st edition) Jason Swett’s Twitter Jason Swett’s LinkedIn Parable: Young Fish and Old Fish – What is Water? Jason’s articles and eBook Jason’s Website Sponsors: Sentry Get a Coder Job Course Fresh Books Cache Fly Picks: David This is Water The Feynman Technique Model Nate Taking some time off Pry Test Eric Fake App Ruby Hack Conference Dave Brooks Shoes Jason The Food Lab Growing Object-Oriented Software

Panel: Dave Kimura Eric Berry Nathan Hopkins David Richards Special Guest: Jason Swett In this episode of Ruby Rogues, the panel talks with Jason Swett who is a host of the podcast show, Ruby Testing! Jason also teaches Rails testing at CodeWithJason.com. He currently resides in the Michigan area and works for Ben Franklin Labs. Check-out today’s episode where the panelists and the guest discuss testing topics. Show Topics: 0:00 – Sentry.IO – Advertisement! Check out the code: DEVCHAT @ Sentry.io. 1:07 – I am David Kimura and here is the panel! Tell us what is going on? 1:38 – Jason: I started my own podcast, and have been doing that for the past few months. That’s one thing. I started a new site with CodeWithJason.com. 2:04 – You released a course? 2:10 – Jason: Total flop and it doesn’t exist, but I am doing something else. 2:24 – I bet you learned a lot by creating the course? 2:34 – Jason: The endeavor of TEACHING it has helped me a lot. 2:50 – Tell us why we should drink the Koolaid? 3:02 – Jason: What IS testing? Good question. Whether is it is manual testing or automated testing. We might was well automate it. 3:25 – If we are testing our code what does that look like? 3:34 – Jason: Not sure what you mean, but I am doing tests at a fine grain vs. coarser grain. 4:00 – Show of hands who has...? 4:19 – What different tests are there? 4:20 – Jason: Good question. One term that one person uses is different to a different person. Let’s start with unit tests vs. integration tests. Jason dives into the similarities and differences between these 2 tests (see above). There are different tests, such as: featured tests, acceptance tests, etc. 5:45 – What tests are THE best? 5:50 – Jason: Good question. The kind of tests you are writing depends on what type of coverage you are going for. If I had a sign-up page for a user, I would... 7:36 – What anti-patterns are you seeing? What is your narrative in teaching people how to use them? 8:07 – Jason talks first about his background and his interaction with one of his colleagues. 8:58 – Question. 9:00 – Jason continues with his answers from 8:07. 9:32 – Jason: Feel free to chime-in. What have you done? 9:42 – I often ignore it until I feel bad and then I say: wait-a-minute I am a professional. Then I realize I ignored the problem because I was acting cowardly. 10:29 – For me it depends on the test that it is. One gem that I found is: RSpec RETRY. 11:16 – Jason: The test is flapping because of something is wrong with the database or something else. Since you asked about anti-patterns let’s talk about that! Rails and Angular are mentioned. 13:10 – Do you find that you back off of your unit testing when you are using integration? 13:22 – Jason: It depends on the context we are talking about. Jason talks about featured testing, model-level testing, and more. 13:58 – What is your view on using MOCKS or FAKES. What should we be doing there? 14:10 – Jason: Going to the Angular world I understand Mocks better than now. There was a parable that I think is applicable here about the young and the old fish. 16:23 – Jason continues talking about testing things in isolation. 16:36 – Question.  16:39 – I have been looking for an area to specialize in and I wrote an eBook. (Check out here to see the articles and books that Jason has authored.) Then I was looking around and I wanted to see what people’s issues are with Rails? They have a hard time with testing. I wanted to help them feel competent with it. 18:03 – In your course you have how to choose a framework. I know Ruby has several options on that front – how do you choose? 18:24 – Jason: There are 2 factors to consider. Jason tells us what those two factors are. Jason: Angular, React and Vue. 19:52 – Panelist: I had a conversation with a beginner and we were talking about the different tests. He said the DSL really appealed to him. The surface area of the AI made it approachable for him. 20:27 – Jason: I wished I had figured out DSL out a little better. Understanding the concept of a block. The IT is just a function and you can put parentheses in different areas and... 21:01 – That makes sense. Let’s revisit the Tweet you wrote. 21:35 – Jason: There are certain use cases where it makes sense. Where Gmail was the thing out there. At some point the Internet formed the opinion that... 22:39 – Old saying: Nobody gets fired for using Microsoft and then it was IBM. Nothing wrong with those things if that’s what you are trying to do. Sometimes we make decisions to not be criticized. We try to grab big frameworks and big codes so we are not criticized for. 23:48 – Jason: I think developers have this idea that OLD is OUTDATED. Not so. I think it’s mature, not necessarily outdated. I think it’s a pervasive idea. 24:31 – I think it suffers a bit when all the mind shares get lumped into one thing. The panelist continues... 24:53 – Jason: I don’t know if I like this analogy. 26:00 – I agree with that sentiment. It’s crazy that the complexity has become so pervasive. 26:18 – I think of SPAs as... 26:37 – Jason: Going back to the Tweet I wrote, I am pulling in JavaScript but I am preferring to sprinkle Java into Rails. 27:02 – Absolutely. I think that’s where we agree on. Late in 2017 we had the guest... “Use JavaScript sprinkles.” 27:49 – Panelist chimes-in. 28:37 – Jason: That make sense. Use your preexisting... I am afraid of committing to a single framework. I don’t have anything against JavaScript but I am afraid of using only one thing when something else becomes fashionable. 29:30 – Have you found that Java sparkle approach is easy to test? 29:38 – Jason: I think it’s easier. Client server architecture... 30:10 – Advertisement: Get A Coder Job! 30:41 – Shout-out to the Rails team! What other testing frameworks are there? What if you are not the developer but you are the Quality Assurance (QA) person. They have been given the task of testing on the application. 31:30 – Jason: So someone who is not a developer and they want to test the application. I don’t want to get out of my role of expertise. I did talk to a QA engineer and I asked them: What do you do? All of his tests are manual. He does the same stuff as a Rails developer would do. 32:52 – Panelist talks about pseudo code. 34:07 – Jason: I am curious, Dave, about the non-programmer helping with tests what is the team structure? 34:23 – Dave: You will have one QA per three developers. 34:44 – Jason: If you have a QA person he is integrated within the team – that’s what has been the case for me. 35:02 – Dave: It’s a nice thing to have because we need to crank out some features and we have a good idea what is wrong with the app. We can go in there and see if our application is good, but they are combining different scenarios to do the unit tests and see what they are lacking. They are uncovering different problems that we hadn’t thought of. 36:07 – The organization has to have the right culture for that to work. 36:35 – If it’s a small team then it will help to see what everyone is doing – it’s that engagement level. If the team is too large then it could be a problem. 37:15 – Jason: Engagement between whom? 37:27 – Both. Panelist goes into detail about different engagement levels throughout the team. 38:10 – Jason: Yeah that’s a tough thing. 38:49 – It’s interesting to see the things that are being created. Testing seems to help that out. We are getting bugs in that area or se didn’t design it well there... We see that we need some flexibility and getting that input and having a way to solve the problems. 39:32 – Jason: Continuous deployment – let’s segue into this topic. 41:17 – Panelist: Do you have recommendations on how often we should be deploying in that system per day/week? 41:40 – Jason: We would deploy several times a day, which was great. The more the better because the more frequently you are deploying the fewer things will go wrong. 42:21 – More frequently the better and more people involved. 42:45 – Jason continues this conversation. 42:51 – Panelist: Continuous integration – any time you were say to forgo tests or being less rigid? 43:14 – Jason: I don’t test everything. I don’t write tests for things that have little risks. 43:56 – I think it is a good segue into how you write your code. If you write a code that is like spaghetti then it will be a mess. Making things easier to test. 44:48 – Jason: This is fresh in my mind because I am writing an app called Green Field. 46:32 – Uniqueness Validations, is mentioned by Jason. 47:00 – Anything else to add to testing a Rails application? 47:08 – Jason: Let’s talk about 2 things: walking skeleton and small stories. This book is a great resource for automated testing. Last point that I want to talk about is small stories: continues deployment and continuous delivery. If you make your stories smaller then you are making your stories crisply defined. Have some bullet points to make it really easy to answer the question. Answer the question: is this story done or not done? Someone should be able to run through the bullet points and answer that question. 50:02 – I am in favor of small stories, too. Makes you feel more productive, too. 50:14 – Work tends to lend itself to these types of stories and running a sprint. 51:22 – You don’t have to carry that burden when you go home. You might have too big of a chunk – it carries too much weight to it. 51:47 – Book the Phoenix Project. Work in progress is a bad thing. That makes sense. You want to have fewer balls in the air. 52:17 – Anything else? 52:22 – Jason: You can find me at: CodewithJason.com also Twitter!  52:45 – Advertisement – Fresh Books! 1:01:50 – Cache Fly! Links: Get a Coder Job Course Erlang Ruby Ruby Motion Ruby on Rails Angular Single Page Application (SPA) RSpec – Retry Ruby Testing Podcast The Feynman Technique Model Book: Growing Object-Oriented Software, Guided by Tests (1st edition) Jason Swett’s Twitter Jason Swett’s LinkedIn Parable: Young Fish and Old Fish – What is Water? Jason’s articles and eBook Jason’s Website Sponsors: Sentry Get a Coder Job Course Fresh Books Cache Fly Picks: David This is Water The Feynman Technique Model Nate Taking some time off Pry Test Eric Fake App Ruby Hack Conference Dave Brooks Shoes Jason The Food Lab Growing Object-Oriented Software

Panel: Dave Kimura Eric Berry Nathan Hopkins David Richards Special Guest: Jason Swett In this episode of Ruby Rogues, the panel talks with Jason Swett who is a host of the podcast show, Ruby Testing! Jason also teaches Rails testing at CodeWithJason.com. He currently resides in the Michigan area and works for Ben Franklin Labs. Check-out today’s episode where the panelists and the guest discuss testing topics. Show Topics: 0:00 – Sentry.IO – Advertisement! Check out the code: DEVCHAT @ Sentry.io. 1:07 – I am David Kimura and here is the panel! Tell us what is going on? 1:38 – Jason: I started my own podcast, and have been doing that for the past few months. That’s one thing. I started a new site with CodeWithJason.com. 2:04 – You released a course? 2:10 – Jason: Total flop and it doesn’t exist, but I am doing something else. 2:24 – I bet you learned a lot by creating the course? 2:34 – Jason: The endeavor of TEACHING it has helped me a lot. 2:50 – Tell us why we should drink the Koolaid? 3:02 – Jason: What IS testing? Good question. Whether is it is manual testing or automated testing. We might was well automate it. 3:25 – If we are testing our code what does that look like? 3:34 – Jason: Not sure what you mean, but I am doing tests at a fine grain vs. coarser grain. 4:00 – Show of hands who has...? 4:19 – What different tests are there? 4:20 – Jason: Good question. One term that one person uses is different to a different person. Let’s start with unit tests vs. integration tests. Jason dives into the similarities and differences between these 2 tests (see above). There are different tests, such as: featured tests, acceptance tests, etc. 5:45 – What tests are THE best? 5:50 – Jason: Good question. The kind of tests you are writing depends on what type of coverage you are going for. If I had a sign-up page for a user, I would... 7:36 – What anti-patterns are you seeing? What is your narrative in teaching people how to use them? 8:07 – Jason talks first about his background and his interaction with one of his colleagues. 8:58 – Question. 9:00 – Jason continues with his answers from 8:07. 9:32 – Jason: Feel free to chime-in. What have you done? 9:42 – I often ignore it until I feel bad and then I say: wait-a-minute I am a professional. Then I realize I ignored the problem because I was acting cowardly. 10:29 – For me it depends on the test that it is. One gem that I found is: RSpec RETRY. 11:16 – Jason: The test is flapping because of something is wrong with the database or something else. Since you asked about anti-patterns let’s talk about that! Rails and Angular are mentioned. 13:10 – Do you find that you back off of your unit testing when you are using integration? 13:22 – Jason: It depends on the context we are talking about. Jason talks about featured testing, model-level testing, and more. 13:58 – What is your view on using MOCKS or FAKES. What should we be doing there? 14:10 – Jason: Going to the Angular world I understand Mocks better than now. There was a parable that I think is applicable here about the young and the old fish. 16:23 – Jason continues talking about testing things in isolation. 16:36 – Question.  16:39 – I have been looking for an area to specialize in and I wrote an eBook. (Check out here to see the articles and books that Jason has authored.) Then I was looking around and I wanted to see what people’s issues are with Rails? They have a hard time with testing. I wanted to help them feel competent with it. 18:03 – In your course you have how to choose a framework. I know Ruby has several options on that front – how do you choose? 18:24 – Jason: There are 2 factors to consider. Jason tells us what those two factors are. Jason: Angular, React and Vue. 19:52 – Panelist: I had a conversation with a beginner and we were talking about the different tests. He said the DSL really appealed to him. The surface area of the AI made it approachable for him. 20:27 – Jason: I wished I had figured out DSL out a little better. Understanding the concept of a block. The IT is just a function and you can put parentheses in different areas and... 21:01 – That makes sense. Let’s revisit the Tweet you wrote. 21:35 – Jason: There are certain use cases where it makes sense. Where Gmail was the thing out there. At some point the Internet formed the opinion that... 22:39 – Old saying: Nobody gets fired for using Microsoft and then it was IBM. Nothing wrong with those things if that’s what you are trying to do. Sometimes we make decisions to not be criticized. We try to grab big frameworks and big codes so we are not criticized for. 23:48 – Jason: I think developers have this idea that OLD is OUTDATED. Not so. I think it’s mature, not necessarily outdated. I think it’s a pervasive idea. 24:31 – I think it suffers a bit when all the mind shares get lumped into one thing. The panelist continues... 24:53 – Jason: I don’t know if I like this analogy. 26:00 – I agree with that sentiment. It’s crazy that the complexity has become so pervasive. 26:18 – I think of SPAs as... 26:37 – Jason: Going back to the Tweet I wrote, I am pulling in JavaScript but I am preferring to sprinkle Java into Rails. 27:02 – Absolutely. I think that’s where we agree on. Late in 2017 we had the guest... “Use JavaScript sprinkles.” 27:49 – Panelist chimes-in. 28:37 – Jason: That make sense. Use your preexisting... I am afraid of committing to a single framework. I don’t have anything against JavaScript but I am afraid of using only one thing when something else becomes fashionable. 29:30 – Have you found that Java sparkle approach is easy to test? 29:38 – Jason: I think it’s easier. Client server architecture... 30:10 – Advertisement: Get A Coder Job! 30:41 – Shout-out to the Rails team! What other testing frameworks are there? What if you are not the developer but you are the Quality Assurance (QA) person. They have been given the task of testing on the application. 31:30 – Jason: So someone who is not a developer and they want to test the application. I don’t want to get out of my role of expertise. I did talk to a QA engineer and I asked them: What do you do? All of his tests are manual. He does the same stuff as a Rails developer would do. 32:52 – Panelist talks about pseudo code. 34:07 – Jason: I am curious, Dave, about the non-programmer helping with tests what is the team structure? 34:23 – Dave: You will have one QA per three developers. 34:44 – Jason: If you have a QA person he is integrated within the team – that’s what has been the case for me. 35:02 – Dave: It’s a nice thing to have because we need to crank out some features and we have a good idea what is wrong with the app. We can go in there and see if our application is good, but they are combining different scenarios to do the unit tests and see what they are lacking. They are uncovering different problems that we hadn’t thought of. 36:07 – The organization has to have the right culture for that to work. 36:35 – If it’s a small team then it will help to see what everyone is doing – it’s that engagement level. If the team is too large then it could be a problem. 37:15 – Jason: Engagement between whom? 37:27 – Both. Panelist goes into detail about different engagement levels throughout the team. 38:10 – Jason: Yeah that’s a tough thing. 38:49 – It’s interesting to see the things that are being created. Testing seems to help that out. We are getting bugs in that area or se didn’t design it well there... We see that we need some flexibility and getting that input and having a way to solve the problems. 39:32 – Jason: Continuous deployment – let’s segue into this topic. 41:17 – Panelist: Do you have recommendations on how often we should be deploying in that system per day/week? 41:40 – Jason: We would deploy several times a day, which was great. The more the better because the more frequently you are deploying the fewer things will go wrong. 42:21 – More frequently the better and more people involved. 42:45 – Jason continues this conversation. 42:51 – Panelist: Continuous integration – any time you were say to forgo tests or being less rigid? 43:14 – Jason: I don’t test everything. I don’t write tests for things that have little risks. 43:56 – I think it is a good segue into how you write your code. If you write a code that is like spaghetti then it will be a mess. Making things easier to test. 44:48 – Jason: This is fresh in my mind because I am writing an app called Green Field. 46:32 – Uniqueness Validations, is mentioned by Jason. 47:00 – Anything else to add to testing a Rails application? 47:08 – Jason: Let’s talk about 2 things: walking skeleton and small stories. This book is a great resource for automated testing. Last point that I want to talk about is small stories: continues deployment and continuous delivery. If you make your stories smaller then you are making your stories crisply defined. Have some bullet points to make it really easy to answer the question. Answer the question: is this story done or not done? Someone should be able to run through the bullet points and answer that question. 50:02 – I am in favor of small stories, too. Makes you feel more productive, too. 50:14 – Work tends to lend itself to these types of stories and running a sprint. 51:22 – You don’t have to carry that burden when you go home. You might have too big of a chunk – it carries too much weight to it. 51:47 – Book the Phoenix Project. Work in progress is a bad thing. That makes sense. You want to have fewer balls in the air. 52:17 – Anything else? 52:22 – Jason: You can find me at: CodewithJason.com also Twitter!  52:45 – Advertisement – Fresh Books! 1:01:50 – Cache Fly! Links: Get a Coder Job Course Erlang Ruby Ruby Motion Ruby on Rails Angular Single Page Application (SPA) RSpec – Retry Ruby Testing Podcast The Feynman Technique Model Book: Growing Object-Oriented Software, Guided by Tests (1st edition) Jason Swett’s Twitter Jason Swett’s LinkedIn Parable: Young Fish and Old Fish – What is Water? Jason’s articles and eBook Jason’s Website Sponsors: Sentry Get a Coder Job Course Fresh Books Cache Fly Picks: David This is Water The Feynman Technique Model Nate Taking some time off Pry Test Eric Fake App Ruby Hack Conference Dave Brooks Shoes Jason The Food Lab Growing Object-Oriented Software

I always hear about how most Ruby developers have embraced testing. So today we’re going to test talk about the Ruby Testing Culture from a developers perspective with Jason Sweet from codewithJason.com. Jason has a bunch of courses and articles on his blog about ruby testing, and he shares his testing knowledge on a whole bunch of topics with us today in this episode. Check it out.

Hello and welcome to the 72nd episode of the Graduate Job Podcast, the UKs most popular careers and jobs podcast. The sun has been shining here in London, but it’s been no excuse for me not bringing you the brightest and the best job search advice. This week’s episode is an international one, as it came about from an email from Piers a listener in South Africa who wanted to know how could he change focus after a law degree and get a job as a coder, with no previous coding experience. My guest bringing his expert wisdom on the matter is Jason Swett from over in Michigan, USA, who is a developer, trainer, and the author of ‘Angular for Rails Developers’. In this episode we delve into Piers question about getting your first job as a coder with no experience, exploring questions such as how do you get started, what programming language should you start learning, and what resources should you be looking at. We also explore how long it will take you before you are ready to start applying for a coding job, how to stand out in your applications and what you can expect throughout the interview process, and why you need to start applying for your first coding job before you think you’re ready. If you have ever thought about a career in programming and coding, then this is the episode for you. As always all links, and a full transcript can be found in the shownotes at graduatejobpodcast.com/coding.  From there you will also find links to all of the other 71 episodes which cover every aspect of getting a graduate job, from help with interviews, assessment centres, to specific companies, to finding a job you love. Check them out and you won’t go far wrong.  Don’t forget, also make sure you check out check out http://www.graduatejobpodcast.com/subscribe which links to how to subscribe on Itunes, Spotify, Youtube, and by email. So something for everyone there. And don’t forget to check out today’s sponsor who are our friends over at CareerGym.com. Career Gym is the number one place for you to undertake all of your psychometric tests which you will face when you apply for a graduate job. No matter what graduate job you apply for you’re going to have to face some type of verbal reasoning, situational judgment, and working style tests. You can practice these at CareerGym.com. Use code GJP to get 20% off all of their tests! MORE SPECIFICALLY IN THIS EPISODE YOU’LL LEARN ABOUT: How to get a job as a coder and programmer without a degree Learn the best coding language to use as a first time coder Discover the top resources to use if you are starting out as a coder Uncover why you need to start applying for your first coding job before you think you’re ready Discover the key mistakes people make when applying for a graduate job in coding What sets successful coders out from the crowd when applying for their first graduate job How to ace a technical interview for your first job as a coder

Links: https://www.codewithjason.com/ https://www.jasonswett.net/

Guest: Jason Swett @JasonSwett Full show notes are at https://developeronfire.com/podcast/episode-311-jason-swett-growing-socailly

2018 is right around the corner! Are there any big life changes coming your way? Could this be the year when you actually quit (or lose) your job and start your own freelancing business? Jason Swett, a programmer and app developer, survived the worst-case scenario during his very first year as a freelancer. He has some entertaining stories, followed by some great advice on how you might be able to survive your own “firsts” as a full-time freelancer. https://freelancetransformation.com/episode147

Jason Swett shares lessons he’s learned in the process of ditching hourly.

Tweet this Episode Jason Swett is a former Ruby Rogues panelist and the author of Angular on Rails. He's also a contractor and corporate trainer. Jason and Chuck dive into Jason's story getting into programming, Ruby, and talk about his current and past ventures in entrepreneurship. We also talk about writing courses and ebooks and blog posts. Links: Pascal Geocities Angelfire Perl Symfony framework PHP CodeIgniter Drupal Laravel Lisp Clojure Python Django Ruby Rails Amir Rajan's My Ruby Story Angular on Rails Basecamp Microconf JasonSwett.net Amazon AWS Indie Hackers Post Justin Gordon Justin Gordon's episode on Ruby Rogues Phoenix Elixir React Vue Webpacker Prototype.js JQuery Todd Motto Green Bits Email Jason @jasonswett Picks Jason: Amazon Web Services in Action awsrails.com Chuck Gitlab Mattermost The Daily Lasagna Entreprogrammers Ruby Dev Summit

Tweet this Episode Jason Swett is a former Ruby Rogues panelist and the author of Angular on Rails. He's also a contractor and corporate trainer. Jason and Chuck dive into Jason's story getting into programming, Ruby, and talk about his current and past ventures in entrepreneurship. We also talk about writing courses and ebooks and blog posts. Links: Pascal Geocities Angelfire Perl Symfony framework PHP CodeIgniter Drupal Laravel Lisp Clojure Python Django Ruby Rails Amir Rajan's My Ruby Story Angular on Rails Basecamp Microconf JasonSwett.net Amazon AWS Indie Hackers Post Justin Gordon Justin Gordon's episode on Ruby Rogues Phoenix Elixir React Vue Webpacker Prototype.js JQuery Todd Motto Green Bits Email Jason @jasonswett Picks Jason: Amazon Web Services in Action awsrails.com Chuck Gitlab Mattermost The Daily Lasagna Entreprogrammers Ruby Dev Summit

Tweet this Episode Jason Swett is a former Ruby Rogues panelist and the author of Angular on Rails. He's also a contractor and corporate trainer. Jason and Chuck dive into Jason's story getting into programming, Ruby, and talk about his current and past ventures in entrepreneurship. We also talk about writing courses and ebooks and blog posts. Links: Pascal Geocities Angelfire Perl Symfony framework PHP CodeIgniter Drupal Laravel Lisp Clojure Python Django Ruby Rails Amir Rajan's My Ruby Story Angular on Rails Basecamp Microconf JasonSwett.net Amazon AWS Indie Hackers Post Justin Gordon Justin Gordon's episode on Ruby Rogues Phoenix Elixir React Vue Webpacker Prototype.js JQuery Todd Motto Green Bits Email Jason @jasonswett Picks Jason: Amazon Web Services in Action awsrails.com Chuck Gitlab Mattermost The Daily Lasagna Entreprogrammers Ruby Dev Summit

RR 314 DynamoDB on Rails with Chandan Jhunjhunwal Today's Ruby Rogues podcast features DynamoDB on Rails with Chandan Jhunjhunwal. DynamoDB is a NoSQL database that helps your team solve managing infrastructure issues like setup, costing and maintenance. Take some time to listen and know more about DynamoDB! [00:02:18] – Introduction to Chandan Jhunjhunwal Chanchan Jhunjhunwal is an owner of Faodail Technology, which is currently helping many startups for their web and mobile applications. They started from IBM, designing and building scalable mobile and web applications. He mainly worked on C++ and DB2 and later on, worked primarily on Ruby on Rails. Questions for Chandan [00:04:05] – Introduction to DynamoDB on Rails I would say that majority of developers work in PostgreSQL, MySQL or other relational database. On the other hand, Ruby on Rails is picked up by many startup or founder for actually implementing their ideas and bringing them to scalable products. I would say that more than 80% of developers are mostly working on RDBMS databases. For the remaining 20%, their applications need to capture large amounts of data so they go with NoSQL. In NoSQL, there are plenty of options like MongoDB, Cassandra, or DynamoDB. When using AWS, there’s no provided MongoDB. With Cassandra, it requires a lot of infrastructure setup and costing, and you’ll have to have a team which is kind of maintaining it on a day to day basis. So DynamoDB takes all those pain out of your team and you no longer have to focus on managing the infrastructure. [00:07:35] – Is it a good idea to start with a regular SQL database and then, switch to NoSQL database or is it better to start with NoSQL database from day one? It depends on a couple of factors. For many of the applications, they start with RDBMS because they just want to get some access, and probably switch to something like NoSQL. First, you have to watch the incoming data and their capacity. Second is familiarity because most of the developers are more familiar with RDBMS and SQL queries. For example, you have a feed application, or a messaging application, where you know that there will be a lot of chat happening and you’d expect that you’re going to take a huge number of users. You can accommodate that in RDBMS but I would probably not recommend that. [00:09:30] Can I use DynamoDB as a caching mechanism or cache store? I would not say replacement, exactly. On those segments where I could see that there’s a lot of activity happening, I plugged in DynamoDB. The remaining part of the application was handled by RDBMS. In many applications, what I’ve seen is that they have used a combination of them. [00:13:05] How do you decide if you actually want to use DynamoDB for all the data in your system? The place where we say that this application is going to be picked from day one is where the number of data which will be coming will increase. It also depends on the development team that you have if they’re familiar with DynamoDB, or any other NoSQL databases. [00:14:50] Is DynamoDB has document store or do you have of columns? You can say key value pairs or document stores. The terminologies are just different and the way you design the database. In DynamoDB, you have something like hash key and range key. [00:22:10] – Why don’t we store images in the database? I would say that there are better places to store the, which is faster and cheaper. There are better storage like CDN or S3. Another good reason is that if you want to fetch a proper size of image based on the user devices screen, resizing and all of the stuff inside the database could be cumbersome. You’ll repeat adding different columns where we’ll be storing those different sizes of images. [00:24:40] – Is there a potentially good reason for NoSQL database as your default go-to data store? If you have some data, which is complete unstructured, if you try to store back in RDBMS, it will be a pain. If we talk about the kind of media which gets generated in our day to day life, if you try to model them in a relational database, it will be pretty painful and eventually, there will be a time when you don’t know how to create correlations. [00:28:30] – Horizontally scalable versus vertically scalable In vertically scalable, when someone posts, we keep adding that at the same table. As we add data to the table, the database size increases (number of rows increases). But in horizontally scalable, we keep different boxes connected via Hadoop or Elastic MapReduce which will process the added data. [00:30:20] – What does it take to hook up a DynamoDB instance to a Rails app? We could integrate DynamoDB by using the SDK provided by AWS. I provided steps which I’ve outlined in the blog - how to create different kinds of tables, how to create those indexes, how to create the throughput, etc. We could configure AWS SDK, add the required credential, then we could create different kinds of tables. [00:33:00] – In terms of scaling, what is the limit for something like PostgreSQL or MySQL, versus DynamoDB? There’s no scalability limit in DynamoDB, or any other NoSQL solutions. Picks David Kimura             CorgUI Jason Swett      Database Design for Mere Mortals Charles Maxwood VMWare Workstation GoCD Ruby Rogues Parley Ruby Dev Summit Chandan Jhunjhunwal      Twitter @ChandanJ chandan@faodailtechnology.com

RR 314 DynamoDB on Rails with Chandan Jhunjhunwal Today's Ruby Rogues podcast features DynamoDB on Rails with Chandan Jhunjhunwal. DynamoDB is a NoSQL database that helps your team solve managing infrastructure issues like setup, costing and maintenance. Take some time to listen and know more about DynamoDB! [00:02:18] – Introduction to Chandan Jhunjhunwal Chanchan Jhunjhunwal is an owner of Faodail Technology, which is currently helping many startups for their web and mobile applications. They started from IBM, designing and building scalable mobile and web applications. He mainly worked on C++ and DB2 and later on, worked primarily on Ruby on Rails. Questions for Chandan [00:04:05] – Introduction to DynamoDB on Rails I would say that majority of developers work in PostgreSQL, MySQL or other relational database. On the other hand, Ruby on Rails is picked up by many startup or founder for actually implementing their ideas and bringing them to scalable products. I would say that more than 80% of developers are mostly working on RDBMS databases. For the remaining 20%, their applications need to capture large amounts of data so they go with NoSQL. In NoSQL, there are plenty of options like MongoDB, Cassandra, or DynamoDB. When using AWS, there’s no provided MongoDB. With Cassandra, it requires a lot of infrastructure setup and costing, and you’ll have to have a team which is kind of maintaining it on a day to day basis. So DynamoDB takes all those pain out of your team and you no longer have to focus on managing the infrastructure. [00:07:35] – Is it a good idea to start with a regular SQL database and then, switch to NoSQL database or is it better to start with NoSQL database from day one? It depends on a couple of factors. For many of the applications, they start with RDBMS because they just want to get some access, and probably switch to something like NoSQL. First, you have to watch the incoming data and their capacity. Second is familiarity because most of the developers are more familiar with RDBMS and SQL queries. For example, you have a feed application, or a messaging application, where you know that there will be a lot of chat happening and you’d expect that you’re going to take a huge number of users. You can accommodate that in RDBMS but I would probably not recommend that. [00:09:30] Can I use DynamoDB as a caching mechanism or cache store? I would not say replacement, exactly. On those segments where I could see that there’s a lot of activity happening, I plugged in DynamoDB. The remaining part of the application was handled by RDBMS. In many applications, what I’ve seen is that they have used a combination of them. [00:13:05] How do you decide if you actually want to use DynamoDB for all the data in your system? The place where we say that this application is going to be picked from day one is where the number of data which will be coming will increase. It also depends on the development team that you have if they’re familiar with DynamoDB, or any other NoSQL databases. [00:14:50] Is DynamoDB has document store or do you have of columns? You can say key value pairs or document stores. The terminologies are just different and the way you design the database. In DynamoDB, you have something like hash key and range key. [00:22:10] – Why don’t we store images in the database? I would say that there are better places to store the, which is faster and cheaper. There are better storage like CDN or S3. Another good reason is that if you want to fetch a proper size of image based on the user devices screen, resizing and all of the stuff inside the database could be cumbersome. You’ll repeat adding different columns where we’ll be storing those different sizes of images. [00:24:40] – Is there a potentially good reason for NoSQL database as your default go-to data store? If you have some data, which is complete unstructured, if you try to store back in RDBMS, it will be a pain. If we talk about the kind of media which gets generated in our day to day life, if you try to model them in a relational database, it will be pretty painful and eventually, there will be a time when you don’t know how to create correlations. [00:28:30] – Horizontally scalable versus vertically scalable In vertically scalable, when someone posts, we keep adding that at the same table. As we add data to the table, the database size increases (number of rows increases). But in horizontally scalable, we keep different boxes connected via Hadoop or Elastic MapReduce which will process the added data. [00:30:20] – What does it take to hook up a DynamoDB instance to a Rails app? We could integrate DynamoDB by using the SDK provided by AWS. I provided steps which I’ve outlined in the blog - how to create different kinds of tables, how to create those indexes, how to create the throughput, etc. We could configure AWS SDK, add the required credential, then we could create different kinds of tables. [00:33:00] – In terms of scaling, what is the limit for something like PostgreSQL or MySQL, versus DynamoDB? There’s no scalability limit in DynamoDB, or any other NoSQL solutions. Picks David Kimura             CorgUI Jason Swett      Database Design for Mere Mortals Charles Maxwood VMWare Workstation GoCD Ruby Rogues Parley Ruby Dev Summit Chandan Jhunjhunwal      Twitter @ChandanJ chandan@faodailtechnology.com

RR 314 DynamoDB on Rails with Chandan Jhunjhunwal Today's Ruby Rogues podcast features DynamoDB on Rails with Chandan Jhunjhunwal. DynamoDB is a NoSQL database that helps your team solve managing infrastructure issues like setup, costing and maintenance. Take some time to listen and know more about DynamoDB! [00:02:18] – Introduction to Chandan Jhunjhunwal Chanchan Jhunjhunwal is an owner of Faodail Technology, which is currently helping many startups for their web and mobile applications. They started from IBM, designing and building scalable mobile and web applications. He mainly worked on C++ and DB2 and later on, worked primarily on Ruby on Rails. Questions for Chandan [00:04:05] – Introduction to DynamoDB on Rails I would say that majority of developers work in PostgreSQL, MySQL or other relational database. On the other hand, Ruby on Rails is picked up by many startup or founder for actually implementing their ideas and bringing them to scalable products. I would say that more than 80% of developers are mostly working on RDBMS databases. For the remaining 20%, their applications need to capture large amounts of data so they go with NoSQL. In NoSQL, there are plenty of options like MongoDB, Cassandra, or DynamoDB. When using AWS, there’s no provided MongoDB. With Cassandra, it requires a lot of infrastructure setup and costing, and you’ll have to have a team which is kind of maintaining it on a day to day basis. So DynamoDB takes all those pain out of your team and you no longer have to focus on managing the infrastructure. [00:07:35] – Is it a good idea to start with a regular SQL database and then, switch to NoSQL database or is it better to start with NoSQL database from day one? It depends on a couple of factors. For many of the applications, they start with RDBMS because they just want to get some access, and probably switch to something like NoSQL. First, you have to watch the incoming data and their capacity. Second is familiarity because most of the developers are more familiar with RDBMS and SQL queries. For example, you have a feed application, or a messaging application, where you know that there will be a lot of chat happening and you’d expect that you’re going to take a huge number of users. You can accommodate that in RDBMS but I would probably not recommend that. [00:09:30] Can I use DynamoDB as a caching mechanism or cache store? I would not say replacement, exactly. On those segments where I could see that there’s a lot of activity happening, I plugged in DynamoDB. The remaining part of the application was handled by RDBMS. In many applications, what I’ve seen is that they have used a combination of them. [00:13:05] How do you decide if you actually want to use DynamoDB for all the data in your system? The place where we say that this application is going to be picked from day one is where the number of data which will be coming will increase. It also depends on the development team that you have if they’re familiar with DynamoDB, or any other NoSQL databases. [00:14:50] Is DynamoDB has document store or do you have of columns? You can say key value pairs or document stores. The terminologies are just different and the way you design the database. In DynamoDB, you have something like hash key and range key. [00:22:10] – Why don’t we store images in the database? I would say that there are better places to store the, which is faster and cheaper. There are better storage like CDN or S3. Another good reason is that if you want to fetch a proper size of image based on the user devices screen, resizing and all of the stuff inside the database could be cumbersome. You’ll repeat adding different columns where we’ll be storing those different sizes of images. [00:24:40] – Is there a potentially good reason for NoSQL database as your default go-to data store? If you have some data, which is complete unstructured, if you try to store back in RDBMS, it will be a pain. If we talk about the kind of media which gets generated in our day to day life, if you try to model them in a relational database, it will be pretty painful and eventually, there will be a time when you don’t know how to create correlations. [00:28:30] – Horizontally scalable versus vertically scalable In vertically scalable, when someone posts, we keep adding that at the same table. As we add data to the table, the database size increases (number of rows increases). But in horizontally scalable, we keep different boxes connected via Hadoop or Elastic MapReduce which will process the added data. [00:30:20] – What does it take to hook up a DynamoDB instance to a Rails app? We could integrate DynamoDB by using the SDK provided by AWS. I provided steps which I’ve outlined in the blog - how to create different kinds of tables, how to create those indexes, how to create the throughput, etc. We could configure AWS SDK, add the required credential, then we could create different kinds of tables. [00:33:00] – In terms of scaling, what is the limit for something like PostgreSQL or MySQL, versus DynamoDB? There’s no scalability limit in DynamoDB, or any other NoSQL solutions. Picks David Kimura             CorgUI Jason Swett      Database Design for Mere Mortals Charles Maxwood VMWare Workstation GoCD Ruby Rogues Parley Ruby Dev Summit Chandan Jhunjhunwal      Twitter @ChandanJ chandan@faodailtechnology.com

Obie Fernandez is the author of The Rails Way series. He has been in the programming industry for almost 25 years. He helped cultivate software development with Jason Swett at Africa. Tune in to today's fascinating talk about The Rails 5 Way with Obie Fernandez! 

Obie Fernandez is the author of The Rails Way series. He has been in the programming industry for almost 25 years. He helped cultivate software development with Jason Swett at Africa. Tune in to today's fascinating talk about The Rails 5 Way with Obie Fernandez! 

Obie Fernandez is the author of The Rails Way series. He has been in the programming industry for almost 25 years. He helped cultivate software development with Jason Swett at Africa. Tune in to today's fascinating talk about The Rails 5 Way with Obie Fernandez! 

On today’s episode, Charles Max Wood, David Kimura, Jason Swett, and Brian Hogan discuss Software Intellectual Property and Forensics with Bob Zeidman. Bob is the President of Zeidman Consulting, a company dedicated in assisting clients and lawyers during litigation. He is an expert on patents, trade secrets, and copyrights of hardware and software. Tune in and be informed about the legal issues in programming!

On today’s episode, Charles Max Wood, David Kimura, Jason Swett, and Brian Hogan discuss Software Intellectual Property and Forensics with Bob Zeidman. Bob is the President of Zeidman Consulting, a company dedicated in assisting clients and lawyers during litigation. He is an expert on patents, trade secrets, and copyrights of hardware and software. Tune in and be informed about the legal issues in programming!

On today’s episode, Charles Max Wood, David Kimura, Jason Swett, and Brian Hogan discuss Software Intellectual Property and Forensics with Bob Zeidman. Bob is the President of Zeidman Consulting, a company dedicated in assisting clients and lawyers during litigation. He is an expert on patents, trade secrets, and copyrights of hardware and software. Tune in and be informed about the legal issues in programming!

On today’s episode, Charles Max Wood, Jason Swett, Brian Hogan, and David Kimura discuss Scope Wars and Being New with Malinna Leach. Malinna is a Junior Full-Stack Web Developer who just graduated from Makers Academy. Tune in and learn more about Scope Wars and what inspired her to write the blog post.

On today’s episode, Charles Max Wood, Jason Swett, Brian Hogan, and David Kimura discuss Scope Wars and Being New with Malinna Leach. Malinna is a Junior Full-Stack Web Developer who just graduated from Makers Academy. Tune in and learn more about Scope Wars and what inspired her to write the blog post.

On today’s episode, Charles Max Wood, Jason Swett, Brian Hogan, and David Kimura discuss Scope Wars and Being New with Malinna Leach. Malinna is a Junior Full-Stack Web Developer who just graduated from Makers Academy. Tune in and learn more about Scope Wars and what inspired her to write the blog post.

On today’s episode, Charles Max Wood, Jason Swett, Brian Hogan, and David Kimura discuss Scaling Web Applications. Tune in and learn more as each of them share their own experiences in scaling Ruby applications!

On today’s episode, Charles Max Wood, Jason Swett, Brian Hogan, and David Kimura discuss Scaling Web Applications. Tune in and learn more as each of them share their own experiences in scaling Ruby applications!

On today’s episode, Charles Max Wood, Jason Swett, Brian Hogan, and David Kimura discuss Scaling Web Applications. Tune in and learn more as each of them share their own experiences in scaling Ruby applications!

On today’s episode, Jason Swett and David Kimura discuss The Future of Work in Web Development with Erik Dietrich. Erik is the founder of DaedTech LLC, programmer, architect, IT management consultant, blogger, and technologist. Tune in and listen as he talks about where he sees things are headed in web development.

On today’s episode, Jason Swett and David Kimura discuss The Future of Work in Web Development with Erik Dietrich. Erik is the founder of DaedTech LLC, programmer, architect, IT management consultant, blogger, and technologist. Tune in and listen as he talks about where he sees things are headed in web development.

On today’s episode, Jason Swett and David Kimura discuss The Future of Work in Web Development with Erik Dietrich. Erik is the founder of DaedTech LLC, programmer, architect, IT management consultant, blogger, and technologist. Tune in and listen as he talks about where he sees things are headed in web development.

On today’s episode, Charles Max Wood, Brian Hogan, and Jason Swett discuss The European Ruby Community with Devon C Estes. Devon is a Ruby and RAILS developer for Education Superhighway, a nonprofit in San Francisco which helps every public school classroom in America to upgrade their Internet access. He also does a lot of Elixir and open source stuff. Tune in as he shares more about the Ruby communities outside the US.

On today’s episode, Charles Max Wood, Brian Hogan, and Jason Swett discuss The European Ruby Community with Devon C Estes. Devon is a Ruby and RAILS developer for Education Superhighway, a nonprofit in San Francisco which helps every public school classroom in America to upgrade their Internet access. He also does a lot of Elixir and open source stuff. Tune in as he shares more about the Ruby communities outside the US.

On today’s episode, Charles Max Wood, Brian Hogan, and Jason Swett discuss The European Ruby Community with Devon C Estes. Devon is a Ruby and RAILS developer for Education Superhighway, a nonprofit in San Francisco which helps every public school classroom in America to upgrade their Internet access. He also does a lot of Elixir and open source stuff. Tune in as he shares more about the Ruby communities outside the US.

00:25 -  Why Ruby is still relevant 06:30 - How we got started with Ruby 08:20 - Why are people saying Ruby is dying? 13:00 - The Ruby community 15:00 - Debating the “waste of time” argument 20:05 - Learning other languages 23:50 - The “pie” 27:05 - Revitalizing Ruby 38:15 - Advice for the worrier Picks: Angular for Rails Developers by Jason Swett (Jerome) Vets Who Code (Jason) The Rise of Theodore Roosevelt by Edmund Morris (Jason) Your Money or Your Life by Vicki Robin (Jason) Going outside (Jason) Gitlab (Charles) Devchat Conferences (Charles) The 12 Week Year and spreadsheet (Charles) Devchat hangout/webinar (Charles)

00:25 -  Why Ruby is still relevant 06:30 - How we got started with Ruby 08:20 - Why are people saying Ruby is dying? 13:00 - The Ruby community 15:00 - Debating the “waste of time” argument 20:05 - Learning other languages 23:50 - The “pie” 27:05 - Revitalizing Ruby 38:15 - Advice for the worrier Picks: Angular for Rails Developers by Jason Swett (Jerome) Vets Who Code (Jason) The Rise of Theodore Roosevelt by Edmund Morris (Jason) Your Money or Your Life by Vicki Robin (Jason) Going outside (Jason) Gitlab (Charles) Devchat Conferences (Charles) The 12 Week Year and spreadsheet (Charles) Devchat hangout/webinar (Charles)

00:25 -  Why Ruby is still relevant 06:30 - How we got started with Ruby 08:20 - Why are people saying Ruby is dying? 13:00 - The Ruby community 15:00 - Debating the “waste of time” argument 20:05 - Learning other languages 23:50 - The “pie” 27:05 - Revitalizing Ruby 38:15 - Advice for the worrier Picks: Angular for Rails Developers by Jason Swett (Jerome) Vets Who Code (Jason) The Rise of Theodore Roosevelt by Edmund Morris (Jason) Your Money or Your Life by Vicki Robin (Jason) Going outside (Jason) Gitlab (Charles) Devchat Conferences (Charles) The 12 Week Year and spreadsheet (Charles) Devchat hangout/webinar (Charles)

00:42 - Introducing Jason Swett Angular on Rails Use the code “rubyrogues” to get $10 off your purchase Twitter Email: jason@angularonrails.com 2:20 - Angular or Rails? 4:40 - Real-time data modeling 9:00 - Angular CLI 11:15 - Structuring Angular and Rails apps 16:50 - Should beginners learn Angular or Rails first? 19:50 - Building apps and tying Angular and Rails together Tour of Heroes Tutorial Jason’s blog post 25:00 - Angular on Rails feedback 28:00 - What’s the hardest part of integrating Angular and Rails? 31:00 - Why invest in Angular when it evolves so fast? 33:35 - Why did Jason write his book? Angular for Rails Developers Pragmatic Bookshelf 37:50 - How to get the most out of the book 42:40 - Panelist Jerome Hardaway Previous Ruby Rogues Episode Vets Who Code DreamForce Picks: Tour of Heroes Tutorial (Jerome) General Assembly (Jerome) DreamForce (Jerome) Adventures in Angular Podcast (Charles and Jason) Angular Remote Conf videos (Charles) NgBook (Jason) How to Win Friends and Influence People by Dale Carnegie (Jason) The 7 Habits of Highly Successful People by Stephen Covey (Jason)

00:42 - Introducing Jason Swett Angular on Rails Use the code “rubyrogues” to get $10 off your purchase Twitter Email: jason@angularonrails.com 2:20 - Angular or Rails? 4:40 - Real-time data modeling 9:00 - Angular CLI 11:15 - Structuring Angular and Rails apps 16:50 - Should beginners learn Angular or Rails first? 19:50 - Building apps and tying Angular and Rails together Tour of Heroes Tutorial Jason’s blog post 25:00 - Angular on Rails feedback 28:00 - What’s the hardest part of integrating Angular and Rails? 31:00 - Why invest in Angular when it evolves so fast? 33:35 - Why did Jason write his book? Angular for Rails Developers Pragmatic Bookshelf 37:50 - How to get the most out of the book 42:40 - Panelist Jerome Hardaway Previous Ruby Rogues Episode Vets Who Code DreamForce Picks: Tour of Heroes Tutorial (Jerome) General Assembly (Jerome) DreamForce (Jerome) Adventures in Angular Podcast (Charles and Jason) Angular Remote Conf videos (Charles) NgBook (Jason) How to Win Friends and Influence People by Dale Carnegie (Jason) The 7 Habits of Highly Successful People by Stephen Covey (Jason)

00:42 - Introducing Jason Swett Angular on Rails Use the code “rubyrogues” to get $10 off your purchase Twitter Email: jason@angularonrails.com 2:20 - Angular or Rails? 4:40 - Real-time data modeling 9:00 - Angular CLI 11:15 - Structuring Angular and Rails apps 16:50 - Should beginners learn Angular or Rails first? 19:50 - Building apps and tying Angular and Rails together Tour of Heroes Tutorial Jason’s blog post 25:00 - Angular on Rails feedback 28:00 - What’s the hardest part of integrating Angular and Rails? 31:00 - Why invest in Angular when it evolves so fast? 33:35 - Why did Jason write his book? Angular for Rails Developers Pragmatic Bookshelf 37:50 - How to get the most out of the book 42:40 - Panelist Jerome Hardaway Previous Ruby Rogues Episode Vets Who Code DreamForce Picks: Tour of Heroes Tutorial (Jerome) General Assembly (Jerome) DreamForce (Jerome) Adventures in Angular Podcast (Charles and Jason) Angular Remote Conf videos (Charles) NgBook (Jason) How to Win Friends and Influence People by Dale Carnegie (Jason) The 7 Habits of Highly Successful People by Stephen Covey (Jason)

Bob and Patrick interview Jason Swett, founder of Snip Salon Software, www.snipsalonsoftware.com