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 446: Development Environments
Today the panel is talking about their development environments and preferences. Most of them run on Macs, but they talk about other operating systems. They discuss some of the pros and cons of using Apple products. While Apple has conveniences to help you restore data, many of them have had issues with cabling and the fact that Macs are not easily extendable. They agree that the speed at which a development environment gets up and running is less about the hardware and more about how the environment is set up.The conversation turns to which development platforms they are running. They discuss the value of Docker as a development environment. The panel compares the features of database management systems such as MySQL, MariaDB, and Postgress. David feels that getting up and running in an environment is the most important thing, but the panel challenges him to consider the maintenance required in some environments. The Ruby experts discuss the merits of using RVM and what they like about it, testing libraries they are using, and how they feel about certain gems. The tradeoffs between security and ease of use are discussed. They conclude the show by talking about the benefits of mechanical keyboards and duo vs. single monitor setups.Panelists David Kimura John Epperson Charles Max Wood Sponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen ____________________________> "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Links Linux Time Machine NetBeans VIM Docker MariaDB MySQL LIV8 Lazy Docker RVM RSpec Mini Test Ruby 2.7 Release Ruby 2.7 features What’s New in Ruby 2.7 Ruby changes reference PicksDavid Kimura: DeWalt Laser Distance Measurer Melamine boards Charles Max Wood: OBS The Man in the High Castle John Epperson: Monopress cable Glengoyne Cask Strength, Monoprice
RR 445: Location Services with Mithun Dhar
Mithun leads development relations at HERE Technologies which specializes in building location services and location platforms. A lot of location is so seamlessly integrated we don’t even have to think about it, but it’s quite complex. He talks about how location services work, such as a ride-sharing app. He talks about some of the tools and data available from HERE Technologies for people who want to use location services. The panel discusses when to use services from companies like HERE and when you should try to do it on your own. Mithun talks about other ways HERE’s services can be utilized. The panel discusses how companies can get mapping so wrong, and Mithun talks about some of the complexities involved in mapping. David Kimura talks about some of his experiences with creating a location app, and the panel talks about the unlimited applications of location services.Mithun talks about how location services are tested and how they are impacting the public sector and the future of mobility. Mobility is the overarching term for all of location services, such as public transportation, traffic, etc. This is changing a lot in many places, but especially in places like Dubai where self-driving cars are becoming more and more common. The panel discusses how to think about location services as a developer. Mithun talks about how to move from web to mobile development. The panelists discuss the issue of privacy and location services. Mithun talks about how HERE Technologies protects individual data and privacy.Panelists David Kimura John Epperson Charles Max Wood GuestMithun T DharSponsors Sentry | Use the code “devchat” for $100 credit____________________________> "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Links HERE Technologies Google maps timeline PicksDavid Kimura: Google Remote Desktop Hatchbox3d Charles Max Wood:Letters from WhitechapelJohn Epperson: Never Split the Difference Kilkerran Scotch Mithun Dhar: The Culture Code Follow Mithun on Twitter and LinkedIn Special Guest: Mithun Dhar.
RR 444: Rails Against the Machine
Brittany Martin, Lead Web Developer at the Pittsburgh Cultural Trust joins the panel today to talk about her talk "Rails Against The Machine". She has given this talk at Southeast Ruby, Rubyconf MY and Ruby on Ice.Brittany Martin works for the Pittsburgh Cultural Trust as the nonprofit’s Lead Web Developer, where she is part of the team that develops, supports and maintains the Trust’s ticketing and festival web applications. She is a certified AWS Developer and the host of the 5by5 Ruby on Rails podcast. Under her alter-ego, Norma Skates, Brittany officiates roller derby for the Little Steel Derby Girls.Her talk's elevator pitch is as follows: "What should a development team do when a few bad users threaten their application? Online businesses are plagued with trolls and bots. Learn how your team can leverage features from RoR and AWS to monitor and (secretly) segment bad actors using automation and behavioral triggers."Brittany and the panel address questions such as "When is it better to block a user instead of incorporating them into your app?" and "How do you know the difference between a security threat or something trying to game the system?" Panelists Dave Kimura Andrew Mason Charles Max Wood GuestBrittany MartinSponsors Sentry | Use the code "devchat" for $100 credit RedisGreen Adventures in DevOps Podcast CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Links Brittany's Talk Podcast Brittany Hosts https://twitter.com/BrittJMartin https://www.instagram.com/wonderwomaninthemaking/ https://brittanymartin.dev https://github.com/wonderwoman13 PicksAndrew Masonhttp://expo.stimulusreflex.com/Dave Kimura Stay secure with CyberGhost VPN Free Proxy https://github.com/danmayer/coverband Charles Max Woodhttps://devchat.tv/events/Brittany Martin KBDfans – KBDfans Mechanical Keyboards Store http://rubyconf.org/ CrossFit Games: The Open Special Guest: Brittany Martin.
RR 443: Sharing Tips from the Trench with Sven Akerman Jr.
Sven Akerman Jr. is the chief architect at Outlook Insight. Today he and the panel are talking about the process behind development, specifically how Sven helped improve the software development process at his previous employer. When he started, they had a formal Scrum/Agile process for the first 5 years, but recognized gaps using key performance indicators like turnaround time. So the company implemented the single piece flow method, which ensures that all developers are focused on one thing from start to finish before moving on. As a company, they have a maximum of 2 products in play at a time, with two in focus. Some of the benefits of single piece flow are that it reduces context switching and increases group knowledge and involvement. Sven talks about how the method was implemented in the company, and admits that it takes a really efficient delivery pipeline to move things this quickly. For those that don’t have much to do with a project, the ‘bored void’ was filled with a list of other important things to work on, finding ways to make their own improvements in an area, and automation. Sven found that the method scales well and works both in an office or remote. One of the biggest drawbacks of this method was the psychological barrier among the workers, as it was hard to get people to change the way things “have always been done”. He notes that conversations in meetings shifted from ‘me’ to ‘us’ since people were more aware of others’ work. This shift occurred naturally with the enforcement of the constraints, though it took a couple of months. Sven talks about more ways he saw things change. Charles and David discuss things about this method that interest them, such as shipping things quicker. They talk about possible difficulties with technical debt, which Sven found actually decreased over time. In order to get started with the single piece flow method, it is important to first understand where you’re at and the size and capabilities of your team before moving forward. Panelists David Kumura Charles Max Wood GuestSven Akerman Jr.Sponsors Sentry | Use the code “devchat” for $100 credit RedisGreen Links Outlook Insight Scrum Agile development Kubernetes PicksDavid Kimura: NGINX Reverse Proxy DeWalt Ceramic Rapid Heat Full Size Glue Gun Charles Max Wood:DiscourseSven Akerman Jr.: Getting off of hardware Follow Sven on LinkedIn @svenakermanjr or outlookinsight.com Special Guest: Sven Akerman Jr.
RR 442:Ruby Rogues Live at GitLab Commit 2019
In this episode of Ruby Rogues, Charles Max Wood interviews speakers at GitLab Commit 2019. Eddie Zaneski from Digital Ocean talks about "Creating a CI/CD Pipeline with GitLab and Kubernetes in 20 minutes", Shamiq Islam from Coinbase talks about "Closing the SDLC Loop- Automating Security" and Jasmine James, from Delta Airlines, discusses " How Delta Became Cloud Native-Avoiding the Vendor Lock".Eddie, Shamiq, and Jasmine give the 5 min "elevator pitch" for the talks they gave at the conference.In his talk, Eddie deploys a fake startup going through the whole pipeline: building the application, containerizing an application and shipping it off to Kubernetes.Shamiq, talks about how the conventional approach to security is to consider it at the very end after all developer has wrapped up their work and why that should change.Jasmine explains more in-depth what it means for a big corporation like Delta to be in a Vendor Lock.Sponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen _____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Links Creating a CI/CD Pipeline with GitLab and Kubernetes in 20 minutes by Eddie Zaneski Hacktoberfest presented by DigitalOcean and DEV Commit Brooklyn 2019: Closing the SDLC Loop - A Security Panel by Shamiq Islam Commit Brooklyn 2019: How Delta Became Truly Cloud Native - Avoiding the Vendor-Lock by Jasmine James Special Guests: Eddie Zaneski , Jasmine James, and Shamiq Islam.
RR 441: Solidus with Alessandro Desantis
Alessandro Desantis is the director of Nebulab and is currently working on Solidus. After talking a little bit about how Nebulab got started, he describes what Solidus is. Solidus is a free, open source eCommerce platform built in Ruby on Rails that gives you complete control over your store. Three things that set it apart from other eCommerce platforms are that it is governed by a single company and that the focus is on quality and backwards compatibility. One of their biggest goals is to make Solidus streamlined, and Alessandro talks about how they handle it with the complex business logic involved in eCommerce. He talks more about the governance of Solidus and the different teams involved. Alessandro admits that Solidus has fewer features than some of its competitors, but this makes it very powerful and customizable. It can be tacked onto any Rails engine and you can pick and choose the things you want. Solidus was made with fewer features because of the unique nature of each eCommerce store. The creators noticed that when people create their stores, they had to adapt their business to suit the eCommerce software they used because the software was not as customizable. Solidus wanted to avoid that, so they provide the foundation and people can customize it. To customize Solidus, the documentation is available on the Solidus website, but the company encourages experimentation. Alessandro regrets that people think eCommerce companies are not technology companies, and so they tend to delegate it to someone else. He and Charles talk about some of the technical aspects of Solidus and what the future holds. In the future, the company plans to emphasize communication and the presentation of Solidus as a tool to help people make the right choice for their business, as well as streamlining the onboarding experience. To contribute to Solidus, you can contribute to the core itself or any of the extensions. There is also an active Slack community where you can ask for the best place to help. The show concludes with Alessandro talking about some of the other projects he’s working on. PanelistsCharles Max WoodGuestAlessandro DesantisSponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen Links Solidus Nebulab Shopify Backbone Solidus Slack community Follow Alessandro on Medium and Alessandro.codes PicksCharles Max Wood:A Christmas StoryAlessandro Desantis: London, UK Elixir Phoenix Special Guest: Alessandro Desantis.
RR 440: Swagger and OpenAPI with Josh Ponelat
Today the panel discusses the difference between Swagger and Open API with Josh Ponelat. Josh details the difference between the two. Swagger is a set of protocols around describing restful APIs. Swagger was taken over by a company called SmartBear, who donated the donated the specification to the Open Linux Foundation, and that became the Open API. Swagger is the tooling surrounding these specifications. Open API is a standardized way to describe a restful API in a YAML file. Once you’ve got a YAML file to describe your API, you can use tooling like Swagger to leverage that and take it to the next level. Using the Open API process is useful for situations where you already have an API in place, but want to codify and document it so that it’s controlled. Then going forward, you won’t introduce contradictions and it remains consistent because it’s documented in a YAML file. The process leaves room for enhancement in the future as well.Josh talks about some of the benefits of standardizing your API and some of the use cases besides tooling. A standardized API can help show developers how to use your API, SDKs, and service stubs by knowing your API is consistent in style. This makes it easier to find breaking changes and more. Josh talks more about Swagger, a finite set of tooling around Open API, most of which are open source. He talks about other tools that test APIs and do linting on YAML files. Some of the companies that use Open API include Google, Amazon, and Microsoft. Josh talks about how Amazon implements Open API.Josh talks about the book he’s writing, Designing APIs with Swagger and Open API. The book goes over describing APIs today, how to design APIs without writing code first, and how to get the most out of the system. The show concludes with Josh talking about the power of consistency and writing things down on paper. He discusses where implications that the standardization of APIs has on the text industry.Panelists Dan Shappir Charles Max Wood GuestJoshua S. PonelatSponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen _____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Links Josh's Twitter Swagger Open API Difference Between Swagger and Open API GraphQL Designing APIs with Swagger and Open API PicksDan ShappirSaga of Pliocene ExileCharles Max Wood DevChat.tv Merchandise BusyCal Josh Ponelat AsciiDoc FASD tool Special Guest: Josh Ponelat.
RR 439: Human Powered Rails: Automated Crowdsourcing In Your RoR App with Andrew Glass
Andrew Glass is a Brooklyn based Rubyist operating a small independent devshop called Bang Equals. He has held many ‘enrichment jobs’, including being a ball person at US Open for 5 years, traveling for judging Guinness World Record attempts, and will be a balloon holder in the Macy’s Thanksgiving Day Parade this year. Today the panel is discussing his about his 2018 RailsConf talk, Human Powered Rails: Automated Crowdsourcing In Your Ruby on Rails App. In his talk, he shows the audience how to use Amazon Mechanical Turk. Amazon Mechanical Turk lets you post tasks, set a price point, and then people can go and complete the task. This is often done with tasks that can’t be done with machine learning and to train machine learning algorithms. In his talk he goes into What it is, how it’s used, and how we can use Ruby to automate the process. In his apps, he uses it for lead generation, qualification, enrichment, and some video and photo tagging. More specific uses include recording items from a picture of a shopping list, identifying specific things in a video, categorizing businesses and items, sentiment analysis of text or image. Overall, Mechanical Turk is used for things that machine learning can’t handle yet. The panel discusses some different uses for crowdsourcing and how to submit something to Mechanical Turk. There are multiple ways to ensure accuracy in your surveys, including setting up multiple stages to your task, having more than one person complete your task, and creating a qualified worker pool based on tests to determine their aptitude and skill. The panel discusses some of the controversy surrounding Mechanical Turk, citing an article in the New York Times (see links). The big issue is wages and worker rights. Wages can be very low, and it is ripe for abuse by companies as they could easily refuse all work and withhold pay. It is also important for the companies to give an accurate time estimate for the task and a reasonable reimbursement. Mechanical Turk attracts a variety of people, from people that do it for fun to people to actually do it for a living, so it is vital that companies use the tool responsibly. Andrew talks more about how his app works. His apps are built on RTurk, Turkee, and Mechanical Turk, and he talks about how they work. The tricky part is figuring out the logic for what answers they will accept. Andrew talks about how to get started with Mechanical Turk and how to validate the work you get back. To ensure you get accurate information, he suggest that you make it happy for your users, make the UX simple and usable, and use a lot of formatting in your forms so that you get good information in. They preface their results with an accuracy score to help determine what is true. Andrew talks about where he wants to go from he. His Turking days are behind him, but his days of coordinating the efforts of many using software show promise. Panelists Dave Kimura Charles Max Wood GuestAndrew GlassSponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19 RedisGreen Links Human Powered Rails: Automated Crowdsourcing In Your RoR App by Andrew Glass Amazon Mechanical Turk AWS Transcribe I Found Work on an Amazon Website. I Made 97 Cents an Hour. RTurk Turkee AWS SDK Turk PicksDave Kimura:HatchBoxCharles Max Wood: The MaxCoders Guide to Finding Your Dream Developer Job White Christmas Andrew Glass: Foragoodstrftime.com Follow Andrew @andrewglass1 on Twitter and Instagram and andyglass.co Special Guest: Andrew Glass.
RR 438: Deviating from the Rails Core
Today Charles and Dave are discussing deviating from the Rails core. Dave doesn’t care for JavaScript frameworks or microservices as he believes that they add too much complexity. These things may become necessary when your project gets massive, but otherwise we shouldn’t jump to these as a first option. If you don’t need the frontend powerhouse features, you may want to see how far you can get with Rails and a minimal frontend. React may not always be the solution that you need. They discuss jQuery versus Stimulus. They both prefer jQuery over Stimulus as they find it less invasive and clunky, and it’s easier to drop things in. Dave talks about his experience with ElasticSearch and how he simplified it. They discuss using MongoDB and Mongoid. They agree that although these are not Ruby specific, they can help. Dave, however, has not found a need for them, while Charles has found that it gave him more advantages in his schema. He talks about some other advantages of MongoDB. Dave and Charles discuss the default testing library for Rails, MiniTest. Dave prefers RSpec, but he still uses Mini test because it’s included in the rails core. He has found that RSpec benefits him, while Mini Test benefits his application, so he sticks to what’s included. He believes that sticking close to the core and counting on the widely used things keeping up to speed makes maintaining on the application easier, and things are less likely to break. They turn to discussing when it is appropriate to deviate. Again, Dave believes that small applications without a massive amount of traffic don’t need to deviate, but adds that unique situations require unique solutions. It’s important to Consider if the solution will box you into an infrastructure provider or long term maintenance on something you don’t usnderstand. They agree that the goal is to introduce the least amount of technical debt as possible. Panelists Dave Kimura Charles Max Wood Sponsors Sentry | Use the code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $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 Backbone React Vue Stimulus jQuery Mongoid MongoDB Elastic Search Squel.js JSON RSpec PicksDave Kimura: Nextcloud DGI Osmo 3 Charles Max Wood: The MaxCoders Guide to Finding Your Dream Developer Job Buymeacoffee.com It’s A Wonderful Life Mr. Kreuger’s Christmas
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.