Ruby Rogues

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.PanelistsDan ShappirCharles Max WoodGuestJoshua S. PonelatSponsorsSentry | Use the code “devchat” for $100 creditCloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $100 of free credits with promo code RubyRogues-19RedisGreen_____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________LinksJosh's TwitterSwaggerOpen APIDifference Between Swagger and Open APIGraphQLDesigning APIs with Swagger and Open APIPicksDan ShappirSaga of Pliocene ExileCharles Max WoodDevChat.tv Merchandise BusyCalJosh PonelatAsciiDocFASD toolSpecial Guest: Josh Ponelat. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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. PanelistsDave KimuraCharles Max WoodGuestAndrew GlassSponsorsSentry | 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 RedisGreenLinksHuman Powered Rails: Automated Crowdsourcing In Your RoR App by Andrew GlassAmazon Mechanical TurkAWS TranscribeI Found Work on an Amazon Website.  I Made 97 Cents an Hour. RTurkTurkeeAWS SDK TurkPicksDave Kimura:HatchBoxCharles Max Wood:The MaxCoders Guide to Finding Your Dream Developer JobWhite ChristmasAndrew Glass:Foragoodstrftime.com Follow Andrew @andrewglass1 on Twitter and Instagram and andyglass.coSpecial Guest: Andrew Glass. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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. PanelistsDave KimuraCharles Max WoodSponsorsSentry | 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._______________________________________________________LinksBackboneReactVueStimulusjQueryMongoidMongoDBElastic SearchSquel.jsJSONRSpecPicksDave Kimura:NextcloudDGI Osmo 3Charles Max Wood:The MaxCoders Guide to Finding Your Dream Developer JobBuymeacoffee.comIt’s A Wonderful LifeMr. Kreuger’s ChristmasAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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.PanelistsAndrew MasonDavid KimuraWith special guests: Khash Sajadi and Kasia HoffmanSponsorsSentry 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. LinksHerokuKubernetesNode.jsAzureAWSCloud 66 Follow DevChatTV on Facebook and Twitter PicksAndrew Mason:Rubocop linter actionDavid Kimura:Sam’s Club Southern Style Chicken BitesCuisinart Air FryerKubernetic (in beta) Khash Sajadi: Follow Khash on Twitter @khashKasia Hoffman:NoticentSpecial Guests: Kasia Hoffman and Khash Sajadi. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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. PanelistsCharles Max WoodAndrew MasonDavid KimuraWith special guest: Michael HeroldSponsorsSentry 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 JabberLinksMichael Herold RailsConf 2018Van Westendorp Price Sensitivity MeterVan Westendorp Price Sensitivity Meter graphConsumer surplusProducer surplusTwopleMeetspaceHow Users Picked Our Pricing Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood:Finding human connectionDisconnect from technology when you need toDavid Kimura:Yarn upgrade-interactiveLego 4x4Michael Herold:HikingCrinkle book from JellycatPhilipe Fatio blog postThe Egg by Andy Weir Follow Michael @mherold on Twitter and Github @michaelherold and michaeljherold.com Special Guest: Michael Herold. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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.PanelistsCharles Max WoodAndrew MasonDavid KimuraNate HopkinsWith special guest: Graham ConzettSponsorsSentry 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 AngularLinksOld School JavaScript and Rails at RailsConf 2018ReactReact NativeReact Native WebJestCapybaraWebpackerRails-ujsTurbolinksStimulusStimulus ReflexBabelTypeScriptActionview componentsAngular Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood:St. George MarathonOBSDavid Kimura:WeDo 2.0 by LegoWorkflow Automation Self HostedAndrew Mason:Publish to Github actionJustDunning.comNate Hopkins:Company of One by Paul JarvisIndieHackersGraham Conzett:Basecamp’s Shape UpPigeonforteachers.com  IKE Smart City Follow Graham @gconzett on Twitter and Github Special Guest: Graham Conzett. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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.PanelistsDave KimuraAndrew MasonNate HopkinsCharles Max WoodWith special guest: Ross KaffenbergerSponsorsSentry 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 VueLinksWebpackWebpackerSprockets  Knockout.jsCKEditorChosenWebpack Bundle AnalyzerManifest.jsonModule shimmingSplitChunksPluginVue Follow DevChatTV on Facebook and Twitter PicksDave Kimura:Avengers Quinjet Lego setPortable air conditionerNate Hopkins:MDN JavaScript ReferenceBrandon Sanderson’s Mistborn series Charles Max Wood:RestreamTwitchOBSRoss Kaffenberger: Exploring ES61 Second EverydayOne Sentence Journal Follow Ross on Twitter and Github, and on his blog Special Guest: Ross Kaffenberger. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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. PanelistsCharles Max WoodAndrew MasonDavid KimuraWith special guest: John EppersonSponsorsSentry 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 UpLinksShipLaneMountain West Ruby 2016 - Surviving the Framework Hype Cycle by Brandon HaysDockerCapistranoDocker SwarmKubernetesDocker ComposeChefPuppetDigital OceanPostgressSinatraElastic Beanstalk Follow DevChatTV on Facebook and Twitter PicksCharles Max Wood:VESA adjustment for your monitors Velcro stripsFor Love of Mother NotDavid Kimura:Grapes.jsMario Kart TourAndrew Mason:HacktoberfestChuckJohn Epperson:Glenscotia 15 year scotchImmortals book Follow John on Github, on rockagile.io, and Twitter Special Guest: John Epperson. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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. PanelistsAndrew MasonDavid KimuraWith special guest: Mike SchutteSponsorsSentry 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 PodcastLinksStop Teaching. Start Storytelling (RailsConf 2018)Tech Done Right episode 69Law of DemeterGrumpy Old ManRSpecMaxiTestMinitest SpecThoughtbot JestStimulusWebpackerStoryBookCucumberTypeScriptActionview component Follow DevChatTV on Facebook and Twitter PicksDavid Kimura:Rode PodcasterAndrew Mason:Drifting Ruby 196VS Code Ruby DebugMike Schutte: Follow Mike on Twitter @tmikeschuStoryBook.jsSpecial Guest: Mike Schutte. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

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