Ruby Rogues

By Charles M WoodBusiness Technology Education How To Careers

Ruby Rogues episodes

November 20, 2019 The MaxCoders Guide To Finding Your Dream Developer Job
"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is available on Amazon. Get your copy here today only for $2.99!
15 min
November 19, 2019RR 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

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
44 min
November 12, 2019RR 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 action
David Kimura:
Sam’s Club Southern Style Chicken Bites
Cuisinart Air Fryer
Kubernetic (in beta)
Khash Sajadi:
Follow Khash on Twitter @khash
Kasia Hoffman:
Noticent
Special Guests: Kasia Hoffman and Khash Sajadi.

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
56 min
November 05, 2019RR 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.

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
46 min
October 29, 2019MRS 101: Taylor Jones
My Ruby Story this week welcomes Taylor Jones, Support Engineer at Heroku. Charles asks Taylor how he ended up at Heroku. Taylor shares his journey after majoring in Computer Science at Auburn University.
Taylor had a lot of downtime in his first job so he started learning Rails online. Then after he graduated he was able to get more chances working full time with Ruby. He then started speaking at conferences such as RailsConf.
Charles and Taylor talk about how working at a place you really want to is not a pie in the sky but actually is doable if you position yourself correctly. For example Taylor really wanted to work at Heroku and was friends with the people at Heroku. When there was an opening his friends contacted him and Taylor was able to find a job at Heroku.
Charles wonders what drew Taylor to programming and Taylor talks about how he was introduced to developing through video games. Taylor also talks about the concept " if you start out with Ruby you stick with Ruby" and how this was true for him.
Finally Charles wants to know what Taylor's life is like outside of work. Taylor talks about what he does is in his free time which is playing guitars and hanging out with his family and his toddler.
Host: Charles Max Wood
Joined By Special Guest: Taylor Jones
Sponsors
Sentry use the code “devchat” for 2 months free on Sentry small plan

React Native Radio

Adventures in DevOps

CacheFly

Links
RR 425: Rails + Webpacker with Taylor Jones

https://www.heroku.com

https://twitter.com/hiimtaylorjones

www.hiimtaylorjones.com

Picks
Charles Max Wood:
https://jamstackconf.com/sf/

Impact Theory with Tom Bilyeu - Podcast

Taylor Jones:
Super Pumped: The Battle for Uber Book by Mike Isaac

https://www.youneedabudget.com/podcasts/
43 min
October 22, 2019RR 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.

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
1 hr
October 22, 2019MRS 100: The Origin and Impact of My Ruby Story
My Ruby Story celebrates its 100th episode. To commemorate the 100th episode host Charles Max Wood talks about how My Ruby Story podcast started and how it progressed.
My Ruby Story started off as a spin-off of Ruby Rogues. Acting upon advice from a business coach he was working with at the time, Charles misunderstood her suggestion to double on Ruby Rogues and instead proceeded to create a podcast similar to Ruby Rogues. Over the years, the show proceeded to inspire many developers who are just starting out and the show developed a fan base of its own.
Over the years, My Ruby Story has helped people get better jobs, shaped their careers. For those who have been positively affected, Charles requests them to send him an email sharing how My Ruby Story or any other Devchat.tv podcast. If you have any questions or are struggling with how to get a better job, how to talk to your boss, or what steps to take to better your developer career, Charles schedule a call at Schedule a 15 Minute Call with Charles Max Wood.
Host: Charles Max Wood
Sponsors
Sentry use the code “devchat” for 2 months free on Sentry small plan

React Native Radio

My Angular Story

CacheFly

Links
MaxCoders

Schedule a 15 Minute Call with Charles Max Wood

Picks
Charles Max Wood
Extreme Ownership by Jocko Willink (Author, Narrator), Leif Babin (Author, Narrator)

The 360-Degree Leade by John C. Maxwell, Wayne Shepherd
29 min
October 15, 2019RR 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.

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
1 hr 24 min
October 08, 2019RR 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.

Advertising Inquiries: https://redcircle.com/brands

Privacy & Opt-Out: https://redcircle.com/privacy

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
27 min
October 08, 2019MRS 099: Joe Leo
Joe Leo joins Charles Max Wood on this week's My Ruby Story. Joe is the Founder and CEO of the agile software consultancy, Def Method. He shares his journey as a developer. Joe was tutored by his uncle and learned how to code in Basic on a command line. He wanted to be in the music industry and liked math.
Joe is currently working on holistic product development and is delving into areas such as what makes a good product manager and what makes a good product design. Charles and Joe talk about difficulties in quantifying good product management skills or writing tests and other non-coding aspects that surround making a product.
Host: Charles Max Wood
Joined by Special Guest: Joe Leo
Sponsors
Sentry use the code “devchat” for 2 months free on Sentry small plan

React Native Radio

My Angular Story

CacheFly

Links
RR 423: The Well-Grounded Rubyist with David A. Black & Joseph Leo III

The Well-Grounded Rubyist: Covers Ruby 1.9.1 by David A. Black and by III Joseph Leo (Author)

Joe's LinkedIn

Def Method

https://devchat.tv/blog/what-really-makes-a-10x-engineer/

Picks
Joe Leo
https://www.kobee.io/

ACR 2019 Ruby·Rails·React Conference

Charles Max Wood
Sign Up on Devchat.tv for our weekly episode round-up

How to Stay Current in Technology Effectively in 2019

All In by by Adrian Gostick and Chester Elton

For Men Only by Shaunti Feldhahn, Jeff Feldhahn
56 min

About Ruby Rogues

From the publisher's feed

Our original panel podcast, Ruby Rogues is a weekly discussion around Ruby, Rails, software development, and the community around Ruby.

Become a supporter of this podcast: