Our original panel podcast, Ruby Rogues is a weekly discussion around Ruby, Rails, software development, and the community around Ruby.
Similar Podcasts
Flutter 101 Podcast
Weekly podcast focusing on software development with Flutter and Dart. Hosted by Vince Varga.
Views on Vue
Vue is a growing front-end framework for web developments. Hear experts cover technologies and movements within the Vue community by talking to members of the open source and development community.
React Round Up
Stay current on the latest innovations and technologies in the React community by listening to our panel of React and Web Development Experts.
RR 437: Deploying Rails Onto Kubernetes with Khash Sajadi
Khash and Kasia work for Cloud 66, a company started in 2012 with a goal to make Rails deployment simple and infrastructure easy to understand for application developers. As the company has moved towards containerization, they have integrated with Kubernetes. Khash talks about what distinguishes Cloud 66 from other platform as a service companies and why the company was started. He begins by talking about the structure of Heroku, how they own the entire stack down to the server, and how they are bound to a data center. Cloud 66 differs because they decided to break that unit economy from a data center to a server, so they don’t own the entire stack. Instead, they deploy what looks like an experience from Heroku onto your own server so you can go anywhere you want to go. They talk to the public API of those cloud providers within the data center that you choose that your account is in, and then provision, deploy, and maintain your application the way that you used to with Heroku, on that data center. Khash talks about how Kubernetes fits into the Cloud 66 model. Cloud 66 was started with Rails, but they wanted to make it generic and available on any framework, and decided this was best accomplished through containerization. They originally had their own containerization service, but then moved over to Kubernetes. Their Kubernetes for Rails product makes deployment of a Rails application onto Kubernetes extremely simple. The panel discusses the different ways that people get to containerization, and situations where containerization is not the correct solution. They also discuss situations where a containerization service like Kubernetes is useful. Containerization can help a lot with distinguishing and establishing boundaries within a team. Kubernetes can help create uniform servers because you can tell it what you want and it will help you get there, including notifying you when things don’t align. Kubernetes is also excellent at dealing with microservices, if you have a need for a repeatable environment, and provisioning the infrastructure for commits. Khash notes that since moving to a unified infrastructure powered by Kubernetes, upgrades in Cloud 66 take significantly less time and talks about how things have been streamlined.In the past, David has seen some issues with autoscaling in Kubernetes clusters, and Khash talks about how those things have been addressed and how to approach scaling in general. The first two things you need to define with scaling problems is how much is needed and what is ‘normal’ for your product. It is also important to consider if you need to scale up or scale down, as sometimes scaling down can hold more benefits. Khash has noticed that one thing that’s missing in the market is that as Rails developers they’re all about finding the best tools and getting the job done, while this approach is lacking in Kubernetes. He closes the show by talking about how Cloud 66 is trying to address what a Kubernetes deployment means for a Rails stack.Panelists Andrew Mason David Kimura With special guests: Khash Sajadi and Kasia HoffmanSponsors 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 & $100 of free credits with promo code RubyRogues-19 RedisGreen "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon. Get your copy on that date only for $1. Links Heroku Kubernetes Node.js Azure AWS Cloud 66 Follow DevChatTV on Facebook and Twitter PicksAndrew Mason:Rubocop linter actionDavid Kimura: Sam’s Club Southern Style Chicken Bites Cuisinart Air Fryer Kubernetic (in beta) Khash Sajadi: Follow Khash on Twitter @khash Kasia Hoffman:NoticentSpecial Guests: Kasia Hoffman and Khash Sajadi.
RR 436: Determining Pricing with Michael Herold
Michael Herold is married to an economist and is a staff engineer at Flywheel where he writes Ruby programs to support PHP programs. He gave a talk at RailsConf 2018 about how to price a product. The frame for the problem is whenever you have a business idea, you eventually have to decide how to price it, and the pricing area is ripe for inefficiency on both customer and business ends. In his talk, he gave a simple framework based on the field of market research that helps give you an idea of what to price your product or service at called the Van Westendorp Price Sensitivity Meter, which is based off of talking with your customers about how they would value your product. He explains the difference between consumer surplus and producer surplus. The panel discusses other ways of determining pricing, such as basing your price off the price of a similar product. They discuss the pros and cons of different complex pricing they’ve seen. While complex pricing can be a turn off for many customers, it can also weed out less serious customers, and so it can be a good thing. Michael talks about what the Van Westendorp Price Sensitivity Meter actually looks like and how it works. It is based off a 4 question survey where customers are what price is too cheap, what price is a good deal, what price is getting expensive, and what price is too expensive. The answers are charted and you look for intersections in the curves (inflection curves) and it gives you an understanding of how people feel about the price of the product.Determining pricing gets more complicated on a global scale, and the panelists discuss methods to handle it, such as giving discounts and adjusting prices by country. They discuss the importance of choosing the right price for your service, and a price that is too low can be as bad as over pricing. Michael talks about how his company determined their pricing using the Van Westendorp Price Sensitivity Meter and some of the difficulties they encountered. In the future, he wants to make a tool for how to figure out prices so that people don’t have to build their own pricing model. They conclude by discussing the merits of having a sale on your product. Panelists Charles Max Wood Andrew Mason David Kimura With special guest: Michael HeroldSponsors 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 JavaScript Jabber Links Michael Herold RailsConf 2018 Van Westendorp Price Sensitivity Meter Van Westendorp Price Sensitivity Meter graph Consumer surplus Producer surplus Twople Meetspace How Users Picked Our Pricing Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood: Finding human connection Disconnect from technology when you need to David Kimura: Yarn upgrade-interactive Lego 4x4 Michael Herold: Hiking Crinkle book from Jellycat Philipe Fatio blog post The Egg by Andy Weir Follow Michael @mherold on Twitter and Github @michaelherold and michaeljherold.com Special Guest: Michael Herold.
RR 435: Alternatives to Adding React with Graham Conzett
Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it. To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited.Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins.If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive.Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React.The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it.Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham ConzettSponsors 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 Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up Pigeonforteachers.com IKE Smart City Follow Graham @gconzett on Twitter and Github Special Guest: Graham Conzett.
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, sometimes the functionality would disappear, and Ross talks about how they figured out their mistakes. It was difficult for them to get out of their Sprockets mindset and into the new mindset of Webpack, which requires different techniques. There are also things that Webpack can do to keep you out of that situationRoss gives some strategy advice for someone who is in a position to update from Sprockets to Webpack. It’s important to consider your app size, your comfort level with Webpack, your team dynamic, and your timeframe. Ross recommends the iterative approach that they took, which took longer, but allowed them to learn as they went. Ross talks about the changes that happened in the switch from Webpack 3 to Webpack 4, and some of the contributions they made. He talks about some of his preferred Webpack configs and plugins. They discuss some of the drawbacks of Webpack, particularly the plethora of plugins that can make it seem daunting. One of the big gotchas with Webpack is the location of your source code. When you install Webpack for the first time, create a JS folder under App, it will place a ‘application.js’ file in another file called ‘Packs”. The idea of that pack file (application.js file under Packs) is that it’s the entry point for all of the JS that you’re going to add to your Webpack build. But if you add additional files to that Pack folder, Webpacker will instruct Webpack to treat each of those files as a separate entry point in a dependency graph. Make sure that only files that are intended to be the entry points for your Webpack builds are in that packs folder. It is also important to understand how you’re using global scope inside your JavaScript modules in your build. There’s a way to allow Webpack to inspect each of the files for a certain variable, such as a dollar sign. If he could go back and do it again, Ross would not split his code manually, but instead Embrace the notion that Webpack understands how to do code splitting for you, as long as instruct it to do it the right way.Ultimately, it took Ross’ company 3 rather tedious months to transition to Webpack. It could’ve gone faster if they’d known more about Webpack to begin with. The panel discusses whether it was worth it to switch to Webpack. Transitioning to Webpack has changed their team dynamic and their day to day coding and debugging. One nice feature of Webpack is the source maps that aid in debugging. There are still areas for improvement, but now that it’s set up most folks on the team don’t think about it. Overall, the development experience has improved, and he thinks it was worth it, but it’s not for everybody.Panelists Dave Kimura Andrew Mason Nate Hopkins Charles Max Wood With special guest: Ross KaffenbergerSponsors 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 Views on Vue Links Webpack Webpacker Sprockets Knockout.js CKEditor Chosen Webpack Bundle Analyzer Manifest.json Module shimming SplitChunksPlugin Vue Follow DevChatTV on Facebook and Twitter PicksDave Kimura: Avengers Quinjet Lego set Portable air conditioner Nate Hopkins: MDN JavaScript Reference Brandon Sanderson’s Mistborn series Charles Max Wood: Restream Twitch OBS Ross Kaffenberger: Exploring ES6 1 Second Everyday One Sentence Journal Follow Ross on Twitter and Github, and on his blog Special Guest: 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 optionIf 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 believe that containerization is here to stay, but the only thing that might remotely threaten Docker is going back to bare metal development or going serverless. They discuss whether going serverless kills Docker. Ultimately, the most important thing is that the problem gets solved. Panelists Charles Max Wood Andrew Mason David Kimura With special guest: John EppersonSponsors 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 React Round Up Links ShipLane Mountain West Ruby 2016 - Surviving the Framework Hype Cycle by Brandon Hays Docker Capistrano Docker Swarm Kubernetes Docker Compose Chef Puppet Digital Ocean Postgress Sinatra Elastic Beanstalk Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood: VESA adjustment for your monitors Velcro strips For Love of Mother Not David Kimura: Grapes.js Mario Kart Tour Andrew Mason: Hacktoberfest Chuck John Epperson: Glenscotia 15 year scotch Immortals book Follow John on Github, on rockagile.io, and Twitter Special Guest: 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 be written differently.This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things. Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways.Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run.The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components. Panelists Andrew Mason David Kimura With special guest: Mike SchutteSponsors 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 Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter PicksDavid Kimura:Rode PodcasterAndrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js Special Guest: 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. 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. Panelists Charles Max Wood David Kimura Nate Hopkins Andrew Mason With special guest: Todd KaufmanSponsors 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 Blockchain Links Test Double Fixed bid Pipedrive Zoom Slack Follow DevChatTV on Facebook and Twitter PicksDavid Kimura: Simply Heinz Ketchup Pyle Rackmount Distribution Conditioner Nate Hopkins: The War on Normal People by Andrew Yang Test Double Standard RB Library Charles Max Wood: Nikon D5600 Rode Newsshooter Andrew Mason:Remote Containers extensionTodd Kaufman: Drive by Daniel Pink The Hard Thing About Hard Things by Ben Horowitz Special Guest: 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 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 WebPacker Stimulus Hyperstack Capybara CoffeeScript Devise Clearwater Reactive Volt framework Nebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated Billing Pingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his website Explaining Postmodernism Texmate Special Guest: Elia Schito.
RR 429: Mechanical Confidence with Adam Cuppy
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 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 PicksDavid 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 Special Guest: Adam Cuppy.
RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson
Sponsors 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 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. Links Action Text Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow DevChat on Facebook and Twitter PicksAndrew Mason: How to Say It Rework episode Nate Hopkins:Stimulus ReflexCharles Max Wood: Atomic Habits Ed Mylet show The MFCEO with Andy Frisella David Kimura: Swing set kit Rails 6 His daughter Ruby David Heinemeier Hansson: Follow David on Twitter @dhh, dhh.dk and Rework.fm To Have or To Be Shape Up book Rails 6 Special Guest: 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 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. Links Stripe Sorbet Sorbet Rails Sorbet Static Ocra mypy TypeScript Sorbet.run Flow React Follow DevChat on Facebook and Twitter PicksAndrew Mason:Stimulus ReflexDavid Kimura:PingversePaul Tarjan: Follow Paul https://paultarjan.com/ Sorbet Special Guest: 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 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. 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 PicksAndrew 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 Special Guest: 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 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.Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter PicksAndrew Mason:Migration Builder by Jason Swett demo videoDavid Kimura: Build-your-own arcade machine Honey Taylor Jones: Slack Engineering Team Shape Up book from Basecamp Follow Taylor @hiimtaylorjones Special Guest: Taylor Jones.
RR 424: Documenting Your Code
Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Nate Hopkins Andrew Mason Episode 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. Links RDoc YARD RuboCop YAML Slim ERB Prettier Pronto Api.rubyonrails.org Swagger Thoughtbot and Thoughtbot Playbook AirBNB Ruby Testdouble HoundCI Okonet API Blueprint Ruby on Rails API documentation guidelines Tom Preston-Werner article Readme Driven Development Follow DevChat on Facebook and Twitter PicksNate Hopkins:Code FundAndrew Mason: SpaceVIM RailsDiff Rails Releases David Kimura:Jackery Supercharger Portable
RR 423: The Well-Grounded Rubyist with David A. Black & Joseph Leo III
Sponsors Sentry 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 Panel Charles Max Wood Andrew Mason With 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.Links The Well-Grounded Rubyist, Third Edition Perl Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th Edition Practical 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 edition Davidablack.net and @david_a_black on Twitter Joseph Leo III: Barbarians at the Gate Firehydrant.io @jleo3 and defmethod.com Special Guests: David A. Black and Joe Leo III.