title

The Ruby Rogues

DevChat.tv

14
Followers
18
Plays
The Ruby Rogues
The Ruby Rogues

The Ruby Rogues

DevChat.tv

14
Followers
18
Plays
OVERVIEWEPISODESYOU MAY ALSO LIKE

Details

About Us

A weekly discussion by Ruby developers about programming, life, and careers.

Latest Episodes

RR 434: Surviving Webpack with Ross Kaffenberger

Ross Kaffenberger is a software engineer at Stitch Fix and has been developing web applications for the past 12 years, mostly in Ruby and JavaScript. Today he and the panel are discussing how to survive Webpack. When many folks first encounter Webpack, they feel confused, overwhelmed, and don’t know how to get it to do what you want it to. In the latest version they tried to introduce some more sane default settings, but it is still a major change in technology. Ross talks about how his company transitioned Rails 5 to Rails 6 with the new Webpacker. His company chose to take an iterative approach and slowly migrated to Webpacker. His app was very JS heavy with a large number of libraries, many of which were not very Webpack friendly. They chose to separate out the vendor libraries into a separate bundle, that way they could contain each deploy. They still had to add some configuration, especially to make things available on global scope.As they started moving jQuery plugins over, s...

83 MIN5 d ago
Comments
RR 434: Surviving Webpack with Ross Kaffenberger

RR 433: ShipLane with John Epperson

John Epperson has been doing ruby for 12 years and is a friend of Andrew Mason. He got into Docker a couple years ago and felt like something was missing, so he wrote Shiplane. He liked Docker because it was a promise that he could delegate a lot of the manual devops work to something else, and that something else was able to automate all of it. What he noticed was if you have a Docker thing in development and want to transfer it into production, there was no clear path to get a Docker item from development to production. The process wasn’t truly automated, so he created ShipLane in an attempt to automate it. ShipLane solves this problem by assuming that you have a box out there, whether it’s a VM or an actual physical box, and you have SSH access to it. It logs in, it makes sure you have Docker installed, and gives you the ability to actually take your development docker compose, and convert it to a productionized version. It also hooks in to Capistrano and replaces that with ShipLane commands. Right now ShipLane is using Docker Raw and creates a network for your stuff to work within, deploys your containers, and then your service is up and running. There are different tools you can use to run Docker in production, but John didn’t want to run containers by using Docker Run with a bunch of stuff after it, didn’t want to maintain a custom script, so he automated it. John is currently working on a version that will translate your Docker Compose files into Kubernetes YAML files. There’s a lot of choices to be made in Rails, none of which are wrong, but one choice begets many more, and there’s so many to make and so many consequences it’s difficult to know your path, and ShipLane provides clearer a path. John talks about how to get started with ShipLane. First, you need to gem install ShipLane and Capestrano, put it in your bundle file, and require it in Capestrano (there’s a generator). It has Capestrano listed as a dependency requirement. Andrew has used ShipLane and found it very quick and effective, only took them about 30 minutes. John asks for feedback from users on ShipLane, since many people are using it but no one has given any. John talks about the versatility of ShipLane as a general solution. He addresses some concerns that people have about putting stuff into containers, and assures them that ShipLane is intended to work right out of the box. It is important that when containerizing services available on the platform of our choice to step back and question if you creating this infrastructure correctly. They discuss some methods for deciding what goes into containers. The panel discusses some of the advantages of Docker, particularly deployment time. Everything is already bundled, the assets are precompiled, so it cuts your deployments down a lot. They talk about different frameworks for Ruby that they like for their scaling abilities, such as Docker, Kubernetes, and Elastic Beanstalk. While Elastic Beanstalk is not one of the primary targets of ShipLane, it is designed as a generalized path to go from development to production, so it shouldn’t matter what your production target is in the end. If you’re gonna pick a provider that isn’t one of the big 3, then ShipLane is a great option If you’re picking a SASS provider, there’s always a possibility that it isn’t compatible with the generalized version, but if we’re targeting Kubernetes it should generally work. The panel discusses the general advice not to use Docker in development and whether or not it has merit. John finds that flips back and forth between projects, and those projects all have different dependencies, so Docker makes it easier to switch between projects because he doesn’t have to think about the dependencies. They talk about how John manages his Docker /compose version with these various projects. They all agree that Kubernetes should not be run locally. Finally they discuss whether tools like ShipLane are the next step with Docker. They beli

64 MIN1 w ago
Comments
RR 433: ShipLane with John Epperson

RR 432: Stop Testing, Start Storytelling with Mike Schutte

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling. Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should...

40 MIN2 w ago
Comments
RR 432: Stop Testing, Start Storytelling with Mike Schutte

RR 431: Building a Consulting Business with Todd Kaufman

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. Tod

68 MIN3 w ago
Comments
RR 431: Building a Consulting Business with Todd Kaufman

RR 430: Opal with Elia Schito

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...

59 MINSEP 17
Comments
RR 430: Opal with Elia Schito

RR 429: Mechanical Confidence with Adam Cuppy

Episode Summary Adam 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 thing The 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 work The 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 is They 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 Panelists Andrew Mason David Kimura Nate Hopkins Charles Max Wood With special guest: Adam Cuppy 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 Adventures in Devops Links Zeal Teamocil Docker TDD Speakerline Follow DevChat on Facebook and Twitter Picks David Kimura: Belt sander PingVerse Nate Hopkins: Talent is Overrated Confreaks 10 Years: Keynote Andrew Mason: His company is hiring, contact him @andrewmcodes Charles Max Wood: Algolia RXJS Live Gitlab Commit Adam Cuppy: This Is Marketing by Seth Goden Interestings podcast Follow Adam @adamcuppy

72 MINSEP 10
Comments
RR 429: Mechanical Confidence with Adam Cuppy

RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

ESponsors Sentry use code “devchat” for $100 credit Sustain Our Software Adventures in Blockchain Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood With Special Guest: David Heinemeier Hansson Episode Summary Today’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...

76 MINSEP 3
Comments
RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

RR 427: Sorbet, a Type Checker for Ruby with Paul Tarjan

Sponsors Sentry use code “devchat” for $100 credit Datadog React Native Radio Panel David Kimura Andrew Mason With Special Guest: Paul Tarjan Episode Summary Paul 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. Links Stripe Sorbet Sorbet Rails Sorbet Static Ocra mypy TypeScript Sorbet.run Flow React Follow DevChat on Facebook and Twitter Picks Andrew Mason: Stimulus Reflex David Kimura: Pingverse Paul Tarjan: Follow Paul https://paultarjan.com/ Sorbet

47 MINAUG 27
Comments
RR 427: Sorbet, a Type Checker for Ruby with Paul Tarjan

RR 426: Dockerized Development Environments with Julian Fahrer

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Charles Max Wood With Special Guests: Julian Fahrer Episode 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. Links JSJ 340: JavaScript Docker with Julian Fahrer EMX 10: Docker with Julian Fahrer Docker Heroku Alpin.io Ubuntu Docker Sink OSXFS Spring Webpacker AWS PostgreSQL Elasticsearch Kubernetes Scripts to Rule Them All LearnDocker.online Follow DevChat on Facebook and Twitter Picks Andrew Mason: Alsop Metal Art Dual Monitor Arms Mental health days David Kimura: Arcade buttons Mini Dewalt air compressor Julan Fahrer: Alexander Technique Railswithdocker.com Blitz Donner Follow Julian at Codetales.io and @jufahr Charles Max Wood: Four Corners Monument Dallas Children’s Museum

57 MINAUG 20
Comments
RR 426: Dockerized Development Environments with Julian Fahrer

RR 425: Rails + Webpacker with Taylor Jones

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

41 MINAUG 13
Comments
RR 425: Rails + Webpacker with Taylor Jones

Latest Episodes

RR 434: Surviving Webpack with Ross Kaffenberger

Ross Kaffenberger is a software engineer at Stitch Fix and has been developing web applications for the past 12 years, mostly in Ruby and JavaScript. Today he and the panel are discussing how to survive Webpack. When many folks first encounter Webpack, they feel confused, overwhelmed, and don’t know how to get it to do what you want it to. In the latest version they tried to introduce some more sane default settings, but it is still a major change in technology. Ross talks about how his company transitioned Rails 5 to Rails 6 with the new Webpacker. His company chose to take an iterative approach and slowly migrated to Webpacker. His app was very JS heavy with a large number of libraries, many of which were not very Webpack friendly. They chose to separate out the vendor libraries into a separate bundle, that way they could contain each deploy. They still had to add some configuration, especially to make things available on global scope.As they started moving jQuery plugins over, s...

83 MIN5 d ago
Comments
RR 434: Surviving Webpack with Ross Kaffenberger

RR 433: ShipLane with John Epperson

John Epperson has been doing ruby for 12 years and is a friend of Andrew Mason. He got into Docker a couple years ago and felt like something was missing, so he wrote Shiplane. He liked Docker because it was a promise that he could delegate a lot of the manual devops work to something else, and that something else was able to automate all of it. What he noticed was if you have a Docker thing in development and want to transfer it into production, there was no clear path to get a Docker item from development to production. The process wasn’t truly automated, so he created ShipLane in an attempt to automate it. ShipLane solves this problem by assuming that you have a box out there, whether it’s a VM or an actual physical box, and you have SSH access to it. It logs in, it makes sure you have Docker installed, and gives you the ability to actually take your development docker compose, and convert it to a productionized version. It also hooks in to Capistrano and replaces that with ShipLane commands. Right now ShipLane is using Docker Raw and creates a network for your stuff to work within, deploys your containers, and then your service is up and running. There are different tools you can use to run Docker in production, but John didn’t want to run containers by using Docker Run with a bunch of stuff after it, didn’t want to maintain a custom script, so he automated it. John is currently working on a version that will translate your Docker Compose files into Kubernetes YAML files. There’s a lot of choices to be made in Rails, none of which are wrong, but one choice begets many more, and there’s so many to make and so many consequences it’s difficult to know your path, and ShipLane provides clearer a path. John talks about how to get started with ShipLane. First, you need to gem install ShipLane and Capestrano, put it in your bundle file, and require it in Capestrano (there’s a generator). It has Capestrano listed as a dependency requirement. Andrew has used ShipLane and found it very quick and effective, only took them about 30 minutes. John asks for feedback from users on ShipLane, since many people are using it but no one has given any. John talks about the versatility of ShipLane as a general solution. He addresses some concerns that people have about putting stuff into containers, and assures them that ShipLane is intended to work right out of the box. It is important that when containerizing services available on the platform of our choice to step back and question if you creating this infrastructure correctly. They discuss some methods for deciding what goes into containers. The panel discusses some of the advantages of Docker, particularly deployment time. Everything is already bundled, the assets are precompiled, so it cuts your deployments down a lot. They talk about different frameworks for Ruby that they like for their scaling abilities, such as Docker, Kubernetes, and Elastic Beanstalk. While Elastic Beanstalk is not one of the primary targets of ShipLane, it is designed as a generalized path to go from development to production, so it shouldn’t matter what your production target is in the end. If you’re gonna pick a provider that isn’t one of the big 3, then ShipLane is a great option If you’re picking a SASS provider, there’s always a possibility that it isn’t compatible with the generalized version, but if we’re targeting Kubernetes it should generally work. The panel discusses the general advice not to use Docker in development and whether or not it has merit. John finds that flips back and forth between projects, and those projects all have different dependencies, so Docker makes it easier to switch between projects because he doesn’t have to think about the dependencies. They talk about how John manages his Docker /compose version with these various projects. They all agree that Kubernetes should not be run locally. Finally they discuss whether tools like ShipLane are the next step with Docker. They beli

64 MIN1 w ago
Comments
RR 433: ShipLane with John Epperson

RR 432: Stop Testing, Start Storytelling with Mike Schutte

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling. Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should...

40 MIN2 w ago
Comments
RR 432: Stop Testing, Start Storytelling with Mike Schutte

RR 431: Building a Consulting Business with Todd Kaufman

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. Tod

68 MIN3 w ago
Comments
RR 431: Building a Consulting Business with Todd Kaufman

RR 430: Opal with Elia Schito

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...

59 MINSEP 17
Comments
RR 430: Opal with Elia Schito

RR 429: Mechanical Confidence with Adam Cuppy

Episode Summary Adam 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 thing The 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 work The 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 is They 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 Panelists Andrew Mason David Kimura Nate Hopkins Charles Max Wood With special guest: Adam Cuppy 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 Adventures in Devops Links Zeal Teamocil Docker TDD Speakerline Follow DevChat on Facebook and Twitter Picks David Kimura: Belt sander PingVerse Nate Hopkins: Talent is Overrated Confreaks 10 Years: Keynote Andrew Mason: His company is hiring, contact him @andrewmcodes Charles Max Wood: Algolia RXJS Live Gitlab Commit Adam Cuppy: This Is Marketing by Seth Goden Interestings podcast Follow Adam @adamcuppy

72 MINSEP 10
Comments
RR 429: Mechanical Confidence with Adam Cuppy

RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

ESponsors Sentry use code “devchat” for $100 credit Sustain Our Software Adventures in Blockchain Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood With Special Guest: David Heinemeier Hansson Episode Summary Today’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...

76 MINSEP 3
Comments
RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

RR 427: Sorbet, a Type Checker for Ruby with Paul Tarjan

Sponsors Sentry use code “devchat” for $100 credit Datadog React Native Radio Panel David Kimura Andrew Mason With Special Guest: Paul Tarjan Episode Summary Paul 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. Links Stripe Sorbet Sorbet Rails Sorbet Static Ocra mypy TypeScript Sorbet.run Flow React Follow DevChat on Facebook and Twitter Picks Andrew Mason: Stimulus Reflex David Kimura: Pingverse Paul Tarjan: Follow Paul https://paultarjan.com/ Sorbet

47 MINAUG 27
Comments
RR 427: Sorbet, a Type Checker for Ruby with Paul Tarjan

RR 426: Dockerized Development Environments with Julian Fahrer

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Charles Max Wood With Special Guests: Julian Fahrer Episode 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. Links JSJ 340: JavaScript Docker with Julian Fahrer EMX 10: Docker with Julian Fahrer Docker Heroku Alpin.io Ubuntu Docker Sink OSXFS Spring Webpacker AWS PostgreSQL Elasticsearch Kubernetes Scripts to Rule Them All LearnDocker.online Follow DevChat on Facebook and Twitter Picks Andrew Mason: Alsop Metal Art Dual Monitor Arms Mental health days David Kimura: Arcade buttons Mini Dewalt air compressor Julan Fahrer: Alexander Technique Railswithdocker.com Blitz Donner Follow Julian at Codetales.io and @jufahr Charles Max Wood: Four Corners Monument Dallas Children’s Museum

57 MINAUG 20
Comments
RR 426: Dockerized Development Environments with Julian Fahrer

RR 425: Rails + Webpacker with Taylor Jones

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

41 MINAUG 13
Comments
RR 425: Rails + Webpacker with Taylor Jones