Ruby Rogues

Todd Kaufman is one of the cofounders of Test Double, a software development consultancy that was started 8 years ago. Todd talks about how he got started with Test Double and how it grew. He and Justin started Test Double because he felt that a lot of consultancies didn’t align with what they thought was important. Most consultancies then didn’t focus on good software development practices, and instead focused solely on the process. They decided that they would put the developers first and foremost so they could solve hard problems.Charles talks about his experience with a consultancy, where he was fired after his project finished, and asks how Test Double does things differently. Todd talks about the importance of financial stability in a consultancy, and one way that Test Double accomplishes this is by being a completely remote company to cut out the cost of having an office,Todd shares their approach to the projects they take on. Their contracts are open ended and they tend to work with clients for a longer duration. They discuss the differences in knowledge that comes from working with a product company versus a consultancy. A product company will typically give you depth, while a consultancy will give you variety. When deciding which you want to work for, you need to know if you want a steady approach to software development or do you want the challenge change up from time to time. Todd delves deeper into their policy of not doing fixed bids and how they uphold that policy when negotiating with companies. Test Double’s unique approach is to engender trust where if the client feels that they are not getting the results they want, they can terminate the contract and ask them to leave. This in turn makes the fixed scope go away. Their only requirement is that the client gives them a weeks notice before termination. When taking on a project, Test Double strives to quickly integrate with an existing team, help them, and leave them in a better place than we found them. They can help with testing, learning languages, meeting deadlines, and communication.The panel discusses some of the gotchas of building up a consulting company. Todd says that you always need someone looking for ne prospects and jobs, keep a consistent level of sales activity, and address issues in real time. He talks about what the company does to generate awareness, such as conference presentations, the website and blogs, networking, and how the company is organized to help manage sales.Todd and the panel discuss Test Double’s process for growing and shrinking the company ahd what drives their decisions. Test Double’s priority is to make sure that the size of the compan does not affect the work experience. He talks about their four step hiring process and their trend of hiring experienced programmers. The panel agrees that there is a commitment to hiring junior programmers. Though Test Double does not typically hire junior programmers, they help companies that do. Todd has found that there are companies that want to hire juniors, but they have no experience leveling them up, so his consultancy helps clients develop mentorship practices.Todd talks about some mistakes made and lessons learned in starting his company. One of his primary regrets is not focusing on diversity and inclusivity enough during the early days of the company. Their goal stated as a company is to improve the industry, and be an example for teams to follow on how to build healthy teams, but much of their early members were fairly homogenous. Todd believes that variety in a company leads to better problem identification and solutions. The panel discusses how to really identify diversity of background, because sometimes it can be proxied by diversity of physical appearance, but sometimes it can’t.It’s important to identify people that truly are diverse, and not just say ‘we want more women’ or ‘we want more people of color’. They discuss ways to increase diversity in hiring. Todd talks about what it was like to make the first hire for Test Double.Todd shares how he decided what Test Double’s values and mission is. They had to consider why they were putting so much energy into building Test Double, and it was because they wanted to help fix the industry and improve the way the world builds software. He talks about how he implements it within his company, especially since they do not have a physical office.  One of Todd’s visions for the software industry is that software isn’t viewed as manufacturing and getting the commodity purchasing out of software development. He also hopes to help create more sustainable code and to fix the problems that caused unsustainable code, whether in the code or the team.Test Double doesn’t focus solely on code, but also on the work environment of the company. They do that by trying to act as an extension of their existing team. Todd talks about what it’s like running a primarily remote company and how it affects their clients. He talks about how the company builds camaraderie between its employees, including an automated tool to pair you up with somebody to have ‘coffee time’ with once a week. He talks about the tools they use, like Zoom and Slack, and the different leadership roles within Test Double. Listeners are encouraged to go to Test Double’s website to learn more about what they’re working on. PanelistsCharles Max WoodDavid KimuraNate HopkinsAndrew MasonWith special guest: Todd KaufmanSponsorsSentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in BlockchainLinksTest DoubleFixed bid  PipedriveZoomSlack Follow DevChatTV on Facebook and Twitter PicksDavid Kimura:Simply Heinz KetchupPyle Rackmount Distribution ConditionerNate Hopkins:The War on Normal People by Andrew YangTest Double Standard RB LibraryCharles Max Wood:Nikon D5600Rode Newsshooter  Andrew Mason:Remote Containers extensionTodd Kaufman:Drive by Daniel PinkThe Hard Thing About Hard Things by Ben HorowitzSpecial Guest: Todd Kaufman. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

Episode Summary   Today’s guest Elia Schito has been a Ruby developer for 12+ years and works for Nebulab. During his career he looked for Ruby to JavaScript translators and found Opal. The panel discusses where Opal belongs within an app and when the compilation into JavaScript occurs. The main reason a person would want to use Opal is to avoid writing in JavaScript. Elia talks about the benefits of using Opal. One is that productivity is better in a language like Ruby. Also, if you’re working on a project that needs to get done quickly, it makes sense to use Opal so that your speed is not hindered. Elia talks about testing Opal with things like WebPacker and Hyperstack, and explains what Hyperstack is.  Opal recently released a newer, bigger version, and Elia talks about the features of the new release. He details what kind of JavaScript it produces and how to hook it into your CICD, how to run it locally, and overall how to use the compiler.  He talks about how to debug in Opal. He notes that during the development cycle in Opal, you can refresh your page and it will compile the Ruby code into JS, so if there are any errors you will see it immediately. Opal is compatible with other tools to check your code. In the future, Elia wants to increase the coverage of the core and standard library, and believes that Opal is a great way to increase your skills in Ruby and JavaScript. He talks about the general reception of Opal among users. Opal is a perfect fit for smaller teams or older fullstack developers, especially if you don’t have a frontend team Elia notes that Opal, much like anything else, is a matter of preference, and relates it to the past reliance on CoffeeScript. For developers who refuse to write in JavaScript, Opal is an excellent option. He talks about the speed of compiling ruby to JavaScript in Opal and how it supports keeping current with Rails versions and other frameworks.  The panel asks if the Opal community made any inroads with DHH for making it part of the Rails stack proper and whether Opal wants to be integrated with Rails. Elia talks about some of Opal’s contributions to the Ruby Community. Elia talks about what generally happens if you choose to use Opal in a project. Opal is small, but you will have to make some tradeoffs. You have to call your standard library from Opal, but there are many ways to overcome that. The show concludes with Elia calling on the community to help him resurrect the Volt framework. Panelists Andrew Mason David Kimura Nate Hopkins With special guest: Elia Schito Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues My Ruby Story Links Opal  WebPackerStimulusHyperstackCapybaraCoffeeScriptDeviseClearwaterReactiveVolt frameworkNebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated BillingPingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his websiteExplaining PostmodernismTexmateSpecial Guest: Elia Schito. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

Episode SummaryAdam Cuppy is the cofounder and current chief operating officer at Zeal, web and mobile app consultancy. Today the panel is discussing the talk he gave at Rails Conf called Mechanically Confident. Adam has a hypothesis that confidence is not the result of belief alone but ingrained routine. The more routine, the more pattern, the more rehearsal applied to a given thing, the more confident you are with that thingThe history behind Adam’s theory stems from his background in theater and performing arts. The concept of rehearsal is commonplace in the performing arts, but not other industries. He talks about where rehearsal comes in for programmers and how he has noticed the patterns of senior developers. The panelists talk about where they see routine and rehearsal come into play with their workThe panelists wonder how do you avoid a stopgap from a slight change, and Adam relates it to some of the most rehearsed actors, improv actors. It’s important to rehearse everything you can, building a routine around the things you control, so that when something does happen you have everything else under control. Adam talks about different tools to help build a routine and an experiment he did with a group of interns to help them establish a routine. When the interns had a routine, in this case, a designated order in which they placed their windows, he saw immediate improvement in their performance. When the order of the windows was changed, it caused initial confusion in the group. The panel discusses the cognitive load applied to managing chaos and how a routine helps. Adam admits that routine is an individualized thing, and that  chaos can be a pattern as long as you know where everything isThey wonder at what point does reliance on patterns become false confidence, relating it to the strict TDD trend within the Ruby community, and how too much routine can make you rigid. Todd again ties this back to acting. The panelists discuss ways to implement a routine. Adam advises to start by finding what is it that you do consistently that creates a happy and proud result. They talk about how to create that small iterative change towards something I want to get better at. The panelists discuss the merits of visualization and if it is a tactic that developers can use to gain confidence, and what to do after you’ve visualized. They discuss whether looking ahead helps or hinders a person, and Adam talks about how to look ahead properly.The show concludes with Adam’s advice for people who would like to give a presentation or conference talk but hasn’t. He talks about how his theory has evolved since he first gave his talk. His closing thoughts are that trends matter more than individual days, how to expedite the experience timeline, and the importance of perspective. If you want to expedite learning, give the why behind something PanelistsAndrew MasonDavid KimuraNate HopkinsCharles Max WoodWith special guest: Adam Cuppy SponsorsSentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in DevopsLinksZealTeamocilDockerTDDSpeakerline Follow DevChat on Facebook and Twitter PicksDavid Kimura:Belt sanderPingVerse Nate Hopkins:Talent is OverratedConfreaks 10 Years: KeynoteAndrew Mason: His company is hiring, contact him @andrewmcodesCharles Max Wood:Algolia  RXJS LiveGitlab CommitAdam Cuppy:This Is Marketing by Seth GodenInterestings podcast Follow Adam @adamcuppySpecial Guest: Adam Cuppy. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

SponsorsSentry use code “devchat” for $100 credit Sustain Our SoftwareAdventures in BlockchainPanelDavid KimuraAndrew MasonNate HopkinsCharles Max WoodWith Special Guest: David Heinemeier HanssonEpisode SummaryToday’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers.  LinksAction Text  Action MailboxStimulus.jsTurbolinksHamlJBuilder Follow DevChat on Facebook and Twitter PicksAndrew Mason:How to Say ItRework episodeNate Hopkins:Stimulus ReflexCharles Max Wood:Atomic HabitsEd Mylet showThe MFCEO with Andy FrisellaDavid Kimura:Swing set kitRails 6His daughter RubyDavid Heinemeier Hansson: Follow David on Twitter @dhh, dhh.dk and Rework.fmTo Have or To BeShape Up bookRails 6Special Guest: David Heinemeier Hansson. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

SponsorsSentry use code “devchat” for $100 credit DatadogReact Native RadioPanelDavid KimuraAndrew MasonWith Special Guest: Paul TarjanEpisode SummaryPaul Tarjan works for Stripe specializing in developer productivity. In the past, he has owned his own company and worked for Facebook. In today’s episode, the panel is talking about Sorbet, a gradual type checker for Ruby that Paul built. Paul talks about how Sorbet fits in the Ruby community and how it works. The two parts of Sorbet are the runtime type check and the static typecheck. Paul talks about how introducing Sorbet at Stripe has changed the way they approach coding. He talks about some of the performance impacts of adding Sorbet, how it differs from other type checkers, and how it was received in the Ruby community. Paul delves into how developers are notified if Sorbet fails a type check while checking a class. The panel discusses ways to convince reluctant team members that introducing a type checker like Sorbet will improve their code, and Paul talks about his experience implementing it at Stripe. He talks about what he sees for the future of Sorbet. The show finishes with the panel discussing similar projects in other languages and their opinions on React in light of Paul’s former employment with Facebook.  LinksStripeSorbetSorbet RailsSorbet StaticOcramypyTypeScriptSorbet.run  FlowReact Follow DevChat on Facebook and Twitter PicksAndrew Mason:Stimulus ReflexDavid Kimura:PingversePaul Tarjan: Follow Paul https://paultarjan.com/SorbetSpecial Guest: Paul Tarjan. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

SponsorsSentry use code “devchat” for $100 credit DatadogPanelDavid KimuraAndrew MasonCharles Max WoodWith Special Guests: Julian FahrerEpisode Summary Julian Fahrer has been a guest on Devchat shows before and recently did a workshop at RailsConf about Docker. He specializes in teaching people about Docker and has his own course, LearnDocker.online. Julian begins by giving suggestions for those considering Dockerizing their Rails applications. He talks about why Docker is a good choice to be used in a local development environment and gives some advice for those who might have trouble running Docker in development. He talks about where Docker fits within the development or production environment. He talks about synchronizing code between development and production and running tests. He advises listeners on how to get started with Docker. He talks about using a Docker registry to build and push images. They discuss how to deal with things once you move to production and how to use containers when considering microservices. Julian talks about debugging in Docker. They finish by talking about Docker’s compatibility with frameworks besides Rails and how services talk to each other in Docker.  LinksJSJ 340: JavaScript Docker with Julian FahrerEMX 10: Docker with Julian FahrerDockerHerokuAlpin.ioUbuntuDocker SinkOSXFSSpringWebpackerAWS  PostgreSQLElasticsearchKubernetesScripts to Rule Them AllLearnDocker.online Follow DevChat on Facebook and Twitter PicksAndrew Mason:Alsop Metal Art Dual Monitor Arms Mental health daysDavid Kimura:Arcade buttonsMini Dewalt air compressorJulan Fahrer:Alexander TechniqueRailswithdocker.comBlitzDonner Follow Julian at Codetales.io and @jufahr Charles Max Wood: Four Corners MonumentDallas Children’s MuseumSpecial Guest: Julian Fahrer. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

SponsorsSentry use code “devchat” for $100 credit DatadogPanelDavid KimuraAndrew MasonNate HopkinsWith Special Guests: Taylor JonesEpisode SummaryTaylor 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.LinksHerokuWebpackerReactSlackjQueryEmberBroccoli.jsStimulusTurbolinksBootstrapConductorZoom Follow DevChat on Facebook and Twitter PicksAndrew Mason:Migration Builder by Jason Swett demo videoDavid Kimura:Build-your-own arcade machineHoney  Taylor Jones: Slack Engineering Team Shape Up book from BasecampFollow Taylor @hiimtaylorjonesSpecial Guest: Taylor Jones. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

SponsorsSentry use code “devchat” for $100 credit DatadogPanelDavid KimuraNate HopkinsAndrew MasonEpisode SummaryToday the panel is talking about documentation. They begin by discussing what documentation is, where it fits within an application, and if the code documents itself. They agree that documentation starts in the comments to explain what you’re doing, but if that’s your exclusive method, then a refactor is in order. They talk about where to start with documentation and different ways they’ve done it. The panel talks about the importance of documentation, especially for people just joining a team. In addition to documenting the project itself, it is important to document what different libraries do and how to interact with them. They discuss where to put this kind of documentation. They talk about documenting patterns, best practices, and procedures in addition to the ‘how to’ of a project. The conversation turns to style guidelines, what they are, and how to keep them up to date. They talk about what tools are available to generate documentation that are close to the code but outside of it that can help keep documentation up to date. The panel believes that there is a relationship between the size of your team and the necessity to document. Nate introduces the idea found in the article by Tom Preston-Werner that you should think about what you’re going to create in the code, and document it first. LinksRDocYARD  RuboCopYAMLSlimERBPrettierProntoApi.rubyonrails.orgSwaggerThoughtbot and Thoughtbot PlaybookAirBNB RubyTestdoubleHoundCIOkonetAPI BlueprintRuby on Rails API documentation guidelinesTom Preston-Werner article Readme Driven Development Follow DevChat on Facebook and Twitter PicksNate Hopkins:Code FundAndrew Mason:SpaceVIMRailsDiffRails ReleasesDavid Kimura:Jackery Supercharger PortableAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

SponsorsSentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues PanelCharles Max WoodAndrew MasonWith Special Guests: David A. Black and Joseph Leo IIIEpisode SummaryDavid A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years. Joseph spent 12 years in software and started the company Def Method Inc. Together, they co-authored the book The Well-Grounded Rubyist, which will soon have its third edition released. They give some of the history behind The Well-Grounded Rubyist. Joseph talks about his experience being brought into the project. David and Joseph talk about how The Well-Grounded Rubyist is different from other books on Ruby. This book is helpful because a lot of people begin by understanding Ruby more than Rails, and this book talks about ways to think about Ruby and understand how it’s structure. Joseph and David talk about how The Well-Grounded Rubyist 3rd edition differs from the 2nd edition. The book has been updated so that a lot of the code and solutions for the exercises are available online and there is an additional chapter in part 3 about Ruby dynamics and how one would write functional programming with RubyThe panel discusses how important it is to learn Ruby before starting a job in Rails 2. They agree that if you are a Ruby developer, even if you’re working on Rails apps, so you should know your tools. They discuss how far down that road The Well Grounded Rubyist would get readers. They panelists talk about other books that are a natural prequel or sequel to the The Well-Grounded Rubyist. Joseph and David talk about their approach to reading books and how The Well-Grounded Rubyist should be read. Their goal in making the book was not to have people work on an overarching application while reading the book, but rather there are exercises and examples that you are encouraged to work through. There are some lessons in the book that you won’t write often, but you still need to know how to do it. While the book doesn’t have everything about Ruby, but the examples are designed to give you the best returns for you study. David and Joseph conclude by giving their final thoughts on the book.LinksThe Well-Grounded Rubyist, Third EditionPerlProgramming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th EditionPractical Object-Oriented Design: An Agile Primer Using Ruby (2nd Edition) by Sandi Metz String mutability Follow DevChat on Facebook and Twitter PicksAndrew Mason:Default GemsCharles Max Wood:Good to Great: Why Some Companies Make The Leap and Others Don't by Jim Collins David A. Black:Pragmatic Programmer 2nd editionDavidablack.net and @david_a_black on TwitterJoseph Leo III: Barbarians at the GateFirehydrant.io @jleo3 and defmethod.comSpecial Guests: David A. Black and Joe Leo III. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

SponsorsSentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues PanelCharles Max WoodAndrew MasonWith Special Guest: Daniel PritchettEpisode Summary Daniel Pritchett started doing Ruby in 2012. Lately he has been working on publishing a book on building Chatbots in Ruby using a framework called Lita and does infrastructure for a startup called Gremlin. Gremlin reaches out to servers and tries to find weak spots so that you can be proactive about solving these problems and be better prepared when fires do start. Daniel’s real purpose in joining the show today was to talk about his book Build Chatbot Interactions. Daniel talks about what he defines as a chatbot. His book teaches you how to program a chatbot with a dozen or so different chatbot skills. Daniel talks about his first community chatbot, @elvis on #memtech IRC, which picked up immediate contributions from local developers. Daniel istructs listeners how to host chatbots and some of the skills that people can pull together for a chatbot from his book. The panel talks about things they would like to do with chatbots, as well as some of the drawbacks and things you have to be careful with. Each skill in Daniel’s book can be a stand-alone skill, or they can be combined. Daniel talks about what convinced him to write a book instead of doing tutorials online. If you would like to purchase the book, click here. Source code for all the book exercises can be found here. LinksLitaHuebotCoffee ScriptChatbotAzure FunctionsHerokuAWS Follow DevChat on Facebook and Twitter PicksAndrew Mason:Lazy DockerCharles Max Wood:Azure FunctionsDaniel Pritchett: AsciinemaServerlessDoctoc Follow Daniel on Twitter, Github, and his personal blog and portfolio Most of the book’s code is also hereSpecial Guest: Daniel Pritchett. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.