All Ruby Podcasts By Devchat.tv

David Kimura and John Epperson talk with Ian Norris on his experiences with Pair Programming. We discuss misconceptions, when pair programming works and when it doesn’t, remote paring and different types of pair programming.Panel:Dave KimuraJohn EppersonGuest:Ian NorrisSponsors:Resolve Digital____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Links:Ruby by the Bay / Ruby for Good - Making the world gooderRubyConf 2019 - Lightning Talks - Ian NorrisBackerKitPicks:Dave Kimura:Visual Studio Live ShareEasiest wall FIX EVERJohn Epperson:Jim Butcher's Codex Alera SeriesPaper Towel Rolls - makes great toys for your kidsIan Norris:Follow Ian on Twitter > @TheProphetBrtha, Github, BlogOn Pair Programming Follow Ruby Rogues on Twitter > @rubyrogues  Special Guest: Ian Norris. Advertising Inquiries: https://redcircle.c

Colin Fulton has written a Ruby implementation in assembly for the Apple II. He's also got a fondness for the impossible and impractical applications of software. He walks through how he approached writing a somewhat limited version of Ruby for a old and limited machine. He also talks through other ways to explore the limits of Ruby and other programming languages.Panel:Charles Max WoodDave KimuraJohn EppersonGuest:Colin FultonSponsors:Resolve Digital____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Links:Ruby on the AppleThat Works?! Quines and Other Delightfully Useless ProgramsPicks:Charles Max Wood:New Devchat.tv Podcast - Clean CodersStar Trek: PicardDave Kimura:Guillotine Paper CutterJohn Epperson:Clint's Salsa - Medium MexicanReact Native Hot ReloadingColin Fulton:Follow Colin on Twitter - @PeterQuines, GitH

In this episode of Ruby Rogues, Zachary and the panelists speak about doing small projects. They cover half-done projects, when is a project really “done” and staying focused. An unfinished project is not a failure and making a small project helps to make a complete project.PanelDave KimuraJohn EppersonGuestZachary SchroederSponsorsResolve DigitalRedisGreen________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________Linkshttps://www.youtube.com/watch?v=taYx6Dy6dwIhttps://github.com/robobluebird/ruby-lofiRuby | GosuRuby2dPicksDave Kimura:Noble Chair EpicDewalt Trim RouterJohn Epperson:Lagavulin 16 Year Old Scotch WhiskyOffice ChairZachary Schroeder:Zachary's GithubRiding a BikeThe Thermals - Live on KEXPSpecial Guest: Zachary Schroeder. Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.c

Jon Druse is a developer from Tennessee and has been using Rails for 15 years. He starts the show by sharing some of the background behind his RailsConf talk “How To Lose 50 Milion Records in 5 Minutes” and the various mistakes that were made that lead to such a dramatic loss. The loss of these records lead the company to refactor and rewrite the entire app in MongoDB. Jon talks about the decision to use Mongo. One of the main points of his talk was that their mistake was discovered because they were trying to figure out wy Elastic Search was getting slow. He counsels listeners to avoid working your way into a poor status quo and accepting it rather than doing something to fix it. If this happens, it can lead to the sudden failure of your app. In the talk, he mentions ‘landmines’, which are things in your app you don’t want to touch and you don’t deal with it until later. In his company, they left these landmines alone and then did something they thought was unrelated, and everything blew up. He stresses the

Bob Quillin and Karthik Gaekwad are on the Oracle developer relations team. Karthik has been on Ruby Rogues previously, and he explains how he went from the Kubernetes team to developer relations. They begin the show by explaining what Kafka is, the leading open-source event streaming platform that Oracle is compatible with. It allows cloud developers to build, publish, and subscribe models for streams of records in addition to many other functions. Systems that used to take a long time to make have become very small and simple with Kafka. Kafka stands out from other message queueing systems because of its robust nature and scalability. Bob goes into more depth about the evolution of Kafka and the panel discusses some different use cases, concluding that Kafka works best for projects with a large amount of data coming in and for making real-time decisions. Bob and Karthik talk about other things Kafka can do beyond the message queue, such as building streams from specific patterns. They talk about when you sh

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

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 th

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 inste

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

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.SponsorsSentry | Use the code “devchat” for $100 creditCloud 66 - Pain Free Rails Deploy

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

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

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 shop

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 defau

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 tal

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 o

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

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 w

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 Ship

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 vie